From address to entity to person: attribution and labeling

Most investigations are opened to answer a question about people: who received the ransom, who ran the scam, who now holds the stolen funds. A blockchain answers questions about addresses. Between the two lies a chain of separate inferences (a cluster, a label naming a service, a record naming an account, evidence that a person controlled it), each with its own evidence and failure modes. An examiner who collapses the chain into one sentence ("the address belongs to Subject 2") hands the other side an easy target. This lesson sets out the layers of attribution, how labels are built, graded and versioned, and how to record the chain so that each link can be checked.

Five layers of attribution

The address layer itself contains two claims. That value reached an address is a deterministic fact anyone can verify. That a particular person controls the address is not visible on-chain at all. Control can be shown by a valid signed message, by recovering the key from a seized device under lawful authority, or by an authenticated service record that says the service holds it.

Clusters are covered in Lessons 4.1 to 4.4. The discipline here is keeping the five claims apart, stating which layer each finding reaches, and never letting a strong lower layer lend its strength to a weak upper one.

Each layer fails differently

• Cluster errors. A heuristic merges two unrelated wallets, or a CoinJoin is read as one owner, and a label is dragged onto addresses it does not belong to.
• Service errors. A label is stale (the exchange rotated its hot wallets), copied from an unknown origin, or attached to a category without an entity.
• Account-holder errors. The service misattributes a deposit, recycles a deposit address after the account closes, or produces records for the wrong period.
• Identity errors. The account holder is not the person who acted: a money mule opened the account for someone else, the identity documents were stolen or bought, the account was taken over, or several people shared the login.

KYC records tell you whose documents were presented at onboarding, not who typed the withdrawal request. Investigators corroborate the step from account holder to individual with independent evidence: login IP addresses and device identifiers that match the suspect's connections, the exchange app found on a seized phone, bank transfers from the suspect's own account, or messages discussing the transaction.

Labels: the service layer

A cluster tells you that addresses belong together; a label tells you who or what they belong to. A label is a claim with 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 an A–D 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 the exchange without knowing the customer.

Where labels come from

The main sources are self-identification (an exchange's published reserve addresses, a protocol's documented contracts), the analyst's own test transactions, public authority releases (indictments, seizure notices, sanctions listings), victim and incident disclosures, open-source research about organizations, and third-party label sets (explorer tags, community datasets, vendor data). Lesson 4.6 grades each family and shows how to verify and date them; two points belong here.

Test transactions are the classic first-hand method: deposit a small amount to a service and observe the deposit address and the sweep. 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 named 2,197 clusters covering more than 1.8 million addresses.

Authority releases are important in 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. Rely on such releases for the addresses they name, make clear that the attribution is the authority's, and treat any extension to further addresses as your 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 (circular reporting). Trace each label to its origin before counting it as corroboration.

Label inheritance

A label attached to one seed address spreads to every address in its cluster. This label inheritance is what makes test transactions so productive, and it works in both directions: a few first-hand observations can label millions of addresses, and a single bad cluster link can mislabel millions. A label is therefore never stronger than the cluster links that carried it.

Inheritance needs rules. A common policy propagates entity labels only through high-strength links, typically common-input links with CoinJoins excluded, and stops 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.

Grading every link

Grade every link in the chain, not only the conclusion. The course-wide scale from Lesson 3.2 (A recorded on-chain, B corroborated, C single heuristic, D inference) extends to labels, control and identity:

Grade the cluster link and the label separately, and the entity and the category separately. These link grades are separate from the two-axis source and information codes of Lesson 4.6 (such as A1), which are recorded alongside them. A worked case: a grade B label "Exchange K" sits on hot wallet HW-3, taken from the exchange's archived reserve list. Four thousand deposit addresses join HW-3 through sweeps (common input, CoinJoin filter on). Each inherits "Exchange K" only through that single heuristic link, so the inherited label is C, not B, until the exchange confirms the deposit addresses or produces records assigning one to an account (B). One more address joins through a single change link; its label is marked inferred and graded D, and a report that counts its funds as exchange funds must say so.

The weakest-link rule applies across all five layers. A grade A flow, a grade C cluster link, an authenticated account record (B) and a grade D link from account holder to suspect give a grade D claim that the suspect received the funds. The right response is not to write the claim more cautiously but to gather the evidence that would raise the weakest link: device evidence, IP logs, financial records.

Grading forces precise language. "Funds reached a deposit address of Exchange K" (service layer), "Exchange K's records assign the address to an account in the name of Subject 2" (account layer) and "Subject 2 controlled the account" (individual layer) are three findings, not one. Lesson 9.2 covers report wording.

Why identity normally comes from legal process

Public data usually stops at the service layer. Once value enters a custodial service, the link between a deposit address and a customer exists only in the service's database (Lesson 3.4). The route to it is legal process: a production order, a court order or a request from a competent authority, often across borders. The Budapest Convention requires its Parties to provide for production orders for data, including subscriber information, held by service providers (Article 18), and its Second Additional Protocol adds procedures for direct disclosure of subscriber information by service providers in another Party (Article 7) and of domain name registration information (Article 6). Lessons 1.3 and 1.4 cover drafting and sending requests.

Open-source research can supply leads at the upper layers (Lesson 4.7), but a lead is not an identification. The defensible path usually runs: on-chain trace to a service, request to the service, records that name an account holder, then corroboration of that account holder as the individual. In the Welcome to Video investigation, announced in October 2019, investigators followed bitcoin payments to the site and its users, and the location of the site's server surfaced through an IP address exposed in the site's own page source. Arrests followed in many countries. Tracing told investigators where to look; identification came from records, seized servers and evidence gathered by local authorities.

This is also an ethical line. Attribution from on-chain analysis is aimed at services, organizations and categories of activity, not private individuals. Label an apparent private wallet by category ("unattributed private wallet") or not at all; do not combine on-chain patterns with open sources to unmask a person, because a wrong match can expose an innocent person to harassment; treat a naming-service record that looks like a person's name as a lead that may be genuine, impersonated or resold (Lesson 1.5).

Recording labels and attributions

Labels decay: exchanges rotate hot wallets and reassign deposit addresses, services change hands, proxy contracts are upgraded, naming-service names expire and are re-registered. A label without a date and a validity window cannot be checked or corrected, so store each one as a versioned record:

{
  "label_id": "lbl-000482",
  "version": 3,
  "subject": {"chain_id": 1, "address": "0xC4d8…27aB"},
  "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,
  "grade": "B",
  "analyst": "analyst-17",
  "supersedes": "lbl-000482-v2"
}

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 current then. Good hygiene adds re-verification of high-impact labels before each report, alerts when a cluster acquires two incompatible entity labels (often the first sign of a false merge), and retirement rather than deletion.

The attribution itself is a second record that names the layer, basis and grade of every link, so that a reviewer can attack or confirm each link separately:

{
  "attribution_id": "ATTR-11",
  "case_id": "CF-2026-0142",
  "subject": {"chain": "bitcoin-mainnet", "address": "bc1q…dx7e"},
  "valid_at": "2026-03-02T14:07:51Z",
  "links": [
    {"layer": "cluster", "claim": "swept with 1,412 deposits into hot wallet HW-3",
     "basis": "common-input, CoinJoin filter on", "grade": "C"},
    {"layer": "service", "claim": "HW-3 is Exchange K",
     "basis": "self-published reserve list, archived 2026-03-04, sha256 9e1c…b07a", "grade": "B"},
    {"layer": "account", "claim": "assigned to account K-778213",
     "basis": "Exchange K production, item EV-0031", "grade": "B"},
    {"layer": "individual", "claim": "account controlled by Subject 2",
     "basis": "KYC only; IP and device logs requested", "grade": "D"}
  ],
  "overall_grade": "D",
  "examiner": "EX-07"
}

The record states the moment at which the attribution applies, because deposit addresses are reassigned. Each link points to the preserved item it rests on. The overall grade is the weakest link, and the individual-layer basis shows exactly what is missing; when the exchange's IP and device logs arrive and match the suspect's home connection, that link and the overall grade can be revised, with the old version kept. Note that the deposit address inherits the B-grade service label only through the C-grade cluster link, which is why the exchange's production matters.

Common errors

• Collapsing layers: writing "the address belongs to Subject 2" when the evidence reaches only the service layer.
• Treating the account holder as the actor without corroboration.
• Ignoring time: an attribution valid in March may be wrong in June after an address is reassigned.
• Letting a label outrun its cluster, or counting copies of one tag as corroboration.
• Hypothesis lock-in: once a suspect is named, every new fact reads as confirmation. Record competing explanations at each layer and test them.
• Exposing people: an unconfirmed upper-layer link to a private individual stays in a restricted annex, never in shared documents.

Exam focus: the five layers (address, cluster, service, account holder, individual) and the claim and typical evidence of each; that control of an address is not visible on-chain and how it can be shown (signed message, recovered key, authenticated record); a label as a claim with subject, assertion and basis, and entity versus category labels; label sources, test transactions and their leverage (344 transactions, 1,070 addresses, 2,197 clusters), authority releases cited as the authority's, and circular reporting; label inheritance and why a label is no stronger than the links carrying it; grading each link A to D and the weakest-link rule across layers; why KYC identifies the account holder, not necessarily the actor; identity through legal process (Budapest Convention Article 18, Second Additional Protocol Articles 6 and 7); versioned label records with validity windows and structured attribution records; attribution aimed at services, never at exposing private individuals.