Non-Explorer Bridge Correlation

Core idea

Some bridges publish a first-party explorer (LayerZeroScan, deBridge, Axelarscan) so attribution is a lookup. Many do not, they are decentralised, defunct, deprecated, or never shipped one. For these non-explorer bridges you reconstruct the cross-chain link from raw on-chain data on both sides. The method depends on which two “worlds” you are bridging, and correlation is only as strong as how explicitly you document which method you used and why.

Components

First, map the bridge contract addresses on each chain (you cannot correlate without them): from bridge documentation (deployment addresses per chain), Arkham/DeBank labels, the source tx’s to address (source-side contract) and the emitter of the mint event (destination-side contract), or by cross-referencing matching message ids across chains. Document these addresses, they recur.

Then correlate by direction:

1. EVM -> EVM (structured, strongest correlation), source side emits three signals: calldata to the bridge contract (destination chain ID, recipient, token, amount, nonce/messageId), a bridge event log (e.g. FundsDeposited on Across, TokenSend on Stargate, TokenSwap on Synapse), and standard ERC-20 Transfer logs. Destination mirrors these (FilledRelay on Across, TokenSwapReceived on Synapse). Method: (a) decode the source event, extract destination chain id / recipient / amount / nonce; (b) on the destination explorer, filter the bridge contract’s logs for events matching recipient AND amount-minus-fee AND nonce; (c) confirm via timestamp (within the bridge’s latency window, often 30s to a few hours) and value tolerance.
2. EVM -> BTC (structured source, value/time on destination, medium difficulty), (a) decode the source event; the destination BTC address is often declared as memo/recipient (THORChain, Chainflip); (b) if the bridge pays from a known BTC hot wallet, monitor its outgoing txns from the source timestamp onward; (c) match by value (amount minus fee, within tolerance) AND time window (minutes to hours); (d) a declared destination address makes the match near-certain, otherwise the hot wallet paying the matching value in-window is the target.
3. BTC -> EVM (unstructured source; correlate in reverse), Bitcoin emits no indexable events, so run destination-to-source: (a) identify the bridge’s EVM contract, which emits a mint/release event per confirmed BTC deposit; (b) note recipient EVM address, amount, destination timestamp; (c) compute expected source deposit = destination_amount + bridge_fee (and any wrapping ratio); (d) on the BTC side, examine the bridge’s receiving address(es) for incoming txns in a window before the destination event (10 minutes to several hours); (e) filter candidate deposits by amount tolerance, in low-activity bridges decisive, in busy bridges narrow by tight-tolerance amount, unique trailing digits after fees, known-cluster counterparties, and processing order (some bridges are strictly FIFO).
4. Mint-style bridges (e.g. RenBTC), do not release from a pool, they mint fresh tokens; time+value against the bridge entity fails. Pivot to counterparty-graph analysis on the mint outputs (see the dedicated tactic).

When to use

Whenever a trace crosses a bridge that lacks a usable first-party explorer, e.g. Across, Stargate (lower-level), Synapse, Hop, cBridge/Celer, Allbridge, Multichain (defunct), Chainflip, THORChain, Wormhole raw, RenBridge (defunct), swftSwap-style. Even seized bridges leave persistent, traceable on-chain artifacts.

Example

A wallet sends 50,000 USDC on Ethereum to an explorer-less bridge: decode the source-side bridge event for destination chain ID, recipient, and amount/nonce, then query the bridge contract on Arbitrum for the matching FilledRelay / TokenSwapReceived event, confirming where it arrived.

Related

Cross-Chain Correlation Edge Cases & Failure Modes, Mint-Style Bridges: Pivot to Counterparty-Graph Analysis, EVM Event Logs & Decoding Calldata, Bitcoin UTXO Clustering Heuristics