The XRP Ledger’s BatchV1_1 amendment is moving closer to activation, but validator support remains below the threshold required to start the network’s two-week activation countdown.
As of September 8, BatchV1_1 had received 24 votes from 35 validators, representing 68.57% support on the XRPL mainnet. Under the current validator configuration, the amendment needs at least 29 affirmative votes to exceed the required 80% threshold.
Until that level is reached and maintained continuously for 14 days, no activation countdown has begun.
Key Takeaways
- BatchV1_1 currently has 24 of 35 validator votes, or 68.57% support.
- At least 29 votes are currently needed to exceed 80% support.
- The amendment must remain above the threshold for 14 consecutive days before activation.
- BatchV1_1 would allow up to eight operations to be bundled into a single batch transaction.
- The new amendment replaces an earlier Batch implementation that was disabled after a critical authorization vulnerability was discovered.
- A September activation remains possible, but there is currently no confirmed activation date.
XRPL Batch Vote Has Yet to Reach the Activation Threshold
The XRP Ledger uses a validator-based amendment process in which proposed protocol changes require sustained support before they can become active.
BatchV1_1 has currently secured 24 affirmative votes out of the 35 validators on the default Unique Node List, according to the supplied XRPScan data. That puts support at 68.57%, well below the more-than-80% requirement.
With 35 validators participating, at least 29 validators would need to vote in favor for the amendment to clear the current threshold.
Even if BatchV1_1 reaches the required level, activation would not happen immediately.
The amendment must maintain more than 80% support for two uninterrupted weeks. If support falls below the threshold during that period, the activation timer resets.
Consequently, reports predicting a September launch should be treated cautiously. A September activation is mathematically possible only if the amendment gains sufficient support soon enough and maintains that support for the entire 14-day period.
Validator participation can also change over time, meaning the precise number of affirmative votes needed could shift if the validator set changes.
What BatchV1_1 Would Bring to the XRP Ledger
If approved, BatchV1_1 would introduce a new way of grouping multiple operations into a coordinated transaction structure.
According to the supplied XRPL documentation, a batch can contain up to eight inner transactions. An outer transaction manages elements such as sequencing, fees and authorization, while the individual operations remain separately identifiable.
The feature would provide four execution modes:
- All or Nothing: Every transaction in the batch must succeed.
- Only One: The first successful operation is applied.
- Until Failure: Operations continue until one of them fails.
- Independent: Each included transaction is attempted regardless of whether another operation succeeds or fails.
This functionality could be useful for applications that currently need to coordinate several dependent transactions separately.
Potential applications include atomic token swaps, NFT-related transactions, bundled platform fees and coordinated activity involving multiple accounts.
For transactions involving several accounts, each participating account would need to authorize the complete batch.
Batch Could Simplify Complex On-Chain Workflows
Bundling several operations together could reduce the amount of external coordination required by applications built on the XRP Ledger.
For example, a decentralized application could potentially combine multiple related actions into a single coordinated transaction rather than requiring users or application infrastructure to manage each step independently.
The individual committed operations would still retain their own metadata and a reference to the parent batch, allowing the underlying actions to remain distinguishable within the ledger.
However, the functionality will only become available on mainnet if validators approve the amendment and the activation process successfully completes.
The release of compatible software therefore does not automatically activate BatchV1_1.
New Batch Version Replaces Vulnerable Implementation
BatchV1_1 exists because an earlier version of the Batch amendment was withdrawn after developers discovered a serious authorization vulnerability.
XRPL version 3.3.0, released on August 6, introduced the corrected BatchV1_1 implementation.
The original Batch code had been disabled earlier after researchers identified an error in the logic used to verify batch signers.
According to the supplied report, Pranamya Keshkamat and Cantina AI’s Apex security tool identified the problem. The vulnerability could potentially have allowed an attacker to bypass certain participant checks and submit unauthorized transactions involving a victim’s account.
The discovery prompted developers to prevent the vulnerable amendment from becoming active.
Importantly, the supplied material states that the original vulnerable Batch amendment never activated on XRPL mainnet, meaning user funds were not exposed through an active deployment of the flawed functionality.
Validators were instructed to vote against the original amendment, while the relevant rippled software marked the initial Batch implementation and its associated fix as unsupported.
Security Improvements Built Into BatchV1_1
The replacement implementation was designed to address the authorization weaknesses found in the earlier version.
The corrected code removes the problematic early-exit behavior, introduces additional authorization protections and changes how individual signer permissions are evaluated.
The replacement was also subjected to an independent security review before release.
This development highlights the importance of the XRPL amendment process: shipping code to node operators is only one part of deploying a major protocol feature. The software must also undergo testing, security review and validator approval before it can affect the live network.
Node Operators Must Prepare Before Voting
Validators and other node operators need to run software that supports BatchV1_1 before participating effectively in the amendment vote.
Infrastructure operators also have preparation requirements. The supplied material notes that Clio operators were advised to upgrade to version 2.8.0 so their API infrastructure can handle the new transaction and ledger formats if BatchV1_1 eventually activates.
This makes ecosystem readiness another important component of the rollout.
Exchanges, wallets, API providers, developers and other XRPL infrastructure may need to ensure compatibility before the amendment reaches the activation stage.
The Next Major Milestone Is 80% Support
For now, the most important number for BatchV1_1 is 80%.
The amendment currently sits at 68.57%, leaving a gap of roughly 11 percentage points and requiring at least five additional affirmative votes under the current 35-validator configuration.
Only after support rises above the threshold will the 14-day activation period begin.
A late-September activation therefore remains possible in theory, but it is not scheduled or guaranteed. The timeline depends first on securing enough validator votes and then maintaining that support without interruption.
XRP Price Impact Remains Unclear
The BatchV1_1 vote changes the XRP Ledger’s transaction capabilities, rather than XRP’s supply or issuance structure.
As a result, there is no verified basis in the supplied material for attributing a specific XRP price movement to the amendment vote.
For the XRPL ecosystem, however, the upgrade could represent a meaningful improvement in how applications coordinate multiple operations—provided validators ultimately approve it.
For now, the key question is not whether BatchV1_1 is technically ready, but whether it can gather enough validator support to cross the 80% threshold and keep it there for 14 consecutive days.
