The XRP Ledger (XRPL) has recovered from intermittent transaction-processing delays, although developers are still preparing a permanent software correction.
On Oct. 22, XRP Ledger Operations confirmed that ledger-closing times had returned to normal after a configuration change recommended to network operators.
The disruption coincided with a separate setback for a protocol amendment designed to correct vulnerabilities affecting token permissions, lending and other financial applications. Its activation has been pushed to November after validator support briefly weakened.
The developments come as XRPL expands its role in institutional payments, stablecoins and tokenized assets, increasing the importance of reliable settlement infrastructure and safeguards governing financial transactions.
XRP Ledger slowdown exposes transaction-processing challenges
The operational problem emerged on Oct. 21 when some ledgers began taking longer than usual to close, disrupting the blockchain’s typical three-to-five-second settlement rhythm.
XRPL Operations said most ledgers continued closing normally, but intermittent delays prompted developers to investigate the network’s behavior and prepare a software correction.
As the delays persisted, the team distributed a recommended xrpld configuration change to hub, validator, and node operators.
The adjustment restored normal closing times by Oct. 22, according to the operations team, although developers continued testing a point release intended to address the underlying cause.
David Schwartz, one of XRPL’s original architects and Ripple’s former chief technology officer, offered additional insight into what may have contributed to the incident.
He said his own hub had continued operating normally after an earlier incident he believed was unrelated, but he restarted it with the recommended configuration change.
Schwartz said:
“I gather the issue was related to servers trying too hard to get too many transactions into each ledger.”
Asked whether that suggested XRPL had encountered a practical limit on its transaction-processing capacity, Schwartz acknowledged a connection between transaction volume and closing frequency.
He added:
“Yes and no. We can’t close a ledger more often than every 4 seconds. So limiting the number of transactions per ledger does not necessarily impose a TPS limit.”
His remarks point to a potential trade-off between processing more transactions in each ledger and maintaining consistent settlement times.
However, developers have not established whether the incident reflected a broader network capacity constraint or a software behavior that can be corrected without affecting throughput.
The distinction carries commercial implications, as XRPL attracts applications that require predictable settlement, including RLUSD stablecoin transfers, tokenized securities, and institutional payment services.
Further disruption could complicate transaction processing for services that depend on rapid movement of funds or collateral.
The forthcoming software release will therefore be important in determining whether the configuration change provides a lasting solution or whether additional adjustments are needed to maintain performance under heavier transaction loads.
Validator voting setback delays financial safeguards
Separately, XRPL’s fixCleanup3_4_0 amendment has encountered a governance setback that will prolong the activation of several corrections to its financial infrastructure.
The amendment, introduced in September’s xrpld 3.4.0 release, addresses technical issues involving token permissions, automated market makers, asset vaults, lending operations and escrow transactions.
Among the changes is a fix for a permission-delegation flaw that could let an account authorized to destroy certain fungible tokens create additional tokens under specific circumstances.
The network’s documentation advises issuers against delegating the affected PaymentBurn permission until the correction becomes active.
Other changes improve precision in vault accounting, enforce token-balance safeguards and correct transaction-handling behavior across decentralized trading and lending functions.
The proposed protections had been moving toward an Oct. 23 activation before validator backing briefly fell below the supermajority required to change XRPL’s protocol rules.
XRPL requires support from more than 80% of trusted validators to remain uninterrupted for 14 days before an amendment can activate.
The temporary loss of support on Oct. 21 erased the amendment’s accumulated approval period, despite backing subsequently recovering above the required threshold.
The XRPLWin amendment tracker now places the earliest activation on Nov. 4, provided the renewed majority remains intact.
XRPL contributor Vet confirmed that additional validator votes had restored the amendment’s activation countdown. He also clarified that fixCleanup3_4_0 addresses older protocol issues and is unrelated to the latest ledger-closing delays.
The postponement extends the period before the affected token-permission safeguards become enforceable. It also delays corrections intended to improve accounting and transaction handling in XRPL’s developing lending infrastructure.
That infrastructure still needs additional protocol approvals before native lending services can go live.
A further decline in validator support would reset the amendment’s waiting period again, potentially pushing activation beyond Nov. 4.
Featured,Governance,Stablecoins,Technology#XRPL #recovers #network #slowdown #critical #security #upgrade #faces #twoweek #delay1792715448
