cross-chain-bridge-audit

cross-chain-bridge-audit

Checklist for auditing a cross-chain bridge / interoperability L1 (observe→attest→execute). Apply on ANY bridge, cross-chain executor, or message-passing protocol. These are the classes that pay; run every one against the code before declaring a surface clean.

The trust/value pipeline — map it first

Diagram: who observes a source event, who attests (which quorum/signature), what a node trusts, where value moves (mint inbound / release outbound), and what authorizes the outbound (TSS / multisig / light client). Name the attacker: outside the validator/attestor set, or at most one member. Everything below hangs off this map.

Inbound (mint) — the "forge an attestation" class

• Event authenticity: are source logs filtered to the exact {gateway, vault} address AND the exact event signature? An attacker emitting a matching-signature event from an arbitrary contract must be rejected.
• Full-tuple binding: does the attestation/ballot key digest EVERY execution-relevant field (amount, recipient, asset, source-tx-hash, log-index, chain-id, payload)? A minority attestor must not be able to substitute one field.
• Replay/dedup: is (source_chain, tx_hash, log_index) (or equivalent) checked before execution, exactly once?
• Quorum soundness: eligible-voter set, (2N)/3+1 math, repeat-vote rejection.
• Decimals/scaling: source↔local decimal conversion — an off-by-10^n inflates a mint.

Outbound (release) — the "sign an unauthorized payment" + "double-spend" classes

• Signed-payload binding: trace the EXACT bytes handed to the signer (TSS/multisig). Does every signer independently rebuild the message from consensused state and refuse to sign unless it byte-matches? A coordinator supplying the payload (not just a nonce) = forge.
• Finality on the outbound decision — THE trap: any code that decides "this outbound failed/succeeded" must read a finalized chain view, not latest/pending. Verify the SEMANTIC, not the helper name — a function called GetFinalizedNonce/getConfirmed that internally passes nil/latest/0 to the RPC reads latest and is reorg-exposed. Grep every NonceAt, BlockByNumber, getBalance, getReceipt for a nil/latest block arg on a security decision.
• Asymmetric finality gates: if the "success" path waits N confirmations but the "not-found/failure/refund" path does NOT, a premature refund + later success = double-payment. Both paths need the same finality gate.
• Replay of the release: a universal replay guard (executed-marker / subTxId / nonce) on EVERY outbound method (transfer, finalize, revert, rescue) — not just some. Check the destination-side dedup too.
• Refund reversibility: once a refund/revert is finalized, can a later "it actually succeeded" observation reverse it? If not, and both can fire, that's the loss.