The investigation lifecycle: from question to hypothesis

A crypto investigation is a project with legal consequences, and it fails in predictable ways: preservation windows are missed, scope drifts, findings go unreviewed and nobody can later explain why a lead was dropped. It also fails quietly: on-chain data is so interconnected that an investigator who starts from a favorite explanation can almost always find transactions that seem to confirm it. A defined lifecycle gives each stage a purpose, an output and a record in the case file; a well-framed question and competing hypotheses keep the analysis honest inside it.

The stages at a glance

ISO/IEC 27043 groups investigations into readiness, initialization, acquisitive and investigative processes, with concurrent processes such as authorization, documentation and chain of custody running throughout: threads from intake to closure, not stages. Nor are the stages linear. Analysis reveals new seeds, such as a second victim or a bridge to another chain, sending the case back to scoping and collection; a review that finds a gap sends it back to planning. Every loop leaves a dated entry explaining the change.

Intake and triage

Intake captures the report as received: who reported, what is alleged, every identifier supplied (txids, addresses, account IDs, screenshots, chat exports), event times in UTC, the claimed loss, and what the reporter has already done, since a victim who has posted the scammer's address or contacted the exchange may already have alerted the subject.

Triage decides priority. Speed often decides the outcome, so the factors ask whether action now can still change things.

Funds mixed two years ago are recorded but not worked first. Record the triage decision and its reasons: a decision not to act may also need explaining later.

From request to answerable question

Requests rarely arrive in a usable form. "Find the scammers" or "Who is behind this wallet?" describe a worry, not a question data can answer. A good question is specific (it names the assets, addresses or events), bounded (in time, hops or effort), answerable from data that can lawfully be obtained, decision-relevant (the answer changes what someone will do: freeze, request records, close the file) and neutral (it does not presuppose the answer).

The first rewrite drops "who": a private person's identity is usually not answerable from chain data alone, and what the case needs is the type of entity and the services where off-chain records exist (Lesson 3.4). Questions are also descriptive (what happened), explanatory (why, or what type of actor) or estimative (something not observable or not yet happened, such as whether the remaining funds will reach an exchange); each needs a different kind of answer and confidence statement (Lesson 9.2).

Scoping

The scope statement sets the questions and the boundaries of every finding.

Seeds, the identifiers the case starts from, are verified on chain before use: victims misread screenshots, copy truncated addresses and confuse networks, and the same EVM address format is valid on many chains, so state which were checked. Express the period as block heights as well as UTC dates, with a margin before the first known event; block ranges are exact, timestamps carry caveats (Lesson 2.1).

Depth limits matter because tracing explodes: if each address sends to three others on average, five hops give 3^5 = 243 paths and ten hops 59,049. A stop rule at custodial services is not laziness: beyond a hot wallet, movements no longer belong to the original owner. A quick sizing query counting the seeds' distinct counterparties in the block window tests the scope: 40 is workable; 40,000 suggests a seed is a service and the question needs rethinking.

Scope creep is not wrong in itself, but unrecorded scope creep is. When the scope changes, record what changed, why, who approved it and on what date.

Planning and competing hypotheses

The investigation plan lists tasks, the data each needs, the legal authority each source requires (Lesson 1.3), owners, deadlines and dependencies; requests abroad can take months, so they start early, in parallel with on-chain work.

A hypothesis is a testable explanation of what the data shows. Write down several before evaluating any, include the benign one, make them as mutually exclusive as possible, and ask "what else could produce this pattern?" until new answers stop. For a reported investment scam: the operators took the funds; a third party compromised the victim's wallet; or the platform was a real, if failing, business. The case file must show which hypotheses were tested and what evidence eliminated them.

Structure matters because, as Richards Heuer, a former CIA analyst, put it, biases behave like optical illusions: knowing about them does not make them go away. Lesson 1.5 covers bias controls in general; the on-chain forms are:

Testing hypotheses: ACH

Analysis of competing hypotheses (ACH) is the technique Heuer described in Psychology of Intelligence Analysis (1999); it comes from intelligence practice, not law. Its eight steps: (1) identify the hypotheses, ideally with colleagues who see the case differently; (2) list the significant evidence, including assumptions and absent expected evidence; (3) build a matrix marking each cell consistent, inconsistent or not applicable; (4) refine it, dropping evidence that does not discriminate; (5) try to disprove hypotheses, so the one with the fewest inconsistencies survives; (6) test how sensitive the conclusion is to a few critical items; (7) report the relative likelihood of all hypotheses; (8) set milestones, future observations that would show events taking a different course.

The central idea is diagnosticity: evidence consistent with every hypothesis says nothing about which is true, however much of it you collect, while one item inconsistent with two hypotheses can settle the question.

A worked matrix

Bitcoin address bc1q…m4x2 receives 38 small payments from 38 addresses over six days, then spends them all in one transaction to two outputs. Three hypotheses fit: H1, it is an exchange deposit address being swept to a hot wallet; H2, an owner is consolidating its own coins while fees are low; H3, a thief is gathering outputs from earlier peel chains.

E1 and E5 are not diagnostic; E2 fits H1 because exchanges receive from anyone. H1 has no inconsistencies, H2 three and H3 two. Sensitivity: E3 and E4 carry the conclusion, and both rest on one label source (E3 by the common-input logic of Lesson 4.1). If that source is wrong, H1 collapses, so the label is checked independently, for example by confirming the sweep pattern repeats across many deposit addresses. Milestone: if bc1q…m4x2 ever sends funds anywhere but the exchange's known hot wallet, H1 deserves a second look. The funds most likely reached a custodial service, so the next step is a request for records through legal process, not more tracing.

From collection to closure

Collection acquires data under the right authority and preserves it for later verification (Lesson 8.2). Analysis turns it into findings with method, basis and confidence (Module 3). Review is a separate stage, not a courtesy: a reviewer who did not do the work re-performs the key hops from raw data and challenges every inference, and disagreements and their resolution go into the file (Lesson 8.3). Reporting (Lesson 9.2) and disclosure, including unused material and tool and label provenance (Lesson 8.4), follow. Closure is easy to neglect: the memo records the outcome, open leads, assets still held and who controls them, retention periods for evidence and personal data, and lessons learned. Crypto cases often reopen when dormant funds move years later, so the file must let a different examiner pick up where the last one stopped.

A worked intake

The case file is the single, access-restricted place where the case lives: intake, scope and changes, plan, legal authority, requests and returns, evidence log, notes, findings, reviews, reports, disclosure and closure.

A victim reports losing 48,500 USDT on Tron in five payments over three weeks to a trading platform that has stopped responding.

1. Verify the seeds. Four txids are confirmed on Tron. The fifth, from a screenshot, is not on Tron but on Ethereum, where the victim had sent a test payment; both facts are recorded.
2. Look forward and triage. The last payment, 9,800 USDT, reached an address that swept to a hot wallet labeled Exchange K two hours ago: funds at a custodial service, moved recently, priority high.
3. Act. Preservation and voluntary freeze requests go to Exchange K the same morning (Lesson 1.4); whether the stablecoin issuer could freeze the receiving address goes into the plan.
4. Scope. Seeds, two chains, a period starting a week before the first payment, three questions and competing hypotheses are written down.

{
  "case_id": "CF-2026-0147",
  "received_utc": "2026-03-04T09:15:00Z",
  "allegation": "investment scam; funds sent to an unresponsive trading platform",
  "seeds": [
    {"chain": "tron", "type": "txid", "value": "7b2f…d9e0", "verified": true},
    {"chain": "ethereum", "type": "txid", "value": "0x3a8c…f71b", "verified": true,
     "note": "screenshot labeled Tron; found on Ethereum"}
  ],
  "reported_loss": {"asset": "USDT", "amount": "48500.00"},
  "priority": "high",
  "priority_reason": "9,800 USDT reached a suspected Exchange K deposit address 2 hours before intake",
  "immediate_actions": ["preservation request P-01", "voluntary freeze request F-01"],
  "assigned_to": "examiner-07",
  "authority_status": "production order requested"
}

The record shows verified seeds, the discrepancy and its resolution, the reason for the priority and each action with a reference to the request in the file. Two of five seeds are shown; the full list goes in the scope statement. Amounts are strings to avoid rounding.

Exam focus: expect questions on the nine stages and their case-file outputs, ISO/IEC 27043 concurrent processes, and triage factors. Be able to rewrite a vague request into a specific, bounded, answerable, decision-relevant and neutral question; list the scope elements (verified seeds, block-height periods, hop limits, stop rules at custodial services); and explain why depth explodes (3^5 = 243). Know competing hypotheses including a benign one, on-chain biases, and ACH: ranking by inconsistency, diagnosticity, sensitivity and milestones. Recognize a sound intake record and closure memo.