XRPL fixes pre-mainnet batch bug; clients face signature risk

Validators placed the BatchV1_1 amendment on a conditional activation path for 14:06:41 UTC on Sept. 29 after developers applied a patch for a pre-mainnet authorization flaw. Support reached a ledger majority in mid-September and must remain above 80% for two weeks to finalize the activation date. On Sept. 22, 30 of 35 trusted validators registered backing the amendment on the dashboard; the on-ledger majority first appeared on Sept. 15.

An earlier Batch amendment failed to activate on mainnet after a critical authorization bug was discovered during the voting phase in February. The flaw occurred in the signer-checking loop: when the code encountered a signer for a newly created account whose key matched that account, it returned success immediately instead of validating the remaining signers. A malicious actor could have placed a valid signer first and then added a forged entry purporting to authorize a victim account. Security reporting at the time indicated no funds were at risk when the issue was found.

XRPL’s technical response began by marking the original Batch and fixBatchInnerSigs amendments unsupported in xrpld 3.1.1 to prevent activation. BatchV1_1 replaces them with a redesigned authorization path and additional checks. The XRPL Foundation’s final XLS-56 specification requires a multi-account batch to include the exact set of BatchSigners whose authorization the inner transactions would normally require, excluding only the account whose normal signature authorizes the outer transaction. Missing, extra, duplicate or incorrectly ordered entries are now grounds for rejection.

The amended design binds each BatchSigner’s signature to the outer account, its sequence number or ticket, the chosen batch mode, the ordered hashes of every inner transaction, and the BatchSigner account. Multi-signed entries also bind nested signer accounts. The merged reference implementation enforces signer ordering and uniqueness, transaction-count limits, rejection of inner transactions submitted directly, and protections against replay across ledgers.

A Batch holds two to eight inner transactions. Inner transactions carry no separate signature or fee and are flagged so they cannot be submitted independently. The outer Batch selects one of four modes: ALLORNOTHING, where all inner transactions must succeed or none commit; ONLYONE, where the first successful inner transaction is applied and the rest ignored; UNTILFAILURE, where transactions apply in order until one fails; and INDEPENDENT, where every inner transaction is attempted regardless of others’ results. Outside ALLORNOTHING mode, the outer Batch can return tesSUCCESS while one or more inner transactions have failed, so client software must read inner-transaction metadata and result codes to determine outcomes.

BatchV1_1 support shipped in xrpld 3.3.0 on Aug. 6. After activation, any server that does not understand the new rules will become amendment-blocked and will not reliably validate the ledger or participate in consensus until it upgrades. An issue documented that xrpl.js version 5.0.0 built Batch signatures using an older payload format that omitted bindings for the outer account and sequence; BatchV1_1-enabled nodes rejected those signatures with temBAD_SIGNATURE. xrpl.js recorded compatible support in version 5.1.0.

Client applications and data services have work to do before or after activation. Wallets must display every inner action and the selected mode so users can see what they are approving. Explorers and indexers need to preserve the relationship between outer and inner transactions and report each inner transaction’s result. The XLS-56 specification notes ongoing investigation of front-running risks when multiple market-facing operations are packaged into an ordered batch.

If support remains above the required threshold through the voting window, the Sept. 29 activation will test whether validators, node operators, signing libraries, wallets and indexers handle the repaired format and rules in practice. Immediate signals to observe after activation include whether outdated nodes become blocked, whether signature failures cluster around old client versions, whether wallets present multi-account batches clearly, and whether explorers report inner outcomes without conflating outer success with complete execution.