Crypto Community Slams LayerZero: More Verifiers Won’t Stop The Next $290M Hack

LayerZero is facing heavy criticism for its response to the recent $290 million KelpDAO exploit after the omnichain interoperability protocol blamed Kelp’s 1-of-1 verifier configuration for the incident.

LayerZero Blames KelpDAO For $290M Exploit

Over the weekend, liquid restaking protocol KelpDAO was the victim of an attack that drained over $290 million in rsETH from the project after malicious actors exploited a weakness in the protocol’s LayerZero-powered bridge.

Two days later, LayerZero addressed the incident, which became the largest DeFi hack of 2026, just weeks after Drift Protocol’s $285 million exploit shocked the industry.

LayerZero attributed the “highly sophisticated attack” to North Korea’s Lazarus Group, claiming that it was a crypto infrastructure attack rather than a protocol exploit, and affirming that “there is zero contagion to any other cross-chain assets or applications.”

They explained that the protocol is built on a “foundation of modular, application-configurable security,” using Decentralized Verifier Networks (DVNs), independent entities responsible for verifying the integrity of cross-chain messages.

The malicious actors allegedly poisoned downstream RPC infrastructure by “compromising a quorum of the RPCs the LayerZero Labs DVN relied upon to verify transactions.”

Per the post, the attackers swapped binaries for a custom payload to forge messages and used DDoS attacks to force failover to the poisoned nodes, triggering the DVN into confirming fake transactions.

Based on this, LayerZero placed responsibility on KelpDAO for using a 1-of-1 verifier configuration instead of the multi-DVN recommendations: “This incident was isolated entirely to KelpDAO’s rsETH configuration as a direct consequence of their single-DVN setup.”

Crypto Community Criticizes ‘Lack Of Accountability’

The crypto community reacted to the post-mortem, sharing its concerns about LayerZero’s response and criticizing the protocol for placing all responsibility only on Kelp’s security setup.

“Imagine building a bridge and vehicles pays to cross, the bridge collapsed and you said it’s their fault for crossing the bridge. A classic clownery act from Bunch of clowns with zero accountability,” X user Saint wrote.

Others questioned why LayerZero included a “1-of-1” configuration if the purpose of a DVN is customizable/modular security. “If the system allows this option, it’s not the fault of the customer who chose it—it’s a fundamental design flaw by the system that permitted it,” user Ditto wrote.

“At the end of the day, the fact remains that the DVN RPC was compromised. DVN is a LayerZero product, and they are the ones who sold it to these teams,” he continued.

Similarly, Chainlink community manager Zach Rynes accused the protocol of deflecting responsibility for the compromise of their own DVN node.

He also criticized them for “throwing KelpDAO under the bus” for trusting LayerZero Labs’ setup that they “willingly support and only blocked after getting hacked, all while claiming everything worked as designed.”

Meanwhile, Yearn Finance core team developer Artem K noted on X that the attack was described as a compromise of an RPC node and RPC poisoning, but that their own infrastructure is what was compromised. “Given it doesn’t say how the breach has occurred, I wouldn’t rush re-enabling the bridges,” he added.

Analyst The Smart Ape also claims that LayerZero made the wrong diagnosis and offered the wrong solution. Notably, the protocol’s post-mortem suggested migrating all applications with 1-of-1 DVN configurations to multi-DVN setups to prevent similar attacks.

However, the analyst pointed out that multi-verifiers won’t stop the next multi-million-dollar attack, asserting that they could fail as all DVNs read chain states from the same handful of RPC providers, which are mostly clustered on AWS or GCP.

If five “independent” DVNs read from the same three RPC providers, an attacker who poisons those three RPCs will poison all five verifiers simultaneously. “If all your verifiers get fooled in the same way at the same time, the math collapses back to 1-of-1. Five clones are not five witnesses,” he added.

To solve this, the analyst suggested that every verifier runs its own full node on different client software, hosted on different cloud providers, maintained by different ops teams, peered with different subsets of the Ethereum network.

“The fix isn’t multi-anything. The fix is that verifiers should attest to their own substrate, not just to chain state. until you can audit a DVN’s upstream topology, which RPC providers, which client software, which clouds, which regions, ‘M-of-N secured’ is marketing copy for a property that hasn’t actually been built. Lazarus didn’t break cryptography on April 18. They broke three servers,” he concluded.