XRPL Considers Native Lending: How XLS-66 Would Work

The XRP Ledger is considering a lending standard that would allow pooled assets to fund fixed-term loans directly on the network.
Key Takeaways
- XLS-66 proposes fixed-term, uncollateralized lending using pooled assets on XRPL.
- Single Asset Vaults would hold depositor funds and issue on-ledger ownership shares.
- Loan brokers would assess borrowers and manage credit risk outside the ledger.
- First-loss capital can offset part of a default, subject to the broker’s chosen coverage terms.
- XLS-66 is draft infrastructure, so pool terms and broker disclosures remain the key evidence to watch.
The proposed system starts with a vault and a broker
XLS-66 relies on XLS-65 Single Asset Vaults. A vault aggregates one asset from depositors and issues shares that represent each depositor’s interest in the pool. The asset can be XRP, an issuer-backed IOU or a Multi-Purpose Token.
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 would 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 public vaults and private vaults. Public pools could accept a wide group of depositors. Private pools can use on-ledger credentials to limit access to approved participants.
That gives XRPL room for institutional credit pools alongside open-access products. It also means that “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.
Putting those details on the ledger could make it easier for lenders, borrowers and custodians to work from the same record. Evernorth CBO 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.
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.
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. 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.
Approval would open the door to testing
XLS-66 remains a draft and requires XLS-65 and XLS-64. A successful governance and activation process would make the lending primitives available on XRPL. 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 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 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.
Source review: Technical claims and proposal status 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.









