Clustering heuristics and their limits · Lesson 5 of 6
Attribution and labeling
7 min read
A cluster tells you that addresses belong together; a label tells you who or what they belong to. Labels turn graphs into findings ("funds reached Exchange K", "the address belongs to a bridge contract"), and they are also where the most damaging errors enter a report. This lesson covers where labels come from, how to grade and version them, and the ethical limits that keep attribution focused on services and organizations rather than private people.
What a label is
A label is a claim: that an address or cluster is controlled by a named entity, or belongs to a category of activity. It has three parts:
- Subject: an address, a contract, or a cluster at a given block height.
- Assertion: an entity name ("Exchange K"), a category ("exchange deposit", "bridge", "mixer", "exploit", "scam"), or both.
- Basis: the source and evidence, the date observed and a confidence grade.
Keep entity labels and category labels distinct. You can often be sure an address is an exchange deposit address (it forwards everything to a hot wallet) without knowing which exchange, and you can know which exchange without knowing the customer. Keep labels separate from clusters, too. A label attached to one seed address spreads to every address in its cluster, a process called label inheritance, so a label is never stronger than the cluster links that carried it.
Label sources
| Source | Examples | Typical strength | Watch for |
|---|---|---|---|
| Self-identification | An exchange's published reserve addresses; a protocol's documented contract addresses; an organization's donation address | Strong for the addresses listed | Lists go stale; impersonators publish fake lists |
| Service tagging by test transaction | Depositing a small amount to a service and observing the deposit address and the sweep | Strong, first-hand | Covers only addresses you touched until clustering extends it |
| Public authority releases | Indictments, seizure announcements, sanctions listings and advisories that include addresses | Strong for the specific addresses named | The attribution is the authority's; cite it as such |
| Victim and incident disclosures | Post-mortems by exploited protocols listing attacker addresses | Strong for the incident addresses | Early lists can contain mistakes later corrected |
| OSINT about organizations | A service's own documentation, official accounts, governance forums, verified contract source code | Moderate; depends on verification | Spoofed accounts and copied pages |
| Third-party label sets | Explorer public tags, open community datasets, vendor data | Variable, often unexplained | Circular copying; unknown method and date |
Test transactions are the classic research method. Meiklejohn et al. (2013, "A Fistful of Bitcoins") made 344 transactions with exchanges, wallets, gambling sites and other services, hand-tagged 1,070 addresses, and through clustering were able to name 2,197 clusters covering more than 1.8 million addresses. The example shows the leverage of label inheritance in both directions: a few first-hand observations can label millions of addresses, and a single bad cluster link can mislabel millions.
Public releases are important for high-profile cases. After the Ronin bridge theft (2022) and the Bybit theft (2025), authorities publicly attributed the attacks to a state-linked group and published addresses involved. An analyst can rely on such releases for the addresses they name, while making clear in the report that the attribution comes from the authority, and should treat any extension to further addresses as the analyst's own inference.
Two third-party tags that agree are not necessarily two sources. Explorers and datasets copy from one another, so a wrong tag can appear in five places with a single origin. This is circular reporting; trace each label to its origin before counting it as corroboration.
Grading confidence
A simple, explicit grading scale keeps labels comparable across analysts:
| Grade | Criteria |
|---|---|
| Confirmed | First-hand evidence (own test transaction), the entity's own publication, or an authority release naming the address |
| High | Two independent indicators agree, for example a sweep pattern into a self-identified hot wallet |
| Moderate | One strong indicator, or a reputable third-party tag with a known method |
| Low | A single weak indicator or an unexplained tag; use as a lead only, never as a finding |
Two refinements matter in practice. First, grade the cluster link and the label separately: a confirmed label on a seed address, inherited through a low-confidence change link, gives a low-confidence label on the inheriting address. Second, grade the entity and the category separately, as described above. The lesson Confidence, uncertainty and language shows how to carry these grades into report wording.
Inheritance also needs rules about which links may carry a label. A common policy is to propagate entity labels only through high-confidence links, typically common-input links with CoinJoins excluded, and to stop propagation at any link that would put a second, different entity label into the same cluster. Change links and account-model links can still be shown in a graph, but the label they would carry is marked as inferred and graded down. Consider a worked case: a confirmed exchange label sits on a hot wallet; 4,000 deposit addresses join it through sweeps (common input, high confidence); one more address joins through a single moderate change link. The 4,000 deposit addresses inherit "Exchange K, high"; the last address inherits at most "Exchange K, moderate", and a report that counts its funds as exchange funds should say so.
Versioning and provenance
Labels decay. Exchanges rotate hot wallets and reassign deposit addresses; services merge, shut down or change hands; proxy contracts are upgraded to new implementations; naming-service names expire and are re-registered; attackers move funds to fresh addresses. A label without a date and a validity window cannot be checked or corrected. Store each label as a versioned record:
{
"label_id": "lbl-000482",
"version": 3,
"subject": {"chain_id": 1, "address": "0xA1b2…9F"},
"entity": "Exchange K",
"category": "exchange_deposit",
"source_type": "test_transaction",
"evidence": ["deposit tx 0x4f3a…c21e", "sweep tx 0x9b7d…e014"],
"observed_at_block": 21000000,
"valid_from": "2024-11-02",
"valid_to": null,
"confidence": "confirmed",
"analyst": "analyst-17",
"supersedes": "lbl-000482-v2"
}The record names its subject with a chain identifier, separates entity from category, points to the transactions that justify it, and states when it was observed and from when it applies. valid_to stays empty until evidence shows the label no longer applies; supersedes keeps the history, so a report written last year can be reproduced with the labels that were current then. The analyst field supports review and accountability without putting personal data in the record.
Good label hygiene includes:
- Re-verification of high-impact labels before each report.
- Conflict alerts when a cluster acquires two incompatible entity labels, often the first sign of a false merge (see the lesson Evaluating cluster quality).
- Retirement rather than deletion, so past findings remain explainable.
Privacy and ethics
Attribution in blockchain analysis is aimed at services, organizations and categories of activity: exchanges, bridges, protocols, mixers, exploit contracts, scam operations named by authorities or victims. It is not a technique for identifying private individuals, and analysts should hold to that line even when the data seems to invite crossing it.
- Label entities, not people. An address that appears to belong to a private individual is labeled by category ("unattributed private wallet") or left unlabeled.
- Do not combine sources to unmask a person. Aggregating on-chain patterns with open-source traces to name a private individual creates exactly the profile that data protection practice warns against, and a wrong match can expose an innocent person to harassment or worse.
- Identity comes through legal process. When a case genuinely requires knowing who controls an account, the route is a request by a competent authority to the service that holds customer records, not public inference.
- Treat self-claims about people as leads. A naming-service record or profile that looks like a person's name may be genuine, impersonated or resold. It stays out of shared documents unless a reader needs it to act and receives it through a restricted channel.
- Publish only what others have made public, or what the reader needs. Addresses published by authorities, courts or the victim organization, and service names, are generally acceptable in a report; inferred links to individuals are not.
The lesson Data protection, ethics and responsible disclosure covers data minimization, redaction and disclosure channels in detail.
Exam focus: a label as a claim with subject, assertion and basis; entity versus category labels; label inheritance through clusters and why a label is no stronger than the links carrying it; the main label sources (self-identification, test transactions, authority releases, victim disclosures, OSINT about organizations, third-party sets) and their weaknesses; circular reporting; a graded confidence scale and grading link and label separately; why labels decay and how versioned records with validity windows and evidence keep findings reproducible; attribution aimed at services and organizations, never at exposing private individuals, with identity obtained only through legal process.