Tornado cash

Tornado cash is an Ethereum privacy protocol using zk-SNARKs

Tornado cash is a privacy tool on Ethereum that hides the direct trail between a deposit and withdrawal using zero-knowledge proofs, which verify ownership without exposing the deposit itself. Its classic pools accept fixed denominations and release the same asset to another address after a valid zk-SNARK proves control of an unspent private note.

The contracts remain accessible on-chain, while interfaces, relayers, pool participation and legal treatment have changed around them. The sections below separate fixed protocol rules from conditions that shift with Ethereum activity.

Each classic ETH denomination has its own pool, so crowd size matters within 0.1, 1, 10 and 100 ETH groups.

Sanctions removal changed access, not the contracts

U.S. Treasury removed the economic sanctions against Tornado cash on March 21, 2025, while the deployed Ethereum bytecode remained unchanged. The contracts had continued accepting correctly formed calls during the 2022 designation because blockchains don't pause code when websites or policies change. Delisting removed the protocol and listed contract addresses from that sanctions program. It didn't guarantee access through every wallet, RPC provider, relayer or centralized exchange. Those services set separate policies, and rules outside the United States follow their own frameworks (examined in practice ).

What does a Tornado cash transaction cost?

A classic Tornado cash pool charges no protocol percentage fee, so network gas creates the mandatory transaction cost. Depositing requires one Ethereum transaction. Withdrawing requires another. A user who submits the withdrawal directly pays its gas from the submitting address, while a relayer advances that gas and deducts its quoted fee from the withdrawn denomination.

The contract fixes an important boundary: the relayer fee can't exceed the pool denomination. Its exact amount isn't fixed because the relayer incorporates Ethereum's base fee, priority fee, the withdrawal's gas use and a service margin. Classic contracts don't create swap slippage because they return the same asset and denomination. ERC-20 deposits add a token approval transaction before the deposit call, so that path normally consumes three on-chain transactions from approval through withdrawal. Nova uses a different balance model on Gnosis Chain, so its cost path shouldn't be substituted for a classic fixed pool.

Fixed denominations shape the anonymity set

Fixed denominations place every classic deposit into a pool containing equal-sized commitments. That design removes exact amount as a distinguishing feature inside one contract. It also means a depositor can't choose an arbitrary value or withdraw a classic note in pieces.

Ethereum's ETH menu contains four pools: 0.1 ETH, 1 ETH, 10 ETH and 100 ETH. DAI likewise has 100, 1 000, 10 000 and 100 000 token denominations. That structure prevents amount matching inside a pool: every withdrawal equals a prior deposit minus any relayer fee. It also fragments participation, because the 1 ETH contract and the 10 ETH contract maintain separate commitment trees. A large deposit count across the protocol therefore says less than the population inside the chosen asset-denomination contract.

Pool menus by asset

Other Ethereum deployments expose narrower menus. USDC and USDT each use 100 and 1 000 token pools. WBTC uses 0.1, 1 and 10 WBTC, while cDAI uses 5 000, 50 000, 500 000 and 5 000 000 cDAI. Compound's cDAI is an interest-bearing ERC-20 rather than ordinary DAI, so the denomination unit and redemption behavior differ. Each amount maps to a separate contract address, which a wallet interface should resolve before signing.

Asset and denomination

Choose the contract by chain, token contract and exact denomination. An ETH pool accepts native ETH, while DAI, USDC, USDT, WBTC and cDAI pools call ERC-20 transfer logic. A similarly named asset on another network isn't interchangeable with the Ethereum token.

Timing and crowd size

Equal amounts remove one obvious link, yet timing still narrows the plausible set. A withdrawal made soon after a quiet pool receives one deposit has fewer plausible predecessors than a withdrawal after many commitments accumulate. The tree's lifetime capacity doesn't describe the live anonymity set.

The private note is the withdrawal credential

The classic private note is the sole credential that authorizes one later withdrawal. The interface generates it locally. Losing the note makes the funds unrecoverable because no account reset exists.

  1. Select the correct chain, asset and fixed denomination.
  2. Connect a compatible wallet such as MetaMask and approve the ERC-20 when required.
  3. Submit the deposit and save the complete note offline.
  4. Let unrelated commitments accumulate in the same pool.
  5. Withdraw to another address directly or through a relayer.

The note encodes a 31-byte nullifier and a 31-byte secret, producing a 62-byte preimage represented by 124 hexadecimal characters. The software hashes that preimage into the public commitment. The deposit transaction publishes the commitment, denomination and sender address, but it doesn't publish the note. At withdrawal, the proof reveals a hash of the nullifier without revealing the secret or commitment leaf. A complete note also includes the asset, amount and network identifier, so copying only its hexadecimal tail strips away context that recovery software needs.

An interface is replaceable; the credential isn't. A compatible client can reconstruct events from Ethereum and generate the same proof if it has the intact note and circuit files.

Address separation is the primary use case

Tornado cash separates public wallet histories when the deposit and recipient serve different on-chain roles. An individual might separate a public donation address from a savings address. A DAO contributor could receive funds into an operating address without publishing which prior account funded it. A project treasury could avoid broadcasting a direct transfer path between working wallets. These scenarios still require off-chain tax, accounting and contractual records.

Classic pools fit one-time transfers of fixed amounts. Tornado cash Nova uses an account-style pool on Gnosis Chain for arbitrary amounts and shielded transfers inside the pool, which changes both the credential model and the transaction path. Deployments have also appeared on Polygon, Avalanche, Optimism, Arbitrum One and BNB Smart Chain. Those networks maintain separate contract addresses, native assets and transaction histories. The core use case stays narrow: break an observable address-to-address link without handing custody to a central intermediary.

Overlapping gold and silver cryptocurrency coins
Overlapping gold and silver cryptocurrency coins.

Pool population sets the privacy ceiling

A Tornado cash anonymity set consists of plausible deposits within one specific pool. Equal denominations stop observers from matching a unique amount, but token, chain, contract and timing remain public. Ten commitments don't automatically create ten equally plausible sources when surrounding activity distinguishes several of them.

A 20-level binary Merkle tree holds at most 1 048 576 commitment leaves. The classic contract also retains 30 recent Merkle roots for withdrawal verification. Those constants provide capacity and proof freshness, not a privacy score. Anonymity strengthens when unrelated deposits share the same denomination and withdrawals occur across a broad time window. It weakens when the recipient is funded from the deposit address, when amounts get recombined into a distinctive total or when a centralized service already knows both endpoints. Repeated timing patterns narrow the credible set further.

Relayers separate gas payment from the recipient

Relayers submit withdrawal proofs so a fresh recipient address doesn't need ETH for gas. The proof binds six public inputs: the Merkle root, nullifier hash, recipient, relayer, fee and refund. Because the recipient and fee sit inside the proof, a relayer can't redirect the withdrawal or enlarge its payment after generation. A direct withdrawal remains possible through any funded transaction sender. Relayer availability and quotes change over time, so the fixed contract rule matters most: the fee must stay at or below the denomination.

How do zk-SNARKs unlink deposits and withdrawals?

Even so, Tornado cash uses a zk-SNARK to prove note ownership without identifying the commitment being spent. The verifier accepts a proof only when its private inputs satisfy the public root and nullifier conditions. That compact verification moves the expensive witness construction off-chain while Ethereum enforces the spending rule on-chain.

Commitment construction

Anything left over is addressed in Using Tornado cash. At deposit, the client concatenates the 31-byte nullifier and 31-byte secret, then applies a Pedersen hash to produce a commitment. The contract appends that commitment to a MiMC-based Merkle tree. With 20 levels, each inclusion path contains 20 sibling hashes and 20 direction bits. The original circuit uses Groth16, which produces a succinct proof after the client builds a witness from the private note and Merkle path. The deposit's sender address remains visible, but the commitment doesn't encode that address.

Withdrawal verification

At withdrawal, the client selects a known root, computes a hash of the nullifier and generates proof constraints for the chosen recipient. The Solidity verifier checks the Groth16 proof against six public values. If the root appears in the 30-entry history and the nullifier hash remains unspent, the contract marks that hash as spent and transfers funds. One note authorizes one withdrawal. This state transition prevents a second valid use of the same note without revealing which leaf supplied the witness.

Governance through TORN

TORN gives token holders on-chain control over selected governance contracts and protocol parameters. It follows ERC-20 and has a fixed supply of 10 000 000 tokens. Governance doesn't rewrite immutable classic pool bytecode; it controls components that expose governance functions, including registries, rewards and treasury actions.

The initial allocation assigned 5% or 500 000 TORN to early-user vouchers, 10% or 1 000 000 to anonymity mining, 55% or 5 500 000 to the DAO treasury and 30% or 3 000 000 to founding developers and early supporters. The distribution schedules also used fixed windows: one year for mining, five years with a three-month cliff for the treasury and three years with a one-year cliff for the final allocation. These figures describe token construction, not current voting participation or market value.

Alternatives across Ethereum, Bitcoin and privacy chains

Privacy alternatives differ mainly by settlement layer, asset model and the information each transaction exposes. Zcash and Monero integrate privacy into their Layer 1 protocols. RAILGUN adds shielded balances through EVM smart contracts. Wasabi Wallet and JoinMarket organize Bitcoin CoinJoin transactions, where multiple participants create one transaction rather than using a deposit-note pool.

Option Settlement network Privacy mechanism Security tier
RAILGUN Ethereum and EVM networks Shielded UTXO ledger with zero-knowledge proofs Smart-contract layer
Zcash Zcash Orchard shielded pool with Halo 2 Layer 1 protocol
Monero Monero RingCT, stealth addresses and Bulletproofs+ Layer 1 protocol
Wasabi Wallet Bitcoin WabiSabi CoinJoin coordination Wallet layer
JoinMarket Bitcoin Peer-to-peer CoinJoin market Application layer

The table's security tier describes where the privacy rules execute, not a quality ranking. Layer 1 designs protect transfers within their native chains, while application protocols inherit Bitcoin or Ethereum settlement plus their own coordination or contract assumptions. RAILGUN suits EVM assets and private DeFi activity. Zcash and Monero require their native transaction formats. Wasabi Wallet and JoinMarket stay within Bitcoin's UTXO model. Asset support, custody model and counterparty workflow should drive the choice before interface familiarity.

Who should weigh the trade-offs most carefully?

Users who need regulated exchange access, formal audit trails or reliable account recovery face the sharpest trade-offs. A destination exchange may request transaction history beyond what its deposit screen shows. Institutions also need internal authorization records, while a private-note system offers no password reset.

Three mechanism-specific exposures deserve attention. First, loss or partial copying of the 124-character hexadecimal note blocks withdrawal. Second, address funding, timing and later asset recombination can reconnect activity that the zk-SNARK separated. Third, immutable contracts preserve their programmed behavior even when interfaces, relayers or legal treatment change. Smart-contract audits by ABDK Consulting covered the original protocol, circuit and cryptography, but an audit doesn't evaluate a user's metadata choices or a third-party client. Operational security therefore spans the contract, proof files, wallet and record-keeping process.

Anyone proceeding needs a verified contract address, the correct network, sufficient gas for required transactions and a durable offline copy of the full note. Those controls address the actual failure points. Privacy strength then comes from the chosen pool's crowd and the separation maintained after withdrawal.

Still wondering about Tornado cash?

Does a Tornado cash note expire?

No, a classic Tornado cash note doesn't contain a time-based expiry. Its commitment remains in the pool's Merkle tree after later deposits change the root. A compatible client reconstructs a current path and proves membership against a root that the contract still recognizes. The withdrawal fails only when the nullifier is already marked spent, the proof uses an unknown root or the saved note is incomplete. Waiting changes privacy conditions, not ownership.

Do I need TORN to make a deposit or withdrawal?

No, TORN isn't required for a classic deposit, proof or withdrawal. The pool accepts its configured asset, such as ETH, DAI or WBTC, while the transaction sender separately pays network gas. TORN serves governance: holders lock it to vote or participate in proposals. A relayer receives its fee from the withdrawn denomination when chosen. Holding TORN neither enlarges the anonymity set nor changes the zero-knowledge circuit.

What happens when a Merkle root leaves the 30-root history?

An unspent note remains usable after its old root leaves the contract's 30-entry history. The client rebuilds the Merkle tree from deposit events, creates a fresh inclusion path and generates the proof against a newer recognized root containing the same commitment. The root history limits which proof snapshots the verifier accepts, not how long the underlying leaf exists. A stale precomputed proof must therefore be generated again before submission.

When is an ERC-20 approval required for Tornado cash?

An ERC-20 approval is required before a token pool can pull its fixed denomination from the depositor's wallet. Native ETH uses payable value and skips that approval. DAI, USDC, USDT, WBTC and cDAI follow the token path on Ethereum. Approving exactly one denomination leaves zero unused allowance after transferFrom consumes it. A broader allowance remains recorded until later spending or an on-chain allowance change.

Where can a user check whether a Tornado cash note was spent?

A compatible client checks note status by deriving the nullifier hash and calling the pool contract's isSpent function. Etherscan also exposes verified contract read methods when the correct chain and pool address are selected. The complete 62-byte secret preimage isn't needed for a public spent-status lookup once the nullifier hash is known. Status belongs to one contract, so checking a different denomination or network returns the wrong context.