What Is a Crypto Bridge? How Blockchain Bridges Work and Where They Break

A token can't leave the chain it was issued on. Every "bridge" you've ever used works around that fact with some form of IOU, and the whole question of whether a bridge is safe comes down to who stands behind the IOU.

Keep that question in mind and most of the rest follows, from how the common designs work to why bridges were the most expensive target in crypto during 2022. We haven't built a bridge ourselves. We do work on chains where cross-chain movement comes up constantly, and we've formed opinions about it.

What a bridge actually does

Two blockchains don't share state. Ethereum has no idea what happened on Solana in the last block, and Solana can't read Ethereum's storage. So when you "move" 10 ETH to another chain, nothing moves. Something on the source chain takes your ETH out of circulation, something on the destination chain issues 10 units of a token that claims to represent it, and some party in the middle tells the destination chain that the first step really happened.

That middle party is the bridge. Everything else is plumbing.

There are three common ways to arrange the plumbing.

Lock and mint. You deposit the original asset into a contract on chain A. The bridge sees the deposit and mints a wrapped version on chain B. The wrapped token is only worth anything because the locked collateral sits in that contract on chain A, waiting to be released. This is how most wrapped assets were born, and it's why the lock contract becomes a giant pile of money with a single point of attack.

Burn and release. The reverse trip. You burn the wrapped token on chain B, the bridge observes the burn, and the lock contract on chain A releases the original. Some token issuers skip the lock entirely and run burn-and-mint natively on every chain they support, which removes the honeypot but means you're trusting the issuer's minting authority instead.

Liquidity networks. No wrapping at all. Liquidity providers hold real inventory on both chains. You hand your tokens to a pool on chain A, and a relayer or pool on chain B pays you out of its own balance, then gets reimbursed once your deposit is confirmed. You receive a native asset, which is nicer, but you're limited by how much inventory sits on the other side, and you pay for the provider's capital.

In all three, someone has to attest that an event on chain A happened. How that attestation is produced is what separates a reasonable bridge from a disaster.

Trust models, from weakest to strongest

We sort bridges by the question "what would an attacker need to compromise to steal the locked funds?" Here's how that plays out across the main designs, roughly from easiest to hardest to break.

A multisig or external validator set is the simplest design. A group of signers watches chain A, and when enough of them sign a message saying "this deposit happened," chain B accepts it. It's fast and cheap to build. It's also exactly as secure as those keys. If the threshold is 5 of 9, then 5 private keys are the whole security model, regardless of how decentralized either chain is.

An optimistic bridge accepts messages after a waiting period unless someone submits a fraud proof. Security depends on at least one honest watcher being online and able to challenge within the window. That's a weaker assumption than trusting a majority of signers, but it costs time, and it fails badly if the verification logic itself is broken (more on that below).

A light client bridge runs a verifier for chain A's consensus inside chain B. Instead of trusting signers, chain B checks block headers and Merkle proofs itself. IBC, the protocol connecting Cosmos chains, is the best known example. You're now trusting the two chains' own consensus, which is the strongest you can get, but on-chain light clients are expensive to run and hard to build for chains with very different cryptography.

A ZK bridge does the light client's work off chain and posts a succinct proof that the headers and the deposit are valid. Chain B verifies the proof, which is cheap. It's the most promising direction, and in our view it's also where the remaining risk shifts to the prover code and the circuit design, which are young and hard to audit.

There's also the special case of a rollup's canonical bridge to its parent chain, where the bridge contract is part of the rollup's own security design. Optimistic rollups on Ethereum hold withdrawals for a challenge period (seven days is typical) for exactly this reason. If you're moving between a rollup and Ethereum, the canonical bridge is usually the slowest option and the safest one.

Why bridges were the biggest target of 2022

Bridges concentrate value. A lock contract on a popular bridge can hold hundreds of millions of dollars backing tokens on another chain, and the code guarding it often sits outside the security assumptions of either chain. Attackers noticed. Three incidents from 2022 cover the main failure modes well.

Ronin, March 2022. The Ronin bridge for Axie Infinity used 9 validators with a 5-of-9 threshold. The attacker got control of four keys run by Sky Mavis plus a fifth, belonging to a validator that had granted Sky Mavis signing permission months earlier and never had it revoked. With five signatures they withdrew roughly 173,600 ETH and 25.5 million USDC, more than $600 million at the time. Nobody noticed for six days. This is the multisig model failing exactly as designed: the chain was fine, the keys weren't.

Wormhole, February 2022. A flaw in signature verification on the Solana side let the attacker convince the bridge that a valid guardian approval existed when it didn't. They minted 120,000 wrapped ETH on Solana with nothing locked behind it, about $320 million worth. Jump Crypto replaced the missing ETH so the wrapped token stayed backed. Here the trust model was arguably sound; the code checking it wasn't.

Nomad, August 2022. Nomad was an optimistic design. A routine upgrade initialized a trusted root to zero, which meant messages that had never been proven were treated as valid. Once one person found that, others copied the transaction, swapped in their own address and replayed it. Hundreds of addresses joined in, and around $190 million left the contract in a few hours. One configuration mistake turned the bridge into a free-for-all.

Three designs and three different bugs, but one lesson: the bridge's security is whatever the weakest component in it is, and that component is usually off to the side of either chain's consensus.

Wrapped tokens carry the bridge's risk with them

This part gets missed by product teams. When a user holds a wrapped asset, they hold a claim on a specific bridge's collateral. If that bridge is drained, the wrapped token loses its backing, and every protocol that accepted it as collateral inherits the loss.

We've seen projects list three different wrapped versions of the same asset because each arrived over a different bridge, then treat them as interchangeable in a pool. They aren't. Each one is a separate credit risk, and the names often look nearly identical in a wallet.

If you're building anything that accepts bridged assets, be explicit about which bridge's version you accept, and know what happens to your users if that bridge fails. That's a product decision, and it belongs in the spec, not in a ticket for whoever wires up the integration.

When you can skip the bridge entirely

The safest bridge is the one you don't need. Much of the time, "we need a bridge" really means "we need two representations of the same value to be convertible." If both representations live on the same chain, a plain contract can do it without any external attestation at all.

Vaulta is a good example from our own day-to-day work. When EOS was renamed Vaulta in 2025, the network introduced a new token, A, alongside the existing EOS token. Moving between them is a 1:1 swap through a system contract on the same chain: send EOS to the contract and receive A, or the reverse. There's no lock on another chain and no validator set signing off on events it can't see directly. The swap is an ordinary on-chain action that the chain's own producers validate. We built that swap into Blocksfinity, and it's one of the less stressful features we've shipped for exactly that reason.

Vaulta also runs an EVM layer (it launched as EOS EVM) that runs as a contract on the native chain. Moving native tokens into it is a transfer to that EVM contract with your EVM address in the memo, and moving them back goes through the same contract. That's still a bridge in the sense that two different execution environments are involved, but both sides are enforced by the same chain and the same producers. It's a much smaller trust surface than a bridge between two independent networks. (The EOS Network Foundation's EVM token docs cover the mechanics.)

The broader point: before you add a cross-chain dependency, ask whether you can keep the logic on one chain. If you're picking a chain for a new product, how much liquidity already lives there natively should weigh more than how many bridges connect to it. Our post on EVM chains goes into that choice in more depth.

What we check before using or integrating a bridge

When a client needs cross-chain movement and there's no way around it, this is the list we work through. It isn't exhaustive, but a bridge that fails several of these doesn't get near production.

• Who can approve a message, how many of them, and who holds those keys in practice. Named operators on separate infrastructure are better than five keys at one company.
• Who can upgrade the bridge contracts, and whether there's a timelock long enough for users to exit before a malicious upgrade lands.
• Audit history, including whether the audited code is the code actually deployed, and whether there's a live bug bounty sized to the value at risk.
• Rate limits and circuit breakers. A bridge that caps withdrawals per hour turns a total loss into a partial one.
• Monitoring: whether someone watches for mismatches between locked collateral and minted supply, and how fast they can pause.
• Which wrapped version of the asset you'll end up holding, and how liquid it is if you need to exit.
• The incident record. A bridge that was hacked and handled it well can be a better bet than one that's never been tested, but read the post-mortem.

On the integration side, treat bridge messages as untrusted input. Check amounts and recipients on your end and cap what any single message can do in your contracts. Design so that a bridge failure freezes one feature, not your entire protocol. We use the same separation of concerns in our exchange work on DEX223, where the UI is decoupled from the contracts so that no single component holds every key.

If your users will be bridging to reach your product, tell them which route you consider safe, and say so plainly in the UI. Most of the people who lost money in 2022 had no idea which trust model they'd signed up for.

Bridges are useful and sometimes unavoidable. They're also the riskiest piece of most multi-chain architectures, and in our experience the best design decision is often the one that removes the need for one. If you're weighing a cross-chain design and want a second opinion, talk to us.