Zero-knowledge proofs: the new standard for DeFi compliance

Zero-knowledge proofs address this conflict at the protocol layer. A user can prove that they are over 18, located in an eligible jurisdiction, or not associated with a sanctioned entity without sending the underlying personal data to the DeFi application or writing it to a public ledger. That is the core value of zk proofs for DeFi compliance and privacy.

The mechanism is not a regulatory exemption. It is a data-minimization system. It changes what the protocol receives from raw identity data to a cryptographic attestation.

That distinction matters. ZK-KYC does not eliminate identity issuers, compliance operators, legal obligations, or the possibility that a regulator may demand access to source records. It narrows the data surface exposed during routine protocol interaction.

The technical architecture of ZK-KYC: beyond public ledgers

The basic ZK-KYC flow has several independent components. Treating it as a single privacy feature is technically inaccurate.

A user first obtains an identity credential from an issuer. The credential may contain attributes such as date of birth, nationality, jurisdiction, accreditation status, or sanctions-screening results. The issuer remains an off-chain trust anchor. The blockchain does not independently determine whether the passport, corporate record, or screening process was valid.

The user then generates a proof against a predefined compliance circuit. The circuit encodes a statement that can be verified without exposing the underlying data.

For an age gate, the statement could be that the user’s date of birth implies an age of at least 18. The verifier receives the result, not the date of birth. For jurisdiction screening, the proof can establish that the user belongs to an eligible jurisdiction without publishing a full address or identity record.

The protocol verifies the proof on-chain. It does not need to store the personal document used to produce it. It also does not need to inspect the full identity credential during every transaction.

A production-grade system must solve more than proof generation. It needs a complete credential lifecycle:

• Issuance: an approved entity creates a credential and binds it to a user-controlled wallet or identity mechanism.
• Attribute selection: the user chooses which claim to prove. The protocol should request the minimum necessary attribute.
• Circuit execution: the claim is converted into a cryptographic proof using a framework such as Groth16, PLONK, zk-STARKs, or Bulletproofs.
• On-chain verification: a smart contract checks the proof against the relevant verification key and public inputs.
• Revocation: the system must account for expired, withdrawn, or invalid credentials.
• Replay resistance: a valid proof should not be reusable in an unintended context.
• Sybil resistance: one compliant credential should not automatically produce unlimited economically relevant identities where that creates abuse.
• Auditability: the issuer and protocol must retain enough off-chain evidence to support legitimate oversight without making routine on-chain activity fully transparent.

The last four elements are where many simplified descriptions fail. A proof can be mathematically valid while the surrounding compliance system is operationally weak.

ZK-KYC hides the credential data. It does not remove the credential issuer.

The strongest design separates three roles:

1. Issuer. Performs the identity or compliance assessment and signs the resulting credential.

2. Prover. Generates a proof from the credential and the requested policy.

3. Verifier. Checks the proof and enforces access rules in a smart contract or application layer.

This separation limits unnecessary data disclosure. It also creates dependencies. If the issuer can revoke credentials arbitrarily, users remain subject to a centralized control point. If the issuer’s screening process is poor, the proof only certifies that a weak process occurred.

The protocol therefore needs a clear answer to a simple question: what exactly is being proven? A proof of possession of an issuer signature is not the same as a proof that a user passed a current sanctions screen. The difference is temporal state.

A credential issued once may become stale. Sanctions lists change. Jurisdictional restrictions change. A user may move. An accredited-investor status may expire. A compliance circuit that ignores freshness is not privacy-preserving compliance. It is privacy-preserving historical evidence.

Selective disclosure changes the data model

Traditional KYC systems often move raw documents through multiple intermediaries. Each intermediary becomes a storage target, breach target, and access-control problem. A selective-disclosure system tries to keep the source data with the user or an authorized custodian and expose only the predicate required by the application.

The predicate is the condition being checked. Examples include:

• The user is at least 18.
• The user is not located in a restricted jurisdiction.
• The user has passed a specified AML screening process.
• The user holds a valid credential from an approved issuer.
• The user satisfies an accreditation requirement.
• The credential was issued before a defined expiry date and has not been revoked.

This is more precise than claiming that a user is anonymous. In most ZK-KYC systems, the user is pseudonymous to the public application. The identity is not necessarily unknown to the issuer, custodian, or authorized compliance function.

The distinction between anonymity and selective disclosure is central to privacy-preserving DeFi compliance. The protocol can reject an ineligible address without knowing the legal name attached to it. But an off-chain party may still be capable of linking the credential to a real person.

Linkability must be designed explicitly. If every proof contains a reusable identifier, privacy degrades. If every interaction creates a new unlinkable identity, compliance monitoring and abuse prevention become harder. Protocols commonly need scoped identifiers, nullifiers, or application-specific commitments to prevent replay while limiting cross-application correlation.

A nullifier can prove that a user has already used a credential for a particular action without revealing the user’s identity. But its privacy properties depend on scope. A global nullifier may make activity linkable across protocols. A narrowly scoped nullifier reduces that risk but can complicate enforcement.

The correct implementation depends on the compliance policy. A DeFi lending market may need to prevent repeated participation under multiple accounts. A one-time distribution may need to prevent duplicate claims. An institutional liquidity pool may require persistent authorization tied to a legal entity. These are different requirements. One generic ZK identity primitive will not satisfy all of them.

Raw KYC data versus selective disclosure

The table shows the trade. ZK systems reduce the amount of information exposed to the protocol. They do not reduce every form of trust. They move trust from data custody toward credential issuance, cryptographic assumptions, policy encoding, and system governance.

That is still a meaningful architectural improvement. It is not magic.

Institutional adoption is a privacy problem and a control problem

Institutional DeFi adoption is constrained by two separate requirements. Institutions need to demonstrate compliance, and they need to protect proprietary information.

A trading firm may not want to reveal its full transaction history, strategy, portfolio composition, or liquidity-routing behavior to a public protocol. A bank may need to show that activity passed AML and sanctions controls without publishing internal risk data. ZKPs can provide the attestation layer for these cases.

A 2025 report from Nethermind and Deutsche Bank identifies zero-knowledge proofs as essential infrastructure for institutions that need privacy around trading flows and proprietary strategies while still attesting to AML and sanctions compliance. The report is 43 pages. Its relevance is not the length. It is the identification of a direct conflict between public verifiability and institutional confidentiality.

Public verification is a core property of blockchains. Public exposure of strategy is not.

An institutional pool could require a proof that a participant has passed a defined compliance process, belongs to an approved category, and operates from an eligible jurisdiction. The pool would verify the proof through a smart contract. Other participants would not need access to the participant’s complete KYC file or corporate documentation.

The arrangement has limits.

First, the protocol must define the accepted issuer set. If any issuer can produce a valid credential, the cryptographic layer cannot distinguish a reliable screening process from a superficial one. If the issuer set is too narrow, the system becomes a permissioned access list with a cryptographic interface.

Second, institutional compliance is not just an entry condition. It includes transaction monitoring, reporting, record retention, suspicious-activity processes, and responses to legal requests. A proof that validates eligibility at entry does not automatically prove that every later transaction was appropriately monitored.

Third, privacy can conflict with investigation. Regulators and authorized investigators may require the ability to identify a participant or inspect source data under specific legal procedures. A system that offers no controlled disclosure path may be operationally unusable for regulated institutions.

The proper design is not total transparency or total opacity. It is selective disclosure with defined escalation. Routine protocol interaction exposes a proof. Authorized review can reach the underlying evidence through the issuer or custodian, subject to the applicable legal process.

Whether regulators in major jurisdictions will accept ZK-KYC as universally binding compliance remains unresolved. The technology can prove that a statement satisfies a circuit. It cannot decide whether that statement is legally sufficient in every jurisdiction.

Regulatory tailwinds: eIDAS 2 and the shift toward selective disclosure

The European Union is moving toward a digital identity model that makes selective disclosure a first-class requirement.

The eIDAS 2 digital identity regulation mandates that EU member states issue digital identity wallets supporting selective-disclosure cryptographic proof mechanisms. The regulation came into force in 2024, with national wallet rollouts running through 2026.

This creates a regulatory environment in which digital identity is not limited to a centralized web login. The wallet becomes a mechanism for presenting verifiable claims while limiting unnecessary disclosure.

For DeFi, the technical opportunity is straightforward. A wallet capable of presenting cryptographic credentials can become the input to a compliance circuit. The protocol asks for a predicate. The wallet produces a proof. The smart contract verifies the result.

The legal and operational questions are less straightforward.

A national identity wallet may support selective disclosure without being designed for permissionless DeFi. A credential format may be technically compatible with a blockchain application while the issuer rules, liability model, or jurisdictional restrictions remain incompatible. Interoperability at the cryptographic layer does not guarantee interoperability at the legal layer.

The same issue applies to cross-chain systems. A ZK proof generated for one application or chain may not be accepted by another unless the verification key, credential schema, issuer registry, and policy assumptions are aligned. Bridging the proof is not the same as bridging the identity context.

DeFi protocols should therefore avoid treating eIDAS 2 as an automatic compliance gateway. The regulation provides infrastructure and direction. It does not certify every downstream use case.

The stronger interpretation is that European identity policy is normalizing selective disclosure as a legitimate design pattern. That reduces one barrier for institutions and applications that need a machine-verifiable compliance layer. It does not settle questions of jurisdiction, liability, or enforcement.

Cryptographic foundations: the proof system determines the cost profile

ZK-KYC is not one cryptographic technology. It is an application category built on different proof systems with different performance and operational properties.

The main frameworks relevant to compliance circuits include zk-SNARKs, zk-STARKs, Bulletproofs, Groth16, and PLONK. They differ in proof size, proving time, verification cost, setup assumptions, and implementation complexity.

zk-SNARKs

zk-SNARKs provide succinct proofs that can be verified efficiently. They are suitable for on-chain environments where verification cost and calldata size matter. The trade-off depends on the specific construction. Some systems require a trusted setup, and the security model must account for how that setup was generated and maintained.

Groth16

Groth16 is widely used because its proofs are small and verification is efficient. That makes it attractive for smart contracts with strict gas constraints. Its weakness is the circuit-specific setup requirement. A change to the circuit generally requires a new setup. This is an operational constraint for compliance policies that change frequently.

PLONK

PLONK-style systems support more flexible circuit workflows and can use a universal or updatable setup model, depending on the implementation. That flexibility may reduce deployment friction when a protocol needs to change policies or support multiple circuits. The performance profile is not identical to Groth16, and the system still depends on correct circuit compilation and key management.

zk-STARKs

zk-STARKs avoid some trusted-setup requirements and rely on transparent cryptographic assumptions. They can offer advantages for scalability and auditability. Proof sizes and verification characteristics may be less convenient for certain on-chain applications, depending on the chain and implementation.

Bulletproofs

Bulletproofs do not require a trusted setup and can be useful for range proofs and related statements. Their verification and proof-size behavior can be less attractive for complex compliance circuits or high-frequency on-chain use.

The choice is not an ideological contest between proof systems. It is an engineering decision based on circuit structure, chain execution costs, prover infrastructure, update frequency, and the acceptable trust model.

A compliance circuit may need to verify a signature, evaluate an age or jurisdiction predicate, check credential expiry, inspect a revocation commitment, and produce a scoped nullifier. Each additional condition increases circuit complexity. The system must be profiled as a complete workflow rather than judged by the headline properties of the underlying proof framework.

A short proof does not imply a simple compliance system. It only means the verifier receives a compact cryptographic object.

The verifier is usually cheaper than the prover. This asymmetry is useful for blockchains. The heavy computation happens off-chain. The chain checks a proof and a set of public inputs.

But the prover still needs to run somewhere. Mobile wallets may lack the resources for complex circuits. A web application may outsource proving to a service, creating a new privacy and trust dependency. A protocol may operate a prover service, which can observe metadata even if it cannot read the underlying credential. Institutions may run their own infrastructure, but that increases integration and maintenance costs.

Proof generation can be computationally intensive. The system needs reliable performance under realistic load, not just a successful demonstration with one credential and one proof.

Implementation hurdles: the circuit is part of the policy

The most dangerous failure mode is not always a broken cryptographic primitive. It is a correct proof of the wrong statement.

A circuit is executable policy. If it checks that a credential was signed by an approved issuer but does not check expiry, the protocol has encoded stale eligibility. If it checks jurisdiction but accepts an outdated jurisdiction list, the system can produce valid proofs for invalid decisions. If it verifies a sanctions-screening credential without a freshness condition, the result may not reflect the current state.

The protocol should specify its public inputs and policy assumptions precisely. At minimum, the design needs to address:

• Credential authenticity: which issuer signatures are accepted?
• Credential freshness: how recent must the assessment be?
• Revocation: how does the verifier learn that a credential is no longer valid?
• Policy versioning: what happens when the compliance rule changes?
• Issuer rotation: how are compromised or retired issuers removed?
• Wallet binding: how is the credential connected to the user’s authorization key?
• Replay protection: can the same proof be reused across transactions or applications?
• Metadata leakage: what can timing, gas usage, wallet behavior, or transaction patterns reveal?
• Emergency response: can the protocol suspend a credential class without freezing unrelated users?
• Audit access: what evidence remains available for authorized review?

These are not documentation details. They are attack surfaces.

Revocation is the difficult state problem

A static proof is easy to describe. A current compliance state is not static.

Revocation lists can be published on-chain, represented through Merkle trees, or handled through accumulator-style constructions. Each approach creates trade-offs between update frequency, proof complexity, on-chain cost, and privacy.

If a user proves membership in a non-revoked set, the proof must be tied to a current set root or equivalent state commitment. The verifier needs to know which root is authoritative and when it was published. A proof against an old root may be mathematically valid but operationally unacceptable.

Frequent updates also create availability risks. If the protocol cannot obtain current revocation state, does it fail open or fail closed? Failing open may permit ineligible access. Failing closed may block compliant users during an infrastructure outage.

There is no cryptographic shortcut around this policy choice.

The issuer remains a concentrated dependency

ZK systems reduce the need to distribute raw personal data. They do not make the issuer decentralized by default.

An issuer can misclassify a user, approve a fraudulent document, fail to update a sanctions result, or become unavailable. A protocol can use multiple issuers, threshold attestations, or independent verification providers to reduce single-party dependence. But each additional issuer increases circuit and governance complexity.

DAO governance also creates a specific risk. If token holders can modify the approved issuer registry or compliance circuit without strict controls, the protocol’s security boundary includes governance manipulation. A valid proof under yesterday’s policy may no longer represent the policy users believed they were accepting.

The governance contract, verification keys, issuer registry, and revocation mechanism should be treated as one system. Auditing only the proof verifier is incomplete.

What ZK-KYC can and cannot prove

A precise compliance architecture defines its claim boundaries.

ZK-KYC can prove that a user possesses a credential satisfying a specified predicate. It can reduce on-chain disclosure of PII. It can support eligibility checks for permissioned pools, institutional markets, token distributions, and other applications where access conditions are explicit.

It cannot automatically prove that the issuer’s underlying process was legally adequate in every jurisdiction. It cannot remove the need for trusted identity sources. It cannot guarantee that transaction metadata is private. It cannot turn a public blockchain into a fully confidential execution environment.

It also does not make every Layer-2 network private. A Layer-2 scaling system may improve throughput or reduce transaction costs while leaving transaction data observable. Privacy requires explicit cryptographic integration, not the label ZK alone.

This distinction is frequently blurred because many systems use ZK technology for scaling and privacy in the same general ecosystem. The functions are separate. A rollup proof can establish state transition correctness. A ZK-KYC proof can establish an eligibility claim. One does not imply the other.

For protocols evaluating a deployment, the architecture should be reduced to a set of testable questions:

1. What exact claim does the proof encode?

2. Who issued the credential?

3. How is credential freshness established?

4. How are revocations propagated?

5. What information is visible from the transaction and wallet metadata?

6. Which proof system and setup model are used?

7. Where does proof generation occur?

8. What happens when the issuer, prover, or revocation service is unavailable?

9. Which party can identify the user under authorized disclosure?

10. Can governance alter the policy without a transparent and controlled process?

A system that cannot answer these questions is not ready for institutional compliance. It may still be a research prototype. Those categories should not be confused.

The viability test for DeFi compliance

The strongest use case for zk proofs is selective access to applications that need compliance attributes but do not need every participant’s full identity record. Institutional liquidity pools, regulated tokenized assets, permissioned lending markets, and jurisdiction-sensitive financial products fit this model.

The weakest use case is a generic claim that ZK-KYC will make all permissionless DeFi compliant without changing its governance, issuer relationships, monitoring procedures, or legal posture. A proof verifier cannot compensate for an undefined policy.

The technology has a clear architectural advantage: it can minimize routine disclosure while preserving machine-verifiable eligibility. That is enough to make it relevant to institutional DeFi and to the identity infrastructure emerging under eIDAS 2.

It is not enough to call it a universal regulatory standard.

Verdict: viable as a compliance interface, not viable as a standalone compliance system.

The cryptography is mature enough for targeted deployments. The remaining failure points are policy encoding, issuer trust, revocation, operational availability, and regulatory acceptance. Protocols that expose only a proof and retain auditable source evidence off-chain have a defensible design. Protocols that treat a valid proof as the entire compliance stack do not.