Summary: Humanity Protocol is taking a big step from Phase 1, which focused on unique-human attestation, to Phase 2, where we're rolling out a full Web3 identity layer. We're doing this by merging privacy-friendly palm biometrics, W3C Verifiable Credentials, and a developer-friendly SDK/API. This roadmap breaks down the architecture, highlights what’s currently live, outlines what’s coming up, and shows how startups and enterprises can easily incorporate verifiable identity into their products with minimal hassle and maximum compliance.

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

Decision-makers checking out decentralized identity solutions have been on the lookout for a solid, privacy-focused alternative to the usual siloed KYC processes and fragile bot defenses. Enter Humanity Protocol (HP), which is stepping up as that identity solution. It's making the leap from a testnet focused on verifying unique humans (Phase 1) to a mainnet identity layer that will issue and verify portable Verifiable Credentials (Phase 2). The approach is pretty straightforward: think smartphone-grade biometrics for better inclusivity, palm vein hardware for enhanced liveness, and W3C DIDs/VCs for seamless interoperability. Plus, they’re using ZK proofs to ensure minimal data exposure. And let's not forget about their developer platform, designed to get you to “Time to First Verify” in just minutes, instead of dragging on for weeks. Check out more details in the roadmap: (docs.humanity.org).

Where Humanity Protocol is today

• The Testnet Phase 2 is officially here! If you snagged a reserved Human ID during Phase 1, you can now enroll through a mobile app that captures your palm prints. Pretty cool, right? Developers can use a public API to verify if an EVM wallet is linked to a unique, palm-verified person. This opens the door for Sybil-resistant airdrops, fairer governance, and so much more. Check it out here: (docs.humanity.org)
• On the funding front, Humanity Protocol (HP) has been killing it! They raised $30 million at a $1 billion valuation back in May 2024 and followed it up with another $20 million in January 2025, now at a $1.1 billion valuation. This round was co-led by Pantera Capital and Jump Crypto, and they're putting that cash to work to scale up their rollout. Want more details? Dive in here: (theblock.co)
• When it comes to tech choices, HP is building on Polygon’s Chain Development Kit (CDK) for a zkEVM Layer 2. This aligns them with EVM tools and cross-chain connectivity. Plus, public statements from Polygon Labs and their partners really highlight this direction. You can find more info here: (blockhead.co)

Phase 1 → Phase 2 at a glance

Humanity’s Proof of Trust (PoT) architecture rolls out in stages on purpose. This strategy helps us strike the right balance between security, decentralization, and making things easy for developers. Here’s a quick look at how it all evolves: (docs.humanity.org)

• Phase 1 (Testnet):
  • Goal: Create the biggest network of one-of-a-kind humans.
  • Modality: Using smartphone palm prints with visible light.
  • Issuance: HP Core is the only issuer of “unique human” Boolean credentials.
  • Data: There's a centralized VC database along with encrypted VC metadata stored on IPFS; basic sharing is available. (docs.humanity.org)

Phase 2 (Mainnet Identity Layer)

• Goal: We’re aiming to become the go-to identity layer for Web3, where we’ll be issuing comprehensive verifiable credentials (VCs) covering aspects like identity, age, employment, and geography.
• Modality: We’re using a combo of palm print and palm vein recognition (with infrared) through our “Humanity Scanners.” This approach helps us ensure users are real (liveness detection) and makes it tougher to spoof. Plus, we’re keeping app-based enrollment for everyone’s convenience and inclusivity. Check out more here.
• Issuance: The process will be decentralized, involving accredited Identity Validators using zkKYC, and we’ll handle revocation directly on-chain. Want to know more? Head over to this link.
• Data: We're implementing sharded storage for personally identifiable information (PII) along with zero-knowledge verifiable presentations. Our VC metadata will be securely encrypted on Walrus (Sui) and IPFS, and we’re adopting OAuth 2.0 scopes for web developers. Dive deeper into this info.
• Interop: We’re fully supporting dApps outside of Humanity’s chain through APIs and bridges, adhering to DID/VC standards. Check out our detailed plans here.

The identity stack: what’s under the hood

• Standards: HP is all about that W3C vibe with DIDs and Verifiable Credentials. So, here’s the deal: VCs are these cryptographically signed claims that only give verifiers the info they really need through zero-knowledge verifiable presentations (VPs). If you’re working on standardizing your internal schemas, make sure to sync up with VC Data Model 2.0 (W3C Recommendation, May 2025). Check it out here: docs.humanity.org.
• Crypto & storage:
  • An identity wallet uses a Baby Jubjub keypair - it’s different from a transactional wallet to keep things from being linked together or analyzed by timing. The VC data is locked down with AES-256 encryption, and the keys are protected through a hardware-backed KMS. More info here: docs.humanity.org.
  • In Phase 1, encrypted VC metadata hangs out on IPFS, and in Phase 2, we roll out Walrus on Sui + IPFS for some serious programmable, verifiable storage. The Walrus mainnet is set to launch on March 27, 2025. You can find more details at: docs.humanity.org.
• Network roles:
  • Identity Validators: These folks stake at least 100,000 H to hand out credentials, and any revocation events? Yeah, those get recorded on-chain. Learn more here: docs.humanity.org.
  • zkProofer Nodes: They’re all about verifying VCs/VPs without peeking at plaintext PII. The design is focused on horizontal decentralization with node licensing tiers (Basic/OG/Founder), capped at a total of 100,000 licenses. You can dive deeper here: docs.humanity.org.
• Fees and incentives:
  • When it comes to verification fees, they’re shared out among Identity Validators and delegators (25%), a general staking pool (25%), zkProofers (25%), and the Foundation Treasury (25%). This setup helps keep everyone motivated to onboard real users and get those credentials out in the wild. Want to know more? Check it out at: docs.humanity.org.

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

• Privacy and data management:
  • Phase 1: HP Core takes care of PII while verifiers get ZK-backed attestations whenever they need them. Check out the details on docs.humanity.org.
  • Phase 2: PII gets sharded with validators, making non-PII VC metadata decentralized and verifiable across different chains. Plus, verifiers can ask for ZK VPs for those “need-to-know” scenarios (like confirming if someone is an adult AND an EU resident) without diving into the actual documents. More info can be found at docs.humanity.org.
• Governance and decentralization:
  • In Phase 2, we’ll see the introduction of DAO participation and validator elections, moving beyond HP Core being the only issuer. This is super important for businesses that need multi-party trust and clear audit trails for revocation. Read more about it at docs.humanity.org.
• Device coverage and inclusivity:
  • Phase 2 will also bring in IR-based palm vein scanning for liveness checks, keeping enrollment contactless and mobile-friendly. The liveness feature of palm vein scanning serves as a solid defense against high-quality fakes. Want to know more? Head over to docs.humanity.org.

Developer experience: API-first, SDK-backed

HP's developer platform offers “verification primitives” that make it easy to integrate checks without needing to be a ZK whiz. The main goal here is to get you to the “Time to First Verify” in roughly 15 minutes. Check it out here: (docs.humanity.org).

• What’s new: We’ve got a straightforward REST endpoint that checks if a wallet is truly owned by a unique, palm-verified human.
  • Endpoint: GET /v1/human/verify
  • Headers: X-HP-API-Key
  • Query Parameter: 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 set up gates for mints, votes, or signups as needed--plus, you won’t have to worry about storing any sensitive info yourself. Check it out here: (docs.humanity.org).

Architecture deep-dive: the PoT verification flow

• Enrollment:
  • Phase 1: The user starts off by scanning their palm print. If they’re not already a member, HP Core will provide a “unique human” verifiable credential (VC) as proof. (Check out the details here)
  • Phase 2: Now the user has two options: they can either (a) sign up through the mobile app or (b) go for a full enrollment using Humanity Scanners, which require a palm print plus vein scan. Accredited validators will then issue domain-specific VCs like age, KYC tier, or employment info. (More info here)
• Presentation:
  • A decentralized app (dApp) will ask for “proof of eligibility.” At this point, the user can either share a non-personally identifiable information (non-PII) VC or request a Zero-Knowledge Verifiable Presentation (ZK VP) from HP Core. As decentralization ramps up, this will shift to a validator-backed generation process. (Learn more here)
• Verification:
  • The zkProofer Nodes step in to verify the proof and log the outcome on-chain. Then, the dApp can either grant or deny access--all without ever looking at the raw biometrics or personal info. (Discover the process here)

Standards alignment and why it matters for enterprises

• Verifiable Credentials (VC) and Decentralized Identifiers (DIDs) are W3C standards that are really coming into their own, especially with a test suite that’s maturing and a 2.0 Recommendation on the horizon for 2025. What does this mean for you? Well, you'll get interoperable semantics, various proof formats (like JWT/Data Integrity), and easier audits. It’s a good idea to adopt VC 2.0 vocabularies when you can; it helps keep your integrations future-proof. Check out more details on this at w3.org.
• HP’s Phase 2 is all about targeting OAuth 2.0-style scopes specifically for web developers, plus making sure that DID/VC portability works seamlessly across L2/L3 and even into the physical world. This is super important if you want your credentials to move smoothly between Web2 and Web3 systems. For more insights, head over to docs.humanity.org.

Practical integration patterns (with concrete details)

1) Sybil-Resistant Loyalty and Airdrops (No KYC Friction)

• Problem: Bots are taking advantage of loyalty programs, which messes with our Customer Acquisition Cost (CAC) to Lifetime Value (LTV) ratios.
• Solution: Let’s add an is_human check when users connect their wallets and hold off on any KYC requirements until they want to redeem something. We can cache those positive checks with short time-to-live (TTL) settings to keep repeated calls to a minimum.
• Implementation Tip: For wallet gating, you can use GET /v1/human/verify. Make sure to store just the boolean result and timestamp--not the user ID unless it’s absolutely necessary for managing rate limits. Check out the details in the docs.humanity.org.

2) Age and Region Gating for Compliant Content or RWA Access

• Problem: We need to verify that users are “≥18” and “EU residents” without asking for any personal identifiable information (PII).
• Solution: The best approach is to ask for a zero-knowledge Verifiable Presentation (VP) that captures both attributes. With HP Phase 2, we can use these composite VPs, and if the original Verifiable Credential (VC) expires, revocation is tracked on-chain.
• Operational Tip: To keep things smooth, make your VP requests idempotent by using a nonce, and remember to log verifier consent receipts for auditing purposes. Check out more details here.

3) KYC-light DeFi Whitelisting

• Problem: There are certain pools or token offerings that ask for proof of eligibility, but they don’t want to keep full KYC data on file.
• Solution: You can lean on Identity Validators’ zkKYC credentials. Your smart contract or backend can accept a Verifiable Presentation (VP) that shows “KYC tier ≥ X” without revealing any Personally Identifiable Information (PII). Just make sure to keep an eye on revocation registries so you can invalidate access if someone’s status changes. (docs.humanity.org)

4) Workforce & Supplier Credentials

• The Problem: We need to restrict internal DAO voting or procurement to verified employees or approved vendors without exposing our entire org chart.
• The Solution: You can use your HRIS or vendor portal as an Issuer (or hand it off to a trusted Identity Validator) to create employment or supplier-status Verifiable Credentials (VCs). When it's time to vote on a proposal, smart contracts will check if "isActiveEmployee=true." If someone leaves the company, the issuer can revoke their VC right on the blockchain. Check out more details here: docs.humanity.org.

5) DePIN and “palm-to-enter” experiences

• Problem: We often struggle with secure physical access or event check-ins that align nicely with our digital entitlements.
• Solution: Humanity Scanners come to the rescue by verifying attendees right on-site using palm vein patterns and fingerprints. The access system simply takes a VP (verification proof) that says, “You’re good to go for Zone A, today only.” Plus, no personally identifiable information (PII) sticks around in the verifier system. Check it out here: (docs.humanity.org)

Best emerging practices for Phase 2 deployments

• Go for minimal disclosure: Stick with Verifiable Presentations (VPs) instead of raw Verifiable Credentials (VCs) whenever possible. If you have to store something, keep it to a minimum--just proof receipts and timestamps, not personally identifiable information (PII). Make sure your schemas are in line with VC 2.0 and keep those JSON-LD contexts intact. (w3.org)
• Keep identifiers separate: Don't mix the HP identity wallet with your transactional wallets. The Baby Jubjub identity wallet is built for unlinkability--so it's crucial you respect that separation in your logging and analytics. (docs.humanity.org)
• Handle the API key like it's precious: Rotate your keys regularly, set up allowlists, and impose rate limits. To cut down on latency and costs during high-traffic times, cache “is_human” for a short time frame (say, 5-15 minutes). (docs.humanity.org)
• Be ready for revocation: Create a revocation listener or a polling mechanism. It's super important that block lists update within minutes to help reduce risks from compromised accounts or if someone’s employment gets rescinded. (docs.humanity.org)
• Embrace validator diversity: Go with several accredited Identity Validators. Keep an eye on their staking and slashing behavior, and only accept credentials from validators that fit your risk criteria (like stake amounts and slashing history). (docs.humanity.org)
• Figure out your hardware stance:
  • Mobile-only enrollment can reach more people but doesn’t offer the best liveness compared to IR palm vein.
  • If you’re dealing with high-stakes situations (think real-world asset custody or facility access), make sure you require a “full enrollment” VC (that’s palm vein plus fingerprint) issued at an in-person event or scanner hub. (docs.humanity.org)
• Choose your storage wisely: Use Walrus for encrypted VC metadata when you need programmable storage and verifiability. IPFS is still good for non-PII stuff. Remember to keep track of Walrus epochs and storage commitments just like you do for certificate expirations. (walrus.xyz)

What it takes to get started this quarter

• If you're just diving into this whole thing, make sure to reserve or import some Human IDs! With Phase 2 onboarding, new users get to snag a Human ID before they enroll their palms. And hey, if you're working with allowlists or pilot programs, definitely focus on those high-referral users! You can find more info here.
• Let's set up a light “humanity middleware”:
  • When you connect, hit up /v1/human/verify; keep that result cached for a bit, and use it to gate actions.
  • For attributes like age, region, and KYC tier, ask users to show a VP. And how about building a nifty verifier microservice that chats with zkProofer Nodes and your policy engine? Check out the details here.
• When it comes to picking validator partners, start with at least two accredited Identity Validators. It’s a good idea to set some SLA targets for how quickly you expect VP responses and revocation times. More guidance can be found here.
• Don’t forget to track those KPIs:
  • You’ll want to see a drop in bot signups and transactions, a boost in approval rates for legitimate users, how long it takes to verify, false negative appeals, and the costs per verification event (that includes fees and infrastructure).
  • Keep an eye on fee splits since they can add up, and think about staking H to help cover those verification fees with rewards. Get more insights here.

Why palm, why now

Palm-based verification offers a more convenient and culturally considerate alternative to face or iris recognition systems, which can sometimes be clunky. With Phase 2’s IR palm vein technology, you get hardware-enforced liveness--meaning the unique patterns are located beneath the skin and can only be seen in a living person. This significantly ups the challenge for anyone trying to spoof the system, all without requiring pricey or invasive hardware for every user. Check out more details here: (docs.humanity.org)

The network and ecosystem trajectory

• Economy and token: H has a fixed supply of 10 billion tokens, which help fund identity attestations, node rewards, and governance. The verification fees create rewards for zkProofers, validators, and stakers, connecting the token’s value to actual demand for verification. (docs.humanity.org)
• Node scale: We're aiming for up to 100,000 zkProofer Node licenses to ensure wide distribution. Our attack modeling includes measures like stake caps, slashing, and anti-collusion strategies to keep everything secure. (docs.humanity.org)
• Chain connectivity: By building on the Polygon CDK, we're keeping EVM tooling familiar and making cross-chain interoperability a breeze. Builders will really benefit from the evolving zkEVM infrastructure and bridges out there. (coindesk.com)

Putting it all together: a phased enterprise rollout

• Phase A (4-6 weeks): We'll kick things off by implementing is_human gating on surfaces where bots usually hang out, like airdrops and waitlists. Our goal here is to see some nice upticks in conversion rates while cutting down on fraud.
• Phase B (6-10 weeks): Next up, we'll introduce an additional attribute for verification purposes (like making sure users are 18 or older) to keep everything compliant. We'll also get into revocation handling and start logging that VP action.
• Phase C (10-16 weeks): During this phase, we’ll test out a domain credential, such as employment or vendor verification, using one Identity Validator. This will be enforced in a DAO or a procurement workflow to see how it holds up.
• Phase D (quarterly): For those sensitive spots, we'll transition eligible users to full enrollment using palm vein and fingerprint scanning at events or at our partner’s scanning hubs. You can check out more about that here.

Final take

Humanity Protocol’s Phase 2 takes “proof of personhood” to the next level, transforming it from a simple one-bit signal into a flexible, standards-based identity framework. It keeps user privacy intact while providing your app with clear, auditable guarantees--like humanity, age, residency, KYC tier, and employment--without storing any personally identifiable information (PII). For decision-makers, this translates to less fraud, a more straightforward compliance process, and a quicker journey from concept to integration, thanks to an easy-to-use API and SDKs.

When you're trying to figure out where to kick things off, start by putting is_human on your most botted surfaces. Next, add those attribute VPs where they can actually help reduce risk or provide some regulatory clarity. As validators, zkProofer Nodes, and storage get more robust, the identity layer transforms from just a safety net into a real engine for growth. (docs.humanity.org)

---

References and Further Reading:

• Check out the Humanity Protocol Whitepaper and Docs for insights on architecture, roles, privacy tables, and tokenomics. (docs.humanity.org)
• Want to know about the Testnet Roadmap and how it differs from the mainnet? Dive into the details here. (docs.humanity.org)
• If you’re looking to get into the nitty-gritty of the API Reference, take a peek at the /v1/human/verify endpoint. (docs.humanity.org)
• Curious about the Palm Scanner and how it ensures liveness via IR vein detection? Find out all the details here. (docs.humanity.org)
• Check out the scoop on Funding Coverage for 2024-2025. (theblock.co)
• Get the background on Polygon CDK and its plans for L2 chains. (coindesk.com)
• Learn about the W3C VC Data Model 2.0 and DIDs if you're into digital identity. (w3.org)
• For info on Walrus mainnet storage for encrypted VC metadata, check this out. (walrus.xyz)

7Block Labs is here to help you create your VC schemas, connect HP’s verification flows, and deliver a privacy-first identity experience that your legal and security teams will approve--all while keeping your roadmap on track.