Why Cross-Chain Bridges Keep Getting Hacked
Bridge hacks took $328M in 2026 and the biggest never touched a smart contract. Why the verifier is the real weak point.
Cross-chain bridges keep getting hacked because they concentrate enormous value behind a verification step that is usually simpler than the money it guards. In the first four and a half months of 2026 alone, attackers took "$328.6 million from cross-chain protocols" across eight major incidents, according to PeckShield data reported by Crypto Times — and the largest of them did not involve a broken smart contract at all. Understanding the pattern matters because bridging is unavoidable for most multi-chain users, and the risk varies enormously depending on which kind of bridge you pick.
What a bridge actually does — and why that is the problem
A bridge does not move your token. It locks or burns the asset on one chain and issues a claim on the other, and something has to verify that the first half really happened before the second half executes.
That verifier is the whole security model. It might be a set of validators signing off, a light client checking proofs, or an oracle network relaying messages. Whatever it is, it sits between "your tokens are locked here" and "release tokens there" — and every dollar bridged through the system piles up behind it. Our explainer on how cross-chain bridges work covers the mechanics in more detail.
Two structural facts follow. First, a bridge's pooled liquidity is a concentrated, standing target holding funds from many chains at once. Second, defeating the verifier does not require breaking cryptography — it requires convincing the system that a deposit occurred. Those two together explain why bridges have produced a disproportionate share of crypto's largest single-incident losses.
The three ways bridges actually get drained
Nearly every major bridge exploit falls into one of three categories, and only one of them is a classic smart contract bug.
| Attack | What the attacker does | Real example |
|---|---|---|
| Key compromise | Obtains enough validator signing keys to meet the quorum, then authorizes a legitimate-looking withdrawal | Ronin ($625M, March 2022); AFX Trade ($24M, July 2026) |
| Forged or unverified message | Gets the destination chain to accept a message about a deposit that never happened | Wormhole ($325M, February 2022); Kelp DAO ($292M, April 2026) |
| Contract logic flaw | Exploits a bug in the bridge's own code — an initialization error, a missing check | Nomad ($190M, August 2022) |
Figures for the 2022–2023 incidents are from Eco's bridge hack history, which puts documented bridge losses at more than $2.5 billion since 2021, alongside Harmony Horizon ($100M, June 2022) and Multichain ($231M, July 2023).
The uncomfortable detail is that key compromise and message forgery — the two biggest categories — are not really coding problems. They are operational and design problems, which is why a clean audit report offers less protection here than people assume.
The $292M exploit where nothing was broken
The Kelp DAO exploit of 18 April 2026 is the clearest illustration of how a modern bridge fails. Attackers took roughly $292 million (116,500 rsETH), making it 2026's largest crypto exploit, and they did it without exploiting a single line of contract code.
According to Chainalysis's post-mortem, the attackers compromised two RPC nodes hosted by LayerZero and knocked out one of the external RPC nodes with a DDoS attack, forcing the system to rely on the nodes they controlled. The bridge was verified by a single decentralised verifier network (DVN) — a 1-of-1 setup, with no independent second opinion required. With that verifier fed false data, the Ethereum contract released rsETH against a token burn that never happened on the source chain. Chainalysis's summary of why nobody caught it in time is the line worth remembering: "On-chain, the transactions looked clean."
Chainalysis reports that LayerZero attributed the attack to North Korea's Lazarus Group, specifically the sub-group known as TraderTraitor, and that Kelp blocked a follow-up attempt to drain a further 40,000 rsETH — around $95 million — using a second forged message.
The aftermath is instructive too. LayerZero initially pointed at Kelp, then publicly acknowledged it had "made a mistake" in allowing its own verifier network to secure high-value assets in that configuration, per CoinDesk. Kelp moved its rsETH bridge to Chainlink's CCIP. The lesson for a user is blunt: a bridge's headline brand tells you very little, because the actual risk lives in a configuration setting most users never see.
Three months later the pattern repeated in the older style. AFX Trade lost $24.15 million in USDC on 22 July 2026, and the mechanics are worth spelling out: security firm Blockaid found that "five of the bridge's hot-validator signatures" authorized the transfer, meeting the required two-thirds quorum, per CoinDesk. From the system's point of view nothing anomalous happened — the signatures were valid, they simply belonged to an attacker. Notably, Arbitrum's own native bridge was not involved; this was AFX Trade's bridge running on Arbitrum, which is exactly the distinction the risk tiers below are about.
Why audits do not solve this
Audits check the code, and in the two largest attack categories the code did what it was written to do. That is the core mismatch.
An auditor can confirm that a contract releases funds when the verifier says a deposit happened. Whether the verifier can be lied to — through a stolen key, a compromised node, a quorum set too small, an off-chain process nobody reviewed — often sits outside the audit's scope. As Halborn's breakdown of the Kelp incident put it, the attackers "didn't attempt to compromise the verifier" at all; they went after the RPC nodes feeding it data, not the smart contract logic the auditors read.
This is not an argument against audits. It is an argument for reading a bridge's trust model rather than its audit badge count.
Bridge risk tiers: not all bridges are equally exposed
Bridges differ enormously in how much trust they ask for. Eco's risk framework sorts them into four tiers, and the tier tells you more about your exposure than the brand does.
| Tier | Design | Trust assumption | Relative risk |
|---|---|---|---|
| 1 | Native first-party bridges run by the asset issuer, with no pooled liquidity (e.g. Circle's CCTP) | The issuer's own verification; "the bridge never holds wrapped IOUs" | Lowest |
| 2 | Optimistic and intent-based designs | Underlying chain plus a challenge period; relayer capital at risk | Low–medium |
| 3 | Federated validator bridges with fixed guardian sets (typically 13–21 nodes) | Enough validators must stay honest | Higher — historical exploits cluster here |
| 4 | Custodial wrapped tokens dependent on a single entity | The custodian stays solvent, unsanctioned and uncompromised | Highest |
The practical read: a canonical L2 bridge that inherits Ethereum's security — or a first-party issuer bridge at Tier 1 — is a genuinely different product from a third-party validator bridge that happens to serve the same route, even when both show you the same "Bridge" button.
How to bridge more carefully
You cannot eliminate bridge risk, but you can decide how much of it you are taking. Eco's checklist for assessing a bridge is a reasonable starting frame:
- Identify the trust model first. Burn-and-mint or canonical beats a multi-sig of unknown participants. If the site does not say who verifies transfers, treat that as the answer.
- Check the audit history — at least two independent firms within the last 12 months, rather than one report from three years ago.
- Look for a meaningful bug bounty. A $1M+ program signals the team is paying market rate for disclosure instead of hoping nobody looks.
- Weigh the operational track record. Three incident-free years is a materially different proposition from six months.
- Check for a backstop. Insurance or a treasury commitment changes what happens to you if it goes wrong.
Three habits worth adding on the user side:
- Size the transfer to the risk. Splitting a large move into tranches across time costs a little more in fees and removes the scenario where one bad minute takes everything.
- Avoid leaving value parked in wrapped assets you do not need. Wrapped tokens are claims on a backing pool; if that pool is drained, the claim is what is left.
- Revoke the approval afterwards. A bridge you used once has little reason to keep a standing allowance on your wallet — our guide to token approvals explains what that permission actually grants, and Coin98 Wallet Health scans your wallets for the ones you have forgotten.
If you bridge from within the Coin98 Super Wallet, SpaceGate is the built-in route — "a Cross-chain Bridge that enables swapping and transfers across multiple networks," currently covering C98 across Solana, Ethereum, BNB Smart Chain, Viction and Polygon, plus SAROS between Viction and Solana and VIC from Ethereum to Viction, with transfers typically completing in two to five minutes. Worth being clear about the trade-off: SpaceGate is an aggregator that routes through integrated bridge solutions, so the trust model of whichever bridge handles your transfer still applies. Aggregation improves routing and convenience; it does not remove the underlying verification risk that this article is about.
FAQ
Are crypto bridges safe to use in 2026? Bridges as a category remain one of crypto's highest-risk components — over $328 million was taken from cross-chain protocols in the first four and a half months of 2026, per PeckShield data. Individual bridges vary a lot, though. A canonical L2 bridge or a native burn-and-mint protocol carries meaningfully less trust risk than a federated validator bridge.
If a bridge gets hacked, do I lose my money? It depends on where your assets were at the time. Funds sitting in the bridge's pool or held as wrapped tokens backed by that pool are directly exposed. Assets you already bridged and moved on to another use are usually unaffected, unless the wrapped asset you hold is the one that lost its backing.
What was the biggest bridge hack? Ronin, at roughly $625 million in March 2022, remains the largest, per Eco's hack history. The largest of 2026 so far is the Kelp DAO exploit at about $292 million in April, which LayerZero attributed to North Korea's Lazarus Group.
Can a bridge be hacked without the smart contract being broken? Yes, and this is now the more common pattern. The Kelp DAO attack compromised off-chain infrastructure and fed false data to a single verifier, so the contract released funds correctly according to the information it received. Key compromises work the same way — the signatures are valid, they just belong to the wrong person.
Is it safer to use a centralized exchange to move between chains? It swaps one risk for another. A CEX transfer removes bridge verification risk but introduces custody risk and requires you to hand over control of the assets while the transfer happens. Neither is universally safer; the right choice depends on the size of the transfer and how much you trust the specific venue.
Do I need to do anything after a bridge transfer completes? Reviewing and revoking the token approval you granted is worth the couple of minutes it takes. A completed transfer does not close the permission, and an open allowance to a bridge contract is exactly the kind of thing worth clearing out if that bridge is later compromised.
The takeaway
Cross-chain bridges get hacked because their security depends on a verification step that is often thinner than the pile of money behind it — and because defeating that step rarely requires breaking any code. The 2026 record makes the point: the year's biggest exploit came from a single verifier being fed bad data, and July's came from stolen signing keys. What you can control is the tier of bridge you use, how much you move at once, and whether you leave approvals behind. If you bridge inside the Coin98 Super Wallet, SpaceGate handles the routing, and Wallet Health will show you which approvals are still open when you are done.
Last updated: July 2026