What are cross-chain bridges? Why they keep getting hacked

Blockchains cannot talk to each other on their own. Bridges are the software that moves value between them, and they have leaked more money to hackers than any other kind of crypto infrastructure, billions across a handful of catastrophic breaches. Here is how bridges actually work, the different trust models behind them, and why the connective tissue of crypto is also its most dangerous single point of failure.

There are hundreds of blockchains, and by design none of them can see the others. Ethereum has no native way to know what happened on Solana; a Bitcoin holder cannot directly spend that Bitcoin inside an Ethereum application. Each chain is an island with its own ledger, its own validators, and no built-in bridge to the mainland.

Yet users constantly need to move value between these islands, to chase yield, access an application, or reach cheaper fees, and that need created an entire category of infrastructure: the cross-chain bridge.

A bridge is software that lets assets and information move between blockchains that otherwise cannot communicate. It is essential plumbing; without bridges, liquidity would be trapped on whichever chain it started on, and the multi-chain world that defines crypto today could not function. Bridges now move billions of dollars a week, and their total value locked runs into the tens of billions.

They are also the single most dangerous piece of infrastructure in crypto. Bridge exploits have produced some of the largest thefts the industry has ever recorded, with individual breaches running into the hundreds of millions and the category’s cumulative losses in the billions. The same design that makes a bridge useful, holding or controlling large pools of assets across chains, makes it a concentrated target, and a small flaw in a bridge can drain a fortune in minutes. 

This guide explains how bridges work, the main architectures they use, the trust models that determine how safe each one is, why they keep getting hacked, and how to think about bridge risk before moving your own funds.

Why bridges are necessary

The root problem is isolation. A blockchain is a self-contained ledger whose validators agree only on the state of their own chain. Nothing in Ethereum’s protocol can natively verify that a transaction happened on another chain, because doing so would require Ethereum’s validators to also run and trust every other chain, which they do not. Each network is sovereign and blind to the others.

Before bridges, the only way to move value between chains was through a centralized exchange: send your asset to the exchange on one chain, trade it, and withdraw a different asset on another chain. This works but reintroduces exactly the centralized intermediary that crypto was meant to reduce, along with accounts, custody, and withdrawal limits. Bridges emerged to do the same job more directly, letting value move between chains without handing it to an exchange in the middle.

The demand is enormous because the ecosystem is fragmented by design. Different chains optimize for different things, and users want to combine them: hold an asset native to one chain but use it in an application on another, move to a network with cheaper fees, or supply liquidity where the returns are highest. The connective role bridges play is why the industry sometimes calls them the tissue linking the chains, and it is why bridge volume tracks the overall growth of multi-chain activity. As newer designs push more of that activity toward stablecoin settlement and payments, the demand to move dollar-denominated value across chains has only intensified, echoing the broader rise of payment-focused chains built around moving stable value efficiently.

The catch is that connecting sovereign, mutually blind systems is genuinely hard, and every method of doing it introduces a trust assumption somewhere. That assumption is where the money leaks.

How a bridge moves an asset

Most bridges rely on a simple-sounding trick: they do not actually send an asset from one chain to another, because that is impossible. Instead, they lock or destroy the asset on the source chain and create a corresponding asset on the destination chain.

Three main architectures implement this idea.

The lock-and-mint model is the most common. When you bridge an asset, the bridge locks your original tokens in a smart contract on the source chain, like putting them in a vault, and mints an equivalent wrapped token on the destination chain. That wrapped token is a claim on the locked original, redeemable by reversing the process: burn the wrapped token on the destination chain, and the bridge unlocks the original on the source chain. The locked assets sit in the bridge’s custody the entire time, which is precisely why lock-and-mint bridges have been the most exploited: the vault holding everyone’s locked assets is a single, enormous target.

The burn-and-mint model is used mainly for assets whose issuer controls supply across chains, such as certain stablecoins. Instead of locking the asset, the bridge permanently burns it on the source chain, removing it from that chain’s supply, and mints a fresh, native version on the destination chain. Because the destination asset is truly native, not a wrapped claim, this avoids the pool-of-locked-assets problem, but it only works when a single issuer has authority to burn and mint the asset on every chain, which is why it is common for stablecoins and rare for everything else.

The liquidity-pool model takes a different approach. The bridge maintains pools of assets on every supported chain, and when you bridge, you deposit into the pool on the source chain and withdraw the equivalent from the pool on the destination chain, often with a solver or market maker fronting the destination asset instantly and settling later. Nothing is wrapped; you simply swap into inventory that already exists on the other side. This can be faster and avoids wrapped-token risk, but it requires the bridge to keep large inventories on every chain, which is both capital-intensive and, again, a target.

Beyond moving assets, modern bridges also pass messages: arbitrary data and instructions that let a smart contract on one chain trigger an action on another. A token transfer is just the simplest message, saying an amount was locked here, so mint it there. More elaborate messages let an application on one chain react to events on another, which powers cross-chain lending, governance, and complex applications. This general message passing is powerful and expands what bridges can do far beyond simple transfers, but every added capability is added surface area for something to go wrong.

The trust models that decide safety

The crucial question for any bridge is who verifies that the source-chain event actually happened before the destination chain acts on it. The answer is the bridge’s trust model, and it is the single biggest determinant of how safe the bridge is. There is a well-known framework classifying these models, and it maps cleanly onto a spectrum from convenient-but-risky to trustless-but-costly.

The trusted model relies on a fixed set of external validators, often secured by a multisignature or multiparty scheme, who watch the source chain and sign off on events for the destination chain. This is fast, cheap, and simple, but the validator set is the trust assumption: if enough of their signing keys are compromised, the attacker controls the bridge. Many of the largest bridge hacks in history were failures of exactly this model, where an attacker gained control of enough validator keys to authorize fraudulent withdrawals. When a bridge’s security rests on a handful of keys, those keys are the whole game.

The light-client or validity-proof model is the trustless end of the spectrum. Here the destination chain actually runs a light client of the source chain and cryptographically verifies its block headers, or accepts a validity proof, instead of trusting a set of signers. This is far more secure because it removes the human validator set and replaces it with mathematics, but it is expensive in computation and complex to build, and it does not work efficiently for every pair of chains. Advances in zero-knowledge proofs, the same cryptography moving to the center of Ethereum’s long-term rebuild, are extending this model to more chains, but it remains harder to deploy than trusting a signer set.

Between the extremes sit optimistic and hybrid models, which assume transactions are valid but allow a challenge window during which watchers can submit proof of fraud, similar to how some scaling systems secure their withdrawals. These trade some speed, through the challenge delay, for stronger security than a pure trusted model, without the full cost of a light client. Where a bridge sits on this spectrum tells you almost everything about its risk: the more it relies on a small trusted group and the less it relies on cryptographic verification, the more it depends on those few parties never being compromised.

Why bridges keep getting hacked

Bridges have lost more to hackers than any other category of crypto infrastructure, and the reasons are structural, not accidental. Understanding them explains why the problem persists despite years of painful lessons.

The first reason is concentration of value. A bridge, especially a lock-and-mint one, accumulates a large pool of locked assets backing all the wrapped tokens it has issued. That pool is a single honeypot, and unlike a diffuse set of user wallets, draining it once takes everything. Attackers are economically rational, and they gravitate to wherever the most value sits behind the fewest defenses, which describes a large bridge almost perfectly.

The second reason is weak trust models. Many bridges chose the fast, cheap, trusted model, securing hundreds of millions of dollars behind a small set of signing keys. The largest bridge thefts on record were, at their core, key compromises: an attacker obtained control of enough of the bridge’s validator keys, through phishing, malware, or infrastructure breaches, and then simply authorized withdrawals that the bridge treated as legitimate. No clever exploit of the blockchain was needed, only control of the keys the bridge trusted. A bridge secured by nine keys where five are enough to move funds is, in security terms, a five-key vault.

The third reason is complexity. Bridges are among the most complex smart-contract systems in crypto, spanning multiple chains, custom message formats, and intricate verification logic, and complexity is the enemy of security. Every added feature, every new supported chain, every message type is more code that can contain a subtle flaw, and bridge exploits have repeatedly come from bugs in verification logic that let an attacker forge a proof of a deposit that never happened, causing the bridge to release funds against nothing. The fraud-proof and verification systems that are supposed to guard a bridge are themselves complex code, and a flaw there is catastrophic because it undermines the entire security model at once. The category’s history rhymes with the broader lesson that concentrated infrastructure fails hard, the same dynamic seen when any single point of control becomes the weakest link in an otherwise sound system.

These three forces combine into a grim equation: bridges hold enormous value, often behind trust models thinner than the value warrants, inside code complex enough to hide fatal bugs. That is why, even as the industry has learned hard lessons and newer designs have improved, bridges remain the place where the largest single thefts tend to happen.

The anatomy of a bridge hack

To make the risk concrete, it helps to walk through how a typical bridge exploit actually unfolds, because the pattern repeats across nearly every major incident and reveals why the losses are so total.

Most catastrophic bridge hacks fall into one of two shapes. The first is a key compromise. A trusted-model bridge secures its locked assets behind a set of signing keys, and an attacker obtains control of enough of those keys, through phishing an employee, compromising a server, or exploiting weak key management, to reach the signing threshold. Once the attacker can produce valid signatures, the bridge has no way to distinguish their fraudulent withdrawal from a legitimate one, because a validly signed instruction is exactly what the bridge is built to obey. The attacker signs a withdrawal that drains the locked pool, and the assets are gone before anyone notices, because from the bridge’s perspective nothing broke; the correct keys authorized the transfer. Several of the largest bridge thefts in history were precisely this: not a clever exploit of the blockchain, but a theft of the keys the bridge trusted, turning the bridge’s own security model into the attacker’s tool.

The second shape is a verification bug. A bridge must verify that a deposit really happened on the source chain before releasing funds on the destination chain, and this verification logic is complex code. If it contains a flaw, an attacker can craft a fake proof of a deposit that never occurred, submit it to the bridge, and the bridge, believing the fake, releases real assets against nothing. The attacker deposited nothing and withdrew a fortune, because the code that was supposed to check the deposit accepted a forgery. These bugs are catastrophic precisely because they attack the bridge’s core trust mechanism: once an attacker can forge the proof the bridge relies on, they can mint or withdraw arbitrary value until someone halts the bridge, which in a fast-moving exploit can be far too late.

Both shapes share a defining feature that explains why recovery is so rare: the theft looks legitimate to the bridge at the moment it happens. A key-compromise withdrawal carries valid signatures; a verification-bug withdrawal carries an accepted proof. Neither trips an alarm inside the system, because both exploit the system doing exactly what it was designed to do, only on fraudulent inputs. By the time the discrepancy surfaces, usually when the locked assets no longer back the wrapped tokens in circulation, the funds have moved through mixers and across other chains. The wrapped tokens left behind become claims on an empty vault, and their holders, who did nothing wrong, absorb the loss. This is the mechanism by which a single flaw in one bridge translates into hundreds of millions gone, and why the security of a bridge deserves more scrutiny than almost any other decision in a multi-chain transaction.

How to think about bridge risk

Bridges are necessary and, used carefully, reasonable to rely on, but their risk profile deserves respect. A few principles help you evaluate any bridge before trusting it with funds.

Prefer stronger trust models. A bridge secured by cryptographic verification, a light client or validity proofs, or by a canonical connection to a base chain, is structurally safer than one secured by a small external signer set. Where a bridge documents its trust model, read it; the difference between trusting mathematics and trusting a handful of keys is the difference between the safest and riskiest bridges in existence. Independent frameworks that score bridges on their trust assumptions exist precisely because this distinction is hard for users to assess alone.

Favor track record and audits. A bridge with a long operational history free of exploits, multiple independent security audits, an active bug bounty, and transparent, time-locked upgrade processes has earned more trust than a new, unaudited one, however attractive its yields. Bridges are not where to chase the newest, highest-return option, because the downside of a bridge failure is total loss of the funds in transit.

Minimize time and size at risk. Bridging is riskiest while your value sits in the bridge’s custody or in transit. Moving smaller amounts, avoiding leaving large balances in wrapped tokens longer than necessary, and using aggregators that route through the safest available path all reduce exposure, while minding the slippage a large cross-chain swap can incur along the way. For very large transfers, splitting them or accepting the slower safety of a canonical bridge can be worth the inconvenience.

Understand what you are holding after you bridge. A wrapped token is a claim on assets locked in a bridge, and it is only as sound as that bridge. If the bridge is exploited and its locked assets drained, the wrapped tokens it issued can become worthless claims on an empty vault, even though your original assets are gone. Native assets obtained through burn-and-mint or liquidity-pool models avoid this specific risk, which is one reason those models are often preferred where available, particularly for the stablecoins that dominate cross-chain settlement.

The honest summary is that bridges are indispensable and imperfect. They solve a real and unavoidable problem, connecting sovereign chains that cannot see each other, and there is no way to do that without introducing a trust assumption somewhere. The safest bridges push that assumption toward cryptography and away from small groups of keys; the most dangerous do the reverse and guard enormous value with thin trust. Knowing which kind you are using, and treating the crossing as the riskiest moment in any multi-chain transaction, is what separates informed use from the kind of blind trust that has, again and again, funded the largest heists in the industry.

It is worth ending on where the technology is heading, because the picture is not static. The industry has absorbed the lessons of its worst bridge failures, and newer designs increasingly favor stronger trust models: burn-and-mint transfers for assets whose issuers can support them, cryptographic light clients and validity proofs where the chain pairs allow, and intent-based systems where independent parties front liquidity and take on the risk rather than pooling everyone’s assets in a single honeypot. Independent risk frameworks now score bridges on exactly the trust assumptions that used to be invisible to ordinary users, making it easier to tell a well-secured bridge from a dangerous one before committing funds. None of this eliminates the fundamental tension that connecting blind, sovereign systems requires trusting something, but it does shift the trust toward mathematics and away from the small key-holding groups that account for the largest historical losses. The bridges of the next few years will be safer than those that leaked billions, not because the problem got easier, but because the industry paid for the lesson in full and is finally building as though it remembers.

Frequently asked questions

Disclaimer: This article is for informational purposes only and does not constitute investment advice. Digital asset markets are volatile and you can lose your entire investment. Always do your own research. Information current as of July 7, 2026.