Ripple is moving to shrink the XRP Ledger’s (XRPL) attack surface as it prepares to expand native lending.
The company has recommended removing more than 10,000 lines of unused XChainBridge code while Lending Protocol V1.1 undergoes an AI-only security review through Sherlock’s Audit Engine.
The parallel efforts come as crypto platforms face renewed pressure to strengthen their defenses. More than $1.31 billion was lost across 344 security incidents in the first half of 2026, with code vulnerabilities remaining the industry’s most common attack category.
Axelar leaves Ripple with 10,000 lines it no longer wants
The original case for keeping XChainBridge (XLS-38) weakened after Ripple turned to Axelar for the XRPL EVM Sidechain and broader demand for the native bridge failed to materialize.
XLS-38 was designed to let assets move between XRPL and connected sidechains through witness servers that observe transactions and attest to activity across networks. The architecture was intended to support private, permissioned, and experimental sidechains, while also providing a bridge between XRPL mainnet and the EVM Sidechain.
Ripple ultimately chose Axelar for the EVM Sidechain after evaluating security, user experience, decentralization, and the operational demands of maintaining a bridge.
The company said the XLS-38 witness model carried trade-offs that became harder to manage as the value protected by a bridge increased. Expanding the witness set could improve decentralization but add coordination and governance complexity, while a smaller group would concentrate more trust among operators.
Ripple announced its decision to use Axelar in June 2024 but kept XLS-38 available for a validator vote and gave developers roughly 12 to 15 months to demonstrate demand for private sidechains that specifically required the amendment.
However, that demand failed to reach the level Ripple expected.
The result is a substantial block of inactive code that developers must continue maintaining and reviewing even though its principal use case has been handled elsewhere.
Ripple estimates that withdrawing XChainBridge and the related fixXChainRewardRounding amendment would eventually remove more than 10,000 lines from xrpld.
Ripple identified maintenance burden, contributor complexity, and attack surface as costs of retaining dormant functionality, arguing that XRPL should remain lean as the network evolves.
The recommendation does not remove XLS-38 immediately. Ripple controls one validator vote, and the proposal remains subject to the XRPL amendment process.
If the community supports the change, Ripple plans to first mark XChainBridge as obsolete. Validators adopting a software version containing that designation would stop voting for the amendment, allowing the code to be removed in a later release once the network converges.
Ripple also left open the possibility of reconsidering if developers can demonstrate concrete projects that still require XLS-38.
Lending raises a different security challenge
Reducing legacy code comes as XRPL prepares to introduce lending infrastructure with considerably more financial interactions to secure.
Lending Protocol V1.1 builds on Ripple’s push to bring native borrowing and lending capabilities to XRPL alongside Single Asset Vaults. The underlying architecture combines loan lifecycle management, interest-rate calculations, multi-party fee routing, credential-based permissions, and interactions with asset pools.
Ripple has described the lending system as one of the most financially complex additions developed for XRPL since the network launched.
On Aug. 27, Sherlock said that V1.1 had entered an intensive AI-only security review through its Audit Engine. The system combines multiple AI auditors and frontier models with specialized security capabilities, adjusting coverage and depth to the protocol being examined.
Sherlock has not disclosed any findings or a completion date. It said a fuller account would follow once the process is finished.
The review follows an unusually extensive security process for the earlier lending and Single Asset Vault codebase, where repeated testing found vulnerabilities even after previous rounds of scrutiny.
Ripple and Immunefi ran a $200,000 attackathon in late 2025 covering 35,498 lines of code. It drew 455 submissions from 131 researchers and ultimately produced 94 unique valid findings, including 15 classified as critical and 19 as high severity. Ripple said it addressed all identified issues.
The company subsequently subjected the lending system to additional audits, community testing, fuzzing, and an AI-assisted red-team program.
Between March and May, Ripple’s AI red team filed 20 lending-specific tickets and identified seven confirmed bugs that were fixed.
Among them were 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 a node deadlock.
Those findings provide a practical reason for repeated testing as Ripple works on V1.1. The company said the enhancement incorporates partner feedback and lessons from the earlier implementation.
Ripple’s broader AI red-team program has also uncovered high-severity issues outside lending. A security-focused xrpld release earlier this year included fixes for public-facing crash paths, bounds-checking problems and cross-feature interactions identified through the program and associated testing.
Crypto’s attack wave raises the cost of missed bugs
The expansion of XRPL’s security program coincides with an industry-wide attack environment that has remained costly despite years of audits and bug-bounty programs.
In July, CertiK recorded $1.315 billion in losses across 344 security incidents during the first six months of 2026.
While that was lower than the headline figure from a year earlier, H1 2025 included the exceptional $1.45 billion Bybit breach. Excluding that event, CertiK calculated that comparable losses rose about 28% this year.
Code vulnerabilities were the most frequent attack type, appearing in 204 incidents. CertiK also found that attackers were increasingly returning to contracts more than a year old, showing how vulnerabilities can remain exploitable well after software has been deployed.
Some of the largest losses came from other weaknesses. Wallet compromises generated more than $444 million in losses, while the Kelp DAO RPC compromise and Drift Protocol breach together accounted for $576 million.
That distinction is significant because no code audit, AI-driven or otherwise, addresses every security threat facing a protocol or its users.
Ripple has consequently been using several layers of testing rather than relying exclusively on AI. Its lending development process has included independent audits, public security competitions, fuzzing, formal methods, community testing and AI-assisted vulnerability discovery.
Ripple’s own security researchers have also cautioned against treating AI as a replacement for expert review. The company said its AI pipelines produce false positives and that human validation remains particularly important for subtle bugs where a model can misinterpret how an invariant is supposed to behave.
That creates an additional test for Sherlock’s AI-only engagement. The review could show how far specialized models can extend protocol-security coverage, but its usefulness will ultimately depend on the vulnerabilities it identifies and whether those findings translate into fixes before V1.1 advances.
For now, Sherlock has released no results. Ripple is therefore trying to reduce known sources of unnecessary complexity in one part of XRPL while subjecting the next generation of financial functionality to increasingly aggressive scrutiny before more value depends on it.
