How to Trace Funds After Tornado Cash

"The funds went into Tornado Cash" is where most incident reports end. It's also where the real investigation begins. Tornado Cash breaks one specific cryptographic link — the direct connection between a deposit and a withdrawal. It does not erase behavior, timing, infrastructure reuse, or the bridges people use on the other side. This guide covers how to find that signal.

What Tornado Cash Actually Breaks (and What It Doesn't)

Tornado Cash is a zero-knowledge mixer. When someone deposits 100 BNB, they receive a cryptographic note. When they later withdraw using that note — possibly from a different wallet, on a different day — the protocol proves the note is valid without revealing which deposit created it. The on-chain link between depositor and withdrawer is genuinely broken at the cryptographic level.

What it doesn't break: patterns. People are predictable. They batch deposits and withdrawals in matching denominations. They withdraw within tight time windows after depositing. They reuse bridge infrastructure. They fund gas the same way every time. None of this requires breaking the cryptography — it requires looking at the data that surrounds it.

The job of post-mixer tracing is to find behavioral signal around the cryptographic gap, not through it.

Step 1 — Establish the Deposit Fingerprint

Before you touch the withdrawals, fully document the deposit side. You need:

The attacker's EOA — the wallet that deposited. Get this from the exploit transaction on Etherscan, Bscscan, or Blockscan depending on the chain. Look at internal transactions, not just the top-level call — many exploits route through helper contracts.

Denomination and count — Tornado Cash uses fixed-denomination pools (0.1, 1, 10, 100 ETH; 100, 1000 BNB; etc.). Record exactly how many deposits of each denomination went in, and the timestamps. This becomes your matching template for the withdrawal side.

Deposit timing — Note the spread. Were all deposits within 65 seconds? Or spread over hours? A tight cluster suggests automation and tells you the withdrawal side will probably be similarly clustered.

Pool addresses — Each denomination has its own pool contract. You'll need these for Dune queries. Get them by querying tornado_cash.withdrawals grouped by contract_address and amount:

SELECT contract_address, amount, COUNT(*) as tx_count
FROM tornado_cash.withdrawals
WHERE blockchain = 'bnb'
GROUP BY contract_address, amount
ORDER BY amount DESC

Step 2 — Query Dune for Withdrawal Clusters

This is where most people either don't look, or look wrong. The key table is tornado_cash.withdrawals in Dune's Spellbook. It normalizes Tornado withdrawals across chains with one row per withdrawal.

Critical details that will save you hours:

Always filter by blockchain — the table covers multiple chains. For BSC use 'bnb', not 'bsc' or 'binance'.

Use the pool contract address, not the proxy — Tornado has a router/proxy contract that most people find first on Bscscan. Queries against the proxy return nothing. You need the actual pool address for the denomination you're investigating.

Recipient addresses are stored in lowercase — if you're filtering by a specific recipient, lowercase your address or the match will fail silently.

The base query for a 48-hour window after deposits:

SELECT block_time, amount, recipient, relayer, tx_from, tx_hash
FROM tornado_cash.withdrawals
WHERE blockchain = 'bnb'
  AND contract_address = lower('YOUR_POOL_ADDRESS')
  AND block_time BETWEEN TIMESTAMP '2026-03-22 19:30:00'
                     AND TIMESTAMP '2026-03-22 19:30:00' + INTERVAL '48' HOUR
ORDER BY block_time

What you're looking for: multiple withdrawals to the same recipient address within a tight time window. The baseline withdrawal rate for the 100-BNB pool on BSC is roughly 5 per day. If you see 6 going to the same wallet in under 3 minutes, that's not random. Six independent users do not accidentally withdraw to the same address.

Also check the relayer column. If withdrawals share a relayer, that's another clustering signal — relayers are chosen by whoever controls the withdrawal, and people reuse them.

Step 3 — Map the Collector and Splitter Structure

Post-mixer fund flows almost always follow the same architecture. Once you've identified a withdrawal recipient, open it in Bscscan (or Etherscan, Blockscan for other chains) and look at the full transaction history:

The collector — receives directly from Tornado. Usually single-use, funded by Tornado itself (no prior history). Doesn't hold funds — moves them quickly to the next layer.

The splitter — receives from the collector and fans funds out to multiple wallets. This is the key node. The number of outgoing transfers tells you how many downstream paths to follow.

The bridge wallets — freshly created, no prior history, each receives a slice from the splitter and immediately routes to a bridge aggregator.

Use Metasleuth to visualize this structure — it's the fastest way to see the full graph without manually clicking through every transaction. Paste the collector address and let it auto-expand one or two hops. The fan-out pattern becomes immediately visible.

Step 4 — Follow the Bridges

This is where most post-mixer traces fail silently. The bridge wallets route through aggregators — LI.FI, Socket, Rango — which dispatch to underlying bridge protocols. The aggregator contract appears on Bscscan, but the destination chain data is not there.

The mistake: querying Dune for LI.FI events and expecting results. LI.FI's Dune tables are often incomplete or delayed. Don't rely on them.

Instead, go directly to the underlying bridge explorers:

Across Protocol — go to across.to, use the transaction search or depositor address search. Returns source chain, destination chain, recipient, amount, and fees. Most LI.FI routes on BSC go through Across.

Axelar — go to axelarscan.io. Some LI.FI routes use Squid Router on top of Axelar. If Across comes back empty for a wallet, try Axelar next.

Mayan Protocol — for cross-chain routes that involve Solana. Less common but worth checking if you see BNB amounts that don't appear in Across or Axelar results.

Stargate, Hop, Synapse — each has its own explorer or transaction search. If a wallet's Bscscan internal transactions show a contract you don't recognize, look it up — it's usually a bridge with its own search tool.

Work through every bridge wallet systematically. Record: source wallet → bridge used → destination chain → recipient address. Do not assume all wallets used the same bridge — in the Cyrus case, 10 of 11 used Across and one used Axelar. Missing that one would have left funds unaccounted for.

Step 5 — Track Gas Funding on the Destination Chain

Fresh wallets on the destination chain need gas. How they get it is a signal.

Normal users have ETH already, or transfer from another wallet, or use a centralized exchange. Attackers doing operational security use gas-funding services that break the link between their existing wallets and the new destination addresses.

The most common one in recent cases: Wagyu (wagyu.xyz). It lets you pay for gas on a new chain by sending stablecoins on a chain you already have funds on. The gas arrives from Wagyu's treasury — no on-chain link to your other addresses. If every destination wallet you're tracking was funded through Wagyu on the day it received bridged funds, that's not a coincidence. It's a pattern.

Check the first incoming transaction of each destination wallet. If it's from a known gas service rather than an EOA or exchange, note it — consistent gas-funding method is a clustering signal that ties wallets together even without a direct on-chain link between them.

Step 6 — Find Where Funds Landed

The final destination is often not visible in standard EVM explorers. In recent exploit cases, funds consistently end up on Hyperliquid — a decentralized perpetual exchange with its own L1. Etherscan and Arbiscan show an empty wallet. The funds are actually sitting in Hyperliquid spot or perp positions.

Tools for finding Hyperliquid balances:

hypurrscan.io — Hyperliquid's native explorer. Paste the destination wallet address. Shows deposits, spot balances, and open positions.

Debank — surfaces Hyperliquid balances alongside EVM wallet data in a single view. Useful when you're checking many wallets quickly.

Beyond Hyperliquid: check deBridge, Stargate, and any protocol-specific explorer for the destination chain. The pattern in recent cases has been: bridge to Arbitrum → Wagyu gas → deposit to Hyperliquid → convert to a privacy-adjacent token (XMR1, in the Cyrus case).

The Pattern Most Investigators Miss

The single most common failure in post-mixer tracing is not looking for patterns where patterns must exist.

Tornado Cash is used by real people with real operational constraints. They are in a hurry. They have infrastructure they've already set up. They use the same bridge they used last time. They fund gas the same way. They consolidate funds at the same destination.

When you see six withdrawals go to the same address, that's not ambiguous — it's arithmetic. When every destination wallet gets gas from the same service on the same day, that's not coincidence. When all bridge routes land on the same Hyperliquid address pattern, that's a signature.

The cryptographic break is real. The behavioral signature around it usually isn't hidden — it's just not where most people look.

Tool Summary

Further Reading

This methodology was developed and tested across two live investigations into the Cyrus Finance exploit. The full traces, including SQL queries, wallet addresses, and bridge transaction details, are documented here:

When the Trail Doesn't End at the Mixer: Where the Cyrus Finance Funds Went — tracing 600 BNB from Tornado Cash through LI.FI to Hyperliquid.

Two Months Before Tornado Cash: The Cyrus Finance Solana Side-Channel — the remaining 210 BNB, and a Solana route the attacker prepared two months before the exploit.