Wallet clustering basics: joining addresses honestly

A wallet cluster is a hypothesis that several addresses are driven by one operator. It rests on observable edges between accounts, never on identity. Wallet clustering on Solana matters because it turns an inflated address count into a smaller count of decision makers, and it is risky because every edge has a mundane explanation.

A cluster is a hypothesis, not an identity

Clustering answers one narrow question: do these addresses behave as though a single party controls them. It does not answer who that party is, where they operate, or whether anything they do is improper. The moment a cluster claim slides from behaviour to identity, it stops being chain analysis and becomes speculation about people, and this desk does not publish that step.

The value of a cluster is arithmetic. A pair that reports several hundred distinct trading addresses in a session may resolve to a much smaller number of operators once funding and fee payment are followed. That reframes unique wallet analysis entirely: the raw address count becomes an upper bound on participation, and the cluster count becomes the lower bound. The honest reading lives between the two.

A cluster also proves no wrongdoing. Running many wallets is a normal choice for market makers, treasuries, custodial products and produced-volume services alike, so a cluster shows only that participation is narrower than the address list suggests.

The funding edge and the graph it builds

Every account that trades on Solana needs SOL, because each signature carries a base fee of 5000 lamports and a lamport is one billionth of a SOL. That SOL arrived from somewhere, and the transfer that first funds an otherwise empty address is the most informative relationship available: it happens once and is rarely repeated by accident.

A funding edge is therefore directed: source address to funded address, with a timestamp and an amount. Direction matters, because Wallet A funding Wallet B describes setup while the reverse edge usually describes a sweep of proceeds. Funding graph analysis assembles those edges into a graph where nodes are addresses and edges are transfers, then reads the connected components as candidate clusters.

The technique is borrowed from chains where one heuristic, common input ownership, does most of the work. Solana has no equivalent, so no single edge carries that weight here, and hop discipline keeps the method usable. One hop from a funded address to its funder is strong. Two hops are readable only when the intermediate node has a low out-degree. Three hops usually merge unrelated populations, because a few very high degree service addresses sit within a short walk of nearly everyone. That does not make deeper edges wrong, only undiscriminating.

Building a small funding graph from public data

The sequence below builds a two-hop graph around a few candidate addresses using nothing but a public explorer such as Solscan and the history it exposes, alongside the collection discipline set out in the note on gathering evidence from chain data. It uses placeholders throughout, because the desk does not publish real addresses in worked examples and the method does not depend on them.

1. Fix the seed set. Take the addresses you actually observed trading in the window, and freeze the list before any expansion. Call them Wallet A, Wallet B and Wallet C.
2. Find the first inbound SOL transfer. Walk each seed back to its earliest inbound native transfer and store a directed row: source, destination, amount, slot. Record edges, not conclusions.
3. Measure the degree of every source. For each funder discovered, count its distinct destinations overall. This is the most important number in the exercise.
4. Remove the hubs. Set a degree ceiling before you look at results, and delete any source above it. High-degree funders are services, and leaving them in connects everything to everything.
5. Take the connected components. What remains splits into small components. Label one Cluster 1 and keep the rest as separate candidates rather than merging them for convenience.
6. Expand one hop only. For each surviving funder, add its other destinations as provisional members, marked provisional in the data rather than in a footnote.
7. Look for a second, independent edge. Check whether members of Cluster 1 also share a fee payer, a rent payer or same-slot activity. One edge type alone leaves a candidate.
8. Write down what you excluded. Record the degree ceiling, the hop cap and every address removed as a hub, so a reviewer can rebuild the graph and argue with the thresholds.

The output is not a cluster but a candidate component with a documented construction, and whether it becomes a cluster depends on the edges below.

The fee payer heuristic on Solana

On Solana the account that pays a transaction fee is the first signer listed in the message, and it does not have to be the account whose tokens are moving. A transaction can be signed by a trading account and paid for by a separate account entirely, provided both signatures are present. The Solana documentation treats this as ordinary transaction structure rather than a special case.

That separation makes fee payment a strong edge. Funding a wallet once can be an accident of provenance; paying its fees across many transactions is an arrangement, because someone configured a payer key and kept using it. When several trading accounts share one payer through a session, the operational link is far harder to explain as coincidence.

The edge still fails in a specific way. Fee abstraction is a product: relayers, custodial platforms and sponsored-transaction services exist so that a user needs no SOL in hand, and every customer of one shares a fee payer with strangers. A shared payer is strong only after the payer itself has been checked for the breadth that marks a service.

Token account creation as a weak edge

An SPL token balance lives in a token account, and the associated token account for an owner and mint is derived deterministically by the program documented in the Solana Program Library. Creating that account costs rent, and the instruction names the payer. That payer is recorded permanently and readable long afterwards.

The rent payer is a real edge and a weak one, because the associated token account for any owner can be created by anyone: the payer needs no permission, and airdrop tooling and launch scripts create accounts for strangers routinely. What carries slightly more weight is the sequence. A batch of accounts for one mint, created by one payer in a tight run of slots immediately before the owners trade, describes a setup routine rather than a series of favours. Even then it corroborates a funding or fee edge rather than replacing one.

Timing co-movement and shared route preference

Solana targets roughly 400 millisecond slots, which makes co-occurrence measurable at a fine grain. If Wallet A and Wallet B repeatedly act inside the same or adjacent slots, in the same order, that regularity is an edge. It suggests a common dispatcher rather than two humans who happen to be awake together, and it strengthens with repetition.

Timing is correlational, so it inherits every weakness of correlation. Reactive traders cluster in time by construction: a price move or a social post pulls dozens of unrelated participants into the same second, and copy-trading produces the same shape with one leader and many independent followers. Timing overlap alone proves nothing about control.

Shared program or route preference is weaker still. Two addresses that always swap through the same aggregator, or that take the same pool path, look similar only because a small number of routes dominate normal Solana usage. Routers are shared infrastructure; using one is the default, not a signature. Treat route similarity as a tie-break between otherwise equal candidates, never as an edge that admits a wallet to a cluster. The same caution applies to behavioural similarity generally, including the repeated buy and sell pairs discussed in the note on round trips and self-trading.

Combining edges into a score that is not calibrated

Because no single edge settles the question, analysts combine them. The usual approach assigns each edge type a weight, sums the weights found between a candidate and an existing cluster, and admits the candidate above a threshold. That is reasonable bookkeeping. It becomes dishonest only when the number is presented as though it had been validated against known ground truth.

That is the whole caveat. Nothing above calibrates 4 against 2, and no labelled set of confirmed operators exists against which a threshold of 8 could be tested. The score ranks candidates consistently inside one study, which is useful. It does not convert into a probability, and printing it as a percentage would manufacture precision the evidence cannot support.

The false positives that defeat each heuristic

Each edge type has a characteristic way of being wrong, and the failures are not interchangeable. Knowing which service shape breaks which heuristic separates a cluster that survives review from one that quietly merged an exchange customer base into a single fictional operator.

Two further sources are easy to miss. Launchpad and protocol fee accounts touch enormous numbers of unrelated transactions, and a graph that does not exclude them will fuse every participant in a venue into one component. Shared custody is subtler: independent parties can sit behind one key, producing perfect edges that describe an arrangement rather than an operator.

What a cluster write-up must state before it is publishable

Multi-wallet operation is not exotic. It is a standard, openly documented setting in commercial tooling, where wallet count, funding routine and schedule are ordinary parameters a buyer sets. The vendor side of Solana volume automation shows how those settings produce exactly the edges described above, which is why addresses moving together are a starting hypothesis about configuration rather than an accusation.

That framing shapes the write-up. A cluster document must let a reader reject its conclusion using the same evidence, so thresholds, exclusions and unresolved alternatives belong in the text rather than in a private notebook.

• The seed set is listed, with the selection criterion stated before any expansion.
• Every edge type used is named, and the ones deliberately not used are named too.
• The hop cap and the degree ceiling for hub removal are given as numbers.
• Every address excluded as a hub is listed, with its observed degree.
• Weights and the admission threshold are printed, with a plain statement that they are analyst choices and not calibrated.
• Placeholders are used throughout, and no real address is printed alongside a manipulation claim.
• At least one alternative explanation is stated in full, not dismissed in a clause.
• The observation that would overturn the cluster is written out concretely enough to test.
• A confidence band is attached to the cluster itself, separately from what the cluster is taken to mean.
• The window, data source and collection date are recorded so the graph can be rebuilt.

The last item is the one most often skipped, and it matters more than the scoring: a cluster is a construction, and constructions are arguable only when their inputs are visible. The wider standard for attaching bands to such claims is set out in the note on stating confidence honestly, and the terms used here are defined in the glossary.

This page will not explain how to make these edges harder to observe. The desk publishes detection method, not evasion guidance: describing how an edge fails is necessary for honest analysis, while describing how to remove it serves no analytical purpose.

Questions this desk is asked