How ZK Payments Work
Shielded transactions, note commitments, nullifiers, Zcash, Aztec, and compliant privacy — the complete guide to zero-knowledge payments
What Are ZK Payments?
ZK payments use zero-knowledge proofs to enable blockchain transactions where the amount, sender, and recipient are cryptographically hidden from the public — while still being verifiable as valid by every node on the network. The result is a payment that is simultaneously private and trustless: no counterparty can learn your financial history, but no counterparty needs to trust you either.
The term covers two distinct use cases that are often conflated. The first is privacy: shielding the participants and amounts of individual transactions from public view. This is what Zcash, Aztec, and Tornado Cash addressed. The second is scalability: using ZK proofs to batch thousands of transactions into a single on-chain proof, dramatically reducing gas costs and increasing throughput. This is what zkSync, StarkNet, and Polygon zkEVM do. The two use cases share the same cryptographic foundation but serve different ends — and have very different regulatory profiles.
Privacy-focused ZK payments solve a problem that traditional finance takes for granted: financial confidentiality. When you pay your rent, your bank knows the amount and the recipient but does not publish that information. On a public blockchain like Ethereum or Bitcoin, every transaction is visible to anyone in the world, permanently, indexed by chain-analysis firms, and linkable to real-world identities through on/off-ramps. ZK payments restore the financial privacy that cash and bank accounts provide — without requiring a trusted intermediary to maintain that privacy.
When builders say "ZK payments" they usually mean one of two things: (1) privacy payments — Zcash, Aztec, Monero-style confidential transactions where sender, recipient, and amount are hidden; or (2) ZK-rollup payments — zkSync, StarkNet, Base where ZK proofs compress payment batches for efficiency, but the payment data itself is typically public on the rollup. This guide covers primarily the privacy angle, with a section on how ZK-rollup payments fit the picture.
The Blockchain Privacy Problem
Public blockchains are, by design, fully transparent. Every transaction is broadcast to thousands of nodes, permanently recorded, and publicly indexed. This transparency is the source of blockchain's trustlessness — but it comes at a severe cost to financial privacy that most users don't fully appreciate until it affects them.
Pseudonymity is not anonymity. Bitcoin addresses are not directly linked to real-world identities — but they are permanently and publicly linked to each other. Every transaction reveals which addresses sent to which, with exact amounts and timestamps. Chain analysis firms like Chainalysis, Elliptic, and TRM Labs specialize in clustering Bitcoin addresses into wallets using heuristics: common input ownership (all UTXOs in a transaction likely belong to the same wallet), change address patterns, exchange withdrawal fingerprints, and more. A user who withdraws Bitcoin from Coinbase — linking their KYC identity to one address — is effectively linking their identity to every address in their cluster.
The same dynamic applies on Ethereum and all EVM chains. Every DeFi interaction, every NFT purchase, every DAO vote, every airdrop claim is permanently associated with the user's address. ERC-20 transfer events record exact amounts and block timestamps. MEV bots and frontrunners routinely monitor pending transactions to extract value. Competitors can watch a fund's on-chain activity to anticipate trades. Employers can inspect applicants' wallet histories. Charities can see exactly how much each donor gave. The combination of permanent record-keeping, public indexing, and identity linkage through exchanges creates a surveillance infrastructure far more comprehensive than traditional finance.
The stakes are higher than most users realize. In 2021, a developer who received payment for open-source work had their full payment history — including what they earned for each project — permanently visible to every future employer. In 2022, users of Tornado Cash had their wallets flagged by Circle (USDC issuer) and blacklisted, rendering their USDC unmovable. Chain analysis turned pseudonymous public ledgers into targeted financial surveillance infrastructure. ZK payments are the cryptographic answer.
How Shielded Transactions Work
Shielded transactions use a combination of cryptographic commitments, ZK proofs, and nullifiers to allow sending and receiving funds without revealing amounts, senders, or recipients — while guaranteeing that no coin is created from nothing and no coin is spent twice.
The core construction is the note. A shielded balance is not stored as a public UTXO or account balance — it is stored as an encrypted note in the sender's wallet. The note records the amount, asset type, the recipient's spending key, and a random secret (ρ). It is never published directly on-chain.
Instead, a commitment — a cryptographic hash of the note — is published on-chain and inserted into a public Merkle tree. The commitment proves that a note exists without revealing its contents. Think of it as a locked box: the box is public, but only the key-holder knows what's inside.
To spend a note, the holder generates a zero-knowledge spend proof that proves — without revealing the note — that they know the secret behind one of the commitments in the Merkle tree and that they control the spending key. This proof is published on-chain and validated by every node. Simultaneously, the sender publishes a nullifier: a unique identifier derived from the note's secret. The nullifier is added to a public set. If anyone tries to spend the same note again, the nullifier will already be present — preventing double-spending — without revealing which note was spent or who spent it.
Shielded Transaction Flow (Zcash / Aztec model)
Alice holds a private note
A shielded balance is represented as a cryptographic 'note' stored in Alice's wallet — never visible on-chain. The note encodes the amount, asset type, a spending key, and a random secret (ρ) that makes it unique.
Data fields
The elegant result is a payment system where the public record contains only proofs, nullifiers, and new commitments — none of which can be linked to specific users or amounts by anyone without the spending key. Every node can verify that the system operates correctly (no coins created from nothing, no double-spending) without learning anything about individual transactions.
Zcash & the Shielded Pool
Zcash, launched in 2016, is the foundational implementation of ZK payments. It pioneered the use of zk-SNARKs for shielded transactions and introduced the concepts of note commitments and nullifiers that underpin all subsequent ZK payment systems.
Zcash supports two address types: transparent addresses (t-addresses), which work identically to Bitcoin — full public visibility — and shielded addresses (z-addresses), which use the shielded pool. Transactions between two z-addresses are fully private. Transactions that cross between t-addresses and z-addresses are partially visible — the transparent side is public, the shielded side is not.
Zcash has gone through three major shielded pool upgrades. The original Sprout pool (2016) used Groth16 zk-SNARKs with a trusted setup ceremony. Sapling (2018) introduced a much more efficient circuit that reduced proving time from minutes to seconds, making shielded transactions practical for everyday use. Orchard (2022) eliminated the trusted setup entirely by using the Halo 2 recursive proving system — removing the single largest security assumption in Zcash's history. The transition to Orchard is ongoing as users migrate from Sapling.
The persistent limitation of Zcash has been the anonymity set problem. Despite strong cryptographic privacy, the practical anonymity of any shielded transaction depends on how many other transactions are in the shielded pool at the same time. Because most Zcash transactions historically used transparent addresses — in part because early exchange and wallet support was limited — the shielded pool was often small. A transaction entering or leaving a small pool can be deanonymised with timing analysis even when its contents are hidden.
Zcash's viewing keys are a critical feature for real-world adoption. Every shielded address comes with associated viewing keys that can be shared selectively to allow auditors, regulators, or counterparties to inspect specific transactions or complete address histories — without granting spending authority. This selective disclosure model is how ZK privacy and regulatory compliance can coexist.
Aztec Network — Private Smart Contracts
Aztec extends ZK privacy beyond simple payments to programmable smart contracts — enabling private DeFi, private voting, private lending, and private NFT ownership. Where Zcash shields the transfer of ZEC, Aztec shields arbitrary computation.
Aztec uses a note-based account model similar in concept to Zcash but extended to support arbitrary state. Each account has a private state — a collection of encrypted notes — and a public state visible on-chain. Smart contracts in Aztec (written in the Noir language) can define both private and public functions. A private function executes entirely in the user's local environment, producing a ZK proof that is submitted on-chain. A public function executes on-chain like a normal EVM call.
The practical implications are significant. A private Uniswap-style swap on Aztec would: (1) prove ownership of input tokens privately, (2) compute the output privately, (3) publish only the ZK proof — the swap amount, tokens involved, and trader identity remain hidden. A private lending protocol would allow borrowers to post collateral and receive loans without revealing their collateral ratio to potential liquidators. A private DAO vote would enable ballot-secrecy without sacrificing on-chain verifiability of the result.
Aztec's proving system — Honk (UltraPlonk-based) — does not require a trusted setup, addressing one of the major concerns with Groth16-based systems. The main UX challenge is proving time: generating a zk-proof for a private transaction takes 1–30 seconds on a consumer device, compared to instant signing for a regular Ethereum transaction. Hardware acceleration and recursive proof folding are active areas of development that are steadily reducing this latency.
ZK-Rollup Payments — Scale Without Privacy
ZK-rollups — zkSync Era, StarkNet, Polygon zkEVM, Scroll, Linea — use ZK proofs for a fundamentally different purpose: scaling throughput and reducing costs, not hiding transaction data. Understanding this distinction is essential to understanding the ZK payment landscape.
A ZK-rollup processes thousands of transactions off-chain, then generates a single validity proof demonstrating that all state transitions were computed correctly. This proof is submitted to Ethereum L1. The key difference from a shielded pool: the transaction data — amounts, addresses, function calls — is published to L1 as calldata or blobs (EIP-4844). Anyone can reconstruct the full state of the rollup from L1 data. The ZK proof guarantees correctness, not privacy.
ZK-rollup payments are therefore transparent by default. Sending USDC on zkSync Era is visible to anyone reading the L1 data availability layer — just like sending on Ethereum mainnet, but cheaper and faster. This makes ZK-rollups excellent for high-volume payment applications where cost and throughput matter but privacy is not required — B2B settlement, micropayments, gaming economies.
The two use cases can be combined: a ZK-rollup with an optional private payment pool. StarkWare's architecture allows for private extensions on top of public rollup infrastructure. Aztec is effectively a ZK-rollup where privacy is the default rather than an optional layer. The long-term vision is a rollup ecosystem where developers can choose the privacy level appropriate for each application.
| System | ZK proof purpose | Transaction data visible? | Best for |
|---|---|---|---|
| Zcash | Privacy (hide tx contents) | No — only commitment + nullifier | Private peer-to-peer payments |
| Aztec | Privacy + smart contracts | No — only proofs posted | Private DeFi, private NFTs |
| zkSync Era | Scalability (validity proof) | Yes — calldata on L1 | High-volume EVM payments |
| StarkNet | Scalability (validity proof) | Yes — data on L1 | Gaming, DeFi, enterprise |
| Polygon zkEVM | Scalability (validity proof) | Yes — calldata on L1 | EVM-compatible apps |
| Tornado Cash | Anonymity set (mixing) | Deposits/withdrawals visible | Breaking transaction linkability (sanctioned) |
Privacy Models Compared
ZK-based privacy is not the only approach to confidential blockchain payments. Monero uses ring signatures, RingCT, and stealth addresses — a different cryptographic construction with different security and usability trade-offs. Understanding the design space helps in evaluating which system fits a given use case.
Privacy Model Comparison
Privacy strength
The key insight from comparing privacy models is that ZK-based privacy (Zcash, Aztec) provides cryptographic privacy — hiding information behind proofs whose security is reducible to well-studied mathematical hardness assumptions. Ring signature-based privacy (Monero) provides probabilistic privacy — the sender is hidden among a ring of decoys, but improving heuristics (such as identifying coinbase outputs that cannot be decoys) can narrow the anonymity set over time. Neither approach is unconditionally secure against an adversary with unlimited computational resources, but ZK-based approaches offer stronger formal privacy guarantees.
MimbleWimble (Grin, Beam) takes the most elegant approach: inputs and outputs of different transactions are merged at the block level, making it impossible to trace individual transaction graphs. The trade-off is that interactive transaction construction requires both sender and recipient to be online simultaneously — impractical for many payment workflows.
The Compliance Challenge
Financial privacy and regulatory compliance are not inherently in conflict — but the tools to reconcile them are still maturing. The Tornado Cash sanctions in August 2022 crystallised the tension and accelerated the development of compliant ZK payment infrastructure.
The FATF Travel Rule requires virtual asset service providers (VASPs) — exchanges, custodians — to collect and transmit originator and beneficiary information for transactions above $1,000 (or equivalent). Applied to shielded transactions, this creates an apparent contradiction: the travel rule requires identifying information that the ZK payment is designed to hide. In practice, the travel rule applies to VASPs, not to on-chain transactions — a peer-to-peer shielded transfer is not subject to travel rule requirements. But any shielded address that interacts with a VASP creates a compliance obligation at the point of the VASP interaction.
The Tornado Cash precedent is the defining regulatory event for ZK privacy. In August 2022, the U.S. Office of Foreign Assets Control (OFAC) sanctioned Tornado Cash — an Ethereum smart contract that pooled and anonymised deposits using ZK proofs. OFAC listed the smart contract addresses themselves, creating an obligation for U.S. persons not to interact with those addresses. Circle subsequently blacklisted USDC held in Tornado Cash contracts. Several front-end operators were arrested in the Netherlands and the U.S. The sanctions were partially reversed by the 5th Circuit Court of Appeals in 2024, which ruled that immutable smart contracts cannot be property subject to OFAC sanctioning — but the chilling effect on privacy protocol development has been substantial.
Compliant privacy is the emerging response. The core idea is that a ZK payment system can provide privacy from the public while allowing selective disclosure to authorized parties — regulators, auditors, law enforcement with legal process. Zcash viewing keys, Aztec's compliance key architecture, and newer proposals like Penumbra's shielded pool all incorporate selective disclosure as a first-class feature. Some designs allow a compliance authority to hold a master viewing key that can view any transaction — a "backdoor for regulators" architecture — while others prefer user-controlled selective disclosure, where the user chooses what to reveal to whom.
Selective Disclosure — Viewing Keys
What each disclosure level reveals to different observers
Default — no keys shared. On-chain observer sees only commitments, nullifiers, and proofs.
The selective disclosure model mirrors how traditional financial privacy works: your bank transactions are private by default, but can be disclosed under legal compulsion. The difference is that in traditional finance, the bank is the trusted party that holds the records. In ZK payment systems, cryptographic proofs allow users to disclose exactly what they choose — without relying on a bank's cooperation or exposing information beyond the disclosure's scope.
ZK Identity & Compliant Privacy
ZK proofs unlock a powerful concept for regulatory compliance: proving attributes about yourself — that you are over 18, that you are not a sanctioned individual, that you are a verified accredited investor — without revealing the underlying identity data. This is the foundation of compliant ZK payments.
A ZK credential is a proof generated from an identity document or database lookup. For example, a KYC provider can issue a signed credential attesting "this wallet address belongs to a person who passed KYC, is not on any sanctions list, and is domiciled in a FATF-member jurisdiction." The wallet holder can then generate a ZK proof that they hold such a credential — without revealing their name, passport number, nationality, or any other underlying data. The proof reveals only the binary attestation: compliant or not.
This architecture enables what developers call programmable compliance: a DeFi protocol or ZK payment system can require a compliance proof as a prerequisite for interaction. Every user of the protocol has been KYC-checked and sanctions-screened, but no personal data is stored on-chain or accessible to other users. The protocol operator knows only that every user is compliant — not who any specific user is.
Protocols building in this space include Polygon ID (ZK-based verifiable credentials on Ethereum), Holonym (ZK proof of unique personhood and citizenship without revealing identity), and Nocturne(a shielded account system that embeds compliance proofs into the spending condition). The Ethereum community's ERC-7812 proposal standardizes ZK credential formats for cross-protocol compatibility.
The apparent paradox of "private but compliant" dissolves when you separate two questions: (1) who knows the details of each transaction?and (2) who can verify the transaction is legitimate? Traditional finance answers (1) with "your bank" and (2) with "your bank." ZK payments answer (1) with "only the parties involved" and (2) with "everyone, via cryptographic proof — including that the user is compliant." The compliance knowledge and the transaction knowledge are decoupled by the math.
The Future of ZK Payments
ZK payment infrastructure is advancing on three parallel fronts: proving speed, institutional adoption, and Ethereum's native privacy roadmap. Each is converging on a future where private payments are as fast and cheap as public ones.
Proving time is the primary UX bottleneck for client-side ZK payments. Generating a Zcash Orchard spend proof takes ~2 seconds on a modern phone; a full Aztec private smart contract interaction can take 10–30 seconds. Proving time is falling rapidly as hardware acceleration — GPU provers, FPGA provers, custom ASICs — is applied to the specific mathematical operations (finite field arithmetic, fast Fourier transforms) required by ZK proofs. Folding schemes like Nova, HyperNova, and Protostar also dramatically reduce proving time for incremental computation. The target is sub-second proving on consumer hardware within 2–3 years.
Institutional private payments are a near-term growth area. Corporate treasury teams, hedge funds, and market makers need to settle large transactions without revealing their positions. Traditional finance solves this with DMA (direct market access) and dark pools. On-chain, ZK payments can provide equivalent confidentiality with atomic settlement. Fireblocks, Copper, and other institutional custodians are integrating ZK payment capabilities. The Monetary Authority of Singapore (MAS) Project Guardian experiments included confidential asset transfers between institutional participants using ZK proofs.
Ethereum's native privacy roadmap, laid out by Vitalik Buterin in 2024, envisions privacy as a first-class property of the Ethereum ecosystem rather than a specialised application layer. The roadmap includes: (1) a standard shielded address format that all wallets and dApps support, allowing users to receive any token to a shielded address; (2) FOCIL (fork-choice inclusion lists) to prevent censorship of privacy transactions at the validator level; and (3) native account abstraction that enables privacy without requiring specialised wallet software. This roadmap would bring ZK payment capabilities to every Ethereum user without requiring a separate chain or protocol.
Cross-chain private payments are enabled by ZK bridges. Traditional cross-chain bridges reveal the transaction amount and direction at the bridge points. ZK bridges — Succinct's Telepathy, Polyhedra's zkBridge — can generate validity proofs for cross-chain state transitions without revealing the underlying data. Combined with shielded pools on each chain, this creates end-to-end private payment paths across chains.
Risks
ZK payments carry unique risks that differ from standard crypto custody risks. Cryptographic, regulatory, and systemic risks each need to be understood before using or building on private payment infrastructure.
| Risk | Description | Mitigation |
|---|---|---|
| Trusted setup compromise | Groth16-based systems (Zcash Sapling) require a trusted setup ceremony. If the toxic waste from the ceremony was not properly destroyed, an attacker could generate undetectable counterfeit notes. | Audit ceremony participation, prefer newer systems (Orchard/Honk) that eliminate trusted setup |
| Regulatory blacklisting | Shielded addresses can be blocked by VASP operators (exchanges, stablecoin issuers) under sanctions screening requirements. Funds held in blacklisted contracts may become unspendable. | Understand that exchange access depends on counterparty compliance policies; maintain transparent address liquidity for exit |
| Small anonymity set | Privacy strength depends on how many other transactions are in the shielded pool simultaneously. A small pool allows timing/amount correlation attacks even when contents are hidden. | Use protocols with large existing shielded pools; avoid entering and exiting with the same amount in a short time window |
| Proving system bugs | ZK circuit bugs can allow fake proofs or note creation. Zcash's 2019 counterfeiting vulnerability (fixed before exploitation) showed that ZK circuit bugs can be critical and hard to detect. | Conservative protocol upgrades; multiple independent circuit audits; bug bounties |
| Key management | Spending keys and viewing keys are high-value cryptographic secrets. Loss means permanent loss of shielded funds; disclosure of viewing keys reveals full transaction history. | Hardware wallets with shielded transaction support; Shamir secret sharing for key backup |
| Compliance failure | Using private payments to evade tax reporting, KYC requirements, or sanctions is illegal in most jurisdictions regardless of the technical capability to do so. | Maintain complete records of own transactions; use selective disclosure for tax reporting; avoid sanctioned protocols |
The most important non-technical risk is regulatory uncertainty. Privacy-preserving technology is legal in most jurisdictions when used for legitimate purposes — financial privacy, corporate confidentiality, protection from targeted theft. The same technology can be used for illegal purposes. Regulators are still developing frameworks for how to treat ZK payment protocols: as neutral infrastructure (like HTTPS encryption) or as regulated financial instruments (like dark pools). The outcome of ongoing legal cases — the Tornado Cash appeals, EU MiCA implementation rules on privacy features — will shape which ZK payment architectures can legally operate at scale in regulated markets over the next several years.