In 2026, tracked cross-chain bridge exploits — from KelpDAO’s $292M LayerZero incident in April to THORChain’s $10.7M validator-key compromise in May — pushed the year’s running bridge-hack toll into the $300M-plus range across roughly a dozen major incidents. Not one of them touched a deposit-based instant swap, because that model never signs a bridge contract, mints a wrapped asset, or asks a validator set to authorize a release on your behalf. This guide breaks down exactly where bridge attack surface lives, what went wrong in 2026’s biggest incidents, and what a deposit-based swap trades away in exchange for skipping that risk.
What a bridge actually is — and where the attack surface lives
A cross-chain bridge lets you move value from chain A to chain B without a centralized exchange in the middle. Mechanically, most bridges do one of two things: lock your asset on the source chain and mint a wrapped representation on the destination chain, or burn/release from a liquidity pool on each side. Either way, something has to verify that a legitimate deposit happened before releasing funds on the other end — and that verification step is where almost every major exploit lives.
Break it into three categories, because each fails differently:
Smart-contract mint/burn logic. The contract that decides how much to release based on how much was deposited. If the validation logic has a gap — for example, not checking that the value committed on the source chain actually matches the payout claimed on the destination chain — an attacker can mint or claim far more than they put in.
Validator or multisig custody. Many bridges don’t use pure math to authorize releases; they use a set of validators or a multisig that signs off on each transaction using threshold cryptography. If an attacker can join that validator set, or extract enough signing material from the threshold scheme, they can authorize fraudulent releases directly — no contract bug required.
Message verification / forged messages. Bridges built on generic messaging layers rely on a verifier (or a small set of verifiers) to attest “yes, this event really happened on the source chain.” If that verification path is thin — a single verifier, or infrastructure the bridge doesn’t fully control — an attacker who compromises the verifier’s data feed can get the destination side to release funds against an event that never happened.
Every bridge exploit in 2026 mapped cleanly onto one of these three categories. None of them required a brand-new class of attack — they exploited gaps that auditors and operators already knew, in principle, to look for.
Bridge hacks in 2026: what actually went wrong
Three incidents illustrate the categories above, and all three are independently documented.
KelpDAO / LayerZero — ~$292M, April 18–19, 2026 (message verification). Attackers compromised two RPC nodes that KelpDAO’s verifier relied on, replacing the node software to selectively feed forged transaction data while returning truthful data everywhere else, then DDoSed the honest endpoints to force failover onto the poisoned nodes. The bridge used a 1-of-1 DVN (decentralized verifier network) setup — LayerZero Labs as the sole verifier — so once that single verification path attested to a fabricated deposit, the bridge released 116,500 rsETH against a transaction that never happened, in under 46 minutes. KelpDAO’s own incident report and reporting from Cointelegraph confirm the mechanics; attribution points toward North Korea’s Lazarus Group.
THORChain — $10.7M, May 15, 2026 (validator/vault custody). A node operator that had churned into THORChain’s validator set two days earlier spent that window in routine signing ceremonies, quietly reconstructing one vault’s full private key from leaked cryptographic material in THORChain’s GG20 threshold-signature implementation. With the key reconstructed, the attacker no longer needed the multi-party signing ceremony at all — they signed and broadcast outbound transactions directly from one of five vaults. THORChain’s own exploit report details the root cause: the network’s GG20 fork had skipped proof checks that validate how the threshold key material was formed. Node operators halted the network within roughly two hours; it stayed offline for about five weeks.
Verus–Ethereum bridge — ~$11.6M, May 2026 (smart-contract mint/burn). Per Halborn’s writeup, the bridge validated cryptographic proofs on both sides but never checked that the economic value committed on the Verus side actually matched the payout being claimed on Ethereum. The attacker forged a cross-chain import payload that passed every signature check while committing close to zero real value on the source chain, and walked away with tBTC, ETH, and USDC worth roughly $11.6M — turning about $10 in fees into a seven-figure payout.
Different root causes, same shape: a verification step that should have been airtight had a gap, and the gap was worth eight or nine figures.
Three risk categories, mapped to what you actually do
The three technical categories above map fairly directly onto three things a user might actually click through:
(a) A DEX or bridge that requires wallet-connect and contract approval. You sign a transaction that gives a smart contract standing permission to move your assets. That approval — plus the bridge contract’s own mint/burn logic — is exactly the surface exploited in the Verus case. Revoking approvals after use reduces, but doesn’t eliminate, this exposure.
(b) A chain-abstraction protocol with validator or vault custody, the THORChain model: your funds pass through a decentralized but not infinite validator/vault set that has to sign off on movements using threshold cryptography. You’re trusting the math of the threshold scheme and the honesty of whoever churns into the validator set next.
(c) A deposit-based instant swap. You send funds to a one-time deposit address; the provider executes the trade and sends the result to your destination address. No contract approval, no validator set authorizing your transaction, no cross-chain message that needs verifying — because there’s no cross-chain message at all in the bridge sense. This is the /exchange/ flow.
Each category has a different owner for the risk. (a) and (b) put contract code and a validator set in the critical path for every single transaction that flows through them, indefinitely. (c) puts a specific provider’s execution in the critical path for the few minutes your swap takes.
Why a deposit-based swap skips bridge attack surface — and what it costs you instead
A deposit-based swap structurally can’t suffer a forged-message or validator-key exploit, because there’s no message to forge and no validator set signing off on a release. You’re not connecting a wallet, not granting a contract approval, and not relying on a liquidity pool that has to balance mint against burn across two chains. Swapping without connecting a wallet removes an entire category of persistent, standing risk that a bridge or DEX approval creates.
That’s a real, structural difference — not a claim that this model is safer in some absolute sense. It carries its own trade-off, and being straight about it matters:
A deposit-based swap trades bridge attack surface for provider-execution trust. You’re not signing a contract, but for the few minutes your swap takes, your funds are in the provider’s hands, not yours — and on private routes, they pass through an additional XMR hop between two providers.
That custody window is short — typically minutes, not the standing exposure a bridge carries for as long as it holds a liquidity pool — but it’s not zero. You’re trusting the provider to execute correctly and settle at the promised rate, the same way you’d trust any counterparty in a trade. On private routes, there’s an added layer: funds hop through Monero between two providers to break the on-chain link, which means an additional point where execution has to go right. If you want the deeper mechanics of how that privacy hop is engineered — and where its own risks live — see our breakdown of a real-world Monero privacy-vs-security incident.
The honest framing: a bridge asks you to trust code and a validator set, indefinitely, for as long as your funds sit inside it. A deposit swap asks you to trust one provider’s execution, for a few minutes, once. Different risk, different time horizon — not “no risk.”
A checklist: evaluating any cross-chain method before you use it
Before moving meaningful size through any cross-chain route — bridge, chain-abstraction protocol, or swap — run through this:
- Identify the attack-surface category. Smart-contract mint/burn, validator/vault custody, or message verification. Each fails differently, so knowing which one you’re exposed to tells you what to check next.
- Check for wallet-connect and approval requirements. A method that only needs a deposit address carries less standing exposure than one that needs a contract approval.
- Look up the protocol’s track record. SlowMist Hacked and PeckShield’s incident feeds are the standard references — search the protocol name before you commit funds, not after.
- Default to a deposit-based swap for one-off conversions. If you just need coin A on one chain to become coin B on another, once, a bridge is often more exposure than the job requires.
- Send a small test amount on unfamiliar routes. A few minutes of delay is cheap insurance against an address or network mistake.
- Verify address, network, and memo fields carefully. This is where the remaining risk actually sits for deposit-based swaps — not in a contract exploit, but in an unrecoverable human error. Crypto transactions don’t reverse.
- Know exactly who you’re trusting. A bridge: its contract code plus its validator/verifier set. A deposit swap: the provider’s execution, plus an intermediate hop on private routes. Neither is trustless — pick the model whose trust assumptions you actually understand.
For a broader comparison of how deposit-based aggregators, DEXs, and centralized exchanges stack up on this exact trade-off, see DEX vs CEX vs swap aggregator.
When you still need a bridge — and how to lower the risk
None of this is an argument against bridges in every case. If you need an asset to live natively on a destination chain long-term — for LP positions, for a DeFi protocol that only accepts native tokens, for ongoing use inside an ecosystem — a one-time swap doesn’t solve that; you need the asset to actually exist on that chain, which is what a bridge is for.
If a bridge is genuinely the right tool, a few things measurably lower the risk:
- Prefer bridges with published, recent audits from firms with a track record (not just a logo on the site) — and check whether the audit covered the specific verification path involved in 2026’s incidents, not just the contract’s happy path.
- Prefer native mint/burn over wrapped-asset liquidity pools where available — fewer moving parts means fewer places for a mismatch like Verus’s to hide.
- Check verifier diversity, not just validator count. KelpDAO’s exposure came specifically from a 1-of-1 verifier setup; a bridge with multiple independent verification paths doesn’t fail the same way from one compromised node.
- Send a test transaction first, same as with a swap — it costs a few minutes and confirms the route actually works before you commit real size.
If you compare specific cross-chain swap platforms against bridge-dependent alternatives, our rundown of THORChain alternatives walks through which routes carry bridge-style risk and which don’t.
Ready to move value across chains without routing through a bridge contract? Start a swap on SwapZilla and see the deposit-address flow for yourself.