XRP Ledger’s Batch Feature Moves Toward Mainnet
The XRP Ledger is approaching a new transaction-batching capability designed to make complex, multi-party operations easier to execute as a single atomic action.
Known as Batch V1.1, the amendment is a revised version of the original Batch feature. It allows multiple XRP Ledger transactions from different accounts to be grouped together so they can execute atomically within one ledger close. If an inner transaction fails under the feature’s all-or-nothing mode, the entire batch is reverted.
As of a September 14 snapshot, 27 of 35 trusted validators were supporting Batch V1.1, or about 77%. However, there is an important governance detail: the XRP Ledger’s official amendment rules require more than 80% support for two continuous weeks. With 35 validators, that means 29 votes are needed to exceed 80%, not 28. Therefore, the current 27/35 position is two validator votes short of the required threshold.
How Batch V1.1 Could Improve XRPL Transactions
The core idea behind Batch is straightforward: instead of treating several related transactions as separate operations, developers can make them part of one coordinated transaction package.
For example, an atomic swap could require one party to send one asset while another party sends a different asset. With batching, both actions can be structured so they either complete together or do not complete at all. RippleX says the feature can also support coordinated settlements and other workflows where multiple participants need to move in lockstep.
The feature could also be useful for wallets, decentralized exchanges and marketplaces. RippleX says these applications can bundle a base transaction, such as a payment, with a platform fee. That can allow the payment and associated fee to be processed as one atomic operation rather than relying on separate transactions.
Security Problems Delayed the Original Batch Feature
The road to Batch V1.1 has been shaped by a serious security issue discovered earlier in 2026.
On February 19, 2026, security researchers Pranamya Keshkamat and Cantina AI identified a critical flaw in the signature-validation logic of the original Batch amendment. The problem involved the checkBatchSign function, which could stop validating additional signers after encountering a particular type of account that did not yet exist on the ledger.
Had the vulnerable amendment reached the XRP Ledger mainnet, the flaw could have allowed an attacker to execute inner transactions on behalf of victim accounts without possessing their private keys. The amendment was still in its voting stage when the vulnerability was discovered, so no funds were at risk. Validators were advised to vote against the amendment, and rippled 3.1.1 subsequently prevented the affected version from being activated.
Batch V1.1 Underwent Additional Security Testing
Batch V1.1 was developed as a replacement rather than simply reactivating the original implementation. The revised version is included in xrpld v3.3.0, with the early-return vulnerability fixed and additional safeguards added.
RippleX said the new version went through code review by four senior engineers, a Sherlock Batch Attackathon, a Halborn re-assessment, a Common Prefix audit, automated analysis that included a Cantina scan, and QA testing on Devnet and testnet.
The review also uncovered and addressed 11 additional issues. They included problems involving MPT validation, signature verification, path-size validation, batch signer ordering, authorization checks and potential node crashes. The changes were intended to strengthen the implementation beyond simply correcting the original signature-validation flaw.
Why Validator Voting Matters
XRPL amendments are activated through the network’s validator-based governance process. According to the official XRP Ledger amendment documentation, a transaction-processing amendment must maintain more than 80% support for two weeks before it becomes enabled.
Validators can change their votes during that period. If support falls to 80% or below, the activation timer resets. This means reaching the required level is only the beginning of the process; sustained support is necessary before Batch V1.1 can become permanently active on the network.
The current XRPL amendment tracker lists BatchV1_1 at 27/35 yes votes, showing that the proposal has significant support but has not yet reached the activation threshold.
What the Upgrade Could Mean for XRPL Developers
Batch V1.1 could give developers a native way to coordinate multiple transactions without depending on separate execution steps. RippleX describes the capability as useful for atomic swaps, institutional settlements, custody transfers, delivery-versus-payment settlement and cross-border payment finalization.
For users, the main benefit is less about seeing a new transaction type and more about reducing the risk of partial execution in applications that involve several parties or actions. Instead of one step succeeding while another fails, an atomic batch can make the complete operation behave as a single unit.
RippleX also says Batch is already relevant to projects in its ecosystem, with use cases under contract or in development. The company has not publicly named all of those projects, so the specific commercial deployments should not be assumed until they are disclosed.
A More Carefully Reviewed Path to Activation
The Batch V1.1 vote represents a second attempt to bring transaction batching to the XRP Ledger after the original implementation was stopped before mainnet activation.
The current version combines the original goal—coordinating multiple XRPL transactions atomically—with a substantially expanded security-review process. But the upgrade is not activated yet. At the latest reported snapshot, it had 27 of 35 trusted validators supporting it, while the official XRPL rules require more than 80% support to begin the two-week activation period.
If the amendment reaches the required support and maintains it for the full voting period, Batch could become an important piece of infrastructure for XRPL applications that need several transactions to succeed together. Until then, the validator vote remains the key milestone to watch.
