The XRP Ledger Batch upgrade has slipped to October 9 after validator support was reset.

XRP Ledger upgrades must keep support from more than 80% of trusted validators for two consecutive weeks before activation. That rule is now affecting two changes: the Batch upgrade and PermissionDelegationV1_1. Both are countdown-based changes, and the validator support test can erase previously accumulated time if backing falls below the threshold.

The test is continuous, not a one-time approval

Validators are operators that check transactions and vote on network changes. For an upgrade to activate, it does not need only a majority at one moment. It needs more than 80% of trusted validators to keep supporting it for two consecutive weeks. If support slips, the accumulated countdown time is wiped out. A quick return of votes does not preserve the lost progress.

For readers, the important point is that activation depends on sustained consensus. A change can be technically ready and still fail to activate if validator support is unstable. The process treats the two-week window as a stability requirement, not merely a waiting period.

Batch enters a second attempt with a new countdown

The Batch upgrade had been counting down since September 15. It is already a second attempt to introduce the feature, after developers withdrew the original version over a critical signature-checking flaw before activation. The corrected implementation shipped in August with version 3.3.0 of the software that runs the ledger.

That history matters because the new countdown is not only about code availability. The revised version must keep validator support above the required level. If support is lost, the time already accumulated does not carry forward, even if validators later vote in favor again. The Batch case shows that a fixed flaw can still lead to another delay if the network does not maintain a stable level of backing.

PermissionDelegationV1_1 separates tasks from fund control

A separate upgrade, PermissionDelegationV1_1, would allow account owners to delegate specific tasks without sharing the signing keys that control their funds. In practical terms, a business could authorize another account to perform approved actions while keeping control of its assets. A token issuer could assign payment and compliance duties to different operational accounts.

This design is aimed at operational delegation rather than asset transfer. The key question it addresses is how teams can divide work without exposing the keys that govern funds. For account owners, the upgrade would make it possible to distribute responsibilities among separate accounts while keeping signing authority in the original control structure.

A one-day support lapse moves the earliest activation date

PermissionDelegationV1_1 lost its qualifying support on September 23 and regained it a day later. The interruption moved its earliest activation from October 5 to October 8 around 21:25 Coordinated Universal Time.

The date shift is small, but the rule behind it is not. Because losing support wipes out accumulated time, a brief lapse can reset the countdown even when validators quickly return to the required level. The upgrade now needs a continuous two-week window of more than 80% support from trusted validators to activate.

What the two cases show

Both Batch and PermissionDelegationV1_1 illustrate the same requirement: the XRP Ledger’s upgrade process rewards sustained validator backing, not a single favorable vote. For Batch, the corrected version still has to survive the support window after an earlier withdrawal. For PermissionDelegationV1_1, a delegation feature with clear operational uses still needs to hold the threshold.

The next signal for readers is whether each upgrade can maintain support from more than 80% of trusted validators for two consecutive weeks. If it does, the countdown can move forward. If it does not, the accumulated time resets again, and the activation date moves.