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.
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.
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.
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.
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.
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.
A credible XRPL lending pool would need more than a published annual yield. Its documentation should answer the following:
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.
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.
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.
The post XRPL Considers Native Lending: How XLS-66 Would Work appeared first on Coindoo.
