Introduction Blockchains do not talk to each other. Ethereum cannot read Solana’s state. Arbitrum cannot verify a transaction on Avalanche. Each chain maintains its own ledger, its own consen
Bridges move assets between blockchains using lock-and-mint, burn-and-mint, or liquidity pool mechanisms, but their trust assumptions have made them the most exploited category in crypto.
SummaryBlockchains do not talk to each other. Ethereum cannot read Solana’s state. Arbitrum cannot verify a transaction on Avalanche. Each chain maintains its own ledger, its own consensus, and its own finality rules. This isolation is a feature of security design, but it creates a practical problem: users hold assets on one chain and want to use them on another.
Bridges exist to solve this. A bridge is a system that lets a user deposit assets on chain A and receive corresponding assets on chain B. The concept sounds simple. The implementation is where billions of dollars have been lost.
The core difficulty is verification. When a user claims to have deposited 100 ETH on Ethereum and asks for 100 ETH on Arbitrum, someone or something must verify that the deposit actually happened. The mechanism chosen for this verification determines the bridge’s security model, its speed, its cost, and its attack surface. As a Coinbase analysis of bridge hacks noted, bridge security failures consistently stem from the gap between the trust assumptions a bridge claims and the trust assumptions it actually enforces.
This guide covers how the major bridge architectures work, why each of the largest exploits succeeded, and what to check before trusting a bridge with your funds.
The earliest and most common bridge design is lock-and-mint. The mechanism works in three steps:
To move back, the process reverses: the user burns the synthetic token on the destination chain, validators attest to the burn, and the original tokens are unlocked on the source chain.
The security of lock-and-mint depends entirely on the verification step. If an attacker can convince the destination chain that a deposit occurred when it did not, they can mint unbacked tokens. This is exactly what happened in the largest bridge exploits.
The arithmetic problem. Lock-and-mint bridges must maintain a 1:1 ratio between locked originals and minted synthetics. If 10,000 ETH is locked on Ethereum, exactly 10,000 bridged ETH should exist on the destination chain. Any discrepancy means some bridged tokens are unbacked. When exploits create unbacked synthetics, the last users to redeem find the vault empty. This creates a bank-run dynamic: once news of an exploit spreads, every holder of the wrapped token rushes to redeem, knowing that only the first to arrive will receive real assets.
Burn-and-mint eliminates the wrapped token problem by destroying the original and creating a new one.
This model works only for tokens whose issuers control minting on multiple chains. Circle’s Cross-Chain Transfer Protocol (CCTP) for USDC is the largest implementation. When a user bridges USDC from Ethereum to Avalanche through CCTP, the Ethereum USDC is burned and native USDC is minted on Avalanche. There are no wrapped tokens, no liquidity fragmentation, and no unbacked synthetics.
The limitation is that burn-and-mint requires the token issuer to deploy and operate infrastructure on every supported chain. It is not a general-purpose mechanism. Arbitrary ERC-20 tokens cannot use burn-and-mint unless their developers build the cross-chain minting infrastructure. CCTP currently supports over a dozen chains, but each integration requires Circle’s direct involvement.
A third model avoids both wrapping and burning by using pre-funded liquidity pools on each chain.
The mechanism:
Stargate (built on LayerZero) and Across Protocol use variations of this model. The advantage is speed: because tokens already exist on the destination chain, there is no minting delay. The user receives real, native tokens immediately.
The tradeoff is capital efficiency. Liquidity must be pre-positioned on every supported chain, and that capital earns a return only when bridges are actively used. During low-volume periods, liquidity providers earn little while their capital sits idle. The aggregate capital requirements across all supported chains can reach hundreds of millions of dollars, creating a barrier to entry and a concentration risk if a single liquidity provider dominates.
On March 23, 2022, attackers drained $624 million in ETH and USDC from the Ronin bridge, which connected Ethereum to the Ronin sidechain used by the game Axie Infinity.
Ronin’s bridge used a multisig validation scheme. Nine validator nodes verified bridge transactions, and any five could authorize a withdrawal. The security assumption was that compromising five of nine independent validators would be impractical.
The assumption was wrong. Sky Mavis, the company behind Axie Infinity, controlled four of the nine validator nodes. A fifth validator had granted Sky Mavis temporary permission to sign on its behalf during a period of high transaction volume and never revoked the permission.
The attackers (later attributed to North Korea’s Lazarus Group by the FBI) compromised Sky Mavis’s systems and obtained the private keys for all five validators. With five of nine signatures, they authorized two fraudulent withdrawals: 173,600 ETH and 25.5 million USDC.
The exploit was not discovered for six days. It came to light only when a user tried to withdraw 5,000 ETH and found the bridge did not have enough funds.
The lesson. Multisig security is only as strong as the independence of its signers. When a single organization controls a majority of keys, the multisig is a single point of failure with extra steps.
On February 2, 2022, an attacker exploited the Wormhole bridge to mint 120,000 wETH (wrapped ETH) on Solana without depositing any ETH on Ethereum. The exploit was worth approximately $326 million.
Wormhole’s bridge relied on a set of 19 guardians to verify cross-chain messages. The guardians would observe a deposit on Ethereum, produce a signed attestation (called a VAA, Verified Action Approval), and the Solana-side contract would verify the signatures before minting.
The vulnerability was in the Solana-side signature verification. Wormhole’s Solana contract used a deprecated system instruction (verify_signatures) that did not properly validate the accounts passed to it. The attacker crafted a fake guardian set, submitted a forged VAA with signatures from that fake set, and the contract accepted it as valid.
In effect, the attacker told the Solana contract “these guardians approved this mint” and the contract did not check whether the guardians were real.
Jump Crypto, which backed Wormhole, replaced the stolen 120,000 ETH from its own reserves. The full restoration happened within 24 hours, an unprecedented response that prevented cascading losses across Solana DeFi protocols that held wETH.
The lesson. Bridge verification code is high-value attack surface. A single logic error in how signatures are validated can allow unlimited unauthorized minting.
On August 1, 2022, the Nomad bridge was drained of approximately $190 million. Unlike Ronin and Wormhole, Nomad was not attacked by a sophisticated group. It was drained by hundreds of individual copycats after the initial exploit became public.
You might also like: Cetus Protocol hack and Sui exploit: The full story behind the $260 million attack
Nomad used an optimistic verification model. Cross-chain messages were submitted and assumed valid unless challenged within a 30-minute window. A routine contract upgrade introduced a bug: the contract was initialized with a trusted root of 0x00, the zero bytes32 value.
In Nomad’s verification logic, every message was checked against the trusted root. Because 0x00 is the default value for uninitialized storage in Solidity, every message automatically passed verification. Any user could submit any message and the contract would accept it as proven.
Once the first attacker demonstrated that arbitrary messages were accepted, others copied the transaction, changed the recipient address, and replayed it. The bridge was drained by a swarm of opportunistic attackers, including white-hat hackers who later returned approximately $36 million in recovered funds.
The lesson. Initialization bugs in bridge contracts can be catastrophic. A single misconfigured parameter turned Nomad’s security model from “optimistic verification with fraud proofs” to “no verification at all.”
In June 2022, the Harmony Horizon bridge lost $100 million when attackers compromised the private keys of two out of five validators in the bridge’s multisig. Harmony’s bridge required only two of five signers to approve a transaction, an unusually low threshold for a bridge holding $100 million.
The attack reinforced the Ronin lesson: multisig bridges are only as secure as their weakest signer set. When the threshold is low relative to the number of signers, a single infrastructure compromise can be sufficient. Security researchers had publicly criticized Harmony’s two-of-five threshold before the attack occurred.
The lesson. Threshold selection matters as much as validator count. A five-of-nine multisig offers meaningfully different security than a two-of-five multisig, even though both use the same underlying mechanism.
The scale of bridge losses is without precedent in smart contract security. Bridge exploits represent roughly $3 billion of the $17 billion in total crypto hacks over the past decade, making bridges the single most attacked category of smart contracts.
The attack patterns cluster into three categories:
Key compromise. The attacker obtains enough validator or signer keys to forge bridge messages. Ronin and Harmony followed this pattern. The vulnerability is not in the code but in the operational security of the signer infrastructure.
Verification bypass. The attacker finds a bug in the verification logic that allows forged messages to pass. Wormhole followed this pattern. The vulnerability is a code-level error in the most critical function of the bridge contract.
Initialization or upgrade errors. The attacker exploits a misconfiguration introduced during deployment or upgrade. Nomad followed this pattern. The vulnerability is procedural: the team made an error during a routine operation.
Each pattern requires a different defense. Key compromise is mitigated by increasing signer diversity and using hardware security modules. Verification bypass is mitigated by auditing and formal verification. Initialization errors are mitigated by upgrade procedures that include mandatory test runs on forked networks.
A fourth emerging pattern deserves mention: governance attacks. An attacker who accumulates enough governance tokens to control a bridge’s upgrade mechanism can modify the bridge contract to drain funds. This attack is slower and more visible than the others, but it targets bridges whose governance is concentrated or whose time-lock on upgrades is too short. Bridge teams increasingly use multi-day time-locks (48 to 72 hours) on contract upgrades to give users time to withdraw before a malicious change takes effect.
A newer approach sidesteps bridge contracts entirely by using intent-based cross-chain transfers. Across Protocol and UniswapX’s cross-chain mode let users express a bridging intent: “I have 1,000 USDC on Ethereum and want 1,000 USDC on Arbitrum.” A solver (called a relayer) immediately sends tokens from their own inventory on the destination chain, then later claims reimbursement.
This model reduces the trust surface. The user never deposits tokens into a bridge contract that holds pooled funds. The solver takes on the reimbursement risk, and the settlement contract enforces that the user received the promised output. There is no large pool of locked assets for an attacker to target.
The tradeoff is solver dependency: if no solver is willing to fill the intent at an acceptable price, the transfer does not execute. For high-traffic routes (Ethereum to Arbitrum, Ethereum to Base), solver competition is strong. For low-volume routes, solvers may not be active.
The exploits above share a common weakness: they rely on external validators or multisigs to attest that something happened on another chain. If those attestors are compromised, the bridge fails.
Light client bridges take a different approach. Instead of trusting a validator set, the destination chain runs a light client that verifies the source chain’s consensus directly.
A light client bridge to Ethereum, for example, would track Ethereum’s validator set and verify block headers and state proofs on-chain. When a user claims to have deposited tokens on Ethereum, the bridge contract verifies the Merkle proof against the Ethereum block header it has already validated.
This approach is trust-minimized: the bridge trusts the source chain’s consensus, not an external committee. But it is expensive. Verifying Ethereum’s consensus on another chain requires significant computation, which translates to high gas costs.
Zero-knowledge proofs offer a solution to the cost problem. Instead of verifying every validator signature on-chain, a ZK proof can compress the verification into a single succinct proof. The destination chain verifies one proof instead of hundreds of signatures.
Projects like Succinct Labs, Polymer, and Lagrange are building ZK-verified bridges. These are still maturing, but they represent the strongest security model for cross-chain communication: trust the math, not the committee. Early implementations show verification costs dropping as ZK proving systems become more efficient, with some bridges already operating on mainnet with proving times under 30 seconds.
This guide explains bridge mechanics and the largest exploits. It does not cover:
Check the verification mechanism. Multisig bridges are the weakest model. Light client and ZK-verified bridges are the strongest. Optimistic bridges fall in between. Know what you are trusting.
Look at the validator or guardian set. For multisig bridges, check how many signers exist, who operates them, and whether they are genuinely independent. If the majority of signers belong to the same organization or geographic jurisdiction, the multisig provides limited security.
Review audit history. Bridge contracts are high-value targets. Look for multiple independent audits from reputable firms. A bridge that has not been audited, or has been audited only once, warrants extra caution. Pay attention to the scope of audits: an audit of the token contract does not cover the verification logic.
Consider total value locked versus security budget. A bridge holding $500 million with a five-of-nine multisig presents a very different risk profile than a bridge holding $5 million. Attackers target bridges where the potential payout justifies the effort. The rational attacker calculates whether the cost of compromising enough keys is less than the value that can be extracted.
Test with small amounts first. Before bridging significant value, send a small test transaction. Verify that the receiving address, token, and amount are correct. Bridge transactions are typically irreversible.
Prefer native bridges for rollups. For Ethereum L2 rollups (Arbitrum, Optimism, Base), the canonical bridge inherits security directly from Ethereum’s consensus. Third-party bridges may be faster but introduce additional trust assumptions. Use canonical bridges for large transfers where security matters more than speed.
Read more: What are cross-chain bridges? Why they keep getting hacked
A cross-chain bridge is a system that transfers assets or data between two blockchains that cannot natively communicate. The bridge locks, burns, or pools tokens on one chain and issues corresponding tokens on another, using a verification mechanism to ensure the transfer is legitimate.
Bridges are high-value targets because they hold large pools of locked assets. They also introduce complex trust assumptions at the boundary between two different security models. A vulnerability in the verification mechanism (compromised keys, faulty signature checks, initialization bugs) can allow an attacker to drain the entire pool in a single transaction.
Lock-and-mint holds the original token on the source chain and mints a synthetic (wrapped) version on the destination chain. Burn-and-mint destroys the original and mints a new native token on the destination. Burn-and-mint produces native tokens rather than synthetics but requires the token issuer to control minting on both chains.
Wrapped tokens are only as safe as the bridge that issued them. If the bridge is exploited and the backing assets are drained, the wrapped tokens become unbacked and lose their peg. Users holding wrapped tokens bear the bridge’s security risk, not just the underlying asset’s risk.
It varies by mechanism. Liquidity pool bridges and intent-based bridges (Across) can complete in seconds. Lock-and-mint bridges with multisig verification typically take 10 to 30 minutes. Optimistic bridges with fraud proof windows can take 7 days for withdrawals from optimistic rollups to Ethereum, though fast bridges can front the liquidity to reduce this.
A light client bridge verifies the source chain’s consensus directly on the destination chain, rather than relying on an external validator set. It checks block headers and state proofs, trusting the source chain’s own security. This is more trust-minimized than multisig or optimistic verification but costs more gas to operate.
Yes. If the bridge is exploited after you have deposited but before you have withdrawn, your locked tokens may be stolen. If you hold wrapped tokens and the bridge is hacked, your wrapped tokens may become worthless. Additionally, incorrect destination addresses or unsupported token types can result in permanent loss.
No single bridge is best for all situations. For USDC, Circle’s CCTP is the most secure option because it uses burn-and-mint with no wrapped tokens. For general ERC-20 transfers, compare the verification mechanisms of available bridges. Prefer bridges with light client or ZK verification, multiple independent audits, and a track record of secure operation. Bridge aggregators like Li.Fi can help compare routes. *Disclaimer: This article is for informational purposes only and does not constitute financial, investment, or legal advice. Cryptocurrency involves significant risk, and you should conduct your own research before making any decisions. Information is accurate as of August 2026.*
