On-Chain Analysis · 7 February 2026 · 10 min read

Address Clustering and the Ownership Question It Cannot Answer

Clustering heuristics group addresses that probably belong together. They do not name a human, and they do not survive being treated as if they did.

Address clustering is a useful analytical technique that is often asked to do something it cannot. Heuristics group addresses that probably share a controller, and the grouping is frequently right. It is also probabilistic, jurisdiction-shy, and silent on the identity of the human behind the keys. DC-Services uses clustering for what it is — a structural indicator — and refuses to dress it up as proof of ownership.

What Clustering Actually Does

Clustering applies heuristics to on-chain behaviour to group addresses likely controlled by the same entity. The most common is the common-input heuristic, which treats addresses that appear together as inputs to a single transaction as probably co-controlled. Others include change detection, behavioural patterns and known service tagging.

Each heuristic produces a probabilistic grouping with a confidence that depends on the chain, the wallet software used, and the behaviour of the controller. The output is a working hypothesis, not a registration document. Treated as the latter, it produces conclusions that do not survive a competent challenge.

Where Heuristics Quietly Break

Common-input heuristics break against CoinJoin and similar privacy techniques, where multiple controllers deliberately combine inputs to defeat the assumption. Change detection breaks against wallets that randomise addresses or use multi-output structures. Service tagging breaks when services change addresses or share infrastructure.

Each known break is identified by name in the analysis. A cluster produced from a chain with significant CoinJoin activity is annotated to that effect. The output then carries its limitations on the same page as its conclusions, rather than asking the reader to know which heuristics not to trust today.

Co-Control Is Not Ownership

Even where a cluster is correct, it identifies common control, not human ownership. The same controller may be a custodian holding funds for many users, a service operating pooled wallets, or an automated system. Concluding that a cluster's activity reflects a single individual's holdings is a non-sequitur that compliance reviewers spot quickly.

The file records what the cluster supports — common control of a set of addresses on a specific chain, subject to the heuristics used — and what it does not support, in language a reader without a clustering background can follow.

Tying A Cluster To A Person

An address cluster becomes useful as ownership evidence only when separate materials tie it to a specific human controller. Exchange withdrawals into the cluster, signed messages from addresses inside it, device records, recovery artefacts, and contemporaneous correspondence can all do that work. Clustering alone cannot.

The file records each attribution separately and shows the chain of reasoning from on-chain evidence to off-chain identity. Where the chain is incomplete, the gap is named. The cluster is then either supported as a position or held as provisional, never both at once.

How The Output Is Documented

The deliverable presents the cluster with the heuristics used, the confidence level produced, the known limitations of those heuristics on the relevant chain, the attribution evidence available, and the residual unresolved questions. Each section is short and consistent, which is unromantic and also the point.

Counterparties receive a document that reads like a record rather than an assertion. They can rely on what it claims and challenge what it leaves open, instead of relying on the strength of the technique and discovering the limits later.

Clustering Heuristics and Their Limits

Heuristic	What it groups	Where it breaks
Common-input	Co-spending addresses	CoinJoin, PayJoin, batched custodial spends
Change detection	Likely change outputs	Randomised wallets, multi-output structures
Behavioural patterns	Time-of-day and amount fingerprints	Automation, shared infrastructure
Service tagging	Known exchange and service addresses	Address rotation, shared deposits
Attribution data	Off-chain identity links	Outdated tags, leaked credentials

Frequently asked questions

Does an address cluster prove a person owns the funds?

No. Clustering identifies common control of addresses by some controller, subject to the heuristics used. Identifying the human controller requires separate off-chain evidence, and the file states that openly rather than implying otherwise.

How reliable are common-input heuristics?

Generally strong on chains with limited privacy use and weaker on chains where CoinJoin, PayJoin or similar techniques are common. The output records the confidence and the known limitations on the relevant chain at the relevant time.

Can clustering be used in a dispute file?

Yes, as a structural indicator alongside attribution evidence. Used alone it is rarely enough to support an ownership position, and treating it as standalone evidence is one of the more avoidable mistakes in this area.

What happens when a service changes its addresses?

Service tags drift. The file records the date of the tag, the source of the attribution, and whether the address remains in active service use. Stale tags are flagged rather than carried forward as current.

Does DC-Services run its own clustering algorithms?

The analysis uses established techniques and documents which were applied. The deliverable focuses on what the output supports rather than the proprietary detail of any particular implementation.

Clustering earns its place in the file when it is presented as what it is: a structural indicator with named limits. Asked to do more, it becomes the weakest part of the file rather than the strongest.