XRPL recovers from network slowdown as critical security upgrade faces two-week delay

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.

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.