XRP Ledger’s Institutional Credit Plan Still Awaits Validators

Blockchain

13 September 2026
|
08:24

Ripple sees institutional credit as a major use case for the XRP Ledger, but the network’s lending tools remain inactive while validators consider the amendments required to enable them.

Ripple sees credit as the missing layer

Ripple product head Jasmine Cooper has described lending as a missing component of tokenized financial markets. Assets can already be issued, transferred and settled onchain, but institutions also need ways to finance those assets and manage short-term liquidity.

In a June 29 article, Cooper outlined several possible applications. A payment company could borrow while waiting for incoming settlements, a market maker could finance inventory, and a corporate treasury could put idle digital assets to work.

The proposal does not ask the ledger to decide whether a borrower deserves credit. Banks, fund managers and specialist underwriters would continue examining financial statements, collateral arrangements, legal documentation and concentration limits. XRPL would record the agreed loan and apply its payment schedule, interest terms and default rules.

That model makes the ledger an administrator of loans rather than a credit committee—a distinction that matters because the protocol can standardise settlement without guaranteeing loan quality.

Two amendments must work together

The planned system depends on two connected amendments. XLS-65 introduces Single Asset Vaults, which collect one type of asset from multiple depositors. The asset may be XRP, an issuer-backed token or a Multi-Purpose Token. Depositors receive vault shares representing their interest in the pool.

XLS-66 adds the lending machinery. A loan broker could use assets from a connected vault to issue fixed-term, uncollateralized loans to approved borrowers. The broker would establish the terms and oversee the relationship throughout the loan.

The broker may contribute first-loss capital, which absorbs an agreed portion of a default before losses reach other vault participants. It is a buffer, not borrower collateral: if losses exceed the cover, vault-share holders could still lose value. The amount of first-loss coverage, borrower concentration and withdrawal terms would be among the details depositors need to assess before committing funds, as outlined in this guide to how XRPL native lending would work.

Validator support remains near one-quarter

Neither amendment is active on the XRP Ledger mainnet. At the time of writing, XRPSCAN reports nine supporting validators for SingleAssetVault, equal to 25.71%, and eight for LendingProtocol, equal to 22.86%.

Under the current 35-validator XRPSCAN set, an amendment needs support from 28 validators and must maintain that level for two consecutive weeks. Software can include the required code before the rules are activated, so even a future 3.4.0 release would not make native lending available until both amendments complete that process.

Both amendments would need to activate: LendingProtocol draws liquidity from a Single Asset Vault, so approval of only one would not create a usable lending market.

Validator voting confirms that network operators are willing to adopt a set of transaction rules. It does not assess prospective borrowers, protect depositors against defaults or establish demand for the resulting products.

Version 3.4.0 is not available yet

Recent reports have said that Lending Protocol version 1.1 will arrive with XRPL version 3.4.0.

The latest stable release shown by 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 a release originated from an XRPL validator’s September 10 post. It provides useful guidance about the development schedule, but it is not a formal commitment from the XRP Ledger Foundation.

Version 1.1 is designed to address a practical problem in the original lending workflow. The existing model uses a custom dual-signature process when a loan is created. That requirement can force wallets and custodians to build specialised integrations before their customers can participate.

An open technical proposal introduces separate loan-proposal and loan-acceptance steps using standard XRPL transactions. Its authors say the change would reduce custody lock-in and allow a wider 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 credit products

Clearpool intends to build institutional credit products around the planned infrastructure. Its September 11 governance proposal seeks approval to expand to XRPL and launch initial yield products using XRP and Ripple’s RLUSD stablecoin.

Clearpool’s proposed use of RLUSD would give the planned products a dollar-denominated asset alongside XRP. RLUSD has already been used in other collateral settings, including when it became margin collateral on OKX. Exchange margin, however, is not the same as underwriting fixed-term, uncollateralized loans: the latter depends on the borrower, the broker and the pool’s loss protections.

The proposal also includes a one-for-one migration from CPOOL to CLEAR and a treasury recapitalization. Clearpool says 99% of the existing token supply has vested, leaving limited reserves for incentives and further development. Community discussion is scheduled to run for 14 days before a tokenholder vote.

Ripple has committed capital to support the planned XRP and RLUSD products, according to Clearpool, although the proposal does not disclose the amount. The products still depend on governance decisions at two levels: Clearpool holders must approve the expansion, and XRPL validators must enable the required amendments.

For readers, the proposal matters because it identifies the first prospective users of the architecture. It does not yet disclose the borrower types, pool size, target yield, loan terms or level of first-loss protection that would determine its actual risk.

Depositors would still carry borrower risk

The protocol can automate loan administration, but it cannot replace underwriting. A pool’s risk would depend on who operates it, which companies can borrow and how much of a default the broker’s first-loss capital can absorb.

A published yield would reveal little on its own. Prospective participants would need to examine the broker’s legal identity, underwriting record, largest borrower exposures, first-loss contribution, withdrawal restrictions and recovery process after default.

Liquidity also deserves attention. A vault may hold one liquid asset while committing a large portion of it to fixed-term loans. Depositors may face delayed withdrawals if a large share of the vault is committed to loans that cannot be repaid or transferred quickly.

The first repayments will matter more than launch day

The amendments would answer a technical question: can XRPL administer pooled, fixed-term credit onchain? A live market would answer the harder one: whether institutions will trust named brokers with uncollateralized borrowers and enough first-loss capital to make the yield worth the risk.

This article is provided for informational purposes only and does not constitute financial or investment advice.

Author

Related stories

Next article