Problem Statement: Trust-Minimized Value Transfer Between Sovereign Chains
Frames the bridge as a distributed verification problem, not a token swap UI.
Problem statement
Design a cross-chain bridge that moves assets and messages from a source chain (for example Ethereum) to a destination chain (for example Polygon, Arbitrum, or an app-chain) by locking the asset on the source and minting a wrapped representation on the destination, with the reverse path burning the wrapper and unlocking the original. The hard part is not the accounting. The hard part is verification: how does the destination chain, which has no access to the source chain's state, become convinced that a deposit really happened and really finalized?
Chains are sovereign state machines. Ethereum finalizes through PoS epochs, rollups inherit L1 data availability, Polygon PoS checkpoints into Ethereum roughly every 30 minutes, and each chain has different block times, reorg behavior, and proof formats. A bridge therefore needs three cooperating layers: on-chain contracts that escrow and mint, a verification layer that proves source-chain events to the destination, and a delivery layer that submits proven messages and pays destination gas.
Why bridges fail
Public history makes the stakes explicit. Ronin Bridge lost roughly $625M in March 2022 when an attacker compromised 5 of its 9 validator keys. Wormhole lost about $320M in February 2022 through an unprotected contract upgrade path on Solana that bypassed signature verification. Nomad lost about $190M in August 2022 when an uninitialized proxy accepted a zero bytes32 value as a valid message root. Poly Network suffered a $611M exploit in August 2021. BNB Chain's bridge had roughly $570M in unauthorized BNB minted via forged IAVL proofs in October 2022. Every one of these was a verification-layer failure, not a UI bug.
The design must therefore treat the supply invariant - wrapped supply on destination never exceeds locked supply on source - as the system's core safety property, and every architectural choice must be evaluated against it.
Four architectural planes
- On-chain protocol plane: locker, minter, burner, nonce registry, and rate limits deployed per chain.
- Verification plane: observers, verifiers or light clients, attestation aggregation, finality tracking.
- Delivery plane: relayers and executors that pay gas, retry, and confirm execution.
- Governance and observability plane: monitoring of the supply invariant, circuit breakers, timelocks, incident response.
A strong answer keeps these planes separate so that a delivery outage delays messages while a verification compromise is contained by quorum, rate limits, and invariant monitoring.
Key Highlights
- •The core invariant is wrapped supply on destination never exceeds locked supply on source.
- •Ronin ($625M), Wormhole ($320M), Nomad ($190M), and BNB Bridge ($570M) were all verification-layer failures.
- •Verification is the hard problem: destination chains cannot natively read source-chain state.
- •Four planes: on-chain protocol, verification, delivery, and governance/observability.
- •Delivery failures cost latency; verification failures cost the entire treasury.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "I will separate message delivery, which may fail and retry, from mint authorization, which must never be forged."
- "Before choosing any technology, let me define who is allowed to convince the destination chain that a deposit finalized."