Tracing to an evidential standard

Any analyst can follow a transaction on an explorer. A forensic trace is different: it may be read by a prosecutor deciding on charges, used to freeze someone's property, and re-run line by line by an expert for the other side. This lesson sets out what a trace actually claims, how to grade each link in it, how to record every hop so that it can be checked, and how independent re-performance turns a trace into evidence.

What a trace claims

A trace is a statement about the flow of value: value that left address A reached address B through a stated path, under a stated allocation method, as observed up to a stated block. It is not a statement about identity. "The ransom proceeds reached a deposit address of Exchange K" is a tracing finding. "The suspect received the ransom" is a combination of a tracing finding, an attribution and, usually, records obtained through legal process (see the lesson From address to entity to person).

Keeping the claims apart matters because they fail differently. A flow can be verified by anyone with a copy of the chain. An attribution rests on labels, records or heuristics that can be wrong or out of date. When a report blends them in one sentence, a defense expert only has to break the weaker claim to discredit both.

A useful discipline is to break every finding into three separate questions:

Three kinds of link

Every hop in a trace rests on one of three kinds of link. The IDFE-BA lesson Cross-chain tracing uses a similar three-grade idea for bridges; here it is applied to every hop.

A deterministic link is written in the chain data itself. In a UTXO chain, an input that spends an earlier output is a deterministic link between the two transactions. On an account chain, a successful transaction carrying value to an address, or a Transfer event emitted by the token contract in a successful transaction, is deterministic. Anyone who runs a node gets the same answer.

A heuristic link applies a rule that usually holds but has known exceptions. The common-input ownership heuristic, change detection and the forwarding of a deposit address to a hot wallet are heuristics (see the IDFE-BA lessons The common-input ownership heuristic and Change detection heuristics). Each has documented failure modes, such as CoinJoin transactions or wallets that randomize change.

An inference is a conclusion drawn from circumstantial patterns: a withdrawal of a similar amount 20 minutes after a deposit, a matching time-of-day pattern, a shared gas funder. Inferences are leads. They justify a request for records; they rarely stand alone as findings.

Note what a deterministic link does not prove. It proves that value moved from one address to another. It does not prove that the same person controls both ends, and when several inputs merge in one transaction it does not say which part of an output is "the stolen money". Those are control and allocation questions.

Confidence grading

A trace needs a declared grading scale so that every link carries a grade a reader can interpret. Units design their own; the example below is illustrative, not a published standard.

Two rules make the scale useful. First, a path is only as strong as its weakest link: a five-hop trace with one grade C hop is a grade C path for any claim that depends on that hop. Second, grade each claim, not each transaction: the same hop can carry a grade A flow and a grade C control claim. For the wording of likelihood and confidence in the report itself, see the IDFE-BA lesson Confidence, uncertainty and language and the lesson Writing the forensic report.

A worked trail

A victim paid a ransom of 2.50000000 BTC. The examiner traces it forward:

The amounts reconcile: 2.5 + 0.8 = 3.3 BTC in, 3.2999 out plus 0.0001 fee; then 1.2 + 2.0998 + 0.0001 = 3.2999. The flow from the ransom address to bc1q…dx7e is grade A at every hop, and it does not depend on the common-input heuristic at H2: value moved whoever owned bc1q…x8w2. What does change the picture is allocation. The 2.5 BTC was merged with 0.8 BTC of unknown origin, so how much of the 1.2 BTC deposit counts as ransom proceeds depends on the method (see the lesson Tracing methods and their consequences). Under the haircut method it is 1.2 × 2.5 ÷ 3.3 = 0.90909091 BTC; under any value-conserving method it cannot exceed 1.2 BTC. The deposit-address label stays at grade C until Exchange K's records confirm it, when it rises to B.

Public cases show the same structure. In June 2021 investigators announced the seizure of 63.7 BTC of the roughly 75 BTC ransom paid after the Colonial Pipeline attack. According to the official release, they followed multiple transfers on the public ledger to one address whose private key the investigators held. The trace established where the value went; the seizure depended on separate evidence about control of the key.

Documenting every hop

Every hop goes into a structured record, written when the hop is examined, not reconstructed at report time. A minimal hop record:

{
  "case_id": "CF-2026-0142",
  "hop_id": "H3",
  "chain": "bitcoin-mainnet",
  "txid": "9c1e…44ab",
  "spends": "5d07…e310:0",
  "output_ref": "9c1e…44ab:0",
  "block_height": 939874,
  "block_hash": "0000…3f9a",
  "block_time_utc": "2026-03-02T14:07:51Z",
  "from": "bc1q…c0n1",
  "to": "bc1q…dx7e",
  "amount_sat": 120000000,
  "allocation": {"method": "haircut", "traced_sat": 90909091},
  "grades": {"flow": "A", "control": "C"},
  "basis": "output 0; recipient swept with known K deposits (see ATTR-11)",
  "source": "own node, Bitcoin Core 29.0, checked 2026-03-05T09:12Z",
  "examiner": "EX-07"
}

The record names the exact output, not just the transaction, because a transaction can pay several parties. It stores the amount in satoshis as an integer to avoid rounding drift, and the block hash as well as the height so that a reorganization or a typing error is detectable. It keeps the allocation and the grades separate from the observed facts, cites the basis of every non-deterministic claim by reference, and records which data source was used and when. Times are UTC. The same fields, with a log index or trace position instead of an output reference, serve account chains. How these records are hashed and preserved is covered in the lessons Preserving on-chain evidence and Hashing, logging and chain of custody.

Independent re-performance

Blockchain evidence has an unusual advantage: the underlying data is public and identical for everyone who validates the chain. A trace can therefore be re-performed by someone else, from raw data, and should be.

ISO/IEC 27037 distinguishes repeatability, getting the same results with the same procedure in the same environment, from reproducibility, getting the same results with the same method in a different environment, such as another examiner with another node or tool. Re-performance tests reproducibility. It comes in two strengths:

1. Verification: a second examiner checks each hop record against their own node: txid exists, output and amount match, block hash matches, the block is final.
2. Independent re-performance: the second examiner starts from the seeds, the scope, the method and the stopping rules only, without seeing the first examiner's path, and traces again. Agreement then means more than a check of arithmetic, and working without the first result reduces confirmation bias.

When results differ, find the first hop where they diverge and record the cause: a different change call, a different allocation method, a later cut-off block, a missed internal transfer. Resolve it from raw data, and keep the disagreement and its resolution in the case file. A trace that cannot be reproduced by a competent second examiner is not ready to be relied on.

Exam focus: a trace claims a flow of value, not identity; separating flow, allocation and control claims; deterministic links, heuristic links and inferences, with examples; what a deterministic link does not prove; a declared grading scale and the weakest-link rule for paths; reconciling amounts and fees hop by hop; the fields of a hop record (exact output or log reference, integer base units, block height and hash, UTC time, method, grades, basis, source); repeatability versus reproducibility (ISO/IEC 27037); verification versus independent re-performance and resolving divergence.