Ripple CTO Emeritus Warns RLUSD Review Exposes a DeFi Security Red Flag

•

Ripple CTO Emeritus David Schwartz said his review of DeFi bridge designs for Ripple’s RLUSD surfaced a recurring problem that may now be central to the KelpDAO/rsETH incident: security controls can exist, but teams are often pushed toward lighter configurations because they are easier to operate and faster to scale.

Schwartz: Security exists, but incentives can make it optional

In a series of posts on X, Schwartz said he evaluated “a lot of DeFi bridging systems” for potential RLUSD use, focusing “almost exclusively” on security and risk. What stood out, he wrote, was not a lack of tooling. Many systems, in his view, already offered strong protections against the kind of failure being discussed around KelpDAO.

However, Schwartz argued that those protections often came with friction—leading some designs to effectively discourage teams from using the most important security mechanisms.

“One thing I noticed is that most schemes were very well designed and had really strong mechanisms available to protect against exactly the type of attack the the KelpDAO/rsETH situation seems to have been caused by,” Schwartz wrote. “However, one thing I noticed was that they generally in effect recommended not bothering to use the most important security mechanisms because they have convenience and operational complexity costs.”

Cause: Convenience-first bridge configurations

Schwartz said bridge business models can be structured so that key security features are optional, even if the assets secured eventually grow large enough to make the tradeoff untenable.

“Their sales pitch was that they have the best security features but they’re easy to use and scale assuming you don’t use the security features,” he wrote. “I have a funny feeling part of the problem is going to be something like KelpDAO choosing not to use key LayerZero security features out of convenience. I hope I’m wrong.”

He framed the broader issue as incentive design: if applications can choose their own trust assumptions, competition may drift toward lower-friction setups rather than higher-assurance ones. XRP community figure Vet made a similar point, arguing that allowing applications to define their own security leads to a “races to the bottom” dynamic.

Development: When “simpler” becomes permanent

Schwartz acknowledged that simpler setups can be reasonable when value is still small, or when assets are backed by a trusted issuer and can be frozen. But he also suggested that in open crypto markets, temporary shortcuts can become lasting.

“The whole DeFi bridging industry is infected with people using moderate security because ‘we just need to get it working, we’ll improve it later’ that grows to protecting huge amounts of money and the later improvements never come,” he wrote.

He also criticized the industry’s tendency to repeat the same lesson after each major incident. “Every once in a while, we’re going to have a big failure and then everyone will be careful for a month or two and the cycle will repeat,” Schwartz said.

Data and incident details: April 18 rsETH breach

The backdrop is the April 18 rsETH incident involving KelpDAO. An attacker exploited KelpDAO’s LayerZero-powered rsETH bridge and drained 116,500 rsETH, valued at roughly $290 million.

Aave’s Guardian then froze rsETH and wrsETH markets across the deployments where the asset was listed. Aave said it had not been hacked and that the issue was scoped to the asset rather than the lending protocol.

Aave later stated that all pools remained operational, but the freeze halted new deposits and new borrows against rsETH collateral while the situation was assessed.

Impact: Broader DeFi risk and collateral questions

The episode became a wider DeFi risk event because rsETH had been integrated into lending markets. That raised renewed questions about collateral standards, bridge configuration choices, and whether convenience-first interoperability is being underpriced across the stack.