Skip to main content

​
Use Case

Prove membership, eligibility, or attribute possession on-chain without revealing identity or creating linkable activity. Applies to financial compliance (KYC registry membership), governance (anonymous voting), national identity (selective disclosure from government documents), and community membership (sybil-resistant access).

​
Business Context

Actors: Credential Issuer (bank, government, DAO, university) · Prover / Subject (investor, citizen, voter, community member) · Verifier (smart contract, institution, election system) · Registry Operator (maintains on-chain commitment: Merkle root, attestation registry, membership set) · Auditor / Regulator (entity with scoped disclosure rights: financial regulator, election observer) · Wallet / Proof Agent (client-side proof generation: mobile wallet, browser extension, NFC reader)
Additional confidential business context is available in the private IPTF repository.

​
Validated Deployments

National Identity

ZKPassport - 120+ country passports via NFC + Noir circuits (used in Aztec token sale)Anon Aadhaar - India’s national ID system

Governance

NounsDAO Private Voting - Aztec + Noir storage proofsMACI - Anti-collusion voting (deployed at ETHDam, ETHMexico, ETH Tegucigalpa)

Community / Sybil Resistance

POD2 - 0xPARC credential systemWorld ID - 25M+ registrations via biometric enrollment

Email Identity

zkEmail - DKIM proofs for email wallets on Arbitrum

​
Problems

​
Problem 1: Authentication Without Identity Leakage

Current authentication methods (e.g., message signatures) prove key control but expose addresses and create linkability between provers and verifiers. Two distinct but related needs emerge:
  1. Authentication: prover demonstrates membership or attribute possession without revealing identity
  2. Interaction privacy: prevent on-chain linkability between prover addresses and verifier contracts
  • Must hide: prover identities, links between verifiers and provers, links between prover EOAs
  • Public OK: registry roots, verifier contract addresses, compliance attestations
  • Auditor access: scoped access to Merkle inclusion proofs, registry updates, or decryption keys where required
  • Settlement: proof verification + transaction execution
  • Ops: resilience against replay attacks; low-cost proof generation; interop across rollups; proof generation on consumer hardware

​
Problem 2: Credential Source Diversity

Different domains require different credential sources: government-issued IDs (passports, national IDs), institutional attestations (KYC providers), biometric enrollment, email ownership (DKIM), event attendance, and on-chain history. No single canonical identity system covers all use cases.
Must support:
  • Document-based (passport NFC)
  • Attestation-based (EAS/VC)
  • Biometric-enrollment-based
  • Email-based (DKIM)
  • Membership-based (Merkle tree)
  • TLS-based (web2 data export)
Must not require:
  • A single canonical identity system
  • Global registry
Interoperability: Credentials from different sources should be composable (e.g., prove KYC + jurisdiction + accreditation from different issuers in one proof)

​
Problem 3: Sybil Resistance Without Surveillance

Systems that distribute value (governance votes, token distributions) must prevent double-claiming without building a surveillance database. This requires deterministic, scope-bound nullifiers that prevent repeat actions without linking to the underlying identity.
Must prevent:
  • Double-claiming
  • Double-voting
  • Distribution farming
Must preserve:
  • Unlinkability across different scopes/services
Must handle:
  • Revocation of compromised credentials without re-identifying holders
Reference: See vOPRF Nullifiers pattern for nullifier generation primitives

​
Recommended Approaches

Credential SourcePrimary ApproachExample Deployments
Institutional KYC registryMerkle tree membership proofsERC-3643 issuances, Semaphore
Government ID (passport)Document ZK proofs (NFC + Noir)ZKPassport / Aztec token sale
Government ID (national)Document DKIM/signature + ZKAnon Aadhaar / ETHIndia
EmailDKIM signature proofszkEmail / Arbitrum wallets
Web2 data sourceTLS transcript proofsTLSNotary
Biometric enrollmentIris/face hash + membership proofWorld ID
Event/communityPOD20xPARC
Multi-party private inputsCollaborative proving (co-SNARK)TACEO
On-chain attestationEAS / ONCHAINID / W3C VCTokeny, EAS
See detailed architecture and trade-offs in Approach: Private Authentication.

​
Open Questions

How practical is it to prove ownership of multiple EOAs derived from the same seed without revealing derivation patterns?Should this be handled at the wallet layer (BIP-32 style derivations) or at the protocol layer (aggregated ZK proofs)?
How to establish cross-credential interoperability? For example, combine a ZKPassport proof with an institutional attestation in a single transaction.
What trust models are acceptable for biometric enrollment systems in different regulatory contexts?
How to handle credential revocation across heterogeneous issuers without a central revocation authority?
How do these building blocks map onto existing and emerging compliance frameworks (EUDI ARF, eIDAS 2.0, MiCA) across jurisdictions?

​
Standards & Frameworks

​
Core Standards

​
ZK Frameworks

​
Credential Systems

​
Validated Deployments

​
Related Patterns

​
Related Use Cases

Build docs developers (and LLMs) love

Get started for freeTalk to us