Cross-Chain Bridges: What 'Trust Minimized' Actually Means
ShareCross-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 out of thin air on Solana without depositing anything on Ethereum.
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 48 hours going through our implementation line by line.
Six weeks later, Ronin Network loses $625M. Sky Mavis's validator keys were compromised and nine of them were controlled by one attacker.
Two massive hacks, six weeks apart, both described as "bridge exploits." But they failed in completely different ways. And understanding why they failed differently is the most useful thing you can know before choosing a bridge for production use.
The Three Bridge Architectures (And Their Real Trust Models)
The marketing material for most bridges describes them as "trust minimized" or "decentralized." These terms are nearly meaningless without context. What you need to ask is: what do I have to trust to believe this bridge's messages are valid?
Light Client Bridges
A light client bridge works by running a cryptographic proof of one chain's consensus inside a smart contract on another chain. When you want to move an asset from chain A to chain B, the bridge contract on chain B verifies a cryptographic proof that your deposit transaction was included in chain A's finalized state.
No external validators. No multisig. The verification is the chain's consensus itself, expressed as a proof the contract can check.
This is the gold standard. It's also expensive and slow. Verifying an Ethereum consensus proof inside a Solana program (or vice versa) requires significant computation. In 2022, this was technically possible but practically prohibitive for high-frequency use. zkBridges have made this more feasible but it's still not cheap.
Trust assumption: You trust that chain A's consensus is correct. That's it. This is the same trust you extend to the chain itself. Genuinely trust-minimized.
MPC / Multisig Bridges
This is most of the bridges that actually existed in 2021-2022. A set of validators watch both chains. When they see a deposit on chain A, they collectively sign a message authorizing the mint on chain B. If enough of them sign, the mint goes through.
Ronin was this architecture. Sky Mavis ran 5 of the 9 validators themselves. An attacker compromised 4 external validators plus found an exploit that gave them control of Sky Mavis's 5. Nine of nine. Game over.
Trust assumption: You trust that more than the threshold of validators are honest, uncompromised, and online. This is a real trust assumption — you're trusting humans and key management, not cryptography.
The honest version of "trust minimized" for MPC bridges is: "less trusted than a single company, more trusted than the cryptographic ideal." The honest question to ask is: how many validators, who runs them, how are the keys stored, and what happens if X of them are simultaneously compromised?
Optimistic Bridges
Optimistic bridges (Connext circa 2022, the base design behind some L1-L2 bridges) assume messages are valid by default and rely on a challenge period during which anyone can submit fraud proofs. If no one challenges a message within the window, it's considered valid.
Trust assumption: You trust that at least one honest, well-resourced watcher is monitoring the bridge and will catch and challenge fraudulent messages within the window. Also that the dispute mechanism itself is correct.
For most use cases, this is a reasonable assumption. For high-stakes automated protocol use, the 7-day challenge window is a problem — your protocol can't wait a week to know if its cross-chain state is valid.
How Wormhole Actually Failed
Wormhole is a message-passing protocol, not just an asset bridge. The core design: validators ("guardians") watch Solana and observe deposit transactions. When they see a deposit, they sign a VAA (Verifiable Action Approval) that authorizes the corresponding mint on the target chain.
The signature verification bug was in the Solana side of the bridge. Specifically, it was in how the program validated the sysvar_instructions account — a Solana-specific construct that was being used as part of the signature verification logic.
An attacker found that by crafting specific account arguments, they could bypass the check that a valid guardian multisig had approved the VAA. The program would see a signature, not verify that it was the right signature from the right guardians, and proceed to mint.
120,000 wETH minted. No deposit. Wormhole's infrastructure was working correctly — guardians were online, messages were passing. The failure was in the contract code, not the validator set.
This is a different failure than Ronin. Wormhole: correct architecture, buggy implementation. Ronin: sound implementation, compromised validator set.
When you're evaluating a bridge, you need to evaluate both. A formally verified light client bridge with a single operator is more dangerous than a well-audited MPC bridge with 100 independent validators. Architecture and implementation quality are separate questions.
The Decision We Made at DecenLabs
When I went back through our integration after the Wormhole hack, the main thing I was checking was: what's our trust model, and have we made it explicit in the code?
We were using an MPC bridge. Our trust assumption was: if the validator threshold is compromised, our users' assets are at risk. We hadn't written that down anywhere. We'd made the choice implicitly because the bridge was popular and had a decent audit.
After the hacks, we added a circuit breaker to our integration: if the bridge's state diverged from what we expected — mint volume too high, unusual validator set changes — the contract would pause. It wasn't a solution to the underlying trust assumption. But it limited our blast radius.
The deeper change was in how we evaluated future bridge integrations. The checklist became:
- What is the trust model? Light client, MPC, optimistic. Who exactly are the trusted parties?
- Who runs the validators / watchers? How many, are they independent, how are keys stored?
- What's the audit history? Not just "was it audited" but which firm, which scope, what was found, was it fixed.
- What are the circuit breakers? Can the bridge be paused? Who can pause it? What triggers a pause?
- What's the worst case? If the bridge is compromised at its weakest point, what exactly can an attacker do, and what's the maximum damage?
Most bridges can't answer all five questions clearly. That's the answer.
What "Trust Minimized" Should Actually Mean
The phrase gets used to mean everything from "we have a 5-of-9 multisig" to "we use a ZK proof of consensus." These are not the same thing.
If someone says their bridge is trust minimized, the follow-up questions are:
- Minimized compared to what baseline?
- What specific trust assumptions remain?
- What's the attack cost to exploit those assumptions?
A bridge with 100 independent validators is more trust-minimized than one with 9, but less than one with zero (light client). "Trust minimized" is a spectrum, not a binary property.
The practical implication for protocol engineers: match your trust tolerance to your value at risk. For small, fast, frequent cross-chain messages, an MPC bridge with a good track record is probably fine. For a bridge that will hold hundreds of millions of dollars in locked assets, you want light client verification even if it costs 10x more per transaction.
This is obvious in hindsight. It was less obvious in early 2022 when "this bridge is popular and audited" felt like sufficient due diligence.
The $945M combined loss from those two months made it very obvious.