Summary: Humanity Protocol is moving from Phase 1 (unique-human attestation) to Phase 2 (a full Web3 identity layer) by combining privacy-preserving palm biometrics, W3C Verifiable Credentials, and a developer-first SDK/API. This roadmap explains the architecture, what’s live now, what’s next, and how startups and enterprises can integrate verifiable identity into products with minimal friction and maximal compliance.

Humanity Protocol Phase 1–Phase 2 Technology Roadmap: Web3 Identity Layer and Verifiable Credentials

Decision-makers evaluating decentralized identity have been waiting for a credible, privacy-first alternative to siloed KYC and brittle bot defenses. Humanity Protocol (HP) is emerging as that identity substrate, progressing from a testnet centered on unique-human verification (Phase 1) to a mainnet identity layer that issues and verifies portable Verifiable Credentials (Phase 2). The path is opinionated: smartphone-grade biometrics for inclusivity, palm vein hardware for stronger liveness, W3C DIDs/VCs for interoperability, ZK proofs for minimal disclosure, and a developer platform that aims to get you to “Time to First Verify” in minutes, not weeks. (docs.humanity.org)

Where Humanity Protocol is today

Testnet Phase 2 is rolling out: users with a reserved Human ID from Phase 1 enroll via a mobile app that captures palm prints; developers can already verify if an EVM wallet is tied to a unique, palm-verified human through a public API. This enables Sybil-resistant airdrops, fairer governance, and more. (docs.humanity.org)
Funding and momentum: HP raised $30M at a $1B valuation in May 2024 and another $20M in January 2025 at a $1.1B valuation, co-led by Pantera Capital and Jump Crypto—capital explicitly earmarked to scale rollout. (theblock.co)
Stack choices: HP builds on Polygon’s Chain Development Kit (CDK) for a zkEVM L2, aligning with EVM tooling and cross-chain connectivity; public statements from Polygon Labs and partners underscore that direction. (blockhead.co)

Phase 1 → Phase 2 at a glance

Humanity’s Proof of Trust (PoT) architecture intentionally ships in stages to balance security, decentralization, and developer usability. The high-level evolution looks like this: (docs.humanity.org)

Phase 1 (Testnet):
- Goal: Build the largest network of unique humans.
- Modality: Smartphone palm print (visible light).
- Issuance: HP Core acts as the sole issuer of “unique human” Boolean credentials.
- Data: Centralized VC database, encrypted VC metadata on IPFS; basic sharing. (docs.humanity.org)
Phase 2 (Mainnet identity layer):
- Goal: Become the Web3 identity layer; issue rich VCs (identity, age, employment, geography).
- Modality: Palm print + palm vein (IR) via “Humanity Scanners” for liveness and stronger spoof-resistance; app-based enrollment continues for inclusivity. (docs.humanity.org)
- Issuance: Decentralized via accredited Identity Validators with zkKYC; on-chain revocation. (docs.humanity.org)
- Data: Sharded PII storage + ZK verifiable presentations; encrypted VC metadata on Walrus (Sui) + IPFS; OAuth 2.0 scopes for web developers. (docs.humanity.org)
- Interop: Full support for dApps beyond HP’s chain via APIs/bridges; DID/VC standards. (docs.humanity.org)

The identity stack: what’s under the hood

Standards: HP anchors identity on W3C DIDs and Verifiable Credentials. VCs are cryptographically signed claims; verifiers get only what they need via zero-knowledge verifiable presentations (VPs). If you’re standardizing your internal schemas, align with VC Data Model 2.0 (W3C Recommendation, May 2025). (docs.humanity.org)
Crypto & storage:
- An identity wallet uses a Baby Jubjub keypair, separate from a transactional wallet to prevent linkability/timing analysis. VC data is encrypted with AES-256; keys guarded via a hardware-backed KMS. (docs.humanity.org)
- Encrypted VC metadata is stored on IPFS in Phase 1; in Phase 2, Walrus on Sui + IPFS is used for programmable, verifiable storage at scale. Walrus mainnet launched March 27, 2025. (docs.humanity.org)
Network roles:
- Identity Validators: stake a minimum of 100,000 H to issue credentials; revocation events are recorded on-chain. (docs.humanity.org)
- zkProofer Nodes: verify VCs/VPs without accessing plaintext PII; designed for horizontal decentralization with node licensing tiers (Basic/OG/Founder), capped at up to 100,000 licenses. (docs.humanity.org)
Fees and incentives:
- Verification fees are split among Identity Validators + delegators (25%), a general staking pool (25%), zkProofers (25%), and the Foundation Treasury (25%). This aligns incentives for onboarding real humans and using credentials in the wild. (docs.humanity.org)

What changes practically between phases (and why it matters for you)

Privacy and data management:
- Phase 1: HP Core handles PII; verifiers receive ZK-backed attestations as needed. (docs.humanity.org)
- Phase 2: PII is sharded with validators; non-PII VC metadata becomes decentralized and cross-chain verifiable; verifiers can request ZK VPs for “need-to-know” checks (e.g., “is adult AND EU resident”) without seeing the underlying documents. (docs.humanity.org)
Governance and decentralization:
- Phase 2 introduces DAO participation and validator elections, expanding beyond HP Core as the sole issuer. This matters for enterprises that require multi-party trust and auditable revocation. (docs.humanity.org)
Device coverage and inclusivity:
- Phase 2 adds IR-based palm vein scanning for liveness; enrollment remains contactless and mobile-first. Palm vein’s liveness property is a practical hedge against high-quality spoofs. (docs.humanity.org)

Developer experience: API-first, SDK-backed

HP’s developer platform exposes “verification primitives” so you can integrate checks without becoming a ZK expert. The north-star metric for the platform is “Time to First Verify” in about 15 minutes. (docs.humanity.org)

What’s live: A simple REST endpoint to verify whether a wallet belongs to a unique, palm-verified human.
- GET /v1/human/verify
- Headers: X-HP-API-Key
- Query: wallet_address (EIP-55)
- Response: { wallet_address, is_human, user_id } (docs.humanity.org)

Example (curl):

curl -s "https://api.humanity.org/v1/human/verify?wallet_address=0xAb5801a7D398351b8bE11C439e05C5B3259aeC9B" \
  -H "X-HP-API-Key: YOUR_API_KEY"

If is_human is true, you can gate mints, votes, or signups accordingly—without storing anything sensitive yourself. (docs.humanity.org)

Architecture deep-dive: the PoT verification flow

Enrollment:
- Phase 1: User scans palm print; HP Core issues a “unique human” VC upon non-membership proof pass. (docs.humanity.org)
- Phase 2: User can (a) enroll via mobile app or (b) complete full enrollment via Humanity Scanners (palm print + vein); accredited validators issue domain-specific VCs (e.g., age, KYC tier, employment). (docs.humanity.org)
Presentation:
- A dApp requests “proof of eligibility”; the user shares either a non-PII VC or requests a ZK VP from HP Core (moving to validator-backed generation as decentralization increases). (docs.humanity.org)
Verification:
- zkProofer Nodes verify the proof, record the result on-chain, and the dApp grants or denies access—without seeing raw biometrics or personal data. (docs.humanity.org)

Standards alignment and why it matters for enterprises

Verifiable Credentials (VC) and DIDs are W3C standards with a maturing test suite and a 2.0 Recommendation in 2025. That means interoperable semantics, multiple proof formats (JWT/Data Integrity), and cleaner audits. Adopt VC 2.0 vocabularies where possible; this future-proofs integrations. (w3.org)
HP’s Phase 2 explicitly targets OAuth 2.0–style scopes for web developers and DID/VC portability across L2/L3 and into the physical world—critical if you expect credentials to traverse Web2 and Web3 systems. (docs.humanity.org)

Practical integration patterns (with concrete details)

Sybil-resistant loyalty and airdrops (no KYC friction)

Problem: Bots farm loyalty, skewing CAC/LTV metrics.
Solution: Require an is_human check on wallet connect; defer KYC until redemption. Cache positive checks with short TTLs to minimize repeated calls.
Implementation tip: Use wallet gating via GET /v1/human/verify; store only the boolean + timestamp, not the user_id (unless strictly needed for rate limits). (docs.humanity.org)

Age and region gating for compliant content or RWA access

Problem: Need to attest “≥18” and “EU resident” without collecting PII.
Solution: Request a zero-knowledge VP that encodes both attributes. HP Phase 2 supports such composite VPs, with revocation recorded on-chain if the underlying VC expires.
Operational tip: Make VP requests idempotent by nonce; log verifier consent receipts for audits. (docs.humanity.org)

KYC-light DeFi whitelisting

Problem: Some pools or token offerings require eligibility evidence without full KYC data retention.
Solution: Rely on Identity Validators’ zkKYC credentials; your smart contract or backend accepts a VP that proves “KYC tier ≥ X” without exposing PII. Track revocation registries to invalidate access on status change. (docs.humanity.org)

Workforce & supplier credentials

Problem: Gate internal DAO voting or procurement to verified employees/approved vendors without leaking org charts.
Solution: Your HRIS or vendor portal acts as an Issuer (or delegates to an accredited Identity Validator), minting employment or supplier-status VCs. Smart contracts check “isActiveEmployee=true” at proposal time; on termination, the issuer revokes the VC on-chain. (docs.humanity.org)

DePIN and “palm-to-enter” experiences

Problem: Secure physical access or event check-ins that map cleanly to digital entitlements.
Solution: Humanity Scanners verify on-site via palm vein + print; the access system consumes a VP asserting “authorized for Zone A, today only.” No PII persists in the verifier system. (docs.humanity.org)

Best emerging practices for Phase 2 deployments

Default to minimal disclosure: prefer VPs over raw VCs; when you must store something, store the least—proof receipts and timestamps, not PII. Align schemas with VC 2.0; keep JSON-LD contexts intact. (w3.org)
Separate identifiers: never co-mingle the HP identity wallet with your transactional wallets; HP’s Baby Jubjub identity wallet is designed for unlinkability—respect that separation in logging and analytics. (docs.humanity.org)
Treat the API key as a secret: rotate keys, enforce allowlists, and set rate limits. Cache “is_human” for a short TTL (e.g., 5–15 minutes) to cut latency and cost during bursts. (docs.humanity.org)
Plan for revocation: build a revocation listener or poller; block lists should propagate within minutes to mitigate risk from compromised accounts or rescinded employment. (docs.humanity.org)
Use validator diversity: choose multiple accredited Identity Validators, track their staking and slashing posture, and set policy to accept credentials only from validators that meet your risk threshold (stake amount, slashing history). (docs.humanity.org)
Decide on hardware posture:
- Mobile-only enrollment maximizes reach but offers weaker liveness than IR palm vein.
- For high-stakes gates (e.g., real-world asset custody, facility access), require a “full enrollment” VC (palm vein + print) issued at an in-person event or scanner hub. (docs.humanity.org)
Storage choices: use Walrus for encrypted VC metadata where you want programmable storage and verifiability; IPFS remains fine for non-PII artifacts. Track Walrus epochs and storage commitments just as you track certificate expiries. (walrus.xyz)

What it takes to get started this quarter

Reserve or import Human IDs; if you’re a new user cohort, Phase 2 onboarding lets users choose a Human ID before enrolling their palms. Prioritize high-referral users if you’re running allowlists or pilots. (docs.humanity.org)
Implement a thin “humanity middleware”:
- On connect: call /v1/human/verify; short-cache the result; gate actions accordingly.
- For attributes (age, region, KYC tier): prompt users to present a VP; build a reusable verifier microservice that talks to zkProofer Nodes and your policy engine. (docs.humanity.org)
Pick validator partners: start with two or more accredited Identity Validators; define SLA targets for VP response times and revocation latencies. (docs.humanity.org)
Instrument KPIs:
- Reduction in bot signups/transactions, approval rate lift for legitimate users, time-to-verify, false negative appeals, and cost per verification event (fees, infra).
- Monitor fee splits as a cost center and consider staking H to offset verification fees via rewards. (docs.humanity.org)

Why palm, why now

Unlike face/iris systems that can be cumbersome and culturally sensitive, palm-based verification can be mobile-first and contactless. Phase 2’s IR palm vein adds hardware-enforced liveness—the pattern is under the skin and only visible in a living body—raising the bar for spoofers without imposing expensive, invasive hardware on every user. (docs.humanity.org)

The network and ecosystem trajectory

Economy and token: H has a fixed 10B supply and funds identity attestations, node rewards, and governance; verification fees drive rewards to zkProofers, validators, and stakers, tying token value to real verification demand. (docs.humanity.org)
Node scale: up to 100,000 zkProofer Node licenses target wide distribution; attack modeling includes stake caps, slashing, and anti-collusion measures. (docs.humanity.org)
Chain connectivity: building on Polygon CDK keeps EVM tooling familiar and supports cross-chain interoperability; builders benefit from maturing zkEVM infrastructure and bridges. (coindesk.com)

Putting it all together: a phased enterprise rollout

Phase A (4–6 weeks): Implement is_human gating on a high-bot surface (airdrops, waitlists). Measure uplifts in conversion and fraud reduction.
Phase B (6–10 weeks): Add one attribute VP (e.g., age ≥ 18) for a compliance-relevant flow; establish revocation handling and VP logging.
Phase C (10–16 weeks): Pilot a domain credential (employment, vendor) with one Identity Validator; enforce in a DAO or procurement workflow.
Phase D (quarterly): For sensitive surfaces, move eligible users to full enrollment (palm vein + print) at events or partners’ scanner hubs. (docs.humanity.org)

Final take

Humanity Protocol’s Phase 2 elevates “proof of personhood” from a one-bit signal to a composable, standards-based identity fabric. It preserves user privacy while giving your app precise, auditable assurances—humanity, age, residency, KYC tier, employment—without warehousing PII. For decision-makers, that means lower fraud, simpler compliance posture, and a faster path from idea to integration via a straightforward API and SDKs.

If you’re evaluating where to start, put is_human in front of your most botted surfaces, then add attribute VPs where they deliver measurable risk reduction or regulatory clarity. As validators, zkProofer Nodes, and storage harden, the identity layer becomes not just a guardrail, but a growth driver. (docs.humanity.org)

References and further reading:

Humanity Protocol Whitepaper and Docs: architecture, roles, privacy tables, tokenomics. (docs.humanity.org)
Testnet Roadmap and differences vs. mainnet. (docs.humanity.org)
API Reference: /v1/human/verify endpoint. (docs.humanity.org)
Palm Scanner details and liveness via IR vein. (docs.humanity.org)
Funding coverage (2024–2025). (theblock.co)
Polygon CDK background for L2 chains. (coindesk.com)
W3C VC Data Model 2.0 and DIDs. (w3.org)
Walrus mainnet storage for encrypted VC metadata. (walrus.xyz)

7Block Labs can help you design your VC schemas, wire up HP’s verification flows, and ship a privacy-first identity experience your legal and security teams will sign off on—without slowing down your roadmap.