Kelp DAO disputes LayerZero's claim, argues 'default' settings led to $290 million loss

A recent cryptocurrency incident has sparked a heated debate, with Kelp DAO and LayerZero pointing fingers at each other. The issue began when Kelp DAO's liquid restaking protocol was exploited, resulting in a massive $290 million loss. According to sources, Kelp DAO plans to dispute LayerZero's claim that the protocol ignored warnings about its single-verifier setup. Instead, Kelp DAO argues that the compromised verifier was part of LayerZero's own infrastructure and that the setup was based on LayerZero's default configuration. The incident occurred when attackers drained 116,500 rsETH, worth approximately $290 million, from Kelp's LayerZero-powered bridge by poisoning the servers that LayerZero's verifier relied on to check transactions. Kelp DAO claims that the attackers compromised two of LayerZero's own servers, which were used to verify cross-chain transactions, and then flooded the backup servers with junk traffic to force LayerZero's verifier onto the compromised ones. The source also contested LayerZero's framing of the '1/1 configuration' as a fringe choice made against guidance, stating that LayerZero's own quickstart guide and default GitHub configuration point to a 1/1 DVN setup. Security researchers have also questioned LayerZero's isolated framing, which pinned the blame on Kelp DAO. Yearn Finance core team developer Artem K posted a technical review of LayerZero's public deployment code, stating that the reference setup ships with single-source verification defaults across every major chain. Chainlink community manager Zach Rynes accused LayerZero of 'deflecting responsibility' for its own compromised infrastructure and throwing Kelp DAO under the bus for trusting a setup LayerZero itself supported. In response, LayerZero has said it will no longer sign messages for any application running a single-verifier setup, forcing a protocol-wide migration. Kelp DAO has confirmed that the 1-of-1 DVN setup at the center of the incident reflects LayerZero's documented default configuration, and the team has operated on LayerZero infrastructure since January 2024, maintaining close communication with the LayerZero team.