RippleX is applying formal verification to the XRP Ledger’s planned native lending system before any Mainnet activation, with the review covering XLS-66 Lending Protocol and XLS-65 Single Asset Vaults. The goal is to catch hidden flaws in core protocol logic before validators decide whether the amendments should move forward.
The review is being carried out with protocol research firm Common Prefix. Ripple engineer Vito Tumas said traditional testing is not enough for DeFi features built directly into Layer-1. Standard tests usually check expected scenarios; formal verification uses mathematical models to determine whether a system can reach invalid states that normal test suites may never hit.
Abstract models are checked against the xrpld implementation
According to the process described by RippleX, the teams first build an abstract model of the intended behavior, then apply machine-checkable methods to verify safety properties, and only after that compare the results with the actual xrpld implementation. XRPL Foundation validator Vet highlighted the effort after Tumas shared the second part of RippleX’s verification series.
Vet described the work as part of building “Fortress XRP,” saying the lending code is being reviewed with methods associated with high-risk software. The article makes clear that this label reflects his own view, not a formal certification. RippleX has also noted that formal methods can prove the absence of specific classes of bugs defined in the model, but they cannot prove the software has no weakness at all because every proof depends on the chosen assumptions and properties.
Putting lending in the base protocol raises the stakes
XRPL plans to place lending functions inside the base protocol rather than rely on separate smart contracts. That can make access simpler. It also means an error in shared core code could affect every application using the feature.
The lending design introduces many interacting components: loan schedules, interest calculations, defaults, vault shares, freeze rules, and clawback behavior. Even small accounting mistakes or rounding issues can compound across repeated transactions, which is why low-probability edge cases matter during this stage of review.
The scrutiny follows an earlier XRPL security issue tied to Batch transactions. Version 3.1.1 disabled Batch support after Pranamya Keshkamat and Cantina AI found a flaw in the proposed amendment.
XLS-66 still depends on validator backing
If activated, XLS-66 would enable fixed-term, uncollateralized loans funded through Single Asset Vaults. Loan brokers would set terms and handle risk management, while borrower underwriting would take place off-chain before funds move on-chain.
The design includes optional first-loss capital that can absorb part of a default before vault depositors take losses. It supports XRP and issued assets, and tokens with compliance controls may be frozen or clawed back where eligible.
XRPL 3.1.0 added support for the lending and vault amendments in January, but the features are still subject to the amendment process and cannot go live unless validators maintain the required level of support. Crypto.news previously reported that XRP Ledger 3.2.0 is targeting a June 15 release and will rename the network’s core server software from rippled to xrpld. Before that, version 3.1.3 introduced accounting and invariant fixes for vaults and lending tools.
For RippleX, formal verification is now an added security layer ahead of any possible Mainnet rollout. The next step depends on what the review finds and whether validators choose to back the amendments.