1. A cluster is an analytical object, not a person
A wallet cluster is a set of addresses grouped because one or more observed patterns suggest shared control, coordination or purpose. The cluster is produced by a method; it is not a fact already written on the chain. Public ledgers expose transactions, contract calls and events. They do not expose the legal identity, intent or device behind an address.
An investigation should preserve three layers: observations, relationships and attribution. An observation might be a transaction signed by one key. A relationship might say two addresses repeatedly fund the same operational wallet. Attribution is the stronger claim that a known entity controls them. Moving between those layers requires additional evidence and a record of uncertainty.
The product consequence is simple: a graph should never turn a grouping rule into a label that looks like identity. A line can mean shared funding, deposit reuse, contract interaction or confirmed control. Each meaning needs its own type, evidence and limits.
2. Define the question before generating the graph
Clustering without a defined decision produces an attractive but unbounded map. Start with the question: are funds connected to a designated service, is an exchange deposit reused, does a bridge path preserve value, or are several addresses likely managed by one operation? The question determines networks, time range, asset scope and acceptable error.
A compliance review may surface false positives for human review, while an enforcement referral demands a much higher evidentiary threshold. A product-fraud model can act on probability when the consequence is reversible, such as requesting another verification step. It should not present the same probability as a public allegation.
Record the purpose, authorised sources and intended audience in the case header. That prevents an exploratory cluster from being reused as if it had been validated for account closure, asset seizure or publication.
3. Every heuristic has a failure model
On account-based chains, common-input logic from UTXO systems does not transfer cleanly. Shared funding can indicate one operator, but it can also reflect an exchange, paymaster, treasury or batch service. Reused nonce patterns, synchronized timing, gas sponsorship and repeated counterparties can strengthen a hypothesis, yet automation creates the same signals at scale.
Deposit-address reuse may connect activity to a service, but not necessarily to one customer. Smart contracts add routers, aggregators, relayers and vaults whose addresses represent roles rather than owners. Bridges add source senders, protocol contracts, attesters, relayers and destination recipients. Treating them all as identity participants inflates clusters.
For each heuristic, store a failure model: what benign behavior can create the signal, what data is missing, and which observation could disconfirm the link. This turns uncertainty into a testable field rather than an endnote.
4. Use evidence tiers instead of one confidence score
A single score such as 92% hides incompatible reasons. A better schema uses evidence tiers. Tier one is chain-native observation. Tier two is a reproducible relationship created by a documented rule. Tier three is corroboration from an independent source. Tier four is verified attribution supported by authoritative or directly confirmed records.
The tiers should not be added arithmetically. Five weak timing similarities do not equal one verified customer record. Correlated providers also should not be counted as independent when they ingest the same tag. Provenance records origin, collection time, query, parser version and transformations.
The interface can summarize strength while allowing a reviewer to open the evidence packet. It should show the claim, supporting and conflicting observations, alternative explanations, source restrictions and the next evidence that would change the assessment.
5. Entity resolution needs negative evidence
Investigators naturally collect confirming links. Reliable entity resolution also searches for contradiction. Addresses believed to share control may transact simultaneously from incompatible custody systems or be identified by authoritative records as different customers. Those facts should weaken or split the cluster.
Build explicit exclusion rules. A known exchange hot wallet should not merge every depositor and withdrawal recipient. A protocol router remains infrastructure without separate evidence. A bridge relayer is not the beneficiary. An address whose role changes over time may require time-bounded membership.
Version every merge and split. If new evidence breaks a cluster, previous reports retain the historical assessment while being marked superseded. Deleting the old grouping makes past decisions impossible to explain; preserving it without status risks continued misuse.
6. Cross-chain identity is a claim about continuity
Moving value across chains does not automatically move identity. A protocol message may prove that a source action resulted in a destination mint or release. It does not prove that source sender, relayer and destination recipient share ownership. Distinguish protocol continuity, economic continuity and control continuity.
Protocol continuity relies on message identifiers, nonce, domains and destination execution. Economic continuity reconciles gross value, fees, slippage and timing. Control continuity requires separate evidence such as wallet signatures, verified service records or an operational pattern strong enough for the intended decision.
Dor Arad’s recommended graph keeps these edges separate. A bridge edge can be confirmed while the ownership edge remains unknown. That is not incomplete analysis; it is the precise result the evidence supports.
7. Off-chain intelligence must remain attributable
Exchange records, domain registrations, device data, sanctions lists and service disclosures can materially change an assessment. They also introduce access restrictions, privacy duties and varying reliability. Keep the source separate from the analytical note and describe whether a reviewer can independently access it.
A vendor tag should include the vendor, tag version, observation date and scope. A court filing or official designation should link to the exact document and legal status, not be summarized as guilt. Customer records should be used only under relevant authority and shared on a need-to-know basis.
When a source cannot be exported, the report should state that limitation. A restricted source can support an internal decision, but it changes what an external reviewer can reproduce.
8. Build an explainable case object
A durable case object contains the question, scope, datasets, observations, relationships, attributions, alternatives, reviewers and decisions. Each edge references immutable evidence identifiers. Each analytical claim has an author, timestamp, method and status. Automated suggestions remain distinct from human-accepted findings.
Exports should preserve those distinctions. A flat CSV of addresses and scores discards the reason a link exists. A useful export includes edge types, source references, time bounds, parser versions and caveats. It should be possible to remove a source and see which claims become unsupported.
Access controls should follow sensitivity, not only project membership. Public chain data may be open, while personal identifiers and restricted records require narrower access and audit logs. Collect only what is necessary for the authorised purpose.
9. Test adversarial and ambiguous cases
A clustering engine should be tested on cases designed to fool it: exchange fan-out, paymasters, mixers, bridge relayers, multisig rotation, contract upgrades, address poisoning, dust, batch settlement and two unrelated users acting at similar times. The correct output is often a candidate or no conclusion.
Measure precision and review burden for each heuristic and consequence. A lead-generation tool can tolerate more candidates than an automated restriction system. Test the human interface too: do reviewers notice conflicting evidence, understand edge types and avoid assuming that the biggest node is the primary actor?
Use synthetic ground truth where real ownership cannot be ethically or reliably established. Re-run tests when parsers, providers or clustering rules change, because model drift can come from infrastructure rather than machine learning.
10. Write conclusions at the strength of the evidence
A disciplined conclusion states what was observed, what was inferred and what remains unknown in separate sentences. For example: the transactions show repeated funding from one service-controlled wallet; timing and amounts support a coordination hypothesis; available evidence does not establish that one person controls every recipient.
Name alternatives and the evidence that would distinguish them. A service record, signed message or verified account link may support stronger attribution. Contradictory custody records may weaken it. Assign owners to open questions so uncertainty becomes a work queue rather than a permanent footnote.
Blockchain intelligence is most useful when it can survive disagreement. The goal is not the largest cluster or highest score. It is a decision trail in which another qualified reviewer can understand the method, reproduce material links and see exactly where confidence stops.