XRP Ledger validators have set BatchV1_1 for conditional activation on September 29 at 14:06:41 UTC, according to support levels shown on xrpldashboard as of September 22. The amendment represents a security repair following a critical flaw discovered in an earlier batch proposal.
On September 22, 30 of 35 trusted validators were supporting the amendment, above the displayed 28-vote threshold. Under XRPL's amendment rules, support must remain above 80% for two weeks to proceed to activation. A decline to 80% or lower would reset the timeline.
The Original Flaw
The original Batch amendment never reached mainnet activation. In February, researchers identified a critical authorization flaw during the amendment's voting phase, and validators were advised to reject it. XRPL Labs' vulnerability disclosure stated that no funds were at risk.
The flaw occurred in the authorization loop that verified signers for batch transactions. If the code found a signer for a newly created account whose key matched that account, it would return success immediately rather than checking remaining signers. An attacker could exploit this by placing a valid signer first, then adding a forged entry claiming to authorize a victim account, potentially allowing unauthorized transactions to execute.
The Network's Response
XRPL responded in two stages. Version 3.1.1 marked both the original Batch and fixBatchInnerSigs amendments as unsupported, blocking their activation. BatchV1_1 later replaced them with a rewritten authorization system and additional safeguards.
The updated XLS-56 specification now requires multi-account batches to contain an exact, complete set of BatchSigners. Missing, extra, duplicate, or incorrectly ordered entries cause rejection. Each BatchSigner signature is bound to the outer account, sequence number or ticket, batch mode, transaction hashes, and participant accounts, preventing valid signatures from being transferred between transactions.
BatchV1_1 batches contain two to eight inner transactions and support four execution modes: ALLORNOTHING (all succeed or none commit), ONLYONE (first successful transaction is applied), UNTILFAILURE (transactions apply until one fails), and INDEPENDENT (all attempted regardless of results).
Integration Challenges Ahead
The amendment's activation will shift risks to implementation. A critical integration issue involves outer Batch transactions returning success even when inner transactions fail outside of ALLORNOTHING mode. Client applications must inspect each inner transaction's metadata and result code to determine actual outcomes.
BatchV1_1 support shipped in xrpld 3.3.0 on August 6. After activation, servers not supporting the new rules will become amendment-blocked and unable to validate the ledger or participate in consensus until upgraded.
xrpl.js version 5.0.0 initially built Batch signatures using an older payload format that omitted the outer account, sequence, and participant binding. BatchV1_1-enabled nodes rejected these signatures. Compatible support was added in xrpl.js version 5.1.0.
Wallets and data infrastructure also face integration challenges. Wallets must clearly display each inner action and selected mode so users understand batch effects. Explorers and indexers must preserve relationships between outer and inner transactions to avoid misreporting batch outcomes.
What Activation Will Test
If validator support holds, September 29 activation will demonstrate whether XRPL's amendment process can halt dangerous changes and successfully route a repaired replacement through governance. It will begin a real-world test of whether servers, signing libraries, wallets, and data infrastructure properly handle the new transaction format.
Activation will not prove that applications have adopted BatchV1_1, that users want the feature, or that transaction demand will increase. The specification also flags front-running as an area still under investigation, noting that stronger authorization prevents forged approvals but does not eliminate all risks from packaging multiple market-facing actions into ordered submissions.
The useful indicators will emerge after activation: whether outdated nodes become blocked, whether signing failures cluster around old client versions, whether wallets intelligibly present multi-account batches, and whether explorers correctly report inner transaction outcomes.
