Batch V1.1: What Changed and Why It's Ready

What is Batch?

Batch (XLS-56) allows multiple XRPL transactions from different accounts to execute atomically in a single ledger close. For example, if any inner transaction fails during the all-or-nothing mode of the feature, the entire batch reverts. This makes various types of atomic operations much easier, and is also foundational infrastructure for multi-party coordination on the XRPL: atomic swaps, coordinated settlements, and any workflow where two or more parties need to move in lockstep without trust assumptions.

What happened with the original Batch (v1.0)

On February 19, 2026, security researchers and Cantina AI identified a critical logic flaw in the signature-validation routine of the original Batch amendment. The function checkBatchSign, which validates that each inner-transaction account has authorized the batch, 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 validation of all remaining signers. This would have allowed an attacker to essentially execute arbitrary transactions on behalf of any victim accounts without their private keys.

See the full Vulnerability Disclosure Report here.

The amendment was in its voting phase and had not been activated on Mainnet. No funds were at risk. Within hours of receiving the report, UNL validators were advised to vote "No," Ripple's engineering team reproduced the issue with an independent unit test, and an emergency release was published, marking both Batch and fixBatchInnerSigs as "unsupported".

What changed in Batch V1.1

Batch V1.1 is a replacement amendment that ships the corrected implementation in xrpld v3.3.0. The primary focus was on fixing the bug found in February and further hardening the implementation.

We took the following steps to ensure that the new version is secure:

Checkpoint	Status
Root-cause fix (early-return elimination)	Complete, merged via PR #6446
Code review by 4 senior engineers	Complete
Sherlock Batch Attackathon contest	Complete
Halborn Batch re-assessment	Complete
Common Prefix Batch audit	Complete
AI-assisted static analysis pipeline (including a Cantina scan)	Integrated into review and release process
QA Devnet and testnet regression testing	Complete

In addition, we found and fixed the following bugs:

• Batch Transaction Bypasses MPT Validation, Crashes Node
• Simulate RPC tfInnerBatchTxn Flag Assertion Crash
• Path Size Validation Bypass via Batch Transactions
• preflight2 tfInnerBatchTxn flag bypasses signature verification in release builds
• preflight1 batch parentBatchId invariant — assert-only enforcement with boolean logic error
• checkValidity does not return early for valid inner batch transactions
• Batch Signatures Miss Outer Account Binding
• Batch signer ordering not enforced, allowing attacker to control authorization check order
• Node crash via uncaught std::runtime_error from Batch::calculateBaseFee
• buildBatchTxnIds hashes full inner array pre-count-cap at deserialization
• Protocol bounds follow hashing and signature verification

Why Batch matters for the XRPL

Batch is a prerequisite or accelerant for several high-value XRPL use cases already under contract or in active pipeline, such as:

Atomic multi-party settlements. Institutional workflows (custody transfers, DvP settlement, cross-border payment finalization) require two or more accounts to act simultaneously. Batch removes the need for trust in execution ordering, eliminating a class of race conditions and partial-execution risks.

Developer experience and ecosystem growth. Batch is one of the most requested features by XRPL application developers and the community broadly. It enables patterns common on programmatic chains (such as multi-call, atomic bundles, and flash loans) natively on XRPL without smart contracts, reducing friction for new builders entering the ecosystem. Batch also enables DEXs, Wallets and Marketplaces to monetise on transactions they process by bundling the base transaction (such as a Payment) with a platform fee. There are many members of the XRPL ecosystem eager to use this feature.

Governance context

The original Batch incident demonstrated that the XRPL governance model works. A critical bug was reported, validators responded within hours, and no funds were ever at risk because the amendment had not yet been activated. The v1.1 replacement was given additional scrutiny precisely because of that history: broader code review, AI-assisted auditing, Sherlock contest, a Halborn re-assessment, and a Common Prefix audit on top of the standard internal audit process.

For validators voting on Batch V1.1 in xrpld version 3.3.0:

• The root cause is fully understood and publicly documented (vulnerability disclosure report published February 25, 2026).
• The fix addresses not just the specific bug but the class of vulnerability (early-return in validation loops, signing payload binding).
• The review process has been expanded with additional tooling and reviewers relative to v1.0.
• The business case is concrete: named partners, contracted use cases, and protocol-level dependencies are waiting on this capability.

Try it on Devnet today!