Bridge Exploits¶

A bridge acts on one chain because it accepts evidence about another. An exploit succeeds when an attacker forges that evidence, controls enough authorized attesters, replays a valid message, bypasses accounting, or replaces the code that verifies the message.

The verification boundary holds the assets¶

Lock-and-mint bridges hold an asset on a source chain and issue a representation on a destination chain. Burn-and-release performs the reverse path. The destination cannot natively inspect arbitrary source-chain consensus, so the bridge chooses a verifier: a multisignature committee, a light client, an optimistic claim with a challenge period, or the proof system of a rollup.

That verifier protects the entire pool, not one user at a time. If it accepts one fabricated deposit, the attacker can mint an unbacked asset and redeem or sell it. If it accepts a fabricated withdrawal, locked collateral leaves directly.

Compromised signers¶

A federated bridge is secure only while fewer than the threshold number of signing keys can be abused. The March 2022 Ronin incident showed how operational independence can collapse: the attacker obtained five of nine validator signatures, including access connected to an earlier operational exception. The cryptographic threshold worked as configured. The organization failed to keep enough signers independent.

Signer count alone is a poor measure. Check who operates each signer, where keys are stored, whether machines share deployment systems or cloud accounts, how membership changes, and whether rate limits or delayed withdrawals constrain a threshold compromise.

Verification bugs¶

A bridge can have honest signers and faulty verification. The February 2022 Wormhole incident involved a forged message accepted on Solana, which allowed unbacked wrapped Ether to be minted. This class includes skipped signature checks, inconsistent serialization, incorrect validator-set updates, proof-verification errors, and assumptions that differ between implementations on two chains.

Cross-chain messages need domain separation. Include source chain, destination chain, source sender, destination contract, nonce, payload, and version in the authenticated message. Record consumed messages so a valid proof cannot execute twice. Decide how finality is established on the source chain before acting on the destination.

Upgrade and accounting risk¶

Upgradeable bridge contracts add an administrative route around the verifier. A compromised upgrade authority can install code that releases assets or accepts arbitrary messages. Pausing may contain damage but also concentrates the ability to freeze transfers.

Accounting must reconcile locked, minted, burned, pending, and released amounts across failure and retry paths. Partial execution is especially dangerous when one side records success and the other retries. Idempotent message handling prevents duplicate release without preventing a failed delivery from being retried safely.

Defense in layers¶

Use independent signers, hardware-backed keys, explicit signer rotation, narrow upgrade authority, delays, withdrawal limits, anomaly monitoring, and tested pause procedures. Verify messages against a precise specification and test replay, wrong-chain, wrong-contract, old-validator-set, duplicate, malformed, and reorg cases.

No monitoring system repairs a verifier that already released assets. It can shorten detection time and cap loss only when the contracts include a control capable of stopping or limiting execution.