Spotting a bridge crossing
Read a bridge's source-side message fields without assuming delivery on another network.
#Plain languageIn plain terms
A bridge can coordinate transfers between networks, but a source-side deposit is not proof that the recipient received value elsewhere. The destination needs its own evidence.
Forensia can extract a message identifier as a candidate lookup key. It is not globally unique: network domains, protocol version and complete relay fields matter too. Similar amounts and times do not establish correspondence.
#How it worksHow it works
- Look through a successful transaction's event logs for any emitted by a known bridge contract.
- Fetch that contract's published interface so the log can be decoded.
- Decode the log and pull out the fields that identify the message.
- Report them as source-side identifiers, with the bridge's own documentation as the reference.
#Technical detailThe exact rules
A bridge contract is one listed as a bridge in the public contract registry for that network. The match is exact and scoped to the network. The registry covers Across, Arbitrum, Base, OP Mainnet, Polygon, Hop, Ronin, Stargate, Synapse and Wormhole contracts.
At most 2 bridge contracts are read per transaction, and only the first log from each. This can miss a later message event. The interface comes from the verification registry; a reported proxy implementation's interface is tried next. Only for the allowlisted Across SpokePools on Ethereum and Base can the pinned bytes32 FundsDeposited shape be used as a fallback. It cannot be borrowed by a different bridge or network.
The decoder requires the exact topic count and canonical event encoding, with a 16 KiB data cap. Contradictory ABI entries, malformed padding and trailing bytes are rejected. Event shape and present-day ABI context do not verify the contract's historical implementation or prove destination execution.
A decoded event is used only when its name suggests a message and it carries at least one identifier field.
| Kind | Field names looked for |
|---|---|
| Identifiers | depositId, destinationChainId, sequence, nonce, messageNonce, messageId, transferId, stateId, transferNonce, rootChainId, chainId |
| Participants | depositor, recipient, to, from, sender, receiver |
| Amounts | inputAmount, outputAmount, amount, value |
Findings: finding:cross-chain-message-identifier, class observed, and finding:cross-chain-boundary, class limitation, whenever a bridge contract appears in the result at all.
#LimitsWhat it does not tell you
- Reading an identifier does not confirm the transfer arrived, succeeded or reached the same party. A deposit can be refunded or remain unclaimed.
- Bridges pay out from pooled funds. The coins that arrive are not the coins that were deposited.
- Similar amounts and times on two networks are not a match. Unrelated transfers of similar size are common.
- A bridge that is not in the registry, or whose interface is not published, is not decoded.
- Only successful transactions are read for bridge events.
- For one bridge, Across between Ethereum and Base, Forensia can go further and look for the matching fill.