How to Trace Crypto Across Cross-Chain Bridges

1. Why a bridge interrupts the trail

On a single chain, a transfer is one event: value leaves an address and arrives at another, recorded in one place.

A cross-chain movement is not one event. The source-chain transaction and the destination-chain settlement are separate transactions on separate ledgers, with no shared block, no shared ordering and — in many designs — no identifier that a block explorer carries automatically from one side to the other.

What connects them depends entirely on the bridge's architecture. Some protocols publish an explicit cross-chain message or identifier that an investigator can follow directly. Others leave only indirect traces, so the two sides must be correlated from their contents and timing. The first task, then, is not to match amounts — it is to identify the protocol and understand how it settles.

This is also why coverage is uneven across the industry. A 2026 research study, XSplicer (Lin et al., arXiv preprint), surveyed 131 bridges and reported that only about 16.79% provided complete public tracking of cross-chain correspondences. Treat that as the authors' survey finding rather than a fixed industry constant, but the direction is clear: for many protocols, the evidence an investigator needs is partial.

2. A seven-step evidence model

The rest of this guide follows one framework. For any cross-chain hop, work through these steps in order and keep the evidence for each separate from the conclusions you draw from it.

1. Source-chain observation — what left the source chain, and in what transaction.
2. Bridge/protocol identification — which bridge or cross-chain service was used.
3. Settlement mechanism — how that specific protocol delivers value on the destination chain.
4. Destination-chain observation — the candidate settlement event(s) on the destination chain.
5. Hard linking evidence — protocol-native correspondence that ties the two sides together.
6. Supporting correlation — amount, timing and recipient evidence, used to strengthen or constrain the match.
7. Investigator conclusion and confidence — proven, probable or partial, stated explicitly.

The discipline is in step 7. A match supported by a shared protocol identifier is a different claim from a match supported only by “a similar amount arrived a few minutes later.” Both can be legitimate findings. They are not the same level of certainty, and a good report never lets one quietly become the other.

3. Bridge architectures differ — identify the mechanism first

There is no single “bridge transaction” pattern. Before looking for a destination-side event, establish which settlement model the protocol uses, because that determines what evidence can exist at all.

Do not assume every source-chain deposit has a simple one-to-one mint on the destination, and do not assume a liquidity-based route is identifier-free. The mechanism decides what evidence is available — so identify it before you start matching.

4. Four layers of linking evidence

Within step 5 and step 6 of the model, not all “links” are equal. It helps to grade them explicitly.

Explicit protocol-native correspondence

A value the protocol itself uses to connect the two sides: a signed message, an attested nonce, a sequence number, a message identifier. When present and verifiable on both chains, this is the strongest evidence and can establish the link deterministically.

Protocol metadata that constrains the match

Fields the protocol records that are not a unique identifier but sharply narrow the candidates: the destination domain or chain, the declared recipient, the message sender, the asset. These do not prove a single pairing on their own, but they can exclude almost every alternative.

Supporting amount, timing and recipient correlation

The destination amount (source amount minus protocol fees and any relayer cost), the settlement time window and the receiving address. Useful corroboration — and sometimes the only evidence available — but see the next section for why it is not sufficient by itself.

Investigator inference

A reasoned hypothesis where stronger evidence is unavailable: “this is the most plausible destination movement given the amount, timing and recipient.” Record it as a hypothesis, not a fact.

5. Why amount and timing alone are not enough

Matching by “the same amount came out a few minutes later” is tempting because it is easy. It is also unreliable on its own.

• Amounts rarely carry across exactly. Protocol fees, relayer gas and swap slippage reduce the destination amount, so you are matching within a tolerance band, not on equality.
• Common amounts collide. Round figures and popular stablecoin sizes recur constantly; several unrelated transfers of a similar size can land in the same window.
• Timing windows vary by design. Some routes settle in seconds; others wait for source-chain finality or sit unclaimed for far longer. A wide window admits more false matches.
• Batching and aggregation blur the one-to-one assumption. Settlement may be batched, split or routed through an intermediary, so the destination movement need not mirror the source one-for-one.

Amount and timing are good for narrowing candidates and for corroborating a link established by stronger evidence. Leaning on them alone produces a plausible story, not a verified one.

6. Worked example: a burn-and-mint transfer you can verify yourself

Circle's Cross-Chain Transfer Protocol (CCTP) is a useful teaching case because the link is explicit. CCTP is burn-and-mint: USDC is burned on the source chain and native USDC — less any executed CCTP fee, where one applies — is minted on the destination, the same canonical asset rather than a wrapped representation. Circle's attestation service observes the burn, signs a cross-chain message that authorizes the mint, and assigns the protocol nonce during that attestation. CCTP V2 supports fees (a maxFee set by the sender and an executed fee applied on mint); in the worked example below that executed fee is zero, so 140,000 USDC burned corresponds to exactly 140,000 USDC minted.

One detail matters for evidence, and it is specific to CCTP V2. The source-chain DepositForBurn event carries no nonce; the raw message emitted by MessageSent contains a zero-value nonce placeholder. Circle assigns the actual CCTP nonce off-chain during attestation, and that assigned nonce is what appears on the destination chain when the message is received. The example below is a real mainnet transfer — an Ethereum to Base transfer of 140,000 USDC — with every field taken directly from the two transactions' event logs.

Full identifiers, for reproduction — source transaction (Ethereum) 0xcdbe38cd28514d0bc7480eb9abbd807b2fb376784306c2e1d736cb46fbeae699; destination transaction (Base) 0x02293585bd3e5877938a0b3acfdee1b1fc844e7f65dbf92c0e9473d41c5bd156; attested nonce 0xd6a70f196ffce11142f1189734fa08a1ed460a9770339250a4b1315552bd0c45; mint recipient 0x86954fae9135831b56c1262b2b21bd1cb62bc5a0.

Read the evidence in the order of the model, and be exact about where each piece originates. The source transaction burns 140,000 USDC; its message declares the destination domain (Base) and the mint recipient, and leaves the nonce as a zero-value placeholder. The assigned nonce is never emitted on the source chain — Circle assigns it during attestation and binds it to this source transaction inside a signed cross-chain message. On Base, that message is received carrying the Circle-assigned nonce, a source domain that points back to Ethereum, and a message body byte-for-byte identical to the one Ethereum emitted; the accompanying mint delivers exactly 140,000 USDC — executed fee zero, so the destination amount equals the source amount — to the declared recipient. The protocol-native correspondence here is the signed attested message that ties the source transaction to the assigned nonce and on to the destination settlement — not a single nonce value sitting unchanged on both ledgers. The identical message body, the matching recipient and amount, and the source-domain field are the on-chain evidence that the message delivered on Base is the one the source emitted.

You can reproduce the link from public data by either of two routes. The convenience route is Circle's public attestation API — the Iris /v2/messages endpoint, keyed by source domain and the source transaction hash — which returns the attested message and its assigned nonce. The fully on-chain route needs no third-party API: read the DepositForBurn and MessageSent events for the source transaction on Etherscan, then read the MessageReceived and MintAndWithdraw events for the destination transaction on Basescan. The destination MessageReceived carries the Circle-assigned nonce, reports Ethereum as its source domain, and contains a message body that is byte-for-byte identical to the one the source MessageSent emitted, while MintAndWithdraw pays the declared recipient the expected amount — all executed by Circle's CCTP V2 contracts. That body-level identity, together with the matching source domain and recipient, is what ties the two transactions on-chain — an independently reproducible link, the strong end of the evidence scale.

7. The harder case: a probable match

Not every hop ends that cleanly. Consider a route where, from your vantage point, no shared identifier is observable on both sides — a swap or aggregator path where the asset itself changes, or a protocol whose cross-chain records you cannot access.

Here you are left with protocol metadata and correlation: a destination movement of roughly the expected amount (after plausible fees or slippage), in a plausible time window, to a plausible recipient. If one candidate fits and others can be excluded, that supports a probable link. If several destination movements are plausible, or the available evidence is incomplete, record a partial result and say which candidates remain.

Two cautions. First, a changed asset is not a broken trail — value continuity and token continuity are different things, and a swap in the path is a feature of the route, not proof the trail ended. Second, do not generalize from one example: the fact that a particular route offered only correlation does not mean its whole protocol class is correlation-only. Many liquidity and messaging protocols expose identifiers or metadata; check the specific one before you conclude.

A probable match, clearly labelled as probable, is a legitimate investigative finding. A probable match presented as a proven one is an error.

8. Continue the trace after the bridge

Connecting the two sides is not the end of the investigation. The destination settlement is a new starting point.

Whatever lands on the destination chain — the same asset, a wrapped representation or the output of a swap — becomes the next transaction to investigate. From there the work is ordinary single-chain tracing again: follow the recipient forward, watch for further bridging, and apply the same discipline of separating observation from inference. Our guide to tracing stolen crypto covers the downstream flow, and the broader method sits in the suspicious-transaction investigation guide. When the destination chain is TRON and the asset is USDT-TRC20, the guide to tracing USDT on TRON covers that single-chain continuation in detail.

Preserve the bridge hop as you would any material finding: both transaction hashes, the networks and domains, the amounts, the linking identifier where one exists, and a one-line statement of how confident you are and why. Another investigator should be able to re-walk the link from your notes.

How OnChainRisk fits this workflow

Automated tooling can accelerate the mechanical parts — identifying a bridge interaction, surfacing the likely destination network and flagging possible cross-chain activity — but it should never replace the evidence underneath a conclusion.

OnChainRisk helps investigators detect possible bridge and cross-chain activity on supported networks. Once a destination-side transaction or address has been established from the available evidence, OnChainRisk can be used to continue the investigation on networks and analysis surfaces that support it. Cross-chain coverage and depth vary by network and analysis type, so every cross-chain link should still be recorded as proven, probable or partial based on the evidence available — not asserted automatically. For where model-assisted reasoning fits into this process, see AI Agents for Crypto Investigations; for building this into a pipeline, see the blockchain analytics API.

Key takeaways

• A cross-chain hop creates separate source-side and destination-side activity on different ledgers; the evidence that connects them depends on the protocol's architecture.
• Identify the bridge and its settlement mechanism before you try to match anything.
• Grade your evidence: protocol-native identifier, then constraining metadata, then amount/timing/recipient correlation, then inference.
• Amount and timing alone narrow and corroborate — they do not prove.
• Where a protocol exposes protocol-native correspondence (as CCTP does through its signed attested message and assigned nonce), the link can be deterministic and independently reproducible.
• Where it does not, record a probable or partial result — and do not generalize one route's evidence model to its whole protocol class.

Cross-chain tracing is not about forcing a clean answer. It is about establishing the strongest supportable link, labelling its confidence honestly, and preserving the evidence so someone else can follow it.