NewsCryptoXRPL Developers Refine XLS-66 Standard for Native Lending

XRPL Developers Refine XLS-66 Standard for Native Lending

Author: Bitcoinist·

Key Takeaways

  • XLS-66 proposes native on-chain lending for the XRP Ledger featuring fixed-term, uncollateralized loans organized through Single Asset Vaults.
  • The standard relies on loan brokers to perform credit assessment off-chain while loan terms and settlement are handled on-chain through XRPL infrastructure.
  • The proposal remains under standards review and code testing, meaning native lending is not yet available on the XRPL mainnet.
  • XLS-66 differs from dominant DeFi lending models by avoiding overcollateralization in favor of a structured approach that depends on off-chain underwriting quality.
  • XRPL implements major financial features as native protocol functionality through formal standards proposals, distinguishing it from EVM-compatible chains where DeFi protocols are deployed as third-party smart contracts.
XRPL Developers Refine XLS-66 Standard for Native Lending

XRP Ledger developers are continuing to refine XLS-66, a proposed standard that would introduce native lending functionality to XRPL. If the specification continues to advance, it could become one of the network's more significant DeFi-style upgrades.

The proposal outlines on-chain, fixed-term, uncollateralized lending built around Single Asset Vaults. It also uses off-chain underwriting by loan brokers, while settlement would be handled on-chain through XRPL infrastructure.

That structure is central to the proposal. XLS-66 is not designed as a simple "anyone borrows from anyone" DeFi lending pool similar to fully collateralized Ethereum money markets. Instead, it presents a more structured lending model that combines off-chain credit assessment with blockchain-based execution.

The feature remains in standards review and code testing. Native lending under XLS-66 is not live on the XRP Ledger mainnet.

XRPL Is Expanding Beyond Payments

The XRP Ledger has long been associated with payments, fast settlement, and exchange functionality. That history remains important, but it can also obscure the network's more recent development direction.

XRPL developers have been working on features intended to broaden the chain's role in on-chain finance, including vaults, automated market maker functionality, credentials, and lending standards. XLS-66 is part of that wider development track. Unlike EVM-compatible chains where DeFi protocols are typically deployed as smart contracts by third-party developers, XRPL implements major financial features as native protocol functionality through standards proposals and amendments. That means features like lending move through a formal standards review process before they can be activated on mainnet, which is why proposals such as XLS-66 are significant indicators of the network's roadmap.

A native lending protocol would give XRPL a more direct connection to credit markets. However, the proposal is not attempting to reproduce existing DeFi models exactly. It introduces Single Asset Vaults and fixed-term lending while keeping off-chain underwriting as a key part of the process.

In that sense, the design resembles a bridge between traditional credit workflows and blockchain settlement. Credit evaluation would take place away from the chain, while the resulting loan structure could be recorded and settled on XRPL.

Why Off-Chain Underwriting Is Central

Most DeFi lending is overcollateralized. In that model, a user deposits assets worth more than the amount they borrow, and smart contracts manage liquidations if the collateral value falls too far. The approach is transparent and automated, but it is also capital-inefficient because borrowers generally need to already hold substantial assets before they can access credit. Protocols like Aave and Compound have popularized this model on Ethereum, and it remains the dominant paradigm across most DeFi lending markets today.

Uncollateralized lending works differently. It requires some combination of trust, identity, credit assessment, or underwriting. Without those elements, borrowers could take loans without a reliable mechanism for lenders to assess repayment risk.

XLS-66 introduces loan brokers as part of this structure. Under the proposed model, credit decisions and borrower assessment would occur off-chain, while the resulting loan terms and settlement could be handled on-chain.

That creates a risk model that differs significantly from standard DeFi lending. It may be better suited to some real-world credit workflows, but it also depends heavily on the quality of the underwriting process. The blockchain can record settlement, enforce certain terms, and provide transparency, but it does not eliminate borrower credit risk.

For that reason, the loan broker role is a central element of the proposal rather than a minor implementation detail.

Single Asset Vaults as a Building Block

Single Asset Vaults are another important part of the proposed design. A vault structure can help organize funds, isolate assets, and create a clearer container for specific lending activity. That could make XRPL-based lending easier to understand and manage than a less structured pool model.

For developers, vaults may also serve as broader financial building blocks. Once vault mechanics are available, other products may become easier to develop. Lending, yield products, structured credit, and asset management tools all require reliable methods for holding and accounting for assets.

That is why technical standards discussions can be important before a mainnet launch. Markets often pay more attention once a feature is live, but the architecture is shaped earlier, while standards are debated, revised, and tested. XLS-66 is the stage where XRPL's native lending design is being developed and refined.

Native XRPL Lending Is Not Live Yet

The main caveat is that XLS-66 remains under review and testing. Users should not assume that native XRPL lending is currently available. Developers are still working through the specification and code integration, including related work tracked in the XRPLF repositories.

That process is typical for protocol development, particularly when financial primitives are involved. Lending systems require careful review because errors can be costly. They involve balances, repayments, defaults, vault accounting, permissions, and user expectations.

For XRP holders and XRPL users, the proposal is notable because it would expand the network's potential use cases if implemented safely. Native lending could strengthen XRPL's DeFi profile and may interest developers and users seeking credit products connected to the ledger's speed and settlement features.

At the current stage, however, the proposal is still about design and testing rather than adoption.

XRPL's DeFi Development Becomes More Visible

XLS-66 shows that XRP Ledger development is moving toward more advanced financial infrastructure. That does not replace the network's payments heritage; it adds another layer to it. Payments and lending are closely connected in traditional finance, and a blockchain that supports both may have a broader role than one used only for transfers.

Several questions remain unresolved. The standard would need to be finalized, code would need to be safely integrated, developers would need to build lending products around it, users would need to trust the off-chain underwriting model, and loan brokers would need to generate real demand.

Those outcomes remain uncertain and will take time to assess. For now, the key point is that XRPL developers are working on native lending in a way that reflects the network's own architecture, rather than simply copying another chain's DeFi model.

If the effort succeeds, XLS-66 could help position XRPL as a broader financial application layer. If it stalls, it will still indicate where developers have been trying to push the network's capabilities. In either case, the standard remains one of the more important XRPL development efforts to monitor.

This article is based on XRPLF GitHub discussions for XLS-66 and the related rippled pull request. The original report was written by the News Desk and edited by Samuel Rae. It is based on information released in disclosures and primary source documentation.