The XRP Ledger’s BatchV1_1 amendment is now projected to activate on October 9 after validator support briefly fell below the level required to preserve its original two-week countdown. According to the XRPL amendment dashboard, the amendment regained its majority on September 25 at 14:46:02 UTC and currently has support from 30 of 35 trusted validators. October 9 is therefore the earliest projected activation point if that supermajority remains uninterrupted, not a guaranteed launch date.
XRPL amendments must maintain support from more than 80% of trusted validators for 14 consecutive days before becoming active. With 35 validators in the current observed set, that means at least 29 affirmative votes because 28 represents exactly 80%. BatchV1_1 originally entered its qualifying window on September 15, but the majority disappeared during a September 25 flag ledger before forming again later that day. The interruption erased the previous countdown rather than pausing it, pushing the projected activation from September 29 to October 9.
Batch Adds Four Multi-Transaction Execution Modes
BatchV1_1 allows users to submit between two and eight transactions together under four execution modes: All or Nothing, Only One, Until Failure and Independent. The most significant for multi-leg settlement is All or Nothing, under which every inner transaction must succeed or none are applied. That atomic structure can reduce execution risk when several ledger actions need to settle as one coordinated operation. XRPL documentation gives use cases spanning payments, trading and multi-account workflows.
The feature arrived in xrpld v3.3.0 alongside PermissionDelegationV1_1, ConfidentialTransfer and other amendments aimed at expanding XRPL’s transaction and token infrastructure. That v3.3.0 upgrade introduced BatchV1_1 without automatically activating it on Mainnet, because validator approval remains a separate governance step. Software support and mainnet activation are therefore distinct milestones on XRPL.
A newer development now sits directly beside the Batch rollout. XRPL released xrpld 3.4.1 on September 25 as an emergency update containing fixBatchV1_2, which rejects Batch inner transactions using the wrong wrapper and includes additional security and stability hardening. The fix has its own majority window and is currently projected to activate at 14:12:51 UTC on October 9, roughly 33 minutes before BatchV1_1’s projected time. BatchV1_1 and its new fix are separate amendments, and both still depend on uninterrupted validator support.
Permission Delegation Faces a Separate October Deadline
PermissionDelegationV1_1 has also had its activation clock reset. The amendment lost its majority on September 23 and regained it on September 24 at 21:25:01 UTC. It currently has exactly 29 of 35 affirmative votes, the minimum needed to preserve its countdown, placing its projected activation on October 8. Any fall to 28 supporting validators would reset that 14-day window again.
The amendment allows an account to grant specified permissions to another account without transferring its primary signing keys, replacing an earlier PermissionDelegation implementation that was disabled after a critical bug was identified. These controls sit within a broader push toward developer and institutional tooling for tokenization, payments and account permissions. Delegated authority can reduce operational key sharing, but it only becomes Mainnet functionality after the amendment completes consensus activation.
The upcoming amendments arrive after XRPL recently recorded 3,254 transactions in a single validated ledger, although that isolated record does not establish sustained throughput or predict how Batch will affect network capacity. Batch primarily changes transaction coordination and atomic execution, not the ledger’s underlying throughput ceiling. The next concrete milestone is now October 8 for PermissionDelegationV1_1, followed by the paired October 9 windows for fixBatchV1_2 and BatchV1_1, provided validator support remains above the required threshold.
Jack Reynolds is SatoshiPick’s infrastructure mind. Based in Denmark, he follows Bitcoin, Ethereum, Layer 1 networks, stablecoins and DeFi with a practical question always in the background: does this actually make crypto work better?
His articles focus on the systems beneath the headlines: settlement rails, protocol upgrades, stablecoin usage, DeFi coordination and the regulatory limits around them. Jack avoids turning technical coverage into a maze. He explains what is live, what is still experimental and why the difference matters.