KelpDAO + LayerZero: $292M Lost in a 1-of-1 DVN Exploit
$292 million in rsETH released through a single-verifier bridge configuration — and a public dispute over whose decision that was.
On 18 April 2026, Kelp DAO's rsETH bridge, built on LayerZero's OFT standard, released 116,500 rsETH — about $292M — after attackers compromised LayerZero Labs' RPC infrastructure and fed forged data into the single verifier Kelp's bridge trusted. LayerZero's other, healthy Decentralized Verifier Network (DVN) nodes were knocked offline with a DDoS attack at the same time. Kelp paused the affected contracts 46 minutes later. Some of the stolen rsETH ended up as collateral on Aave, leaving that market holding bad debt. LayerZero and Kelp still disagree over who is responsible for the 1-of-1 configuration that made a single compromised source enough to move $292M.
Case File Update
Sources replaced; both sides of the LayerZero/Kelp dispute shown.
The Scheme
Kelp DAO's rsETH bridge used LayerZero's Omnichain Fungible Token (OFT) standard to move rsETH across chains. Every cross-chain transfer depends on a Decentralized Verifier Network (DVN) confirming the message is genuine before the destination chain releases funds. Kelp's bridge was configured to accept sign-off from a single DVN — operated by LayerZero Labs — as sufficient on its own. On 18 April 2026, attackers compromised LayerZero Labs' RPC infrastructure and fed it forged data, while simultaneously hitting the network's other, healthy DVN nodes with a DDoS attack. The one verifier Kelp's bridge actually relied on signed off on a fraudulent release of 116,500 rsETH, worth about $292M.
A Decentralized Verifier Network is supposed to mean more than one verifier matters. Here, only one did.
Series: Bridge Exploits
Different bridges, same highway. How cross-chain infrastructure fails — through a leaked key or a fabricated message.
A Bridge Built On One Verifier's Word
LayerZero lets every integrating protocol choose how many independent DVNs must sign off on a cross-chain message before it's trusted. More DVNs means more independent confirmation and more cost; fewer means less of both. Kelp's rsETH OFT bridge was set to require just one DVN — LayerZero Labs' own — to authorise a release.
On 18 April 2026, that single point of trust became a single point of failure. Attackers compromised the RPC infrastructure LayerZero Labs' DVN relied on to read on-chain state and used it to feed the DVN forged data. At the same time, a distributed denial-of-service attack on LayerZero's other, healthy DVN nodes meant no independent verifier was available even if the bridge had wanted a second opinion.
The forged data was enough for Kelp's bridge contracts to release 116,500 rsETH — about $292M at the time — to an attacker-controlled address. Kelp's team paused the affected contracts 46 minutes after the exploit began.
Forty-six minutes is a fast response. It still wasn't fast enough to stop $292M from leaving.
Why 1-of-1 Meant One Compromise Was Enough
A verifier network only verifies anything if a compromised signer can be outvoted, or at least flagged, by an honest one. Set the required number of confirmations to one, and a single point of compromise — a server, an RPC endpoint, a key — becomes sufficient to move any amount the bridge is willing to release.
Who decided Kelp's bridge should run 1-of-1 is disputed. LayerZero Labs says Kelp configured the bridge that way against the guidance LayerZero gives integrators. Kelp says LayerZero's own default settings point protocols toward a 1-of-1 setup, and that the compromised component — the RPC infrastructure feeding the DVN — belonged to LayerZero, not to Kelp.
Both LayerZero and Chainalysis attribute the exploit to the Lazarus Group, also tracked as TraderTraitor, the North Korea-linked hacking cluster blamed for a long list of other crypto thefts.
Whoever picked '1,' the attackers only needed to beat one.
Vocabulary Decoded: 'Decentralized Verifier Network' vs One Verifier
What the DVN model is designed to provide, versus what Kelp's bridge actually required:
"Decentralized Verifier Network (DVN)"
What it sounds like:
A set of independent verifiers, each able to catch a forged or manipulated cross-chain message, so no single compromised party can move funds alone.
What actually happened:
Kelp's rsETH OFT bridge required confirmation from exactly one DVN — operated by LayerZero Labs. When that DVN's data source was compromised, there was no second verifier positioned to disagree.
"LayerZero-powered bridge"
What it sounds like:
A bridge backed by LayerZero's broader infrastructure and security model.
What actually happened:
LayerZero provides the messaging framework and lets each integrator choose its own verifier configuration. Kelp's choice — a single DVN — determined how much security the bridge actually had, independent of what LayerZero's framework can support.
"$292M bridge hack" (the headline figure)
What it sounds like:
A single company, LayerZero or Kelp, was straightforwardly hacked.
What actually happened:
LayerZero's infrastructure was compromised — an RPC feed and a DDoS on backup verifiers — and Kelp's bridge accepted the resulting forged message because its configuration required only that one DVN's sign-off. The two companies point to different parts of that chain as the real failure.
The companies disagree on fault. On-chain, 116,500 rsETH still left Kelp's bridge.
How The Exploit Unfolded
Based on public statements from LayerZero and Kelp DAO, and Chainalysis's reconstruction:
Step 1: Compromise LayerZero's RPC Infrastructure
Attackers gained access to RPC infrastructure that LayerZero Labs' DVN used to read blockchain state, and used it to feed that DVN forged data about a withdrawal that never happened.
A DVN is only as trustworthy as the data it reads. Compromise the feed, and the signature built on top of it is worthless.
Step 2: Knock The Other DVN Nodes Offline
A distributed denial-of-service attack hit LayerZero's other, healthy DVN infrastructure at the same time, removing any chance that an independent verifier could catch or contest the forged message.
Kelp's bridge only needed one DVN to agree. The attackers made sure the only one available was the compromised one.
Step 3: Release 116,500 rsETH
LayerZero Labs' DVN — the sole verifier Kelp's OFT bridge trusted — signed off on the forged withdrawal message. Kelp's bridge contracts released 116,500 rsETH, worth about $292M, to the attacker.
The contracts did exactly what a 1-of-1 configuration tells them to do: trust the one signature they're given.
Step 4: Stolen rsETH Lands As Collateral On Aave
Some of the stolen rsETH was deposited as collateral on Aave. With the token's legitimacy in question, this left Aave's market holding bad debt.
A bridge exploit doesn't stay contained to the bridge once the stolen asset is accepted as collateral somewhere else.
Timeline: From Forged Data To Paused Contracts
Reconstructed from LayerZero's incident statement, Chainalysis's analysis, and reporting from The Block, CoinDesk and BleepingComputer:
18 April 2026: RPC Infrastructure Compromised
Attackers gain access to LayerZero Labs' RPC infrastructure and begin feeding forged data to the DVN that Kelp's bridge relied on.
LayerZero and Chainalysis both attribute the operation to the Lazarus Group, also tracked as TraderTraitor.
Same Day: Healthy DVN Nodes DDoSed
LayerZero's other DVN infrastructure is hit with a distributed denial-of-service attack, removing independent verifiers from the picture at the critical moment.
Kelp's bridge required sign-off from only one DVN — LayerZero Labs' — so the DDoS on other nodes didn't need to defeat redundancy that didn't exist for this integration.
Forged Message Accepted, 116,500 rsETH Released
The compromised DVN signs off on a fraudulent withdrawal. Kelp's bridge contracts release 116,500 rsETH, about $292M, to an attacker-controlled address.
The Block, Decrypt and Cointelegraph all reported the loss in the roughly $290–292M range on and immediately after 18 April 2026.
46 Minutes Later: Kelp Pauses The Contracts
Kelp's team pauses the affected bridge contracts 46 minutes after the exploit began, stopping further withdrawals through the same path.
LayerZero published an incident statement the following day, 19 April 2026.
Aftermath: Bad Debt On Aave, A Public Dispute Over Blame
Some stolen rsETH ends up posted as collateral on Aave, leaving the lending market with bad debt. LayerZero and Kelp publicly dispute who is responsible for the 1-of-1 DVN configuration.
LayerZero says Kelp configured the bridge against its advice. Kelp says LayerZero's defaults point toward 1-of-1, and that the compromised infrastructure was LayerZero's.
Forty-six minutes from exploit to pause. $292M had already moved.
On-Chain Evidence: The Addresses Involved
Confirmed on-chain and visible on Etherscan. Addresses shown truncated:
Etherscan labels an address that received the stolen rsETH "Kelp DAO Exploiter 3" (0x1F4C…deF).
This is the wallet Etherscan associates with the proceeds of the exploit.
Labelled exploiter addresses let researchers and exchanges track, and where possible flag or freeze, downstream movement of stolen funds.
The RSETH_OFTAdapter contract (0x85d4…Ef3) is the bridge contract through which the 116,500 rsETH was released.
This is Kelp's LayerZero OFT adapter contract — the piece that executed the withdrawal the forged DVN message authorised.
The contract itself was not exploited through a code bug; it executed a withdrawal it had been told, by the single verifier it trusted, was legitimate.
Stolen rsETH posted as collateral on Aave left the market holding bad debt once the token's provenance was in question.
A bridge exploit spread beyond the bridge the moment the stolen asset was accepted as collateral elsewhere in DeFi.
This is why bridge exploits rarely stay contained to the bridge: any protocol that accepts the bridged asset inherits exposure to its integrity.
What A 1-of-1 DVN Configuration Actually Means
- •requiredDVNCount = 1 on a bridge moving hundreds of millions — A single verifier's sign-off was sufficient to authorise any withdrawal, with no independent party required to agree.
- •The sole verifier and the compromised infrastructure belonged to the same company — LayerZero Labs operated both the DVN Kelp's bridge trusted and the RPC infrastructure that was compromised to feed it forged data.
- •Backup verifiers existed on the network but weren't required by this integration — A DDoS on LayerZero's other DVN nodes only mattered because Kelp's configuration didn't require any of them to weigh in.
- •46-minute response time, after $292M had already moved — Pausing contracts quickly limits further damage, but can't undo a release that's already been signed off on-chain.
- •Stolen tokens were usable as real collateral elsewhere in DeFi — Aave accepted the stolen rsETH as collateral, showing a compromised bridge's output can still move freely through DeFi until flagged.
LayerZero and Kelp disagree about who chose it. Both agree it was there.
The Numbers
What's confirmed about the scale of the exploit:
116,500 rsETH — Total Released
Worth about $292M at the time of the exploit on 18 April 2026.
1 — Number Of DVNs Required To Authorise The Withdrawal
Kelp's rsETH OFT bridge required sign-off from a single DVN, operated by LayerZero Labs, to release funds.
46 Minutes — Time To Pause The Contracts
Kelp's team paused the affected contracts 46 minutes after the exploit began.
Disputed — Who Is Responsible For The 1-of-1 Configuration
LayerZero says Kelp chose 1-of-1 against its advice. Kelp says LayerZero's defaults point toward 1-of-1 and that the compromised infrastructure belonged to LayerZero.
Why Bridges Keep Running Thin Verifier Configurations
The dynamics that produce a 1-of-1 setup are common across the industry:
Fewer Verifiers Means Lower Cost, Until It Doesn't
Every additional independent verifier a bridge requires adds cost and latency to each cross-chain message. Protocols that compete on speed and fees have an incentive to require fewer confirmations.
The savings are visible every day. The risk is invisible until the day it isn't.
Default Settings Shape What Gets Deployed
Whatever a messaging framework's examples or defaults suggest, many integrators ship close to that configuration rather than hardening it further — part of why LayerZero and Kelp now dispute whose defaults led here.
A framework that allows strong security isn't the same as a deployment that requires it.
Shared Infrastructure Means Shared Failure Modes
When one company operates both the sole trusted verifier and the infrastructure that feeds it data, a single compromise of that infrastructure can defeat the verification step entirely.
Decentralization on paper doesn't help if, in practice, only one party's systems matter.
Who's Being Blamed, And Why It's Contested
LayerZero and Kelp have each given their account of responsibility:
LayerZero's Position
LayerZero Labs says Kelp configured its bridge to require only one DVN against the guidance LayerZero provides integrators, and that Kelp's choice is what let a single compromise be sufficient.
Kelp's Position
Kelp DAO says LayerZero's own default settings point protocols toward a 1-of-1 configuration, and that the infrastructure that was actually compromised — the RPC feed to the DVN — belonged to LayerZero, not to Kelp.
Attribution To Lazarus / TraderTraitor
Both LayerZero and Chainalysis attribute the exploit to the Lazarus Group, also tracked as TraderTraitor — a North Korea-linked hacking cluster.
Bad Debt Spread To Aave
Stolen rsETH used as collateral on Aave left that lending market holding bad debt, extending the exploit's impact beyond Kelp and LayerZero.
Both companies agree on what happened on-chain. They disagree on who made the configuration choice that allowed it.
How To Protect Yourself From The Next Thin-Verifier Bridge
Steps that reduce exposure to a similar failure:
- Rule 1: Check a bridge's required DVN (or equivalent verifier) count before trusting it with size LayerZero's DVN configurations are public on-chain. A requirement of one verifier means a single compromise is enough.
- Rule 2: Note who operates the verifier(s) a bridge relies on If the same company operates the sole verifier and the infrastructure that feeds it, a single compromise of that company's systems can be enough to defeat verification.
- Rule 3: Understand that a bridged asset's risk doesn't stay inside the bridge Once a bridged token can be used as collateral elsewhere, any problem with that token's legitimacy can create bad debt in unrelated protocols.
- Rule 4: Watch official statements for disputed attribution of responsibility When the messaging provider and the integrating protocol publicly disagree about configuration choices, treat both accounts as partial until independent audits settle it.
- Rule 5: Run any unfamiliar bridge or token through our free Scam Detector If a URL, contract or DM related to a bridge feels off, check it before you sign anything.
Got a Suspicious Message?
Use our AI-powered detector to analyze potential scams instantly.
Key Takeaways
- 1.On 18 April 2026, Kelp DAO's rsETH bridge released 116,500 rsETH, about $292M, after LayerZero Labs' RPC infrastructure was compromised and fed forged data to the single DVN Kelp's bridge trusted.
- 2.LayerZero's other, healthy DVN nodes were hit with a DDoS attack at the same time, removing any chance of independent verification even if the bridge had required it.
- 3.Kelp's bridge was configured to accept sign-off from just one DVN — LayerZero Labs' own — making that single compromise sufficient to authorise the release.
- 4.Kelp paused the affected contracts 46 minutes after the exploit began. The stolen rsETH was used as collateral on Aave, leaving that market holding bad debt.
- 5.LayerZero and Chainalysis both attribute the exploit to the Lazarus Group / TraderTraitor. Blame for the 1-of-1 configuration is disputed: LayerZero says Kelp chose it against advice; Kelp says LayerZero's defaults point to 1-of-1 and that LayerZero's own infrastructure was the compromised component.
- 6.Before trusting a bridge with size, check its required verifier count and who operates that verifier — a single point of trust is a single point of failure, whoever configured it.
“One verifier. One compromised feed.”
$292 million moved before anyone could agree whose fault the configuration was.
Frequently Asked Questions
Sources & Citations
Research for this investigation compiled from publicly available blockchain data, security reports, and community documentation.
LayerZero Labs · 19 Apr 2026
BleepingComputer · 20 Apr 2026
CoinDesk · 20 Apr 2026
Blockaid · Date not published or not verified
Etherscan · Date not published or not verified
Etherscan · Date not published or not verified
Verification: All blockchain transactions and addresses referenced in this article can be independently verified through the linked blockchain explorers. We encourage readers to conduct their own verification.
Methodology: Every case needs at least two independent sources before publication, plus verifiable on-chain evidence whenever a public transaction trail exists. Full standards: /methodology
Legal notice: This assessment is based on publicly available data, including on-chain records, official statements and reported incidents. It is journalistic and educational analysis, not legal advice, an accusation of criminal conduct or a court finding. Named companies, projects, domains, wallets and individuals are described as reported by the cited sources; a company name may appear because fraudsters impersonated it, not because the company did anything wrong. If you believe something is inaccurate or out of date, write to cryptostrapon@proton.me and we will correct it and log the change. Editorial policy
More Scam Warnings
Continue learning about crypto threats
Hyperbridge $1.2B Fake DOT: The Unchecked Mint Function
Bridge Exploit • 2026-05-28
A missing access-control modifier let an attacker mint $1.2B of unbacked DOT on Ethereum via Hyperbridge. Full kill chain plus $237k Uniswap dump.
CrossCurve Bridge Hack: $3M Stolen in 15 Minutes [2026]
Bridge Exploit • 2026-03-10
One fake message. Zero validation. $3M drained across 3 chains in a single tx. The audit passed — the bridge didn't. See the exact exploit flow inside.
IoTeX Bridge Hack: How 1 Leaked Key Drained $8.8M [2026]
Bridge Exploit • 2026-03-05
One validator key leaked. $8.8M gone in minutes. The IoTeX ioTube bridge had zero failsafes.