TLDR
- BatchV1_1 has 24 of 35 validator votes, or 68.57% support, on the XRP Ledger mainnet.
- Activation needs support above 80% held for fourteen straight days, and that countdown has not begun.
- The upgrade would let users bundle up to eight transactions into one batch, with four execution modes.
- XRPL version 3.3.0 introduced BatchV1_1 in August after the original Batch code was pulled over a security flaw.
- The earlier flaw could have allowed unauthorized payments, but it never went live on the mainnet.
XRP Ledger validators are still voting on a proposed upgrade called BatchV1_1. As of September 8, the amendment had not reached the support level it needs to move forward.
Data from XRPScan shows 24 of 35 validators backing the change. That works out to 68.57% support on the network.
To activate, an amendment needs more than 80% approval, and that support has to hold steady for fourteen days in a row. Right now, that countdown has not started.
Under the current setup of 35 validators, BatchV1_1 needs at least five more votes to clear the 80% mark. If the group of validators changes, that number could shift too.
There is no confirmed date for activation. Even if support jumped past 80% today, the ledger would still need two full weeks of unbroken approval before the feature turns on.
Validator support can also drop. Node operators sometimes pull their votes if testing turns up problems with compatibility or security.
What BatchV1_1 Would Change
The upgrade would let a single outer transaction hold up to eight inner transactions. That outer transaction handles sequencing, fees, and authorization for the whole group.
Four modes would control how these bundles run. “All or nothing” requires every transaction inside to succeed. “Only one” runs just the first one that works. “Until failure” processes them in order and stops at the first failure. “Independent” runs every transaction no matter what happens to the others.
Possible uses include swapping tokens in one step, minting an NFT and listing it for sale together, or combining platform fees into a single action. For batches involving more than one account, every account involved has to approve the full set of transactions.
Why the Original Batch Code Was Pulled
XRPL version 3.3.0 launched BatchV1_1 on August 6 to replace an earlier version of the Batch feature. That original code had been disabled back in February.
Researchers Pranamya Keshkamat and Cantina AI’s Apex tool found a flaw in how the original version checked batch signers. The bug could have let an attacker skip authorization checks for some participants and move funds from another user’s account without permission.
XRPL Labs said the flawed version never activated on the mainnet, so no user funds were ever at risk. Validators were told to vote against it, and rippled version 3.1.1 marked the old code as unsupported.
The new version closes that gap, adds extra authorization checks, and tightens how each signer gets verified. It also went through an independent audit before release.
Node operators need software that supports BatchV1_1 before they can vote for it. XRPL has also told operators running Clio, the API layer used by many apps, to update to version 2.8.0 so it can handle the new transaction formats if the amendment goes live.
The next thing to watch is whether support crosses 80%. Only then does the two-week clock start. A late-September activation is still possible, but nothing is scheduled, and there is no reported link between this vote and any recent XRP price movement.
