Key points

  • BatchV1_1 regained majority support on September 25 after a brief drop reset its two-week activation countdown.
  • The amendment can group up to eight transactions and optionally require the entire group to succeed or fail together.
  • Activation is conditional on support remaining above 80% of the trusted validator list through October 9.

The XRP Ledger's BatchV1_1 amendment has restarted its two-week validator countdown, shifting its earliest possible activation to October 9. XRPL Dashboard data showed the corrected amendment with support from 30 of 35 trusted validators after regaining majority status at 14:46:02 UTC on September 25. The projected activation time is 14:46:02 UTC on October 9, provided support does not fall below the required level again.

A validator drop reset the clock

XRP Ledger amendments do not activate as soon as they cross the voting threshold. An amendment must retain support from more than 80% of the trusted validator list for 14 consecutive days. The dashboard currently calculates that requirement as 29 of 35 validators. BatchV1_1 had already entered a majority period on September 15, but that period ended on September 25 when support briefly fell to the threshold rather than remaining above it. The renewed 30-validator majority started a fresh countdown.

Related reporting: XRPL 3.4.0 adds closed-ended lending vaults

What the Batch amendment changes

BatchV1_1 is designed to let users submit as many as eight transactions as one group. Its transaction model supports several execution modes, including an all-or-nothing option in which every transaction must succeed for the batch to be applied. Other modes can sequence related actions while preserving their individual results. The feature is intended for workflows such as multi-step payments, exchanges and coordinated account operations that otherwise require separate submissions. A batch still contains individually signed inner transactions, and each transaction is subject to the ledger's normal authorization and fee rules. Grouping them changes how related actions are submitted and evaluated; it does not remove the underlying account controls or make unrelated transactions dependent on one another.

The corrected version replaces an earlier design

The current amendment is not the original Batch proposal. XRP Ledger developers withdrew the earlier version after identifying a critical signature-validation issue before activation. The corrected BatchV1_1 implementation was included in rippled version 3.3.0, which the XRP Ledger Foundation released in August. The official release notes say the revision fixes the disabled amendment and preserves the ability to combine up to eight inner transactions, including atomic execution.

October 9 remains conditional

The displayed date is therefore a forecast, not a fixed network upgrade appointment. Validator operators can change their votes, software upgrades can alter the trusted list and any loss of sustained majority support would reset the 14-day window again. CoinDesk independently reported the reset and the same October 9 projection, while noting that the upgrade had previously been expected around September 29.

A separate amendment also restarted

PermissionDelegationV1_1, another amendment included in the same software generation, is moving through a separate countdown. The dashboard projects its earliest activation for October 8 at 21:25:01 UTC if support holds. That proposal allows accounts to delegate specific permissions without sharing their master credentials. Its timing does not control BatchV1_1, but the parallel reset illustrates how validator voting can move proposed XRP Ledger changes independently.

What to watch next

The immediate evidence point is whether BatchV1_1 keeps at least 29 supporting validators throughout the window. If it does, the amendment should activate automatically at the first eligible ledger close after the projected time. If support weakens, the date will move again. Until activation is recorded on the ledger, applications should treat batch transactions as pending functionality rather than an available production feature.

Sources

AI-generated editorial image; not a photograph of the reported event. Prepared with AI assistance and source verification.