When compliance teams, regulators, or investigators evaluate blockchain analytics providers, the conversation almost always starts the same: How many services have you identified?
On the surface, it seems like the right question. More attributed entities, or clusters, should translate to broader coverage, and broader coverage should lead to more comprehensive intelligence. But that conclusion depends on a critical assumption: that the clusters themselves are accurate. In practice, some analytics firms do not uphold rigorous standards for their data, leading to inaccuracies.
As the first mover in blockchain intelligence, Chainalysis has spent more than a decade building a comprehensive map that connects pseudonymous blockchain addresses to real-world services and entities. This work involves three distinct steps:
- Structural — determining that separate addresses share the same key control
- Attribution — linking a group of addresses to a named entity
- Operator vs Beneficiary — demonstrating that the entity actually runs the wallet, and doesn’t just use it
These three analytical outcomes are often collapsed into the single term “cluster,” making it difficult to compare the quality of different providers’ data. This matters because if the data is wrong, a compliance professional or law enforcement investigator will waste time and resources chasing a false lead. The downstream effects can be even worse: a single incorrect attribution can discredit hundreds of related insights. Understanding those distinctions is critical, and we’ll explore them in more detail below.
The term “cluster” is too broad
The term “cluster” entered the blockchain analytics vocabulary over a decade ago, when Bitcoin was the only blockchain around. Researchers surmised that when multiple addresses appear as inputs in a single transaction, whoever signed that transaction must have controlled all of them. They called groups of addresses “clusters.” The term helped them define – and track – ownership onchain.
Today, that once-narrow word is broadly applied to any group of addresses believed to be jointly owned. It’s become a standard term of the analytics industry. The problem is that it conflates the three distinct claims above.
Consider an exchange. Structural analysis may identify thousands of addresses under common control. Attribution links those addresses to the specific exchange. Operator-beneficiary analysis determines those wallets are operated by the exchange itself and not a nested service or a customer. All three make up the “clustering” process, but they each represent a fundamentally different analytical claim requiring processes and standards.
Cluster count alone is meaningless
Because these claims are frequently combined into a single metric, cluster counts alone reveal very little about data quality. Organizing our thinking around these three distinct, standardized parts helps us ensure the accuracy of the clusters we create. A provider may excel at structural grouping but have weaker attribution standards. Another may accurately identify services but struggle to distinguish operators from users. Without understanding the standards supporting each claim, it is impossible to meaningfully compare two cluster datasets.
Separating these claims allows them to be evaluated independently, making it easier to assess the breadth, depth, and quality of any blockchain intelligence dataset.
A cluster built through rigorous, evidence-based analysis may look identical — in the count — to one stitched together by a machine learning model. Both add “1” to the total number of clusters.
As a result, cluster count comparisons alone can reward the wrong behavior. Providers that apply looser grouping methods or accept weaker attribution evidence will naturally produce more clusters. Providers that maintain stricter standards and refuse to label a cluster until the evidence meets a high bar may produce fewer. By only asking for the cluster-count metric, the less rigorous provider might win.
This is why cluster count, while useful, should not be viewed in isolation. A high-quality blockchain analytics provider should demonstrate broad and deep coverage while also maintaining high standards for structural, attribution, and operator claims.
Questions every provider should be able to answer
Evaluating the claims behind a cluster count is critical to ensuring the success of any investigation or compliance program built on them. Here are questions any provider should be able to answer about any cluster it produces:
- How were these addresses grouped? Is the method deterministic and reproducible, or probabilistic? Can it be audited?
- What kind of evidence links this group to a named entity? Can the provider characterize the source, its independence, and its reliability?
- Is the structural grouping independent of the attribution? If the label changes, does the grouping still hold?
- Has the operator-beneficiary distinction been assessed? Is the named entity actually running this wallet, or is it a user of someone else’s infrastructure?
None of these questions require a provider to reveal proprietary methods. They require describing what kind of claim is being made and what evidence supports it. They break through the problem of non-standardized language. For example, a provider should be able to explain whether a cluster was created through deterministic ownership heuristics, with standalone attribution evidence, or operator analysis, and what evidence supports each conclusion.
The next time you’re evaluating blockchain analytics, don’t just ask “how many do you have?” Ask “how do you know?”
To learn more about Chainalysis’s data standards, read Defining The Cluster, our formal ontology for address analysis and intelligence claims. For more questions to ask your blockchain analytics provider about data quality, see our blog.
This website contains links to third-party sites that are not under the control of Chainalysis, Inc. or its affiliates (collectively “Chainalysis”). Access to such information does not imply association with, endorsement of, approval of, or recommendation by Chainalysis of the site or its operators, and Chainalysis is not responsible for the products, services, or other content hosted therein.
This material is for informational purposes only, and is not intended to provide legal, tax, financial, or investment advice. Recipients should consult their own advisors before making these types of decisions. Chainalysis has no responsibility or liability for any decision made or any other acts or omissions in connection with Recipient’s use of this material.
Chainalysis does not guarantee or warrant the accuracy, completeness, timeliness, suitability or validity of the information in this report and will not be responsible for any claim attributable to errors, omissions, or other inaccuracies of any part of such material.
