LayerZero Bridge Hack: How Single Verifier Caused $290M Loss

On April 18, 2026, the crypto world witnessed one of the most sophisticated cross-chain bridge attacks in DeFi history. The LayerZero bridge vulnerability — a failure in single-verifier configuration combined with RPC infrastructure compromise — enabled hackers to drain 116,500 rsETH ($290 million) from Kelp DAO without exploiting smart contract code. This incident exposed fundamental weaknesses in how cross-chain bridges verify transactions across blockchains.

Key Takeaways:The $290 million Kelp DAO exploit succeeded because Kelp DAO operated a 1-of-1 DVN (Decentralized Verification Network) configuration, creating a single point of failure where one compromised verifier could authorize any cross-chain message.Attackers compromised two independent RPC nodes and launched DDoS attacks against legitimate validators, forcing the LayerZero message verification system to rely entirely on malicious infrastructure feeding false transaction data.The vulnerability was an infrastructure-level attack rather than smart contract exploit: attackers controlled the blockchain data layer that the cryptographic verification system depended upon, bypassing even theoretically sound verification logic.The exploit triggered $15 billion in withdrawals across DeFi protocols and created $195 million in bad debt on Aave V3, demonstrating how bridge vulnerabilities create systemic risk across the ecosystem.North Korea's Lazarus Group executed the attack using message forgery techniques that exploited the lzReceive function, pulling funds without any corresponding transaction on the source chain (Unichain).

Table of Contents

• LayerZero's Cross-Chain Architecture
• The Infrastructure Compromise Attack Vector
• Single-Verifier Configuration Failure
• Technical Breakdown of the Exploit
• Security Implications for Cross-Chain Bridges
• Prevention Measures and Best Practices
• Bridge Security Model Comparison
• Frequently Asked Questions

LayerZero's Cross-Chain Architecture

To understand how the LayerZero bridge vulnerability materialized, we need to examine the protocol's underlying architecture. LayerZero operates as an omnichain interoperability protocol that enables verified message passing between different blockchains without requiring wrapped tokens or traditional custodial bridges.

Core Components:

• LayerZero Endpoint: The core contract deployed on each supported chain that handles message sending and receiving
• Decentralized Verification Network (DVN): Independent validators that verify cross-chain messages
• Send/Receive Libraries: Protocol-specific logic for encoding and decoding cross-chain messages
• OFT (Omnichain Fungible Token): Token standard enabling native cross-chain functionality

The protocol's security model relies on DVNs to cryptographically verify that messages originated from the source chain before executing them on the destination chain. Each DVN runs light client verification, checking block headers and transaction inclusion proofs to ensure message authenticity.

Message Flow Process:

1. User initiates cross-chain transaction on source chain
2. Source endpoint emits PacketSent event with message payload
3. DVNs monitor source chain and verify transaction inclusion
4. DVNs submit verification proofs to destination endpoint
5. Destination endpoint validates proofs and executes message

This architecture theoretically eliminates the need for custodial intermediaries, but as the Kelp DAO incident demonstrates, the verification layer itself became the attack surface. The cross-chain bridge security depends not just on cryptographic soundness but on the resilience of external infrastructure feeding data to verifiers.

The Infrastructure Compromise Attack Vector

The $290 million exploit wasn't a traditional smart contract vulnerability. Instead, LayerZero attributed the attack to North Korea's Lazarus Group, specifically the TraderTraitor subunit, which executed a sophisticated infrastructure-level compromise.

Phase 1: RPC Node Infiltration

The attackers targeted the verification infrastructure by compromising two independent RPC (Remote Procedure Call) nodes that DVNs relied upon for blockchain data. This wasn't a simple server breach — the attackers replaced legitimate software binaries with malicious versions designed to intercept and manipulate transaction data.

RPC nodes serve as the data layer between DVNs and blockchain networks. When a DVN queries blockchain state to verify a cross-chain message, it relies on RPC responses to determine transaction validity. By controlling these nodes, attackers could feed false information to the verification process.

Phase 2: Validator Network Disruption

Simultaneously, the attackers launched distributed denial-of-service (DDoS) attacks against functioning RPC nodes. This created a network partition scenario where legitimate validators couldn't access accurate blockchain data, forcing the system to rely on the compromised infrastructure.

The timing was crucial. According to on-chain analysis from blockchain investigator banteg, the attack occurred at 2026-04-18 17:35 UTC, with Kelp DAO detecting and pausing the system at 18:21 UTC — a 46-minute window. This demonstrates the critical importance of infrastructure security in preventing DeFi exploits, similar to patterns seen in other major bridge attacks.

Single-Verifier Configuration Failure

The technical root cause of the exploit lies in Kelp DAO's verification configuration. Despite LayerZero offering multi-DVN security models, Kelp DAO operated with a single-verifier setup — a 1-of-1 configuration that created a catastrophic single point of failure.

How DVN Verification Works:

In a properly configured multi-DVN setup, cross-chain messages require verification from multiple independent validators. For example, a 2-of-3 configuration means at least two out of three DVNs must confirm message validity before execution. This creates redundancy — even if one DVN is compromised, the others can prevent fraudulent transactions.

However, Kelp DAO's 1-of-1 configuration meant that compromising a single verifier could authorize any cross-chain message. When attackers gained control of the RPC infrastructure feeding data to this sole verifier, they essentially gained control over the entire verification process.

LayerZero's Default Configuration Controversy:

The incident sparked a dispute over responsibility. Kelp DAO claimed that LayerZero's default onboarding settings used the vulnerable single-verifier model, essentially arguing that following LayerZero's standard setup led to the compromise.

LayerZero countered that they had recommended multi-DVN configurations to Kelp DAO and that the protocol provided tools for more secure setups. This highlights a critical tension in DeFi bridge design: ease of deployment versus security maximization. Understanding trustless bridge design principles becomes essential when evaluating which bridges minimize such configuration risks.

Technical Breakdown of the Exploit

The exploit's execution involved sophisticated manipulation of LayerZero's message verification system. Let's examine the technical mechanics that enabled 116,500 rsETH to be drained from Ethereum without any corresponding debit on the source chain (Unichain).

Message Forgery Mechanism:

The attackers exploited the `lzReceive` function on LayerZero's EndpointV2 contract. This function is designed to process incoming cross-chain messages after DVN verification. In normal operation: (1) DVN verifies message authenticity on source chain, (2) DVN submits verification proof to destination endpoint, (3) `lzReceive` processes the verified message, and (4) token transfer executes on destination chain.

However, with compromised RPC infrastructure, the attackers could forge verification proofs. The malicious RPC nodes provided false blockchain data indicating that a legitimate transfer had occurred on Unichain, when no such transaction existed.

On-Chain Evidence Analysis:

Based on banteg's technical investigation, the Ethereum delivery transaction `0x1ae232da212c45f35c1525f851e4c41d529bf18af862d9ce9fd40bf709db4222` released 116,500 rsETH from the bridge's inventory but wasn't backed by any legitimate source-side debit on Unichain.

Key technical indicators include: (1) PayloadVerified Event emitted at 17:33:35 UTC indicating DVN approval, (2) Transfer Execution occurring between 17:35:11 and 17:35:35 UTC, (3) Source Chain Analysis showing no corresponding rsETH lock or burn on Unichain, and (4) Emergency Response with TransfersBlocked event at 18:23:11 UTC.

Attack Transaction Flow:

1. Attacker wallet triggers `lzReceive` on Ethereum LayerZero endpoint
2. Compromised RPC provides fake verification data
3. Single DVN approves based on manipulated information
4. Kelp's rsETH OFT adapter releases 116,500 tokens
5. Funds transfer to attacker-controlled address

Security Implications for Cross-Chain Bridges

The Kelp DAO exploit exposed fundamental vulnerabilities in cross-chain bridge security models that extend far beyond LayerZero. The incident demonstrated how infrastructure-level attacks can bypass cryptographic protections when verification systems contain single points of failure.

Trust Assumptions in Bridge Design:

Cross-chain bridges operate on various trust assumptions: Custodial Bridges require users to trust a centralized entity holding funds, Multi-Sig Bridges require trust in a committee of validators, Light Client Bridges rely on cryptographic proofs and verification logic, and Optimistic Bridges depend on fraud proofs and challenge periods.

LayerZero's model falls into the light client category, but the Kelp incident shows that even cryptographically sound verification can be undermined by infrastructure compromise. When RPC nodes feeding data to light clients are controlled by attackers, the entire verification process becomes unreliable.

Systemic Risk Propagation:

The hack triggered $15 billion in withdrawals across DeFi, demonstrating how bridge vulnerabilities create systemic risk. Aave V3 accumulated $195 million in bad debt from stolen rsETH used as collateral, while secondary protocols like SparkLend, Fluid, and Upshift froze markets. rsETH lost its ETH peg across multiple chains, and the broader DeFi ecosystem experienced significant capital flight. This shows that understanding safe cross-chain trading practices is essential for DeFi participants.

Prevention Measures and Best Practices

The LayerZero bridge vulnerability reveals several critical security practices that could have prevented or mitigated the exploit. Understanding these measures is essential for both protocol developers and users evaluating cross-chain bridge security.

Multi-DVN Configuration:

The most direct prevention would have been implementing a multi-DVN setup. Instead of relying on a single verifier, Kelp DAO could have configured multiple independent DVNs with different RPC providers and verification infrastructure. Recommended configurations include: Minimum 2-of-3 providing basic redundancy against single point failures, Geographic Distribution with DVNs in different jurisdictions reducing coordinated attack risk, Infrastructure Diversity using different RPC providers and technical stacks, and Economic Incentives through slashing conditions and penalties for malicious behavior.

RPC Infrastructure Hardening:

Since the attack vector targeted RPC nodes, protocols should implement comprehensive RPC security measures: (1) Query multiple independent providers and compare responses, (2) Require majority agreement across RPC sources, (3) Verify blockchain data integrity using merkle proofs, (4) Prevent DDoS attacks with intelligent traffic management, and (5) Deploy real-time alerting systems for RPC response anomalies.

Emergency Response Mechanisms:

Kelp DAO's 46-minute response time, while relatively fast, still allowed complete drainage. More proactive measures include: Automated Circuit Breakers that pause large withdrawals when unusual patterns are detected, Multi-Signature Admin Controls requiring multiple parties to authorize emergency actions, Gradual Withdrawal Limits implementing time-locked large transfers, and Real-Time Monitoring systems for cross-chain balance discrepancies.

Bridge Security Model Comparison

Understanding how different cross-chain bridges handle security can help users and developers make informed choices. The comparison below shows major bridge architectures and their vulnerability profiles.

Teleswap represents a different approach to trustless Bitcoin bridging. Rather than relying on off-chain verifiers or custodians, Teleswap uses SPV (Simplified Payment Verification) light client proofs verified directly on-chain. This eliminates the RPC infrastructure attack vector that compromised LayerZero, as verification occurs through cryptographic proofs of Bitcoin transactions rather than trusted data feeds.

SPV Verification Advantages:

Teleswap's architecture offers distinct benefits: (1) No Off-Chain Dependencies with verification logic running entirely on destination chain, (2) Bitcoin-Native Security inheriting Bitcoin's proof-of-work security model, (3) Infrastructure Resilience with no RPC nodes or external validators to compromise, and (4) Transparent Verification with all proof validation occurring in publicly auditable smart contracts.

However, SPV verification is currently limited to Bitcoin due to its UTXO model and proof-of-work consensus. For other assets and chains, multi-DVN configurations remain the best available option for reducing single points of failure. The key lesson from the LayerZero exploit is that bridge security depends not just on cryptographic design but also on operational implementation. Even theoretically secure protocols can fail when deployed with suboptimal configurations or insufficient infrastructure hardening.

Due Diligence Framework for Bridge Users:

Before using any cross-chain bridge, users should evaluate: (1) Verification Model including single validator vs. multi-validator consensus, (2) Infrastructure Dependencies showing number and diversity of RPC providers, (3) Emergency Controls including pause mechanisms and response procedures, (4) Historical Security through past incidents and response quality, and (5) Economic Incentives with validator penalties and insurance mechanisms.

Frequently Asked Questions

What exactly is the LayerZero bridge vulnerability that caused the $290M loss?

The vulnerability was a combination of Kelp DAO's single-verifier (1-of-1 DVN) configuration and compromised RPC infrastructure that allowed attackers to forge cross-chain messages. Attackers compromised two independent RPC nodes feeding data to LayerZero's sole Decentralized Verification Network, enabling them to drain 116,500 rsETH without any corresponding transaction on the source chain. This was an infrastructure-level attack rather than a smart contract code exploit.

How did attackers bypass LayerZero's cryptographic verification system?

They controlled the data layer that the verification system depended upon by replacing legitimate RPC node software with malicious versions. By compromising two key RPC nodes and launching DDoS attacks against functioning nodes, attackers fed false blockchain data to the single DVN. The cryptographic verification system itself worked as designed, but it verified false data, making fraudulent transactions appear legitimate.

Could multi-DVN configuration have prevented this exploit?

Yes, a properly configured multi-DVN setup would have significantly reduced the attack's likelihood of success and made the exploit nearly impossible. With multiple independent verifiers using different RPC providers and infrastructure, attackers would need to compromise multiple systems simultaneously rather than just one. A 2-of-3 configuration would have required compromising at least two independent verification systems, exponentially increasing attack cost and complexity.

Why did LayerZero and Kelp DAO dispute responsibility for the vulnerability?

Kelp DAO claimed that LayerZero's default onboarding settings used the vulnerable single-verifier configuration, while LayerZero stated they had recommended multi-DVN setups. This dispute highlights the tension between deployment simplicity and security maximization in bridge design. Kelp DAO's argument centered on LayerZero providing insecure default settings, while LayerZero countered that more secure configurations were available and recommended.

What makes this attack different from other bridge hacks?

This was an infrastructure-level attack targeting the external data systems that verification depends on, rather than exploiting smart contract bugs. Instead of finding code vulnerabilities, attackers compromised RPC nodes and the data feeds they provide. This attack vector is particularly dangerous because it can affect multiple protocols simultaneously if they share infrastructure dependencies, making it a systemic risk rather than isolated protocol vulnerability.

How does LayerZero's security compare to other bridge models?

LayerZero's light client verification is theoretically sound but practically depends on external RPC infrastructure, unlike SPV-based bridges like Teleswap that verify on-chain or custodial models with clear trust assumptions. Custodial bridges like WBTC centralize trust in a single entity, threshold signature schemes like tBTC distribute trust through cryptographic computation, SPV bridges like Teleswap verify transactions directly on-chain eliminating external dependencies, while multi-DVN LayerZero configurations distribute verification across independent verifiers. The Kelp DAO incident shows LayerZero's vulnerability to infrastructure compromise.

What specific security measures should users prioritize in cross-chain bridges?

Users should prioritize bridges with multi-validator consensus, diverse infrastructure providers, and strong emergency response mechanisms that have been tested under actual incidents. Key factors include: at least 2-of-3 multi-validator verification, geographic and technical diversity in verification infrastructure, automated circuit breakers detecting unusual withdrawal patterns, rapid response procedures proven by past incident response, and transparent communication about incidents and resolutions. Avoid single-verifier configurations entirely.