Smart-contract mixers

A smart-contract mixer leaves a more complete public record than any custodial service: every deposit and every withdrawal is an event anyone can decode. What it removes is the one fact investigators want, the link between them, and it removes it with cryptography rather than a database that can be seized. This lesson covers what the contract's records prove, how published linkage heuristics work and how far they can be trusted, and where the evidence that settles a link actually lives: notes, relayers and front-ends.

Tornado Cash in evidential terms

Tornado Cash is the reference design. Each pool is a contract that accepts one fixed amount; the ETH pools take 0.1, 1, 10 or 100 ETH, and token pools exist for assets such as DAI, USDC, USDT and WBTC. The pool contracts cannot be paused or upgraded. The mechanics are described in the IDFE-BA lesson Mixers, CoinJoin and obfuscation in graphs; here is what each record proves.

The depositor's software generates two secrets, a nullifier and a random value. The commitment is a hash of both; the nullifier hash is a hash of the nullifier alone. The user keeps both secrets as a note, a string such as tornado-eth-0.1-1-0x… that encodes the currency, amount, chain ID and the secrets. The contract records each nullifier hash and rejects a second withdrawal with the same value. Whoever holds the note can withdraw; the note is, in effect, a bearer key.

The anonymity set and how to report it

For a given withdrawal, the candidates are the deposits made to the same pool before it. Two numbers describe that set honestly, and decoded event tables give both:

-- Anonymity set for one withdrawal from the 10 ETH pool at block 15,200,000
SELECT
  (SELECT COUNT(*) FROM tc_deposits
    WHERE pool = 'ETH-10' AND block_number < 15200000)    AS prior_deposits,
  (SELECT COUNT(*) FROM tc_withdrawals
    WHERE pool = 'ETH-10' AND block_number < 15200000)    AS prior_withdrawals;

The first subquery counts every deposit before the withdrawal block: each is a candidate, because the contract never reveals which deposits have been spent. The second counts earlier withdrawals. The difference is the number of deposits still unspent at that moment, which is the pool's working size. Report both, with the pool, the block and the data source. The table names here are illustrative; build them from the pool contract's logs filtered by event signature (see the IDFE-BA lesson Querying EVM logs and traces).

Linkage heuristics in published research

Researchers have measured how often users leak the link themselves. The heuristics most often cited:

Two studies give the scale. Tutela (Wu and colleagues, 2022) flagged about 42,800 of 97,300 deposits, roughly 44%, as potentially compromised by at least one heuristic, led by linked addresses (18,900), address match (18,600) and multi-denomination (16,200), and estimated an average 37% (±15%) reduction in anonymity sets. Wang and colleagues (ACM Web Conference 2023) reported average reductions of 27.34% for the most popular Ethereum mixer pools and 46.02% for a comparable mixer on another chain. Béres and colleagues (2021) used naming-service identifiers as partial ground truth for profiling users by gas-price habits and time-of-day activity.

The critical point for evidence: the Tutela authors state that their heuristics will produce false positives and report no ground-truth validation for the Tornado Cash heuristics. Published figures show leaks are common; they do not give an error rate for a link in your case. Grade a single heuristic link C or D depending on its logic, and look for corroboration from a different kind of evidence.

Worked example. Address 0xA1b2…9F deposits 3 × 10 ETH and 1 × 1 ETH within an hour. Nineteen hours later, fresh address 0x5cE0…71 receives three withdrawals from the 10 ETH pool and one from the 1 ETH pool through a relayer, each less the relayer's fee, and its first outgoing transaction pays an exchange deposit address. The examiner counts how many other addresses deposited the same combination in the preceding 48 hours (none) and how many withdrawal sets of that shape occurred (one). The multi-denomination match is recorded as grade D with its counts; the exchange's records for the deposit address are requested; if they show the same customer who funded 0xA1b2…9F, the link rises to B.

Notes: the evidence that settles a link

A note found under lawful authority does what no heuristic can. From the note's secrets the examiner recomputes the commitment, which identifies the Deposit event, and the nullifier hash, which identifies the Withdrawal event if one exists. That is a deterministic, independently repeatable link from depositor to recipient. If no withdrawal carries that nullifier hash, the deposit is still in the pool and the note still controls it; securing it is then an asset-recovery question (see the lessons Freezing and seizure options and Securing seized crypto-assets).

Where notes are found:

• text files, including backup files that the command-line client writes when it creates a note;
• password managers, notes apps, screenshots, chat messages to oneself and paper;
• encrypted backups the interface could store on chain through a "note account", readable with the account's key;
• reports from the interface's compliance tool, which generated a document from a note listing its deposit and withdrawal.

Handle a note as you would a private key (see the lessons Wallets on seized devices and Hashing, logging and chain of custody). Never paste it into a hosted interface or third-party site: anyone who sees it can withdraw unspent funds. Recompute with open-source code on an isolated examiner machine, record the software version and hash, and have a second examiner repeat the computation.

Relayers and front-ends

The Withdrawal event names the relayer and its fee, so the relayer address is a deterministic fact. Relayers are independent operators; registered ones stake governance tokens in an on-chain registry that the interface reads, but the pools pay any relayer that a withdrawal names. A relayer receives the withdrawal request over the network and may hold logs of request times and network addresses, if it keeps any. Treat it as a possible record holder, identify its operator from registry and naming records, and expect that many operate behind anonymizing networks or keep nothing.

The front-end is separate code, served from decentralized storage and gateways, and it changes. In early 2024 a malicious governance proposal inserted code into the interface served through IPFS gateways that sent users' notes to an outside server, from January 1, 2024 until it was found. Two lessons follow: record which interface version and gateway a subject used (browser history, wallet-extension connection logs), and remember that a note may also exist in someone else's hands.

One authority sanctioned the Tornado Cash contracts in August 2022 and lifted the designation in March 2025; the contracts kept working throughout (see the IDFE-CC lesson Wallet and transaction screening).

Exam focus: what the Deposit and Withdrawal events and the withdraw parameters prove and do not prove; commitment, nullifier hash and the note as a bearer key; reporting prior deposits and unspent deposits as the anonymity set; address match, linked addresses, gas funding, multi-denomination, unique gas price, timing and reward-claim heuristics with their caveats; Tutela (about 44% of deposits flagged, 37% average reduction) and Wang et al. (27.34%) and the absence of validated error rates; a found note as a deterministic link, where notes are found, and safe handling; relayer and front-end evidence.