The transaction graph and address clustering

A single person on the blockchain almost never uses just one address. They have dozens or hundreds, and an exchange has millions. So how does an analyst figure out that twenty different addresses actually belong to one wallet? The answer is the transaction graph and clustering heuristics. This is the foundation of all blockchain analytics: it's how Chainalysis, Elliptic and AMLConsensus turn the chaos of anonymous addresses into understandable entities — "exchange," "mixer," "fraudster."

What a transaction graph is

The blockchain is by nature a giant graph. In mathematics, a graph is made of vertices (nodes) and edges (the links between them). In blockchain analysis:

Vertices are addresses (or, in the UTXO model, the transactions and their outputs themselves).
Edges are the transactions that carry value from one address to another, with a direction arrow and a weight (the amount).

When you enter an address into an AML check, the system doesn't look at it in isolation. It pulls in its surroundings — who paid it, whom it paid — and builds a subgraph. It's from the shape and content of this subgraph that a conclusion about risk is drawn.

The simplest example of a graph: address A sent 1 BTC to address B; B sent 0.5 BTC to address C and 0.5 BTC to address D. Draw this with arrows and you get a directed, weighted graph. An analyst reads such structures like text: a branching-out into many small outputs may mean "splitting" (structuring), a convergence of many inputs into one may mean a consolidation of funds, and passing through a known mixer contract may mean an attempt to break the link.

A mini flow diagram.
Phishing victim → Thief's address A → splits into A1, A2, A3 → each to a new address → mixer → exchange deposit.
The analyst's task is not to lose the "thread" through all these hops and to understand that A1, A2, A3 are one and the same owner.

The problem: address ≠ owner

The key difficulty of blockchain analysis is that an address is not an account. Creating a new address is free and instant; wallets automatically generate a new address for each transaction for the sake of privacy. So from a single address you can't directly say how much money a person has in total and whom they're connected to. You first have to group addresses into clusters, each of which is, with high probability, controlled by one entity. This process is called clustering, and the tools for it are heuristics.

Heuristic 1: common input (common-input-ownership)

This is the most powerful and reliable heuristic for networks on the UTXO model (Bitcoin, Litecoin). Its idea is simple and rests on how signatures work.

The logic of common input

To spend funds in a transaction, you must sign each of its inputs with the private key of the corresponding address. If a single transaction has several inputs from different addresses, then whoever created it owned the private keys of all those addresses at once.

We observe a transaction. Inputs: address X (0.3 BTC), address Y (0.2 BTC), address Z (0.5 BTC). Output: one payment of 1 BTC. Three inputs gathered together.
We draw a conclusion. X, Y and Z were signed by one person → all three belong to one wallet. We merge them into a cluster.
We expand. If tomorrow X takes part in a transaction together with address W, then W is drawn into the same cluster too. Clusters grow like a snowball.

This is exactly how a single exchange cluster can grow to hundreds of millions of addresses — all of them have at least once taken part in joint consolidation transactions.

A limitation. The common-input heuristic is broken by CoinJoin — the deliberate combining of inputs from different, unrelated users into one transaction. Here a naive application produces false merging. So quality analytics engines first recognise the CoinJoin pattern (equal output amounts, many participants) and exclude such transactions from clustering.

Heuristic 2: the change address

The second classic heuristic also comes from the UTXO model. When you pay with part of your balance, the "change" comes back to you — but to a new address, so as not to reveal the remainder. If the analyst can work out which output is the change, they'll link that new address to the sender.

The "new address" clue. One of the outputs goes to an address that has never appeared on the blockchain before — a likely change candidate.
The "round amount" clue. If one output is exactly 0.50000000 BTC (the payment) and the other is 0.34172618 BTC (a non-round remainder), the non-round one is most likely the change back to the sender.
The script-type clue. Change usually comes back to an address of the same type/format as the inputs (for example, the same bech32 format).

Example: address A spends 1 BTC. Outputs: 0.7 BTC to seller B and 0.29 BTC to a new address C. The change heuristic: C is the change, which means C belongs to the same owner as A. Now A and C are in one cluster, even though formally they are different addresses.

Other clustering signals

Behavioural and external heuristics

Timing and patterns. Addresses that pay the same service at the same moments in the same amounts may be controlled by one bot/owner.
Address reuse. In account-model networks (Ethereum) a single address is used many times, and common-input doesn't work — there they cluster by contract interactions, exchange deposit addresses, and gas patterns.
Exchange deposit addresses. An exchange gives each user a unique address for deposits and then sweeps the funds to a hot wallet. By tracing the sweep, the analyst links the user's deposit address to the exchange's cluster.
External labels (attribution). Data from the real world: an address published on a forum, in the OFAC sanctions list, in a court case, or obtained through one's own KYC deposit to an exchange. It's the labels that give a cluster a name.

From cluster to entity: how an analyst "sees" a wallet

Let's put it all together in an end-to-end example. An analyst is investigating the address of a victim whose funds were stolen.

Builds a graph around the thief's address. Sees that the stolen funds are split into A1, A2, A3. The first layer of laundering.
Applies common-input. Two weeks later A1 and A3 appear in a single consolidation transaction — meaning it's one owner. The cluster is assembled. The splitting didn't help — the heuristic glued it back together.
Applies the change heuristic. Tracks the change and doesn't lose the "thread" when part of the funds go to "new" addresses. The cluster grows.
Catches the exit point. The cluster sends funds to an address labelled as a deposit of exchange X. Here the off-chain part begins.
Draws a conclusion for the report. "The stolen funds, after 4 hops and splitting, settled on a deposit of exchange X — that is where a KYC-disclosure request should be directed." An anonymous graph turned into an actionable conclusion.

Why this matters for AML scoring. When you check a wallet in AMLConsensus and see "link to a mixer" or "receipt of funds from a darknet market," behind that line stands precisely clustering: the system knows that a mixer's many addresses are one entity, because it glued them together with heuristics. Without clustering, every address would be nameless, and scoring would be impossible.

Remember the errors. Heuristics are probabilistic assumptions, not proof. Common-input is broken by CoinJoin; the change heuristic — by the deliberate use of round outputs and identical address types. A good analyst always states a confidence level and doesn't pass off a cluster as an irrefutable fact. Falsely merging two owners into one cluster is a real source of unfair "red" scores — something we'll discuss in the section on false positives.

← Programme Programme →

This material is for educational purposes.