Clustering Related Addresses: Signals and Their Weight

Cluster addresses by scoring signals rather than by drawing lines. Give each signal a weight that reflects how hard it is to produce by accident, require at least two signals that fail for independent reasons, write down the ordinary situation that would explain the group without a common operator, and attach a confidence band to the result. A cluster is a hypothesis with a number on it.

The alternative, which is what most published clustering looks like, is a graph that shows connections without showing weights. Such a diagram is persuasive out of proportion to its evidence, because visual adjacency reads as relationship and the reader has no way to see that one edge means "signed together" while another means "both received money from a popular exchange".

What clustering can and cannot be

Clustering answers one question: do these addresses behave as though a single process or party moves them? It does not answer who that party is, and on this site it is never used to try. The output is a group with a confidence level, useful for reading a market, sizing an operation or separating one operator's activity from background flow.

The ceiling is set by the medium. Control is off chain. A single operator can run addresses that never touch, fund them from separate sources, use them at separate times and leave no observable link. Conversely, addresses can look tightly linked while being operated by different people using the same infrastructure. Clustering measures observable coupling, and coupling is a noisy proxy for control.

Six signals and their weight

Weights below are ordinal rather than numerical facts: they express how hard each pattern is to produce without a genuine relationship. Use them to force a ranking rather than to compute a score you then treat as precise.

The gap between the top two rows and the bottom two is the whole message. The high-weight signals require access to keys or an explicit on-chain permission, which is expensive to fake and rare by accident. The low-weight signals require only that two parties made similar choices, which happens constantly in a market where a small number of tools and venues dominate.

Co-signing, the one strong signal

A Solana transaction can require several signatures, and each required signer had to authorise it with a private key. When two addresses both appear as required signers on the same transaction, somebody had access to both keys at the same instant. That is materially stronger than any behavioural pattern, and it is the closest thing this field has to direct evidence.

It is not conclusive. Multisig arrangements exist precisely so that separate parties can co-authorise, and a counterparty signing an agreement transaction is co-signing without being the same operator. The honest reading is that co-signing shows the keys were used together, which usually indicates a common process and occasionally indicates a negotiated transaction between different parties.

Authority relationships sit at similar strength for a related reason. When an account is recorded as the authority over a token account, a stake account or a program-owned account, the ledger itself is recording a permission rather than a coincidence. Check who set the authority and when, because delegation to a protocol is an entirely different fact from delegation to another user wallet.

A scoring sheet, worked

The sheet exists to stop the strongest impression from becoming the conclusion. Score each signal present, note its weight, and note explicitly whether two present signals could share one cause. The example uses placeholder labels and describes no real accounts.

• SET wallet-A, wallet-B, wallet-C
• S1 shared funder, fan-out 3,400 recipients -- weight: negligible
• S2 timing correlation, same 40-second window -- weight: low
• S3 identical route and fee settings -- weight: low
• S4 co-signing evidence -- absent
• S5 authority relationship -- absent
• DEP S2 and S3 share one cause: the same software
• OUT "consistent with one process"; NOT "one operator"

The dependency line is the one that does the work. Three signals sounded like a case until the sheet noted that two of them are produced by the same mechanism, which reduces three pieces of evidence to two, one of which is worthless on its own because thousands of accounts share that funder. The output sentence shrinks accordingly, and shrinking is the correct behaviour.

Now change one input. Add a transaction on which wallet-A and wallet-B are both required signers. The sheet gains a high-weight signal that fails for an entirely different reason than the behavioural ones, and the honest output moves from "consistent with one process" to "the keys for A and B were used together on a stated date, and all three share an execution pattern". That is a real finding, and it still names nobody.

Looking for disconfirming evidence

Every scoring pass should include a deliberate search for evidence against the group, because confirmation is easy to accumulate and almost nobody looks for the opposite. Four checks catch most bad clusters.

• Do the accounts ever transact with each other at arm's length, in a way that would be pointless within one operation?
• Do they operate simultaneously in ways one process would not, such as taking both sides of the same trade at a loss?
• Does the shared funder or shared destination have a fan count large enough to make the overlap meaningless?
• Does the shared behaviour predate the accounts, in the sense that it is a widely used default rather than a distinctive configuration?

If any check comes back positive, say so in the finding rather than dropping it. A cluster reported with its disconfirming evidence attached is more useful to the next reader than a clean one, because it shows where to push if the question ever matters enough to revisit.

Heuristics that do not transfer to Solana

Most published clustering method was written for Bitcoin, and the flagship heuristic does not port. In a UTXO system, spending several inputs in one transaction normally requires the keys for all of them, so common input ownership is a strong default assumption. Solana has no inputs in that sense: a transaction names accounts and requires signatures only from those that must authorise something.

Change addresses do not port either. Bitcoin change outputs create a rich vein of heuristics about which output returns to the sender. Solana accounts persist and are reused, balances are modified in place, and there is nothing structurally equivalent to a change output to reason about.

What Solana offers instead is the account model itself: explicit authority fields, associated token accounts derived deterministically from an owner and a mint, and program-derived addresses that belong to protocols. These are more informative than change heuristics ever were, because they are declarations rather than inferences. The analyst's job is to read the declarations rather than to import assumptions from a different data model.

When the cluster is a product feature

A large share of tightly coupled wallet sets on Solana exists because running several wallets is a documented feature of the software being used, not because anyone is concealing anything. Trading desks split flow across accounts for execution reasons; testing runs use fresh accounts by design; distribution operations fan out by definition.

This is why reading the documentation of tools that operate wallet sets is legitimate analytical work. A Solana volume bot platform that describes how many wallets a run uses, how they are funded and what each one does gives you a documented reference pattern, and comparing an observed cluster against a documented pattern is a far better test than deciding from the shape of the graph what the operator must have intended.

Bundles, snipers and grouped execution

Grouped execution produces some of the most cluster-like patterns on the network, and the mechanisms differ in ways worth knowing before you score them. Bundling submits several transactions to be executed together in a defined order, which produces very tight slot-level co-occurrence between accounts. Sniping races to transact at a specific moment, which produces near-identical timing across accounts with no relationship other than a shared target.

Those two produce timing correlation for entirely different reasons, and neither implies a common operator. The distinctions between tool classes are worth understanding for exactly this reason, and a comparison such as volume bot vs bundler is useful to an analyst rather than only to an operator, because knowing which mechanism produces which artefact is the difference between reading a bundle as one operation and reading it as a conspiracy of strangers.

Recording a cluster honestly

Write the group, the signals present with their weights, the dependencies between signals, the disconfirming checks you ran, and a confidence band in words rather than a percentage you cannot justify. Three bands are enough: consistent with one process, probable common operation, and strong evidence of shared key use. Nothing above the third band exists in public data.

Date the cluster and treat it as perishable. Wallet sets change: accounts are retired, new ones are provisioned, tools are swapped, and an operator who ran one pattern last quarter may run another now. A cluster with no date is a claim about the present made from evidence about the past, and it will be quoted long after it stopped being true. The same problem applies to the names you attach, which is the subject of labelling what you find.

How this method fails

The dominant failure is shared software mistaken for shared control. Popular tooling imposes its own rhythm on every account it touches, so behavioural similarity measures tool adoption rather than operator identity. Where one tool has many users, behavioural clustering will confidently merge unrelated operators, and it will do so more confidently the more users the tool has.

The second failure is compounding weak signals. Four low-weight signals do not add up to a high-weight one when they share a cause. Analysts count evidence instead of counting independent mechanisms, and the arithmetic of that mistake is not small: it turns a coincidence into a case file that reads as though it were carefully built.

The third is scale. In a network with an enormous number of accounts, patterns that seem improbable for a specific pair occur constantly somewhere, so searching a large space for a pattern and then treating the discovery as improbable inverts the reasoning. That failure has its own page in false positives and honest conclusions, and it is the one that catches experienced people.

What this desk will not cluster

Two things are outside the method entirely. The first is any clustering exercise aimed at reaching a person: correlating on-chain timing with off-chain activity, combining name services or profile data to build an identity index, or joining chain data to any leaked dataset. Those techniques exist, and their realistic use is exposure rather than analysis.

The second is publishing clusters of real addresses as findings about named projects or individuals. A group that is probably right about a process becomes an accusation the moment it is attached to a name, and readers reliably strip the confidence band when they repeat it. The method belongs in public; the case file does not, and a published cluster is a permanent claim built on evidence that was always provisional.

Questions this page gets asked