Intermediate · 12 min read

How Cross-Chain Bridges Work (and Why They're Risky)

Cross-chain bridges move billions between blockchains every week — and have lost billions more to exploits. Here's how the plumbing actually works and how to size up the risk before you use one.

Dario FennDario FennDeFi & Markets Lead · DeFi protocols, yield, market structure and on-chain data
How Cross-Chain Bridges Work (and Why They're Risky)
The short answer

A cross-chain bridge locks or burns an asset on one chain and releases or mints a representation on another, with some mechanism attesting the first half happened. That attester — a validator set, a signature verifier, a trusted root — is what has failed in every large bridge theft, not the chains themselves. Prefer the issuer's own route or a canonical chain bridge, and keep bridge exposure measured in minutes.

Every time you move an asset from Ethereum to Arbitrum, or wrap Bitcoin as an ERC-20 to use in a DeFi pool, you're relying on a cross-chain bridge — a piece of infrastructure that has, cumulatively, been the site of more stolen crypto than almost any other category of exploit. Bridges are indispensable plumbing for a multi-chain industry, and they are also, structurally, one of its weakest points. Understanding how cross-chain bridges work isn't academic. It's the difference between moving funds with your eyes open and finding out the hard way why a chain's liquidity vanished overnight.

What a cross-chain bridge actually does

Blockchains don't talk to each other natively. Ethereum has no idea Solana exists, and vice versa — each is a closed ledger with its own validators, its own state, its own rules for what counts as a valid transaction. A bridge is the software and, crucially, the trust arrangement that lets an asset (or a message representing an asset) move from one closed system to another. There is no teleportation involved. What actually happens is one of a handful of mechanical patterns, and knowing which one a given bridge uses tells you most of what you need to know about its risk.

The most common pattern is lock-and-mint. You send your native asset — say, ETH — to a smart contract on the source chain, which locks it. The bridge then instructs a corresponding contract on the destination chain to mint a wrapped version, such as WETH on Avalanche. That wrapped token is a claim on the locked original; redeem it and the bridge burns the wrapped token and unlocks the underlying asset. A second pattern, burn-and-mint, is used when a token already has canonical representations on multiple chains — the token is burned on one side and minted on the other, with total supply managed across chains rather than one chain holding a reserve. A third pattern, liquidity-pool bridging, avoids wrapping altogether: you deposit an asset into a pool on chain A, and a market maker or automated pool pays you out the equivalent on chain B from its own reserves, later rebalancing behind the scenes. Stargate and Synapse popularised this approach because it sidesteps some of the wrapped-asset liquidity fragmentation that plagued earlier bridges.

The trust models bridges rely on

This is the part that matters most and gets glossed over most often. A bridge is only as trustworthy as the mechanism that verifies "yes, the deposit on chain A genuinely happened" before it authorises a mint or payout on chain B. There are three broad trust models in production today, and they trade off decentralisation against speed and cost.

Federated or multisig bridges rely on a fixed set of validators — often a single company or a small consortium — who watch the source chain and jointly sign off on destination-chain actions. This is fast and cheap to build, which is why the large majority of bridges use it, but it concentrates risk into however many keys are required to authorise a transfer. The Ronin bridge behind Axie Infinity used a 5-of-9 multisig; attackers who compromised five of those nine keys could mint whatever they wanted, and in March 2022 that's exactly what happened. Light-client and zero-knowledge bridges instead have the destination chain cryptographically verify a compressed proof of the source chain's state — no trusted intermediary required, in principle — but they're expensive to run and harder to build correctly, which is precisely why so few bridges use them despite being the theoretically sounder design. Optimistic bridges sit in between: they assume transfers are valid unless someone submits fraud proof within a challenge window, trading some speed for a weaker trust assumption than a multisig.

Why bridges keep getting hacked

The numbers are not subtle. Ronin lost roughly $625 million in March 2022 when attackers forged signatures using five compromised validator keys. Wormhole lost $325 million a month earlier after an attacker found a way to spoof the signature verification that was meant to confirm a deposit had actually occurred on Solana. Nomad lost close to $190 million in August 2022 because of a botched contract upgrade that let literally any message be replayed as "valid" — turning the exploit into a free-for-all that drew in opportunistic copycats within hours. Poly Network lost $611 million in August 2021 to a bug that let an attacker rewrite the contract's own list of authorised keepers, though in that case most of the funds were eventually returned.

Look at those four and a pattern emerges: none of them were exotic. They were signature verification bugs, key compromises, and access-control mistakes — the unglamorous stuff of software engineering, magnified by the fact that a single flaw can unlock a shared pool worth hundreds of millions. Bridges are attractive targets precisely because they concentrate value: a lending protocol exploit nets you whatever's in that one protocol, but a bridge exploit can net you the reserve backing every wrapped asset that bridge has ever issued.

Reading a bridge's risk profile before you use it

Before routing meaningful size through any bridge, there's a short list worth working through. How many entities can authorise a transfer, and how many of them need to collude or be compromised for funds to move improperly — five keys is a very different proposition to nineteen. Has the contract code been audited, by whom, and how long ago, given that audits are a snapshot, not a guarantee. Has the bridge been live long enough, and processed enough volume, to have earned some confidence, since a brand-new bridge offering unusually generous incentives is a red flag rather than a bargain. Is there an insurance fund or backstop, and is it actually large enough relative to the value the bridge secures to matter in a real incident. And is this the chain's canonical bridge — built and maintained by the chain's own team, typically the most conservative and most scrutinised option — or a third-party bridge built by an outside team chasing speed and fees.

Canonical bridges, such as the official Arbitrum or Optimism bridges back to Ethereum, tend to be the safer default for large transfers precisely because they're boring: fewer intermediate trust assumptions, direct backing by the L2's own contracts, and the most scrutiny from the ecosystem that depends on them. Third-party bridges earn their place by being faster or supporting routes the canonical bridge doesn't, which is a real value — it's just a value that comes with an extra layer of trust you're choosing to take on.

Practical rules for moving assets across chains

A few habits go a long way. Split large transfers rather than sending everything through one bridge in one transaction — if something goes wrong, you want to have found out with a fraction of your position, not all of it. Default to canonical, chain-native bridges for anything you'd consider a meaningful sum, and reserve newer or exotic bridges for smaller, more disposable amounts. Check whether a bridge has a public incident history before assuming a clean track record — some quietly patched near-misses without ever being exploited, and that's worth knowing. Be sceptical of bridges offering conspicuously high yields for providing liquidity; that yield is compensation for a risk somebody has priced, and it's worth asking exactly what that risk is.

Bridge aggregators such as Li.Fi, Socket, and Bungee route your transfer through whichever underlying bridge looks cheapest or fastest at that moment, which is convenient but adds a layer of abstraction between you and the actual trust model doing the work. They're useful for discovery and for small, routine transfers; for anything sizeable, it's worth clicking through to see which bridge is actually executing the move and applying the same scrutiny you would if you'd chosen it directly.

None of this makes bridges avoidable — a multi-chain industry needs them, and they're not going away. What changes with a bit of homework is the odds. Bridges will keep being a preferred target for as long as they keep concentrating value behind a small number of signatures, and the difference between an ordinary user and an exposed one usually comes down to whether they ever asked how the bridge they were using actually worked.

FAQ

What does a cross-chain bridge actually do?
It locks or burns an asset on the source chain and releases or mints a representation on the destination, with some mechanism attesting that the first half happened.
Why do bridges get hacked so often?
Almost every large bridge loss hit the component that attests a deposit occurred — validator keys, a signature verifier, a privileged role. The chains themselves have not been the weak point.
Is bridged crypto the same as the original asset?
Not unless the issuer minted it natively. A bridge-issued wrapper is a claim on that bridge's reserves and loses its backing if the bridge is drained, while the original asset is unaffected.
How can I reduce bridge risk?
Prefer the asset issuer's own route where one exists, then the chain's canonical bridge, and keep bridge exposure measured in minutes rather than leaving value parked in one.