A draft proposal on the XRP Ledger (XRPL), XLS-66, would introduce fixed-term, uncollateralized lending using pooled assets. The XLS-66 Lending Protocol remains a draft and depends on two companion proposals, XLS-65 and XLS-64. Its design sketches how native lending could function on the ledger: pooled vaults hold depositor assets, loan brokers originate loans and manage credit risk outside the ledger, and first-loss capital can offset part of a default, subject to the broker’s chosen coverage terms. If approved through governance and activated, the proposal would make lending primitives available on XRPL — though it would not by itself create borrowers, liquidity, or a proven broker network. Because the proposal is still draft infrastructure, pool terms and broker disclosures remain the key evidence to watch.

A vault and a broker at the core

XLS-66 builds on XLS-65 Single Asset Vaults. A vault aggregates a single asset from depositors — XRP, an issuer-backed IOU, or a Multi-Purpose Token — and issues shares that represent each depositor’s interest in the pool.

A loan broker connects the vault to the lending protocol. The broker sets up the pool, originates loans, and manages the arrangement throughout its life. The broker also sets key economic terms, including management fees and the amount of first-loss capital, if any, posted against the pool.

Vault shares show ownership, not guaranteed liquidity

Depositors receive vault shares when they place assets into a pool. Those shares represent a proportional claim on the vault, yet their practical value depends on the pool’s available assets and withdrawal policy. Once capital has been lent out, a depositor may not have immediate access to the same amount of liquid assets. A future vault’s documentation should therefore state how withdrawals work while loans remain open, whether requests can queue, and whether the vault places limits on lending relative to available liquidity.

Access can be open or restricted

XLS-65 permits both public and private vaults. Public pools could accept a wide group of depositors, while private pools can use on-ledger credentials to limit access to approved participants. That leaves XRPL room for institutional credit pools alongside open-access products. It also means “native lending” will not describe one uniform experience: each pool can differ in who may deposit, who may borrow, and what information participants receive.

How a loan would be recorded and serviced

Under XLS-66, the loan broker and borrower create a loan with a stated principal, interest rate, payment interval, maturity, and grace period. The loan object then tracks the principal and interest that remain outstanding. The protocol includes payment handling, late-interest rules, and fees for services such as loan origination or early repayment. If a borrower misses payments beyond the agreed grace period, the broker can mark the loan as impaired or defaulted under the proposal’s rules.

Recording those details on the ledger could make it easier for lenders, borrowers, and custodians to work from the same record. Evernorth Chief Business Officer Sagar Shah has argued that shared loan data can reduce reconciliation disputes among those parties in a company communication filed with the SEC.

A default status, however, is an accounting event. It does not itself recover the unpaid amount. The legal agreement behind the loan and the broker’s recovery process remain central to the outcome for depositors, especially because the protocol does not replace the off-chain contracts that would govern real credit relationships.

Credit decisions remain outside XRPL

XLS-66 is designed for uncollateralized loans at the protocol level. Its authors intentionally omitted automated on-chain collateral management and forced liquidations, opting for off-chain underwriting instead. In practice, a broker would need to determine whether a borrower can repay. That assessment may involve financial statements, trading history, legal agreements, guarantees, or collateral held outside XRPL. The proposal does not prescribe one underwriting method or establish a universal borrower standard.

That design may suit market makers and institutions that already use established credit processes. It also puts more weight on broker transparency: depositors need enough information to judge the broker’s lending discipline before they decide whether the offered return compensates for the risk. In that sense, the proposal’s usefulness will depend not just on ledger mechanics, but on whether borrowers, brokers, and vault operators can present terms clearly enough for others to evaluate them.

First-loss capital can soften a default

The proposal allows a broker to deposit first-loss capital. In a default, a portion of that capital can be liquidated and returned to the vault, reducing the loss passed on to depositors. The buffer may be modest or substantial depending on the pool, and its value cannot be judged from a token amount alone: a reserve of 1 million XRP has a very different meaning against 5 million XRP in loans than it does against 100 million XRP.

Future pool disclosures should show the minimum cover required, the share of that cover available for liquidation, and the broker’s ability to withdraw excess capital. Those figures reveal how much protection depositors actually have when a borrower fails.

The terms that should be visible before capital enters a pool

A credible XRPL lending pool would need more than a published annual yield. Its documentation should answer the following:

• Broker identity and jurisdiction: Who runs the pool, under which legal entity, and under which governing law?
• Borrower eligibility: Which firms or accounts can receive loans, and can affiliates borrow from the pool?
• Concentration limits: What portion of the vault may be lent to one borrower or group of connected borrowers?
• Loss cover: How much first-loss capital is posted as a percentage of outstanding debt?
• Withdrawal terms: When can depositors redeem vault shares, and what happens when a large part of the pool is outstanding in loans?
• Default and recovery process: Who takes action after default, and what claims does the pool hold against the borrower?

These are ordinary lending questions, yet they become more important when an on-chain vault gives participants a simple route into a credit market. Settlement transparency does not replace credit analysis, and a ledger-native structure does not remove the need for plain-language disclosure about who bears risk and when funds may be available again.

Approval would open the door to testing

XLS-66 remains a draft and requires both XLS-65 and XLS-64. A successful governance and activation process would make the lending primitives available on XRPL, but it would not create borrowers, liquidity, or a proven broker network on its own. The first useful signs of adoption would be concrete: named brokers, published pool terms, disclosed coverage ratios, and an on-ledger repayment history that can be examined over time. Those details would show whether the proposed framework is serving a real credit market or only adding another unused ledger feature.

Why Evernorth appears in the discussion

The Block reported on August 20 that Evernorth is exploring DeFi opportunities around XRP. Evernorth does not control XLS-66, and no primary material reviewed identifies an Evernorth-run lending pool. Its relevance is narrower: its stated treasury strategy, outlined in its official launch release, includes lending, liquidity provision, and DeFi yield, making it one potential institutional user if XRPL lending becomes available.

XRPL’s lending proposal will be judged by the pools built under it: their borrowers, their liquidity terms, and the protection available when credit conditions deteriorate.

Technical claims and proposal status in this article are based on the official XLS-66 Lending Protocol and XLS-65 Single Asset Vault specifications. Evernorth’s current relevance is referenced from The Block’s August 20 report, its official launch release, and an SEC-filed company communication.