XRP Ledger's BatchV1_1 Amendment Stalls at 68.57% Validator Support
Key Takeaways
- •BatchV1_1 held 68.57% validator support (24 of 35 votes) as of September 8, 2026, below the required supermajority of more than 80%.
- •Activation requires sustained above-80% support for 14 consecutive days, and the countdown has not begun because the threshold has not been crossed.
- •If activated, a Batch transaction could bundle up to eight inner transactions in one outer transaction with four execution modes, including "All or nothing" and "Independent".
- •BatchV1_1 is a rewritten replacement for the original Batch amendment, which was disabled in February 2026 after a critical batch-signer verification flaw was identified, though the vulnerable version never reached mainnet.
- •The amendment changes ledger transaction functionality rather than XRP supply rules, so it is currently an infrastructure story rather than a confirmed price catalyst.

On September 8, 2026, XRP Ledger validators held the BatchV1_1 amendment at 24 of 35 votes, equal to 68.57% support, leaving it well short of the more-than-80% supermajority required to begin its two-week activation window. Although BatchV1_1 ships inside the rippled software, that does not mean it is live on the XRP Ledger, and the DeFi and functionality gains often attached to the upgrade remain unconfirmed until validators clear that bar.
The XRP Ledger's Batch amendment is now at 68% support. We could see Batch going live by the end of this month. Batch will unlock a lot of new use cases for the XRP ecosystem. You can track progress here pic.twitter.com/uoo2Q5kf0X — moonkie (@xmoonkie), September 7, 2026
BatchV1_1 remains below the activation threshold
BatchV1_1 arrived inside rippled 3.3.0, released August 6, 2026, but code inclusion and mainnet activation are separate events on the XRP Ledger. Unlike networks that deploy protocol changes through hard forks or off-chain governance votes, XRPL changes go live automatically through validator consensus: once an amendment holds majority support for the required period, it activates on every server running compatible software, with no coordinated chain split. As of the September 8 snapshot, the amendment sat at 68.57% support among the default Unique Node List, according to XRPScan data.
Activation requires more than 80% approval sustained for 14 consecutive days, and that countdown has not started. Under the current 35-validator configuration, at least 29 affirmative votes are needed to clear the threshold, though the exact number can shift if the participating validator set changes. Support can also fall back below 80% mid-countdown, which resets the timer entirely.
Version 3.3.0 was not a single-feature release – it also introduced ConfidentialTransfer, DynamicMPT, Sponsor and PermissionDelegationV1_1, bundling BatchV1_1 into a broader package of institutional-facing upgrades. Investors tracking XRP Ledger growth and ETF-driven inflows should treat these amendments as parallel storylines, each requiring its own validator supermajority before any functionality goes live.
What Batch transactions could enable if activated
Once live, a Batch transaction could bundle up to eight inner transactions inside a single outer transaction, with four execution modes: "All or nothing," which requires every inner transaction to succeed; "Only one," which applies the first successful operation; "until failure," which processes transactions until one fails; and "Independent," which attempts every included transaction regardless of outcome.
Potential use cases include atomic token swaps, NFT minting paired with an offer, bundled platform fees, and coordinated actions spanning multiple accounts – provided every participating account authorizes the full collection. Each committed inner transaction would retain its own metadata plus a reference back to its parent batch, a structure aimed at cutting the external coordination infrastructure that applications currently need for multi-step actions.
These remain designed capabilities rather than live outcomes. The efficiency gains (and any resulting boost to activity around use cases like RLUSD settlement and tokenized-finance flows on XRPL) depend on both validator activation and subsequent wallet and SDK support.
Security history behind the replacement amendment
BatchV1_1 is not the original Batch code: it is a rewrite. Developers disabled the original amendment in February 2026 after Pranamya Keshkamat and Cantina AI's Apex security tool identified a critical flaw in batch-signer verification logic. The bug could have let an attacker skip authorization checks for some participants and submit unauthorized transactions from a victim's account.
Critically, the vulnerable version never activated on mainnet, and XRPL Labs said no user funds were placed at risk. Rippled 3.1.1 marked the original Batch amendment as unsupported, and its replacement removes the early-exit error, adds authorization safeguards, and narrows signer checks, with an independent audit reviewing BatchV1_1 before its inclusion in 3.3.0.
Why this is not yet an XRP price catalyst
This news did not produce a notable price movement, and that is unlikely to change while support sits at 68.57%. The amendment alters transaction functionality on the ledger, not XRP's supply or issuance rules, so it carries no direct monetary-policy angle for traders pricing XRP's near-term breakout potential.
Any uplift in XRPL transaction volume, DeFi activity or token demand tied to Batch remains forward-looking, contingent on activation clearing the supermajority and then on wallets, exchanges and DeFi protocols actually integrating the feature. Until then, Batch functions as an infrastructure story rather than a confirmed valuation catalyst.
The next milestone is a sustained validator supermajority
The next confirmed checkpoint for XRPL validators is crossing 80% support. Only after that happens does the ledger begin recording the mandatory 14-day continuous majority period. Support must hold above the threshold for the full stretch, or the clock resets to zero.
A late-September activation was mathematically possible as of the September 8 snapshot, but nothing is scheduled. Node operators must first run software supporting BatchV1_1 before they can vote for it, and XRPL separately warned Clio operators to upgrade to version 2.8.0 so API infrastructure can process new transaction and ledger formats if the amendment does activate.
Source: https://icobench.com/news/xrp-news-batchv1-1-xrp-ledger-vote/