Address Labeling and Entity Clustering: How Analysts Identify Exchanges, Funds, and Protocols

Key Takeaways

• What it is: The process of connecting pseudonymous blockchain addresses to known services, wallets, contracts, and probabilistic entities.
• How it is built: Labels combine public disclosures, contract registries, transaction patterns, deposit-address structures, co-spending heuristics, operational fingerprints, and manual research.
• Core expression: Entity estimate = verified labels + bounded heuristics − known false-positive classes; probabilistic clusters must not be presented as certain identity.
• Best use: Entity-adjusted metrics can remove internal transfers and consolidate service-controlled addresses, producing more economically meaningful flows.
• Main limitation: Heuristics can merge unrelated users, exchanges can change wallet architecture, privacy tools deliberately break linkability, and labels may become stale.
• Practical rule: Before trusting an entity label, confirm when it was last verified, whether the exchange's wallet architecture has changed since, and whether the clustering heuristic could have merged unrelated users.

Who This Guide Is For

Entity labels sit underneath most published on-chain metrics, and almost nobody who uses those metrics has looked at how the labels are made. This page covers the heuristics themselves: what each one assumes, what it produces, and the specific conditions under which it produces a wrong answer.

Read it if you rely on exchange flows, whale metrics, or any series that names an actor. The pitfalls section covers cluster contamination, which is the failure mode with the largest consequences and the least visibility.

Educational content. Not individualized financial advice.

What Does Address Labeling and Entity Clustering Measure?

Clustering groups addresses believed to share a controller. Labeling attaches a name to a cluster. They are separate operations with separate error rates, and conflating them obscures where a mistake came from.

Clustering is a structural inference from transaction patterns and can be evaluated on its own terms. Labeling is an identification claim about the real world and requires evidence from outside the chain entirely. A cluster can be perfectly correct while its label is wrong, and a label can be correct for a cluster that has absorbed addresses it should not contain.

Plain-language definition

Clustering decides which addresses belong to the same owner. Labeling decides what to call that owner. Neither is recorded on the chain.

Why the distinction matters

An error in clustering silently changes the size of an entity, so a whale metric can report accumulation that is really two clusters being merged. An error in labeling changes which category a flow lands in, so a custodian misidentified as an exchange moves volume between series without changing any total. The two produce different symptoms and need different checks.

How Is Address Labeling and Entity Clustering Constructed?

Common-input ownership

If a transaction spends several inputs, the spender needed the private key for all of them, so they are usually one controller. This is the workhorse heuristic on UTXO chains and it is powerful: one transaction can merge two large clusters permanently.

It fails against collaborative transactions. A CoinJoin deliberately combines inputs from many independent parties into one transaction, which the heuristic reads as proof they are all the same entity. A single such transaction can merge thousands of unrelated addresses into one cluster, and once merged the cluster is wrong in a way that is difficult to detect after the fact.

Change detection

A payment usually returns change to the sender, so identifying which output is change extends the cluster forward. Heuristics include an output with an address type matching the inputs, an output not seen before, and a value with more decimal places than a round payment would have. Each is probabilistic and wallet software that randomizes output ordering or matches change amounts defeats them.

Deposit-address mapping

The most reliable technique for exchanges. A researcher deposits, observes the address they were given, and watches where funds are swept. The sweep destination is the exchange's consolidation wallet, and every address sweeping into it is an exchange deposit address. This produces high-confidence labels for the venues someone actually tested.

Behavioral signatures

Batching patterns, sweep timing, and fee-setting behavior suggest institutional operation. These are suggestive rather than probative and should not carry a specific name on their own.

Disclosure

Some entities publish addresses, particularly for reserve attestations. This is the only category that is evidence rather than inference, and it is the smallest.

Formula and Measurement Logic

Clustering is a union-find over an address set, where each heuristic supplies merge assertions.

For each transaction: if the common-input heuristic applies, merge the clusters of all input addresses.
If a change output is identified, merge it into the input cluster.

The critical structural property is that merges are one-directional and effectively permanent. Two clusters joined by one transaction stay joined for every subsequent computation. There is no mechanism by which normal processing separates them again, so a single false merge is absorbing: it can only grow.

How Should Address Labeling and Entity Clustering Be Interpreted?

Read every entity-level metric as conditional on a specific label set at a specific version. Two symptoms are worth learning to recognize because they indicate a clustering problem rather than a market event.

• A sudden step in an entity's size with no corresponding transfers. That is a merge or a label update, not accumulation.
• Historical series changing shape between two retrievals. That is a retroactive re-clustering, and it means the earlier chart was wrong or the current one is.

Directional bias

The two dominant heuristics fail in opposite directions and this shapes what you should expect. Common-input over-merges, so the largest clusters are the least trustworthy and whale metrics are systematically exposed to it. Deposit mapping under-covers, so exchange balances are more likely understated than overstated, and the shortfall is worse for venues nobody has tested.

Both biases are systematic rather than random, which means they do not cancel out across a large sample and cannot be averaged away by using several providers.

Coverage is also uneven in a way that matters: heavily researched entities on heavily researched chains have good labels, and everything else does not. A metric aggregating across entities inherits the coverage of the worst-mapped ones.

Step-by-Step Workflow

1. Establish which heuristics produced the cluster you are relying on.
2. For a large cluster, check whether a CoinJoin or collaborative transaction could have merged it.
3. Distinguish a clustering claim from a labeling claim and state which is doing the work.
4. Check whether any part of the label rests on disclosure rather than inference.
5. Record the label set version with any figure you publish.
6. Compare two vintages to detect retroactive re-clustering.
7. Check for step changes in entity size that lack matching transfers.
8. Cross-check exchange clusters against published reserve attestations where available.

Worked Hypothetical Scenario

A whale-tracking series reports that a single entity's balance rose from 8,000 to 47,000 units on one day, and commentary describes it as major accumulation.

Check whether transfers explain it. Total inbound transfers to the cluster's known addresses that day: 340 units.

The other 38,660 units did not move. They were already sitting in addresses that were assigned to a different cluster the day before, and one transaction merged the two.

The merge is either correct, in which case the entity always held 47,000 and the previous day's 8,000 figure was the error, or it is a false merge from a collaborative transaction, in which case today's figure is the error. Either way, the one thing that definitely did not happen is a 39,000-unit accumulation.

The diagnostic is cheap: compare the reported balance change against the sum of actual inbound transfers. Where they diverge by orders of magnitude, the change is structural. This check should precede any statement about entity behavior and almost never happens.

What Can Make the Interpretation Wrong?

• CoinJoin contamination. One collaborative transaction can merge thousands of unrelated addresses through the common-input heuristic, and the merge is effectively permanent.
• Merges are absorbing. Normal processing never splits a cluster again, so a false merge can only grow.
• Clustering and labeling conflated. A correct cluster with a wrong name and a wrong cluster with a right name produce different symptoms and need different checks.
• Systematic bias in both directions. Common-input over-merges and deposit mapping under-covers, and neither averages away across providers.
• Retroactive re-clustering. Historical series change shape when clustering improves, usually without annotation.
• Uneven coverage. An aggregate inherits the label quality of the worst-mapped entity in it.
• Address reuse assumptions. A shared custodial address represents many beneficial owners and clusters as one entity.
• Behavioral labels treated as identification. A pattern suggesting institutional operation does not name the institution.

Cross-Network and Provider Comparison

The available heuristics differ by ledger model, which makes label quality structurally different rather than merely differently resourced.

UTXO chains support the common-input heuristic, which is efficient and propagates labels across many addresses from a single observation. That efficiency is also its danger, since one collaborative transaction propagates a false merge just as efficiently. Change detection is available and is probabilistic.

Account chains have neither heuristic. There are no multi-input transactions in the UTXO sense and no change outputs, so clustering depends almost entirely on deposit-address mapping, disclosure, and behavioral inference. Coverage is therefore patchier for equivalent research effort, though the specific catastrophic failure mode of CoinJoin contamination does not exist there. Contract addresses add a distinct problem: a contract holding pooled user funds is one address representing many beneficial owners, and no clustering technique resolves that.

Privacy-preserving systems remove the linkage the heuristics operate on by design. On those chains the correct answer is that clustering does not work, which is the system functioning as intended.

Advanced Analytical Methods

Cluster provenance tracking

Recording which heuristic and which transaction caused each merge allows a suspect cluster to be audited and, if necessary, unwound. Most pipelines discard this and cannot answer why two addresses are considered the same entity.

CoinJoin detection as a pre-filter

Identifying collaborative transactions by their characteristic structure, such as many equal-value outputs, and excluding them from common-input merging prevents the largest single source of contamination. Detection is imperfect and improves materially on doing nothing.

Confidence-scored labels

Distinguishing disclosed addresses from mapped ones from behaviorally inferred ones, and propagating that confidence through to the metric, produces an error estimate. Almost no published series does this and it is the largest available improvement in the field.

Attestation reconciliation

Comparing a labeled exchange cluster against a published reserve attestation quantifies coverage for that venue directly and bounds the error on aggregate exchange metrics.

Balance-change versus transfer reconciliation

Systematically comparing reported entity balance changes against actual inbound and outbound transfers flags structural changes automatically, which is the check the worked example above performs by hand.

Practical Checklist

• I know which heuristics produced this cluster.
• I checked large clusters for collaborative-transaction contamination.
• I separated the clustering claim from the labeling claim.
• I know which part of the label rests on disclosure.
• I recorded the label set version.
• I compared vintages to detect retroactive re-clustering.
• I reconciled reported balance changes against actual transfers.
• I cross-checked against a reserve attestation where one exists.

Frequently Asked Questions

References

These sources support data structures and methods, not the hypothetical conclusion. Provider formulas, chain rules, and APIs can change. Confirm current documentation before publication.

• Bitcoin Developer Guide: Block Chain: Bitcoin ledger, blocks, proof of work, and transaction history.
• Bitcoin Developer Guide: Transactions: UTXO transaction construction and spending.
• Ethereum.org: Technical Introduction: Accounts, execution, proof of stake, and smart contracts.
• Ethereum.org: Transactions: Ethereum transaction fields and execution.
• Coin Metrics: Network Data Glossary: Cross-network address, account, ledger, and UTXO definitions.
• Coin Metrics: Getting Started With Data: Network, market, index, and reference data.
• Dune: Data Explorer and Raw Tables: Blocks, transactions, logs, traces, and decoded data.
• Dune: Address Labels: Address labeling and entity context.