XRPL Batch v1.1 ships atomic multi-account transactions after signature flaw sank original amendment

What Batch does

According to a RippleX engineering post on dev.to, Batch — amendment XLS-56 — lets the XRP Ledger execute several transactions from different accounts within a single ledger close. In its all-or-nothing mode, if any inner transaction fails, the entire batch reverts. The post describes this as foundational plumbing for multi-party coordination on XRPL: atomic swaps, coordinated settlements, and any workflow where two or more parties must move in lockstep without trusting one another's execution ordering.

The bug that stopped v1.0

On February 19, 2026, security researchers and Cantina AI identified a critical logic flaw in the original amendment's signature-validation routine. The function that verified each inner transaction had been authorized by its account, checkBatchSign, contained an early-return bug: when it encountered a signer whose account did not yet exist on the ledger, it immediately returned success and skipped validating all remaining signers. An attacker could have exploited this to execute transactions on behalf of victim accounts without their private keys.

The amendment was still in its voting phase and had never activated on Mainnet, so no funds were at risk. Within hours of the report, UNL validators were advised to vote against it, Ripple's engineering team reproduced the issue with an independent unit test, and an emergency release marked both Batch and the companion amendment fixBatchInnerSigs as unsupported.

What v1.1 changes

Batch v1.1 is a replacement amendment that ships the corrected implementation in xrpld v3.3.0. According to the post, the fix addresses the whole class of vulnerability — early returns inside validation loops and the binding of signing payloads — rather than only the single reported instance, and the implementation received further hardening.

The review also surfaced and fixed a long list of additional bugs, including:

• a batch transaction bypassing multi-purpose token (MPT) validation and crashing a node
• a crash triggered through the Simulate RPC via an inner-batch transaction flag
• a path size validation bypass through batch transactions
• a preflight flag that skipped signature verification in release builds
• assert-only enforcement of a parentBatchId invariant, with a boolean logic error
• batch signatures missing a binding to the outer account
• unenforced signer ordering, which would have let an attacker control the order of authorization checks
• a node crash from an uncaught runtime error during base-fee calculation

What it unlocks

RippleX frames Batch as a prerequisite or accelerant for use cases already contracted or in active development. Institutional workflows such as custody transfers, delivery-versus-payment settlement and cross-border payment finalization require multiple accounts to act simultaneously; Batch removes the need to trust execution ordering, eliminating a class of race conditions and partial-execution risk.

The feature is also described as one of the most requested by XRPL application developers and the broader community. It brings patterns common on programmable chains — multi-call, atomic bundles, flash loans — to XRPL natively, without smart contracts. It also lets DEXs, wallets and marketplaces bundle a base transaction such as a Payment with a platform fee, giving them a way to monetize the transactions they process.

Governance and review

The post presents the v1.0 incident as evidence that XRPL's governance model works: a critical bug was reported, validators responded within hours, and no funds were exposed because the amendment had not activated. That history shaped v1.1's review, which added broader code review, AI-assisted auditing, a Sherlock contest, a Halborn re-assessment and a Common Prefix audit on top of the standard internal process. A vulnerability disclosure report was published on February 25, 2026. Validators are now voting on Batch v1.1 in xrpld v3.3.0, and the feature is available to try on Devnet today.

Why it matters

Atomic multi-account execution is table stakes on smart-contract platforms, but XRPL — which deliberately has no general-purpose virtual machine — has lacked a native equivalent. Batch closes that gap while keeping execution at the protocol layer, which matters for institutional settlement flows that need deterministic, all-or-nothing behavior without on-ledger programs. The v1.0 episode is also a useful case study in amendment-based governance: a key-handling flaw was caught and neutralized before activation, and the replacement was subjected to materially heavier scrutiny than its predecessor. Whether Batch v1.1 reaches Mainnet now rests with validators, along with the contracted use cases waiting on it.