[ENG] What LayerZero DVNs See, What Cosmos IBC Light Clients See

A structural comparison of cross-chain verification, surfaced by the KelpDAO $290M exploit

Apr 22, 2026

On April 18, 2026, KelpDAO lost 116,500 rsETH. At roughly $290M, it is the largest DeFi hack of the year.

The LayerZero post-mortem is technically clear. The protocol code was not compromised. DVN contracts, key management, OApp Solidity code, none of that was touched. What was compromised were two op-geth RPC nodes polled by the LayerZero Labs DVN, plus a DDoS on healthy external RPCs that forced failover to the poisoned ones.

No on-chain code was broken, yet a “verified” cross-chain message was forged and executed. Understanding how that is possible means looking at what the DVN structurally verifies. That structure becomes sharper when you contrast it with how Cosmos IBC is designed.

1. DVNs see a signature. Light clients see the state.

When Ethereum accepts “this message originated on Unichain” in LayerZero, the Ethereum endpoint checks exactly one thing: did the DVN set configured by the OApp post an attestation over this message’s payloadHash?

If the attestation arrives, the message executes. Ethereum does not store Unichain block headers. It does not recompute Unichain’s state transitions. It trusts the DVN’s claim that the event happened. The DVN produces that claim by polling a configured RPC endpoint for the source-chain event, taking whatever answer comes back, and signing it for posting to the destination. That is the full chain of custody.

What the destination chain ultimately trusts is the DVN signer’s signature, not the source chain’s state.

IBC is designed differently. A light client of the source chain lives on the destination chain. That light client knows the source chain’s validator set. When a new header comes in, it verifies directly that at least 2/3 of the validator set has signed it. Validator set rotations are tracked through UpdateClient. When a packet arrives, the destination chain independently runs a Merkle proof against the AppHash held by the light client, checking that the message is actually included in the source chain’s state, following ICS-23.

A relayer carries the headers and proofs, but the relayer is not trusted. The destination chain recomputes everything itself, so a lying relayer just produces a proof that fails verification. The unit of trust is not “who delivered it” or “who signed it,” but “the source chain’s own consensus.”

This model is not fully trustless. The ibc-go documentation calls IBC “trust-minimized,” not trustless. If 2/3 or more of the source chain’s validators collude, the AppHash they produce can itself be a lie, and the light client gets deceived. The cost of that attack, however, is capturing the source chain’s consensus, which is on-chain economic security. That is a different economic unit from compromising a handful of off-chain nodes.

Both models carry real tradeoffs. The light-client approach is bounded by chain-pair feasibility. Consensus types must be compatible, the client implementation has to be deployed on the destination, and update frequency and gas cost are nontrivial. Connecting arbitrary chains quickly is hard. The attestation approach works across any pair and is cheap, but it pushes the question of “how does the verifier know the source chain’s state” onto each operator.

This incident is what happens when that question breaks down. The DVN does not independently reconstruct chain state. It asks an RPC and takes the answer. Poison those RPCs and DDoS the healthy ones, and the DVN’s picture of the source chain is itself fabricated. On top of a fabricated picture, the DVN signed honestly and the destination chain verified the signature honestly. There is no line of code anywhere that you can point to and say “this is where the lie entered.”

2. Multi-DVN is necessary but not sufficient

LayerZero’s public position is simple. KelpDAO ran a 1-of-1 DVN setup, so it got hit. A multi-DVN setup would have prevented this. The post-mortem states that multi-DVN redundancy has been LayerZero’s consistent recommendation to integrators.

KelpDAO pushed back publicly. It says it has been running on LayerZero since January 2024, had a direct communication channel open since July 2024, and had the default configuration confirmed as appropriate when rsETH expanded to L2s. Kelp says it was never told to change the DVN setup specifically.

The numerics from Dune shortly after the incident: of 2,665 active LayerZero OApps, 47% use a 1-of-1 DVN setup. Why that fraction is so large is not a mystery. The sample layerzero.config.ts in the LayerZero V2 OApp Quickstart ships with one required DVN and zero optional DVNs. Yearn’s banteg confirmed separately that LayerZero’s public deployment code ships single-source verification as the reference across Ethereum, BSC, Polygon, Arbitrum, and Optimism. The official recommendation and the default shipping 1/1 can both be true at the same time.

Set the default problem aside and ask the structural question. Does having N DVNs actually give you N times the safety?

If five “independent” DVNs all read source-chain state from the same three RPC providers, an attacker who poisons those three providers forces all five DVNs to see the same forged state and produce the same valid signatures. M-of-N only does real work when each N is an independent failure domain.

This incident fits that proposition exactly. KelpDAO’s rsETH bridge was configured at the OApp layer with one required DVN. That is the 1-of-1 configuration. Whether that single DVN internally uses one signer or a multi-signer setup has not been disclosed publicly by LayerZero. Whatever the internal signing policy is, if the input to that policy, the observation of the source chain, comes through the same RPC, the outcome is the same. Multiple signers observe the same lie and produce multiple valid signatures. They do not cross-check independent observations.

Majority safety comes from how many different observations exist, not how many signatures exist. This attack is the case where that distinction was real on paper and absent in operation.

Assume we raised the DVN count at the OApp layer from 1 to 3. If those three DVNs all run the same binary image that LayerZero Labs distributes and all depend on the same class of public RPC provider, the attack surface is materially unchanged. The count goes up, the correlation stays the same.

Correlation axes worth auditing:

Binary implementation. Do they share the same image or the same codebase? LayerZero typically distributes the DVN binary to partner operators, which creates shared-implementation risk by default.
RPC dependency. Do they hit the same public endpoints (Infura, Alchemy) or run independent full nodes? Are RPCs IP-whitelisted private, or open public?
Client implementation. All op-geth? All Reth? Is there a single client-level zero-day exposure?
Hosting. All on AWS us-east-1? Are regions, clouds, and ISPs diversified?
Operating entity. Legally separate companies, or different brands under the same parent? Contractually independent?

SEAL’s advisory, published two days after the incident, calls this out directly. Teams need to exhaustively map their supply chain. The real risk is hidden correlation, the “3-of-5 multisig where 4 signers use the same custodian” pattern. Raising the count is trivial. Actually achieving independence requires deliberate work on each axis.

The contrast with the light-client model is sharp. Imagine running three independent light-client instances. What each verifies is the source chain’s validator signatures and its AppHash. Forging those signatures requires actually compromising 2/3 of the source chain’s validator set. Even if all three instances happen to read header data from the same RPC, signature verification still runs independently in each instance. A lying RPC produces a proof that fails verification, not a forged state that propagates. The light client verifies what is attached to the data, not how the data was delivered.

The DVN verifies the RPC response itself. Nothing is attached to that response. Poison the RPC and the whole thing travels downstream.

3. April 18: how the difference showed up

Two large incidents hit 18 days apart in 2026. Drift Protocol lost $285M on April 1. KelpDAO lost $290M on April 18. Combined: $575M. Both are attributed to North Korea’s Lazarus Group, specifically the TraderTraitor sub-unit.

Neither was a smart-contract bug. Drift was social engineering against governance signers. KelpDAO was infrastructure penetration against the RPCs the DVN depended on. As Blockaid noted, both exits sit outside the scope of smart-contract audits.

The attack, step by step:

Reconnaissance, RPC list acquisition. The attacker obtained the list of RPC nodes the LayerZero Labs DVN polls. The LayerZero statement says only that “the attacker was able to gain access to the list of RPCs our DVN uses.” How that list leaked is not disclosed. The initial intrusion vector remains unexplained in the public record.
RPC node compromise, binary swap. The binaries running on two op-geth nodes, hosted in separate clusters, were replaced with malicious versions. The DVN instances themselves were not breached. Least-privilege isolation held.
Selective forgery, monitoring evasion. The malicious binary returned forged data only to the DVN’s IP, while returning honest data to every other IP (LayerZero Scan, external observers). LayerZero wrote that the design “was carefully designed to prevent any security monitoring from noticing anomalies.” LayerZero’s own anomaly detection was effectively blinded during the window.
DDoS to force failover. The DVN runs a redundant RPC setup across internal and external providers, so compromising two nodes was not enough. A DDoS was mounted against the healthy external RPCs, forcing failover to the poisoned ones. The window was 10:20 a.m. to 11:40 a.m. PT on April 18. LayerZero published the external RPC traffic graph showing the DDoS peak.
Message forgery. Once failover triggered, the poisoned nodes reported a Unichain transaction that never happened. Whatever internal signing policy the DVN uses, its input all came from the same poisoned RPC, so a valid attestation was produced and the 1-DVN requirement Kelp had configured was met. The Ethereum OFTAdapter then released 116,500 rsETH to the attacker through lzReceive.
Anti-forensics. Once the window closed, the malicious binary self-destructed. LayerZero’s statement: “It was designed to self-destruct once the attack could no longer be performed, disabling the RPCs, deleting the malicious binary and corresponding local logs and configs.” Disable the RPC daemons, wipe the binary, wipe the logs, wipe the configs. That pattern is standard APT tradecraft.

What matters here is that the attacker thought like a network operator, not a smart-contract attacker. Reconnaissance, pivot, selective deception, availability-to-integrity downgrade, anti-forensics. Those are familiar to a web2 security team, not to a Solidity auditor.

The structural reason this attack succeeded is that the destination chain only verifies “what the DVN said.” If the destination chain had verified “what the source chain’s validators signed,” RPC poisoning and DDoS would produce failures, but not forged messages. None of the six steps above forges a source-chain validator signature.

In the DVN model, the compromise of off-chain nodes propagates all the way to destination-chain approval. In the light-client model, off-chain compromise stops at “signature verification failed.” That difference is structural.

Closing

This is not a takedown of LayerZero specifically. Attestation-based verifier models are a legitimate option for chain pairs that a light client cannot reach, and this incident does not invalidate that design choice. Where the destination chain cannot natively run the source’s light client, whether because of a missing implementation or an incompatible proof system, an attestation layer like the DVN is a practical way around the limit.

The design decision, though, requires that “what is the verifier ultimately looking at” be asked explicitly. DVNs see RPC responses. Light clients see validator signatures and Merkle proofs. The first accepts “someone’s report about the chain’s state.” The second accepts “the chain’s state itself.” What broke on April 18 was the first model’s premise.

When evaluating cross-chain infrastructure, “how many DVNs in the set” is the second question. The first question is “what are those verifiers ultimately looking at.” The answer to that determines whether an attacker has to break a handful of off-chain nodes, or the source chain’s consensus itself.

References

jinuahn

Discussion about this post

Ready for more?