Cross-chain bridges have lost more money to exploits than almost any other category in crypto.
The Ronin bridge lost $625 million in 2022. Wormhole lost $320 million that same year. Nomad lost $190 million just months later.
Yet bridges matter more now than ever.
TAC, Celo, and dozens of other projects rely on them to connect separate blockchain ecosystems that otherwise can't talk to each other.
Understanding why bridges are both indispensable and dangerous starts with understanding what they actually do at a technical level.
TL;DR
- A blockchain bridge is software that locks assets on one chain and mints equivalent representations on another, letting value move between isolated networks.
- Bridges are high-value targets because they hold custody of locked assets, sometimes billions of dollars, in smart contracts or multisig wallets.
- There are four main bridge designs (lock-and-mint, burn-and-mint, liquidity pools, and light-client verification), each with different security trade-offs.
- Most major hacks exploited validator key compromise, oracle manipulation, or logic bugs in smart contracts, not the underlying blockchains themselves.
- Newer trust-minimized designs using zero-knowledge proofs are reducing the attack surface, but no bridge is risk-free today.
What A Blockchain Bridge Actually Does
Two blockchains are, by default, completely isolated systems.
Bitcoin (BTC) has no awareness of Ethereum (ETH). Ethereum can't natively read a Solana (SOL) state update.
Each chain processes its own transactions, maintains its own ledger, and reaches consensus independently. There's no shared memory between them.
A bridge is the software layer that creates the illusion of cross-chain movement.
In practice, assets don't literally "move" from one chain to another. What actually happens is a two-step process: an asset gets locked (or burned) on the source chain, and a corresponding representation gets minted (or released) on the destination chain.
The bridge protocol coordinates these two events and guarantees they're linked.
A bridge does not teleport your tokens. It locks them on one side and prints an IOU on the other — the security question is always: who controls the lock, and who authorizes the printing?
This distinction matters enormously for security.
The original asset sits in custody somewhere. That custody is the attack surface.
Whether it's a smart contract, a multisig wallet controlled by a committee of validators, or a cryptographic proof system determines almost everything about how safe the bridge is.
Also Read: Bitget Blocked 150M Cyber Attacks In One Year, New Report Reveals
The Four Main Bridge Designs
Not all bridges work the same way. There are four dominant architectural patterns in production today, and each makes a different set of trade-offs between security, speed, capital efficiency, and decentralization.
Lock-and-Mint is the most common design. A user sends tokens to a smart contract on the source chain, where they are locked. The bridge's validator set observes this deposit and instructs the destination chain to mint a "wrapped" version of that token. Wrapped Bitcoin (WBTC) on Ethereum works this way. So does most of the bridged ETH on early Layer 2 networks. The wrapped token represents a claim on the locked original. When a user wants to go back, they burn the wrapped token and the lock on the source chain releases.
Burn-and-Mint is used when a token's issuer controls supply on multiple chains directly. Instead of wrapping, the token is burned on the source chain (reducing total supply there) and minted fresh on the destination chain. Circle's Cross-Chain Transfer Protocol (CCTP) for USD Coin (USDC) operates this way. Because Circle itself authorizes the mint, there is no pool of locked tokens for an attacker to steal, but you are trusting Circle entirely.
Liquidity Pool bridges like those used by Hop Protocol and Across Protocol work differently. Instead of locking assets and minting representations, they rely on liquidity providers who hold the native token on both sides. A user deposits on the source chain, and a liquidity provider on the destination chain sends them the equivalent native token immediately. The LP is then reimbursed through the protocol. This approach is faster and avoids wrapped tokens, but depends on adequate liquidity and introduces LP counterparty risk.
Light-Client Verification is the most trust-minimized design and the hardest to build. Here, the destination chain runs a cryptographic proof of the source chain's consensus directly inside a smart contract or ZK circuit. No external validator committee is required, the math proves the deposit happened. IBC (Inter-Blockchain Communication), the bridge standard used across Cosmos (ATOM) chains, approximates this model. ZK-based bridges like Succinct's SP1 and Polyhedra's zkBridge push this further using zero-knowledge proofs to verify state transitions cheaply.
Also Read: HIVE Just Borrowed $115M At Zero Percent To Bet Against Bitcoin Mining
Why Bridges Concentrate So Much Risk
The attack surface of a bridge is fundamentally different from the attack surface of a single blockchain. A chain like Ethereum is secured by hundreds of billions of dollars in staked ETH and hundreds of thousands of validators. Compromising it requires compromising a large fraction of that validator set simultaneously, an almost impossibly expensive attack.
A bridge validator set is often much smaller. The Ronin bridge, which served the Axie Infinity game on its own sidechain, was secured by just nine validator nodes. An attacker needed control of five of them to authorize withdrawals. Lazarus Group, the North Korean state-sponsored hacking organization, compromised five private keys through a combination of phishing and a fake job offer. They authorized $625 million in fraudulent withdrawals. The underlying Ethereum and Ronin chains were never touched.
The Ronin hack did not break a blockchain. It broke a nine-of-nine validator committee where five keys were held insecurely. The bridge was the weakest link by design.
This is the structural problem with externally-validated bridges. Their security is not inherited from the chains they connect, it is a separate, often smaller, and often less battle-tested system. The more value a bridge holds, the more attractive it becomes as a target, but the security model does not automatically scale with the assets under custody.
The Wormhole exploit in February 2022 was different in mechanism but similar in outcome. An attacker found a bug in Wormhole's Solana smart contract that allowed them to fake a "guardian signature verification" event. They convinced the contract that 120,000 ETH had been deposited on Ethereum when it had not, and minted $320 million in wrapped ETH on Solana. No validators were compromised. The vulnerability was in the contract logic itself. Jump Crypto, Wormhole's backer, replaced the funds within 24 hours, which prevented a market collapse but did not undo the underlying flaw.
Also Read: Polymarket Users Lose $3.1M In Frontend Attack As CFTC Probe Continues
How Validators And Oracles Fit In
Most bridges that aren't pure light-client systems rely on some form of external observer to confirm that a deposit happened and to authorize the corresponding mint or release.
These observers go by different names — validators, relayers, guardians, attestors — but they perform the same function: watching one chain and reporting state to another.
The trust question is always: what does it take to make these observers lie?
In a multisig model, the answer is "compromise enough keys." In an oracle-based model, the answer might be "manipulate the price feed or block data the oracle reports." In a proof-of-stake validator model, the answer is "acquire enough stake to control a supermajority."
LayerZero uses a model where each application configures its own set of oracles and relayers, creating application-specific security rather than a shared bridge validator set. This shifts the risk from "one bridge fails, everything fails" to "each application bears its own risk," which is a meaningful improvement for isolation but puts more responsibility on developers to configure security correctly.
Axelar uses a proof-of-stake network of its own validators to observe cross-chain events. The security of the bridge is therefore tied to the value of Axelar's own token staked by validators, a similar model to a Layer 1 blockchain, but scoped to cross-chain messaging.
The fundamental challenge is that you cannot natively verify a foreign chain's state without running that chain's full node, which is expensive. Light-client and ZK approaches solve this cryptographically. Everything else involves trusting an intermediary to report honestly.
Also Read: Is Ethereum Headed For $1,000 After Losing Key Support?
How ZK Proofs Are Changing Bridge Security
Zero-knowledge proofs are the most promising long-term solution to the bridge trust problem. A ZK proof allows one party to prove to another that a statement is true, such as "this transaction was included in a finalized block on Ethereum", without the verifier having to replay all the computation themselves.
Applied to bridges, this means a destination chain can verify a source chain event cryptographically, without trusting any external validator. The proof itself is the attestation. A compromised validator cannot forge a valid ZK proof. There are no private keys to steal. The security derives from the math.
The practical challenge is computation cost. Generating ZK proofs for full chain consensus (like Ethereum's Proof of Stake BLS signature aggregation over thousands of validators) requires substantial computational work, though this cost has dropped dramatically as ZK proving technology has matured. Teams like Succinct Labs, =nil; Foundation, and Polyhedra are building proving systems specifically optimized for blockchain state verification.
TAC, the Layer 1 trending now on CoinGecko, takes a specific approach to this problem: it bridges Ethereum's EVM developer ecosystem to the TON (The Open Network) and Telegram user base, using a hybrid validator and proof model. Projects like TAC illustrate the practical demand for bridges, Telegram has roughly 950 million monthly active users, and connecting that audience to Ethereum-compatible applications requires exactly the kind of cross-chain infrastructure that bridges provide.
The tradeoff with ZK bridges today is latency. Generating a proof for a finalized Ethereum block can take minutes. For applications requiring fast finality, optimistic bridges with fraud-proof windows are still often preferred, accepting a longer withdrawal delay (typically 7 days on major optimistic rollups) in exchange for simplicity.
Also Read: Chainlink’s Wallet Record Turns LINK’s $9 Rebound Into The Main Test
Native Bridges Versus Third-Party Bridges
When you move assets between a Layer 1 and its Layer 2 rollup, you are typically using a "native bridge", a bridge built and maintained by the rollup team itself, deeply integrated with the rollup's own security model. Arbitrum (ARB)'s native bridge, Optimism (OP)'s native bridge, and zkSync's native bridge all fall into this category.
Native bridges inherit much of the rollup's own security guarantees. On an optimistic rollup, a fraudulent withdrawal can be challenged during the 7-day fraud proof window. On a ZK rollup, a withdrawal is only finalized once a valid ZK proof of the transaction batch is posted to Ethereum. These are meaningfully stronger guarantees than most third-party bridges.
The trade-off is that native bridges only go one direction: from L1 to L2 and back. They cannot bridge Ethereum assets to Solana, or move assets across two separate L2s directly. For cross-ecosystem movement, Ethereum to Solana, or Arbitrum to Polygon (POL), users must use third-party bridges, which carry the validator and smart contract risks described above.
This creates a practical taxonomy: use native bridges for L1-to-L2 movement when security is the priority, and use audited third-party bridges with track records for cross-ecosystem movement when you accept the additional risk. Checking whether a bridge has been audited by a reputable security firm (Trail of Bits, OpenZeppelin, Certik, Spearbit) and reviewing any prior exploit history is the minimum due diligence before using any cross-chain transfer service.
Also Read: Russian Hackers Found A Signal Weak Spot In Recovery Keys
Who Actually Needs To Use A Bridge
Bridges are not necessary for most casual crypto users. If you hold Bitcoin (BTC) or Ethereum (ETH) on a centralized exchange and simply want exposure to price movement, you never touch a bridge at all.
You need a bridge when you want to use an application that lives on a different chain than where your assets are. If your ETH sits on Ethereum mainnet but you want to use a DeFi protocol on Arbitrum, you bridge to Arbitrum's native bridge. If you want to use a Solana-native application with USDC that started on Ethereum, you use a third-party bridge.
Developers building cross-chain applications are the heaviest bridge users. Any protocol that wants to aggregate liquidity across multiple chains, or any game that wants to let players use assets across different networks, needs bridging infrastructure baked into the product. This is why projects like LayerZero, Axelar, Wormhole, and Hyperlane position themselves as "omnichain messaging protocols" rather than just bridges: they are infrastructure for developers, not just end users moving tokens.
For regular users, the practical guidance is straightforward. Use canonical native bridges when moving between L1 and a major L2. For third-party bridges, limit exposure to what you are willing to lose, check the audit history, and prefer bridges that have operated without incident for at least a year under meaningful TVL. The "bridge slowly, bridge small" approach is not timidity, it reflects the honest risk profile of the technology as it exists today.
Also Read: Claude Fable 5 May Return As Washington Softens Anthropic Standoff
Final Thoughts
Cross-chain bridges solve a real and unavoidable problem.
Blockchains are sovereign systems. Without bridges, crypto would be a collection of isolated silos where assets and applications never interact.
The interoperability that bridges enable underpins most of DeFi, gaming, and the multi-chain ecosystem that projects like TAC are actively building into.
The hacks aren't evidence that bridges are inherently broken.
They're evidence that early bridge designs made aggressive security trade-offs — small validator committees, unaudited smart contract logic, oracle dependencies — that weren't proportionate to the value they came to hold.
Each major exploit has pushed the industry toward better designs: larger validator sets, formal verification, ZK-based proof systems, and native rollup bridges that inherit L1 security directly.
Read Next: PUMP Gains 12% While Protocol Data Warns The Rebound May Be Fragile