XRP Ledger's Batch Upgrade Explained: Why It's Been Delayed Twice in 2026

Two unrelated upgrades to the XRP Ledger — called Batch and Permission Delegation — are both sitting in the final stretch of the network’s validator-approval process as of early October 2026, and both have already slipped past their first scheduled activation dates. Batch, the more consequential of the two, is on its second attempt after a security researcher found a critical flaw in the first version back in February. Here’s what each upgrade actually does, why they keep getting delayed, and what that says about how the XRP Ledger decides when a change is safe to ship.

What the Batch Amendment Actually Does

The Batch amendment, officially proposal XLS-56, lets up to eight individual transactions be bundled together and submitted as a single on-chain operation (dev.to/ripplexdev). Its key feature is an “AllOrNothing” execution mode that makes the whole bundle atomic: either every transaction inside it succeeds, or none of them do. Nothing gets left half-finished.

That matters for anything that currently requires several separate transactions to happen in the right order with no room for one of them failing midway — an atomic swap between two assets, a conditional token mint that should only happen if a payment clears, or an exchange attaching its service fee directly to a customer’s transaction instead of sending it as a second, independent transfer. Today, if the second step of a multi-step process on the XRP Ledger fails, the first step has already happened and can’t be undone. Batch is designed to remove that risk entirely for anything bundled inside it.

The Security Flaw That Paused the First Version

Batch almost shipped once already, and it’s a good example of why XRP Ledger’s process is slower and more conservative than it might look from the outside. On February 19, 2026, security researcher Pranamya Keshkamat, working with Cantina AI’s autonomous auditing tool Apex, identified a critical flaw in the original Batch amendment’s signature-validation logic while it was still going through validator voting — before it had ever activated on the live network (CryptoSlate).

The bug was serious: it could have let an attacker execute an “inner” transaction inside a batch as though it had been authorized by a completely different account, without ever needing that account’s private keys. In practice, that could have meant unauthorized fund transfers or ledger-setting changes made on someone else’s account, with no stolen seed phrase or compromised key involved at all. Ripple shipped an emergency software release, rippled 3.1.1, on February 23, 2026, and the original amendment was paused before it could reach mainnet.

Developers then rebuilt the feature from the ground up as a corrected replacement, BatchV1_1, which is the version now working its way back through validator voting.

Why BatchV1_1 Slipped From September 29 to October 9

BatchV1_1’s second attempt also hit a snag — though a much more mundane one than a security flaw. By September 20, 2026, 30 of the network’s 35 trusted validators (about 86%) were backing the amendment, comfortably clearing the 80% support level needed to start XRP Ledger’s mandatory 14-day activation countdown, which was on track to complete at 14:06 UTC on September 29, 2026.

Support then dipped below 80% before that 14-day window finished. Under XRP Ledger’s rules, that’s not a pause — it’s a full reset. The countdown goes back to zero the moment support drops below the threshold, even briefly, and has to build back up from scratch. Validators crossed 80% support again on September 25, 2026 (back to 30 of 35), which restarted the 14-day clock and put BatchV1_1’s new earliest possible activation at roughly October 9, 2026, around 14:46 UTC — assuming support holds for the full two weeks this time (CoinDesk).

How XRP Ledger’s Amendment Voting Actually Works

This all comes down to a deliberately slow, consensus-driven system that XRP Ledger uses for every protocol change, not just Batch. Changes to the network ship as “amendments” bundled into new releases of the validator software (rippled). Each validator operator decides whether to support or oppose a given amendment through their own server configuration, and that support is tallied continuously as the network’s validators do their normal job of agreeing on each new ledger (Ripple).

An amendment only starts its activation countdown once more than 80% of the network’s trusted validators are voting yes for it. From that point, it needs to hold that 80%+ support for 14 consecutive days before it automatically activates and becomes a permanent part of the ledger’s rules. If support ever drops to 80% or below during that window — for any reason, even temporarily — the amendment is rejected and the 14-day clock resets entirely. It has to re-earn majority support from scratch before trying again.

The design is intentional: it gives the community and validator operators a real window to flag problems, change their vote, or simply wait and watch before a change becomes permanent and irreversible. It’s slow by the standards of most software, but it’s also exactly the kind of process that catches something like the original Batch flaw before it can do damage on the live network rather than after.

Permission Delegation: A Second Amendment Going Through the Same Gauntlet

While Batch works through its second attempt, an unrelated amendment called Permission Delegation (proposal XLS-75) is going through the identical validator-vote process just a day or two ahead of it. Permission Delegation, shipped as part of the xrpld 3.3.0 software release, lets an account delegate a specific, limited set of transaction permissions to another account — without ever handing over that account’s master key (cryptoticker.io).

That’s aimed squarely at custodians and payment services: a business can let an operational account handle routine, limited tasks on its behalf while keeping full custody and ultimate control locked to the primary account. Permission Delegation is approved by 29 of the network’s 35 trusted validators. Its support only crossed the 80% line on September 24, 2026, which — following the same 14-day rule as Batch — pushed its earliest possible activation to around October 8, 2026, at approximately 21:25 UTC. Some earlier coverage had cited an October 5 activation date, which turned out to be based on when support for the amendment first appeared rather than when it reliably crossed and held the 80% threshold.

Batch vs. Permission Delegation at a Glance

	Batch (XLS-56 / BatchV1_1)	Permission Delegation (XLS-75)
What it changes	Bundles up to 8 transactions into one atomic, all-or-nothing on-chain operation	Lets an account delegate specific transaction rights to another account without sharing its master key
Who benefits most	Exchanges, wallets, and apps doing atomic swaps or bundled fee payments	Custodians and payment services delegating limited operational authority
Validator support (early Oct. 2026)	30 of 35 trusted validators	29 of 35 trusted validators
80% threshold last crossed	Sept. 25, 2026 (reset once already after dipping below 80%)	Sept. 24, 2026
Earliest possible activation	~Oct. 9, 2026, 14:46 UTC	~Oct. 8, 2026, 21:25 UTC
Prior setback	Original version paused in Feb. 2026 after a critical security flaw was found pre-mainnet	None reported

Does Any of This Affect Regular XRP Holders?

Not directly, and neither amendment requires you to do anything. Both are protocol-level changes to how transactions get built and processed on the XRP Ledger — they don’t touch how your XRP, your wallet software, or your private keys work, the same way a software update to a payment network’s back-end doesn’t change how your existing debit card works. If you hold XRP on an exchange or through a custodian, that platform is responsible for adopting these features if and when it chooses to; you won’t need to upgrade anything yourself.

What this episode is actually useful for is understanding how much friction is built into XRP Ledger’s process on purpose. Two amendments, one of which already caused a real security scare, both got held to the same strict bar — and one of them got bounced back to square one over a validator dip that lasted less than a day. That’s arguably the system working as intended, even if it’s frustrating for anyone waiting on a specific feature date. As always, none of this is a signal about XRP’s price one way or the other — upgrade timelines and token prices are separate things, and this is not financial advice.

If you want another recent example of a major blockchain catching a problem before it reached production, our explainer on Ethereum’s Glamsterdam upgrade covers a similar last-minute security warning ahead of a different network’s testnet activation. And for more on how exploits that don’t involve a stolen private key keep showing up as 2026’s biggest crypto security stories, see our roundup of September 2026’s $768 million in crypto hacks.