DeFiPunk'd

Tornado Cash

Privacy

TVL $771.5M
Type Privacy
Chains Ethereum, Binance, Arbitrum, Avalanche, Polygon +3
View on DeFiLlama ↗
Control criteria
Upgradeability Mixed Bug bounty — Governance forum tornadocash.community Docs docs.tornado.cash
About

Tornado Cash is a non-custodial, zkSNARK-based cryptocurrency privacy protocol deployed across multiple EVM chains. Users deposit fixed denominations of ETH or ERC-20 tokens (or arbitrary amounts via Tornado Cash Nova on Gnosis Chain) and later withdraw to a fresh address with no on-chain link to the deposit, using zero-knowledge proofs to preserve privacy. The core pool contracts are immutable and cannot be upgraded or paused by anyone; peripheral contracts (router, relayer registry, fee manager, instance registry, staking rewards) are upgradeable and governed by the TORN-token DAO. The protocol was sanctioned by the US Treasury in August 2022 but those sanctions were partially overturned by a US federal appeals court in November 2024.

Risk analysis

One card per dimension, sorted by severity. Only Verifiability and Autonomy carry automated signals in Phase 0. See methodology for scope.

Audit a dimension yourself · DEFI@home Contribute an LLM-run assessment — any model, any dimension. Three agreeing runs merge automatically into the public record.

DEFI@home is a distributed audit network modeled on SETI@home: instead of CPU cycles, it crowdsources LLM reasoning. Paste a slice prompt into Claude, ChatGPT, Gemini, or any browsing-capable model, and submit the JSON output as a pull request. The quorum bot merges it once ≥3 independent runs (from different models) reach the same grade — no single model, and no single contributor, can move the needle alone. How it works →

  • Address discovery 24 addresses on file · 1 run Submit run ↗
  • Verifiability Unverified Submit run ↗
  • Control 2/3 submitted Submit run ↗
  • Ability to exit 2/3 submitted Submit run ↗
  • Autonomy 2/3 submitted Submit run ↗
  • Open Access Submit run ↗
  • Audit all 5 dimensions · one prompt Submit run ↗
  1. Verifiability tentative
    Open source + 13 audits

    Protocol publishes a GitHub repository and has at least one audit on record. This is a coarse Phase-0 signal only: auditor reputation, scope, and post-audit review coverage are not yet weighted.

    Run your own prompt Submit run ↗
  2. Control 2/3 models submitted
    Core pool and governance control surfaces are visible, but live admin/operator reads were not determinable
    Tentative grades
    • gpt-5.5 unknown
    • gemini-3-flash-preview orange

    No quorum yet — verdict and steelman hidden until ≥3 models agree.

    Evidence (9)
    C1
    The representative Ethereum 100 ETH pool is a verified TornadoCash_eth contract exposing an operator() view plus changeOperator(address) and updateVerifier(address); the current operator value was not available from the fetched explorer text.
    C2
    The Tornado governance contract at 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce is shown by Etherscan as a proxy with current implementation 0xbf46f2222c0712cAF2f13B8590732DbD964ce395 and a recorded proxy-upgrade history.
    C3
    The current governance implementation ABI exposes propose, castVote, execute, state, timing-constant getters, and configuration setters; execute(uint256) delegates execution to the proposal target's executeProposal() path.
    C7
    The representative pool's withdraw path depends on verifier.verifyProof, while updateVerifier(address) is operator-gated; if operator is nonzero and controlled, that path is potentially fund-critical, but the live operator could not be read.
    C1
    The core mixer contracts (e.g., the 0.1 ETH pool at 0x47E0f3B3... and the Router at 0x12D66f87...) are immutable and have no owner or admin role capable of modifying logic or extracting funds. However, the Governance contract at 0x5efda50f... is a proxy that controls the protocol treasury and its own staking logic.
    C2
    The Governance contract is a transparent proxy (0x5efda50f...) whose admin is itself. This allows governance to upgrade its own logic, including the rules for voting and the handling of staked TORN tokens.
    C3
    The execution path for a proposal is: Voting (17,280 blocks ≈ 2.4 days) followed by a Timelock delay (172,800 seconds = 2 days). The total uncontested fast path is approximately 4.4 days.
    C5
    On-chain governance constants read from 0x5efda50f...: PROPOSAL_THRESHOLD = 1,000 TORN (1e21), VOTING_PERIOD = 17,280 blocks, and EXECUTION_DELAY = 172,800 seconds.
    C7
    The protocol reaches T1 (Fund-Critical) because the Governance contract holds user-staked TORN and is upgradeable via the 4.4-day path. While the ETH in the mixers is unreachable (T1-exempt), the staked TORN and the protocol treasury (T2) are within the blast radius of a governance takeover, as demonstrated in the May 2023 attack.
    Why is this slice uncertain?
    • only 2 of 3 model submissions on record — quorum requires ≥3 agreeing models
    • submitted models do not yet agree on a single grade

    A fresh independent run can establish (or overturn) a verdict.

    Run your own prompt Submit run ↗
    Sources gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗
  3. Ability to exit 2/3 models submitted
    Classic pools expose on-chain withdraw, but full protocol exit coverage is unresolved
    Tentative grades
    • gpt-5.5 unknown
    • gemini-3-flash-preview green

    No quorum yet — verdict and steelman hidden until ≥3 models agree.

    Evidence (14)
    E1
    The inspected Ethereum classic ETH pool exposes a user-facing `withdraw(bytes,bytes32,bytes32,address,address,uint256,uint256)` exit function; I did not complete enumeration for Tornado Cash Nova, ERC20 pools, or all non-Ethereum deployments.
    E2
    In the inspected classic ETH source, `withdraw` is `external payable nonReentrant` and checks fee, nullifier, known Merkle root, and verifier proof before calling internal `_processWithdraw`; no `onlyOperator`, `whenNotPaused`, or role pause guard appears on `withdraw`.
    E3
    The inspected classic ETH source has no pause guard on `withdraw`, but it does define an `operator` with `onlyOperator` authority to call `updateVerifier`; Etherscan shows constructor operator `0x8589427373D6D84E98730D7795D8f6f8731FDA16`, but I could not verify the current mutable operator value.
    E4
    No separate emergency/governance pause path was visible in the inspected classic ETH source; the only privileged path found there is the operator-controlled verifier update.
    E5
    The inspected classic ETH source has no queued redemption, daily withdrawal cap, request/claim split, or queue pause; `withdraw` verifies the proof and immediately calls `_processWithdraw`.
    E6
    The inspected classic ETH source does not show a separate forced-exit or emergency escape hatch; the normal exit path depends on successful verification by the current verifier.
    E7
    The inspected Etherscan pages expose contract source/ABI and Read/Write Contract tabs, and the ABI includes `withdraw`, supporting direct on-chain invocation without the project frontend for the checked Ethereum classic pools.
    E1
    The primary user-facing exit function is 'withdraw', which is present in all core pool contracts (e.g., 0.1 ETH, 1 ETH, etc.) [Evidence 0, 1].
    E2
    The 'withdraw' function in the core pool contracts has no access modifiers (like 'onlyOwner') and no pause guards (like 'whenNotPaused'), allowing any user with a valid ZK-proof to call it [Evidence 1].
    E3
    There is no pause functionality or PAUSE_ROLE defined in the core pool contracts; the contracts are immutable and do not inherit from any pausable or ownable logic [Evidence 0, 1].
    E4
    No emergency or governance-controlled pause paths exist for the core pools; the logic is hardcoded and cannot be altered by the DAO or the original developers [Evidence 1, 2].
    E5
    The protocol does not use a withdrawal queue or daily caps; withdrawals are processed instantly upon the submission of a valid ZK-proof [Evidence 1].
    E6
    The 'withdraw' function itself serves as a permissionless escape hatch, as it requires only a cryptographic proof of a prior deposit and does not rely on any external administrative state [Evidence 1, 2].
    E7
    The 'withdraw' function is directly callable on-chain via the 'Write Contract' tab on block explorers like Etherscan, ensuring users can exit even if all frontends are unavailable [Evidence 0].
    Why is this slice uncertain?
    • only 2 of 3 model submissions on record — quorum requires ≥3 agreeing models
    • submitted models do not yet agree on a single grade

    A fresh independent run can establish (or overturn) a verdict.

    Run your own prompt Submit run ↗
    Sources gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗
  4. Autonomy 2/3 models submitted
    Nova's OmniBridge path can lose or freeze <0.01% TVS; classic pools are mostly self-contained.
    Tentative grades
    • gpt-5.5 orange
    • gemini-3-flash-preview green

    No quorum yet — verdict and steelman hidden until ≥3 models agree.

    Evidence (14)
    A1
    Classic fixed pools have no oracle or price-feed calls: withdrawals check a protocol verifier and Merkle root, ETH pools only transfer ETH, and ERC20 pools call the selected token contract for transferFrom/transfer. Ethereum ERC20 pool token dependencies inspected were DAI 0x6B175474E89094C44Da98b954EedeAC495271d0F, cDAI 0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643, USDC 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48, USDT 0xdAC17F958D2ee523a2206206994597C13D831ec7, and WBTC 0x2260FAC5E5542a773Aa44fBCfeDf7C193bc2C599; failures are isolated to users of those asset pools.
    A1
    Nova's configured external/protocol-adjacent calls are Gnosis WETH 0x6a023ccd1ff6f2045c3309768ead9e68f978f6e1, Gnosis OmniBridge 0xf6a78083ca3e2a662d6dd1703c939c8ace2e268d, L1 Unwrapper 0x3F615bA21Bc6Cc5D4a6D798c5950cc5c42937fbd, Ethereum OmniBridge 0x88ad09518695c6c3712AC10a214bE5109a655671, and Ethereum WETH 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2; L1 deposit and L1 withdrawal flows depend on those bridge/token contracts.
    A2
    No oracle/reporter committee was found for classic pools; Nova relies on OmniBridge/AMB messages for L1-to-L2 deposits and cross-chain governance upgrades, so bridge message mis-reporting could cause bridged deposits or upgrades to execute incorrectly.
    A3
    Nova is the only inspected module with a material bridge call path: its README states it uses an ETH(mainnet) to WETH(xDai) bridge, and TornadoPool's withdrawal path sends tokens to the configured OmniBridge when isL1Withdrawal is true.
    A4
    No restaking or receipt-of-receipt collateral chain was found. Classic ERC20 pools and Nova's bridged WETH are opt-in isolated assets; a DAI, USDC, USDT, WBTC, cDAI, or bridged-WETH failure propagates only to users in that asset/module, not to ETH fixed pools.
    A6
    Classic pools have no oracle fallback because they do not price assets. Nova has a live-code fallback for failed bridged deposit processing that transfers the sent amount to the configured multisig, but that does not mitigate OmniBridge compromise or bridge liveness failure.
    A7
    Ethereum classic pools have no additional sequencer dependency beyond Ethereum substrate. Optimism and Arbitrum fixed-pool deployments inherit their rollup liveness, but the Tornado fixed-pool contracts inspected do not call L1 bridge or sequencer contracts themselves.
    A8
    Relayers are optional for classic withdrawals: withdraw includes a relayer fee recipient, but any caller can submit the proof directly. If relayers disappear, privacy and gas-sourcing UX degrade, but principal exit remains available to users with gas.
    A9
    Classic fixed pools store verifier/hasher/token addresses at construction and no dependency setter was found in the inspected core contracts. Nova has governance upgradeability, but no specific bridge/token/oracle setter was identified; arbitrary implementation upgrade is a control-slice issue rather than a specific A9 dependency setter.
    A3
    TVS weighting: DeFiLlama showed total TVL $809.02m and Gnosis-chain TVL $46,866, so even treating all Gnosis TVL as Nova bridge-exposed gives <0.01% of protocol TVS; Ethereum fixed pools alone included ~216k ETH across the four ETH denomination contracts checked.
    A1
    The core mixer contracts (e.g., 1 ETH pool) are self-contained and do not call external oracles, price feeds, or third-party lending protocols; the deposit amount is hardcoded in the contract bytecode.
    A7
    Deployments on L2s (Arbitrum, Optimism) inherit the liveness and censorship risks of the respective sequencers, though L1 deployments remain unaffected.
    A8
    Withdrawals utilize a permissionless relayer network for privacy; however, the relayer role is non-exclusive, and users can execute withdrawals directly if they provide their own gas, ensuring principal is never trapped by relayer failure.
    A9
    The individual mixer pools (0.1, 1, 10, 100 ETH) are immutable, non-proxy contracts; governance cannot change their logic, swap their verifier contracts, or introduce new dependencies to existing pools.
    Why is this slice uncertain?
    • only 2 of 3 model submissions on record — quorum requires ≥3 agreeing models
    • submitted models do not yet agree on a single grade

    A fresh independent run can establish (or overturn) a verdict.

    Run your own prompt Submit run ↗
    Sources gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗
  5. Open Access tentative 2/2 models agree AI-only 0/2 with chat share link
    Contract admission is permissionless; live UI legal checks remain partly unverified
    Verdict

    Choosing green because the deployed Classic pool and the checked Classic/Nova source show direct user-facing admission paths without whitelist, KYC, or on-chain sanctions checks, and the only unresolved items concern live-frontend/legal-text verification rather than contract-level user admission.

    Steelman argument
    Steelman argument The strongest green argument is that the checked Classic and Nova contracts expose user entry/exit functions without KYC, allowlists, or operator approval, while relayers and bridges are optional or transport/liveness mechanisms rather than per-user admission approvers.
    Evidence (9)
    A1
    Classic pool user entry and exit are not gated by whitelist/KYC modifiers in the checked source: deposit only rejects duplicate commitments and withdraw checks fee, nullifier, known root, and proof validity; deployed Etherscan ABI exposes deposit and withdraw on the assessed 0.1 ETH pool.
    A1
    Nova user functions are likewise not whitelist-based in the checked source: transact handles L2 deposits, withdrawals, and shielded transfers subject to amount/proof/root/nullifier checks, while register only requires the registered account owner to be msg.sender; onlyMultisig is present for rescueTokens and configureLimits, not for user admission.
    A2
    Classic deposits are direct contract calls; Classic withdrawals can be submitted directly by the user or with an optional relayer address/fee, so relayers are fee recipients rather than approval operators for admission.
    A2
    Nova L2 transact/register paths admit users directly subject to proof and pool-limit checks; Nova L1 bridge deposits enter through OmniBridge callback onTokenBridged, which is a bridge delivery path rather than a whitelist or per-user approval role in the checked source.
    A3
    The official Classic UI source is buildable locally and deployable to IPFS, and the Decurity audit identifies deployed UI endpoints including tornadocash.eth.limo and tornadocash.eth.link; no verified A3-active block banner, KYC wall, or wallet-screening provider was found in the allowed evidence checked.
    A3b
    A3b-i: official UI redistributions exist through IPFS/self-hosted builds, which are not independent of the official UI code but do reduce dependence on a single hosted site.
    A3b
    A3b-ii: independent access exists through direct contract interaction on Etherscan and through the command-line flow documented in tornado-core; these paths are separate from any official frontend ToS or runtime UI behavior.
    A4
    No on-chain OFAC/sanctions/blocklist check appears in the checked Classic deposit/withdraw implementation or Nova transact/register implementation; the deployed Classic ABI also does not expose a blocklist-management entrypoint.
    A5
    Read access is public through view helpers such as isSpent/isSpentArray and block explorers; write access for deposits/withdrawals is exposed through Classic deposit/withdraw and Nova transact/register/registerAndTransact without user allowlists.
    Why is this consensus tentative?
    • weak consensus margin
    • only 0/2 sources have a public chat share link
    • total support weight 0.02 below confidence floor (1.5)

    A fresh independent run can strengthen (or overturn) the verdict.

    Run your own prompt Submit run ↗
    Sources gpt-5.5 no url gemini-3-flash-preview no url View raw submissions ↗

Stage

Preview of the Phase-3 maturity framework. DeFiPunk'd will adopt DeFiScan v2's stages verbatim; the section is rendered below in its intended shape so the structure is visible today.

Tornado Cash has not yet been assessed under the DeFiScan v2 stage framework.
The walkaway test is the central criterion. Once stages land, protocols reach Stage 1 only if users can exit in the presence of malicious operators even when the emergency council disappears.
Scope of assessment
Stages are assessed per-protocol against DeFiScan v2's criteria: governance structure, upgradeability path, timelock durations, emergency-council scope, and the walkaway test. The analysis depends on onchain discovery (roles, owners, timelocks) and deeper review of deployed contracts — neither of which DeFiPunk'd automates at Phase 0.
Stage 0 requirements pending
Governance is largely off-chain, contracts are upgradeable with short or no timelock, and the protocol depends on a multisig or team with full discretion. At Phase 0 DeFiPunk'd does not automatically evaluate these; the assessment lands with crawler-based onchain discovery.
Stage 1 requirements pending
Users can exit or opt out on their own terms even if the team disappears. Upgrades run through a meaningful timelock with an emergency security council clearly scoped. The walkaway test is the headline criterion.
Stage 2 requirements pending
Protocol is fully permissionless and immutable, or upgrades require a supermajority of token holders with a long timelock and no emergency override. This is the terminal stage of the DeFiScan v2 framework.
Learn more about DeFiScan v2 stages →
Stages are an opinionated assessment of maturity, not a rating of security or safety. A protocol can sit at Stage 2 and still carry substantial technical or economic risk; the framework exists to incentivize decentralization, not to rank protocols.

Contract surface

Every contract in scope for this protocol — pooled from DeFiLlama's TVL adapter (mechanical) and DEFI@home discovery submissions (LLM-curated). Verified-source flags come from Etherscan + Sourcify; owner / multisig metadata is read on-chain when available. Reviewer audit context, not a slice score. A lending protocol's adapter set will list third-party collateral tokens alongside its own contracts; attribution is the grader's job.

  • 24addresses
  • 0verified source
  • 0proxies

Ethereumdefipunkd surfacer confirms address exists on Ethereum; no verified ABI found (governance/DAO)0x5efd…52bbdiscovery———governance
Ethereumdefipunkd surfacer confirms address exists on Ethereum; no verified ABI found (unresolved governance contract)0x5efd…5286discovery———governance
Ethereumdefipunkd surfacer confirms address on Ethereum; no verified ABI (Governance & Staking)0x5efd…d21ddiscovery———governance
Ethereumdefipunkd surfacer confirms address on Ethereum; no verified ABI (Governance)0x5efd…ca38discovery———governance
Ethereumdefipunkd surfacer confirms address on Ethereum; no verified ABI (Tornado Cash Router per address_book)0x5efd…0368discovery———router
Ethereumdefipunkd surfacer confirms address on Ethereum; no verified ABI; this address is also returned as sole owner of the Nova L1Unwrapper multisig (0xb04E030140b30C27bcdfaafFFA98C57d80eDa7B4)0x5efd…a1cediscovery———governance
EthereumEtherscan name-tag 'Tornado.Cash: TORN Token' for 0x77777FeDdddFfC19Ff86DB637967013e6C6A116C on Ethereum; contract verified0x7777…116cdiscovery———token
Ethereumfactory (InstanceRegistry implementation)0x2573…7fafdiscovery———factory
Ethereumfactory (Proxy of instanceRegistryContract — InstanceRegistry proxy; upgradeable)0xb20c…a911discovery———factory
EthereumGnosis Safe 1.1.1, 1-of-1 multisig (threshold=1, owners=[0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce]), proxy implementation=0x34CfAC646f301356fAa8B21e94227e3583Fe3F5F; labeled Nova L1Unwrapper owner / L1 multisig0xb04e…a7b4discovery———multisig
Ethereumother (FeeManager implementation)0xf4b0…0daadiscovery————
Ethereumother (initial classic ETH pool verifier operator from constructor; appears in tornado-core README as Kovan test relayer — mainnet role unresolved)0x8589…da16discovery———bridge
Ethereumother (Mining v2 — Anonymity Mining contract)0x746a…78e9discovery————
Ethereumother (Proxy of feeManagerContract)0x5f6c…d4d7discovery————
Ethereumother (Proxy of relayerRegistryContract — RelayerRegistry proxy; upgradeable)0x58e8…3df2discovery————
Ethereumother (Proxy of stakingContract / TornadoStakingRewards proxy)0x2fc9…b4bfdiscovery————
Ethereumother (RelayerRegistry implementation)0x01e2…5bb1discovery————
Ethereumother (Tornado.Cash: Reward Swap — AP-to-TORN reward swap AMM)0x5cab…ed2adiscovery————
Ethereumother (TornadoStakingRewards implementation)0x2690…8c89discovery————
Ethereumrouter (Tornado Router — from docs smart-contracts page)0xd90e…f31bdiscovery———router
Ethereumtoken (Voucher TORN Token — vTORN non-transferable voucher)0x3efa…c39ediscovery———token
Ethereumvault (Tornado.Cash: Governance Vault)0x2f50…2185discovery———governance
Gnosismultisig (Nova Gnosis multisig for limits and failed bridged deposit recovery)0x1f72…5b52discovery———multisig
Gnosispool (Tornado Cash Nova Pool Contract proxy on Gnosis Chain)0xd692…0696discovery————

Protocol Info

Security

[:] Source: DEFI@home quorum
Audits
11 audits
Bug bounty
unknown
Security contact
security@tornado.cash

Technical

[:] Source: DEFI@home quorum
Voting token
TORN Ethereum: 0x77777FeDdddFfC19Ff86DB637967013e6C6A116C
Upgradeability
Mixed (some immutable, some upgradeable)

Provenance

[defillama] Source: DeFiLlama
Review status
listed
Updated
2026-09-28 12:50 UTC