XRPL Lending Protocol in 2026: Vaults, Loans, Risk, and XRP Yield

By XORA · Published 2026-08-31

XRPL's native lending architecture exists in specifications, production server code, documentation, and Devnet, but it was not enabled on XRP Ledger Mainnet when checked on 31 August 2026. The design pools XRP or issued assets in Single Asset Vaults, represents depositor claims as shares, and issues fixed-term uncollateralized loans after off-chain underwriting. That is fundamentally different from depositing XRP as collateral for a liquidation-driven loan.

The status first: supported code is not an enabled network feature

Three facts can all be true at once. The rippled 3.1.0 release added supported implementations of SingleAssetVault and LendingProtocol. The standards registry still labels XLS-65 and XLS-66 as Draft. And Mainnet can still leave both amendments disabled because validators, not a software release, determine activation through amendment voting.

We queried the official feature method against a validated Mainnet ledger. At ledger index 106,664,609, both amendment IDs returned supported: true and enabled: false. The same queries on Devnet returned enabled for both; Testnet returned supported but disabled. This is a dated state check, not a prediction of the next validator vote.

Layer one: the Single Asset Vault is an accounting primitive

A Single Asset Vault pools exactly one underlying asset: XRP, a trust line token, or an MPT. The Vault ledger entry records the rules and accounting, while an owned pseudo-account holds the assets because ledger objects cannot hold balances directly. The pseudo-account cannot sign ordinary transactions.

Depositors receive vault shares as MPT units issued by that pseudo-account. Shares represent a proportional claim, not a fixed promise. If net interest raises vault assets while share supply is unchanged, each share can redeem for more. If a loan default reduces assets, each share can redeem for less. XRP itself earns nothing merely by being inside the vault.

Vaults may be public or private. Private deposits require credentials tied to a Permissioned Domain, but an existing shareholder retains the right to redeem even after credentials expire. Shares can be configured as transferable or non-transferable. The vault also tracks unrealized loss and applies separate deposit and withdrawal exchange-rate logic to limit loss-shifting between entering, exiting, and remaining depositors.

Layer two: the LoanBroker connects pooled assets to credit

XLS-66 adds two core ledger entries. LoanBroker stores the associated vault ID, total debt, debt ceiling, configurable management fee, first-loss balance, and cover rates. Loan stores the borrower, principal and interest state, payment schedule, grace period, and fee terms. In the current specification, the vault owner and loan broker owner are the same account.

The broker creates a loan agreement with a borrower through LoanSet. Principal leaves the vault's available assets and reaches the borrower. Scheduled payments then return principal and depositor interest, while configured origination, service, late, early-payment, and management fees route according to protocol rules. LoanPay, LoanManage, and LoanDelete advance or close the lifecycle.

This is uncollateralized credit, not “borrow against XRP”

The design intentionally omits automated on-chain collateral and liquidation. A broker evaluates creditworthiness off-chain, agrees fixed terms, and originates the loan on-ledger. If a payment is missed, the loan enters its configured grace period; the broker may then impair or default it. No oracle watches an XRP collateral ratio, and no smart liquidation engine sells collateral when a threshold breaks.

That distinction changes the dominant risk. In a collateralized XRP loan, market volatility can liquidate a borrower even if they intended to repay. In XLS-66 lending, a depositor is exposed primarily to borrower credit quality, broker underwriting, concentration, loan duration, and available vault liquidity. Someone “borrowing against XRP” pledges XRP to obtain another asset. Someone borrowing XRP from a native XRP vault would receive the vault's XRP as unsecured principal.

Where potential XRP lending yield would come from

Potential yield comes from borrower payments, not XRPL consensus and not the vault wrapper itself. When a loan is issued, expected interest net of the management fee is included in the protocol's debt and vault accounting. As payments become available assets, depositors' unchanged share supply represents a larger asset claim. There is no protocol-wide APY: every loan broker chooses terms, fees, debt limits, borrowers, and cover settings.

That also means a displayed rate would need context. Is it contracted interest, realized interest, or an annualized recent period? Does it subtract management fees, defaults, idle liquidity, and impaired loans? Can depositors redeem at the quoted value now? A defensible product should expose net realized performance and credit losses rather than turn a loan coupon into a guaranteed depositor APY.

First-loss capital helps, but it is not insurance

The broker may deposit the same asset into a separate pseudo-account as first-loss capital. CoverRateMinimum sets required cover relative to total debt; CoverRateLiquidation limits how much of that required cover moves into the vault when a loan defaults. If cover falls below its minimum, the broker cannot issue new loans and broker fees replenish cover rather than flow to the owner.

The word “first-loss” can sound stronger than the formula. In the specification's example, total debt is 1,090 units, minimum cover is 10%, and the liquidation rate is 10%. The resulting cover is only 10.9 units: 1,090 × 10% × 10%. The remaining 1,079.1-unit default reduces vault assets. Cover is optional and parameterized, so depositors must inspect its amount and rules, not merely its presence.

A practical risk checklist for a future Mainnet vault

• Activation risk: confirm both required amendments are enabled on the network being used. Documentation and transaction serializers alone do not make a Mainnet feature live.
• Credit risk: demand the broker's underwriting standards, borrower concentration, arrears, realized defaults, and recovery process. The ledger records agreed state; it does not know whether a borrower is creditworthy.
• Liquidity risk: compare available assets with total depositor claims and loan maturities. A share valuation is not the same thing as immediate cash available for every redemption.
• Cover risk: inspect CoverAvailable, minimum cover, liquidation rate, and debt total. Treat first-loss capital as a finite buffer, never a guarantee.
• Asset-control risk: issuers of trust line tokens and MPTs can freeze, deep-freeze, lock, or claw back in defined cases. Those issuer controls do not apply to native XRP in the same way.
• Version risk: follow later cleanup amendments and LendingProtocolV1_1. The Known Amendments page listed version 1.1 as in development on this article's date.

Put XRP to work while native lending remains separate

XRPL's Lending Protocol is a specific amendment-gated credit architecture. It was not enabled on Mainnet at this dated check, and it should not be used to explain or market unrelated yield products. XORA's separate offering is up to 22% APY value (15% native subsidised + XORA reward value). It is variable, not guaranteed, and involves custody, liquidity, operational, counterparty, market, and reward-value risks.

xora.finance is where to put your XRP to work and earn up to 22% instead of leaving it idle on an exchange. Review the security model, understand the distinction from native XRPL lending, and start with an amount appropriate for your risk tolerance.