Cross-Chain Bridges: What 'Trust Minimized' Actually Means
February 2nd, 2022. Wormhole loses $320 million in about six minutes because a signature verification bug let an attacker mint 120,000 wETH on Solana out of thin air, no deposit on Ethereum required.
I was at DecenLabs at the time, mid-way through architecting a cross-chain integration that used a bridge. Not Wormhole, but one with similar trust assumptions. We spent the next couple of days going through our implementation line by line.
Six weeks later, Ronin loses $625M. Sky Mavis's validator keys got compromised and one attacker controlled nine of them.
Two massive hacks six weeks apart, both filed under "bridge exploit". But they failed in completely different ways, and understanding why is the most useful thing you can know before picking a bridge for production.
The three architectures and their real trust models#
Bridge marketing calls everything "trust minimized" or "decentralized". Meaningless without context. The actual question: what do I have to trust for this bridge's messages to be valid?
Light client bridges#
A light client bridge runs a cryptographic proof of one chain's consensus inside a contract on another chain. Moving an asset A → B means the contract on B verifies a proof that your deposit was finalized in A's state.
No external validators, no multisig. The verification is the chain's consensus itself, expressed as a checkable proof.
Gold standard. Also expensive and slow. Verifying Ethereum consensus inside a Solana program costs serious computation. In 2022 it was technically possible but practically prohibitive at high frequency. zkBridges have made it more feasible since. Still not cheap.
Trust assumption: that chain A's consensus is correct. Same trust you already extend to the chain itself. Actually trust-minimized.
MPC / multisig bridges#
Most bridges that existed in 2021-2022. A validator set watches both chains. Deposit on A, they collectively sign a message authorizing the mint on B. Enough signatures, the mint goes through.
Ronin was this. Sky Mavis ran 5 of 9 validators themselves. The attacker compromised 4 external validators plus found a path to Sky Mavis's 5. Nine of nine. Game over.
Trust assumption: more than the threshold of validators stays honest, uncompromised, and online. That's trusting humans and key management, not cryptography.
The honest translation of "trust minimized" for MPC bridges is "less trusted than one company, more trusted than the cryptographic ideal". The questions that matter: how many validators, who runs them, how are keys stored, what happens when X get compromised at once.
Optimistic bridges#
Optimistic bridges (Connext at the time, plus the base design behind some L1→L2 bridges) assume messages are valid by default and rely on a challenge window where anyone can submit fraud proofs. No challenge in the window, message is valid.
Trust assumption: at least one honest, well-resourced watcher is monitoring and will challenge fraud inside the window. Plus the dispute mechanism itself being correct.
Reasonable for most cases. For high-stakes automated protocol use, the 7-day window is the problem. Your protocol can't wait a week to learn if its cross-chain state was valid.
How Wormhole actually failed#
Wormhole is a message-passing protocol, not just an asset bridge. Validators ("guardians") watch Solana for deposits and sign a VAA (Verifiable Action Approval) authorizing the mint on the target chain.
The bug was on the Solana side, in how the program validated the sysvar_instructions account used inside the signature verification logic.
The attacker crafted account arguments that bypassed the check that a valid guardian multisig had approved the VAA. The program saw a signature, didn't verify it was the right signature from the right guardians, and minted.
120,000 wETH. No deposit. Wormhole's infrastructure was working perfectly, guardians online, messages passing. The failure was in the contract code, not the validator set.
Different failure from Ronin. Wormhole: correct architecture, buggy implementation. Ronin: sound implementation, compromised validator set.
Both matter when you're evaluating a bridge. A formally verified light client bridge with a single operator is more dangerous than a well-audited MPC bridge with 100 independent validators. Architecture quality and implementation quality are separate questions.
What we changed at DecenLabs#
Going back through our integration after Wormhole, the main question was: what's our trust model, and is it written down anywhere?
We were using an MPC bridge. Our assumption: if the validator threshold gets compromised, user assets are at risk. We'd never written that down. We'd chosen implicitly because the bridge was popular and had a decent audit.
So we added a circuit breaker: if bridge state diverged from expectations (mint volume spiking, unusual validator set changes), our contract paused. Didn't fix the underlying trust assumption. It limited the blast radius.
The deeper change was in how we evaluated bridge integrations after that:
- What's the trust model? Light client, MPC, optimistic. Who are the trusted parties, exactly?
- Who runs the validators/watchers? How many, are they independent, how are keys stored?
- Audit history? Not "was it audited" but which firm, what scope, what was found, was it fixed.
- Circuit breakers? Can it pause, who pauses it, what triggers a pause?
- What's the worst case? Compromised at the weakest point, what can an attacker do and what's the maximum damage?
Most bridges can't answer all five clearly. That is the answer.
What "trust minimized" should mean#
The phrase covers everything from "we have a 5-of-9 multisig" to "ZK proof of consensus". Not the same thing.
If someone says trust minimized, the follow-ups are:
- Minimized compared to what?
- Which trust assumptions remain?
- What's the attack cost on those assumptions?
A bridge with 100 independent validators is more trust-minimized than one with 9, and less than one with zero. It's a spectrum, not a binary.
The practical version: match your trust tolerance to your value at risk. Small fast frequent cross-chain messages, a well-tracked MPC bridge is probably fine. A bridge holding hundreds of millions, you want light client verification even at 10x per-transaction cost.
Obvious in hindsight. Less obvious in early 2022 when "popular and audited" felt like enough due diligence.
The $945M combined loss across those two months made it very obvious.