Search
Search for projects by name or address
Tornado Cash
About
A classic Ethereum mixer design based on fixed-denomination pools and zk withdrawals.
About
A classic Ethereum mixer design based on fixed-denomination pools and zk withdrawals.
Tornado Cash is a non-custodial mixer on Ethereum built around separate fixed-denomination pools, which prevents linking deposits and withdrawals via the amount. A deposit publishes a commitment into a Merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. producing a secret note, and a later withdrawal uses a zk-SNARKShort for "succinct non-interactive argument of knowledge", a SNARK is a widely used type of zero-knowledge proof that is short and fast to verify. Different kinds of SNARKs are usually systematized by proof size, verification time, and type of setup. The most famous SNARKs are Groth16, PLONK/Marlin, Bulletproofs, and STARKs. proof and the note to send the same denomination to a different address, breaking the deposit-withdrawal link. The note represents ownership of tokens in a Tornado cash pool, and losing it will effectively mean losing the tokens.
The core mixer contracts are immutable and have no admin, pause, or upgrade path, so funds can only move out with a valid proof. However Tornado cash features TORN token governance, which controls peripheral smart contracts: official pool registry, relayer registration requirement and TORN tokenomics.
Privacy considerations
Tornado cash introduces a permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. relayer networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes., which is essential for practical privacy. Relayers process withdrawals from Tornado cash pools on user’s behalf for a fee, which enables withdrawals to fresh addresses without funding them before the withdrawal. Without an active relayer network, practical privacy of Tornado cash deteriorates significantly.
Practical privacy also depends on the timing of deposits and withdrawals, underlying network and browser used to interact with Tornado cash frontend (if used), RPC providers used to send transactions and query public blockchain state. Users are advised to research OPSEC best practice.
Fees
The immutable Tornado Cash pools do not charge a protocol-level deposit or withdrawal fee. Withdrawals can include a relayer fee chosen offchain between the user and the relayer and passed to the pool withdrawal call.
Compliance
Tornado cash does not have any protocol-level compliance features. However, it provides an optional Compliance Tool, which allows users to generate a proof linking a withdrawal to a specific deposit without revealing this information publicly onchain. This enables users to selectively disclose the origin of funds to third parties, such as exchanges or regulators.
Protocol pools were sanctioned by OFAC in August 2022, flagging funds moved through these smart contracts as illicit and resulting in broad censorship (mainly by blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. builders) of transactions touching the contracts. Sanctions were lifted on March 21, 2025.
Anonymity setIn privacy protocols, anonymity set denotes all users, to which a particular withdrawal could be plausibly attributed. Anonymity set depends on a particular withdrawal, the size of the anonymity set is a metric for level of user's privacy.
A user’s anonymity set consists of all previous deposits into the same bucket (i.e. deposits of the same token and amount). Deposits can be mixed only with other deposits of the same token and denomination. To maximize the anonymity set, users are advised to deposit into the buckets with the most usage.
Secure frontend
For average users, the Tornado Cash frontend must be recognized as a critical part of the privacy protocol. If compromised, it can steal user assets and violate user privacy, which was exploited in 2024.
The frontend’s root of trust is the IPFS content hashA fixed-length fingerprint of variable-size input, produced by a hash function. registered for tornadocash.eth in the ENS smart contract on Ethereum. The latest hash can be fetched from a trusted ethereum nodeA software client that participates in the network. (e.g. your own or trusted light node rpc). There were incidents of malicious frontend hash updates passing onchain governance proposals before, so using a publicly audited or self-audited IPFS hash is advised. An example of an audit process with useful links can be found here or here. The frontend can then be accessed by running a local IPFS node that automatically fetches the verified frontend hash (e.g. dapp3.eth or kubo + ipfs-companion and serves it in the browser locally.
What the protocol promises: Hides which deposit funds which withdrawal. Everything else is public.
On public blockchains like Ethereum, all actions transparent by default. A privacy protocol can at best cut the link between addresses or offer privacy while deposited. The colour says whether a careful user can keep the link, amount or recipient private against that adversary: green yes, yellow only outside supported options or by accepting another leak, red no. Fields marked at risk stay private only under the condition in their note.
Each pool has one fixed amount and no in-pool transfers, so every withdrawal spends exactly one deposit.
Advice: Exit through a relayer, so no wallet of yours pays gas for the receiving address.
The candidates for a withdrawal are the unspent deposits of the same pool, the anonymity set, which differs sharply between pools. Timing, address reuse and relayer choice narrow it further. Paying gas from your own wallet instead of a relayer exposes that wallet's fingerprint, its account implementation and fee habits, even from a fresh address.
Advice: Use a pool with a large anonymity set. Deposit a large sum as one note. Wait before exiting and pick a different time of day than the deposit. Exit to a fresh address every time and spend from it with a different wallet than the one that deposited.
The app downloads all deposits and matches locally, so a node learns only which pool you looked at. The relayer receives only the finished withdrawal.
Advice: Read the chain from your own node, send through a public RPC over Tor, and use a popular relayer. If you settle for a VPN instead of Tor, pick one you trust: it hides your IP from the relayer but sees it itself.
The pools cannot be paused, upgraded or made to reveal anything. Governance controls only the website, the router and the relayer list.
Advice: Run an inspected local build of the client instead of the hosted frontend. Otherwise load it from its ENS name or IPFS hash.
Commitments use a Pedersen hash on an elliptic curve. A quantum computer could test whether a given deposit can fund a withdrawal, shrinking the candidate set without singling out one deposit. Notes backed up onchain are encrypted with elliptic-curve keys and become readable.
Advice: Use a pool with a large anonymity set. Keep the note on your device and skip the onchain backup.
30 day historic anonymity set
How many unique addresses you could have blended in with if you withdrew on a particular day after depositing during the previous 30 days. This metric is a proxy for the historic anonymity set and shows how it developed over time.
The metric looks backwards: it counts deposits that already happened, including from addresses that have since withdrawn. Your real anonymity also depends on deposits made after yours, which cannot be known in advance.
Estimated anonymity set by holding duration
An estimate of how many unique addresses you blend in with, depending on how long you leave your deposit in the pool. It is based on historic data of past deposits: each point counts depositors from the preceding period, so holding for up to 30 days effectively means blending in with everyone who deposited during the last 30 days.
Asset | Buckets | Deposits 7D | Deposits 30D | Deposits Total | Value Locked |
|---|---|---|---|---|---|
| 4 | 1.77 K $13.75 M | 8.63 K $100.23 M | 294.11 K $13.40 B | $658.14 M | |
| 4 | 5 $3.19 K | 75 $2.45 M | 9.64 K $474.78 M | $7.87 M | |
| 3 | 0 $0.00 | 2 $17.06 K | 2.40 K $535.43 M | $6.92 M | |
| 2 | 142 $132.99 K | 192 $166.78 K | 3.08 K $2.21 M | $40.18 K | |
| 2 | 1 $999.96 | 11 $7.39 K | 1.32 K $973.71 K | $31.58 K | |
| 4 | 0 $0.00 | 0 $0.00 | 324 $13.31 M | $25.31 K | |
| Total | 1.92 K $13.89 M | 8.91 K $102.88 M | 310.89 K $14.43 B | $673.03 M |
Funds can be stolen if
- the zk proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. is broken, allowing invalid withdrawals.
- the trusted setup is compromised or all ceremony participants collude, allowing invalid withdrawals.
Funds can be lost if
- a user loses the note secrets required to withdraw.
Privacy can be lost if
- no relayer is available and the withdrawal must be submitted from an address that can be linked to the user (see best practice page for more info).
Tornado cash has a TORN DAO, which does not have the authority to upgrade or modify existing pools in any way. However it controls a significant portion of the Tornado cash protocol and periphery, including:
- Default router for deposits and withdrawals and the official registry of supported pools. Malicious upgrades of these components could lead to users losing deposited tokens.
- Standard UI IPFS hashA fixed-length fingerprint of variable-size input, produced by a hash function. registered on ENS (link). Malicious upgrades of these components could lead to users losing deposited tokens.
- TORN token itself. Malicious upgrades of the token could lead to token transfers being frozen.
- Registered relayers. Malicious upgrades of these components could remove all registered relayers, disrupting user-relayer coordination and complicating private withdrawals.
Governance profile
Upgrades
| Normal upgrade path | Lock and optionally delegate TORN in the Governance contract → submit a proposal with at least 1.00 K TORN → wait 1m 15s → vote for 5d (extended by 6h if the outcome changes during the last 1h) → pass with a simple majority and 100.00 K TORN quorum → wait 2d → permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution within 3d. The DAO controls protocol and periphery components, but cannot upgrade or modify existing pools. |
|---|---|
| Exit window | 2d for DAO-controlled changes — an accepted proposal remains timelocked for this period before it can be executed. Existing Tornado Cash pools are immutable and cannot be upgraded by the DAO. |
Token governance
| Governance token |
|
|---|---|
| Stake lock | After voting or proposing, staked tokens are locked for 5d 6h after proposal ends, preventing governance hopping. |
| Voting venue | Governance contract on Ethereum. Proposals are viewable on the voting tab of the frontend, see the note on secure frontend above. |
| Proposal threshold | 1.00 K TORN locked in governance. |
| Quorum | 100.00 K TORN, with a simple majority required for acceptance. |
| Execution model | PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution after an onchain vote and timelock. An accepted proposal waits 2d and can then be executed by anyone within 3d. Proposal executable payload is committed in the |
Tornado Cash
Detailed description
CircuitA program written for the purpose of being proven within a proving system. A circuit is a mathematical representation of the computation to be executed, arithmetic circuits and zkVM execution trace are examples of circuits. Circuits can be written in different languages, ranging from low-level to high-level.-specific trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits. for Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. Tornado Cash circuits. It was publicly announced as a Phase 2For Groth16 trusted setup, phase 2 represents circuit-dependent part of the trusted setup. It generates a part of the secret cryptographic data required for Groth16 ZK protocol to work. If the outcome of phase 2 trusted setup ceremony is known, arbitrary proofs could be forged. ceremony built on top of the 30th contribution to the Perpetual Powers of Tau ceremony, and completed in May 2020. It collected 1114 contributions over 10 days, with 450 identified contributors and 664 anonymous ones. Tornado Cash published the participant list, archive of contributions and artifacts, and the generated verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract.
- Phase 1For Groth16 trusted setup, phase 1 represents circuit-independent part of the trusted setup (e.g. Perpetual Powers of Tau), which could be reused across different circuits. It generates a part of the secret cryptographic data required for Groth16 ZK protocol to work. If the outcome of phase 1 trusted setup ceremony is known, arbitrary proofs could be forged. ceremony (first 30 contributions are used): https://github.com/privacy-ethereum/perpetualpowersoftau.
- Ceremony completion announcement: https://tornado-cash.medium.com/the-biggest-trusted-setup-ceremony-in-the-world-3c6ab9c8fffa
- Ceremony page with participant list and archive download: https://ceremony.tornado.cash/
- Initial ceremony announcement: https://tornado-cash.medium.com/tornado-cash-trusted-setup-ceremony-b846e1e00be1
- Ceremony code repository: https://github.com/tornadocash/phase2-bn254
Verifier | Verification | Used in | Known deployments | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Tornado Cash verifier v2.1 | by | | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Verifier ID: Tornado Cash verifier 03.07.2026Known deployments Verification steps This regeneration attests that the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. smart contract verification keys correspond to circuits published in Tornado Cash release. Generally, to regenerate Tornado Cash verifier, the following has to be done:
Helper scripts that implement the flow above and more detailed explanations could be found in this script .zip archive. This .zip must be extracted in | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Ossification
Contracts our research team classifies as critical form the project's critical perimeter. Its clock starts at the ossification genesis, and every critical change resets it (changes within 24 hours count as one). The ossification score is the share of recorded code-bug exploits whose exploited code was younger than this perimeter is today. Battle-tested exposure is the value secured, summed over that unchanged period.
Discovery updates
2026 October 01, 10:49 UTC1changeProposal 69 (1,000 TORN to Mr Anon) was defeated (~163k for vs ~458k TORN against). The same proposer resubmitted it as proposal 70 (voting active, ends 2026-10-06) with a new verified Proposal contract (eth:0x04C2eb6Df3bF6032b8e07a03Fc9a5Ca424414483): 1,000 TORN split into 500 TORN to abusedotch and 500 TORN to JJ (Mr Anon's share, redirected as repayment). It only transfers TORN from governance, no protocol parameters or contracts are changed.
Proposal 69 (1,000 TORN to Mr Anon) was defeated (~163k for vs ~458k TORN against). The same proposer resubmitted it as proposal 70 (voting active, ends 2026-10-06) with a new verified Proposal contract (eth:0x04C2eb6Df3bF6032b8e07a03Fc9a5Ca424414483): 1,000 TORN split into 500 TORN to abusedotch and 500 TORN to JJ (Mr Anon’s share, redirected as repayment). It only transfers TORN from governance, no protocol parameters or contracts are changed.
| contract GovernanceProposalStateUpgrade (eth:0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce) [tornado-cash/GovernanceProposalStateUpgrade] { | |
| +++ description: Upgradeable Tornado Cash governance contract that manages proposals, voting, execution, and treasury-connected governance modules. If you trust this contract, you trust its upgrade path and proposal rules to change protocol governance behavior. | |
| values.proposalCount: | |
| - | 69 |
| + | 70 |
| } | |
2026 September 28, 10:54 UTC1changeNew proposal on DAO to reward Mr Anon with 1000 TORN for taking down fradulent tornado.cash frontend. This is a legit proposal that originates from Tornado Cash DAO tg channel.
New proposal on DAO to reward Mr Anon with 1000 TORN for taking down fradulent tornado.cash frontend. This is a legit proposal that originates from Tornado Cash DAO tg channel.
| contract GovernanceProposalStateUpgrade (eth:0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce) [tornado-cash/GovernanceProposalStateUpgrade] { | |
| +++ description: Upgradeable Tornado Cash governance contract that manages proposals, voting, execution, and treasury-connected governance modules. If you trust this contract, you trust its upgrade path and proposal rules to change protocol governance behavior. | |
| values.proposalCount: | |
| - | 68 |
| + | 69 |
| } | |
2026 August 21, 10:25 UTC1changeNew proposal to update DAO-controled tornado cash frontend: https://github.com/tornado-dao/classic-ui/compare/e312df5a4f6caaa7e93f1b5960c603d8dd7ec67a...17c54dae9ad91bb3c6d62a7860df6cd365ab76d4. It replaces RPC queries with Graph queries, sources proposal states from the onchain data, changes source link from Codeberg to GitHub and adds a phishing website notice board for tornado.cash. Sol verified that the published CID matches the changes.
New proposal to update DAO-controled tornado cash frontend: https://github.com/tornado-dao/classic-ui/compare/e312df5a4f6caaa7e93f1b5960c603d8dd7ec67a…17c54dae9ad91bb3c6d62a7860df6cd365ab76d4. It replaces RPC queries with Graph queries, sources proposal states from the onchain data, changes source link from Codeberg to GitHub and adds a phishing website notice board for tornado.cash.
Sol verified that the published CID matches the changes.
| contract GovernanceProposalStateUpgrade (eth:0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce) [tornado-cash/GovernanceProposalStateUpgrade] { | |
| +++ description: Upgradeable Tornado Cash governance contract that manages proposals, voting, execution, and treasury-connected governance modules. If you trust this contract, you trust its upgrade path and proposal rules to change protocol governance behavior. | |
| values.proposalCount: | |
| - | 67 |
| + | 68 |
| } | |
2026 July 03, 08:56 UTC4changesManually verified the Tornado Cash MiMC hasher against the pinned Tornado circomlib MiMC sponge generator and deployment bytecode.
Manually verified the Tornado Cash MiMC hasher against the pinned Tornado circomlib MiMC sponge generator and deployment bytecode.
New and verified contracts
| contract MiMCHasher (eth:0x83584f83f26aF4eDDA9CBe8C730bc87C364b28fe) [N/A] { | |
| +++ description: MiMC hasher used by newer Tornado pool generations for commitment-tree operations, manually verified against the pinned Tornado circomlib generator. | |
| unverified: | |
| - | true |
| description: | |
| - | "Unverified MiMC hasher used by newer Tornado pool generations for commitment-tree operations. If this contract were malicious or had a backdoor, all pools using it would be compromised." |
| + | "MiMC hasher used by newer Tornado pool generations for commitment-tree operations, manually verified against the pinned Tornado circomlib generator." |
| sourceHashes: | |
| + | ["0x96acbaf2288d4cc44cf8e9634da42d922960c005a6982e0b54a84823be2776f2"] |
| references: | |
| + | [{"text":"Tornado Cash hasher build script","href":"https://github.com/tornadocash/tornado-core/blob/master/scripts/compileHasher.js"},{"text":"Source Code","href":"https://github.com/tornadocash/circomlib/blob/c372f14d324d57339c88451834bf2824e73bbdbc/src/mimcsponge_gencontract.js"}] |
| } | |
2026 June 25, 12:44 UTC1changeNew proposal, (yet) unverified and malicious, see https://x.com/pcaversaccio/status/2070125180261896246 .
New proposal, (yet) unverified and malicious, see https://x.com/pcaversaccio/status/2070125180261896246 .
| contract GovernanceProposalStateUpgrade (eth:0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce) [tornado-cash/GovernanceProposalStateUpgrade] { | |
| +++ description: Upgradeable Tornado Cash governance contract that manages proposals, voting, execution, and treasury-connected governance modules. If you trust this contract, you trust its upgrade path and proposal rules to change protocol governance behavior. | |
| values.proposalCount: | |
| - | 66 |
| + | 67 |
| } | |
Ethereum
Actors:
Upgradeable Tornado Cash governance contract that manages proposals, voting, execution, and treasury-connected governance modules. If you trust this contract, you trust its upgrade path and proposal rules to change protocol governance behavior. Member of GnosisSafe.
- Can upgrade with no delay
- TornadoTreesV2
- RelayerRegistry
- TornadoStakingRewards
- GovernanceProposalStateUpgrade
- FeeManager
- InstanceRegistry
- Can interact with TornadoTreesV2
- replace the proxy allowed to enqueue deposit and withdrawal leaves
- replace the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. used for batched tree updates
- Can interact with RelayerRegistry
- change the router address allowed to burn relayer stake during withdrawals
- nullify a registered relayer’s staked balance
- set the minimum TORN stake required to become a relayer
- Can interact with TornadoStakingRewards
- update user reward accounting when locked balances change
- withdraw TORN held by the staking rewards contract
- Can interact with FeeManager
- change how long cached per-instance fees remain valid before they must be recomputed
- change the TWAP lookback period used to price Tornado instances
- change the Uniswap fee tier used for the TORN price source
- Can interact with TornadoProxyV2
- add or update supported pool instances
- replace the connected Tornado Trees contract
- rescue tokens sent to the proxy
- Can interact with Miner
- change the reward-swap pool weight used when distributing TORN rewards
- replace the connected Tornado Trees contract
- replace the reward, withdrawal, and tree-update verifiers
- set mining reward rates
- Can interact with TORN
- manage the allowlist of addresses that can transfer while TORN is paused
- pause or unpause TORN transfers after the initial pause period expires
- rescue arbitrary tokens held by the TORN contract
- Can interact with TornadoProxyV1
- enable or disable supported pool instances
- rescue tokens sent to the proxy
- Can interact with InstanceRegistry
- add or update supported Tornado instances and their enabled/disabled state
- change the router contract allowed to interact with registered instances
- remove supported instances from the registry
- set per-instance protocol fees charged to relayers
- Can interact with TornadoRouter
- rescue tokens sent to the router
A Multisig with 1/1 threshold.
Participants (1):
GovernanceProposalStateUpgrade
Ethereum
Fixed-denomination Tornado Cash pool for 50K cDAI deposits.
Fixed-denomination Tornado Cash pool for 10K DAI deposits.
Fixed-denomination Tornado Cash pool for 1000 USDT deposits.
Fixed-denomination Tornado Cash pool for 0.1 ETH deposits.
Fixed-denomination Tornado Cash pool for 100 USDT deposits.
Fixed-denomination Tornado Cash pool for 0.1 WBTC deposits.
Fixed-denomination Tornado Cash pool for 5K cDAI deposits.
Fixed-denomination Tornado Cash pool for 100K DAI deposits.
Fixed-denomination Tornado Cash pool for 500K cDAI deposits.
Fixed-denomination Tornado Cash pool for 1000 USDC deposits.
Fixed-denomination Tornado Cash pool for 1 ETH deposits.
Upgradeable registry that tracks registered relayers, their worker addresses, and their staked TORN balances used to service withdrawals. Relayers registered here could be queried by a tornadocash frontend to facilitate discovery for users, but users are free to use any (unregistered) relayer at withdrawal time.
- Roles:
- admin: GovernanceProposalStateUpgrade
- governance: GovernanceProposalStateUpgrade
Upgradeable fee manager that derives relayer burn fees for each Tornado instance from registry settings and Uniswap TWAP data.
- Roles:
- admin: GovernanceProposalStateUpgrade
- governance: GovernanceProposalStateUpgrade
Fixed-denomination Tornado Cash pool for 1 WBTC deposits.
MiMC hasher used by every Tornado pool for commitment-tree operations (linked library in the 2019 pools, constructor argument in the 2021 pools), manually verified against the pinned Tornado circomlib generator.
Fixed-denomination Tornado Cash pool for 10 ETH deposits.
Fixed-denomination Tornado Cash pool for 100 ETH deposits.
Upgradeable registry of supported Tornado Cash pool instances and their mutable per-instance fee and routing configuration.
- Roles:
- admin: GovernanceProposalStateUpgrade
- governance: GovernanceProposalStateUpgrade
Fixed-denomination Tornado Cash pool for 10 WBTC deposits.
Fixed-denomination Tornado Cash pool for 5M cDAI deposits.
Fixed-denomination Tornado Cash pool for 100 DAI deposits.
Router contract that validates supported instances, forwards deposits and withdrawals, and subtracts from relayer stake through the relayer registry during withdrawals.
- Roles:
- governance: GovernanceProposalStateUpgrade
Fixed-denomination Tornado Cash pool for 100 USDC deposits.
Fixed-denomination Tornado Cash pool for 1000 DAI deposits.
Staking contract that escrows TORN staked by relayers. With time, their stake is subtracted from for being officially registered as relayers and receiving fees from each withdrawal, and is redirected as TORN rewards for governance participants who are locking their TORN for voting/staking.
- Roles:
- admin: GovernanceProposalStateUpgrade
- governance: GovernanceProposalStateUpgrade
TORN governance token contract. Transfers start paused and can later be toggled by governance, which also controls the paused-transfer allowlist and token rescue functions.
- Roles:
- governance: GovernanceProposalStateUpgrade
Anonymity Mining - VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for Tornado anonymity-mining withdrawal proofs.
Anonymity Mining - Legacy Tornado Trees contract that records deposit and withdrawal leaves from TornadoProxyV1 and maintains the roots later consumed by migration and mining logic.
Anonymity Mining - Upgradeable batch-based Tornado Trees contract that reuses legacy tree state, queues new leaves from the newer proxy, and accepts batched root updates proven by a verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover..
- Roles:
- admin: GovernanceProposalStateUpgrade
- governance: GovernanceProposalStateUpgrade
Anonymity Mining - Liquidity schedule that pays out TORN rewards for anonymity mining. Only the Miner contract can draw from it or adjust the reward weight.
Anonymity Mining - VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for Tornado mining account-tree update proofs.
Anonymity Mining - Newer immutable Tornado proxy that routes deposits and withdrawals to supported pool instances and records them in the upgraded Tornado Trees contract.
- Roles:
- governance: GovernanceProposalStateUpgrade
Anonymity Mining - Mining and reward-distribution contract for Tornado anonymity mining. It verifies reward and withdrawal proofs, maintains account roots, and routes TORN rewards through the swap contract.
- Roles:
- governance: GovernanceProposalStateUpgrade
Anonymity Mining - VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for Tornado anonymity-mining reward proofs.
Anonymity Mining - Legacy immutable Tornado proxy that routes deposits and withdrawals to pool instances and records them in the legacy Tornado Trees contract.
- Roles:
- governance: GovernanceProposalStateUpgrade
Anonymity Mining - Unverified Poseidon hasher used by the legacy Tornado Trees merkle trees. The source code of this contract is not verified on Etherscan.
Anonymity Mining - VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for batched Tornado Trees root updates.
Vault that escrows locked TORN of governance participants who wish to receive voting rights.
Unverified merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. instance that stores legacy Tornado deposit leaves for TornadoTreesV1. The source code of this contract is not verified on Etherscan.
Unverified merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. instance that stores legacy Tornado withdrawal leaves for TornadoTreesV1. The source code of this contract is not verified on Etherscan.
Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract used by Tornado Cash pool withdrawal proofs.
Vault that escrows ETH for governance gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources.-compensation payouts and can return unused funds to governance.
The current deployment carries some associated risks:
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).