Ripple CTO Comments on Kelp DAO's $290 Million Security Breach

icon币界网
Share
Share IconShare IconShare IconShare IconShare IconShare IconCopy
AI summary iconSummary

expand icon
Ripple’s honorary CTO David Schwartz commented on Kelp DAO’s $290 million security breach, highlighting vulnerabilities in cross-chain infrastructure. The April 18 attack resulted in the theft of 116,500 rsETH, one of the largest DeFi losses in 2026. Schwartz emphasized the risks of favoring convenience over security in bridge designs. The breach exploited a one-to-one validator model on LayerZero, creating a single point of failure. Aave later faced $195 million in bad debt exposure after the stolen rsETH was used as collateral. On-chain data underscores the scale of the exploit, revealing ongoing challenges in DAO technology.
CoinDesk reports:

David Schwartz, Ripple’s Honorary Chief Technology Officer, said that the Kelp DAO vulnerability reflects a broader issue in cross-chain infrastructure. He noted that while many bridge systems offer robust safeguards, teams are often encouraged to adopt simpler solutions to reduce operational costs. Previously, on April 18, the Kelp DAO rsETH bridge was attacked, resulting in the theft of approximately 116,500 rsETH—one of the largest DeFi losses of 2026 to date. His remarks have reignited focus on how bridge operators balance speed, cost, and security when deploying products tied to large pools of funds.

Ripple's CTO links RLUSD review to security choices

David Schwartz said that while evaluating various options for RLUSD, he examined multiple DeFi bridge systems, focusing on risk and security. He wrote that many of these systems appear well-designed and include mechanisms capable of addressing the types of failures that occurred in the Kelp DAO case.

He added that the issue is not always about a lack of security tools. Instead, service providers often market themselves on ease of deployment and rapid chain expansion, assuming project teams will bypass the strongest security measures. In recent news related to Ripple’s stablecoin initiative, Schwartz described this trade-off as a recurring weakness in bridge deployments.

The Kelp DAO exploit incident once again brings attention to LayerZero settings

The Kelp DAO rsETH bridge was attacked on April 18, resulting in losses of approximately $290 million to $292 million. Public reports and incident analysis indicate that the attacker stole 116,500 rsETH through LayerZero-related bridge activity, making this the largest DeFi security breach of 2026 to date.

Technical commentary released after the attack identified weak validation mechanisms as the core issue. A widely cited analysis article pointed out that the bridge configuration relied on a one-to-one validator model, creating a single point of failure that allowed forged messages to release assets from custodial accounts. This structure has become a focal point of discussion regarding whether this security vulnerability stemmed from underutilizing optional security settings.

Following the Kelp DAO vulnerability, Aave's total value locked reportedly saw attackers exploit stolen rsETH as collateral to borrow wETH on the Aave v3 platform, causing a significant drop in rsETH's price. In response, Aave froze several rsETH and wETH markets, exposing the protocol to approximately $195 million in bad debt risk.

Ripple executives emphasize convenience over security

Schwartz said he “had a hunch” that some of the issues may have stemmed from Kelp DAO opting not to use LayerZero’s key security features for convenience. His remarks reflect a widespread concern that some bridge teams adopt more relaxed configurations during early development stages and defer stricter controls to later phases.

This perspective adds a new dimension to current XRP news coverage, as the RLUSD assessment will still take infrastructure risk into account. Schwartz’s comments indicate that Ripple’s internal review places significant emphasis on the actual configuration of the bridging system, not just its theoretical design.

Thus, this vulnerability has sparked a broader discussion about who should be responsible for securing bridge design. Some developers argue that applications need flexibility to choose their own validation models, while critics contend that this freedom may lead developers to adopt weaker default settings for easier deployment and maintenance.

Disclaimer: The information on this page may have been obtained from third parties and does not necessarily reflect the views or opinions of KuCoin. This content is provided for general informational purposes only, without any representation or warranty of any kind, nor shall it be construed as financial or investment advice. KuCoin shall not be liable for any errors or omissions, or for any outcomes resulting from the use of this information. Investments in digital assets can be risky. Please carefully evaluate the risks of a product and your risk tolerance based on your own financial circumstances. For more information, please refer to our Terms of Use and Risk Disclosure.