Zero-Knowledge Proofs in Financial Infrastructure

Section 01

The Compliance Paradox: Why Data-Sharing KYC Is Broken

Every time a person opens a crypto exchange account, a neobank, or a DeFi protocol with onboarding, they hand over their passport scan, proof of address, selfie, sometimes biometrics — to an institution whose security posture they cannot audit, whose data retention policies they cannot verify, and whose future breach they cannot prevent.

The regulatory intent is legitimate: verify that users are who they say they are, that they are not on sanctions lists, that they are not moving proceeds of crime. But the mechanism — centralised storage of raw identity documents — is a product of 1990s database thinking applied to 2020s threat models. The Equifax breach (147 million records), the Binance KYC leak (60,000 user photographs), and dozens of smaller exchange leaks illustrate the compounding cost of storing what you only needed to verify.

"The problem was never verification. The problem is that verification became an excuse for permanent data collection. Zero-knowledge proofs separate the proof from the payload — and in doing so, collapse an entire category of risk.

The architecture of traditional KYC creates three compounding problems. First, every institution that onboards a user becomes a data custodian with perpetual liability. Second, users repeat this process across dozens of platforms — each one a new attack surface. Third, the data, once collected, is often shared laterally across group entities, sold to data brokers, or retained long after the regulatory minimum period, with no cryptographic guarantee of deletion.

Zero-knowledge proofs offer a structural exit from this compounding liability. A ZK proof is a cryptographic object that proves a statement is true without revealing the evidence behind it. Applied to compliance, this means: prove that a user is over 18, is not sanctions-listed, and is a verified resident of a qualifying jurisdiction — without transmitting the passport number, date of birth, or home address to any counterparty.

Table 1: Traditional KYC vs ZK-KYC across key compliance dimensions

Section 02

Zero-Knowledge Proof Foundations

A zero-knowledge proof is a protocol between a prover and a verifier. The prover demonstrates knowledge of a secret witness w satisfying a public statement x— defined by a relation R(x, w) = true — without revealing w. For financial compliance, the statement might be "this address has completed KYC with a licensed provider and is not sanctions-listed"; the witness is the user's actual identity data and the identity provider's signature over it.

Three properties define a ZK proof system:

Modern ZK proof systems — zkSNARKs (Succinct Non-interactive ARguments of Knowledge) and zkSTARKs — add two further properties critical for blockchain deployment: succinctness (the proof is short regardless of witness size) and non-interactivity (no back-and-forth between prover and verifier — the proof is a static object that anyone can verify).

// A zkSNARK for relation R proves:
//   Knowledge of witness w such that R(x, w) = 1
//   Without revealing w to the verifier

Setup:    (pk, vk) ← Setup(R)          // Trusted or universal setup
Prove:    π ← Prove(pk, x, w)           // Prover generates proof
Verify:   {0,1} ← Verify(vk, x, π)     // Verifier checks proof

// Financial compliance instantiation:
R(x, w) = 1  iff:
  x = (sanctions_merkle_root, issuer_pubkey, min_age)
  w = (identity_data, issuer_signature, merkle_path)
  AND:
    issuer_signature.verify(identity_data, issuer_pubkey) = true
    age_from(identity_data) >= min_age
    merkle_nonmembership(identity_data.hash, sanctions_merkle_root, merkle_path) = true

The statement x (the public input) is known to both parties and committed on-chain. The witness w never leaves the prover's device. The proof π is a compact byte array — typically 192–288 bytes for Groth16 — that the smart contract verifier checks in a single transaction. If it passes, the contract knows the statement is true. If it fails, the transaction reverts. No personal data crosses the wire.

Section 03

ZK-KYC Architecture: Identity Without Disclosure

The ZK-KYC stack separates identity verification into three independent roles: the issuer (a licensed KYC provider who verifies the user once), the holder (the user, who stores their credentials locally), and the verifier (a protocol, exchange, or institution that needs compliance assurance). The issuer never interacts with the verifier. The verifier never sees the issuer's data. The proof is the only link between them.

┌──────────┐          ┌──────────────┐          ┌─────────────┐          ┌──────────────┐
│  User    │          │  KYC Issuer  │          │  ZK Wallet  │          │  Verifier    │
│ (Holder) │          │  (e.g. Sumsub│          │  (Privado)  │          │  (Protocol)  │
└────┬─────┘          └──────┬───────┘          └──────┬──────┘          └──────┬───────┘
     │                        │                         │                        │
     │── [1] Submit docs ────►│                         │                        │
     │                        │── [2] Verify identity ──┤                        │
     │                        │                         │                        │
     │◄─ [3] Issue VC ────────│                         │                        │
     │   {age, country, KYC_  │                         │                        │
     │   level, expiry, sig}  │                         │                        │
     │                        │                         │                        │
     │── [4] Store VC ───────────────────────────────►  │                        │
     │                        │                         │                        │
     │                        │                         │                        │
     │   ── ── ── ── LATER: Protocol Interaction ── ── ── ── ──                 │
     │                        │                         │                        │
     │── [5] Request proof ────────────────────────────────────────────────────►│
     │                        │                    [6] Generate ZK proof         │
     │                        │                        from VC + circuit         │
     │◄── ── ── ── ── ── ── ── ── ── ── [7] Return π + public inputs ──────────│
     │                        │                         │                        │
     │── [8] Submit tx + π ────────────────────────────────────────────────────►│
     │                        │                    [9] Verify(vk, x, π) on-chain │
     │                        │                    [10] Record nullifier hash    │
     │◄── [11] Access granted ──────────────────────────────────────────────────│

Steps 1–3 happen once. The KYC issuer verifies the user's identity through standard document checks (liveness detection, document scanning, sanctions screening) and issues a verifiable credential (VC) — a signed JSON-LD object containing the verified attributes. This VC is stored in the user's identity wallet, encrypted with their private key.

Steps 5–11 happen at every protocol interaction. The user generates a ZK proof from their VC — proving specific claims from it — and the verifier checks only the proof. A nullifieris recorded on-chain for each proof: a deterministic hash derived from the credential and the verifier's identifier, preventing the same credential from being reused to bypass per-wallet limits while preserving user pseudonymity across protocols.

The credential schema determines what claims can be proven. A minimal KYC credential schema for DeFi protocol compliance might include: kyc_level, country_code, age_over_18, accredited_investor, sanctions_cleared, and expiry_timestamp. A proof can selectively disclose any subset of these claims — the circuit constrains only the claims the verifier needs, leaving all other attributes private.

Section 04

ZK-AML: Transaction Compliance Without Exposure

AML compliance has a harder problem than KYC. KYC is a one-time identity check; AML is ongoing transaction monitoring. The standard approach — feeding transaction data to centralised screening services (Chainalysis, Elliptic, TRM Labs) — works but creates a surveillance layer that sees every transaction across every screened entity. ZK-AML aims to preserve the compliance guarantee while removing the need for transaction disclosure.

Three ZK-AML patterns are deployed in production or near-production today:

pragma circom 2.1.0;
include "circomlib/circuits/poseidon.circom";
include "circomlib/circuits/merkleProof.circom";

// Proves: address is NOT in the sanctions Merkle tree
// Public:  sanctions_root (committed on-chain)
// Private: address, merkle_path, path_indices

template SanctionsExclusion(tree_depth) {
    // Public inputs
    signal input sanctions_root;

    // Private inputs (never revealed)
    signal input address;
    signal input merkle_path[tree_depth];
    signal input path_indices[tree_depth];

    // 1. Hash the address to a leaf
    component hasher = Poseidon(1);
    hasher.inputs[0] <== address;
    signal leaf <== hasher.out;

    // 2. Compute the Merkle root for this leaf using the provided path
    component merkleCheck = MerkleProof(tree_depth);
    merkleCheck.leaf <== leaf;
    merkleCheck.pathElements <== merkle_path;
    merkleCheck.pathIndices <== path_indices;
    signal computed_root <== merkleCheck.root;

    // 3. CONSTRAINT: computed root must NOT equal sanctions root
    //    (enforce non-membership — if address IS in tree, proof fails)
    component neq = IsZero();
    neq.in <== computed_root - sanctions_root;
    neq.out === 0;  // Must be zero diff = ZERO, i.e. NOT in tree
    // NOTE: full non-membership requires Sparse Merkle Tree (SMT)
    //       with ordered leaves and boundary proof — see iden3/go-merkletree
}

In production, Sparse Merkle Trees (SMTs) replace standard Merkle trees for non-membership proofs. An SMT assigns a canonical position to every possible leaf; a non-membership proof demonstrates that the path from root to the expected position is empty. The iden3 team's go-merkletree-sql library and Aztec's indexed-merkle-tree are the two most production-ready implementations.

Section 05

Proof System Selection: Groth16, PLONK & STARKs

Choosing a proof system is an engineering trade-off between setup trust requirements, proof size, verification cost, prover efficiency, and cryptographic assumption strength. For financial applications where on-chain verification gas cost and proof reusability matter, the choice typically narrows to three systems:

Table 2: ZK proof system comparison for financial compliance applications

For most early-stage ZK-KYC deployments, Groth16 remains the pragmatic choice: the smallest on-chain footprint, the most audited circuit libraries (Circom ecosystem), and the widest toolchain support (snarkjs, circom, Hardhat plugins). The per-circuit trusted setup is a real risk — mitigated by running a large multi-party computation (MPC) ceremony where even one honest participant guarantees security. Zcash's Sapling ceremony (90 participants) and the Tornado Cash ceremony (1,114 contributions) are the reference implementations. For production deployments serving regulated institutions, running a ceremony with 50+ independent participants across multiple jurisdictions is the minimum bar.

PLONK/FFLONK becomes attractive when a compliance system needs many circuit variants (different claim types, jurisdiction-specific rule sets) because the universal setup amortises across all circuits. Aztec's Noir language and Halo2 from the Zcash Foundation are production-grade PLONK-family implementations with active financial application development.

"Post-quantum resistance matters for long-lived compliance records. A sanctions non-membership proof stored on-chain today might be computationally broken in 15 years. STARKs, whose security rests on hash functions rather than elliptic curve assumptions, provide a durable guarantee. For most active transaction verification, the quantum threat is distant — but for permanent on-chain identity anchors, it deserves consideration in system design.

Section 06

Production Systems: Polygon ID, Privado & Verite

Three ecosystems have reached production deployment for ZK-based identity in financial applications:

Table 3: Production ZK identity systems comparison for financial applications

Section 07

Circuit Design for Compliance Applications

Writing a ZK circuit for compliance is more like writing a hardware specification than application code. Every operation must be expressed as a system of polynomial constraints over a prime field. Conditionals, comparisons, and data structures that feel trivial in normal programming become non-trivial constraint engineering challenges. The most common source of exploitable bugs in production ZK systems is underconstraint — a variable that should be constrained to a specific range is left partially free, allowing an adversary to satisfy the circuit with a false witness.

// INSECURE: This does NOT constrain 'age' to be >= 18
// An adversary can supply any field element that satisfies the comparison
template AgeCheck_INSECURE() {
    signal input age;
    signal input min_age;
    signal output valid;

    valid <== age - min_age;  // ← WRONG: not a boolean constraint
}

// SECURE: Use a bitwise range decomposition to enforce age is in [0, 2^8)
// then constrain comparison using Num2Bits + LessThan gadgets
template AgeCheck_SECURE() {
    signal input age;
    signal input min_age;  // public input

    // Decompose age into 8 bits — proves it's a valid 8-bit integer
    component bits = Num2Bits(8);
    bits.in <== age;

    // LessThan gadget with n=8 bits (range-constrained)
    component lt = LessThan(8);
    lt.in[0] <== min_age;   // min_age < age → valid
    lt.in[1] <== age;
    lt.out === 0;            // 0 means NOT (min_age < age), so age >= min_age
    // Or: use GreaterEqThan gadget from circomlib for clarity
}

The circomlib library (maintained by iden3) provides audited gadgets for common operations: bitwise arithmetic, Poseidon hashing, EdDSA signature verification, Merkle path verification, and comparison operators. Never reimplement these — circuit bugs are not caught by testing the way application bugs are, because a circuit that generates valid proofs may still be exploitable through a carefully crafted false witness that satisfies underspecified constraints.

For a production ZK-KYC system handling accredited investor verification, the circuit typically needs to verify: the issuer's EdDSA signature over the credential, the credential's expiry timestamp relative to the current block timestamp, the jurisdiction claim against a country allowlist (Merkle membership proof), and the specific attribute being queried (e.g., kyc_level >= 2). A well-designed circuit for this full check runs to approximately 35,000–55,000 constraints using circomlib gadgets — manageable for mobile proving in 2–5 seconds.

Section 08

Performance Engineering & Gas Cost Analysis

Performance has historically been ZK's Achilles heel. Proof generation for complex circuits was measured in minutes on desktop hardware as recently as 2022. The engineering progress since then has been significant — but understanding current bottlenecks is essential before designing a production system that relies on real-time compliance gating.

// Groth16 prover time (approximate):
T_prove ≈ k₁ · C · log(C) / CPU_threads   (for CPU proving)
T_prove ≈ k₂ · C / GPU_cores              (for GPU proving)

// Where:
//   C = number of constraints in the circuit
//   k₁ ≈ 40 ns per constraint·log-factor (Apple M2, snarkjs WASM)
//   k₂ ≈ 2 ns per constraint (RTX 3090, RapidSnark)

// Empirical benchmarks (2025 hardware, snarkjs WASM):
//   C =  10,000  → ~1.2s  (simple age + sanctions check)
//   C =  30,000  → ~4.1s  (full KYC claim + country allowlist)
//   C = 100,000  → ~16s   (complex AML volume circuit)
//   C = 500,000  → ~95s   (too slow for client-side; needs proving server)

// RapidSnark (native, M2):
//   C = 100,000  → ~0.8s  (GPU acceleration possible)
//   C = 500,000  → ~3.2s

// Rule of thumb: keep compliance circuits under 50,000 constraints
// for acceptable client-side proving on mid-range smartphones (2024+)

Table 4: ZK proof verification gas costs across deployment targets (May 2026, ETH ~$2,800)

For high-throughput compliance applications (exchange login, per-transaction AML checks), the unit economics only work on L2 networks or through proof aggregation. Recursive proof aggregation — batching hundreds of individual compliance proofs into a single aggregate proof verified on-chain — reduces per-proof gas cost by 2–3 orders of magnitude. Polygon's zkEVM validium mode and Aztec's proof aggregation layer both support this pattern.

Section 09

FATF Travel Rule: The ZK Approach

FATF Recommendation 16 requires Virtual Asset Service Providers (VASPs) to collect and transmit originator and beneficiary information for transactions above the threshold (USD 1,000 / EUR 1,000 in most jurisdictions). This is the direct regulatory collision point for ZK privacy: the regulation explicitly requires data sharing between VASPs, which ZK is designed to avoid.

The ZK-compatible Travel Rule architecture separates what the regulation requires from what the regulation forces. FATF requires that:

• Originator VASP verifies originator identity (KYC obligation — satisfiable with ZK)
• Beneficiary VASP verifies that originator data is available if requested by authorities (data access obligation)
• Sanctions screening occurs on both sides (satisfiable with ZK non-membership proof)
• Data is retained for 5 years (storage obligation — requires encrypted off-chain escrow)

// ZK-compatible FATF Travel Rule flow:

1. ORIGINATOR VASP (Sender side):
   a. Perform standard KYC on originator
   b. Generate ZK credential: prove(originator_is_KYC_verified, not_sanctions_listed)
   c. Encrypt raw originator data → E_kyc (AES-256-GCM, key escrowed with regulator)
   d. Commit: H(E_kyc) → on-chain travel rule registry

2. TRANSACTION:
   a. Attach π_kyc (ZK proof of KYC) and H(E_kyc) (encrypted data commitment) to tx
   b. Beneficiary VASP receives π_kyc + H(E_kyc)

3. BENEFICIARY VASP (Receiver side):
   a. Verify π_kyc on-chain → confirms originator is KYC'd and sanctions-clear
   b. Perform own ZK sanctions check on beneficiary address
   c. Store H(E_kyc) in compliance log for 5 years
   d. Does NOT receive raw personal data — but can retrieve E_kyc on authority demand

4. ON AUTHORITY REQUEST (regulator subpoena):
   a. Originator VASP provides E_kyc decryption key to regulator
   b. Regulator decrypts → full originator data available
   c. On-chain H(E_kyc) provides tamper-proof audit trail of what was escrowed

// Result: Day-to-day operations use ZK proofs (privacy preserved)
//         Regulatory access preserved through escrow mechanism
//         No data shared between VASPs in normal operations

MAS (Singapore) published a Technology Risk Management Notice in late 2025 acknowledging ZK-based compliance architectures as "technically viable" for meeting Travel Rule requirements, provided that the encrypted data escrow is accessible to MAS within 48 hours of a legal demand. BNM (Malaysia) is expected to follow with similar guidance by Q3 2026. The EU's MiCA regulation and the DORA framework both permit ZK-based identity proofs in the context of regulated crypto-asset service providers, subject to supervisory inspection rights.

OpenVASP, Notabene, and TRM Labs are each developing ZK-native Travel Rule extensions to their existing inter-VASP messaging standards. The critical engineering challenge is not the ZK proof itself — it is the key management architecture for the encrypted escrow: who holds the decryption keys, how are they rotated, and how do you guarantee availability to authorities without creating a backdoor to the general public.

Section 10

Failure Modes & Attack Vectors

ZK systems fail differently from traditional software — and often silently. A compromised trusted setup, an underconstrained circuit, or a corrupted credential issuer can produce a system that generates valid-looking proofs for false statements. Unlike a buffer overflow that crashes a process, a ZK exploit may operate undetected until forensic analysis catches an impossible state. Here are the vectors that matter.

Section 11

Deployment Playbook: Five Phases

A realistic ZK compliance deployment for a regulated financial application — exchange, lending protocol, or payment provider — follows five phases spanning 6–18 months depending on regulatory complexity.

Section 12

Frequently Asked Questions

Related Reading