XRP Ledger validators have placed the repaired BatchV1_1 amendment on course for conditional activation at 14:06:41 UTC on 29 September, after an earlier version was stopped by a critical authorisation flaw before it reached mainnet.
On 22 September, xrpldashboard recorded 30 of 35 trusted validators supporting the amendment, above its displayed 28-vote threshold. The majority first appeared on-ledger on 15 September. Under XRPL rules, support must remain above 80% for two weeks; if it falls to 80% or below, the majority period ends and the activation date will not proceed.
The vote will be the first production test of whether XRPL’s validator process, reference implementation and wider client ecosystem can safely deploy the replacement.
Flaw blocked before mainnet
The original Batch amendment never activated on the XRP Ledger mainnet. Researchers identified a critical authorisation problem in February, while it was still being voted on, and validators were advised to reject it. XRPL Labs said in its official vulnerability disclosure that no funds were at risk.
The flaw affected the loop checking the accounts authorising a batch. If the code found a signer for a newly created account whose key matched that account, it returned success without checking the remaining signers. An attacker could have placed that valid signer first, followed by a forged entry claiming to authorise a victim’s account. Had the amendment gone live, the victim’s transaction could have been executed without the victim’s keys.
Version 3.1.1 of xrpld marked the original Batch and fixBatchInnerSigs amendments as unsupported, preventing activation. BatchV1_1 later replaced them with a rewritten authorisation process and additional safeguards.
The final XLS-56 specification requires a multi-account batch to contain the exact, complete set of BatchSigners needed by its inner transactions, excluding the account whose normal signature authorises the outer transaction. Missing, extra, duplicate or incorrectly ordered entries are rejected.
Signatures are also tied to the outer account, sequence number or ticket, selected batch mode, ordered hashes of all inner transactions and the BatchSigner account. Multi-signed entries include each nested signer account, preventing signatures being transferred to another outer transaction or participant.
A batch contains between two and eight inner transactions. They carry no signature or fee and cannot be submitted independently. The outer transaction must use one of four modes: ALLORNOTHING, ONLYONE, UNTILFAILURE or INDEPENDENT. These allow full rollback, first-success execution, ordered execution until failure, or attempts on every inner transaction respectively.
Client software remains exposed
The main integration risk is that an outer Batch can return tesSUCCESS even when inner transactions fail. Clients must therefore inspect each inner transaction’s metadata and result code, particularly outside ALLORNOTHING mode.
BatchV1_1 support was added to xrpld 3.3.0 on 6 August. After activation, servers that do not understand the amendment will become amendment-blocked and cannot reliably validate the ledger or take part in consensus until upgraded.
An xrpl.js issue showed that version 5.0.0 used the older signing payload, omitting the outer account, sequence and participant binding. BatchV1_1-enabled nodes rejected those signatures with temBAD_SIGNATURE. Compatible support was recorded in xrpl.js 5.1.0.
Wallets must display every inner action and the selected mode, while explorers and indexers must preserve the relationship between outer and inner transactions. Otherwise users may approve an unclear bundle or interfaces may misreport its outcome.
The specification says front-running remains under investigation. Activation will test software compatibility and reporting, but will not demonstrate user adoption, increased transaction demand or additional XRP buying.
