XRPL Fixes Critical Pre-Mainnet Flaw but Client Apps Remain at Risk
What Happened
XRPL validators have placed the repaired BatchV1_1 amendment on a conditional path to activate at 14:06:41 UTC on Sept. 29. The amendment fixes a critical authorization flaw that was discovered before the original Batch amendment could reach the XRP Ledger mainnet, turning a security near-miss into a live test of the network's upgrade process and the software ecosystem surrounding it.
Key Details
- XRPL validators put BatchV1_1 on a conditional path to activate Sept. 29 if support stays above 80%.
- The rewrite closes a critical authorization flaw and enables safer multi-transaction batches with four execution modes.
- Outdated nodes and clients may fail after activation, while outer success can still conceal failed inner transactions.
The Authorization Flaw and Its Repair
The original Batch amendment never activated on the XRP Ledger mainnet. In February, researchers found a critical authorization flaw while the amendment was still in its voting phase, and validators were advised to vote it down. The flaw sat in the code that checked which accounts were authorizing a batch. If the code encountered a signer for a newly created account whose key matched that account, it returned success immediately instead of continuing through the remaining signers. An attacker could have placed that valid signer first, then added a forged entry purporting to authorize a victim account. If the amendment had gone live, the unchecked victim transaction could have executed without the victim's keys. XRPL Labs' official vulnerability disclosure states that no funds were at risk.
XRPL's response came in two stages. Version 3.1.1 marked the original Batch and fixBatchInnerSigs amendments unsupported, blocking their activation. BatchV1_1 later replaced them with a rewritten authorization path and additional defenses. The XRPL Foundation's final XLS-56 specification now requires a multi-account batch to contain the exact, complete set of BatchSigners whose authorization the inner transactions would ordinarily need, apart from the account whose normal signature authorizes the outer transaction. Missing, extra, duplicate, or incorrectly ordered entries cause rejection. Each BatchSigner also signs more than a loose collection of inner transactions. The payload binds the signature to the outer account, its sequence number or ticket, the selected batch mode, the ordered hashes of every inner transaction, and the BatchSigner account. A multi-signed entry also binds each nested signer account, preventing a valid signature from being lifted into a different outer transaction or reassigned to another participant.
How Batches Work and What Modes They Support
A Batch contains two to eight inner transactions. Each inner transaction carries no signature or fee and is marked so it cannot be submitted independently. The outer Batch selects exactly one of four modes: ALLORNOTHING, where every inner transaction must succeed or none of their state changes commit; ONLYONE, where the first successful inner transaction is the only one applied; UNTILFAILURE, where transactions apply in order until one fails; and INDEPENDENT, where every inner transaction is attempted regardless of the others' results. BatchV1_1 can support atomic all-or-nothing flows, but not every batch is atomic in that narrow sense. Developers can also use it for ordered fallbacks or independent bundles.
Client and Library Readiness After Activation
The most immediate integration trap is that an outer Batch can return tesSUCCESS even when one or more inner transactions fail. Clients must inspect each inner transaction's metadata and result code to determine what happened. That distinction is important outside ALLORNOTHING mode, where partial or independent execution is intentional.
BatchV1_1 support shipped in xrpld 3.3.0 on Aug. 6. Once the amendment activates, a server that does not understand the new rules becomes amendment-blocked. It can no longer reliably validate the ledger or participate in consensus until it upgrades. An issue filed against xrpl.js documented that version 5.0.0 built Batch signatures using the older payload, omitting the outer account, sequence, and participant binding. BatchV1_1-enabled nodes rejected those signatures with temBAD_SIGNATURE. The xrpl.js release history records compatible support in version 5.1.0. Wallets need to display every inner action and the selected mode, or a user may approve a bundle without understanding its full effect. Explorers and indexers need to preserve the relationship between outer and inner transactions, or interfaces can misreport or fragment the outcome of a batch.
What Is Confirmed
XRPL validators had 30 of 35 trusted validators supporting the amendment as of Sept. 22, above the displayed 28-vote threshold. The majority first appeared on-ledger on Sept. 15. Under XRPL's amendment rules, support must remain above 80% for two weeks. A fall to 80% or less ends the majority period. The original Batch amendment never activated on the XRP Ledger mainnet. XRPL Labs' official vulnerability disclosure states that no funds were at risk. Version 3.1.1 marked the original Batch and fixBatchInnerSigs amendments unsupported. BatchV1_1 support shipped in xrpld 3.3.0 on Aug. 6. xrpl.js version 5.1.0 added compatible support, while version 5.0.0 produced signatures rejected by BatchV1_1 nodes.
What Is Still Unclear
Whether validator support will remain above 80% through the required two-week period is uncertain. The activation date of Sept. 29 is conditional on this requirement being met. It is also unclear how many wallets and explorers are currently running compatible versions, and whether the community has identified any additional edge cases in the rewritten authorization path.
Why This Matters for XRPL
This episode was a failure caught at the boundary between software release and protocol activation. The XRPL validator process and reference implementation successfully identified and fixed a dangerous flaw before it could affect the mainnet. However, the activation of BatchV1_1 will test whether the broader client ecosystem, including nodes, wallets, libraries, and explorers, has kept pace with the repair. If outdated software remains in use, it could lead to broken validation, rejected transactions, or misreported batch outcomes.
What Happens Next
If validator support remains above 80%, the amendment is scheduled to activate at 14:06:41 UTC on Sept. 29. After activation, servers running incompatible software will become amendment-blocked and unable to validate the ledger or participate in consensus until they upgrade.
Sources
Newisty Editorial Team covers technology, cryptocurrency, digital products, online platforms, developer tools and the wider digital economy. Our content is researched from official sources, company announcements, public documentation, market data and other primary or reputable sources. Articles are reviewed and edited before publication for clarity, accuracy and useful context.
Related Posts
BVNK Adds Stellar Network Support for Stablecoin Payments
IMF: El Salvador stopped using public funds for bitcoin in June 2025
