Reading the chain

Reading the chain · the ledger, then the law that follows it

Two literacies the file now assumes: reading a public transaction record without folklore, and knowing what identity data the law makes travel alongside it. Both are learnable in an afternoon; both are routinely got wrong.

A public blockchain is an evidence source unlike a bank statement: the ledger itself is open, permanent and checkable by anyone with a browser — but it records movements between addresses, not people. The gap between those two things is where most error lives. Part 1 is the ledger. Part 2 is the law that attaches names to it. Nothing below requires a subscription, an account or special tooling.

Part 1 — Reading a transaction on a public explorer

A block explorer is a search engine over a public ledger. It indexes blocks, transactions and addresses, and renders them as web pages; anyone who pastes the same identifier sees the same record. The explorer adds convenience and context — some of that context is ledger fact, and some, as the caveats below set out, is not.

The transaction hash — the citation

Every transaction has a hash (on Bitcoin, the txid): a fixed-length identifier derived cryptographically from the transaction's contents — 64 hexadecimal characters, prefixed with 0x on Ethereum. Change one byte of the underlying transaction and the hash changes entirely; quote the hash and any node or explorer in the world resolves it to the same record.

What it proves — that this exact transfer, between these addresses, in this amount, at this block and time, is part of the ledger.
What to record — the hash, the chain, the block height, the date read, and which explorer was used.
What it cannot do — name a human being.

So what — a transaction hash is a citation, not a screenshot: the other side, the tribunal and the supervisor can each reproduce it independently, indefinitely.

Source: ethereum.org — transactions

Two ledgers, two grammars — UTXO and accounts

Bitcoin and Ethereum record value differently, and reading one in the grammar of the other is the commonest explorer error.

	Bitcoin (UTXO)	Ethereum (accounts)
Unit of record	Unspent transaction outputs (UTXOs)	Account balances in a global state
A "balance" is	The sum of outputs a key can still spend	A field attached to the address
A payment is	Inputs consuming prior outputs, creating new ones	A value or state change between accounts
Change	Returned to the payer, often at a fresh address	No change mechanism — balances just adjust
Trap for the reader	A change output misread as a second payee	A zero-value transaction that moved tokens

On Bitcoin there are no balances at protocol level: each input spends value paid to a previous output, and each output waits as a UTXO until a later transaction spends it. Because inputs must be consumed whole, most payments create an extra output returning change to the payer — frequently to an address the payer has never used before. Ethereum is account-based: two account types, externally-owned (controlled by whoever holds the private key) and contract accounts (controlled by code), each with a balance the transaction adjusts.

So what — on Bitcoin, a two-output transaction is usually one payment plus the payer's own change, not two recipients. Asserting otherwise in a report is the classic unforced error.

Source: Bitcoin developer guide — transactions · ethereum.org — accounts

Confirmations and finality

A transaction sitting in the queue of pending transactions is a proposal. Included in a block, it has one confirmation; every later block adds another.

Bitcoin — settlement is probabilistic. Blocks arrive roughly every ten minutes on average, and the developer guide's convention is that software handling high-value payments waits for at least six confirmations — about an hour — before treating a payment as accepted, a number the guide itself calls "somewhat arbitrary".
Ethereum — proof-of-stake adds explicit finality: checkpoint blocks are finalised once validators representing two-thirds of all staked ETH attest to them, after which reverting the block would require an attacker to forfeit at least a third of the total stake. In normal operation this is a matter of minutes, not hours.

So what — "confirmed" is a statement about depth at a moment in time. Capture the confirmation count together with the hash and the date of reading.

Source: Bitcoin developer guide — payment processing · ethereum.org — proof-of-stake

Fees and gas

Bitcoin — there is no fee field. The fee is implicit: whatever the inputs spend beyond what the outputs receive goes to the miner. Explorers compute and display it.
Ethereum — the fee is units of gas used × (base fee + priority fee). A plain ETH transfer consumes 21,000 units of gas; complex contract interactions consume more. The base fee is set by the protocol and destroyed ("burned"); the priority fee is a tip that persuades a validator to include the transaction sooner.

So what — fee choices are conduct evidence. A sender paying far over the market rate to move funds within the hour has left the urgency on the ledger, timestamped.

Source: ethereum.org — gas

An address is what a key can sign — not who signed

An address is derived from a cryptographic key pair. Creating one costs nothing and takes no registration: one person can hold thousands, and typical wallets generate new addresses continuously.
The converse also holds: a single address at a custodial platform can pool deposits belonging to many unrelated customers. The on-chain "sender" is then the platform's wallet infrastructure, not any individual.
The ledger proves that value moved between addresses. It does not prove who held the key, who instructed the movement, or on whose behalf.

So what — in written findings, "the address transferred" is a fact; "he transferred" is a conclusion that needs separate evidence. Keep the two apart until attribution is corroborated.

Source: ethereum.org — accounts

Tokens, contracts and what "value" means

On Ethereum, most value of interest does not move as ETH. A stablecoin balance lives inside the token's own contract; transferring it means sending a transaction to the token contract, which updates its internal ledger and emits an event recording sender, recipient and amount. On the explorer page this produces three things worth knowing:

the native value field can read zero while the token-transfers tab shows a seven-figure stablecoin movement;
the to field names the contract, not the economic recipient — the recipient sits in the decoded event log;
a contract interaction displays a method name (Transfer, Approve, Swap and so on): the high-level, human-readable statement of what the transaction asked the contract to do. The event logs record what the contract actually did.

So what — read the token-transfers tab and the event log before concluding that nothing moved — or that only the headline amount did.

Source: ethereum.org — ERC-20 token standard

Where the ledger stops — three caveats

Clustering is probabilistic. Grouping addresses into one "wallet" or "entity" rests on heuristics — inputs co-spent in a single transaction, change-address patterns — characterised in the academic literature as early as 2013. The heuristics fail in known ways (shared custody, CoinJoin, payment batching), and an early clustering error propagates silently into every attribution built on it.
The explorer shows the ledger, not the owner. Everything above proves state changes. Ownership, control and instruction are off-chain facts, established — if at all — by other evidence.
Labels are curated metadata, not ledger data. Explorer name-tags are attributions maintained by the explorer's operators from public declarations and submissions; Etherscan runs a removal process for tags "falsely attributed" to an address. Labels differ between explorers, go stale, and are sometimes simply wrong.

So what — clusters and labels are leads. In a report, they are "attributed by the named explorer or vendor, not independently verified" until corroborated.

Source: Meiklejohn et al. — A Fistful of Bitcoins (IMC 2013) · Etherscan — public name tags and labels

Part 2 — The travel rule: what it actually demands

The ledger's pseudonymity is exactly why the oldest rule in payments was stretched over it. If the chain will not carry names, the institutions on either side of a transfer must.

From wire transfers to wallets — Recommendation 16

FATF Recommendation 16 has long required banks to send identifying information about payer and payee along with wire transfers — the "travel rule", because the data must travel with the payment. In October 2018 the FATF amended its standards to bring virtual assets and virtual asset service providers (VASPs) within scope; in June 2019 it applied the Recommendation 16 obligations to virtual-asset transfers between VASPs; and in October 2021 it published updated guidance on implementation. The FATF baseline permits a de-minimis: countries may exempt virtual-asset transfers below USD/EUR 1,000 from parts of the requirement. Not all have taken the option — the EU, notably, has not.

So what — nothing here is novel law. It is the same rule correspondent banking has run for decades, extended to a new rail — and the reason a "crypto business" cannot treat identity data as someone else's problem.

Source: FATF — Updated Guidance for a Risk-Based Approach to Virtual Assets and VASPs (October 2021)

What must travel — the data

Party	Required with the transfer
Originator	Name · account number or wallet address used in the transaction · and one of: physical address, national identity number, customer identification number, or date and place of birth
Beneficiary	Name · account number or wallet address

Two properties matter for evidence purposes. First, the data does not move on-chain: it passes between the institutions through separate, secure channels, so the ledger and the identity record are two different artefacts held in two different places. Second, both institutions must hold the information under record-keeping duties — it persists after the transfer settles.

So what — once funds have crossed regulated VASPs, the name attached to a hop exists off-chain in travel-rule records. That is where a properly directed production or disclosure request points.

Source: FATF — virtual assets

The EU — Regulation (EU) 2023/1113

The recast Transfer of Funds Regulation rewrites the EU's 2015 wire-transfer rules and extends them to crypto-assets. It applies from 30 December 2024, alongside MiCA's authorisation regime for crypto-asset service providers (CASPs).

No de-minimis — the EU declined FATF's USD/EUR 1,000 option: the information duties attach to CASP transfers of any amount.
Self-hosted addresses — for a transfer exceeding EUR 1,000 between a customer's account and a self-hosted address, the customer's CASP must take adequate measures to assess whether that address is owned or controlled by the customer (Article 14(5); mirrored on the receiving side).
Missing data has consequences — the EBA's Travel Rule Guidelines (EBA/GL/2024/11, also applicable from 30 December 2024) set out how CASPs must detect transfers with missing or incomplete information and when to reject, return or suspend them.

So what — from 30 December 2024, any transfer touching an EU CASP generates an identity record, whatever the amount. For tracing work, that date bounds where records can be expected to exist.

Source: EUR-Lex — Regulation (EU) 2023/1113 · EBA — Travel Rule Guidelines

Switzerland — stricter than the standard

FINMA set its position early, in Guidance 02/2019 (Payments on the blockchain, 26 August 2019), and it is technology-neutral: the information duties of Art. 10 AMLO-FINMA — originator and beneficiary details accompanying payment orders — apply to token transfers as they do to bank transfers, with no relief.

The stricter part — for as long as originator and beneficiary information cannot be transmitted reliably in the payment system itself, FINMA-supervised institutions may send tokens only to external wallets that belong to their own, already verified customers, and may receive tokens only from such wallets. Unlike the FATF standard, there is no exception for unregulated wallet providers — a practice FINMA itself describes as "one of the most stringent in the world".
The CHF 1,000, in context — a separate threshold, often confused with the travel rule. FINMA lowered the customer-identification threshold for exchange transactions in cryptocurrencies from CHF 5,000 to CHF 1,000 (Art. 51a AMLO-FINMA), implementing the 2019 FATF standards; the partially revised ordinance in force since 1 January 2023 requires technical measures to stop linked transactions within thirty days from slipping under it, for exchanges against cash or other anonymous means of payment. It is an identification threshold for exchange business — the Art. 10 information duty itself carries no de-minimis.

So what — a Swiss counterparty's file should contain proof of wallet ownership, not merely collected names. When reconstructing a transfer chain through Switzerland, ask for the ownership evidence, and expect it to exist.

Source: FINMA — Guidance 02/2019 press release · FINMA — partially revised AMLO-FINMA (November 2022) · Fedlex — AMLO-FINMA (SR 955.033.0)

Self-hosted wallets — three treatments

A self-hosted (or "unhosted") wallet is one whose keys are held by the person, not by a service provider. There is no institution on that side of the transfer to hold travel-rule data — so each regime answers the gap differently.

Regime	Treatment
FATF standard	VASPs collect originator and beneficiary information from their own customer; countries may impose further controls on higher-risk unhosted transfers
EU (Reg. 2023/1113)	Collect and hold information for transfers to and from self-hosted addresses; above EUR 1,000 to a customer's own self-hosted address, take adequate measures to assess ownership or control
Switzerland (FINMA practice)	Transfers only to and from external wallets proven to belong to the institution's own verified customer — third-party external wallets effectively barred while identity data cannot travel reliably

So what — self-custody does not put funds beyond analysis. Every movement remains on the public ledger; what varies is which institution, in which jurisdiction, holds the identity data for the hop before or after.

Source: FATF — Updated Guidance (October 2021)

The sunrise problem

The travel rule "rises" jurisdiction by jurisdiction: a VASP in a compliant country must send and expect identity data, while counterparties elsewhere are under no equivalent duty yet. The FATF's June 2025 targeted update put numbers on it — of 117 jurisdictions surveyed, 85 had passed travel-rule legislation (up from 65 a year earlier), while enforcement and supervisory findings continued to lag well behind the laws themselves. In the interim, compliant firms receive transfers with missing data and must apply documented policies — the EBA guidelines above are the EU's answer — on when to ask, hold, return or reject.

So what — an incomplete travel-rule trail is often a jurisdiction-and-date artefact, not evidence of concealment. Before drawing an inference from missing data, check what the counterparty's regime actually required at the time of the transfer.

Source: FATF — targeted update on virtual assets and VASPs (June 2025)

IVMS 101 — the common language

The data has to be structured somehow, and the industry converged on one model: the interVASP Messaging Standard (IVMS 101), developed by a joint working group formed in December 2019 by three industry associations and released in May 2020. It defines the datatypes and fields for originator and beneficiary payloads — names, address formats, identifiers, character-set handling — and is used across the main travel-rule solution providers. The standard is now maintained by the interVASP Standards Working Group, which released the current revision, IVMS 101.2023, with an update in June 2024.

So what — when requesting travel-rule records from a VASP, ask for the IVMS 101 payload by name: it is structured, machine-readable, and its fields are defined in a published standard rather than by the respondent.

Source: interVASP — IVMS 101

Why this matters at the evidence desk

The claim	Its quality
"Transaction X moved amount Y from address A to address B at time T"	Ledger fact — citable by hash, reproducible by anyone, effectively tamper-proof
"Address A belongs to person P"	Attribution — probabilistic, built on clustering, labels or vendor intelligence; needs corroboration
"Person P instructed the transfer"	Inference — needs off-chain evidence: travel-rule records, exchange KYC, devices, admissions, disclosure

A transaction hash is about as good as documentary evidence gets: precise, timestamped, reproducible against a public source by every party to a dispute, and unalterable after the fact. Cite it like a citation — hash, chain, block height, date read.

Attribution is a different species of claim, and the file should say so. State the basis for every name attached to an address, keep the confidence level visible, and corroborate through the off-chain records this dossier's second half maps — because since the EU and Swiss regimes hardened, identity data now exists somewhere for most transfers that touch a regulated counterparty. Knowing which regime, which date and which institution tells the practitioner where that corroboration can actually be obtained.

Next: Tracing in practice performs this method on real transactions — a worked example, then live exercises with model answers. Unfamiliar terms across both dossiers carry hover definitions; the full list is in the glossary.

Orientation, not advice · verify against the primary texts