Ripple’s former chief technology officer David Schwartz has raised a serious warning flag for the entire DeFi ecosystem, arguing that a fundamental design flaw in bridge security is being repeatedly ignored in favor of convenience and rapid growth.
Schwartz, now CTO Emeritus at Ripple, explained that his deep dive into cross-chain bridge architectures for Ripple’s RLUSD stablecoin exposed a troubling pattern. While many DeFi bridge frameworks technically include robust security mechanisms, he says teams are often steered-by design and by incentives-toward running them in weakened, “light” modes because those are simpler to manage and easier to scale.
According to Schwartz, his evaluation of “a lot of DeFi bridging systems” for potential integration with RLUSD focused almost entirely on risks and security assumptions. What surprised him was not the absence of strong defenses in these systems, but rather how rarely those defenses are fully enabled in real-world deployments. The tooling exists, the safeguards exist, yet they are frequently optional and, in practice, left unused.
He pointed out that many bridge designs already provide advanced protections against the very class of attack that appears to have affected KelpDAO’s rsETH bridge. In his view, the problem is that enabling these protections often introduces friction: more operational complexity, slower onboarding, more complicated key management, or higher costs. As a result, protocols may tout best-in-class security on paper while subtly encouraging users and integrators to skip the most critical settings.
Schwartz described the pattern in blunt terms. In his words, most schemes are “very well designed” and include “really strong mechanisms” specifically engineered to guard against the kind of exploit now associated with the KelpDAO/rsETH situation. But their practical recommendation, direct or implied, often amounts to not using “the most important security mechanisms” because of the hit to convenience and scalability.
He stressed that this is not a matter of technology being unavailable. Instead, it is a business and product decision: security features are present but framed as optional add-ons. Protocols market themselves as having top-tier safety while simultaneously emphasizing how simple and scalable they are-so long as operators do not fully activate the heavy-duty security layers. This, Schwartz suggested, creates a hidden tradeoff that many teams resolve in favor of speed and growth rather than maximum safety.
In this context, he speculated that KelpDAO might have taken the same route with its LayerZero-based rsETH bridge, potentially leaving out or underutilizing key security features in pursuit of easier operations. He admitted he hopes this suspicion is wrong, but his “funny feeling” is that convenience once again overrode a more conservative security posture.
Behind this specific case, Schwartz sees a broader systemic problem: incentive design in DeFi. When individual applications are given wide latitude to choose their own trust assumptions and security levels, market competition can inadvertently reward whoever offers the smoothest user experience and the fastest integrations-often at the expense of rigorous risk controls. Over time, this dynamic can push the entire sector into an equilibrium where moderate or even weak security becomes the norm.
Some in the XRP ecosystem have argued that allowing each protocol to define its own security guarantees creates a “race to the bottom,” where projects that cut corners can outcompete those that invest in heavy-duty safeguards. Schwartz did not fully dismiss the idea that simpler models can be justified in certain contexts, particularly when the value at stake is still small or when underlying assets are issued by a trusted entity capable of freezing or clawing back funds in an emergency. In such cases, weaker bridges may be tolerable as transitional tools.
However, he highlighted a recurring pattern: what is initially framed as a temporary compromise-“we just need to get it working, we’ll harden it later”-tends to persist far longer than intended. Assets and total value locked grow, user exposure increases, but the promised security upgrades keep getting delayed, overshadowed by feature rollouts, marketing pushes, and ecosystem expansion.
This, he said, is how “moderate security” solutions gradually end up protecting enormous sums of money. By the time the system’s scale truly justifies the more stringent protections originally planned, the cost and complexity of making those changes have grown, incentives have shifted, and the industry often only revisits the issue after a major failure.
On the legal side, Schwartz was cautious about whether affected users might have recourse against teams that chose lighter security settings. He suggested that liability questions quickly become extremely complex and are unlikely to provide clear, predictable accountability in the short term. Instead, he framed the core issue as one of governance and responsibility: who decides what level of risk is acceptable when the funds belong to other people?
He also criticized the industry’s tendency to repeat the same cycle: outrage and vigilance after each catastrophic breach, followed by a gradual slide back into complacency. As he put it, the sector has not collectively chosen to wait for “perfect” solutions before scaling, so periodic large failures are almost baked into the current model. Each incident sparks a brief period of heightened caution, but within a month or two, the pressure to ship new products and chase yields reasserts itself.
For Schwartz, the heart of the problem is structural. DeFi continues to push for massive cross-chain liquidity and interoperability while lacking adequate frameworks for managing bridge risk at a level commensurate with the scale of user funds. Even he, while acknowledging that simpler designs can be acceptable in narrow use cases, conceded that decentralized governance mechanisms are poorly suited to making tough, centralized-style decisions about custodial risk and emergency intervention.
The immediate backdrop to his comments is the April 18 rsETH exploit involving KelpDAO. An attacker is reported to have taken advantage of vulnerabilities in KelpDAO’s LayerZero-powered rsETH bridge, resulting in the draining of 116,500 rsETH-roughly 290 million dollars at the time. In response, Aave’s Guardian moved to freeze rsETH and its wrapped version across all markets where they were listed, emphasizing that Aave’s own protocols had not been compromised and that the issue stemmed from the external bridge infrastructure.
This incident underscores why bridge security has become one of the most critical-and fragile-components of the DeFi stack. Bridges effectively serve as the connective tissue between blockchains, locking assets on one chain and minting representations on another. If the locking contract, messaging layer, or validator set is compromised, the bridge can mint unbacked assets or release locked funds without authorization, leading to enormous losses that ripple across multiple protocols.
In many designs, security hinges on off-chain or semi-centralized components: multisignature committees, oracle networks, or third-party messaging layers. While these can be hardened, they also introduce complex trust assumptions. Schwartz’s critique suggests that, too often, project teams either underestimate these assumptions or intentionally downplay them in user-facing messaging, leaning on marketing lines about decentralization and safety while running configurations that are only partially robust.
For RLUSD, Ripple’s planned stablecoin, the stakes are particularly high. A core part of any stablecoin’s value proposition is reliability and predictable redemption. If cross-chain movement of RLUSD were to depend on bridges that quietly cut corners on security, the reputational and financial damage from a single breach could be immense. Schwartz’s comments imply that Ripple’s internal review process is deliberately conservative, prioritizing worst-case scenarios over convenience.
This cautious stance may point toward a future where serious projects favor either extremely battle-tested bridge designs, native multi-chain issuance, or architectures that minimize dependencies on external messaging layers. It also suggests a push toward security configurations where the safest settings are not optional but enforced by default, even if that slows down adoption or complicates integrations.
For DeFi users and developers, Schwartz’s warning carries several practical implications. First, reading “we support advanced security features” in technical documentation is not enough; the real question is which features are actually enabled in production and under what conditions. Second, protocols that advertise frictionless, instant cross-chain interactions may be implicitly signaling that they have made security concessions in pursuit of speed. Third, users should be aware that the biggest risks in DeFi are often not visible in glossy front-end interfaces but buried in architecture choices, validator setups, and upgrade keys.
The governance angle is equally important. In systems where token-holders or DAOs control security parameters, there is a natural temptation to favor decisions that grow TVL and user numbers over choices that introduce friction-even when those cautious choices would materially reduce risk. Without strong cultural norms around security, or hard constraints embedded in protocol design, market forces alone may not be sufficient to steer behavior toward safer configurations.
There is also a psychological aspect to these dynamics. When a bridge runs smoothly for months or years without incident, teams and users alike may infer that the moderate-security setup is “good enough,” even if experts have flagged structural weaknesses. This can foster a false sense of security that only breaks when an attacker finally exploits the system at scale. By then, the impact is magnified precisely because the bridge has succeeded in attracting large volumes of capital.
Schwartz’s perspective effectively calls for a recalibration of what the industry considers acceptable risk. Rather than assuming that failures are the price of innovation, his comments suggest that the sector should treat bridge security as critical financial infrastructure-worthy of the same level of scrutiny, redundancy, and conservatism that traditional finance applies to core settlement and custody systems.
In practical terms, this could mean requiring multi-layered defense-in-depth strategies for any bridge holding significant value: stricter validation processes, default use of all available safety features, robust monitoring, clearly defined emergency procedures, and transparent communication about trust assumptions. It may also involve external audits that do not merely affirm code quality but explicitly model how security is configured in live deployments.
Finally, his remarks serve as a reminder that “decentralization” is not a binary label that automatically guarantees safety. A bridge can be decentralized in some respects yet still hinge on a small set of operators, a single messaging stack, or upgrade keys held by a handful of entities. Users and developers alike need to interrogate how power and responsibility are distributed, how failures are handled, and whether the architecture is truly designed to protect other people’s money under stress-not just to grow as quickly as possible in favorable market conditions.
In that sense, the KelpDAO rsETH incident is not just an isolated misfortune but a case study in how design, incentives, and human behavior intersect in DeFi. Schwartz’s warning is that unless the industry confronts these structural issues head-on-especially around bridges-the same story will keep playing out: explosive growth, a spectacular failure, a brief period of caution, and then a return to the very practices that set the stage for the next crisis.