How Crypto Bridges Work, and Why They Keep Getting Exploited

Look down the list of the largest crypto thefts and bridges appear repeatedly. That is not coincidence, and it is not because bridge developers are unusually careless. It follows from what a bridge has to be.

What a bridge does

Blockchains cannot see each other. A token on one chain has no existence on another, and there is no native mechanism for moving it. A bridge simulates that movement.

The common design locks your asset in a contract on the source chain and issues a representation of it on the destination chain. The representation is only worth anything because the original is locked and will be released when the representation is destroyed. Some part of the system must decide, correctly, when that has happened.

Where the risk concentrates

Three properties follow, and together they explain the pattern:

1. A bridge holds pooled collateral. Everything locked sits in one place. The value at risk is the total, not any user’s balance.
2. Something privileged decides when to release it. A validator set, a guardian set, a keeper role, a verification contract. That authority is the actual security boundary.
3. The two chains have no shared source of truth. Correctness rests on the bridge’s own attestation that a deposit occurred.

Compromise the attestation and you can withdraw without depositing. That is the shape of nearly every major bridge exploit.

The same failure, four ways

Our tracker records four bridge incidents whose mechanisms are worth comparing, because they are variations on one theme:

• Ronin — the attacker obtained enough validator keys to meet the signature threshold. The threshold was nominally five of nine, but the keys were not independently held.
• Wormhole — a flaw in signature verification let a forged attestation be accepted, minting wrapped assets against a deposit that never happened.
• Poly Network — a contract function allowed the privileged keeper role to be reassigned. The attacker then made properly-authorised withdrawals.
• Nomad — an upgrade initialised the trusted root to zero, so every message verified as proven. No skill was needed to participate, and hundreds of addresses did.

Note what is absent from all four: nobody broke a cryptographic primitive. The failures are key management, verification logic, authorisation and deployment configuration.

Wrapped assets are a claim

A wrapped token is a claim on collateral held elsewhere. When the collateral is gone, the wrapper is unbacked — and it will usually keep trading and transferring normally, because nothing on the destination chain knows. Wormhole holders were exposed to precisely this until a backer replaced the shortfall, which was a discretionary act rather than a property of the system.

What a user can reasonably assess

You cannot audit a bridge. You can ask narrower questions:

• Who can authorise a withdrawal, and how many genuinely independent parties are involved? Not the nominal threshold — who actually holds the keys.
• Is there monitoring that reconciles locked collateral against circulating wrapped supply? Ronin’s theft went unnoticed for six days.
• Is the contract upgradeable, and by whom? Nomad’s defect arrived in an upgrade.
• How long has it been live at this value? Time under adversarial attention is real evidence.

What this does not tell you

A bridge that answers all of these well can still fail. These questions filter out the obviously fragile; they do not certify the rest. The durable mitigation is not choosing a perfect bridge but limiting how much sits in one at a time, and not treating bridged assets as equivalent to the underlying.