Chain-hopping and cross-chain tracing

Stolen and criminal funds now cross several blockchains within hours, and each crossing moves the evidence to a different ledger, often to a different record holder in a different country. Two ledgers share no transaction edge, so cross-chain tracing is the work of reconnecting their records and being honest about how strong each reconnection is. It is also a contest of time: every hop adds a matching problem, records to preserve and a link whose strength must be stated. Swaps and instant exchanges are covered in Lesson 5.2, bridges, rollups and other chain designs in Lesson 5.4; this lesson covers the pattern, the grading of cross-chain links, matching when no identifier exists, and how to record and run a multi-chain case.

Why offenders hop

Chain-hopping is the movement of value across blockchains or asset types, through bridges, swaps or exchange services, with the effect (and often the purpose) of making a trail harder to follow. Offenders hop for several reasons, usually at once:

• To break the graph. Every crossing forces the investigator to establish a link that a single-chain tool will not draw automatically, and some tools cover only certain chains and bridges.
• To leave freezable assets. Stablecoin issuers can freeze tokens at an address (Lesson 10.1), so thieves holding stablecoins often swap them for a native asset within minutes. The reverse also happens: funds are converted into stablecoins on a low-fee chain just before cash-out, because that is where brokers and buyers are.
• To reach liquidity and exits. Large amounts need deep markets, and cash-out venues (OTC brokers, peer-to-peer sellers, exchanges with weak controls) favor particular chains and assets.
• To fragment jurisdiction. A trail that touches a bridge front end in one country, an instant-exchange service in a second and an exchange in a third needs three sets of legal requests, each with its own delay (Lesson 1.3).
• To reach privacy systems. Some hops end in a privacy coin or a mixer (Module 6).

Hopping is not in itself evidence of crime: ordinary users bridge to save fees or chase yields. The FATF report Virtual Assets Red Flag Indicators of Money Laundering and Terrorist Financing (September 2020) treats as red flags transactions that use more than one type of virtual asset despite extra fees, and large conversions between asset types with no logical business explanation. The indicator is the combination: speed, cost, no economic purpose and a criminal source.

Typical sequences

After the March 2022 Ronin bridge theft, a public analysis by a security firm described stolen ETH moving through a smart-contract mixer, swapped on DEXs for a bitcoin-pegged token, bridged to the Bitcoin network and unwrapped into BTC, before part went through custodial bitcoin mixers. After the February 2025 theft of about $1.5 billion from the Bybit exchange, an estimate published on February 27, 2025 by the security researcher Taylor Monahan counted at least 161,490 ETH moved through the THORChain cross-chain swap protocol in 3,934 transactions within about five days, and the victim's own update of March 4, 2025 reported that about 72% of the stolen ether (361,255 ETH) had passed through THORChain and about 83% (417,348 ETH) had been converted to bitcoin.

A generic laundering sequence for a theft or scam:

Changes of form on one chain

Before leaving a chain, funds often change form, and each change must be recorded with its rate. A DEX swap is a deterministic link in one transaction, but the trace must switch asset (Lesson 5.2). Wrapped assets represent one asset in another form. WETH wraps ETH on Ethereum itself: the WETH contract emits a Deposit event when ETH goes in and a Withdrawal event when it comes out, one to one. Wrapped bitcoin tokens on Ethereum are minted and burned by a custodian or a bridge, so the link back to real bitcoin runs through that issuer's records, not through either chain. Bridged versions of the same token can coexist on one network under different contract addresses, so always identify a token by its contract address, never by its ticker.

Grading cross-chain links

Within one chain, a spent output or a transfer event is a hard fact. Across chains there is no shared edge, so each link rests on one of three bases:

A path is only as strong as its weakest link. Applied to the usual hop types:

Three practical consequences follow. First, where the destination address is written into the source transaction (a bridge recipient field, a swap memo), the link does not depend on matching at all: read the source event, find its identifier and destination fields, and look for the same identifier on the destination chain before searching by amount (Lesson 5.4 sets out the bridge matching steps). Second, a hop through a custodial service ends the on-chain trail on the deposit side (Lesson 3.4); what comes out is a new trail that must be linked by records or by explicit inference. Third, record the asset change at every hop, with the rate and the price source, because amounts change form as well as ledger.

Matching by amount and time

When no identifier connects two sides, you must search the destination chain for candidates, and the search window must come from the mechanism, not from habit.

Time windows. Block intervals range from well under a second to about ten minutes, and delays differ by mechanism: seconds to a few minutes for a relayer fill, minutes for a bridge that waits for source-chain finality, about a week for a canonical withdrawal from an optimistic rollup, and minutes to hours for an instant-exchange service, depending on its confirmation policy and queue. Convert every timestamp to UTC, record block heights on both chains and allow for clock differences in services' own records.

Amount windows. Expected output equals input times the exchange rate, minus the service fee, minus network fees on both sides. Compute a range, not a point: the rate at deposit and at payout can differ, and some services quote a fixed rate for a short period. Record the price source and the time of each quote.

A worked example

A wallet under investigation sends 2.00000000 BTC to an instant-exchange deposit address at 14:02 UTC. At the time, 1 BTC = 60,000 USD and 1 ETH = 2,400 USD, so 2 BTC is worth 50 ETH. Allowing a service fee of 0.5% to 1% plus network costs, the expected payout is roughly 49.4 to 49.75 ETH. The query lists the service's ETH payouts in the following hour within a 5% band below 50 ETH:

-- service_outflows_eth: case table of the service's ETH payouts, built from
-- transactions and traces, with value converted from wei to ETH
SELECT o.transaction_hash, o.to_address, o.block_timestamp, o.amount_eth,
       ABS(o.amount_eth - 49.6) / 49.6 AS rel_gap      -- distance from expected value
FROM service_outflows_eth o
WHERE o.block_timestamp >= TIMESTAMP '2026-05-11 14:02:00'
  AND o.block_timestamp <  TIMESTAMP '2026-05-11 15:02:00'
  AND o.amount_eth BETWEEN 47.5 AND 50.0                 -- 5% band below 50 ETH
ORDER BY rel_gap;

It returns four payouts: 49.61 ETH at 14:19, 49.58 ETH at 14:51, 49.20 ETH at 14:33 and 48.95 ETH at 14:48. The first two fit the expected range; the last two do not. Matching has narrowed four candidates to two, but it has not produced a link. Further evidence can separate them: does one recipient later send funds to an exchange deposit address the subject used before? Does it share gas-funding sources or timing habits with the subject's known wallets? Each independent fact strengthens or weakens a candidate.

Quantifying and defending the match

Probabilistic links need numbers, not adjectives alone:

• Candidate set size: how many payouts fit the window and band. One candidate among four is very different from one among forty.
• Chance-match rate: run the same rule for a sample of unrelated deposits to the same service at random times. If 60% of random deposits also find a "match", a match is weak evidence; if 2% do, it is strong.
• Sensitivity: widen and narrow the window and band. A link that appears only under one narrow setting is fragile.
• Corroboration: count independent signals (amount, timing, destination behavior, later convergence with known wallets) and note any that contradict the link.

Write down the window and band, and why, before running the search: a match found only after the window was adjusted to fit is worth little in court. Then translate the result into calibrated language (Lesson 9.2), keep deterministic and probabilistic links visually distinct in diagrams (solid and dashed edges, Lesson 9.3), and list identifiers and queries in an appendix so the path can be rebuilt on both chains.

Recording every hop

Each hop deserves one structured record in the case file, kept with the working notes and hashed with the other exhibits (Lesson 8.3). A fictional example:

{
  "hop_id": "H-04",
  "type": "bridge_liquidity_fill",
  "source": {"chain_id": 1, "txid": "0x5e2a…c71d", "log_index": 212,
             "block": 25466930, "block_hash": "0x8b41…e02f",
             "time_utc": "2026-06-16T02:58:11Z", "asset": "ETH",
             "amount_wei": "600000000000000000000"},
  "destination": {"chain_id": 42161, "txid": "0x91bf…04ae", "log_index": 7,
                  "block": 483120877, "block_hash": "0x2d7c…91a4",
                  "time_utc": "2026-06-16T02:58:47Z", "asset": "ETH",
                  "amount_wei": "599640000000000000000"},
  "link_key": {"origin_chain_id": 1, "deposit_id": "1840221"},
  "grades": {"flow": "A", "basis": "shared key verified on both chains"},
  "fee_explained": "0.36 ETH relayer fee quoted in deposit event",
  "sources": ["own archive node (ETH)", "provider RPC (ARB), checked on explorer"],
  "records_to_request": ["bridge front end: API and IP logs, depositor address"],
  "examiner": "EX-07", "recorded_utc": "2026-06-16T09:40:00Z"
}

The record names both sides with chain ID, transaction hash, log index, block height and hash, UTC time, asset and amount in integer base units; the key that links them; the grade and its basis; an explanation of the amount difference (600 − 599.64 = 0.36 ETH); where the data came from; and which records could confirm or extend the hop. An unexplained amount difference or a missing data source is a weakness the defense will find, so the record forces you to address both at the time. For a probabilistic hop, the same record holds the window, band, candidate count and chance-match rate in place of the link key.

Working against the clock

Offenders move in hours and legal process takes days, so the plan for a multi-chain case runs in parallel:

1. Map the hops already visible and decide for each who may hold records: bridge operators and front ends, relayers, interface operators named in swap affiliate fields, instant-exchange services, exchanges.
2. Send preservation requests to all of them at once, not one after another (Lesson 1.4).
3. Watch the unmoved balances. A dormant address on one chain may be tomorrow's next hop, and a withdrawal that will take days to complete gives time to alert the receiving service (Lesson 5.4).
4. Separate proven from inferred hops in every interim briefing, because early briefings are often what is later disclosed.

Exam focus: why offenders hop (break the graph, leave freezable assets, reach liquidity, fragment jurisdiction, reach privacy systems) and why a hop alone is not evidence of crime; the FATF 2020 red flags on multiple asset types and conversions without business purpose; typical sequences and the Ronin and Bybit patterns; WETH Deposit and Withdrawal, custodian-issued wrapped tokens and identifying tokens by contract address; deterministic, protocol-recorded and probabilistic links, their grades, and the weakest-link rule; reading the source event before matching by amount; custodial hops ending the on-chain trail; setting time and amount windows from the mechanism and fees; the worked amount-time example; candidate set size, chance-match rate, sensitivity and corroboration; what a hop record contains; parallel preservation requests.