XRP Ledger Institutional Credit Plan Still Pending Verifier Approval

Core Points

The lending function of the XRP Ledger (XRPL) main network is still idle. The support rate of the verification node is well below the threshold required for activation. Version 3.4.0 has not been confirmed for release. Clearpool plans to launch products based on XRP and RLUSD. Credit evaluations will remain off-chain.

Ripple views credit as the missing link

Jasmine Cooper, product leader at Ripple, points out that lending is a missing link in the tokenized financial market. Assets can now be issued, transferred and settled on-chain, but institutions still need to finance these assets and manage short-term liquidity.

In a June 29 article, Cooper outlined several possible application scenarios: payment companies can borrow while waiting for settlement, market makers can finance inventories, and corporate treasury departments can make idle digital assets work.

The proposal does not require the ledger to determine whether a borrower deserves credit. Banks, fund managers and professional underwriters will continue to review financial statements, collateral arrangements, legal documents and concentration limits. XRPL will record the agreed loan and apply its repayment schedule, interest terms and default rules.

This model makes the ledger the manager of loans rather than the credit committee-a distinction that is crucial because agreements can standardize settlement without ensuring loan quality.

Two amendments must work together

The planned system relies on two interrelated amendments.

XLS-65"Single Asset Vaults" were introduced to collect one type of asset from multiple depositors. The asset can be an XRP, an issuer backed token, or a multipurpose token (MPT). Depositors receive a share of the treasury that represents their interest in the pool.

XLS-66 adds a lending mechanism. Loan brokers can use assets from connected vaults to issue fixed-term, unsecured loans to approved borrowers. The broker will establish terms and monitor the relationship throughout the loan period.

Brokers may provide "first-loss capital", which absorbs an agreed proportion of default losses before losses hit other treasury participants. This is a buffer mechanism, not borrower collateral: if losses exceed coverage, treasury share holders may still suffer a loss of value. The first loss coverage amount, borrower concentration and withdrawal terms will be among the details depositors need to evaluate before committing funds, as outlined in the guide on how XRPL native lending works.

Verification node support rate is still close to a quarter

Neither amendment is activated on the XRP Ledger main network. As of the time of writing this article, XRPScan reported that there are 9 verification nodes supporting SingleAssetVault, accounting for 25.71%, and 8 verification nodes supporting LendingProtocol, accounting for 22.86%.

In the current XRPScan set of 35 verification nodes, an amendment requires support from 28 verification nodes and must maintain that level for two consecutive weeks. The software can include the required code before rules are activated, so even if version 3.4.0 is released in the future, native lending features will not be available until the two amendments complete the process.

Both amendments must be activated: LendingProtocol draws liquidity from the Single Asset Vault, so approving only one of them will not create a usable lending market.

The verification node votes to confirm that the network operator is willing to adopt a set of transaction rules. It does not assess potential borrowers, does not protect depositors from default, and does not establish demand for resulting products.

Version 3.4.0 is not yet available

Recent reports say that version 1.1 of the Lending Protocol will come with version 3.4.0 of the XRPL.

The latest stable version shown in the XRPL Foundation GitHub repository is 3.3.0. The official amendment catalog lists LendingProtocolV1_1 as "under development" and has not yet released a dated release announcement for version 3.4.0.

Expectations for release stem from a post posted by the XRPL Verification Node on September 10. The post provides important guidance on the development timeline, but it does not come from a formal commitment from the XRP Ledger Foundation.

Version 1.1 is designed to address a practical issue in the original lending workflow. Existing models use a custom dual-signature process when creating loans. This requirement may force wallets and managed services to build specialized integrations before their customers engage.

A published technical proposal introduces separate "loan offer" and "loan acceptance" steps using standard XRPL transactions. Its authors said the change would reduce custody lock-ins and allow a wider range of wallets to support the protocol.

The proposal and related implementation work have not yet been completed. Until the code is completed and incorporated into a stable release, version 1.1 will remain a development project, not an available XRPL feature.

Clearpool proposes XRP and RLUSD credit products

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

Clearpool proposes to use RLUSD, which will provide a dollar-denominated asset for planned products that coexist with XRP. RLUSD has been used in other mortgage settings, including becoming margin collateral on OKX. However, exchange margins are different from underwriting fixed-term, unsecured loans: the latter depends on the loss protection mechanisms of the borrower, broker and pool.

The proposal also includes a 1:1 migration of CPOOL to CLEAR and a treasury reorganization. Clearpool said 99% of the existing token supply has been vested, leaving limited reserves for incentives and further development. The community discussion is planned to last for 14 days, followed by a vote by token holders.

According to Clearpool, Ripple has committed capital to support planned XRP and RLUSD products, although the proposal did not disclose specific amounts. These products still depend on governance decisions at two levels: Clearpool holders must approve extensions, and XRPL verification nodes must enable the required amendments.

The importance of this proposal to readers is that it identifies the first potential users of the architecture. It has not disclosed the type of borrower, pool size, target yield, loan terms or level of first-loss protection that will determine the actual risk.

Depositors still bear borrower risk

This agreement automates loan management, but cannot replace underwriting. The risk of the pool depends on who the operator is, which companies can borrow, and how much default losses can be absorbed by the broker's first-loss capital.

The reported yields themselves reveal little information. Potential participants need to examine the broker's legal identity, underwriting record, maximum borrower exposure, first loss contribution, withdrawal limits and post-default recovery process.

Liquidity is also worthy of attention. Treasury may hold a highly liquid asset but also use most of it for fixed-term loans. If most of the vault's funds are committed to loans that cannot be repaid or transferred quickly, depositors may face withdrawal delays.

Initial repayment is more important than launch date

The amendment will answer a technical question: Can XRPL manage pooled, fixed-term credits on the chain? An active market will answer the more difficult question: whether institutions will trust well-known brokers with unsecured borrowers and brokers with enough first-loss capital to make the gains worth the risk.

This article is for reference only and does not constitute financial or investment advice.