What a crypto bridge actually does, and why it has to hold your money
A crypto bridge is a piece of infrastructure that lets you move a token from one blockchain to another. If you hold ETH on Ethereum mainnet but want to use it on Solana to trade a token that lives there, you don't have to sell the ETH, withdraw to a bank, and rebuy on the other side. Instead, you send your ETH to a bridge, and on the other end you receive a "wrapped" version that represents your deposit on the new chain.
To make this work without a trusted middleman, bridges almost universally use some form of a lock-mint or burn-mint model. Your original ETH is locked in a smart contract on the source chain (or burned, which is functionally the same — the supply is destroyed), and an equivalent amount of "wrapped" ETH (often called WETH, or for cross-chain variants like Wormhole's, a wormhole-wrapped ETH) is minted on the destination chain. To go back, you burn the wrapped token, and the contract releases (or remints) the original on the home chain.
This design is elegant, but it has a structural consequence that non-crypto people often miss: at any given moment, the bridge is sitting on top of every token users have ever deposited. A bridge that has processed a billion dollars of volume might have $300 million in custody at peak. That custody lives in a smart contract — and that single contract is the entire attack surface. Steal the keys, compromise the validators, or find one bug, and you walk off with the lot. Compare that to a regular DEX (decentralized exchange) like Uniswap, where liquidity is spread across thousands of independent pools and an attacker draining one pool doesn't compromise the others. Bridges concentrate risk the way almost nothing else in crypto does.
Why bridges keep getting hacked: the three structural weaknesses
When you read about a bridge exploit — and there have been many — the post-mortems usually describe a specific bug or a specific compromised key. But underneath every one of them is the same trio of structural weaknesses. They are what make bridges uniquely attractive targets.
Bridges custody enormous value in a single contract. The lock-mint model means the bridge contract on the source chain holds the real assets, and the wrapped tokens on the destination chain are claims against that pool. If you mint on chain B without a real lock on chain A, you've created unbacked wrapped tokens that will collapse in price the moment users try to redeem. So the entire security model of the bridge collapses onto that one contract, plus the minting authority on the other side. A billion-dollar DEX is, in attacker terms, a thousand million-dollar honeypots. A billion-dollar bridge is one billion-dollar honeypot.
Bridge contracts are hard to upgrade once they hold real money. You might think: "Just patch the bug." In theory, yes. In practice, bridge contracts are intentionally non-upgradeable, because the entire point of a trust-minimized bridge is that no single party can change the rules after you deposited. If the deployer held an upgrade key, they could rug the depositors in one transaction. So the contracts are immutable — and immutable contracts cannot be patched when a vulnerability is discovered. The bug you shipped in 2021 is the bug that gets exploited in 2024, because there is no central party with the authority to fix it without breaking user trust.
The validator set guarding the bridge is smaller and weaker than the chains it connects. This is the most underappreciated point. Ethereum mainnet is secured by hundreds of thousands of validators. Solana has thousands. A typical bridge might be guarded by a 5-of-9 multisig (a wallet that requires five out of nine pre-approved signers to approve any action), or a small validator set that you can enumerate on-chain. Attackers study these sets the way bank robbers study guard schedules. If five of those nine keys are held by the same team, or if the keys are stored on a hot server somewhere, or if the multisig members don't even know each other, the bridge has effectively centralized its security model down to a handful of humans — and humans, as Ronin demonstrated, can be phished.
How the lock-mint model gets attacked in practice
Once you understand the lock-mint model, the attack patterns start to look like variations on a theme. The attacker doesn't need to break the underlying chain. They need to break one of three things: the source-chain contract holding the deposits, the destination-chain contract that mints the wrapped tokens, or the off-chain infrastructure that signs cross-chain messages.
Smart-contract bugs in the lock or mint logic. The classic case is Wormhole in February 2022. Wormhole was a popular bridge between Ethereum and Solana that let users deposit ETH on Ethereum and receive wrapped ETH on Solana. The attacker found a bug in Wormhole's Solana-side code: a function that the bridge used to verify that a deposit had really happened on Ethereum was using an outdated "signature set" account that the attacker could replace with a fake one. With a fake signature in place, the attacker convinced the Solana contract to mint 120,000 wrapped ETH — worth about $320 million at the time — without ever locking any real ETH on Ethereum. When the dust settled, users holding the wrapped token on Solana discovered their "ETH" had no backing, and the Wormhole team had to inject capital from its treasury to make depositors whole. The bug was in the code, not the keys, but the structural effect was identical.
Validator-set compromise. If an attacker can collect enough of the keys or signer slots that approve cross-chain messages, they don't need a bug at all. They simply sign a fraudulent message themselves, and the bridge dutifully releases funds. The Ronin bridge hack in March 2022 is the canonical example. Ronin was an Ethereum sidechain built for the play-to-earn game Axie Infinity, and its bridge was secured by a 5-of-9 multisig. Five of those nine signers were run by the same team (Sky Mavis, the developer of Axie). The attackers compromised four Sky Mavis signers plus a fifth partner, and walked off with around $625 million in USDC and ETH. They didn't break any cryptographic primitive — they just had access to enough legitimate signers.
Burn-mint race conditions and replay bugs. In a burn-mint model, where tokens are destroyed on one chain and reminted on another, an attacker can sometimes trick the bridge into processing the same burn twice, or processing a burn without actually waiting for the cross-chain confirmation. The Nomad bridge hack in August 2022 was a version of this: a routine contract upgrade accidentally marked every message as valid, so anyone could call the bridge and withdraw funds as if they had deposited. Roughly $190 million was drained by opportunistic copycats before the bridge was shut down.
Famous bridge hacks, and what each one teaches
Reading the post-mortems of famous bridge hacks is one of the fastest ways to internalize the threat model. Each one demonstrates a different weakness in the same general design.
Wormhole, February 2022 — ~$320 million. Cause: a signature-verification bug on the Solana side that allowed the attacker to mint unbacked wrapped ETH. Lesson: even well-audited code can have logic flaws in how it interprets cross-chain messages. The fact that the bridge worked perfectly for years didn't mean it was safe.
Ronin, March 2022 — ~$625 million. Cause: compromise of five of nine multisig keys via social engineering and a compromised partner infrastructure. Lesson: validator decentralization on paper is not the same as validator decentralization in practice. Sky Mavis controlled most of the signers "just for convenience" and that concentration was what got exploited.
Harmony Horizon, June 2022 — ~$100 million. Cause: compromise of a 2-of-5 multisig protecting the bridge, via compromised hot-wallet keys. Lesson: multisigs with very low thresholds and hot-wallet key storage are barely better than a single signer.
Nomad, August 2022 — ~$190 million. Cause: a contract upgrade that accidentally allowed arbitrary withdrawals. Lesson: bridge contracts that are designed to be upgradable can also be upgraded into a vulnerable state. Immutability cuts both ways.
Add up just those four incidents and you get over $1.2 billion in losses, in a single year, from a single category of protocol. For comparison, every other category of crypto hack combined — DEXs, lending protocols, wallets, individuals — does not destroy capital at that rate relative to TVL (total value locked, the value of assets deposited in a protocol).
Validator-set compromise vs smart-contract bug: which is more common?
Smart-contract bugs get more press because they read like puzzles. A missed zero check, an outdated Merkle root, a reentrancy guard that doesn't fire — these are the things auditors highlight, and they're the things developers work on fixing. Validator compromise is messier. It involves humans, internal processes, off-chain infrastructure, and sometimes nation-state attackers. But if you tally the dollar losses, validator compromise has historically been the larger category by a wide margin.
The Ronin, Harmony, and several smaller heists were essentially "whoever controls the signers controls the bridge" exploits. The attackers did not need to find a clever code path; they needed a key. That means defending against them requires a different toolkit than defending against smart-contract bugs: hardware security modules (specialized hardware devices designed to keep private keys offline and resistant to tampering) instead of hot wallets, geographically distributed signers, threshold cryptography (where a private key is split into many shares such that no single device or person ever holds the full key) instead of static multisigs, and continuous monitoring of signer activity. None of these measures are purely on-chain, which is why a lot of security-minded bridges have moved toward decentralized oracle networks (services that bring real-world or cross-chain data on-chain using many independent nodes, like Chainlink's LINK-powered network) and dedicated validator pools to spread trust more broadly.
Cross-chain messaging protocols like LayerZero and Chainlink's CCIP (Cross-Chain Interoperability Protocol) are an attempt to make this less painful. Instead of each bridge rolling its own validator set, they outsource message verification to a larger, more battle-tested network — in CCIP's case, the Chainlink oracle network, which is designed to require compromise of many independent node operators to forge a message. The trade-off is that you've traded a small bridge-specific trust assumption for a larger network-wide trust assumption, and you should understand what that network's failure modes look like before relying on it.
Shared security and CCIP as an alternative direction
The honest read on the bridge problem is that no design removes the trust assumption — it only moves it around. A bridge that uses a small validator set trusts those validators. A bridge that uses an oracle network trusts the oracle network. A bridge that uses light clients (programs on one chain that independently verify the block headers of another chain, removing the need for external relayers) trusts that the cryptography and implementation are sound. A bridge that uses a hash-based lock (the user locks funds in a hashlock on one chain and reveals a secret to claim them on the other, the basis of atomic swap protocols) trusts that liquidity exists on the receiving side.
Shared security is the latest attempt to thread this needle. The idea is that instead of each bridge maintaining its own bespoke validator set, validators from a large, decentralized network — or from the underlying chains themselves — are reused for cross-chain verification. Chainlink's CCIP is the most prominent example in production today: rather than running a parallel set of signers, the bridge leans on Chainlink's existing oracle infrastructure plus a separate Risk Management Network as a second layer of defense. The economic argument is that attacking CCIP would require compromising both the oracle network and the risk network, which is more expensive than attacking a single bridge's multisig.
This is a real improvement, but it is not a panacea. CCIP inherits the trust assumptions of Chainlink's oracle network. If that network is compromised, CCIP is compromised. If a new shared-security model emerges and 80% of bridges adopt it, that model becomes a single point of failure for the entire cross-chain ecosystem. There's a reason seasoned DeFi users still split large transfers across multiple routes and don't trust any one bridge with life-changing amounts.
How to assess a bridge before using it
There is no "safe bridge." Anyone who tells you otherwise is selling something. But there are bridges that are more or less risky, and a few questions that materially shift the risk you take on. Treat this as a checklist, not a guarantee.
How is custody distributed? Look at the on-chain admin and signer set. A 2-of-5 multisig is dramatically riskier than a 12-of-20 setup. Look at whether the signers are independent entities or arms of the same team. Look at how the keys are stored — hot wallets on a cloud server are a red flag; hardware wallets distributed across geographies are better.
Are the contracts upgradeable, and by whom? Immutability cuts both ways. An immutable contract cannot be patched, which means a bug stays a bug forever. An upgradeable contract can be patched, which means a malicious or compromised key holder can also change the rules. Read the documentation to understand exactly what upgrade powers exist and who holds them.
Has it been audited, and by whom? An audit is not a guarantee. A single audit from a mid-tier firm is not the same as multiple audits from top-tier firms plus a public bug bounty. Look for the audit reports, see what was found, and see how the team responded to findings.
How long has it been in production, and how much volume has it processed? A bridge that has moved $20 billion over three years and never been exploited has some empirical track record. A bridge that launched last week has no track record at all, regardless of how well-marketed it is.
What's the worst-case failure mode? Read the post-mortems of past incidents and think through: if the bridge is hacked tomorrow, how do users get made whole? Is there an insurance fund? Does the protocol have a treasury large enough to cover losses? If the answer is "nothing," you should treat your deposit as 100% at risk the moment it lands.
How to follow bridge exploits the smart way
Bridge exploits move fast — by the time a post-mortem lands on a blog, the next incident is already brewing. Tracking which bridges are being audited, which are launching, which have had recent security incidents, and how the cross-chain space is evolving is a full-time job if you do it manually. Zippfeed surfaces bridge and interoperability headlines with sentiment scoring (bullish, neutral, or bearish) and an importance rating, so you can spot meaningful signals without reading every thread yourself. That way, when a new "audited" bridge launches or a familiar name appears in a security advisory, you see it in context — not in the panic of the post-hack tweet storm.
