Cryptocurrency clustering: where the behavioral model errs
Cryptocurrency clustering relies on heuristics of the transaction graph: common input in one transaction, change address, key reuse.
Behavioral features of addresses — activity rhythm, transfer size, counterparty set, share of incoming with batch payouts — refine the picture where links break.
But every assumption has a boundary beyond which false positives of the model grow faster than coverage: a cluster with an incorrect label is worse than no label, because risk and listing decisions rely on it.
The first gap is mixing of flows within services. Custodial wallets, exchange hot addresses and mass payouts pool funds of thousands of clients into one input.
The common-input heuristic merges them into one node, and the model attributes the behavior of a single owner to a service contour.
Service features are readable: regularity by time, even sizes, matching the payout schedule — they should be subtracted before, not after, clustering.
The second is multisignature and contract wallets: an address is controlled by multiple keys, and the signature threshold changes by owners' decision.
The graph breaks when the composition rotates and, conversely, produces false links when one participant reuses their key in different schemes.
Transit addresses add noise: they behave like change, but serve only to move funds between contours and do not carry the behavior of the end owner.
The third is drift of the network itself. Changes in fee structure, migration of users to new address types, and growth in the share of batch operations shift feature distribution.
A model trained on a past snapshot loses accuracy on the current one: thresholds that previously separated now mix classes.
We break down how this is addressed: which features we validate on the graph manually, how we calibrate thresholds, and what we consider an acceptable false-positive rate.
What the model provides: attribution accuracy and analysis speed
The effect of the model is measured not by the "smartness" of the algorithm, but by three numbers: the share of correct merges of addresses into clusters, the time to analyze one chain, and the volume of addresses that had to be labeled manually.
Attribution accuracy is kept at a level where false merging is an exception: an incorrect merge pulls third-party transactions into all reports, so the system leaves a disputed case separate.
Chain analysis speed changes qualitatively. At the input is a graph with assembled clusters and labels of exchanges, mixers and services, and the work reduces to testing hypotheses instead of manually going through transfers.
A chain of average depth is analyzed in minutes, and analysis becomes reproducible: another engineer repeats the same fund route by the same rules.
Reduction of manual labeling and the volume of the address registry are directly connected.
New addresses are labeled by behavior — matching inputs, timings, reuse of an address for change — and the registry accumulates the result: a confirmed label expands the cluster, and a similar case no longer requires a human.
The class of disputed cases remains and is deliberately not automated: mixers with equal shares, bridges between networks, exchange deposits with a shared deposit address.
They go to manual review with an explanation of why the cluster was not merged — this is the price of accuracy, visible in the report.
Approaches to cryptocurrency clustering: rules, features, learning
The choice of approach is determined not by model complexity, but by what data is available at the input and who will maintain the result further.
If there is no labeled sample and it is unclear in advance which classes even exist, supervised learning turns into manual labeling blind — and it becomes outdated faster than it pays off.
Below are three options that teams realistically choose between at the start.
Three options and their limitations
| Option | When it fits | Limitations |
|---|---|---|
| Clustering heuristics: thresholds by transfer volume, share of operations with exchanges, number of active addresses | A quick start is needed, little data, explainability of each decision matters | Thresholds are set manually, break when participant behavior changes, do not scale to new types |
| Supervised learning on a labeled sample | Historical labels exist: exchanges, stablecoins, gaming tokens | Labeling is expensive, rare classes remain uncovered, labels quickly diverge from reality |
| Unsupervised learning on graph features of transfers | No labels, but there is a connected transaction graph between addresses | Requires regular graph recomputation, sensitive to the quality of address normalization |
In practice, approaches are combined: heuristics provide primary labels, supervised learning refines the boundaries between them, graph features add transfer context invisible in a single address.
The acceptance criterion is cluster stability: if, when the observation window shifts, group composition changes insignificantly, the model can be put into monitoring rather than rebuilt every month.
How we build the model: work stages from data audit to handover
The model implementation stages follow a fixed order: first we make sure the data describes behavior, and only then we build the partition.
An error in features at the first step is not corrected by algorithm choice or selection of the number of clusters — that is why data audit and feature schema take more time than assembly itself.
- Data audit. We consolidate sources: network events, address balances and activity, fund movements through exchanges, trading history. We check completeness, gaps, duplicates, time zones and block rollbacks — otherwise cryptocurrency clustering reproduces collection artifacts rather than behavior.
- Feature schema. We define observation windows and calculate over them transaction intensity, holder concentration, turnover, share of large addresses, reaction to volatility. We normalize features and record the source of each — this way assets with different market caps become comparable.
- Model assembly. We select the proximity metric, number of clusters and robustness to outliers, and check partition stability on subsamples and when the window shifts.
- Validation on a holdout sample. We split data by time, not randomly: training on the past, validation on the subsequent period. This excludes look-ahead bias and shows whether the cluster structure persists.
- Interpretation. We compare clusters with known categories — exchange, stablecoin, infrastructure, speculative — and give readable names, otherwise the result does not transfer into decisions.
- Handover and training. We hand over the code, feature schema, recomputation regulations and drift monitoring, and train the client's team — the model remains operational without us.
Handover artifacts: configurations, schemas, regulations, and labels
We hand over not a "model in words," but a kit by which the client's team launches, checks and develops the solution without us.
Code, configurations, labels, and documents live in one repository and are versioned together — no discrepancies remain between what is described and what works.
- Working model — trained weights, launch script and fixed environment: the result is reproduced on the client's data, not only in our sandbox.
- Feature description — a dictionary with formulas: which on-chain and market metrics are calculated, over which aggregation window, how gaps and outliers are handled.
- Merging rules — proximity metric of profiles, merge threshold and minimum cluster size: labels can be reassembled and yield the same result.
- Reference labels — addresses and tokens with labels and snapshot date; every new version is run against them and behavior is compared with the old one.
- Trigger thresholds — what counts as a behavior change, at what value a signal is sent and who receives it.
- Retraining regulation — periodicity, triggers by distribution drift, procedure for validating and publishing a new version.
- Maintenance instructions — deployment, monitoring, rollback to the previous version, and a model card with applicability boundaries.
The kit removes dependence on the contractor: the feature set, thresholds, and labels can be changed in-house rather than rebuilding the solution from scratch.
Case study: how the model reduced the false-positive rate
The task was brought by a team that labeled an address stream manually: a set of rules based on amount thresholds, operation frequency, and wallet age.
The cost of this approach was immediately clear — almost every third alert went to analysis as false, and one disputed group of addresses took an analyst several hours. As the stream grew, the rules had to be extended, and they began to contradict each other.
What the control sample showed
We fixed a sample of manually labeled addresses and did not change it between versions — otherwise there is nothing to compare metrics with.
On it, the rules gave a false-positive rate of about one third and recall for target groups of 0.61: some schemes simply did not get labeled because they did not fit the thresholds.
What we changed and what the result was
The behavior-based clustering model calculates features from transaction history: activity rhythm, counterparty composition, share of transit transfers, density of links within a group.
Clusters are built unsupervised; manual labeling remained only for quality checking — we compared it also with open datasets Chainalysis.
After implementation, the false-positive rate on the same sample dropped to 9%, and recall grew to 0.84. Analysis of a disputed group was reduced from hours to 20–30 minutes: the analyst receives a ready cluster with justification, not a list of addresses.
Honestly about limitations: on young addresses with a short history, the model returns "insufficient data" instead of a guess — such cases go to manual analysis, and this is a deliberate decision, not a gap.
We reassemble the control sample as new types of behavior appear, otherwise the metrics stop reflecting reality.
How does address clustering differ from wallet attribution?
Address clustering answers the question "which addresses belong to one participant," while wallet attribution answers "who this participant is." The first step works only with blockchain data: transactions and links between them.
The second connects external context and turns a depersonalized cluster into an exchange, service, or specific owner.
Within clustering, behavioral heuristics are at work. Joint spending of inputs merges addresses signed by one transaction; reuse of an address for receiving, typical change patterns, and correlated transaction times add links to the graph.
Formally, this is graph clustering with a weight on each edge: the decision to merge is made by the sum of features, not by a single match.
Wallet attribution starts from anchor points — exchange deposit addresses, customer verification data, public project statements, tags in explorers such as Etherscan. Owner identification is matching a ready cluster against these labels.
A single address without clustering covers one transaction branch and provides almost no conclusions.
The difference between approaches is visible in the cost of an error. Clustering errs by false merging: two different participants become one, and the error is replicated across all links. Attribution errs by false label: a service is assigned to the wrong cluster.
That is why clustering is checked for coverage completeness and robustness to mixers, which break the common-input-spending heuristic, while attribution is checked for label accuracy.
The order of work is always the same: first a cluster graph is built, then labels are applied to it. Then owner identification relies on network behavior, not on a guess from a single address.
Technical concerns: data quality, labeling, privacy
Cryptocurrency clustering relies on behavioral features: distribution of volumes by address, regularity of transactions, concentration among large holders.
The dirtier the data and the fewer labeled examples, the higher the chance that the model will find stable groups where there are none.
What to do if transaction history is incomplete?
We do not fill gaps with guesses. We calculate features over windows with sufficient data density, and mark "holey" periods as uncertain — they are not included in the final segmentation but are visible in the report.
Additionally, we cross-check several sources so that an outlier from one does not spread across the entire sample.
How do you check the quality of sample labeling?
We describe the criteria for assigning to a group before the start, and handle disputed cases separately. Part of the sample is labeled independently to measure agreement rather than rely on one person's decisions.
We check stability by recomputing on subsamples and shifted windows: if groups fall apart, we rebuild the features.
What about transaction privacy?
We work with aggregates: addresses are pseudonymized, and distributions, shares, and intervals go into features. Raw addresses and wallet-to-identity links are not fed into the model and do not leave the client's perimeter; we agree on the processing scheme before the start.
Will the result hold when data is updated?
We fix the feature set, selection parameters, and sample composition, and save control runs.
For new data periods, we compare the partition with the previous one: the share of objects that moved between groups is a measurable indicator of stability, and it goes into the report rather than remaining a claim.
Let's discuss the task: what is needed to start work
To come back with a timeline estimate and work plan, not a "plus-minus" range, we need a set of inputs about the data and about what solution you expect.
The more specific the input data, the more precise the stages: feature preparation, training, cluster stability checking, and delivery of the result.
- List of networks and assets: which blockchains and tokens are in scope and how many there are — this determines the volume of snapshots and data preparation time.
- Observation horizon and step: over what period we take activity and at what frequency we recompute — day, week, or month.
- Sources: whether there are proprietary transaction archives or we collect from public explorers; whether exchange metrics on trading and liquidity are needed.
- Access: API keys, nodes, file exports — what already exists and what needs to be arranged.
- Known groups: assets that you definitely assign to one category (stablecoins, exchange tokens) — we use them to check that the model distinguishes the obvious.
- Features and similarity criterion: address behavior, holder distribution, frequency and volume of transfers — what matters more to you.
- Result format: asset labeling by groups, a report with cluster profiles, or regular recomputation on new data.
- Constraints: privacy, data storage requirements, whether decision explainability and export into your system are needed.
Describe the task in free form — we will come back with an estimate and work plan: stages, data composition, and acceptance criteria.