Batch lets transactions from different accounts run in one bundle. Payment and asset delivery can depend on each other, while fees and individual results follow their own rules.
XRP Ledger activated Batch on mainnet in an October 9 blockchain upgrade, allowing multiple transactions to be processed together. The network’s official amendment list marks both BatchV1_1 and the related fixBatchV1_2 security correction as enabled on that date.
XRPL validator and XRP Ledger Foundation contributor Vet announced that “Batch feature is now LIVE” in a post today. He cited delivery-versus-payment, over-the-counter trades and NFT-for-NFT swaps as possible uses. The announcement did not identify a completed institutional transaction or disclose trading volume.
Vet’s Batch activation announcement, October 9, 2026
The post loads from X when you open it.
Up to eight transactions in one batch
The XLS-56 technical standard allows a bundle of two to eight transactions from the same account or several accounts. In all-or-nothing mode, every transaction must succeed for any of them to be applied. An NFT mint and a sale offer, for example, can be bundled: if creating the offer fails, the mint is rolled back too.
In a swap involving multiple accounts, each required signer authorizes the full set of transactions. The other party cannot extract only the transfer that benefits it and submit that transfer alone. Linking payment to delivery is intended to avoid a partially completed exchange in which one party sends the asset but the other does not send the payment.
The four Batch modes do not all provide that guarantee. Only-one mode applies the first transaction that succeeds. Until-failure mode retains completed steps, then stops at the first failure without applying the remaining steps. Independent mode attempts each transaction regardless of the others’ outcomes. Applications choose a mode based on how the operations should depend on one another.
Fees and transaction results need separate checks
Network fees can still be charged when the transactions in a batch fail. Rolling back those transactions does not imply a fee refund.
The fee is paid through the outer Batch transaction. Its calculation includes twice the base fee, the fees associated with the inner transactions and charges for additional signatures. A zero fee field on an inner transaction therefore does not make the whole bundle free.
Developers need to inspect individual results. A success code on the outer Batch transaction does not, on its own, prove that every step inside it completed. The standard calls for applications to check each inner transaction’s outcome and for wallets to display all the operations and the chosen mode on their signing screens.
The security fix is now active too
BatchV1_1 was prepared to replace the original Batch implementation after a bug was found. Developers subsequently introduced fixBatchV1_2 in the emergency xrpld 3.4.1 release on September 25. Its release notes list rejection of inner Batch transactions paired with the wrong outer wrapper among the changes.
Those notes warned that servers not upgraded to 3.4.1 would be unable to remain synchronized with the rest of the network once the correction activated. For users, mainnet activation does not establish that every wallet offers a screen for creating and signing Batch transactions; wallet and application developers still need to provide those functions.
In the English-language interview published by Ripple on January 15, 2026, XRPL Labs executive Robert Kiuru discusses wallet usability and earning application revenue through Batch transactions. The interview predates today’s activation announcement and is included as background.
