XRP Ledger validators are approaching the possibility of approving BatchV1_1. However, voting data from September 8 indicated that the amendment had not yet reached the necessary threshold for initiating its two-week activation period.
Summary
- Currently, BatchV1_1 has received votes from 24 out of 35 validators, reflecting a support level of 68.57% on the XRPL mainnet.
- For activation, more than 80% backing is required consistently over a span of fourteen days, with no countdown initiated yet.
- Once active, batch transactions will allow up to eight operations and support four different execution modes.
- BatchV1_1 was introduced in XRPL version 3.3.0, following the disabling of the original Batch code due to a security issue.
- The earlier vulnerability had the potential to enable unauthorized payments, but that flawed amendment never went live on the XRPL mainnet.
As per XRPScan, BatchV1_1 is supported by 24 out of 35 validators, translating to 68.57%. At least 29 affirmative votes are needed to surpass the 80% threshold given the current validator count.
The amendment aims to enable accounts to consolidate up to eight transactions into a single comprehensive operation. Nonetheless, assertions regarding its activation in September are speculative, as the required majority has yet to be attained.
A September activation will only be feasible if the support exceeds 80% and maintains that level for two consecutive weeks.
Countdown for XRP Ledger Batch vote has yet to commence
XRPL amendments can only be activated when they secure over 80% support from trusted validators for a continuous fortnight. If the support dips below this threshold during this period, the countdown resets.
Thus, BatchV1_1 requires at least five additional affirmative votes in the current 35-validator setup. Changes in the validator pool could affect the exact number needed.
No confirmed activation date exists for this amendment. Even if the threshold is met immediately, activation cannot proceed until the two-week continuous period has elapsed.
Votes from validators can also change, as operators may withdraw support if testing reveals compatibility, security, or operational issues.
BatchV1_1 enables the combination of eight transactions
According to the official XRPL documentation, Batch transactions can encapsulate up to eight individual operations. These operations are included in a larger outer transaction that governs sequencing, fees, and authorization.
There would be four available execution modes. The “All or nothing” mode requires all inner transactions to succeed, while the “Only one” mode applies the first successful operation. The “Until failure” mode processes transactions until one fails, and the “Independent” mode attempts every included transaction regardless of the results of others.
Use cases may involve atomic token swaps, minting NFTs followed by an offer, package platform fees, and coordinated initiatives involving multiple accounts. For multi-account batches, every participating account must approve the entire set of transactions.
This feature could streamline external mechanisms that applications require to coordinate dependent actions. Each committed inner transaction would retain unique metadata alongside a reference to its parent batch.
As reported by crypto.news at the time of version 3.3.0’s release, the deployment of this code did not activate the feature; validator approval remains essential.
Revised amendment replaces compromised Batch code
BatchV1_1 was introduced in XRPL version 3.3.0 on August 6 to replace the earlier Batch amendment, which had been disabled in February after a critical authorization flaw was discovered.
This issue was identified by Pranamya Keshkamat and Cantina AI’s Apex security tool, revealing a logic error in the verification of batch signers. This flaw could have enabled an attacker to bypass checks for certain participants and execute unauthorized transactions from another’s account.
XRPL Labs confirmed that the compromised amendment was never activated on the mainnet, and no user funds were at risk. Validators were encouraged to vote against it, while version 3.1.1 of Ripple marked the original Batch and its corresponding fix as unsupported.
The revised version rectifies the early-exit error, implements additional authorization safeguards, and narrows the conditions for each signer’s verification process. A separate audit was conducted on the replacement prior to its release.
Related coverage from crypto.news disclosed that the original flaw was detected before activation, and BatchV1_1 was rewritten for version 3.3.0.
Activation is contingent solely upon validators
Node operators must utilize software that supports BatchV1_1 to participate in voting. Furthermore, XRPL has advised Clio operators to upgrade to version 2.8.0 to ensure their API setup can handle the new transaction and ledger formats if the amendments are activated.
The next crucial goal is meeting the 80% validator threshold, as this marks the start of the two-week majority period.
While a late-September activation remains theoretically feasible, it is not officially scheduled. The precise timing hinges on additional validator votes and sustained support thereafter.
There has been no verified movement in the XRP price directly tied to the BatchV1_1 vote, as the amendment affects transaction capabilities rather than XRP’s supply or issuance parameters.