An XRP Ledger maintenance amendment is running on a new activation clock after losing the validator majority behind its earlier countdown. The fixCleanup3_4_0 amendment regained majority support on October 21, moving its earliest possible activation window to November 4, subject to that support continuing.

TL;DR: The amendment regained validator majority on October 21 after its first countdown failed. A fresh two-week window points to November 4 at the earliest, if support holds.

At the XRPL Dashboard’s October 24, 07:09 UTC snapshot, 32 of 35 trusted validators supported the amendment, or 91.43%. The tracker showed a new majority timestamp of October 21 at 14:46:22 UTC. Those figures are a dated observation; validators can change their positions.

XRPL Win’s amendment history separately records the earlier attempt beginning October 9 and losing majority on October 21. The interrupted run lasted more than 12 days. It did not satisfy the uninterrupted period required for activation, so the earlier October 23 expectation no longer applies.

The Clock Requires Continuous Support

The ledger’s official amendment documentation requires support from more than 80% of trusted validators for two weeks. If support falls below the requirement, the waiting period starts again when the amendment regains majority.

Network processing also means the end of the two-week period should not be treated as an exact appointment. Amendment decisions are handled through designated ledger checkpoints. November 4 is therefore a conditional earliest window, rather than a guaranteed switch at precisely 14:46 UTC.

This is a consensus process among validators on the blockchain. Holding XRP does not itself constitute an amendment vote. The visible count matters because it shows whether the required network support is being maintained throughout the waiting period.

A Collection Of Technical Fixes

The official amendment description groups fixes affecting vaults, lending, automated market makers, permissioned exchange functions, trust lines, NFTs and other ledger features. Examples include more precise vault rounding and changes to when a loan can be treated as in default.

Another change concerns delegated payment permissions. The documentation says an account with a delegated PaymentBurn permission should also need PaymentMint permission to cross a zero balance into minting. That concerns issued tokens and multi-purpose tokens, which can represent tokenized assets; it should not be described as permission to mint native XRP.

The package also separates signing prefixes used for sponsor and counterparty signatures. These are changes to the handling of transactions and permissions, rather than evidence that a new lending service has launched.

Separate lending amendments still have their own voting status. Users tracking the wider DeFi roadmap should therefore distinguish the cleanup package from activation of those features. The next decisive development for this amendment will be sustained majority through the full window, followed by the ledger recording it as enabled.

Written by the News Desk and edited by Samuel Rae.

TL;DR: The XRP Ledger’s BatchV1_1 amendment remains in its activation window and is expected to enable around October 9 if validator support stays above the required threshold. The upgrade allows multiple transactions to be bundled into an atomic group, replacing an earlier Batch version that was halted after a critical bug was found.

A major XRP Ledger upgrade is approaching activation after one of the more unusual validator coordination episodes in the network’s recent history.

BatchV1_1 is currently inside the XRPL amendment process and is expected to activate around October 9 if support remains above the required supermajority threshold.

The feature allows multiple transactions to be bundled together so they either succeed as a group or fail as a group.

That opens the door to more complex operations such as atomic swaps and workflows where several ledger actions need to complete together.

The route to activation has not been smooth.

An earlier version of Batch was prevented from activating after a critical issue was discovered.

Validators then coordinated around a corrected version, with support temporarily adjusted so the activation countdown could reset and the Batch amendment could arrive alongside its associated fix.

XRPL amendments require more than 80% support from trusted validators for two consecutive weeks before they can become active.

If support falls below that threshold, the clock resets.

That mechanism is deliberately conservative.

An amendment changes the rules understood by the network. Once it activates, servers that do not support the new rules can become amendment blocked and stop following the ledger correctly.

The corrected BatchV1_1 feature is therefore being paired with newer software designed to address the earlier problem.

The upgrade matters because atomic transaction groups are a basic building block for more sophisticated financial applications.

Without them, a developer may need to coordinate several separate ledger operations and deal with the possibility that one succeeds while another fails.

Batching lets the application treat those actions as one logical unit.

That can be useful for trading, tokenization and other workflows where partial execution would create risk.

The XRP Ledger has increasingly been adding features aimed at institutional assets and more complex on-chain finance.

Batch transactions fit into that broader direction, alongside work on multi-purpose tokens, permission controls and other features designed to support financial applications beyond basic XRP transfers.

The current countdown is not an absolute guarantee.

Validator support has to remain above the required level until the activation process completes.

But the network is much closer to enabling Batch than it was when the first version ran into trouble.

In some ways, the delay may be the more reassuring part of the story.

A decentralized network found a serious issue before activation, validators coordinated to stop the change, and the amendment process was reset around a fix.

Now the feature gets another attempt.

This time, the XRP Ledger is trying to make sure the batch arrives as a complete package rather than simply arriving on time.