Skip to main content

«  View All Posts

XRP Ledger Version 2.5.0 Update- Batch (XLS-56)

October 8th, 2025

3 min read

By Jake Hanley

This is the third in a series of articles devoted to the new amendments introduced for consensus voting with the latest version of the XRP Ledger (v2.5.0).

The first article in the series introduced and explained the amendment system. Please refer back to the first article for a baseline understanding of the process. This article focuses on Batch amendment (XLS-56) and assumes the reader is reading the series in order.

Stay informed on what's coming on Open Source Ripple

What is Batching and How Does Batching Work Right Now?

Batching is the grouping of multiple tasks into a single operation. A great example is doing your laundry. You can certainly wash each one of your socks separately in the sink but it is much more efficient to batch them by gathering them all up in your washing machine and running a single cycle.

Simply put, there is no way to do proper batching within XRPL right now. All transactions must be submitted separately and if there is a failed transaction along the way, all of the effort, and fees, are lost.

Batch Amendment (XLS-56)

This new amendment drastically changes the functionality of the XRP Ledger by allowing the grouping and ordering of up to 8 transactions into a single batched operation. It also introduces atomic execution via ALLORNOTHING as one of its execution modes for batched transactions. Atomic in this case refers to the structure of the code that specifies if any transaction within a batch fails, the entire operation fails and no transactions ever take place.1

These two changes have obvious time and cost efficiencies built into them. Being able to rely on a multi-step process allows for much more complex transaction structuring and deal facilitation. Participants will be able to more seamlessly control their operational risk with what is likely to be a much lower multi-step failure rate.

Let’s take a look at all four new execution modes, including ALLORNOTHING, introduced by the Batch amendment and what they can add.

ALLORNOTHING: We’ve already generally explained ALLORNOTHING but in a batch transaction, any INNER transaction failure will cause the OUTER Batch transaction to fail and it's as if neither the INNER nor OUTER transactions ever happened.

ONLYONE: The next mode is ONLYONE. This mode specifies that INNER transactions will be tried in a specified order until one succeeds. If one succeeds, the rest of the INNER transactions are never attempted. If they all fail, the OUTER Batch transaction fails.

UNTILFAILURE: UNTILFAILURE is the inverse of ONLYONE, this mode runs until one of the INNER transactions fails. When one of them fails, the OUTER Batch transaction is complete.

INDEPENDENT: The last mode is exactly what you would expect from the name. While up to 8 INNER transactions can be bundled together, if INDEPENDENT mode is specified, they’ll have no dependency on each other’s success or failure. Once all the INNER transactions have succeeded or failed, the OUTER Batch transaction is finished.

All of these modes increase the overall efficiency of the blockchain. By reducing the number of overall transaction failures and the need to retry transactions, it’s likely a lot of bloat from the current style of cyclical transaction attempts will be cut out moving forward. Along with that bloat removal is likely to be a lot of cost savings as we’ve noted every transaction has a fee, regardless of outcome.2

We’re only scratching the surface of the implementation possibilities, but developers are already starting to create more sophisticated decentralized applications that were previously unusable because they require complex operational workflows with low failure rates. Some of these potential use cases could be multi-party escrows to complement the TokenEscrow amendment, automated market making and swaps, and much more granular condition payment structures. All of these adds up to a huge potential upgrade if the Batch amendment gains consensus.3

1 XRPL Foundation. "XLS-0056-batch." GitHub repository, XRPLF/XRPL-Standards. https://github.com/XRPLF/XRPL-Standards/tree/master/XLS-0056-batch.

2 XRP Ledger Foundation. "Known Amendments." XRPL.org. https://xrpl.org/resources/known-amendments.

3 RippleX Development Team. "Introducing Batch Transactions on the XRP Ledger: More Opportunities, Less Friction." DEV Community, June 27, 2025. https://dev.to/ripplexdev/introducing-batch-transactions-on-the-xrp-ledger-more-opportunities-less-friction-50h5.

 


The information provided on this page and its associated documents is intended to provide a broad overview for discussion purposes. It is subject to change and should not be taken as financial or investment advice. Teucrium Trading LLC and Teucrium Investment Advisors, LLC make no offers to sell, solicitations to buy, or recommendations for any security, nor do they offer advisory services.

Past performance is not indicative of future results. Teucrium disclaims any liability for any actions taken based on the information provided herein.

Jake Hanley

Managing Director/Senior Portfolio Specialist.