How a Single LayerZero DVN Compromise Drained $292M from KelpDAO

Executive Summary

On April 18, 2026 at approximately 17:35 UTC, an attacker forged a LayerZero cross-chain message claiming to originate from KelpDAO's Unichain deployment and successfully passed it through a single, compromised Decentralized Verifier Network (DVN). With no redundant verifier in the security stack to catch the fraud, KelpDAO's Ethereum OFTAdapter released 116,500 rsETH, worth approximately $292M at time of exploit, to an attacker-controlled address. A second fraudulent packet targeting an additional 40,000 rsETH was authenticated by the same compromised DVN but blocked by KelpDAO's emergency multisig before execution.

The rsETH token contract itself was not exploited. No minting vulnerability, admin takeover, or contract backdoor was involved. The attack surface was entirely in the bridge's verification configuration: a 1-of-1 DVN setup where a single compromised signer set was sufficient to authorize an arbitrary cross-chain message. KelpDAO has since paused rsETH transfers on Ethereum. User holdings remain intact but temporarily frozen.

Blockaid detected the incident in real time. Attacker and consolidation addresses have been identified, flagged, and are actively generating warnings for all Blockaid-protected users. Our research team is actively co-investigating alongside SEAL, KelpDAO, and LayerZero Labs.

Background: What Is KelpDAO and rsETH?

KelpDAO is a liquid restaking protocol built on EigenLayer. Users deposit ETH, which is routed through EigenLayer to earn restaking yield on top of standard Ethereum staking rewards. In return, users receive rsETH: a tradeable liquid restaking token that represents their restaked position and accrues rewards across multiple AVS (Actively Validated Services).

To enable rsETH to move cross-chain, KelpDAO deployed a LayerZero-based bridge architecture using the OFT (Omnichain Fungible Token) standard. On Ethereum, KelpDAO operates an OFTAdapter contract, an escrow mechanism that locks native rsETH and mints a corresponding OFT-wrapped version on destination chains. rsETH is deployed across more than 20 networks including Base, Arbitrum, Linea, Blast, Mantle, and Scroll. The Ethereum OFTAdapter held the backing reserve for all of these L2 deployments. As of the time of the exploit, KelpDAO held approximately $1.07 billion in ETH LRT TVL, making it the second-largest participant in EigenLayer's ecosystem.

This is the reserve that was drained.

LayerZero DVNs: The Security Stack Behind Cross-Chain Messaging

To understand how this exploit worked, it is necessary to understand how LayerZero V2 validates cross-chain messages.

LayerZero is a cross-chain messaging protocol. When an OApp (like KelpDAO's bridge) sends a message from Chain A to Chain B, the protocol requires that one or more Decentralized Verifier Networks (DVNs) observe the packet on the source chain, verify it, and deliver a signed attestation to the destination chain. Only once the required DVNs have attested to the packet's validity can it be executed at the destination.

DVNs are configured per-OApp, per-pathway. The security parameters (how many required DVNs, how many optional DVNs, what threshold of optional DVNs must sign, and how many block confirmations are required) are set by the OApp developer via a setConfig call on LayerZero's EndpointV2 contract. The relevant structure is the ULN (Ultra Light Node) configuration:

1struct UlnConfig {
2    uint64   confirmations;
3    uint8    requiredDVNCount;
4    uint8    optionalDVNCount;
5    uint8    optionalDVNThreshold;
6    address[] requiredDVNs;
7    address[] optionalDVNs;
8}

In practice, a well-configured OFT deployment might specify two required DVNs, for example the LayerZero default DVN and a secondary provider like Google Cloud or Polyhedra, such that both must independently verify a packet before it can be executed. This is a 2-of-N configuration, and it provides meaningful redundancy: an attacker would need to compromise two independent verification infrastructures simultaneously to forge a message.

KelpDAO's Ethereum OFTAdapter, deployed at 0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3, was configured with a single required DVN at 0x589dedbd617e0cbcb916a9223f4d1300c294236b, and zero optional DVNs. This is a 1-of-1 configuration. The compromise or subversion of that single DVN's off-chain signing infrastructure was sufficient to authenticate any arbitrary LayerZero message, including one claiming a source transaction that never happened on Unichain.

The Exploit: Step by Step

Step 1. Pre-positioning via Tornado Cash

Attacker wallets were pre-funded through Tornado Cash, the standard operational security tactic for obscuring attack origins. This confirms the operation was deliberate and planned, not opportunistic.

Step 2. The Forged LayerZero Message

The attacker crafted a LayerZero packet claiming to originate from KelpDAO's Unichain OFT deployment. The packet encoded a lzReceive call to KelpDAO's Ethereum OFTAdapter, instructing it to release 116,500 rsETH to an attacker-controlled address. Critically, no corresponding source transaction exists on Unichain. The message was entirely synthetic; fabricated off-chain.

The forged packet was submitted to LayerZero's EndpointV2 contract on Ethereum. Because KelpDAO's receive pathway required only a single DVN attestation, and because the DVN at 0x589dedbd... had been compromised, that attestation was provided. LayerZero's on-chain contracts, which cannot independently verify source-chain state, accepted the attestation as valid.

The relevant delivery transaction: 0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222

LayerZero scan confirms: nonce 308, no source transaction on Unichain.

Step 3. OFTAdapter Release

The authenticated lzReceive call executed against the OFTAdapter. The contract, functioning entirely as designed, released 116,500 rsETH from escrow to the attacker's address. No smart contract vulnerability was exploited. The OFTAdapter did exactly what it was built to do; it trusted the LayerZero message delivery system, which had been compromised at the DVN layer.

Step 4. Second Attack Attempt Blocked

A second forged packet (nonce 309) was also authenticated by the compromised DVN, targeting an additional 40,000 rsETH (~$100M). KelpDAO's emergency response team identified the incident in progress and executed a pause transaction (0x4f52256ab6c8ab95d30cf994e0264f1de27e089764bb011824d5ddd47d9a1698) before the second packet could be delivered. KelpDAO's emergency pauser multisig acted 46 minutes after the initial drain. Both follow-up attempts carrying the same packet failed.

Step 5. Fund Extraction

Immediately following the drain, the attacker began routing funds to maximize extraction:

• 116,500 rsETH deposited as collateral into Aave V3 on Ethereum (0xc295f4cd51fdd7d76f64cb7993aba0630769c032190a70835666516825840fc6)
• WETH borrowed against the stolen rsETH collateral, creating an effectively unliquidatable position that leaves Aave's WETH reserve carrying bad debt
• 52,440 ETH sent to a consolidation address (0xe21c3603917d55641267b12b9a4539e6fa48f2b5b40f7afb50c0e6d46ce4d7f6)
• USDC bridged cross-chain to EVM address 0xE69f6d77DB6Ff493FDD15D8A0B390c36E18E5b21
• Additional funds routed through ChangeNow and Binance deposit addresses

The attacker's deliberate use of Aave V3 as an extraction mechanism, depositing stolen rsETH to borrow real assets against it, is a sophisticated two-step that weaponizes DeFi composability. The rsETH collateral cannot be seized via normal liquidation because it has no real underlying value post-drain, leaving Aave's WETH reserve with bad debt it cannot recover through standard protocol mechanics.

Verifying Your DVN Configuration

If you operate a LayerZero OFT or OApp, you should immediately verify your DVN configuration. Blockaid has published a bash script to check your setup: gist.github.com/IdoBn/7753f16fdb6810b11c5c87cdf11f8aa0

The relevant on-chain check is a getConfig call against the LayerZero EndpointV2 contract for your OApp address and receive library, querying CONFIG_TYPE_ULN (type 2):

1bash
2# Replace variables with your OApp and pathway details
3OAPP=<your_oapp_address>
4RECEIVE_LIB=<receive_uln302_address>
5REMOTE_EID=<source_chain_endpoint_id>
6
7cast call $ENDPOINT \
8  "getConfig(address,address,uint32,uint32)(bytes)" \
9  $OAPP $RECEIVE_LIB $REMOTE_EID 2

Decode the returned bytes as a UlnConfig struct. If requiredDVNCount equals 1 and optionalDVNCount equals 0, you are running a 1-of-1 configuration. You should immediately add a second required DVN or configure optional DVNs with a threshold.

DeFi Contagion: The Composability Cascade

The downstream impact from this exploit illustrates exactly why liquid restaking tokens represent a systemic risk vector in DeFi. rsETH was whitelisted as collateral on multiple major lending protocols simultaneously. When the backing reserve was drained, the consequences cascaded in real time across the ecosystem.

Aave V3 and V4 - rsETH markets were frozen by the AAVE guardian multisig within hours of the incident. Aave founder Stani Kulechov confirmed that Aave's contracts were not exploited and the freeze was precautionary. However, the Aave V3 WETH reserve is now carrying unliquidatable bad debt from the attacker's borrowing position against stolen rsETH. Solidity auditor 0xQuit flagged on X that partial withdrawals from the WETH pool may only become available after Aave's Umbrella backstop mechanism settles the deficit.

SparkLend - rsETH markets frozen as a precautionary measure.

Fluid - rsETH markets frozen.

Upshift Finance - Deposits and withdrawals to High Growth ETH and Kelp Gain vaults paused pending investigation. USDC and EarnAUSD vaults confirmed to have zero rsETH exposure.

Multiple protocols across L2s - rsETH is deployed on Base, Arbitrum, Linea, Blast, Mantle, Scroll, and more than a dozen other networks. With the Ethereum backing reserve drained, holders of wrapped rsETH on these chains now face the question of whether their tokens have real underlying value. Redemption pressure from L2 holders flows back to the Ethereum supply, potentially forcing KelpDAO to unwind restaking positions to honor withdrawals; a feedback loop that compounds the protocol's immediate solvency stress.

This is not just a KelpDAO problem. Every protocol that whitelisted rsETH as collateral made an implicit assumption: that the underlying token remained fully backed and properly secured. That assumption has been invalidated. The incident will force a broad re-evaluation of risk parameters for liquid restaking tokens across the lending ecosystem.

Root Cause Analysis: What We Know So Far

Root cause is still under active investigation. Based on current on-chain evidence, Blockaid assesses the following.

The attack did not exploit any vulnerability in LayerZero's on-chain contracts, the rsETH token contract, or KelpDAO's OFTAdapter. All of these operated exactly as designed. The failure was in the off-chain infrastructure of the single DVN configured to verify the Unichain-to-Ethereum pathway.

The most likely scenarios are: (1) direct compromise of the DVN's private signing keys, through operational security failure, social engineering, or infrastructure breach; or (2) compromise of the DVN operator's off-chain node or message-delivery pipeline, enabling an attacker to inject fraudulent signed attestations without possessing the underlying keys. The first scenario implies the DVN's key management was breached. The second implies a software or infrastructure compromise at the DVN execution layer.

Either way, the root structural failure is the 1-of-1 DVN configuration. A compromised single signer, regardless of attack vector, is sufficient to authorize any arbitrary message on any pathway it secures. No multi-party threshold existed to catch the fraud.

The investigation is ongoing. We will publish an updated post-mortem as root cause is confirmed.

What This Means for OFT and OApp Operators

This incident establishes a clear and urgent message for every protocol using LayerZero's OFT standard: a 1-of-1 DVN configuration is a single point of failure. If that verifier is compromised, your bridge is compromised, regardless of how robust your smart contracts are.

Blockaid recommends the following.

Immediately audit your DVN configuration - Use the script above or call getConfig directly on the EndpointV2 contract. Identify every pathway where requiredDVNCount equals 1 and optionalDVNCount equals 0. These are your highest-risk pathways.

Move to a >=2-of-N required DVN configuration on all high-value pathways - Select two independent required DVNs from separate operators, for example the LayerZero default DVN and Google Cloud, or Polyhedra, such that both must independently attest to a message before it can execute. An attacker must then compromise two independent verification infrastructures simultaneously, which is a materially higher bar.

Consider optional DVN thresholds as additional defense in depth - Configuring one or two optional DVNs with a threshold of 1 provides a third verification layer without requiring unanimous consensus, balancing security with liveness.

Assess your escrow exposure - If your OFTAdapter holds a large backing reserve, the blast radius of a DVN compromise is proportional to those holdings. High-value escrow pathways warrant the strictest possible DVN configuration.

Monitor for anomalous message delivery - Blockaid's Onchain Monitoring platform surfaces abnormal cross-chain message patterns, including messages where source-chain transaction state does not match claimed delivery data. This class of attack, a forged message with no source transaction, is detectable in real time with appropriate monitoring in place.

How Blockaid Could Have Helped

Blockaid's Onchain Monitoring platform detected this attack in near-real time, identifying a large anomalous transfer to a new address that had been funded via Tornado Cash, as well as a transfer that was recorded on one-side that never originated from the source chain. A customer alert was issued immediately. But detection after the fact, while critical for response, is only one layer of what Blockaid's platform provides. Had the DVN operator been using Cosigner and Onchain Monitoring, multiple independent controls could have been in place to prevent or contain the exploit well before the funds left the escrow.

Additional signing authority on the DVN - While the exact internal setup of the compromised DVN is still under investigation, the core failure was a single signer holding full authority over a $292M escrow. Blockaid's recommendation is to configure the DVN's signing infrastructure as a multisig, with Cosigner acting as a required co-signer on any transaction it authorizes. Cosigner plugs into Safe, Fireblocks, Squads, and other major multisig and MPC wallet providers, and acts as an independent, policy-enforcing validation layer that sits between transaction creation and execution. It cannot be phished, deceived by a spoofed UI, or socially engineered. Had it been in place here, the forged message could not have been co-signed and executed regardless of how many other signers were compromised.

Proactive posture-risk flagging - Before this incident ever occurred, Blockaid would have flagged the 1-of-1 DVN configuration as an unacceptable risk posture during a security review. We have a broad network of customers, ranging from Centralized Exchanges to protocols, asset managers, DeFi apps and trad-fi institutions, and we work closely with our customers to deploy effective risk policies through our Onchain Monitoring and Cosigner platforms. Our policy engine is designed to surface structural vulnerabilities before they become liabilities. The immediate steps protocols should take to eliminate single-signer scenarios are outlined in Blockaid's public thread.

Pre-transaction protection - Using Cosigner, a policy could have been configured to cap the maximum number of tokens transferable in a single transaction from the OFTAdapter. A transaction attempting to release 116,500 rsETH in one operation would have breached that threshold and been blocked at the transaction level, before it was ever submitted on-chain. The exploit would have been stopped before execution regardless of whether the DVN had been compromised.

Post-transaction monitoring - In parallel, Blockaid's Onchain Monitoring platform would have had a dedicated monitor configured against the OFTAdapter and associated bridge wallets. A transfer of this magnitude, to a new address with Tornado Cash funding history, would have triggered an immediate automated alert and response workflow: notifying the security team via Slack, flagging the addresses as malicious, and optionally triggering an automatic contract pause or cosigner denial for any follow-on transactions. This is exactly the kind of anomalous activity Blockaid's battle-tested ML models are built to catch - large suspicious transfers, unusual function calls, and wallet behavior linked to known obfuscation infrastructure. Our alerts not just protect our own customers, but can also prevent contagion from downstream effects of exploits.

Together, these layers represent the difference between an incident that is prevented and one that is merely investigated after the fact. The KelpDAO exploit is a stark illustration of why bridge security cannot rely on a single off-chain trust assumption, and why real-time protection across the full transaction lifecycle, from posture assessment through pre-transaction simulation to post-transaction monitoring, is now a baseline requirement for any protocol custodying significant value.

Phishing Warning

In the hours following the exploit, Blockaid's threat intelligence team identified active phishing campaigns impersonating KelpDAO on X, directing rsETH holders to "migrate" their tokens to a new contract. Analysis of the campaign revealed several old accounts repurposed by scammers, with a burst of 9 KelpDAO retweets executed in a 6-minute window between 19:34 and 19:41 UTC; a textbook account hijack timed to the incident.

The phishing domain portal-kelpdao.com was registered on April 18, 2026, the day of the exploit, and impersonates the legitimate kerneldao.com. There is no migration. Do not interact with any link claiming otherwise. All known phishing domains and addresses associated with this campaign have been flagged in the Blockaid platform.

The Broader Pattern

This is the second exploit exceeding $292M to hit DeFi in the past 17 days. On April 1, Drift Protocol was drained of $285M through a multi-week social engineering campaign targeting its Security Council multisig signers. The Drift incident exploited the key management layer. This incident exploits the bridge verification layer. The common thread is identical: the attack surface in modern DeFi is no longer primarily the smart contract code. It is the off-chain infrastructure, key management, and trust assumptions that smart contracts delegate to.

Smart contract audits remain necessary. They are not sufficient. KelpDAO's OFTAdapter passed its audit. The LayerZero contracts passed their audits. The exploit required no on-chain vulnerability; only the compromise of a single off-chain signer set that one configuration decision gave absolute authority over a $292M escrow.

The Drift hack is an example of why you need a co-signer on privileged key operations. The KelpDAO hack is an example of why you need multi-party bridge monitoring and >=2-of-N DVN configurations. Both incidents point toward the same structural gap: protocols are deploying production-grade smart contracts while operating off-chain security infrastructure at a fraction of the rigor those contracts deserve.

Conclusion

The KelpDAO exploit of April 18, 2026 will be studied as the definitive case study in bridge DVN configuration risk. It did not require a zero-day. It did not require weeks of preparation or social engineering. It exploited a weak governance policy and limited controls to create systemic contagion impact on the entire ecosystem.

116,500 rsETH, approximately $292M, left KelpDAO's Ethereum escrow in a single transaction. The mechanism that should have prevented this was present in the protocol. It was simply configured with no redundancy.

If you operate a LayerZero OFT or OApp: audit your DVN configuration today.

Blockaid will continue publishing updates as our co-investigation with SEAL, KelpDAO, and LayerZero Labs develops. A full post-mortem covering DVN root cause, confirmed fund flows, and remediation recommendations will follow.

Exploiter: 0x1F4C1c2e610f089D6914c4448E6F21Cb0db3adeF 

Compromised DVN: 0x589dedbd617e0cbcb916a9223f4d1300c294236b 

OFTAdapter (victim): 0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3 

Status: All entities marked malicious across the Blockaid platform. Active warnings in effect.

About Blockaid

Blockaid is the onchain security platform trusted by the largest companies operating in Web3. Built by veterans of elite intelligence and cybersecurity units, Blockaid provides end-to-end protection for financial institutions, protocols, and end users — combining direct wallet and dApp integrations with real-time monitoring, detection, and response across smart contracts, infrastructure, and externally owned accounts. Since 2025, Blockaid scanned over 6.3+ billion transactions and blocked 585+ million attacks. Blockaid is the security infrastructure behind Coinbase, MetaMask, Uniswap, Safe, and dozens of the most widely used platforms in the industry.

Learn more at blockaid.io, and follow us on Twitter and LinkedIn.