Following the money: flows and clustering

From addresses to entities

A blockchain records addresses, not people. One person can control hundreds of addresses, and one exchange address can hold the deposits of millions of customers. So the analyst’s real work is not reading transfers, which any explorer does, but grouping addresses into entities and deciding which entity each transfer belongs to. The output is never a certainty. It is a graph of hypotheses, each with a reason and a confidence, and the discipline of the craft is keeping those two things attached to every edge.

This is the same machinery that the guide to what your address says about you describes from the other side. Knowing how clustering works is how you keep your own addresses from being clustered.

Bitcoin: common inputs and change

Bitcoin’s own whitepaper names the first heuristic. In its section on privacy it notes that "some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner." To spend several coins at once, a wallet has to sign for all of them, so inputs that appear together usually share a keyholder. Chained across thousands of transactions, this common input ownership heuristic collapses many addresses into one wallet.

One Bitcoin transaction, two inputs and two outputs (illustrative)

inputs    bc1q...a   0.61000000 BTC    signed together in one transaction,
          bc1q...b   0.52000000 BTC    so one wallet very likely holds both keys
outputs   bc1q...x   1.00000000 BTC    round number: probably the payment
          bc1q...y   0.12985000 BTC    odd amount, never seen before, same
                                       script type as the inputs: probably change
fee                  0.00015000 BTC

The second heuristic is change detection. Bitcoin outputs are spent whole, so a payment usually creates change back to the sender. The change output tends to be the odd amount, to go to a brand new address, and to use the same script type as the inputs. Identify the change and you can follow the sender’s wallet forward. A long run of transactions that each peel a small payment off a large balance and send the rest to fresh change is called a peel chain, a pattern analysts recognize at a glance.

Both heuristics break by design in CoinJoin, where many users combine inputs into one transaction, and in PayJoin, where the receiver contributes an input. That is why privacy minded users and launderers alike use them, and why a trail through a CoinJoin becomes probabilistic at best.

Account chains: deposit addresses, gas and habits

Ethereum has no inputs and outputs, so the Bitcoin heuristics do not apply. A foundational academic treatment, Friedhelm Victor’s "Address clustering heuristics for Ethereum" (Financial Cryptography 2020), proposed three: reuse of exchange deposit addresses, participation in several airdrops that are then consolidated, and token approvals between addresses. Over Ethereum’s first four years they clustered 17.9% of active externally owned addresses into more than 340,000 multi-address entities, and deposit address reuse was the most effective.

The deposit heuristic works because exchanges give each customer a unique deposit address that forward whatever arrives to a central hot wallet. If two of your addresses both pay into the same deposit address, they almost certainly belong to the same exchange account. Dune now builds a public table of detected deposit addresses, cex.deposit_addresses, from exactly this consolidation pattern.

Two more signals do a lot of practical work. Gas funding: a new address needs native coins before it can do anything, so its first incoming transfer often points to its owner. And habits: the same active hours, the same gas settings, the same apps in the same order. These are the core of sybil detection in airdrop design, where one farmer running many wallets tends to fund them from one place and click through them in the same sequence.

Labels: useful, fallible, sometimes adversarial

Clusters become meaningful when one address in them has a name. Labels come from exchanges’ own disclosures, explorer name tags, forensic firms, community submissions and inference. Dune documents its own mix: curated seed files for exchanges, protocols and DAOs, automated contract analysis, ENS resolution and community contributions. Each source fails differently:

• Inferred labels presented as fact. "Exchange: deposit" may be one analyst’s guess from a consolidation pattern, copied between tools until it looks authoritative.
• Stale labels. Contracts are upgraded, wallets are handed over, and a label that was right in 2022 can be wrong today.
• Self-chosen names. An ENS name is a claim by whoever registered it. Anyone can call their address anything.
• Service labels hide users. "Binance" on a hot wallet tells you nothing about which of its customers sent the funds. Only the exchange can answer that.

Speed matters too. In the Bybit case, TRM Labs says it tagged the compromised addresses almost immediately and created a single tracking entity for the exploiter. Labels like that propagate across compliance systems within hours, which is powerful when they are right and damaging when they are not. Record the source of every label you use.

Tracing through swaps, bridges and services

Swaps. A DEX swap changes the asset but not the owner, and it happens inside one transaction. Follow the Swap event and the output Transfer to the recipient, as in reading a transaction. Aggregators route through several pools in the same transaction, so skip to the final transfer out.

Bridges. A bridge locks or burns on one chain and releases or mints on another. Match the two sides by the bridge’s own identifiers (deposit IDs and message IDs, which most bridges expose in an explorer such as Wormholescan), then by amount minus fees and by timing. The trust models behind those messages are covered in cross chain security.

Custodial services and mixers. A deposit into an exchange or an instant swap service usually ends the public trail, because the link between what went in and what came out lives in the service’s database. Only the service, under legal process, can extend it. Mixers and CoinJoin produce outputs that cannot be deterministically matched to inputs; amount and timing correlations can suggest links, but treat them as weak evidence, not a continuation of the trail.

Case study: following the Bybit theft

On February 21, 2025, attackers took 401,347 ETH plus staked ether tokens from Bybit’s cold wallet, about 1.46 billion dollars and the largest crypto theft on record (how the signers were deceived is covered in what went wrong at Bybit). The laundering that followed was traced in public, in real time, by several analytics firms, and it shows every technique above in use on both sides. The sequence below comes from public analyzes by Elliptic, TRM Labs and Chainalysis.

Attribution rested on clustering. Chainalysis reported that funds from the exploit consolidated in addresses already holding funds from other known North Korea linked attacks, which is common control inferred from a shared destination. On February 26, 2025 the FBI publicly attributed the theft to North Korea, activity it calls TraderTraitor, published 51 Ethereum addresses connected to it, and asked node operators, exchanges, bridges and analytics firms to block transactions derived from them.

The launderers adapted to being watched. TRM described the approach as "flood the zone": so many rapid, high frequency transactions across so many platforms that compliance teams could not keep pace. The counter was collaboration and incentives. Bybit offered a bounty of up to 10% of any frozen or recovered funds, and Chainalysis said on February 27, 2025 that it had already helped freeze more than 40 million dollars.

Three lessons carry over to any investigation. Freezable assets move first, so the first minutes show you what the attacker fears. Equal sized fan outs are easy to label but expensive to watch, so labeling is a race. And public data can follow funds up to a custodial service but rarely through it; beyond that point, recovery depends on institutions that can freeze funds or compel records.

Tools, and what they are really doing

Every one of these tools runs the same heuristics described above, plus labels. A beautiful graph is a rendering of someone’s inferences. When you can, check the key edges yourself on an explorer, or test a heuristic at scale with your own SQL.

A disciplined workflow

1. Write the question down

   "Where did the proceeds of this exploit go?" is answerable. "Who is behind this wallet?" usually is not from public data, and chasing it is where investigations go wrong.

2. Pin the starting point

   Start from transactions you can verify yourself: the exploit transaction, the scam payment, the treasury transfer. Decode them properly first (see reading a transaction).

3. Expand one hop at a time, with rules

   Decide in advance what you follow: a minimum amount, a time window, and what counts as a service where you stop. Without rules, every graph grows until it touches a major exchange.

4. Record evidence and confidence for every link

   Note why you believe each connection (same transaction, memo, amount and timing, deposit address reuse) and how strong it is. A chain of five "probably" links is not a "probably".

5. Corroborate before you conclude

   Look for an independent signal: a second heuristic, a public statement, a law enforcement notice. Then write it up with the uncertainty left in.

Ethics and limits

Some rules follow directly. Never publish a private person’s identity, home or family on the strength of a cluster, and never contact, threaten or pile onto someone you suspect. Report to the people who can act: the exchange that received the funds, the protocol’s security contact, the victim’s official recovery channel, and law enforcement. If you trace your own stolen funds to an exchange, send its security team the transaction hashes and file a police report; the steps are in what to do if your wallet is drained. Anyone offering to "recover" stolen crypto for an upfront fee is almost always a second scam.

Know the limits too. Public data rarely proves identity, clustering error rates are unknown for any specific case, and well funded launderers study the same heuristics you do. The goal of onchain analysis is better questions and better evidence for the people who can act on it, not verdicts.

Common questions

Where to go next