The XRP Ledger is approaching the activation of Batch V1.1, an amendment designed to let users coordinate multiple transactions within a single batch. The amendment currently has support from 30 of 35 trusted validators, approximately 85.7%, placing it above the threshold required for its 14-day activation period. If that majority remains intact, Batch V1.1 is projected to activate on September 29 at approximately 14:06 UTC.
According to the live XRPLDashboard amendment tracker, Batch V1.1 first recorded its required majority on September 15 at 14:06:41 UTC. XRP Ledger amendments must maintain support from at least 80% of trusted validators continuously for two weeks before becoming enabled. A drop below the threshold during that period would cancel the existing majority and require the countdown to begin again after support recovers.
Batch Supports Four Transaction Execution Modes
Batch V1.1 implements XLS-56 and allows between two and eight inner transactions from one or multiple accounts to be submitted together. The feature supports atomic execution, but not every batch is automatically all-or-nothing. Developers can select from four modes depending on how the grouped transactions should behave: All or Nothing, Only One, Until Failure and Independent.
Under ALLORNOTHING, every inner transaction must succeed or none of them are applied, making the mode suitable for workflows such as atomic swaps or coordinated multi-party settlements. ONLYONE applies only the first successful operation, UNTILFAILURE processes transactions until one fails, and INDEPENDENT attempts every transaction regardless of failures elsewhere in the batch. That flexibility makes Batch broader than a single atomic-payment primitive and gives developers several ways to coordinate related ledger actions.
The eight-transaction ceiling was chosen to balance utility against performance and abuse concerns, according to the XLS-56 specification. Inner transactions also carry no individual fee or independent signature; authorization is handled through the outer Batch transaction and, where multiple accounts participate, through BatchSigner authorization. The design is intended to keep related operations coordinated while preventing unsigned inner transactions from being extracted and submitted independently.
V1.1 Replaces a Withdrawn Batch Implementation
The current amendment replaces the original Batch version after researchers identified a critical signature-validation flaw in February. The vulnerability could have allowed unauthorized inner transactions to execute on behalf of other accounts, but the affected amendment had not activated on mainnet, so no user funds were exposed. XRPL developers subsequently disabled the earlier implementation and rebuilt the feature before shipping Batch V1.1 in rippled 3.3.0 on August 6.
The replacement underwent additional security work before returning to validator voting. RippleX engineer Mayukha Vadari said the review process included four senior reviewers, a Sherlock attackathon and audits by Halborn and Common Prefix. Reporting on that review identified 11 additional issues involving signature handling, authorization checks and conditions capable of causing server instability, which developers addressed before the current voting cycle.
Batch V1.1 is therefore not active yet despite already being included in supported XRPL software. The immediate milestone is maintaining at least 28 supporting validators through September 29 at 14:06:41 UTC. If the majority survives the full window, the amendment will become part of XRPL’s enabled transaction rules; only after that point will real mainnet usage provide evidence of how developers apply its four batching modes to swaps, payments and coordinated settlement workflows.
