Bridges are, year after year, the most drained component in the entire ecosystem. The post-mortems get read as a run of bad luck, one team after another shipping a subtle bug. They are not bad luck. They are the predictable result of a naming problem: the word bridge describes what the user sees, and completely hides the only question that decides whether the thing is safe.
That question is: who is allowed to say that something happened on the other chain?
Nothing crosses anything
Start with the mechanics, because the mental model people carry is wrong in a way that matters. No asset moves between chains. It cannot. A token is a row in a contract’s storage on one chain, and that chain has no ability to read or write the state of another.
What actually happens is a pair of independent, local operations that a protocol asserts are related:
- On the source chain, value is locked in a contract, or burned outright, and an event is emitted.
- On the destination chain, a contract mints a representation, or releases from its own reserve, because something convinced it that step one occurred.
Every bridge in existence is a different answer to “because something convinced it.” The lock and the mint are the easy part. The convincing is the entire security model, and it is where the money goes.
Three answers, three failure modes
There are only three structurally different ways to convince chain B that something happened on chain A, and each one buys safety with a different currency.
| Model | What B trusts | Cost | Latency | How it actually fails |
|---|---|---|---|---|
| External verifier set | A quorum of named signers | Cheap gas | Minutes | Key compromise or collusion. The threshold is the ceiling. |
| On-chain light client | A’s consensus rules, verified in a contract | Expensive gas | Finality of A | Bugs in the verification code, or a consensus fork on A |
| Optimistic with fraud proofs | That at least one honest watcher exists and is awake | Cheap gas | Hours, by design | Nobody is watching, or the challenger cannot get a transaction included |
Read the right-hand column again. Those are not three flavours of the same risk. They are three completely different questions to audit, and a review that is good at one is often blind to the others.
The verifier set is the wallet
Most production bridges use the first model, because it is the only one that is cheap and fast at the same time. Strip the marketing away and the destination contract does something with this shape:
function releaseTo(Message calldata m, bytes[] calldata sigs) external {
require(!processed[m.id], "replayed");
require(countValidSigners(hash(m), sigs) >= threshold, "quorum");
processed[m.id] = true;
token.transfer(m.recipient, m.amount);
}Look at what this contract knows. It does not know that anything was locked on the source chain. It does not know the source chain exists. It knows that threshold keys signed a message saying so, and it pays out on that basis.
So the security of the bridge is exactly the security of those keys, and no better. A bridge holding nine figures behind a five-of-nine set is a five-of-nine multisig with a very good landing page. That is a defensible design, and plenty of serious systems are built that way. It stops being defensible the moment the documentation calls it trustless, because then the people relying on it are pricing a risk they were told they did not have.
If you cannot name the parties whose compromise drains the bridge, you have not finished reading the documentation.
Where the bugs actually live
Almost none of the large losses came from breaking a signature scheme. They came from the boring seam between “the proof is valid” and “the proof is about the thing you think it is about.” Four recurring shapes:
Domain separation that was never done
A message signed for one destination gets accepted by another, because the signed payload never committed to a chain identifier, a contract address, or a protocol version. The signature verifies perfectly. It was simply an answer to a different question. Whatever goes into the hash must pin down every dimension the message is scoped to, and “every” includes the ones that only have one value today.
Verifying the wrapper instead of the contents
A contract checks that a proof structure is well formed and that a header is signed, then reads the payload without confirming that the payload is the one the proof commits to. This is the single most productive bug class in the space. It is also the hardest to see in review, because the verification code is present, dense, and correct as far as it goes.
Token identity taken on faith
The destination decides which local token to release by reading a field the message supplied, rather than by consulting a registry the protocol controls. Anyone who can get any message accepted can then choose which asset comes out. The proof was about a deposit of something worthless; the release was of something valuable.
The upgrade key nobody counted
The verifier set is five of nine, and a single proxy admin key can replace the verification logic entirely. The real threshold is one. Any honest description of a bridge’s trust model has to include the keys that can change the trust model, and in practice those are held more loosely than the signing keys, because they feel like operations rather than custody.
Optimistic designs move the assumption, they do not remove it
Fraud proofs are a real improvement: instead of trusting a quorum to be honest, you need only one participant to be honest and paying attention. But notice what that sentence smuggles in. “Paying attention” is a liveness assumption about a human process, and liveness assumptions decay quietly.
Concretely, an optimistic bridge is only as safe as the answers to these:
- Who runs a watcher today, and what happens to them financially if they stop?
- Is watching profitable, or is it a cost someone absorbs out of goodwill until they do not?
- Can a challenge transaction reliably get included during the exact congestion that an attacker would choose to create?
- Is the challenge window long enough to survive a holiday weekend, and short enough that anyone will use the bridge?
That last one is a genuine tension, not an oversight. Every hour added to the window buys safety and costs adoption, and the team is choosing a point on that line whether or not they say so.
Light clients are the honest answer and the expensive one
Verifying the source chain’s consensus inside a destination contract is the only model where the trust assumption is “chain A works as specified” rather than “these people behave.” It is also the model that runs into economics immediately, because signature verification and header tracking cost gas on every message, forever.
Which is why so much engineering effort in this area is really cost engineering: succinct proofs, committee-based sampling, batching many messages behind one verification. Those are all ways to pay less for the same assurance, and each one adds code to the part of the system where a bug is unrecoverable. The trade is real work, not a shortcut, and it deserves to be read as such.
What to ask, in order
If you have to evaluate a bridge, whether as an integrator or as someone deciding what to hold, these questions get you to the actual risk faster than any amount of reading about throughput:
- Which of the three models is this, without the marketing vocabulary?
- Name every key that can move funds or change the code, and say who holds it and where.
- What exactly does the signed or proven payload commit to? Chain id, contract, version, nonce, recipient, amount, token?
- Where does the destination learn which local asset to release, and can a message influence that?
- If this is optimistic: who is watching right now, and what pays them?
- What is the largest amount that can be released between two human reviews?
- What did the audit explicitly declare out of scope? That sentence is usually more informative than the findings.
None of this argues that bridges are unsound. It argues that “bridge” is a category of user experience, not a category of security, and that treating the two as the same thing is what keeps producing the same headline. A system that plainly says “seven named organisations hold keys, four of them can release your funds” is more trustworthy than one that says nothing and lets the word trustless do the work.
State on a public chain is permanent, and a mistake in this layer is not a bug you patch and move past. That is reason to be exact about the trust model, not reason to avoid the subject.