Cross chain security: bridge trust models and messaging

A chain cannot see another chain

A smart contract on chain B can read chain B’s state and nothing else. When a bridge releases funds on B because a deposit happened on A, the contract on B is acting on a claim about A. The whole security of the bridge is the security of that claim: who makes it, what it costs to make a false one, and what checks it before funds move.

Two properties make bridges among the most attacked contracts in crypto. They concentrate value, because a lock and mint bridge holds the entire backing of every wrapped token it has issued. And they sit between two security domains, so the weaker of the two chains, or the verification layer between them, sets the bar. A token bridged from a chain with billions in stake through a five person multisig is secured by the multisig.

Four ways to verify a message

The first model is the cheapest and most general, and it is where most losses have occurred. The third is what a rollup’s canonical bridge uses, since the L1 verifies the rollup’s proofs, and what IBC uses between Cosmos chains. Zero knowledge light clients aim to bring native verification to pairs of chains where running one chain’s light client on the other would be too expensive, at the cost of proving overhead and circuit risk.

What a light client actually checks

Native verification is concrete. An IBC light client for a Tendermint style chain stores a trusted validator set. For each new header a relayer submits, it checks that validators holding more than two thirds of the voting power signed it, or, when skipping ahead, that enough of the set it already trusts signed it to hand trust over to the new set. Trust expires: if no update arrives within the client’s trusting period, it can no longer verify anything until it is revived through governance. Evidence of misbehavior, two conflicting signed headers at the same height, freezes the client so that no further messages are accepted. The relayer carrying all of this is untrusted: it can delay a message but cannot forge one. What remains is trust in the source chain’s validators and in the light client code.

Lock and mint, burn and mint, liquidity networks

Separate from how a message is verified is what the message does to assets.

The invariant a lock and mint bridge must hold is simple: wrapped supply on all destinations never exceeds the amount locked. Every exploit below broke it by minting or releasing against a message that was never really sent. Liquidity networks change who bears that risk. The user is paid quickly by a relayer, and the relayer’s repayment is what the verification layer secures. Across, for example, verifies relayer repayment bundles optimistically through UMA’s oracle, with bonds and a dispute path. See intents and solvers for the fill side.

Messaging protocols by trust model

General messaging protocols carry arbitrary payloads, token transfers included. Described by who attests, as each project documents it in September 2026:

The trend is visible across the table: a sensible default plus the ability for an application to add independent verifiers. That is good design and also a transfer of responsibility. An application that ships with a default configuration has accepted the default’s trust model, whether or not anyone read it. The LayerZero DVN documentation and Wormhole’s Guardian documentation are good examples of stating these assumptions plainly.

The math of a k of n committee

A committee bridge is exactly as secure as the cheapest way to control k of its n signers. Nominal k is almost never the real number, because signers are not independent: keys run by the same company, hosted by the same cloud provider, approved through the same signing interface or reachable through the same employee collapse into one failure domain.

Ronin is the canonical example. Nine validators, five signatures to withdraw: a threshold that looked like five independent parties. Sky Mavis ran four validators and still held a permission, granted months earlier and never revoked, to sign for the fifth. Compromising one organization reached the threshold.

Economic security gives a second lens. A lock and mint bridge’s profit from corruption can be close to its entire locked value. If its verifiers are backed by slashable stake, the cost of corruption is the stake a quorum would lose. With illustrative numbers, a bridge holding $500 million, verified by a committee that needs two thirds of $300 million in stake to sign, costs $200 million to corrupt and pays up to $500 million: economically insecure regardless of how honest the operators are today. Restaked verification tries to raise the cost side; the restaking guide covers how that math works and where it breaks.

Four failures, four lessons

Ronin: the threshold was an illusion

The attackers reached Sky Mavis systems through a fake job offer, took the keys they needed, and withdrew in two transactions. Nobody noticed for six days, until a user could not withdraw. The FBI attributed the theft to North Korea’s Lazarus Group. Lessons: count failure domains, not signers; revoke temporary permissions; alert on large outflows. The Ronin case study tells it in full.

Wormhole: the verifier trusted its input

On Solana, Wormhole verified Guardian signatures by delegating to the secp256k1 program and then inspecting the instructions sysvar to confirm that verification had happened. The contract did not check that the account passed in as the sysvar was the real one. The attacker supplied an account crafted to look like a successful verification, obtained a valid looking signature set, and minted 120,000 wETH on Solana, bridging part of it back to Ethereum. Jump Crypto replaced the ETH within about a day. Lesson: in a signature verification path, every account and every input is attacker controlled until proven otherwise.

Nomad: the zero value was trusted

// Simplified sketch of the pattern in Nomad's Replica contract (2022).
mapping(bytes32 => uint256) public confirmAt;   // root => time it becomes acceptable
mapping(bytes32 => bytes32) public messages;    // message hash => root it was proven under

function acceptableRoot(bytes32 root) public view returns (bool) {
    uint256 t = confirmAt[root];
    if (t == 0) return false;                   // unknown root
    return block.timestamp >= t;                // optimistic window has passed
}

function process(bytes memory message) external {
    bytes32 h = keccak256(message);
    // A message that was never proven has messages[h] == bytes32(0).
    require(acceptableRoot(messages[h]), "!proven");
    // ... mark processed, then release funds to the recipient in the message
}

// The June 2022 upgrade initialized the zero root as confirmed.
// bytes32(0) became an acceptable root, so every unproven message passed.

Nomad was an optimistic bridge: roots became acceptable after a fraud window. A routine upgrade in June 2022 initialized the zero root as confirmed. A message that had never been proven maps to the zero root by default, so every unproven message passed. Once the first exploit transaction appeared, others copied it, replacing only the recipient address, and about $190 million left in roughly two and a half hours. Lesson: default values are inputs, and initialization is as security critical as any function.

Defense in depth

No verification model is perfect, so well run bridges assume one layer will fail and limit what a single failure can cost.

1. Require independent verifiers to agree

   Combine verification paths with AND, not OR: a committee and a proof, or two committees run by different organizations on different infrastructure. OR combinations make the weakest path the security.

2. Rate limit and delay

   Cap outflows per asset per time window and delay transfers above a threshold, as Wormhole’s Governor and CCIP’s token pool rate limits do. A drain becomes a leak that responders can stop.

3. Enforce the supply invariant on chain

   Track wrapped supply against locked collateral across chains and refuse any mint that breaks it, the job Wormhole’s Global Accountant performs.

4. Watch and be able to stop

   Monitor for anomalous flows and give a narrowly scoped role the power to pause, so the six day gap at Ronin becomes minutes.

5. Treat upgrades and keys as the attack surface

   Timelocked upgrades, reviewed initialization, and admin key hygiene with real signer independence. Several of the incidents above began with an upgrade or a key, not with the verification math.

What is still unsolved

• Finality mismatches. A bridge that attests before the source chain is final can be reorged out from under. Waiting for finality costs latency; not waiting costs safety. Fast bridges price that gap.
• The cost of native verification. Light clients for heterogeneous chains and the proofs for ZK light clients are improving but not free, so committees remain the default for many chain pairs.
• Configuration risk. Modular security moves decisions to application teams, and misconfigured or stale defaults become the new weak link.
• Economic security that holds under stress. Staked or restaked verifier sets only help while slashable value exceeds what an attack pays across every application they secure at the same time.

Common questions

Where to go next