How Does Bitcoin Address Clustering Work?

A Bitcoin address is not an account. Modern wallets generate a fresh address for every incoming payment and another for every bit of change, so a single user with a few hundred dollars of activity can easily be spread across dozens of addresses that look, on the chain, completely unrelated. That is the design working as intended. It is also why looking up one address balance usually answers the wrong question, and why every serious analytics or compliance workflow starts by rebuilding the wallet behind the address.

That rebuilding step is address clustering. It is the single most consequential piece of inference in on-chain analysis, it is the foundation under every entity-level metric you have ever read, and it is wrong more often than most vendors admit. Here is how it actually works.

How does Bitcoin address clustering work?

Clustering works by reading the transaction graph for behavioral patterns that leak information about shared control. Bitcoin never records who owns what, but the mechanics of spending force wallets to reveal relationships between their own addresses. Two heuristics do nearly all the work, and a handful of weaker signals fill in the edges.

Clusters are built transitively. If address A and B appear together as inputs, and later B and C appear together, then A, B and C all land in one cluster even though A and C were never seen in the same transaction. This is what lets a cluster grow to millions of addresses for a large exchange. It is also why a single bad link can silently merge two unrelated entities forever, a failure mode called cluster collapse.

What is the common input ownership heuristic?

The common-input-ownership heuristic states that if a transaction spends several inputs at once, one party must have held the private keys for all of them, so those addresses belong to the same wallet. The logic is mechanical rather than statistical: to build a valid transaction you need a signature for every input you spend, so under normal circumstances only one keyholder could have produced it.

Sarah Meiklejohn and co-authors formalized this in A Fistful of Bitcoins at IMC 2013, together with the change heuristic below. That paper won the IMC Test-of-Time Award in 2024, and its two heuristics remain the backbone of essentially every commercial clustering engine in use today. If you have seen a chart of exchange balances or a whale-tracking dashboard, you have seen the output of this heuristic.

Its strength is also its limitation. The assumption is only true when a single party built the transaction. Protocols exist specifically to make that false.

What is a change address, and how is it detected?

Bitcoin spends whole outputs. If you hold a 1 BTC output and want to send 0.3 BTC, the transaction consumes the entire 1 BTC and creates two outputs: 0.3 to the recipient and roughly 0.7 back to an address you control, minus the fee. That return output is change, and it is a direct consequence of how UTXOs work. Identifying it adds the change address to the sender's cluster.

Detection relies on behavior rather than cryptography. The classic signal is a one-time address: if one output pays an address that has never appeared on the chain before and is never reused afterward, while the other pays an address with history, the fresh one is probably change. Analysts stack additional tells on top, such as an output whose value has more decimal precision than its sibling (round-number payments suggest the recipient), or an output whose script type matches the inputs while the other does not.

None of these are guarantees. A wallet that sends to a fresh recipient address, which is good practice, produces exactly the pattern that change detection looks for. That is why we treat change links as medium confidence and keep them separable from common-input links, so an investigator can drop them when the standard of evidence needs to be higher.

Can Bitcoin address clustering be wrong?

Yes, in both directions, and the two error types have very different consequences.

A false merge puts addresses from different owners into one cluster. This is the dangerous one. It inflates apparent balances, creates fictional links between unrelated parties, and in a compliance context can produce an exposure finding about someone who never transacted with the entity in question. Because clustering is transitive, one false link contaminates everything downstream of it.

A false split leaves one owner's addresses in separate clusters. This is the common one and the safer one. You undercount a wallet's holdings and miss connections, but you do not invent relationships that never existed. Möser and Narayanan's Resurrecting Address Clustering in Bitcoin (Financial Cryptography 2022) documented how much clustering quality has degraded as wallet behavior evolved, which is a useful corrective to any vendor implying their clusters are complete.

The practical response is not to distrust clustering, it is to demand that a provider show its reasoning. A cluster membership that arrives with the heuristic and confidence attached is auditable. A cluster that arrives as a bare list of addresses asks you to take an unverifiable claim on faith, which is a poor position to be in if you ever have to defend an analysis.

Does CoinJoin break address clustering?

CoinJoin breaks common-input-ownership by design. In a CoinJoin, multiple independent users cooperatively build one transaction, each signing only their own inputs, and the outputs are typically equal-value so they cannot be matched back to specific inputs. Applied naively, the heuristic concludes that every participant is the same entity, which is exactly the false merge described above.

Competent indexers detect the structural signature of these transactions, many equal-value outputs and a participant count consistent with a known implementation, and exclude them from clustering rather than let them poison the graph. PayJoin is harder, because it is deliberately built to look like an ordinary payment while including an input from the recipient. It is a genuine, unsolved limit on the heuristic, and anyone claiming otherwise is selling certainty they do not have.

What is the difference between address clustering and address labels?

Clustering is the grouping step and labeling is the naming step. Clustering works out which addresses share control; it produces an anonymous set. Labeling attaches a known entity to that set, such as a major exchange's hot wallet or a mining pool payout cluster, using public attribution like published deposit addresses or documented service behavior.

The order matters, because you can cluster without ever labeling. The overwhelming majority of clusters on Bitcoin are grouped but unnamed, since no public information ties them to any real-world entity. When a cluster does carry an entity label, that label is informational context about a service, not an identity claim about an individual. Nothing in on-chain analysis reveals a person's name. The point where a chain of addresses becomes a person is always a records request to a regulated business, never a query.

How do compliance and research teams use clustering?

For AML work, clustering is what makes exposure measurable. Screening a single deposit address against a sanctions list catches almost nothing, because the counterparty simply uses a different address next time. Screening at the cluster level asks the more useful question: has this wallet, as a whole, ever transacted with an entity we care about, and how many hops away? That output feeds a human review, and the decision to escalate or file belongs to the team that owns the compliance program, not to the data provider. If you want the full workflow, tracing a Bitcoin transaction walks through it step by step.

For research and market analysis, clustering is what turns per-address noise into entity-level signal. Exchange reserves, whale accumulation, miner selling, holder concentration: every one of those metrics is a cluster aggregate, and every one inherits the clustering engine's errors. When two data providers publish different exchange balance figures, the disagreement is almost always in the clustering, not the arithmetic.

How do you query address clusters in practice?

Three access patterns cover nearly everything. A REST lookup handles the per-address case: an app has an address and needs the cluster, the cluster balance and the confidence behind each link. SQL handles aggregate work, where you want to rank clusters by balance, roll up exposure across thousands of them, or join clusters against fund flows and labels in one pass rather than looping thousands of API calls. Dashboards cover manual case review.

You can build all of this yourself. It means running a full node, replaying every block since genesis, implementing both heuristics plus CoinJoin exclusion, and re-running the clustering as the chain grows, which is a meaningful ongoing engineering commitment rather than a weekend project. The alternative is querying a chain that has already been indexed and clustered. Our Bitcoin address clustering API returns the cluster for any address with the heuristic and confidence on every membership, and the same clusters are queryable in SQL alongside balances, transaction tracing and AML risk signals.

Whichever route you take, hold onto the honest framing. Clustering is high-quality inference about control, drawn from a public ledger that was never designed to reveal it. Treated as evidence to be weighed, it is the most useful tool in on-chain analysis. Treated as fact, it will eventually tell you something confident and false.

Informational on-chain data and analytics only. Nothing here is legal, financial or investment advice, and clustering results are probabilistic signals to support your own review, not identity claims about any person or entity.