More than $2.5 billion has been stolen from bridges. Ronin lost $625 million. Wormhole lost $325 million. Nomad lost $190 million in a few hours to a copy-paste exploit anyone could run. Poly Network lost $611 million. The pattern is not a coincidence. Bridges concentrate value behind a small amount of trusted code, and that makes them the single richest target in the entire space.
If your product needs to move value or messages between chains, you are building on top of the most consistently exploited component in crypto. You do not get to be casual about which bridge you trust, how you trust it, or whether you should be bridging at all.
This is a teardown of how bridges actually work, where they break, and what the exploit history teaches that the marketing pages omit.
What a bridge actually is
A bridge does one of two things. It moves tokens, or it moves messages. Everything else is a variation on those two.
Token bridging is almost always lock-and-mint or burn-and-mint. You lock an asset on chain A, and a representation gets minted on chain B. To go back, you burn on B and unlock on A. The locked assets sit in a contract on the origin chain. That contract is the honeypot. Every dollar that has ever crossed the bridge and not crossed back is sitting there, guarded by whatever validates the mint on the other side.
Message bridging is the more general primitive. Chain A emits an event. Some set of off-chain actors observes it, attests to it, and delivers it to a contract on chain B, which executes a call. Token bridging is just message bridging where the message is "mint 100 USDC to this address."
The security of the whole system reduces to one question: who decides that the event on chain A really happened, and what stops them from lying?
The trust models, ranked by how they fail
External validator sets. A fixed set of nodes runs a multisig or a threshold signature scheme. They watch chain A, sign attestations, and the destination contract mints when it sees enough signatures. This is the most common model and the most exploited one. Ronin was nine validators with a five-of-nine threshold. The attacker got five keys. That is the entire story. Wormhole was a guardian set, and a signature verification bug let the attacker forge the approval without any keys at all.
The failure mode is structural. You have moved the security of hundreds of millions of dollars to the operational security of a handful of servers. The chains underneath can be perfectly secure and it does not matter.
Optimistic verification. Messages are assumed valid and execute after a challenge window unless a watcher proves fraud. This is cheaper and removes the large validator set, but it introduces latency — typically 30 minutes — and it only works if someone is actually watching. Nomad's exploit was not even a trust-model failure in the pure sense. An upgrade marked a zero root as valid, which meant every message verified. The challenge mechanism was irrelevant because the contract accepted everything. The lesson is brutal: the cleverness of your trust model is worth nothing if the implementation has a hole.
Light clients and native verification. The destination chain runs a light client of the origin chain and verifies consensus proofs directly. No external trust. This is the cryptographically honest answer and the expensive one. It is hard to build, hard to maintain across consensus upgrades, and gas-heavy to verify on-chain. IBC in the Cosmos world does this. It is also why IBC has not produced a Ronin-scale headline — the verification is the chains themselves, not a committee.
Liquidity networks. No minting. Liquidity pools on both sides, and a relayer fronts you funds on the destination, settling later. This avoids the mint-authority honeypot entirely. The tradeoff is liquidity limits and relayer trust for the settlement leg. For payments and swaps under a threshold, this is often the right answer and nobody mentions it because it does not need a token.
What the exploit history actually teaches
Read the post-mortems as a group and three lessons repeat.
The first: the bug is rarely in the cryptography. It is in the glue. Signature verification that does not check the right field. An initializer that can be called twice. An admin upgrade that ships a zero-value as valid. The math held. The plumbing leaked.
The second: privileged keys are the soft underbelly. Most large bridge losses trace back to compromised signers or compromised upgrade authority, not broken consensus. If you run a validator-set bridge, you are running a key-management company that happens to bridge tokens. Treat it that way or do not run it.
The third: value concentration makes a slow bug catastrophic. A vulnerability in a payment contract leaks one transaction at a time. A vulnerability in a bridge lock contract leaks the entire pooled balance in one call. Nomad bled $190 million in hours because once the exploit was public, it was a free-for-all — people copied the attacker's transaction and changed the recipient address. The blast radius is the whole pool, every time.
How we evaluate a bridge before we touch it
We do not ask "is this bridge audited." Everything that got exploited was audited. We ask a narrower set of questions.
What is the validation model in one sentence? If the honest answer is "a multisig of validators we have to trust," we treat the bridge as a custodian and size our exposure accordingly. We do not route more value through it than we would hand to a custodian with the same operational profile.
Where does mint authority live, and what is the upgrade path on that contract? An upgradeable mint contract with a hot admin key is a different risk than an immutable one. We trace the admin to a multisig or a timelock and we read the timelock delay. A zero-delay upgrade key on a bridge is a disqualifier.
What is the maximum value at rest in the lock contract, and is there a per-transaction or per-window cap? Rate limits are not glamorous and they are the difference between a contained incident and a total loss. A bridge with a circuit breaker that halts on anomalous outflow has bought itself a chance to respond. One without it has not.
Is there a way to not bridge?
When to avoid bridging entirely
This is the question most teams skip, and it is the cheapest security win available.
If your users do not actually need an asset on chain B — they need to do something on chain B — you may not need a bridge at all. Account abstraction and intent-based execution let a user express what they want and let a solver handle the cross-chain mechanics, often without your protocol custodying anything across chains. The value moves through liquidity, not through a mint authority you control.
If you are issuing your own token, native multichain issuance beats bridging it. A canonical token deployed natively on each chain with a burn-and-mint controller you own is strictly safer than wrapping your token through a third-party bridge, because you are not inheriting their validator set. Circle's approach to USDC — native issuance plus a burn-and-mint transfer protocol — exists precisely because wrapped, bridged stablecoins were a liability.
If you only need data, not value — a price, a state, a proof — a message bridge with a small, capped blast radius is acceptable where a token bridge would not be. The most dangerous bridges are the ones holding pooled funds. A bridge that only delivers a number cannot be drained.
And sometimes the right answer is one chain. We have talked clients out of a multichain architecture that existed to chase liquidity that was not there. The cross-chain complexity was pure downside. ./chain --single shipped faster and got exploited zero times.
What fixed looks like
A cross-chain architecture we would sign off on names its trust model out loud and sizes exposure to match it. Value at rest in any single bridge contract is capped. There is a circuit breaker that halts outflow on anomalous volume and a human-reachable procedure to trip it. Mint authority and upgrade authority sit behind a timelock long enough to react to. Where the design could avoid pooling funds — native issuance, liquidity networks, intent-based execution — it does.
And the team can answer, without flinching, why bridging is necessary at all rather than assumed. The first 90 days are quiet because the attack surface was mapped before deployment, not after the funds left.
This is for you if
You are building a production system that moves real value or critical messages across chains, and a bridge failure would be measured in seven figures or in regulatory exposure. You want an adversarial read of your cross-chain trust model before you commit funds to it. The engineering scope for a proper cross-chain architecture review and build — trust-model analysis, blast-radius design, circuit breakers, and the off-chain message infrastructure — runs $100k and up depending on how many chains and how much value flows.
This is not for you if you are bridging a memecoin for the liquidity and the value at risk is a rounding error. Spend your security budget where the loss would actually hurt.