Bridges, layer 2s, sidechains and other chain designs

Trails rarely stay on Bitcoin or Ethereum mainnet. Stolen funds are bridged to rollups and sidechains, moved as stablecoins on Tron, routed through Solana programs or carried between Cosmos chains. Each crossing is where a trail becomes strong or falls apart. A well-documented crossing leaves an identifier on both ledgers that ties deposit to payout as firmly as a spent output ties two Bitcoin transactions; a poorly documented one leaves an amount-and-time guess. The examiner must find that identifier, prove the match on both chains, explain every difference in amount, know where each chain keeps its data and who could rewrite it, and know which operator holds what the chains do not show. Lesson 5.3 covers chain-hopping patterns and amount-and-time matching; this lesson covers the mechanisms and the evidence each leaves.

Bridge designs and their link keys

Between the sides sits a verification layer: a validator set, a light client, an optimistic challenge window or a zero-knowledge proof. Bridges to sidechains are usually signed by a small validator set, so a "deterministic" link there holds only within the trust placed in those validators; the report should say so.

Most bridges run on a messaging layer. Wormhole identifies each message by emitter chain, emitter address and sequence; LayerZero gives each packet a source endpoint, sender and nonce plus a 32-byte global identifier (GUID). Applications inherit these identifiers, so first work out which layer a bridge uses. Circle's Cross-Chain Transfer Protocol (CCTP) for USDC is burn-and-mint: the source emits DepositForBurn (amount, depositor, mint recipient, destination domain), the destination MessageReceived (source domain, nonce). In the current version the issuer assigns nonces off chain and its attestation service returns them for a source transaction hash. Part of the key therefore comes from the operator: treat that API response as an exhibit, with request, retrieval time and a hash of the response.

Bridges also number chains their own way: Wormhole has its own 16-bit chain IDs, LayerZero endpoint IDs, and CCTP domains (Ethereum 0, Arbitrum 3, Solana 5, Base 6), while Arbitrum One's EIP-155 chain ID is 42161. Reading destinationDomain = 3 as "chain 3" sends you to the wrong network. Record each mapping and its source, the bridge documentation at a dated version.

Matching a deposit to its release

A defensible match passes seven checks:

1. Decode the source event from the receipt, not an explorer summary: contracts, amount, depositor, recipient, destination identifier, link key.
2. Map the destination identifier to a network and record the mapping.
3. Find the destination event with the same key (and, on messaging layers, the same emitter or sender).
4. Check the recipient against the one written in the source event; explain any difference before going further.
5. Reconcile the amount: destination equals source minus the stated fee, with decimals checked on both sides, since wrapped tokens do not always keep the original's decimals.
6. Check order and status: release after deposit; a deposit with no release may be pending, expired or refunded.
7. Re-perform the match from a second data source and record both.

Passing all seven gives a grade A flow link on the scale of Lesson 3.2; failing the recipient or amount check means no match until explained. In a warehouse the match is a LEFT JOIN of deposits to fills on origin chain ID and deposit ID, not a search by amount: it keeps unfilled deposits for the refund check, computes the implied fee and names the relayer so nobody mistakes it for the subject. Relayer fills can arrive seconds after the deposit, before the source chain is final; if the source block were reorganized away, the relayer would usually carry the loss, but your evidence would cite a transaction that no longer exists. Record the source block hash and its finality status (Lesson 8.2).

Traps that weaken a link:

• Relayers, executors and finalizers are not owners. A naive trace through a liquidity bridge jumps into an unrelated party's funds.
• Recipient is not depositor. The source event's recipient field is the evidence.
• Aggregators may appear as depositor; read the trace to find who called them.
• Same address, different owner. An externally owned account (EOA) has the same address on every EVM chain, but a contract address may hold different code, or none, elsewhere. In June 2022 about 20 million OP tokens went to an Optimism address where the intended multisig existed only on Ethereum; an attacker deployed a different multisig there and took them.
• Tokens by contract, not ticker: several bridged versions of one asset can coexist.

Reconciling escrow and supply

A lock-and-mint bridge's invariant: wrapped supply on the destination never exceeds collateral in escrow on the source, apart from deposits in transit. Compare the escrow's balanceOf with the wrapped token's totalSupply() at matched times, or keep daily running totals of net locked and net minted units. A small positive gap is normal; a negative gap means unbacked tokens. Exploits invert the trace: funds appear with no legitimate deposit, so start from the mint or release (root causes are in Lesson 5.5).

Ronin's six days argue for continuous monitoring. Lending protocols need the same check (supply tokens against underlying held plus debt), and their events separate who acted from whose position changed: a router appears as user, the owner as onBehalfOf. Interest-bearing balances such as aTokens grow without Transfer events, so read them from state. Flash-loan principal enters and leaves in one transaction and must be netted out of any loss (Lesson 5.5).

Operators as sources. The chain shows the transfer; operators may show the person. A bridge operator or front end may hold API and web logs (IP addresses, user agents, connected wallets), relayer fills, attestations, support tickets and screening logs; issuers behind burn-and-mint bridges can also freeze (Lesson 10.1). A fully decentralized bridge may have no operator, so ask the front end the subject used. Name the chain, deposit hash, depositor, recipient, UTC window and fields, and ask for preservation first (Lesson 1.4).

Rollups and sidechains

A rollup's history can in principle be rebuilt from L1; a sidechain's is only as reliable as its validators. For a sidechain, record consensus and finality rules, the validator set if published, and whether you used its only explorer or your own node.

Sequencers and layered finality. Most rollups have one sequencer that orders transactions, sets L2 timestamps within protocol limits and posts batches to L1. OP Stack nodes expose unsafe (sequencer only, reorganizable), safe (derived from L1 data) and finalized heads; build evidence from safe or finalized blocks and record the anchoring L1 transaction. Since the Dencun upgrade (March 13, 2024) most rollups post blobs, which L1 nodes prune after 4,096 epochs, about 18 days, leaving a versioned hash. To show L2 history can be rebuilt independently, preserve blob data within that window or name the archive used. Sequencer operators and public RPC providers may log submission metadata and can receive precise requests.

Deposits. On OP Stack chains the L1 OptimismPortal emits TransactionDeposited and the L2 creates an unsigned deposit transaction of type 0x7E (126 as an integer) whose sourceHash, computed from the L1 block hash and log index, is an exact join key; its mint field is ETH created on L2, mirrored by ETH locked on L1. With no signature, authority and attribution come from the L1 sender. On Arbitrum a retryable ticket that fails automatic redemption waits up to a week, so the L2 effect can lag by days. Both families alias L1 contracts by adding 0x1111000000000000000000000000000000001111: L1 contract 0x5d3a…7c10 arrives on L2 as 0x6e4b…8d21. EOAs are not aliased; search for the alias.

Withdrawals. An OP Stack canonical withdrawal takes three steps linked by a withdrawal hash: initiate on L2 (MessagePassed), prove on L1 (WithdrawalProven), finalize after the challenge window (WithdrawalFinalized). Arbitrum has no prove step (sendTxToL1, then Outbox execution about a week later). Once initiation is visible, the L1 recipient and earliest arrival are known days ahead, so an exchange can be alerted before funds land (Lesson 10.1). Provers and finalizers are often relayers, and windows differ by chain and change, so record the parameter in force. Offenders therefore usually exit through liquidity bridges.

Key every table by chain ID and address: Ethereum 1, OP Mainnet 10, BNB Smart Chain 56, Polygon PoS 137, zkSync Era 324, Base 8453, Arbitrum One 42161, Linea 59144, Scroll 534352.

Other chain designs

Tron is EVM-compatible (TRC-20 emits ERC-20's Transfer event), carries a large share of USDT and produces blocks about every three seconds. T… addresses encode a 0x41 byte plus a 20-byte body; convert to hex to join EVM data, keeping the chain identifier in every row. Fees use bandwidth and energy, which can be delegated or rented, so the paying account may be a rental service. A new address usually activates on first receiving TRX, and the activator is a lead. The USDT issuer can freeze an address (AddedBlackList) and burn its balance (DestroyedBlackFunds); check both before calling funds available.

Solana keeps everything in accounts (1 SOL = 1,000,000,000 lamports). Programs hold no state; a mint account defines a token and balances sit in token accounts, normally the associated token account derived from owner, token program and mint. Tokens move between token accounts, so map each to its owner as of the transfer. Record the first signature (the transaction ID), the slot and the estimated blockTime. Diffing preTokenBalances and postTokenBalances beats decoding inner instructions: an account falling from 900,000,000 to 650,000,000 base units at 6 decimals sent 250 tokens. Many nodes keep only recent history; name the archival source.

Cardano extends UTXO (eUTXO): outputs carry ADA and native tokens; script outputs hold a datum and are spent with a redeemer. Payment addresses sharing one delegation credential are in most cases one wallet, a strong clustering signal but not proof.

Cosmos chains use prefixed Bech32 addresses (cosmos1…, osmo1…), and one key often yields matching addresses across chains. IBC escrows on the source and mints a voucher denominated ibc/ plus a SHA-256 hash of path and base denomination; the packet's port, channel and sequence appear in send_packet and in recv_packet and acknowledge_packet, an exact join key. One asset arriving by two paths has two different denominations.

Monero and shielded Zcash hide parties and amounts; analysis centers on entry and exit points (Lesson 6.4).

Unsupported chains. When your tools cannot decode a chain: read its documentation at a dated version; take data from two sources, saving and hashing raw responses (Lesson 8.3); validate on known ground, such as a deposit whose exchange records you hold; report only validated fields; lean on the bridges and exchanges at the edges; and state every limitation (Lesson 3.6).

Exam focus: the four bridge designs and what each leaves on both chains; Wormhole, LayerZero and CCTP identifiers, issuer-assigned CCTP nonces and mapping bridge identifiers such as CCTP domains to networks; the seven-step match; relayers, aggregators and finalizers as non-owners; the invariant that wrapped supply never exceeds escrow, and how Wormhole, Ronin and Nomad appear in it; acting address versus onBehalfOf; optimistic and ZK rollups versus sidechains; unsafe, safe and finalized heads and blob pruning after about 18 days; sourceHash, retryable tickets and aliasing; the three-step withdrawal as warning time; keying by chain ID plus address; Tron resources, activation and USDT freezes; Solana token accounts and balance diffs; Cardano delegation credentials; IBC packet keys.