The Validity Ladder: How Trust Grows

Most identity systems are binary: verified or not. You either jump through all the hoops upfront, or you're locked out.

HUMΛN takes a different approach: progressive verification. Trust builds over time, through layers. You start with what you need, and upgrade when you need more.

This is the Validity Ladder—four layers of verification that protect both you and the ecosystem, without demanding everything upfront.

Why Progressive Verification?

Imagine if you had to provide your passport, driver's license, birth certificate, and biometric scan just to create an email account. Most people would walk away.

But if you only need an email account, why should you have to prove your entire identity? And if you're doing high-value work later, why shouldn't you be able to upgrade your verification?

Progressive verification matches trust to risk. Low-risk activities get low-barrier access. High-risk activities require stronger verification. You climb the ladder as you need to, not all at once.

This protects both sides:

• Users: Start using the system immediately, upgrade when needed
• Ecosystem: Higher-risk activities require stronger verification, reducing fraud

The Four Layers

The Validity Ladder has four layers, each building on the previous:

Let's walk through each layer.

Layer 0: No Verification (Development/Testing)

What it is: Free tier for development, testing, and experimentation.

What it proves: Nothing. This is intentionally low-barrier.

Use cases:

• Developers building integrations
• Testing workflows
• Prototyping
• Learning the system

Limitations:

• Can't access paid features
• Can't receive high-value work assignments
• Can't participate in governance
• Can't publish agents to the marketplace

Why it exists: Lower the barrier to entry. Let developers experiment without friction. Let people try the system before committing.

Real scenario: A developer wants to build a HUMΛN integration. They create a Passport in seconds, start coding, test their integration. No credit card, no verification, no friction. When they're ready to publish, they upgrade.

Layer 1: Device Attestation (Soft Barrier)

What it is: Platform-level verification that you're using a real device, not a bot or emulator.

How it works:

// iOS App Attest
const deviceAttestation = await DCAppAttestService.attestKey(keyId);

// Proves:
// ✅ Real Apple device (not emulator, not jailbroken)
// ✅ Genuine app (Apple-signed)
// ✅ Key generated in Secure Enclave
// ✅ Device hasn't minted a Passport before

// Android Play Integrity API
const integrityToken = await googlePlayIntegrity.requestIntegrityToken();

// Proves:
// ✅ Real Android device (Google-verified)
// ✅ App is genuine (not tampered)
// ✅ Device passes integrity checks

What it prevents:

• Bots and scripts (no real device)
• Emulators (detected by attestation)
• Jailbroken/rooted devices (attestation fails)
• Casual duplication (one Passport per device)

What it doesn't prevent:

• Determined attacker with multiple real devices
• Device farm attacks (expensive but possible)

Tradeoff:

• Pro: No PII required, works offline, privacy-preserving
• Con: Weak barrier (attacker can buy multiple devices)

Use cases:

• Free tier Companion access
• Basic Workforce Cloud tasks
• Academy free courses
• Development and testing

Real scenario: Alice wants to use HUMΛN Companion. She creates a Passport on her iPhone. The device attestation proves it's a real iPhone with a genuine app. She can start using Companion immediately. If she wants paid features later, she upgrades to Layer 2.

Layer 2: Biometric Binding (Strong Barrier)

What it is: Cryptographically bind your Passport to your biological identity via device biometrics.

How it works:

// Passport creation requires biometric enrollment
const passport = await createPassport({
  displayName: "Alice Chen",  // Display only; in production, display name comes from profile (Resource Graph)
  biometricEnrollment: {
    type: 'faceID',  // or touchID, fingerprint
    challenge: 'passport-creation',
    requireLiveness: true  // Anti-spoofing
  }
});

// What happens:
// 1. Device captures biometric (Face ID, Touch ID)
// 2. Biometric template stored ONLY in Secure Enclave
// 3. Passport keypair bound to biometric
// 4. All signing operations require biometric re-auth
// 5. Hash of biometric template included in attestation

// If Alice tries to create second Passport:
const secondAttempt = await createPassport({
  displayName: "Alice Chen 2",
  biometricEnrollment: { type: 'faceID', ... }
});

// System detects biometric collision
const existingPassport = await db.passports.findByBiometricHash(
  hash(secondAttempt.biometricTemplate)
);

if (existingPassport) {
  throw new Error('Passport already exists for this biometric.');
}

What it prevents:

• Same person creating multiple Passports (biometric collision)
• Device theft → new Passport (biometric mismatch)
• Device farm attacks (each device needs different biometric)

What it doesn't prevent:

• Identical twins (rare collision, acceptable)
• Sophisticated spoofing (3D face models, fingerprint replicas)

Privacy preservation:

• ✅ Biometric template NEVER leaves device (stored in Secure Enclave)
• ✅ Only cryptographic hash sent to HUMΛN (irreversible)
• ✅ Hash cannot reconstruct biometric
• ✅ HUMΛN cannot identify person from hash (unlinkable)

Tradeoff:

• Pro: Strong barrier, privacy-preserving (hash only), no PII
• Con: Requires device with biometric sensor, accessibility concerns

Use cases:

• Paid tier Companion
• Workforce Cloud general tasks
• Academy paid courses
• Enterprise employee onboarding

Real scenario: Alice wants to access paid Companion features. She upgrades to Layer 2. Her iPhone's Face ID captures her biometric, stores it in the Secure Enclave, and creates a hash. That hash is sent to HUMΛN (not the biometric itself). Now she can access paid features. If she tries to create a second Passport on another device, the system detects the biometric collision and prevents it.

Layer 3: Social Attestation (Web of Trust)

What it is: Humans vouch for each other's uniqueness and trustworthiness.

How it works:

// Alice requests vouches from trusted contacts
const socialAttestation = await alicePassport.requestVouches({
  vouchers: [
    'did:human:bob',    // Bob knows Alice IRL
    'did:human:carol',  // Carol works with Alice
    'did:human:dave'    // Dave is Alice's friend
  ],
  statement: 'I know this person is unique and not a duplicate account'
});

// Each voucher signs attestation
const bobVouch = await bobPassport.sign({
  action: 'vouch_for_uniqueness',
  subject: 'did:human:alice',
  statement: 'I personally know Alice Chen and confirm this is her only Passport',
  confidence: 'high',
  relationship: 'colleague',
  metSince: new Date('2023-01-15')
});

// Reputation-weighted vouching
// - Vouchers with higher reputation count more
// - Vouchers who've never given bad vouches count more
// - Diverse vouch network (different social circles) counts more

What it prevents:

• Anonymous Sybil attacks (need real social connections)
• Bot networks (can't get human vouches)
• Biometric spoofing (vouchers confirm real person)

What it doesn't prevent:

• Collusion (group of attackers vouch for each other)
• Paid vouches (black market for vouches)

Tradeoff:

• Pro: Decentralized, no central authority, resistant to single point of failure
• Con: Requires social connections, can exclude isolated individuals, vulnerable to collusion

Use cases:

• High-trust tier Companion
• Workforce Cloud premium tasks
• Enterprise employee verification
• Governance participation
• Marketplace agent publishing

Real scenario: Alice wants to publish an agent to the marketplace. This requires Layer 3 verification. She asks three colleagues—Bob, Carol, and Dave—to vouch for her. Each signs a cryptographic attestation confirming they know Alice and this is her only Passport. The system weights these vouches based on Bob, Carol, and Dave's own reputation. Alice now has Layer 3 verification and can publish her agent.

Layer 4: Proof of Personhood (Cryptographic Uniqueness)

What it is: Zero-knowledge proof that you're a unique person without revealing your identity.

How it works (conceptual):

// Privacy-preserving biometric zero-knowledge proof
const uniquenessProof = await generateZKProofOfPersonhood({
  biometricCommitment: hash(biometricTemplate),  // Commitment, not template
  nullifier: deriveNullifier(biometricTemplate),  // Prevents double-registration
  publicKey: alicePassport.publicKey
});

// Nullifier prevents double-registration:
// - Same biometric → Same nullifier
// - Already seen this nullifier → Reject
// - Different biometric → Different nullifier → Allow

// Verification:
const isValid = await verifyZKProof(uniquenessProof);
// Returns: true (unique person) or false (duplicate/invalid)
// BUT: Verifier learns NOTHING about who the person is

What it prevents:

• All forms of Sybil attack (cryptographically enforced uniqueness)
• Biometric spoofing (liveness checks)
• Bot networks (human verification required)
• Device farms (person must appear)

What it doesn't prevent:

• Identical twins (acceptable collision rate < 0.1%)
• Validator collusion (mitigated by random selection + quorum)

Tradeoff:

• Pro: Strongest guarantee of uniqueness, privacy-preserving (ZK), decentralized
• Con: Complex cryptography, requires research, UX friction, accessibility challenges

Use cases:

• Critical infrastructure (government services, financial systems)
• High-value Workforce Cloud tasks
• Governance (voting, policy decisions)
• Regulatory compliance

Real scenario: Alice wants to participate in HUMΛN governance voting. This requires Layer 4 verification. She generates a zero-knowledge proof of personhood using her biometric. The proof demonstrates she's a unique person without revealing who she is. The system verifies the proof and grants her Layer 4 status. She can now vote in governance decisions.

Identity Tiers: A Parallel Track

While the Validity Ladder focuses on uniqueness verification, there's a parallel track: Identity Tiers. These represent how much you've revealed about yourself, not how verified you are.

Tier 0: Anonymous

• No real-world identity revealed
• Can use DID without revealing name
• Good for privacy-sensitive use cases

Tier 1: Verified Name

• Real name attached to Passport
• Verified through social attestation or KYC
• Good for professional use cases

Tier 2: Verified Credentials

• Educational credentials verified
• Professional licenses verified
• Employment history verified
• Good for workforce matching

Tier 3: Full Profile

• Complete capability graph
• Full work history
• All credentials attested
• Good for high-trust scenarios

Identity Tiers and Validity Layers are independent. You can have Layer 4 verification (strongest uniqueness) with Tier 0 identity (anonymous). You can have Layer 1 verification (weak uniqueness) with Tier 3 identity (full profile).

Natural Gates: When Upgrades Are Needed

The system doesn't force you to upgrade. Instead, natural gates require higher verification when you need it:

Gate 1: Paid Features

• Layer 1 → Layer 2 required
• Prevents payment fraud
• Example: Upgrading to paid Companion

Gate 2: High-Value Work

• Layer 2 → Layer 3 required
• Prevents task fraud
• Example: Workforce Cloud premium tasks

Gate 3: Publishing

• Layer 2 → Layer 3 required
• Prevents spam/malicious agents
• Example: Publishing agent to marketplace

Gate 4: Governance

• Layer 3 → Layer 4 required
• Prevents vote manipulation
• Example: Participating in protocol governance

Gate 5: Critical Infrastructure

• Layer 4 required
• Maximum trust requirement
• Example: Government services, financial systems

These gates protect the ecosystem while allowing users to start with minimal verification.

Privacy Implications

Progressive verification is designed to be privacy-preserving:

Layer 1 (Device Attestation):

• No PII collected
• Only device attestation token
• Can't identify person from token

Layer 2 (Biometric):

• Biometric template never leaves device
• Only hash sent to HUMΛN
• Hash is irreversible, unlinkable

Layer 3 (Social):

• Vouches are public attestations
• But don't reveal private data
• Relationship types are optional

Layer 4 (Personhood):

• Zero-knowledge proofs
• Verifier learns nothing about identity
• Maximum privacy with maximum verification

Each layer adds verification without sacrificing privacy.

Why Progressive Is Better Than All-or-Nothing

Traditional approach (all-or-nothing):

• High barrier to entry
• Excludes legitimate users
• Forces over-verification for low-risk activities
• Creates friction that reduces adoption

Progressive approach:

• Low barrier to entry
• Includes everyone who wants to participate
• Matches verification to risk
• Allows natural upgrade path

Real impact:

A developer can start building in 10 seconds (Layer 0). They can test their integration immediately. When they're ready to publish, they upgrade to Layer 3. The system doesn't block them upfront, but protects the ecosystem when it matters.

A user can start using Companion immediately (Layer 1). They can explore, learn, build trust. When they want paid features, they upgrade to Layer 2. The system doesn't demand everything upfront, but ensures payment security when needed.

Progressive verification respects users while protecting the ecosystem.

The Compound Interest Metaphor

Just like identity gets stronger over time (the compound interest of identity), verification gets stronger as you climb the ladder.

Each layer builds on the previous. Each attestation strengthens your Passport. Each verification adds to your reputation.

You're not just proving who you are—you're building trust that compounds over time.

Conclusion

The Validity Ladder isn't about gatekeeping. It's about matching trust to risk, protecting both users and the ecosystem, and allowing natural progression.

Start where you need to start. Climb when you need to climb. The ladder is there when you need it, not blocking you when you don't.

Trust grows. Verification scales. Identity compounds.

That's the Validity Ladder.