XRP Ledger bug fix delayed to Nov. 4 after validator support briefly fell below threshold

XRP Ledger bug fix delayed to Nov. 4 after validator support briefly fell below threshold

N
News Editor
2026-10-22 04:36:20
A bug fix on the XRP Ledger has been pushed back to Nov. 4 after validator support briefly dropped below the network’s approval threshold, resetting the required 14-day activation clock less than two days before the change was set to go live. The amendment, known as fixCleanup3_4_0, had been scheduled for activation at 09:34 UTC on Oct. 23, but support fell to 26 of the network’s 35 default trusted validators at a checkpoint on Wednesday, according to XRPL Dashboard. By 14:46 UTC, support had recovered to 29, enough to restart the countdown. XRPLWin now shows the new activation time as 14:46 UTC on Nov. 4. Support has since climbed to 31 of 35 validators, above the 29 needed to maintain the threshold. The patch addresses a token-creation loophole and changes how vault and lending code calculates whether a loan is late or in default. Still, the broader lending system tied to that code has not yet won enough validator backing to begin its own activation process, and it remained offline as of Thursday.

An XRP Ledger bug fix has been delayed until Nov. 4 after validator backing briefly slipped below the network’s approval threshold, wiping out a nearly completed 14-day activation countdown.

The amendment, called fixCleanup3_4_0, had been on track to go live at 09:34 UTC on Oct. 23. That changed when support fell to 26 of the 35 default trusted validators at a checkpoint at 12:54 UTC on Wednesday, according to XRPL Dashboard.

Support drop reset the clock

On the XRP Ledger, rule changes need backing from more than 80% of the 35 validators the network trusts by default. That means at least 29 votes. Validators are independent servers that agree on which transactions count.

The network checks that support roughly every 15 minutes, and the threshold has to hold at every check for 14 straight days. A single miss resets the countdown, even if the drop lasts only briefly.

That is what happened here. The fix was sitting at exactly 29 votes on Monday, leaving no margin for error. After support dropped on Wednesday, the countdown was reset. By 14:46 UTC, the vote count had returned to 29, starting a fresh 14-day period.

XRPLWin now lists the amendment as going live at 14:46 UTC on Nov. 4. Support has since risen to 31 of 35 validators, giving the proposal two votes of cushion this time, compared with none during the first run.

What the patch changes

According to the xrpld 3.4.0 release notes, the patch closes a loophole that could, under certain conditions, allow an account that was only supposed to burn an issuer’s tokens to create new ones instead.

It also changes how vault and lending code determines when a loan is late or in default.

That code is part of the lending system Ripple has pitched to banks and payment companies since June. In that setup, lenders place XRP or other tokens into vaults and a broker lends them out for a fixed term. As of Thursday, the broader lending system was still not live.

Broader lending system still lacks support

While the bug fix has regained enough backing to restart its activation process, the larger lending system has not secured enough validator support to begin its own countdown.

Neither of the XRPL tracking sites cited in the report shows which validators dropped off during the two-hour dip. The report noted that only votes from validators the network actually hears from at each check are counted. A server that is offline or restarting at the wrong moment is treated the same as a no vote.

This article was originally published by Bit.Fan. For more cryptocurrency news and market insights, visit www.bit.fan.
100

Disclaimer:

The market information, project data, and third-party content displayed on this platform are for industry information sharing only and do not constitute any form of investment advice or return commitment.

Cryptocurrency trading carries high risks. Users should fully assess their risk tolerance and make independent decisions. All profits, losses, and legal responsibilities are borne by the users themselves.