One Dip Below 80% Pushes the XRP Ledger's Batch Upgrade to 9 October

The XRP Ledger's Batch amendment lost its majority for part of one day, and that cost it ten. Support is back at 30 of the 35 trusted validators the network tracks, but the clock it had been running since 15 September is gone. A fresh fourteen-day window started in its place, which puts the earliest activation at 9 October at 14:46 UTC. The old target was 29 September. Nothing about the feature itself changed.

What a lost majority costs

An amendment on the XRP Ledger ships dormant inside the server software and waits for validators to vote it in. The bar is more than 80% of trusted validators, held without a break for two weeks. Continuity is the whole rule.

The network "records a lost-majority event and removes the pending amendment from its countdown until enough validators support it again," coinpaper wrote on Saturday.

Coindoo puts the same mechanic in plainer terms, that an amendment needs uninterrupted backing through the full window even when its vote count later returns to the same level. When the dip happened is thinly sourced. Coindoo has the majority lost on 25 September and reformed later that day; CoinDesk and a KuCoin flash say only that support fell below the threshold briefly. Which validators changed their vote, and why, appears in none of the accounts. The ledger's own amendment dashboard would not load at the time of writing, so every count here is an outlet's reading of a tracker.

Twenty-eight votes or twenty-nine

The threshold is reported two ways, and the arithmetic accounts for both. Eighty per cent of 35 validators is 28. More than 80% is 29. Coindoo takes the second reading and calls 30 a one-vote cushion, with a fall to 28 setting off another reset. This desk's 20 September report gave the bar as 28, from CoinDesk and Phemex that week. The two figures do not reconcile, and neither outlet acknowledges the other.

Two to eight transactions, or up to eight

Batch bundles transactions so that they settle together or not at all. The count differs by account. CoinDesk says up to eight; coinpaper and KuCoin say two to eight. Four execution modes exist, and the one every account names is all-or-nothing. The use it was built for is delivery versus payment, where a buyer's money and a tokenized asset move in the same ledger close, so neither leg can land on its own. Multi-step NFT operations and swaps are the other examples given.

This is the second version of the feature. The first was pulled before activation in February over a flaw in signature checking, which CoinDesk calls critical and KuCoin describes as an authorization problem. Same bug, two labels. The rebuilt amendment shipped in version 3.3.0 in August, and has been waiting on a vote since.

A second amendment moved with it

PermissionDelegationV1_1 went through the same loss and recovery. Its earliest activation moved from 5 October to 8 October, on CoinDesk's account and no other in this sweep. The feature lets an account owner hand specific tasks to another account without sharing signing keys, which matters for custodians and for applications that pay fees on a user's behalf.

Nine October is still conditional

Neither date is fixed. A fall to 28 votes resets the count again, and the only confirmation that settles anything is an EnableAmendment pseudo-transaction appearing on the ledger, a detail coindoo alone points to. Ten days is a short delay for a feature that has been rebuilt once already. It is also the second time this year that what stands between Batch and the mainnet is a vote rather than the code.