XRPL Fixes Critical Pre-Mainnet Flaw, but Client Apps Remain at Risk

XRPL validators have placed the BatchV1_1 amendment on a conditional activation path for 14:06:41 UTC on Sept. 29. The vote reached the required threshold, but the amendment will only activate if support stays above 80 % for two weeks.

Background: a near‑miss flaw

In February, researchers identified a critical authorization bug in the original Batch amendment. The flaw allowed a signer for a newly created account to trigger immediate success, potentially letting an attacker forge a victim’s transaction. XRPL Labs disclosed that no funds were at risk, and validators were advised to vote the amendment down.

Repair and new specification

The XRPL Foundation responded with two steps:

• Version 3.1.1 marked the original Batch and fixBatchInnerSigs amendments as unsupported.
• BatchV1_1 replaced them with a rewritten authorization path, adding signer ordering, uniqueness checks, transaction‑count bounds, and replay protections.

The final XLS‑56 specification now requires a multi‑account batch to include the exact set of BatchSigners, each bound to the outer account, sequence, batch mode, and ordered inner‑transaction hashes.

How BatchV1_1 works

A Batch can contain two to eight inner transactions, which carry no signature or fee and cannot be submitted independently. The outer Batch selects one of four modes:

1. ALLORNOTHING: all inner transactions must succeed or none are committed.
2. ONLYONE: only the first successful inner transaction is applied.
3. UNTILFAILURE: transactions are applied in order until one fails.
4. INDEPENDENT: each inner transaction is attempted regardless of others’ results.

BatchV1_1 supports atomic all‑or‑nothing flows but also enables ordered fallbacks or independent bundles.

Implementation risks

Clients must inspect each inner transaction’s metadata because an outer Batch can return tesSUCCESS even when some inner transactions fail. Outdated software will become amendment‑blocked after activation:

• xrpld versions prior to 3.3.0 lack the new rules.
• xrpl.js 5.0.0 produces signatures that BatchV1_1 nodes reject; compatibility was added in xrpl.js 5.1.0.
• Wallets and explorers need to display every inner action and its result to avoid user confusion.

What the Sept. 29 test will show

If the validator majority holds, activation will demonstrate that XRPL’s governance can replace a dangerous amendment with a repaired version. It will also reveal whether the broader ecosystem—servers, signing libraries, wallets, and indexers—has adopted the new transaction format correctly. The test does not guarantee user adoption, increased transaction demand, or price effects for XRP.

Open questions

Key signals to watch after activation include:

• Whether outdated nodes become blocked.
• Frequency of signing failures linked to old client versions.
• Clarity of batch presentation in wallets.
• Accuracy of explorers in reporting inner‑transaction outcomes.