XRP Ledger validators are moving closer to approving BatchV1_1, but live voting data on Sept. 8 showed the amendment remained below the threshold needed to begin its two-week activation period. Summary BatchV1_1 currently has 24 of 35 validator votes, equal to 68.57% support on XRPL mainnet. Activation requires more than 80% support continuously for fourteen days, and no countdown has started. Batch transactions can contain up to eight operations and support four execution modes after activation. XRPL version 3.3.0 introduced BatchV1_1 after developers disabled the original Batch code over a vulnerability. Earlier flaw could have enabled unauthorized payments, but vulnerable amendment never activated on XRPL mainnet. BatchV1_1 had support from 24 of 35 validators on the default Unique Node List, equal to 68.57%, according to XRPScan. At least 29 affirmative votes would be required to exceed 80% with the current validator count. The amendment would let accounts bundle as many as eight transactions into one coordinated operation. However, reports suggesting it will activate in September remain speculative because the required majority has not been reached. A September activation is possible only if support first exceeds 80% and remains there continuously for fourteen days. XRP Ledger Batch vote has not started its countdown XRPL amendments activate only after holding support from more than 80% of trusted validators for two consecutive weeks. If support falls below that level during the period, the timer resets. BatchV1_1 therefore needs at least five additional affirmative votes under the current 35-validator configuration. Changes to the participating set could alter the exact number required. The amendment has no confirmed activation date. Even if it crossed the threshold immediately, it could not activate until the continuous two-week period ended. Validator votes can also change. Operators may withdraw support if testing uncovers compatibility, security or operational concerns. BatchV1_1 would combine eight transactions Official XRPL documentation says Batch transactions can contain up to eight inner transactions. The operations are packaged inside an outer transaction that manages sequencing, fees and authorization. Four execution modes would be available. “All or nothing” requires every inner transaction to succeed. “Only one” applies the first successful operation, while “until failure” processes transactions until one fails. “Independent” attempts every included transaction regardless of other results. Potential uses include atomic token swaps, NFT minting followed by an offer, bundled platform fees and coordinated actions involving several accounts. Multi-account batches require every participating account to authorize the full collection. The feature could reduce the external infrastructure applications need to coordinate dependent actions. Each committed inner transaction would retain separate metadata and a reference to its parent batch. As crypto.news reported when version 3.3.0 was released, shipping the code did not activate the feature. Validator approval remained necessary. Corrected amendment replaces vulnerable Batch code XRPL version 3.3.0 introduced BatchV1_1 on Aug. 6 as a replacement for the original Batch amendment. Developers disabled that earlier version in February after researchers found a critical authorization flaw. Pranamya Keshkamat and Cantina AI’s Apex security tool identified an error in the logic used to verify batch signers. The flaw could have allowed an attacker to skip checks for some participants and submit unauthorized transactions from a victim’s account. XRPL Labs said the vulnerable amendment had not activated on mainnet and no user funds were placed at risk. Validators were advised to vote against it, while rippled version 3.1.1 marked the original Batch and its companion fix as unsupported. The corrected version removes the early-exit error, adds authorization safeguards and narrows how each signer is checked. An independent audit later reviewed the replacement before its release. In related coverage of the security review, crypto.news reported that the original flaw was caught before activation and BatchV1_1 was rewritten for version 3.3.0. Activation depends entirely on validators Node operators must run software supporting BatchV1_1 before voting for it. XRPL also warned Clio operators to upgrade to version 2.8.0 so their API infrastructure can process the new transaction and ledger formats if amendments activate. The next confirmed milestone is the 80% validator threshold. Only then will the ledger record the beginning of the two-week majority period. A late-September activation remains mathematically possible, but it is not scheduled. The exact timing depends on additional validator votes and uninterrupted support afterward. No verified XRP price movement could be attributed specifically to the BatchV1_1 vote. The amendment changes transaction functionality rather than XRP’s supply or issuance rules.
