XRP Ledger bug fix nears approval as lending launch remains on hold

The XRP Ledger has moved closer to activating a package of software fixes on October 23 after securing the 29 validator votes required for approval, although its planned lending system remains below the network’s voting threshold.

According to the XRPL Dashboard, the amendment known as fixCleanup3_4_0 had received support from 29 of the 35 validators on the network’s default trusted list as of October 19. The proposal is undergoing its required two-week approval period, with activation projected for Friday if that support continues.

XRPL lending still lacks the validator votes to go live, and the Oct. 23 amendment is already patching vaults and lending before either ships. Fine by me. A lending bug on a ledger with no rollbacks gets pricey. Faster, or wait? pic.twitter.com/xQhmhCEiXH

— Rob XRP (@robxrp1) October 18, 2026

The update contains fixes affecting token transactions, vault accounting, automated market makers and lending-related processes. Its activation would not enable lending on the network because the main lending and vault proposals are undergoing separate votes.

The LendingProtocol amendment had 19 supporting validators, leaving it 10 votes short of the required 29. SingleAssetVault, which would hold funds used for loans, had 21 votes and needed eight more.

XRP Ledger bug fix targets October 23 activation

The fixCleanup3_4_0 amendment reached the required validator majority on October 9, beginning a 14-day period during which support must remain above 80%.

At the October 19 checkpoint, the proposal had completed approximately nine days of that waiting period. The dashboard projected October 23 at around 09:34 UTC as the point when the required approval period would finish.

Actual activation could occur shortly afterward because the XRP Ledger processes amendment decisions at designated intervals known as flag ledgers.

According to the network’s amendment documentation, these checks occur every 256 ledgers. Once the required waiting period has passed, the network records the amendment decision and applies the updated rules in subsequent ledgers.

On the dashboard’s October 19 snapshot, the fix had exactly 29 votes, leaving no additional supporting validators beyond the required minimum. If one of those validators withdrew support before the waiting period ended, the proposal would fall below the necessary majority.

Under XRPL’s rules, losing that majority restarts the two-week approval period when sufficient support is restored. The October 23 activation time is therefore a projection, not confirmation that the update has already taken effect.

Server operators must run software that recognizes approved amendments. According to XRPL documentation, servers using older versions without the necessary code can become amendment-blocked once the network begins enforcing new rules.

XRPL developers released version 3.4.0 of the xrpld server software on September 16 and advised operators to upgrade to maintain compatibility.

XRP Ledger lending remains 10 votes short of approval

Although parts of the pending fix relate to lending, the network’s lending service has not received enough validator support to activate.

The LendingProtocol proposal, known as XLS-66, had 19 of the 35 trusted validator votes in the October 19 snapshot. Its companion SingleAssetVault proposal, XLS-65, had 21 votes. Both require support from at least 29 validators for two continuous weeks before taking effect.

The proposals must activate before the planned lending system can operate on the XRP Ledger mainnet. Even if both reached the required vote count immediately, the two-week waiting rule means they could not activate alongside the October 23 bug-fix package.

A separate amendment, LendingProtocolV1_1, had 19 supporting votes. Introduced in version 3.4.0, it proposes changes to the design of lending vaults and the accounting of loan interest.

The additional amendment would require newly created loan brokers to use closed-ended vaults, where deposits, lending and withdrawals follow defined stages.

The proposal divides that process into subscription, investment and redemption periods.

It would change interest accounting so that revenue is recognized when borrowers actually make payments, instead of recording all scheduled interest when a loan begins.

Those proposed changes remain subject to validator approval.

In September, crypto.news reported the software release and its two new amendments, noting that the release of working code did not itself activate the new lending rules.

The latest validator tally shows the bundled maintenance update progressing ahead of the financial features it partly supports.

Lending design relies on brokers for borrower checks

Under the proposed XRPL lending system, depositors would contribute assets to a shared vault, and a loan broker would arrange fixed-term loans using those pooled funds.

The ledger would record loan obligations, repayments and other associated transactions.

Borrowers would not have to provide collateral directly through the protocol.

Instead, loan brokers would assess borrowers’ financial condition and ability to repay using checks performed outside the blockchain. This arrangement would give brokers responsibility for deciding which borrowers qualify and what lending terms they receive.

The published design includes an optional protection mechanism called first-loss capital. A broker could place additional assets into a separate account to help cover losses when borrowers fail to repay their loans.

The protection would depend on the amount made available. It would not guarantee that depositors could recover all their funds after a default. XRPL’s documentation explains that the protocol does not currently provide automatic on-chain collateral management or liquidation.

Loan brokers would have the option to declare a loan in default after a borrower misses a payment and the relevant grace period expires.

The protocol is intended to support institutional lending activities using XRP and other eligible assets issued on the ledger. Ripple has supported the development of the lending proposals as part of its work with financial institutions.

In August, Ripple backed both amendments through its validator while they remained below the activation threshold.

A separate June security re-audit of lending reported no critical or high-risk findings in the changes reviewed by cybersecurity firm Halborn.

The absence of critical findings in that review did not amount to network approval or a guarantee against future software problems.

Latest software update addresses vault and transaction errors

The September 16 xrpld 3.4.0 release notes describe several corrections included in fixCleanup3_4_0.

One fix prevents certain automated market maker recovery transactions from destroying a user’s liquidity-provider tokens when rounding would result in no underlying assets being recovered.

Other changes address calculations used when people deposit or withdraw funds from vaults. The fixes are designed to keep vault asset balances and the number of shares issued to depositors consistent during transactions.

For lending, developers updated rules covering authorization, frozen assets, credentials and payment destinations. The release notes specify changes involving how loan defaults interact with asset freezes and how the protocol checks withdrawals from permissioned vaults.

Separate adjustments address permissioned decentralized exchange transactions, NFT offers and escrow processing. One signing-related correction introduces distinct cryptographic prefixes for different signature roles. The change prevents a signature intended for one role from being reused in another.

The release also tightens restrictions on certain token transactions and enforces checks that were previously recorded only in software logs. These corrections are included in the software release but require the relevant amendment to activate before its new transaction rules become enforceable on mainnet.

The version 3.4.0 release additionally changes how compatible server packages are distributed, with signed Linux installation packages provided through the XRPL Foundation.

The foundation’s release notice instructs operators to upgrade their servers to version 3.4.0 to maintain service as the network adopts the new amendments.