XRP Ledger back to normal after slowdown, but key security fix delayed to November

XRP Ledger returns to normal speed, but a security fix slips to November

The XRP Ledger, a blockchain built for fast payments, has recovered from intermittent transaction-processing delays. Network operators applied a recommended configuration change, and on Oct. 22 XRP Ledger Operations confirmed that ledger-closing times were back to normal.

At the same time, a separate protocol upgrade that corrects several security flaws has been delayed. The amendment briefly lost the validator support it needs, so it must restart its approval countdown and now waits for activation in November.

The main points

• On Oct. 21, some ledgers on the XRP Ledger began taking longer than usual to close, disrupting the network's typical three-to-five-second settlement rhythm.
• Operators applied a recommended configuration change, and XRPL Operations confirmed normal closing times on Oct. 22.
• Developers are still testing a software update meant to fix the underlying cause.
• The fixCleanup3_4_0 amendment was headed for Oct. 23 activation, but validator support briefly dropped, pushing its activation to November.
• The ledger requires more than 80% of trusted validators to back an amendment for 14 straight days before it can go live.

What XRPL Operations confirmed

XRP Ledger Operations, the team that monitors the network, said on Oct. 22 that closing times had returned to normal after operators applied the configuration change. In an earlier update, the team said most ledgers had continued closing normally, but the intermittent delays prompted developers to investigate the network's behavior and prepare a software correction.

The team distributed the recommended change for xrpld, the ledger's server software, to hub, validator, and node operators. These operators run the servers that keep the network connected and agree on the order of transactions. Normal closing times returned by Oct. 22, though developers continued testing a point release intended to address the underlying cause.

David Schwartz on what may have caused the delays

David Schwartz, one of the XRP Ledger's original architects and Ripple's former chief technology officer, offered his own reading of the incident. He said his hub had kept operating normally after an earlier incident he believed was unrelated, but that he restarted it with the recommended configuration change.

"I gather the issue was related to servers trying too hard to get too many transactions into each ledger."

Asked whether this pointed to a practical limit on how many transactions the network can process, Schwartz acknowledged a link between transaction volume and how often the ledger can close:

"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."

TPS stands for transactions per second, a common measure of blockchain speed. His comments suggest a possible trade-off between packing more transactions into each ledger and keeping settlement times steady. His remarks were his own interpretation, not a confirmed technical finding.

A security amendment loses validator support

Separately, the fixCleanup3_4_0 amendment, introduced with September's xrpld 3.4.0 release, has hit a governance setback. It corrects technical issues involving token permissions, automated market makers, asset vaults, lending operations, and escrow transactions. Automated market makers are on-chain systems that let people swap tokens without a traditional order book.

One fix addresses a permission-delegation flaw. Under specific circumstances, an account authorized to destroy certain fungible tokens could create additional tokens instead. The ledger's documentation advises issuers not to delegate the affected PaymentBurn permission until the correction is active. Other changes improve precision in vault accounting, enforce token-balance safeguards, and correct transaction-handling behavior across decentralized trading and lending functions.

The amendment had been moving toward activation on Oct. 23 before validator backing briefly fell below the supermajority required to change the ledger's rules. Under XRPL rules, more than 80% of trusted validators must support an amendment, without interruption, for 14 days before it activates. Validators are the independent servers that agree on the ledger's state. The temporary loss of support on Oct. 21 restarts that countdown, delaying activation by roughly two weeks into November.

What is confirmed

• The slowdown began on Oct. 21, and XRPL Operations confirmed normal ledger-closing times on Oct. 22 after the configuration change was applied.
• Developers are preparing and testing a software correction for the underlying cause.
• The fixCleanup3_4_0 amendment corrects issues affecting token permissions, automated market makers, asset vaults, lending, and escrow, including the PaymentBurn delegation flaw.
• The amendment lost validator support, and its activation now awaits November under the ledger's approval rules.

What remains unclear

• Developers have not established whether the slowdown reflected a broader capacity constraint on the network or a software behavior that can be corrected without affecting throughput.
• Schwartz's explanation of the cause was his personal understanding of the issue, not a confirmed diagnosis.

Why this matters for XRPL users

The slowdown raised concerns about the ledger's settlement reliability at a time when XRPL is expanding in institutional payments, stablecoins, and tokenized assets. Stablecoins are digital tokens whose value is pegged to a stable asset such as the US dollar. Applications such as RLUSD stablecoin transfers, tokenized securities, and institutional payment services depend on predictable settlement, and further disruption could complicate the rapid movement of funds or collateral. The security amendment matters because it closes flaws in the rules that govern these financial applications.

What happens next

• Developers are testing a point release intended to fix the underlying cause. Its outcome will show whether the configuration change is a lasting solution or whether more adjustments are needed under heavier transaction loads.
• The fixCleanup3_4_0 amendment needs validator support above the 80% threshold, sustained for 14 days, before it can activate in November.
• Until the amendment is active, XRPL documentation advises token issuers not to delegate the PaymentBurn permission.

Sources

• CryptoSlate