Privacy Pool

What Is a Privacy Pool?

A privacy pool is a protocol design that enables private on-chain transactions while remaining compatible with regulatory compliance. The concept was formally introduced in a 2023 paper titled "Blockchain Privacy and Regulatory Compliance: Towards a Practical Equilibrium," co-authored by Vitalik Buterin, Jacob Illum (Chainalysis), Matthias Nadler, Fabian Schär (University of Basel), and Ameen Soleimani.

The core problem privacy pools solve: traditional privacy tools mix all users into a single anonymity set, making it impossible to distinguish legitimate privacy-seeking users from those laundering illicit funds. This is what led to the OFAC sanctioning of Tornado Cash in August 2022. Privacy pools add a compliance layer on top of the mixing mechanism, allowing honest users to dissociate from flagged deposits without sacrificing their own privacy.

Rather than choosing between full transparency and full anonymity, privacy pools let users selectively prove properties about their funds. You can demonstrate that your deposit belongs to a set of "clean" deposits without revealing which specific deposit is yours.

How It Works

Privacy pools combine two established cryptographic techniques: commitment schemes for hiding deposit details, and zero-knowledge proofs for verifying compliance without revealing identity.

Deposit

When a user deposits into a privacy pool:

1. The depositor generates two random values: a secret s and a nullifier n
2. A commitment c = H(s, n) is computed using a ZK-friendly hash function (typically Poseidon, which is optimized for efficient computation inside zk-SNARK circuits)
3. This commitment is recorded as a new leaf in a Merkle tree maintained by the smart contract
4. The commitment reveals nothing about the depositor or any future recipient

// Simplified deposit flow
const secret = randomBytes(32);
const nullifier = randomBytes(32);
const commitment = poseidonHash(secret, nullifier);

// Contract stores commitment in Merkle tree
await privacyPool.deposit(commitment, { value: depositAmount });

Withdrawal

To withdraw, the user generates a zero-knowledge proof that demonstrates three things:

1. They know the secret and nullifier for a valid commitment in the pool
2. The nullifier hash has not been used before (preventing double-spending)
3. Their commitment belongs to a specific association set: a curated subset of deposits deemed compliant

The smart contract verifies the proof, checks the nullifier against its registry, and transfers funds to the specified withdrawal address. The on-chain transaction reveals the association set root (the Merkle root of the chosen subset) but not which deposit within that set belongs to the withdrawer.

// Simplified withdrawal flow
const proof = await generateZKProof({
  secret,
  nullifier,
  associationSetRoot,  // Merkle root of the compliant subset
  recipient,
});

// Contract verifies proof and transfers funds
await privacyPool.withdraw(proof, nullifierHash, recipient, associationSetRoot);

Association Sets

Association sets are the key innovation that distinguishes privacy pools from earlier mixers. An association set is a subset of all deposits in the pool. When withdrawing, a user selects an association set and proves via ZKP that their deposit belongs to it.

There are two approaches to constructing association sets:

• Inclusion proofs: identify deposits with evidence they are low-risk, then build a set containing only those deposits. The user proves their deposit is within this "good" set.
• Exclusion proofs: identify deposits with evidence they are high-risk, then build a set containing everything except those flagged deposits. The user proves their deposit is not among the flagged ones.

Association Set Providers (ASPs) are the entities responsible for curating these sets. ASPs monitor on-chain deposits, conduct Know Your Transaction (KYT) analysis via tools like sanctions screening, and maintain an on-chain registry of approved deposit labels. ASPs cannot move user funds or prevent a public exit.

The Ragequit Mechanism

Privacy pools include a safety valve called "ragequit": if a deposit is incorrectly excluded by an ASP, the original depositor can publicly withdraw their funds without ASP approval. This sacrifices privacy (the deposit-withdrawal link becomes visible on-chain) but guarantees fund recovery. The mechanism requires the initiator to be the original depositor and the commitment to be unspent.

Privacy Pools vs. Tornado Cash vs. CoinJoin

Understanding privacy pools requires comparing them with the two most prominent alternatives for on-chain transaction privacy.

For a broader look at how these tools fit into Bitcoin's privacy ecosystem, see the Bitcoin privacy landscape research article.

Real-World Implementations

The first production implementation of privacy pools launched on Ethereum mainnet on March 31, 2025, built by 0xbow (co-founded by Ameen Soleimani and Zak Cole). Vitalik Buterin was among the first depositors. By late 2025, the protocol had processed approximately $6 million in transaction volume across over 1,500 users, supporting ETH, wBTC, USDC, USDT, and DAI.

In November 2025, 0xbow closed a $3.5 million seed round led by Starbloom Capital, with angel investment from Buterin. The protocol has also been deployed on the Gnosis network.

The Ethereum Foundation integrated privacy pools into its Kohaku wallet, demonstrated at the Cypherpunk Congress during Devconnect in Buenos Aires (November 2025). In May 2026, the Foundation released the Kohaku SDK (v0.0.1-alpha), an open-source toolkit for integrating privacy pool functionality into any Ethereum wallet.

Use Cases

• Regulatory-compliant privacy: institutions and businesses that need transaction privacy for competitive reasons but must demonstrate compliance with anti-money laundering rules can use privacy pools to satisfy both requirements
• Personal financial privacy: individuals can prevent address clustering and taint analysis from linking their transactions while remaining in a compliant anonymity set
• DAO treasury management: decentralized organizations can execute payments without revealing strategic treasury movements to competitors or front-runners
• Salary and payroll privacy: employers paying in stablecoins can protect employee compensation details from being publicly visible on-chain
• Whistleblower and donor protection: journalists, activists, and donors can receive funds without exposing the sender-receiver relationship

Why It Matters

Privacy pools address a fundamental tension in public blockchain design: the same transparency that enables censorship resistance and auditability also exposes every financial transaction to public scrutiny. Most traditional financial systems provide baseline privacy by default. Public blockchains provide none.

Previous attempts to solve this created a binary choice: either accept full transparency or use tools that regulators view as money laundering infrastructure. Privacy pools offer a third option where compliance and privacy coexist. If successful, this model could become the standard for how privacy is implemented across layer-1 and layer-2 networks.

For Bitcoin-native approaches to transaction privacy, protocols like CoinJoin, silent payments, and PayJoin take different architectural approaches. Privacy pools are currently Ethereum-focused but the underlying principle of compliance-compatible privacy applies across ecosystems.

Risks and Considerations

ASP Centralization

Association Set Providers introduce a trusted third party into an otherwise trustless system. A malicious or compromised ASP could construct association sets that maximize extractable information about users, inflate perceived anonymity by padding sets with known deposits, or face regulatory pressure to implement full whitelisting with KYC pre-screening.

Anonymity Set Size

The privacy guarantee of a privacy pool depends directly on the size of the association set. Smaller, more restrictive sets provide weaker privacy because there are fewer deposits to hide among. There is an inherent tension: stricter compliance criteria shrink the association set, which degrades privacy. Conversely, larger sets offer better privacy but may include deposits whose compliance status is uncertain.

Blacklist Timing Gaps

There is an unavoidable delay between when illicit activity occurs and when an ASP flags the associated deposit. During this window, a bad actor can deposit and withdraw through a "clean" association set before their deposit is flagged. This is a fundamental limitation: no real-time classification system can eliminate this lag entirely.

Pressure Toward Whitelisting

Critics argue that if ASPs face regulatory liability for deposits they fail to flag, the system will inevitably shift from blacklisting (excluding known bad actors) to whitelisting (only including pre-approved, KYC-verified deposits). Whitelisting would fundamentally undermine the privacy promise by shrinking association sets to only identified users.

Early-Stage Technology

Privacy pools remain relatively new. The 0xbow implementation describes itself as "version zero" with future iterations planned. While the smart contracts have been audited, the broader ecosystem of ASPs, wallet integrations, and regulatory acceptance is still developing.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.