Ripple is moving to shrink the XRP Ledger's attack surface through two parallel security initiatives: removing unused bridge code and conducting an intensive AI-driven audit of its new lending infrastructure.
The company has recommended removing more than 10,000 lines of XChainBridge code, an original cross-chain bridge design that has become largely obsolete. After Ripple selected Axelar for its EVM Sidechain in June 2024, demand for the native XChainBridge failed to materialize as developers expected. The proposal would also remove the related fixXChainRewardRounding amendment.
Ripple cited three reasons for the recommendation: maintenance burden, contributor complexity, and the expanded attack surface created by retaining dormant functionality. The company argued that keeping the network lean would better serve it as the platform evolves.
The removal process would not be immediate. Ripple controls one validator vote, and the proposal must proceed through the XRPL amendment process. If community support materializes, validators would first mark XChainBridge as obsolete, stopping votes for the amendment and allowing code removal in a later release once the network converges.
Lending Security Through Multiple Testing Layers
As XRPL prepares to introduce native lending capabilities, Ripple has subjected Lending Protocol V1.1 to extensive scrutiny. On August 27, Sherlock announced that the protocol had entered an intensive AI-only security review through its Audit Engine, which combines multiple AI auditors and frontier models with specialized security capabilities.
The lending system represents one of the most financially complex additions to XRPL since its launch. It incorporates loan lifecycle management, interest-rate calculations, multi-party fee routing, credential-based permissions, and interactions with asset pools.
Sherlock has not yet disclosed findings or a completion date. The review follows an unusually extensive security process for the earlier lending and Single Asset Vault codebase, where repeated testing identified vulnerabilities even after previous rounds of scrutiny.
In late 2025, Ripple and Immunefi conducted a $200,000 attackathon covering 35,498 lines of code. The competition drew 455 submissions from 131 researchers and produced 94 unique valid findings, including 15 classified as critical and 19 as high severity. Ripple addressed all identified issues.
Between March and May, Ripple's AI red team filed 20 lending-specific tickets and identified seven confirmed bugs that were fixed. These included an inverted invariant that could have allowed phantom collateral to go undetected, a fee-free spam vector involving loan payments, and an integer-overflow issue that could have caused node deadlock.
Industry Security Pressures Mount
Ripple's security expansion reflects industry-wide pressure to strengthen defenses. In July, CertiK recorded $1.315 billion in losses across 344 security incidents during the first half of 2026. Excluding the exceptional $1.45 billion Bybit breach from the previous year, comparable losses rose approximately 28% in 2026.
Code vulnerabilities were the most frequent attack type, appearing in 204 incidents. CertiK also found that attackers increasingly targeted contracts more than a year old, demonstrating how vulnerabilities can remain exploitable well after deployment.
Other significant losses came from wallet compromises, which generated over $444 million in losses, and infrastructure breaches including the Kelp DAO RPC compromise and Drift Protocol breach, which together accounted for $576 million.
Balancing Automated and Human Review
Ripple has cautioned that no code audit, whether AI-driven or traditional, addresses every security threat facing a protocol or its users. The company's lending development process has layered multiple testing approaches: independent audits, public security competitions, fuzzing, formal methods, community testing, and AI-assisted vulnerability discovery.
Ripple's security researchers have noted that AI pipelines produce false positives and that human validation remains particularly important for subtle bugs where models can misinterpret how an invariant should behave.
