At 17:35 UTC on 18 April 2026, an attacker’s wallet called LayerZero’s EndpointV2 contract and Kelp’s bridge released 116,500 rsETH, about 292 million dollars, according to The Block’s reconstruction from the event logs. No matching deposit had ever been made on the other chain. Kelp’s emergency multisig paused the contracts 46 minutes later, and two further attempts of 40,000 rsETH each reverted.
Nothing in that transfer was a tunnel between two blockchains. A cross-chain bridge moves nothing at all: it lets a contract on chain B act on a claim about what happened on chain A. Someone has to vouch for that claim. In Kelp’s case a single verifier vouched for a deposit that did not exist. The rest of this lesson follows one question through every design: who signs off on the message, and what do you wait for or risk because of it.
Two reminders before going deeper. Each chain keeps its own ledger and cannot read another chain’s state by itself; the split between base layers and the rollups built on them is covered in our guide to layer 1 and layer 2 blockchains. Where the liquidity sits, chain by chain, was the subject of the previous lesson, where DeFi lives: chains compared. Moving between those chains is the job of a bridge, and this lesson sorts bridges into three families by who carries the trust.
Three questions to ask about any cross-chain transfer
Every cross-chain product, whatever its marketing, answers the same three questions. What is moved: the original asset, a wrapped copy, or a message that tells a contract to do something? Who verifies that the event on the source chain really happened: the destination chain itself, a set of signers, a single company, or a relayer who has put up its own money? And what does the user wait for: seconds, minutes or a week?
The answers group products into three families. Native or canonical bridges are run by the chain or the token issuer and verified by the chain’s own proof system or by the issuer. Third-party bridges and messaging networks are separate systems, verified by their own validator sets, committees or configurable verifiers. Intent systems let the user sign the result they want and let a filler deliver it first with its own capital, with settlement checked afterwards. Fees and speed differ, but the real difference is where the risk lands when something breaks.
Native bridges: slow withdrawals, secured by the rollup itself
A rollup’s canonical bridge is the contract pair that the rollup itself uses to move ETH and tokens between Ethereum and the layer 2. Deposits from Ethereum to the rollup are fast, because the rollup reads Ethereum directly. Withdrawals are the slow direction, because Ethereum has to be convinced that the rollup’s state is correct.
How a rollup withdrawal works, step by step
On an OP Stack chain such as OP Mainnet or Base, Optimism’s documentation describes three transactions. You initiate the withdrawal on the layer 2. Once a proposal covering that block has been posted to Ethereum, you prove the withdrawal on Ethereum with a Merkle proof against that proposal. Then you wait out the fault challenge period, 7 days on mainnet, and finalise. During the wait anyone can dispute the posted state through a fault dispute game; a withdrawal proven against a losing proposal cannot be finalised.
Arbitrum follows the same logic with different vocabulary. Its documentation on messages to the parent chain gives a dispute window of about 6.4 days (the same page also rounds it to about 7 days). Once the assertion is confirmed, anyone can execute the withdrawal through the Outbox contract with a Merkle proof. The message stays in the Outbox with no expiry, so a forgotten withdrawal can still be claimed later, but nobody executes it for you unless you pay a third-party service.
The week is the price of the security model. The canonical bridge trusts no outside signer: if the rollup’s posted state is wrong, the dispute game is meant to catch it before any money leaves. That is also why third-party services offer fast withdrawals. They pay you on Ethereum much sooner and take the seven-day wait, and the risk that comes with it, onto their own balance sheet.
CCTP: native USDC moved by burning and minting
Circle‘s Cross-Chain Transfer Protocol works differently because the issuer controls both ends. USDC is burned on the source chain, Circle’s attestation service signs that the burn happened, and native USDC is minted on the destination chain. No wrapped token is created and no smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">liquidity pool is involved. Circle launched the second version on 11 March 2025 with two features: Fast Transfer and Hooks, which trigger automated actions on the destination chain after the USDC arrives. Circle now calls that version simply CCTP; the first version is labelled legacy.
The speeds are on Circle’s CCTP developer page: about 8 to 20 seconds for a Fast Transfer and 15 to 19 minutes for a Standard Transfer from Ethereum and its layer 2s, with the fee taken from the amount sent. The supported-chains page listed 31 blockchains as of 28 October 2026. A Fast Transfer is quick because Circle signs its attestation once the burn is included in a block, without waiting for hard finality on the source chain; to cover the risk of a reorganisation, Circle caps these transfers with a global allowance, according to its page on finality.
CCTP is native, not trustless. The only verifier is Circle. For a stablecoin whose issuer already stands behind every token, that adds little new trust compared with holding USDC in the first place, and it avoids the wrapped copies that a lock-and-mint bridge would create. Circle has extended the same attestation service to EURC and to registered third-party tokens, but for most tokens no issuer-run route of this kind exists.
Where native bridges are weaker than they sound
Native does not mean equally safe everywhere. L2BEAT’s summary lists Arbitrum One, Base and OP Mainnet at Stage 1, not Stage 2; what each stage means for your funds is explained in the previous lesson. Some chains’ own bridges rest on a permissioned group: L2BEAT describes Hyperliquid’s bridge as validated by a permissioned set of Hyperliquid validators. The question is the same as for any bridge: who can approve a withdrawal, and how many of them would have to fail.
Size matters too. As of 28 October 2026, DefiLlama counts 3.31 billion dollars in the Arbitrum canonical bridge, 2.92 billion in Base’s and 0.64 billion in Optimism’s. Those balances back every bridged token on the layer 2, so a bug in the bridge contract would reach every holder at once.
Third-party bridges: lock-and-mint, burn-and-mint and liquidity networks
A third-party bridge is a separate system that sits between two chains it does not control. Ethereum.org’s bridge page sorts them by mechanism. Lock-and-mint locks the original asset in a contract on chain A and mints a wrapped copy on chain B; the copy is only as good as the lock. Burn-and-mint destroys tokens on one chain and creates them on the other, which suits tokens whose issuer deploys natively on several chains. Liquidity networks hold real tokens on both sides and swap your asset on A for the same asset on B out of their own pools, so you receive the native token rather than a copy.
The same page draws the line that matters for risk: trusted bridges rely on an outside group (a multisig federation, an MPC network, an oracle network) to report what happened, while trustless bridges rely only on the connected chains and their proofs. Most bridges in use are on the trusted side. That is also why bridges are attractive targets: the lock contract holds the collateral behind every wrapped token on the other side, so a single flaw can empty a pool that backs many positions.
staking or liquidity, measured at current market prices. It is the main size metric in DeFi.">Locked value gives a rough sense of where the trust sits. The figures below are tokens held in bridge contracts, not transfer volume, which DefiLlama sells only in its paid plan. Burn-and-mint systems such as CCTP hold almost nothing by design, and intent systems hold little because fillers use their own capital.
| Bridge (DefiLlama name) | Type | Locked value, 28 October 2026 |
|---|---|---|
| LayerZero V2 | Messaging, tokens held by apps built on it | 16.73 billion dollars |
| WBTC | Custodial wrapped bitcoin | 9.48 billion dollars |
| Arbitrum Bridge | Canonical rollup bridge | 3.31 billion dollars |
| USDT0 | Omnichain USDT | 3.21 billion dollars |
| Base Bridge | Canonical rollup bridge | 2.92 billion dollars |
| Chainlink CCIP | Messaging and token pools | 1.99 billion dollars |
| Portal (Wormhole) | Messaging, lock-and-mint | 1.52 billion dollars |
| Optimism Bridge | Canonical rollup bridge | 0.64 billion dollars |
| NEAR Intents | Intent system | 208 million dollars |
| Axelar | Proof-of-stake messaging | 141 million dollars |
| Hyperlane | Messaging, app-chosen security | 77 million dollars |
| Across | Intent system | 17 million dollars |
The LayerZero figure is not LayerZero’s own money: it is the sum of tokens held by applications that send their messages through LayerZero, each with its own security settings.
Cross-chain messaging: who signs off on a message
Most modern bridges are applications on top of a messaging network. The token contract on chain A emits a message (“lock 10 tokens for this address”); the network carries it to chain B; a contract on chain B acts on it. The network does the same job as an oracle that reports outside data to a smart contract, except that the outside data is another chain’s state. The security of the transfer is the security of whoever attests to that message.
LayerZero: verifiers chosen by each application
On LayerZero v2 the verifiers are Decentralized Verifier Networks (DVNs). Each application sets its own security stack per pathway, written X-of-Y-of-N: a list of required DVNs that must all verify, plus optional DVNs of which a set number must agree. An Executor then delivers the message. If the application sets nothing, the protocol falls back to defaults that, per the LayerZero documentation, may change without notice. The docs are blunt: “You should always set your DVN configuration explicitly.” They also tell production applications to require at least one DVN not run by LayerZero Labs.
This design puts the decision with the application. Two tokens on LayerZero can have very different security: one verified by five independent operators, another by a single one. A user looking at a LayerZero-bridged token cannot assume anything from the brand; the configuration is a per-app setting that someone chose.
Chainlink CCIP: a committee, extra verifiers and an emergency brake
Chainlink‘s Cross-Chain Interoperability Protocol uses, per its architecture page, a default Committee Verifier of 16 independent node operators on every lane; each signs the message ID and an aggregator assembles a quorum. Lanes, token pools and receiving contracts can require additional verifiers. Delivery is permissionless: any executor can submit a verified message. Token issuers own their token pools, which lock or burn on one side and release or mint on the other, and token pools enforce per-chain rate limits. A risk management component acts as an on-chain emergency safeguard that can “curse” a chain and make affected operations revert.
Wormhole, Hyperlane and Axelar
Wormhole uses a fixed set of 19 Guardians, run by established validator companies; a message (a VAA, verified action approval) needs 13 of their 19 signatures, according to Wormhole’s Guardian documentation. Hyperlane, like LayerZero, leaves the choice to the receiving application: it picks an Interchain Security Module, by default a multisig module, and can combine modules or deploy its own. Axelar runs a proof-of-stake validator set; the key that controls its gateway contract on each connected EVM chain is split into shares held by the validators in proportion to stake, and a command executes only once enough weight has signed.
| Protocol | Who verifies the message | Who chooses the security |
|---|---|---|
| LayerZero v2 | DVNs, X-of-Y-of-N | Each application (defaults exist) |
| Chainlink CCIP | Committee of 16 operators by default, optional extra verifiers | Chainlink, plus issuers and receivers who add verifiers |
| Wormhole | 19 Guardians, 13 signatures | The protocol |
| Hyperlane | Interchain Security Module on the destination | Receiving application (default multisig) |
| Axelar | Proof-of-stake validators, stake-weighted key shares | The protocol |
| Circle CCTP | Circle’s attestation service | Circle |
None of these answers is good or bad on paper. A fixed set of 13 out of 19 known companies is easy to audit and hard to change. An app-chosen stack can be stronger than any default, or much weaker. What a user can do is find out which case applies before sending a large amount.
Cross-chain bridge risk: four ways the promise breaks
Bridges have been the most expensive part of DeFi to defend. As of 28 October 2026, DefiLlama flags 99 incidents as bridge hacks, for 3.69 billion dollars out of 21.19 billion across every hack it records, about 17 percent. Bridge-flagged losses dated 2026 already reach about 753 million dollars. The concentration was worse in the peak year: Chainalysis wrote on 2 August 2022 that 13 bridge hacks had taken about 2 billion dollars, 69 percent of all funds stolen that year so far. Our history of DeFi lists the cases in order; here the point is why each one failed.
| Date | Bridge | Amount (DefiLlama) | DefiLlama technique |
|---|---|---|---|
| 10 Aug 2021 | Poly Network | 611 million dollars | Improper access control |
| 2 Feb 2022 | Wormhole (Portal) | 326 million dollars | Signature verification flaw |
| 23 Mar 2022 | Ronin Bridge | 624 million dollars | Validator key compromised |
| 23 Jun 2022 | Harmony Bridge | 100 million dollars | Validator key compromised |
| 1 Aug 2022 | Nomad | 190 million dollars | Forged proof |
| 6 Oct 2022 | Binance Bridge (BSC) | 570 million dollars | Proof verifier bug |
| 7 Jul 2023 | Multichain | 126 million dollars | Validator key compromised |
| 18 Apr 2026 | Kelp (rsETH) | 293 million dollars | Cross-chain message spoofing |
| 6 Sep 2026 | Liquid Network | 320 million dollars | Unbacked cross-chain mint |
Too few keys: Ronin in 2022 and Multichain in 2023
Ronin, the sidechain built for Axie Infinity, needed 5 signatures out of 9 validators to approve a withdrawal. Halborn’s analysis describes how the attacker got all five: four validators run by Sky Mavis, plus one belonging to Axie DAO. In November 2021 Axie DAO had let Sky Mavis sign on its behalf to cope with heavy traffic; the arrangement ended the next month, but the permission was never revoked. After breaking into Sky Mavis systems, the attacker had enough keys to sign withdrawals of 173,600 ETH and 25.5 million USDC, about 624 million dollars. Nobody noticed for six days, until a user could not withdraw 5,000 ETH. On 14 April 2022 the FBI said it had confirmed that the Lazarus Group and APT38, actors associated with North Korea, were responsible, as BleepingComputer reported.
The lesson is arithmetic. Nine signers sounded like a federation, but four sat in one company and a fifth could be reached through a stale permission. Independence, not the headline count, is what protects a multisig.
Multichain failed without a single line of bad code. According to the team’s own statements reported by Cointelegraph, chief executive Zhaojun was taken from his home by Chinese police on 21 May 2023, and “all the team’s funds and access to the servers” were with him and the police. In early July more than 100 million dollars left the bridge’s contracts; Multichain halted operations on 14 July. Chainalysis said the withdrawals looked like an insider rug pull. The team’s account has not been tested in court, but the failure type is plain: the keys of a bridge holding hundreds of millions depended on one person.
A verification bug: Wormhole in 2022
On 2 February 2022 the Solana side of Wormhole minted 120,000 wrapped ETH with nothing locked on Ethereum, about 326 million dollars. The contract did not properly validate the accounts passed to it, which let the attacker present forged Guardian signatures as valid, as The Block reported. The 13-of-19 Guardian rule was never broken: the contract simply never confirmed that the signature check had actually run. Jump Crypto replaced the 120,000 ETH the next day, so holders of wrapped ETH were made whole. That rescue was a choice by a wealthy sponsor, not a property of the bridge.
An upgrade that approved everything: Nomad in 2022
Nomad’s failure on 1 August 2022 came from a routine upgrade. According to Immunefi’s analysis, the initialisation of a new Replica contract marked the zero root as trusted. In Ethereum storage an unknown entry reads as zero, so any message the contract had never seen counted as proven. The first attacker took 100 WBTC; then hundreds of others copied the transaction, swapped in their own address and replayed it. About 190 million dollars left in hours. No key was stolen and no signer lied. A configuration value turned the verification off.
One verifier and poisoned data: Kelp in 2026
The Kelp case of 18 April 2026 combined a weak configuration with an attack on the verifier’s data. According to LayerZero, reported by The Block on 9 May 2026, attackers compromised the internal RPC nodes that LayerZero Labs’ DVN used to read the source chain, poisoned their data and knocked out external RPC providers with a denial-of-service attack, so the DVN signed off on a transfer that never happened. LayerZero attributes the attack to North Korea’s Lazarus Group, an attribution we could not confirm from a government source.
Who set the single verifier is disputed. LayerZero said Kelp used a 1-of-1 configuration against its recommendations. Kelp said on 20 April, as CoinDesk reported, that the setup reflected LayerZero’s documented default and had been confirmed during its expansion to layer 2s. In May LayerZero wrote that “we made a mistake by allowing our DVN to act as a 1/1 DVN for high-value transactions”, said its DVN would no longer support 1-of-1 setups and moved defaults to at least five verifiers where possible, with a floor of three.
The damage spread beyond Kelp. The attacker used stolen rsETH as collateral on Aave, which froze its rsETH markets on V3 and V4 and said the problem was rsETH, not its own contracts. A bridged token’s risk lands on every protocol that accepts it as collateral.
Value minted without backing: Liquid Network in 2026
Bitcoin sidechains carry the same risk. On 6 September 2026 an attacker minted about 4,000 L-BTC with no bitcoin behind them on Liquid, the Blockstream sidechain, and redeemed them for real BTC through SideSwap, an approved peg-out operator, with the 11-of-15 federation signing the release. According to TRM Labs, 36 minutes passed from mint to payout and the loss was about 319 million dollars. Halborn traces it to a cache in Elements, Liquid’s node software, whose key did not include the asset ID and script context, so a proof verified once could validate a different output. The federation signed honestly: its software said the coins were valid. On 7 September the attacker, who claimed to be a white hat, returned about 3,400 BTC after nodes patched the bug; about 598.5 BTC stayed with them, per TRM Labs.
Put side by side, the cases fall into four families: keys held by too few independent parties (Ronin, Harmony, Multichain), a verification bug (Wormhole, Binance Bridge, Liquid), an upgrade or configuration error (Nomad, and the 1-of-1 setting in Kelp), and trust in off-chain data (Kelp’s RPC nodes). None of them broke the cryptography. Each broke the assumption about who was checking.
Intents and solvers: someone else carries the route
Intent systems turn the problem around. Instead of sending a transaction that does each step, the user signs the result they want (“I give 1,000 USDC on Arbitrum and want at least 999 USDC on Base”) and competing third parties, called solvers, fillers or relayers, deliver it with their own capital. They are repaid afterwards, once the settlement layer has checked that they delivered.
Same-chain intents: CoW batches and UniswapX auctions
CoW Protocol is the textbook case on a single chain. Its documentation describes a signed intent that “is not an executable user transaction”: solvers compete to settle a batch of orders, all trades of the same pair in a batch clear at one price, and opposite orders can be matched directly against each other. The winning solver carries the execution risk. UniswapX, from Uniswap, uses signed orders and a Dutch auction: the order starts at the best price for the user and decays towards a floor until a filler finds it worth taking; the user pays no gas and pays nothing for a failed transaction.
Cross-chain intents: how Across settles
Across applies the idea between chains. Per its architecture page, relayers fill the user’s order on the destination chain with their own money, competing on speed, and choose the chain where they want to be repaid. An off-chain Dataworker groups fills into bundles covering about 1.5 hours, checks them against deposits and proposes each bundle to the HubPool contract on Ethereum with a bond. The UMA Optimistic Oracle secures the process: a bundle is accepted unless someone challenges it, and one honest challenger is enough. Canonical bridges rebalance the pools behind the scenes.
The user’s wait shrinks to the relayer’s reaction time, and the user no longer depends on the canonical bridge’s seven days. The relayer does, and it charges for that capital. As of 28 October 2026 DefiLlama counts only 17 million dollars locked in Across and 208 million in NEAR Intents, another intent system: little capital sits in contracts because fillers bring their own.
ERC-7683 is still a draft
Every intent system has its own order format, which forces solvers to write custom code for each. ERC-7683, Cross Chain Intents, created on 11 April 2024, proposes a common interface: each protocol publishes a resolver contract that turns its own orders into a shared description of steps and payments, so solvers can judge an order without bespoke code. As of 28 October 2026 its status on the EIPs site is Draft. The current text has narrowed to that resolution step after an earlier version covered more of the order lifecycle. Which products implement the current draft is not something we could verify.
Intents were hit too: Across and NEAR Intents in 2026
Intents move risk; they do not remove it. On 17 July 2026 an attacker forged 1,627 deposit events on Solana, with a face value of about 41.7 million dollars, by exploiting a missing check in the off-chain relayer software that reads Solana events, as The Cryptonomist reported. The relayer filled 581 of them before Solana was disabled as an origin chain, paying about 4.5 million dollars of Risk Labs’ own capital (DefiLlama records 4.5 million). No smart contract was compromised, genuine transfers were completed or refunded the same day, and Solana service resumed about 12 hours later through CCTP. The filler’s capital absorbed the loss, which is the design working, but the event reader was still a trust point.
On 1 October 2026 NEAR Intents halted after losses of about 3.8 million dollars. The team first attributed it to a bug in how its Omni deposit and withdrawal infrastructure interacted with the NEAR Intents contract and pledged full compensation, The Block reported. The post-mortem published on 16 October by chief executive Alex Shevchenko told a different story: the flaw sat in the NEAR Intents contract, not in Omni. On each deposit the contract notified a third-party contract; the attacker’s contract failed that notification on purpose, so the token contract refunded the deposit while NEAR Intents kept the credit on its ledger. Across 23 such failed deposits the attacker built up about 3.8 million dollars of unbacked balances and withdrew real tokens against them. According to the post-mortem, the funds came back within 36 hours and affected users were compensated; a second report on the same function led to its removal on 7 October and a 300,000 dollar bounty. DefiLlama files the case as a bridge logic flaw.
Native, third-party or intent: how they compare
| Native or issuer bridge | Third-party bridge or messaging | Intent system | |
|---|---|---|---|
| Who verifies | The rollup’s proof system, or the issuer (Circle for CCTP) | Validators, a committee or app-chosen verifiers | A settlement layer after the filler has paid |
| Typical wait | About 7 days out of an optimistic rollup; 8 seconds to 19 minutes for CCTP | Depends on the verifiers and the source chain | As soon as a filler acts |
| What you receive | The native asset | Often a wrapped copy, sometimes the native token | The native asset from the filler |
| What fails | Proof system or issuer | Keys, signature checks, configuration | Filler software, settlement checks |
| Who loses first | Every holder of the bridged asset | Holders of the wrapped token, then protocols using it as collateral | Usually the filler’s capital |
For a user, two rules come out of the table. Large and patient transfers of an asset with a native route (ETH out of a rollup, USDC through CCTP) carry the fewest extra trust assumptions. Fast transfers are fine when someone else’s capital takes the waiting risk, but the price is a fee and, for wrapped tokens, exposure to the bridge for as long as you hold them.
A safety checklist for a cross-chain bridge transfer
Before moving a meaningful amount, run through these steps. They take ten minutes and cost a small test fee in gas.
- Open the bridge from its official address, typed or bookmarked, never from a search ad, a direct message or a link in a Discord or Telegram post.
- Send a small test amount first and check it arrived where you expected, on the right chain and as the right token.
- Check the exact token you will receive: the native asset, the issuer’s official version, or a wrapped copy whose value depends on the bridge.
- Find out who verifies the transfer: the rollup, the issuer, a fixed validator set, or an application’s own configuration, and how many independent parties that means.
- For USDC between supported chains, compare the CCTP route with routes that hand you a wrapped dollar token.
- Read the token approval your wallet asks you to sign, approve only the amount you are sending, and revoke old unlimited approvals afterwards.
- If you add a network to your wallet, check its chain ID and RPC address against the project’s own documentation.
- Keep some native gas token on the destination chain, or you will not be able to move what you bridged.
- Save the transaction hashes on both chains until the transfer is final and visible in your wallet.
- Write down the date, amounts and dollar values for your tax records.
Fake bridges and fake chains
A bridge front end is also a phishing target. In late September 2026 a counterfeit bridge for GIWA, the layer 2 developed by Dunamu, the operator of Upbit, received about 767.65 ETH from 1,335 addresses before scammers drained 766.25 ETH, about 2 million dollars, according to Cointelegraph; DefiLlama files it on 27 September as an impersonation scam of 2.08 million dollars. GIWA said its mainnet was not running. DYORSWAP, a decentralised exchange that had first taken the fake bridge for GIWA’s mainnet, paid more than 200 ETH to affected users from its own funds. A chain that has not launched cannot have a bridge. Our guide on how to avoid crypto scams covers the other patterns.
Taxes and rules when you bridge
No US rule names bridging. The IRS digital assets page treats exchanging one digital asset for another as a disposal that must be reported, and says transfers between wallets you own or control are not digital asset transactions unless you paid a fee in digital assets. A bridge sits between those two cases: moving native USDC with CCTP looks like a transfer of the same asset, while giving ETH and receiving a different wrapped token can look like an exchange. Notice 2024-57 spares brokers from reporting wrapping and unwrapping on Form 1099-DA until further guidance, which says nothing about how you treat it on your own return. Keep full records and see our guide to crypto taxes in the United States.
Regulators have not written bridge-specific rules either. We found nothing on bridging from the SEC, the CFTC or, in the United Kingdom, the FCA, and we did not find an HMRC position specific to bridges. Bridging also leaves you holding whatever the bridge gives you: if a wrapped token loses its backing, no deposit insurance or investor compensation scheme covers it.
The next lesson of the DeFi course leaves the chains behind and compares DeFi with centralised exchanges and traditional finance, pillar by pillar, following one transaction from end to end.
