XRP Ledger's fixCleanup3_4_0 Slips to 4 November After a Two-Hour Dip

The XRP Ledger was due to activate a bug fix at 09:34 UTC on Friday. It did not. Support for the fixCleanup3_4_0 amendment fell to 26 of 35 trusted validators at about 12:54 UTC on Wednesday, three short of the 29 the network requires, and that one reading reset a 14-day clock. Votes returned to 29 at 14:46 UTC the same day. The earliest the fix can now take effect is about 14:46 UTC on 4 November, and only if nothing slips again.

Fourteen days, checked every fifteen minutes

The XRP Ledger changes itself by amendment. A proposal needs more than 80% of the default trusted validator list, which comes to 29 of 35 at present, and it needs that support at every flag ledger, the checkpoint the network reaches roughly every quarter of an hour. Miss one and the fortnight starts over. CoinDesk, FinanceFeeds and The Crypto Times describe the mechanism the same way, and all three date the dip and the recovery identically. The gap lasted about two hours. This is the second time this autumn that one reading below the bar has pushed an XRPL upgrade back.

Nobody says which validators left

The cause is not established anywhere read here. CoinDesk notes that neither tracker it consulted shows which validators dropped off, and that a validator offline or restarting when a checkpoint lands counts as a no vote. That is one account's reading of the possibilities, not a finding. No operator has published an explanation, and neither Ripple nor RippleX has addressed the dip in anything read here. The ledger kept closing blocks throughout. An amendment vote runs alongside consensus on transactions, not inside it.

Two counts of the same cushion

Where the accounts part is the current margin. CoinDesk puts support at 31 of 35 on Thursday, two votes above the bar. The Crypto Times gives the same 31, calling it about 88.6%. FinanceFeeds reads 32 of 35 off the XRPL Dashboard for 22 October. Two accounts say 31 and one says 32, for the same day, and none of the three mentions another figure. They do not reconcile. When the amendment first cleared the bar is muddled too. FinanceFeeds and The Crypto Times both say 9 October at exactly 29 votes, which matches the 23 October activation this desk reported last Sunday, while CoinDesk dates the 29-vote reading to a Monday. We could not establish what that Monday refers to.

What the fix does, and what still cannot start

fixCleanup3_4_0 shipped with xrpld 3.4.0 in September. It closes a condition under which an account granted permission only to burn an issuer's tokens could create new ones, on CoinDesk's reading of the release notes. FinanceFeeds describes the same delegated-permission problem arising when a payment crossed a zero-balance boundary, and says the documentation does not show it was ever exploited. That last point rests on one account. The amendment also changes how the lending code decides that a loan is late or in default, which matters only once lending exists.

It does not yet. Ripple's lending system, pitched to banks and payment companies since June, lets lenders put XRP or other tokens into vaults that a broker lends out for a fixed term. Its amendments are nowhere near the bar. At the 22 October checkpoint FinanceFeeds read SingleAssetVault at 21 validators, with LendingProtocol and LendingProtocolV1_1 at 19 apiece, against the same 29 needed. CoinDesk puts it without the counts: the lending system lacks the support to start a countdown at all. Nothing read here gives those three a route to 29, and nothing gives lending a launch target. The 4 November date belongs to the bug fix alone, and it holds only while 29 validators keep voting yes every fifteen minutes for a fortnight.