Address Clustering and the Limits of On-Chain Attribution

Address clustering is the process of grouping on-chain addresses that behave as if controlled by one wallet. It uses heuristics — common-input ownership, change-address detection, repeated co-spending — to infer that two addresses share a controller. The result is a structural inference about the ledger, not an identification of any person, and a documentation file that treats the two as equivalent introduces a category error at its foundation.

Clustering is useful where the records the client supplies cross several addresses controlled by the same wallet software. It allows reconstruction of a single counterparty graph from entries that would otherwise look unrelated. The engagement file records which heuristics were applied, the software or library used, and the version, so that any later reviewer can rerun the same clustering against the same chain state and reach the same grouping.

Heuristic limits are recorded alongside the result. Common-input ownership breaks where the wallet uses coinjoin, multi-party signing or batched-payment services. Change-address detection breaks where the wallet client deliberately reorders outputs or uses non-standard scripts. Each break is noted at the position it affects, and the cluster is narrowed or marked uncertain rather than presented as a single confident grouping.

Attribution sits a layer above clustering and the file treats the two separately. A cluster shows that a set of addresses behaves as one wallet; attribution claims to know who that wallet is. Attribution requires evidence outside the chain — a venue confirmation, a signed message, a device record or correspondence that ties the wallet to a named party. Without that evidence the file records the cluster and stops.

Cross-chain attribution is treated more cautiously again. A bridged transfer connects activity on one chain to activity on another, but the bridge's own ledger sits between the two and may itself be custodial. The file records what each chain shows, what the bridge confirms, and where the inference depends on the bridge operator's records rather than on the public chains the engagement examined.

Third-party labels are noted as labels, not as findings. A commercial analytics provider may tag an address as belonging to a venue, a service or a sanctioned entity. The file records the label, the provider, the date, and treats it as supporting context. It does not adopt the label as the firm's own finding without source records that independently support the same classification under the engagement's methodology.

Counterparty reviewers care about the boundary because a file that overreaches on attribution is a file that invites them to discount every finding inside it. A reviewer who sees the cluster, the heuristics, the limits and the separate attribution layer can rely on each conclusion at its actual weight. A reviewer who sees one confident graph with no method shown has to discount the whole document.

DC-SERVICES does not certify on-chain attribution, does not provide investigative conclusions, and does not present clustering as proof of identity. The work is documentation: apply the heuristics, record the method, mark the limits, preserve third-party labels as labels, and deliver a source-linked file in which the cluster, the attribution and the gap between them are all visible to the reviewer reading the deliverable.