Wallet relationships and clustering
Two wallets are related when funds move between them. Wallet Sleuth records those movements as a directed graph, scores how strong each tie is, and groups wallets that appear to share an owner. This page explains the scoring, what a cluster does and does not claim, and the detectors that look for coordination across a list of wallets.
What counts as a relationship
Only direct transfers between wallets form a tie. Swaps are excluded on purpose: a trade against a liquidity pool is an interaction with a venue, not with another person, and including it would connect every trader of a token to the same handful of contracts. Program and pool addresses are also filtered out at ingest so routing traffic never appears as a relationship.
Relationship strength
Each tie carries a strength between 0 and 1, recomputed whenever a new transfer lands. It blends four signals:
| Signal | What it measures | Direction |
|---|---|---|
| Frequency | How often the pair transacts over the period they have been active | More often is stronger, with diminishing returns |
| Recency | How long ago the last transfer happened | Decays over time with a fixed half-life, so old ties fade rather than vanish |
| Amount regularity | How similar the transfer amounts are to each other | Consistent, repeated amounts are stronger than random ones |
| Volume consistency | How evenly the value is spread across transfers | A steady flow is stronger than one outlier |
Frequency and recency carry the most weight. A pair that transfers often, recently, and in similar sizes reads as an ongoing relationship. A single transfer years ago reads as almost nothing.
Clusters
A cluster is a set of wallets believed to belong to one entity. Three things create or grow them:
- Human confirmation. Merging wallets on a tracking page or in an address book records a confirmation on the cluster. This is the strongest signal in the system.
- Shared names. Wallets given the same nickname on the same tracking page are folded together.
- Community detection. On request, the whole graph is partitioned by a modularity-based algorithm that groups wallets with dense ties among themselves and sparse ties to everyone else. The groups it finds become suggested clusters at low confidence, waiting for a person to confirm or split them.
Cluster confidence is a weighted blend of the cluster's size, how densely its members are connected to each other, how strong those internal ties are, how many people have confirmed it, and whether members share a name. Human confirmation is deliberately the heaviest term, so a large algorithmic grouping nobody has checked stays below a small cluster two people have confirmed.
A cluster is a working hypothesis, not proof of common ownership. Exchanges, bridges and services are excluded from clustering where they are recognised, and a cluster's page always shows the evidence it rests on.
Discovery in audits
A wallet audit starts from the list you submit. For each submitted wallet, it looks one hop outward at the addresses that received funds from it, keeps the ones that look like wallets rather than contracts or exchanges, and nests each under the submitted wallet that funded it first. These discovered wallets are valued for their holdings so the report can show wealth that sits one step away from the client's own addresses. They are not analysed for risk or behaviour, and the total is capped so a very large audit stays tractable.
Cross-wallet detectors
After every submitted wallet has been analysed, the audit looks across the whole list for patterns no single wallet shows on its own:
| Detector | What it looks for |
|---|---|
| Shared funding source | Several submitted wallets received funds from the same outside address. Exchanges and well-known infrastructure are excluded, since sharing a Binance hot wallet is not sharing a funder. |
| Coordinated buying | Several wallets bought the same token within a short window of each other. |
| Uniform trade sizes | Several wallets bought the same token in near-identical amounts. |
| Circular flow | Funds travel in a loop among submitted wallets. |
| Aggregate concentration | The audited wallets together hold a large share of a token's available liquidity. |
| Widely held token | One token is held by a large share of the submitted wallets. |
Each detector has a minimum number of wallets before it fires and a tuned threshold that is not published. When one fires, every wallet involved receives a risk factor and the report gains one finding naming them.
Scout canvas grouping
The Scout investigation canvas also groups wallets, but only for layout. Wallets the same number of hops from the starting point that share a source or destination are collapsed into one node so the picture stays readable. Any wallet with a label, a flag, or an exchange tag is kept visible on its own. This grouping says nothing about ownership and is not stored.