The XRP Ledger (XRPL) is one validator vote away from starting the activation process for Batch V1.1, a payments upgrade that lets users group several related transactions into a single operation.
As of September 15, Batch V1.1 had support from 27 of 35 trusted validators, or roughly 77%. XRPL amendments need at least 80% support, which means one additional validator vote would push the proposal over the threshold and start a two-week activation period.
The upgrade is also moving forward after RippleX developers addressed 11 additional software issues discovered during review, including bugs related to signatures, authorization checks, and server stability.
Batch V1.1 Is One Vote From the Activation Threshold
Batch V1.1 lets applications group up to eight transactions into one batch.
The most important feature is that related actions can depend on each other. For example, two sides of a token swap could be executed together instead of allowing one transfer to complete while the other fails.
The amendment currently has 27 supporting validators out of the 35 tracked in the trusted set. With 28 votes, support would reach the 80% threshold required to begin the activation process.
Notably, crossing 80% does not make the feature active immediately. Support must remain at or above the required level for two consecutive weeks.
Validators can also change their votes during that period, meaning the countdown can be interrupted if approval falls back below the threshold.
| Batch V1.1 Metric | Current Status |
| Supporting validators | 27 of 35 |
| Current support | ~77% |
| Threshold to begin activation | 80% |
| Votes needed to reach threshold | 1 |
| Required support period | 14 days |
| Transactions per batch | Up to 8 |
Table 1. XRP Ledger Batch V1.1 Voting Status
Developers Fixed 11 More Bugs Before Activation
The voting milestone comes after another round of security work on Batch V1.1. RippleX said the latest review uncovered and addressed 11 additional issues.
The problems included signature handling, authorization checks, and conditions that could crash servers.
Security firm Common Prefix identified an issue considered severe because it could have allowed signing permissions to be reused in ways beyond what a user originally intended.
That matters because batching introduces more complex transaction relationships than a normal single XRPL payment.
According to the development review, Batch V1.1 has undergone multiple layers of scrutiny, including reviews by senior engineers, audits by Halborn and Common Prefix, automated testing, and a public security competition.
The First Batch Version Never Reached Mainnet
Batch V1.1 replaces an earlier version that was withdrawn after researchers discovered a security vulnerability.
The original Batch implementation contained a signature-related flaw that under specific conditions could have allowed unauthorized transactions to be initiated from another account. That vulnerable amendment never activated on XRPL mainnet, so users were not exposed to the issue on the live network.
Developers later rebuilt the feature and introduced Batch V1.1 with xrpld version 3.3.0 on August 6.
The newer implementation addresses the root cause of the earlier vulnerability while adding additional safeguards discovered through later audits and testing.
Why Batch Transactions Matter for Payments
The main benefit of Batch V1.1 is not simply fitting more transactions into one request. Its value comes from coordinating actions that need to happen together.
For example, a dApp could combine several dependent payment steps into one batch. Depending on the execution mode, the application could require all of those transactions to succeed together rather than leaving users with only part of a multi-step process completed.
That could be useful for workflows such as the following:
- Token swaps
- Multi-party payments
- NFT minting followed by listing
- Coordinated account actions
- Applications that require several ledger transactions to succeed as one process
The amendment therefore reduces some of the additional logic developers currently need to build around multi-step payments.
For users, the practical benefit is simpler execution. Instead of relying on an application to coordinate several separate off-ledger transactions, the ledger can enforce how the linked actions are processed.
Batch V1.1 Follows a Busy Period for XRPL Upgrades
Batch V1.1 is part of a larger group of protocol changes introduced with xrpld 3.3.0.
The release also included proposals such as ConfidentialTransfer, DynamicMPT, PermissionDelegationV1_1, and Sponsor. Those amendments cover areas such as private Multi-Purpose Token transfers, changing token properties, delegated permissions, and allowing third parties to cover account costs.
Batch V1.1 is currently the closest of those features to reaching the validator threshold.
It also follows the activation of maintenance amendments designed to improve areas including lending, vaults, automated market makers, and other advanced XRP Ledger functions.
XRPL developers are gradually adding infrastructure aimed at more complex financial and application use cases.
The Upgrade Comes After XRPL Sets a Transaction Record
The pending Batch vote also follows an unusual burst of XRP Ledger activity.
On September 14, XRPL reportedly processed 3,254 transactions in a single ledger, a new reported record.
Most of the transactions were very small XRP payments and may have been related to throughput testing rather than normal user activity.
The record and Batch V1.1 should not be treated as the same development.
The September 14 event showed how XRPL handled a large concentration of simple payments. Batch V1.1, by contrast, is designed to coordinate several related operations within a single transaction structure.
That difference is important because 3,254 simple XRP transfers do not create the same computational load as thousands of more complex transactions involving permissions, tokens, or multiple account changes.
What Comes Next
If support for Batch V1.1 reaches 28 of the 35 trusted validators, the proposal would cross the 80% threshold and begin its two-week activation period. Approval would then need to remain above the required level for the full 14 days before the amendment could become active.
The vote will also signal how validators view the additional security work completed after the earlier Batch implementation was withdrawn.
If the amendment activates, developers will gain a native way to coordinate up to eight related transactions, potentially simplifying payments, swaps, and other multi-step XRPL applications.
What this means for you: Batch V1.1 is close to activation, but the key point is not simply that XRPL can group transactions. The upgrade would move coordination of multi-step actions into the protocol itself, reducing the risk of applications completing only part of a linked payment process.
