Direct answer: an auditable trace must allow another analyst to reproduce the material conclusions from the same inputs. The goal is not maximum distance; every hop needs transaction evidence, asset continuity, time logic, and an explicit stop rule.
Step 1: normalize case input
Standardize network, address format, transaction hash, token contract, decimals, amount, timezone, and narrative. Mark the narrative as the reporting person’s statement rather than treating it as an on-chain fact.
Step 2: verify the loss transaction
Confirm existence, success, affected sender, recipient or contract, asset, and amount. Ethereum documentation identifies fields such as from, to, value, input, and signature; contract interactions also require calldata and event parsing.
Step 3: create an address-security snapshot
Record multi-chain balances, token approvals, multisig or permission settings, native balance, contract interactions, and recent anomalies. Safety advice must follow concrete approval or device evidence, not a scam label alone.
Step 4: normalize fund-flow edges
Convert native transfers, token events, internal calls, swaps, and bridges into one edge model: source, destination, asset, quantity, time, hash, event index, source, and evidence grade. Deduplicate records while retaining a reference to the raw provider response.
Step 5: apply bounded recursion
Match downstream candidates by asset, amount, time, and counterparty. Limit address count, API calls, runtime, and branch width. Stop at a reliable CEX, bridge, mixer, non-unique match, or data gap and record why. A boundary is quality control, not proof that funds disappeared.
Step 6: validate entity labels
Record label source, update date, and confidence. A CEX value point requires both a continuous path and an entity label. Treat a single-provider label as an association until supported by platform-published information or a second independent source.
Step 7: form judgments and scores
Output verified facts, associations, inferences, unknowns, gaps, and next actions separately. Explain scoring dimensions and state that the result is an investigation-triage indicator, not a statistical probability or legal finding.
Step 8: archive and version
Retain submitted input, hashes of raw API responses, normalized path, query time, tool version, label sources, conclusions, review record, and report version. Human revisions must not erase the prior version.
Related cases
Use the dispersal, bridge, consolidation, and exchange-intersection cases in the Case Library to test branch and stop rules.
Review and data scope
Data cutoff: 2 August 2026. Reviewed by the Crypto Forensics Lab Editorial Team for reproducibility, evidence boundaries, label validation, and version audit. This SOP does not replace network, provider, or jurisdiction-specific requirements.