$XRP Ledger Batch upgrade closes in on 80% support
Batch V1.1 would allow as many as eight transactions to be grouped into a single operation, with execution rules that can require linked transactions to succeed together.
For a token swap between two users, the feature could make both transfers dependent on each other. If one side of the exchange fails, the other transaction would not be completed independently.
Wallets and marketplaces could use the same structure to process a customer payment and a platform fee together. RippleX said commercial projects using Batch are already under contract or development, though the developer team has not publicly identified the companies involved.
Validator support has risen quickly over the past week. On Sept. 8, Batch V1.1 had 24 votes from the 35 validators on the default Unique Node List, equal to 68.57%, crypto.news previously reported. Three more validators have since backed the amendment.
Under $XRP Ledger governance rules, an amendment must maintain at least 80% validator support for 14 consecutive days before it can activate. With 35 trusted validators currently counted, another supporting vote would take Batch V1.1 above the threshold and begin that period.
The outcome would not be locked in once the countdown starts. Validators can change their positions, and support falling below 80% during the 14-day window would interrupt the activation process.
A similar process played out in July when the fixCleanup3_2_0 amendment secured 85.71% support and entered its activation window. The package subsequently activated on July 29 after retaining enough validator backing for the required period.
Batch V1.1 replaces an earlier version with a serious flaw
The current vote follows the withdrawal of the original Batch design after researchers found a vulnerability before the feature reached the $XRP Ledger mainnet.
Under certain conditions, the flaw could have allowed an attacker to place transactions from another user’s account inside a batch without obtaining the required authorization. No user funds were put at risk because the affected amendment never activated.
Developers rebuilt the feature following the discovery, with Batch V1.1 later included in xrpld 3.3.0, released on Aug. 6.
The xrpld 3.3.0 release introduced the corrected Batch implementation alongside several other proposed protocol features. Each amendment still requires separate validator approval before becoming active on the mainnet.
RippleX software engineer Mayukha Vadari said the original signature problem was found in February before mainnet deployment. The subsequent work included a root-cause fix, reviews by four senior engineers, a Sherlock security contest and audits from Halborn and Common Prefix.
“After the v1.0 signature bug was caught in February (pre-Mainnet, no funds at risk), we rebuilt it,” Vadari wrote on X on Sept. 14.
The review process did not end with the initial vulnerability. RippleX said another 11 issues were found while the replacement implementation was being examined.
The Batch V1.1 amendment shipped in xrpld 3.3.0 and is now up for voting.
After the v1.0 signature bug was caught in February (pre-Mainnet, no funds at risk), we rebuilt it: root-cause fix, 4 senior reviewers, a Sherlock attackathon, and audits from Halborn and Common Prefix. We…
— Mayukha Vadari (@msvadari) September 14, 2026
Security reviews found 11 more Batch issues
The additional findings covered signature handling, authorization checks and software conditions capable of crashing servers.
Common Prefix classified one of the vulnerabilities as critical. According to RippleX’s review, the issue could have allowed an attacker to reuse permission that a user had signed and carry out more transactions than the user originally intended to authorize.
Other findings involved the way Batch transactions verified permissions and processed signatures. Developers addressed the reported problems before the amendment reached its current stage of validator voting.
RippleX said four senior engineers reviewed the implementation, while Halborn and Common Prefix performed outside audits. The code went through automated testing and a public security contest designed to expose weaknesses before activation.
Security testing has been used across other recent $XRP Ledger proposals. A June Common Prefix security review identified numerical and behavioral issues in XRPL components, with fixes deployed through version 3.2.0. The security firm was subsequently tasked with formal verification and analysis of other parts of the network.
A separate Sherlock contest covering proposed $XRP Ledger features found dozens of valid vulnerabilities before the affected amendments reached mainnet, including critical and high-severity findings.
Batch forms part of the xrpld 3.3.0 feature set
Batch is one of several protocol changes introduced through the 3.3.0 software cycle as $XRP Ledger developers work on transaction settlement, privacy, permissions and institutional features.
Before the software was released, developers outlined five proposed XRPL amendments that included Batch transactions, Confidential MPT, Sponsor, Dynamic MPT and Permission Delegation.
Batch is designed around atomic settlement, where multiple related operations can be handled as a coordinated transaction instead of being submitted separately.
Permission Delegation would allow an account to grant restricted authority to another account without handing over full control. Confidential MPT is designed to conceal balances and transfer amounts for Multi-Purpose Tokens while keeping account identities visible on the public ledger.
None of the features becomes active simply because its code is included in xrpld. Validators separately decide whether to support amendments, leaving each proposal on its own voting schedule.
The network has already seen different adoption rates across the 3.3.0 proposals. Ripple voted in August for the PermissionDelegationV1_1 amendment when it had support from seven of the 35 trusted validators.
Batch has since moved much closer to the activation threshold. Its current 27 votes leave the amendment one supporting validator away from starting the 14-day period, provided the existing votes remain in place.
RippleX has not named the commercial projects it said are under contract or development to use Batch. CoinDesk said it asked the developer team which companies are preparing to use the feature and whether the 11 latest fixes received independent review against the version currently being considered by validators.
