A blockchain address can appear precise. It may have a visible transaction history, a persistent balance and a sequence of incoming and outgoing transfers. Yet an address is not a name. It is a ledger identifier, and the evidential question is how, if at all, that identifier can be connected to a person or entity.
Blockchain attribution is generally a process of combining on-chain activity with off-chain evidence. Transaction graphs and clustering heuristics can identify patterns, possible control and service-level relationships. Stronger identity conclusions may require corroboration from sources such as exchange records, account information, service confirmations, seized infrastructure, server logs or device evidence. Each source must be assessed separately for authenticity, provenance, completeness, reliability and its connection to the relevant person or entity.
An on-chain association may be useful and reproducible in part without being conclusive. The distinction matters when a transaction narrative is being prepared for an investigation, disclosure exercise or litigation.
An address is a pseudonym, not an identity
Public blockchains expose transaction activity associated with cryptographic addresses. This makes many blockchain systems pseudonymous rather than inherently anonymous: the ledger may preserve a visible identifier and its transactions, but it does not ordinarily contain the holder’s true name.
An identifier can sometimes be linked to a real-world actor when other evidence connects it to an account, service, device, communication or transaction event. The address itself does not supply that connection automatically.
A more defensible sequence of questions is:
- What activity is associated with the address or address cluster?
- What assumptions were used to group addresses or trace funds?
- Is the address associated with a service?
- What independent evidence connects that service-level activity to a person or entity?
- What alternative explanations remain plausible?
The strength of the conclusion depends on the evidential record as a whole, not only on the appearance of a transaction graph.
What on-chain analysis can show
Transaction flows and graph structure
On-chain analysis can trace movements of cryptocurrency through inputs and outputs. This may help identify payment paths, intermediary addresses, recurring patterns and possible points at which funds enter or leave a service.
Flow tracing may also identify activity that is consistent with a service-level relationship, such as an exchange or mixing service. Such findings can provide an investigative lead and a basis for seeking further records. They do not, without more, establish the identity or control of a particular person.
Native ledger data can often be examined again when the relevant transactions, block information, chain state, query parameters and analytical decisions are documented. That supports independent examination or partial reproducibility; it does not turn an analytical inference into direct proof of identity.
Address clustering heuristics
Investigators and analytical systems may group addresses that appear likely to be controlled by the same actor. One approach used in Bitcoin-like UTXO systems is the common-input-ownership heuristic: where multiple addresses appear as inputs in one transaction, the analysis may infer common control.
Other techniques may consider change-address behaviour, address reuse, transaction timing, fee patterns, repeated payment structures and service-specific formats. These techniques remain heuristics. Their conclusions depend on assumptions about how a transaction was constructed and how a wallet or service operates.
The evidential meaning of a method also depends on the relevant blockchain model. A signal available in a UTXO-based system may not have the same meaning on an account-model chain. Behavioural patterns, contract interactions, token movements or service formats should therefore be described with their chain-specific assumptions rather than treated as universally transferable methods.
Why on-chain attribution is not enough on its own
A cluster is not a person. A vendor label is not necessarily a disclosed account record. A flow pattern consistent with one explanation may also be consistent with others.
Some transaction designs and service arrangements can weaken common clustering assumptions or make service-level observations difficult to connect to an individual account. Examples may include privacy-oriented transaction structures, exchange pooling and account aggregation. The relevance of any such feature depends on the chain, transaction design, available data and analytical method; it should not be treated as a universal conclusion about attribution.
Commercial providers may use proprietary methods, data sources and labels that are not fully auditable publicly. Their outputs can be useful investigative intelligence, but vendor labels and cluster merges should not be treated as conclusive or as the sole basis for a litigation-level attribution. Public, independent and reproducible accuracy metrics for major vendor systems are not generally available in the supplied research base.
Accordingly, a statement that an address is owned by a named person should not be made from on-chain heuristics alone. Wording should reflect what the evidence supports, such as that activity is “consistent with” a service or “strongly suggests” a relationship, subject to stated assumptions and corroboration.
Off-chain evidence can provide an identity connection
The most direct identity evidence may be outside the blockchain, but no category of record is self-authenticating or automatically conclusive.
VASP and exchange records
Virtual asset service providers and exchanges may hold customer information, account records and deposit-address mappings. Where available through applicable legal processes, such records may help connect an account holder to activity observed on-chain.
Access depends on the relevant jurisdiction, legal authority, provider status, disclosure rules, retention practices and the particular facts. FATF material provides international policy and guidance context; it does not itself create a universal entitlement to records or establish the reliability or admissibility of a particular provider record.
An exchange association should still be examined carefully. A deposit address may be controlled by a service rather than directly by a customer, and service architecture may involve pooled funds or intermediary addresses. The relevant question is whether the provider’s records reliably identify the account, activity and relationship and whether those records can be correlated with the on-chain evidence.
Seizures, infrastructure and device evidence
Seized private keys, service infrastructure, server logs, wallet files, keystores, communications or other device artefacts may strengthen an attribution. Possession or presence of such material does not, by itself, establish who controlled an address, used a key or authored a communication.
The assessment should consider provenance, integrity, access history, control, collection and preservation, together with the relationship between the artefact, the relevant person, device, account and transaction. A wallet file or key may show access or technical capability without independently proving identity or control at the relevant time.
OSINT and other correlated records
Public webpages, forum disclosures, deposit-address publications, smart-contract event records and leaked database material may map an address to an account or service. These sources can generate important leads, but require validation. Public availability does not by itself establish authenticity, authorship, control, completeness or timing.
Network and mempool observations may, in some circumstances, provide information about the origin of a transaction broadcast. Research into Bitcoin’s peer-to-peer network has examined possible network-level deanonymisation. Such evidence is research-dependent, requires specialised telemetry or cooperation, and may be subject to jurisdiction-specific legal constraints. It should not be treated as routine or decisive without corroboration.
Privacy tools and service arrangements change the evidential landscape
Privacy-enhancing designs and services can reduce confidence in an address attribution. A transaction pattern may complicate assumptions about common control, and pooled or intermediary service architecture may interrupt the apparent path from a service address to an individual account.
The effect is context-dependent. The relevant analysis should identify the chain, transaction structure, service arrangement and data available, rather than assume that a named privacy tool has one uniform evidential effect in every case. Where the on-chain record supports only a narrower service-level or transaction-level finding, the conclusion should remain at that level.
A regulatory designation or enforcement action is also distinct from technical proof. For example, the cited U.S. Treasury action concerning Tornado Cash records a particular government sanctions action; it does not, by itself, establish that a particular transaction used a service, identify the person behind it or validate a vendor label. Technical identification and regulatory treatment should be analysed separately.
A defensible evidential workflow
The quality of an attribution depends on preservation, explanation and corroboration as well as on the analytical result.
Preserve and distinguish the underlying data
Preserve native transaction and block data where available, identifying the relevant chain state or block height and the data source used. Distinguish that material from provider or vendor exports, indexed data, labels and derived analytical outputs. Record product and version details, timestamps, query parameters, processing steps and any changes made during analysis.
Preservation enables later examination, but does not by itself validate the analysis or guarantee exact reproduction. Results may be affected by node configuration, data-source differences, chain reorganisations, token-indexing logic, vendor processing and undocumented transformations. The preservation record should therefore explain the processing environment and the limits of any reproduction claim.
Correlated off-chain records should be preserved with their provenance and acquisition context. The objective is to allow another reviewer to understand what was obtained, when it was obtained and how it was connected to the on-chain activity.
Timestamps also require qualification. A block timestamp, provider-record timestamp, system timestamp, publication timestamp and the time of an underlying real-world event are not necessarily the same. A timestamp may not establish when a person acted or when an external event occurred. Reports should identify the timestamp type, source, clock assumptions, time zone and recording process, and compare the timing with corroborating evidence.
Document assumptions and analytical decisions
A report should identify the heuristics used, including common-input, change-detection or flow-tracing rules. It should record thresholds, exclusions, aggregation, pruning and post-processing. Where scripts or reproducible procedures are used, they should be retained with the relevant evidence and documentation.
The reasoning should be transparent enough for its assumptions and limitations to be examined. This is different from claiming that every result can be reproduced exactly.
Seek corroborating identity evidence
On-chain analysis is often most useful for developing lines of inquiry. It can identify likely service touchpoints, candidate accounts and records to seek through appropriate legal processes.
Where available and lawfully obtained, exchange or VASP records, service confirmations, seizure materials, server logs, device forensics and communications may corroborate an address relationship. Each record still requires assessment of authenticity, provenance, completeness, reliability and control. Vendor labels may help identify a relevant service, but the underlying source supporting the label should be considered, particularly where the output may be relied upon in a contested setting.
State uncertainty and alternatives
A clear report should distinguish observed facts from analytical interpretations. It should state whether a conclusion is consistent with, likely to reflect or strongly suggest a particular explanation, and identify relevant alternatives such as pooling, aggregation, change-detection error, privacy-oriented transaction structures or incomplete service data.
This approach separates an investigative hypothesis from an identity conclusion that may be relied upon more broadly.
What decision-makers should ask
When reviewing a proposed attribution, litigation and investigations professionals should ask:
- Is the finding based on native ledger data, provider or vendor outputs, off-chain records, or a combination?
- Which addresses were grouped together, and why?
- Which heuristics, parameters and processing steps were applied?
- Is the result a service-level association or a person-level identity link?
- What independent record connects the service or address to the named individual or entity?
- Were pooling, aggregation, privacy-oriented transaction structures and other relevant failure modes considered?
- Can the underlying data, outputs and analytical process be independently examined, and what limits apply?
- What alternative explanations remain, and how were they assessed?
These questions help identify where further disclosure, technical analysis or lawful requests may be required without treating any single record or label as conclusive.
The IVIDENTIA perspective
Blockchain evidence is most useful when treated as a structured body of digital evidence rather than as an automatic identity register. On-chain analysis can reconstruct flows, expose relationships and identify investigative targets. Off-chain records may provide corroborating identity evidence, but their authenticity, provenance, completeness, reliability and connection to the relevant person or entity must be assessed.
The disciplined approach is to preserve the relevant records, explain analytical assumptions, obtain corroboration where possible and express the conclusion at the level the evidence can support. For litigation lawyers and investigations professionals, the central distinction is between what a cryptocurrency trail shows, what it suggests and what still requires independent confirmation.
Sources
- Blockchain Technology Overview (NIST IR 8202) — NIST / U.S. Department of Commerce.
- Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs — FATF.
- What is wallet attribution? — Chainalysis.
- How Chainalysis Collects and Uses Service-Level Data — Chainalysis.
- A Fistful of Bitcoins: Characterizing Payments Among Men with No Names — Meiklejohn et al., IMC 2013.
- An Analysis of Anonymity in the Bitcoin System — Reid and Harrigan.
- The Unreasonable Effectiveness of Address Clustering — Harrigan and Fretter.
- Treasury Sanctions Notorious Virtual Currency Mixer Tornado Cash — U.S. Department of the Treasury / OFAC.
- Deanonymisation of Clients in the Bitcoin P2P Network — Biryukov, Khovratovich and Pustogarov.
- 2024 Crypto Money Laundering Report — Chainalysis.
