A bank needs to verify that counterparties and end users meet KYC, sanctions, and jurisdictional eligibility requirements without exposing personal data on chain or building cross-institutional dossiers. The same architecture must serve government registries, DAOs, and humanitarian programs whose users may be in jurisdictions where the issuer becomes unavailable, hostile, or destroyed.
For institutional KYC, sanctions compliance, and ERC-3643 permissioned token transfers, On-Chain Attestation with EAS and ONCHAINID is the production-default; pair with OpenAC for cross-verifier unlinkability where the issuer-linkage signal is competitively sensitive. Registry Membership suits well-defined institutional whitelists where the operator is administratively tractable. Document ZK is suited for sanctions and age verification where attribute-only proofs are sufficient and full KYC is overhead. Issuer-Independent OPRF is the suitable choice when issuer continuity is a documented risk: institutions in sanctioned jurisdictions, humanitarian programs, or governance contexts where the issuer cannot remain available indefinitely.
Engineering effort scales by approach. Registry Membership reuses Semaphore-class infrastructure with the lowest proof cost. Document ZK requires mobile NFC integration plus Noir or Circom circuits per document type. TLS Transcript Proofs add the Notary infrastructure and TLS-record introspection. On-Chain Attestation is the simplest verification surface (signature check) but requires registry hygiene at the issuer. POD2 is composable across heterogeneous attestations but the tooling is community-driven. Issuer-Independent OPRF is the heaviest engineering surface (threshold network, on-chain LeanIMT, recovery infrastructure) but is the only category designed to survive single-issuer failure.
This is a perspective for legal review by the deploying institution, not legal advice. Each approach exposes a distinct disclosure interface. Registry Membership pairs scoped view keys with EAS-logged audit trails; the registry operator would typically be the named regulated party. Document zero-knowledge proofs disclose only the attribute predicate's public output; jurisdictional acceptance varies (ZKPassport was used at the Aztec sale to attest non-sanctioned status across OFAC / Swiss / EU / UK lists, which is a deployment data point, not a regulatory endorsement). TLS Transcript Proofs raise classification questions about the Notary's role. On-Chain Attestation aligns with existing identity-issuer registry conventions; whether a given regulator accepts EAS or ONCHAINID-style attestations as compliance evidence is a per-jurisdiction question, and OpenAC layers unlinkability without breaking the audit trail at the issuer. POD2 is community-grade and may not match institutional-grade evidence requirements. Issuer-Independent OPRF would require legal sign-off on the threshold-network composition, the recovery model, and the coercion-resistance posture; the document does not claim sufficiency for any specific regime.
Requirements
Verify eligibility claims without revealing the underlying identity
Composable across credential sources (passport, national ID, email, web2 data, community attestation)
Sybil resistance with per-identity cost curve (legitimate pseudonyms cheap, mass sybils expensive)
Selective disclosure for regulators with scoped, time-bound access
Issuer-independent verification path: on-chain trust anchor only, no issuer contact during verification
Constraints
Open-source verification logic; no canonical identity provider
Proof generation practical on consumer hardware (mobile + browser)
Revocation without re-identification
Recovery from device loss or guardian compromise
Coercion resistance for governance and humanitarian contexts
Architectural options
Recommended
For institutional permissioned-asset access today, default to On-Chain Attestation with EAS and ONCHAINID; add OpenAC when cross-verifier unlinkability matters. For institutional KYC whitelists with operator-controlled membership, default to Registry Membership Proofs (Semaphore-class). For sanctions and age verification on a global user base, default to Document ZK (ZKPassport) on supported documents.
Registry-Based Membership Proofs
prototyped
CRCensorship-resistancemedium
OSOpen sourceyes
PPrivacyfull
SSecurityhigh
A registry operator maintains a Merkle tree of approved members; provers generate ZK membership proofs without revealing which leaf they correspond to.
How it works
The operator publishes an on-chain Merkle root commitment with an incremental tree. Members generate zero-knowledge proofs of inclusion in the membership tree and exclusion from a revocation tree, with scope-bound nullifiers preventing replay across verifiers. Contract hooks verify proofs and integrate with ERC-3643 token transfers; attestation logs (EAS) provide audit trails.
Trust assumptions
Registry operator(s) honesty and availability
Merkle tree integrity and revocation correctness
ZK soundness
Threat model
Registry operator censorship by omission or selective revocation
Operator compromise reveals membership; mitigated by multi-operator registries
Registry update latency creates verification windows
Works best when
Membership set is well-defined (institutional KYC list, DAO whitelist)
Operator trust is administratively tractable (audited operations, multi-operator)
Revocation cadence is bounded by governance, not adversarial pace
Avoid when
Registry operator failure must not break verification (use Issuer-Independent OPRF instead)
Membership churn is high enough that revocation lag becomes a security problem
Document ZK Proofs
prototyped
CRCensorship-resistancemedium
OSOpen sourceyes
PPrivacyfull
SSecurityhigh
zero-knowledge proofs over cryptographic data from government-issued identity documents (passport NFC, national ID signatures); selectively disclose attributes without revealing the document.
How it works
ZKPassport reads passport NFC chips (120+ countries) and proves attributes (age, nationality, sanctions-list non-membership) under Noir / UltraHonk on mobile. Anon Aadhaar verifies UIDAI's RSA signature client-side and emits EVM-verifiable proofs over Indian national ID attributes. The verifier checks the SNARK; no identity data is collected.
Document issuer compromise propagates to all proofs
Cloned passports / NFC replay; mitigated by document-side anti-cloning
Mobile platform compromise reveals derivation material
Works best when
Attribute proofs are sufficient (sanctions, age, nationality) and full KYC is unnecessary
User base has NFC-capable devices or supported national IDs
Issuer cooperation persists for credential refresh
Avoid when
Issuer cooperation cannot be assumed long-term (use Issuer-Independent OPRF)
Document cryptography is too weak or restricted for the threat model
TLS Transcript Proofs
prototyped
CRCensorship-resistancemedium
OSOpen sourceyes
PPrivacypartial
SSecuritymedium
TLSNotary generates zero-knowledge proofs over TLS session transcripts from any web2 source (bank portals, government sites, social media); selectively discloses specific fields.
How it works
A Notary co-signs the TLS session; the prover holds the session transcript and generates a zero-knowledge proof attesting to specific fields (account balance, government registry record, social signal). The verifier checks the proof against the Notary's signature and the TLS session metadata.
Trust assumptions
Notary honesty and availability during the session
TLS server certificate validity
Web2 data source not adversarial during the session
Threat model
Notary compromise corrupts the witnessing function
TLS server-side data manipulation between sessions
Disclosure granularity limited by TLS record structure
Works best when
Web2 data source has no API for direct attestation
Notary trust is administratively manageable (audited, multi-notary, or threshold)
Freshness expectation is bounded by session timing
Avoid when
Trusted Notary is incompatible with the threat model
Required disclosure granularity is below TLS record boundaries
On-Chain Attestation
production
CRCensorship-resistancemedium
OSOpen sourceyes
PPrivacypartial
SSecuritymedium
Trusted issuers publish signed claims on chain (EAS, ONCHAINID via ERC-734/735, W3C VCs); ZK wrappers (OpenAC) add unlinkable presentation across verifiers.
How it works
Issuers sign attestations under known keys and publish them on chain. Verifiers reference the attestation and check the issuer signature. With ZK wrappers like OpenAC, the holder presents a proof of attestation possession with selective disclosure, unlinkable across verifiers; no trusted setup, EUDI ARF compatible.
Trust assumptions
Issuer signing key custody and lifecycle (rotation, revocation)
Attestation registry availability and correctness
ZK wrapper soundness (OpenAC) where unlinkability is required
Unlinkability across verifiers is a goal, pair with OpenAC
Avoid when
Issuer cooperation cannot be assumed long-term (use Issuer-Independent OPRF)
Verifiers must not be able to correlate via shared issuer references and OpenAC is unavailable
POD2
prototyped
CRCensorship-resistancehigh
OSOpen sourceyes
PPrivacyfull
SSecuritymedium
POD2 (Provable Object Data) bundles any data with a cryptographic proof of correctness; event tickets, community badges, poll responses, and access tokens share a composable format.
How it works
Each POD is a typed record signed by the issuer; verifiers check the signature and the typed schema. PODs compose: a holder can prove statements over multiple PODs in a single zero-knowledge proof (e.g., "I hold an event POD and a community POD without revealing which event or community").
Issuer key compromise corrupts all PODs from that issuer
Schema collision or malleability across communities
Tooling maturity affects audit confidence
Works best when
Event gating, community membership, anonymous polls, sybil-resistant access
Composable credential ecosystems where heterogeneous attestations interoperate
Community-driven adoption is acceptable
Avoid when
Institutional-grade audit and assurance is required (community tooling is less mature than EAS / ONCHAINID)
Issuer-Independent Enrollment via Distributed OPRF
prototyped
CRCensorship-resistancehigh
OSOpen sourceyes
PPrivacyfull
SSecurityhigh
Holders prove identity to a threshold vOPRF network, yielding a deterministic enrollment nullifier and a Poseidon leaf in an on-chain LeanIMT; post-enrollment, the on-chain root is the sole trust anchor, no issuer contact during verification.
How it works
Any A-E source can enroll (passport, national ID, email DKIM, TLS notary, biometric, community vouch). The holder runs RFC 9497 + Jarecki threshold OPRF against the network (TACEO operates a 13-node production network). Output: a deterministic enrollment nullifier and a leaf added to the on-chain LeanIMT. Verification at any verifier checks a zero-knowledge proof against the on-chain root with public inputs (root, scope-bound nullifier, predicate parameters). Sybil resistance is layered: cryptographic (one enrollment per source credential), economic (refundable stake, default 0.1 ETH), social (web-of-trust vouching, future). Recovery via Shamir threshold splitting and guardian-based social recovery.
If issuer continuity is a documented risk (sanctions, jurisdictional disruption, humanitarian context), choose Issuer-Independent OPRF and design the threshold network for jurisdictional diversity.
If web2 data sources without APIs must be brought on chain, choose TLS Transcript Proofs and validate the Notary governance.
If the ecosystem requires composable attestations across heterogeneous communities, choose POD2 and accept the community-tooling maturity trade-off.
Hybrid composition
Run On-Chain Attestation as the default for production permissioned flows; layer Document ZK for sanctions screening at the entry boundary; enroll high-risk users (institutions in jurisdictionally exposed locations, humanitarian recipients) into the Issuer-Independent OPRF as a continuity backup. Recovery uses Shamir + guardian quorum across the same enrollment. Coercion-resistance posture is documented per program; production-grade anti-coercion mechanism is an open research item.
Open questions
Multi-Address Efficiency. Proving ownership of multiple EOAs from the same seed without revealing derivation patterns.
Regulatory Recognition. Legal recognition of zero-knowledge proofs as sufficient compliance evidence per jurisdiction.
Notary Trust. Guaranteeing Notary trustworthiness in zk-TLS deployments; threshold or audited Notary networks.
Cross-Credential Composability. Combining proofs from heterogeneous sources (passport + KYC attestation + community POD) in a single verification.
Credential Revocation. Revocation across heterogeneous issuers without a central authority.
Guardian Recovery Design. Minimum guardian set for anti-coercion; acceptable coordination overhead for quorum recovery.
Attribute Freshness. Without an issuer to refresh, how stale attributes (expired passports, changed nationality) are handled in OPRF-anchored enrollment.
