XRPL's Batch amendment resets and cannot activate before 9 October
Victoria Shinder2 min readThe XRP Ledger's Batch amendment will not switch on at the end of September as it had been on course to do. Support among trusted validators for BatchV1_1 briefly dropped below the 80% threshold, and under the ledger's rules that erases the time already accumulated: an amendment has to hold more than 80% support for two uninterrupted weeks before it activates. We checked the ledger directly on 26 September. A public server reports BatchV1_1 holding a majority since 25 September at 14:46 UTC, which puts the earliest activation at 9 October around the same time if support holds, and the amendments dashboard showed it at 85.71% - 30 of 35 validators.
Batch lets an account submit up to eight transactions as one unit, including an all-or-nothing mode in which either every inner transaction succeeds or none do. That is the building block for delivery-versus-payment on the ledger: a buyer's payment and the transfer of a tokenised asset complete together or not at all. BatchV1_1 is itself the second attempt: according to CoinDesk, the original amendment was withdrawn before activation after a critical flaw in signature checking was found, and the corrected version shipped with rippled 3.3.0 in August.
A second amendment reset in the same way. PermissionDelegationV1_1, which lets an account authorise another account to perform specific actions without handing over its signing keys, has held a majority since 24 September at 21:25 UTC, making 8 October its earliest date; the dashboard showed it at 82.86%. The dashboard also lists a fixBatchV1_2 amendment counting down alongside.
What it means
An amendment's date on the XRP Ledger is a forecast, not a schedule. Any validator that changes its vote during the two-week window can reset the count, and the margin here is thin: 30 of 35 is only a validator or two above the threshold. Teams building on Batch - RippleX has said projects are being designed around it, without naming them - should treat 9 October as the earliest possible date and plan releases that do not depend on it.
The practical check is cheap: the feature method on any rippled server returns each amendment's majority timestamp, and adding two weeks gives the real earliest activation. That number, not a date quoted in coverage, is what a deployment plan should track.