tornado.cash
Docs ↗
Launch app ↗
TORNADO.CASH / TORNADO CASH WHITEPAPER
Tornado Cash is a decentralized protocol for private transactions on public blockchains. It separates the visible relationship between a deposit address and a later recipient by combining immutable smart-contract pools with zero-knowledge proofs.
Tornado Cash Whitepaper: The protocol implementation includes smart contracts, circuits, proof tooling, and interface code. Source repositories explain how commitments are inserted, proofs are constructed, nullifiers are checked, and withdrawals are executed.
The protocol accepts a commitment from one address and later verifies a proof for a recipient. The private note connects those actions for the user, but the note itself is not published on-chain.
The browser generates secret values and derives a private note. The asset and a hash of that note are submitted to a fixed-denomination pool.
commitmentHashsecret + nullifierAs more equal-value commitments enter the pool, obvious timing relationships become less useful. Privacy still depends on careful user behavior and network metadata.
The client proves that a valid, unspent commitment exists in the Merkle tree. The contract verifies the proof and transfers funds to the chosen recipient.
root + nullifierHashdeposit path + secretsA public blockchain normally exposes a direct transaction path. Tornado Cash changes that path: the source publishes a commitment, while the destination later presents a proof that is valid for the shared pool.
The note contains the secret material needed to create a proof. It should be stored like a private key and never shared.
The contract records a commitment in a Merkle tree rather than storing the user’s secret note.
A public nullifier hash marks the note as spent without revealing which commitment generated it.
Recipient and relayer parameters are included in the proof inputs to protect the withdrawal from substitution.
Tornado Cash contracts evaluate cryptographic facts. They do not need to learn the private note, maintain a customer balance sheet, or select which valid recipient receives a withdrawal.
Read the protocol documentation ↗A hash derived from the secret and nullifier is inserted as a leaf in the pool’s Merkle tree.
H(secret, nullifier)
The client reconstructs the tree and proves that its commitment belongs to an accepted root.
leaf ∈ root
The contract rejects a nullifier hash that has already been used, preventing a second withdrawal.
spent[nHash] == false
The verifier checks the proof and the pool sends the fixed amount to the bound recipient.
verifyProof() → true
Classic pools group equal denominations. Deposits generate notes that are later used to construct a withdrawal proof for a selected recipient.
Nova introduces arbitrary values and transfers that can remain inside the shielded pool, using a different account and transaction model.
Control is represented by secret information held by the user, not an account controlled by a service operator.
Contracts, circuits, proof tooling, and interface code can be reviewed and independently hosted.
Deployed pool contracts execute according to their bytecode rather than depending on the original developers.
Governance proposals and TORN voting operate on-chain and remain separate from user note custody.
These answers describe the core design. Privacy is not automatic: users must also consider timing, address reuse, browser state, RPC providers, and applicable law.
The pool contract receives the asset and a commitment derived from secret values. The private note stays with the user and is required to construct the withdrawal proof. The protocol does not keep a conventional account password or recovery database.
Waiting allows other equal-value deposits to enter the same pool and reduces obvious timing correlations. Waiting alone is not a guarantee of privacy; address reuse, browser data, network metadata, and withdrawal behavior also matter.
It establishes that the withdrawer knows secret values corresponding to a commitment included in an accepted Merkle root and that the associated nullifier has not been used before. The secrets themselves are not published on-chain.
A relayer can submit the withdrawal transaction and pay gas on behalf of the recipient. This lets a new recipient address receive funds without first being funded from another address, while the proof binds the requested recipient and fee.
Review the documentation, verify the contracts, protect the note, and understand the privacy assumptions before interacting.