XRPL Institutional Lending Plan Still Awaits Validator Approval
Key Takeaways
- •Activating XRPL lending requires both the XLS-65 Single Asset Vaults and XLS-66 LendingProtocol amendments, which currently hold only 25.71% and 22.86% validator support, respectively, far below the required 28 of 35 validators sustained for two consecutive weeks.
- •XRPL version 3.4.0 has not been officially released or scheduled, with version 3.3.0 remaining the latest stable release and LendingProtocolV1_1 still listed as in development.
- •Clearpool's September 11 governance proposal seeks to expand to XRPL with institutional yield products based on XRP and Ripple's RLUSD stablecoin, and Clearpool states Ripple has committed capital of an undisclosed amount.
- •Under the proposed model, the XRP Ledger would record loans and enforce their payment, interest, and default terms, while banks, fund managers, and underwriters continue performing credit assessment outside the ledger.
- •Broker-provided first-loss capital would absorb an agreed portion of defaults, but vault shareholders could still lose value if losses exceed that buffer, and depositors could face delayed withdrawals if vault assets are tied to illiquid fixed-term loans.

Key points
- Native XRPL lending remains inactive on the mainnet.
- Validator support for the required amendments is still well below the activation threshold.
- Version 3.4.0 has not been officially released or scheduled.
- Clearpool is proposing institutional credit products using XRP and Ripple’s RLUSD stablecoin.
- Credit assessment and underwriting would remain outside the ledger.
Ripple identifies lending as a missing layer
Jasmine Cooper, Ripple’s head of product, has described lending as a missing component of tokenized financial markets. Digital assets can already be issued, transferred and settled onchain, but institutions also need mechanisms to finance those assets and manage short-term liquidity.
In a June 29 article published by Ripple, Cooper described several potential applications. A payments company could borrow while waiting for incoming settlements, a market maker could finance inventory, and a corporate treasury could deploy otherwise idle digital assets.
The proposed system would not require the XRP Ledger to determine whether a borrower is creditworthy. Banks, fund managers and specialist underwriters would continue to review financial statements, collateral arrangements, legal documentation and concentration limits. XRPL would record the agreed loan and enforce its payment schedule, interest terms and default rules.
Under that model, the ledger would administer loans rather than act as a credit committee. The distinction is important because the protocol could standardize settlement without guaranteeing the quality of the loans or the financial soundness of borrowers.
Two amendments are required
The planned lending system relies on two connected amendments. XLS-65 introduces Single Asset Vaults, which pool one type of asset from multiple depositors. The asset could be XRP, an issuer-backed token or a Multi-Purpose Token. In exchange for their deposits, participants receive vault shares representing their interests in the pool.
XLS-66 provides the lending functionality. A loan broker could use assets from a connected vault to issue fixed-term, uncollateralized loans to approved borrowers. The broker would set the terms and manage the relationship for the duration of each loan.
The broker could also provide first-loss capital. That capital would absorb an agreed portion of a default before losses reached other vault participants. It would serve as a loss buffer rather than as collateral posted by the borrower. If losses exceeded the first-loss protection, vault-share holders could still lose value.
Before committing funds, depositors would need to evaluate the amount of first-loss coverage, borrower concentration and withdrawal conditions, among other factors. The structure is also described in Coindoo’s guide to native XRPL lending.
Validator support remains near one-quarter
Neither amendment is active on the XRP Ledger mainnet. At the time of writing, XRPSCAN reported nine validators supporting SingleAssetVault, representing 25.71%, and eight supporting LendingProtocol, representing 22.86%.
Under the current XRPSCAN set of 35 validators, an amendment requires support from 28 validators and must maintain that support for two consecutive weeks. The required software code can be included before the rules are activated. As a result, even a future version 3.4.0 release would not make native lending available unless both amendments completed the activation process.
Both amendments must be approved. LendingProtocol draws liquidity from a Single Asset Vault, so activating only one of them would not create a functional lending market.
Validator voting indicates that network operators are prepared to adopt a set of transaction rules. It does not evaluate prospective borrowers, protect depositors from defaults or demonstrate demand for the resulting credit products.
Version 3.4.0 has not been released
Recent reports have stated that Lending Protocol version 1.1 will be included in XRPL version 3.4.0. However, the latest stable release listed in the XRPL Foundation’s GitHub repository is version 3.3.0.
The official amendment directory lists LendingProtocolV1_1 as “In Development,” and no dated release announcement for version 3.4.0 has been published. The expectation of an upcoming release originated with a September 10 post from an XRPL validator. That post provides guidance about the development schedule, but it does not represent a formal commitment from the XRP Ledger Foundation.
Version 1.1 is intended to address a practical issue in the original lending workflow. The current model uses a custom dual-signature process when a loan is created, potentially requiring wallets and custodians to build specialized integrations before their customers can participate.
An open technical proposal would introduce separate loan-proposal and loan-acceptance steps using standard XRPL transactions. Its authors say the change would reduce custody lock-in and enable a broader range of wallets to support the protocol.
The proposal and related implementation work remain unfinished. Until the code is completed and included in a stable release, version 1.1 remains a development item rather than an available XRPL feature.
Clearpool proposes XRP and RLUSD products
Clearpool plans to develop institutional credit products using the proposed infrastructure. Its September 11 governance proposal seeks approval to expand to XRPL and launch initial yield products based on XRP and Ripple’s RLUSD stablecoin.
Using RLUSD would give the proposed products a dollar-denominated asset alongside XRP. RLUSD has already been used in other collateral settings, including after it became margin collateral on OKX. Exchange margin is not equivalent to underwriting fixed-term, uncollateralized loans, however. The latter depends on the borrower, the broker and the loss protections available to the pool.
The proposal also calls for a one-for-one migration from CPOOL to CLEAR and a treasury recapitalization. Clearpool says that 99% of the existing token supply has vested, leaving limited reserves for incentives and additional development. Community discussion is scheduled to continue for 14 days before a tokenholder vote.
According to Clearpool, Ripple has committed capital to support the proposed XRP and RLUSD products, although the proposal does not disclose the amount. The products remain dependent on decisions at two governance levels: Clearpool tokenholders must approve the expansion, and XRPL validators must activate the required amendments.
The proposal identifies the first prospective users of the planned architecture, but it does not disclose the borrower types, pool size, target yield, loan terms or first-loss protection level that would determine the products’ actual risk.
Depositors would remain exposed to borrower risk
The protocol could automate loan administration, but it could not replace underwriting. A pool’s risk would depend on its operator, the companies permitted to borrow and the amount of losses that the broker’s first-loss capital could absorb.
A stated yield would provide limited information by itself. Prospective participants would need to review the broker’s legal identity, underwriting record, largest borrower exposures, first-loss contribution, withdrawal restrictions and recovery process following a default.
Liquidity would also require consideration. A vault could hold a single liquid asset while committing a substantial portion of that asset to fixed-term loans. Depositors could face delayed withdrawals if a large share of the vault were tied to loans that could not be repaid or transferred quickly.
Repayments will provide a more significant test than launch
The amendments would answer a technical question: whether XRPL can administer pooled, fixed-term credit onchain. A live market would address the more difficult question of whether institutions will trust identified brokers with uncollateralized borrowers and whether sufficient first-loss capital will make the offered yield proportionate to the risk.
This article is provided for informational purposes only and does not constitute financial or investment advice.
Original source: Coindoo.