XRP Ledger is about to switch on a protocol feature it already switched on once. The obvious story is that atomic transactions are finally arriving. That story is wrong. This is not a feature story. It is a release-management story, and its clearest record is not the roadmap but the amendment vote table, where the mistakes are still standing and still being counted.
I will give you my conclusion before the evidence. XLS-56 is an ordinary piece of design exposed to an extraordinary process. The code is easy and the maintenance is not. The feature is being switched on by two amendments from two different releases, one of which fixes a bug that shipped in a release whose main other job was to switch the same feature off, and the second of which has no public release notes at all. I have watched a lot of teams ship a feature twice and call the second one progress; a protocol does not forget what it once enabled.
Nothing in XLS-56 is hard. That is the point.
Read the specification and you will hunt for the hard part. You will not find it. XLS-56, Atomic/Batch Transactions, is an Amendment-category standard with status Final, authored by Mayukha Vadari of Ripple, created on 2023-12-13 and last updated on 2026-08-14. It adds one transaction type, Batch, plus an addition to the common fields every transaction already carries, with no new ledger objects and no changes to existing ones. Nothing here would take a competent engineer more than a week. A change like this cannot ship as a library, though. It has to go into the protocol, and going into the protocol means an amendment, two weeks of validator support, a compile-time default vote every operator can override, and a permanent place in the codebase. Eighty per cent of the cost of software is maintenance, and maintenance does not end inside a ledger.
What the amendment actually adds: two to eight transactions, one fee, one mode flag
The body of the change is smaller than its reputation. RawTransactions carries two to eight inner transactions, from one account or several, and the specification says the limit of eight can be relaxed later, which is where the next amendment will go. Each inner transaction must set the tfInnerBatchTxn flag, must set its fee to zero, and must not be signed: empty SigningPubKey and no TxnSignature. The outer transaction pays n plus 2 times the base fee plus the sum of the inner fees, where n counts the outer signatures; with no fee escalation that overhead is 20 drops against a base fee of 10 drops, and the inner fees are paid by the outer transaction so escalation is computed on the total cost, not the overhead alone. When inner transactions come from more than one account, BatchSigners must carry a signature from every account that would normally sign, excluding the outer signer, and the array must be strictly ascending, with no duplicates and no gaps, up to 24 entries. Where the boundary between a signed thing and an unsigned thing is drawn is exactly where signature bugs live, which is the argument I made about hardware in the piece on where a machine ends and the software begins. Exactly one mode flag is allowed per Batch, and there are four.
| Mode and flag value | What it does | When one inner transaction fails | Who it is for |
|---|---|---|---|
| tfAllOrNothing (0x00010000) | All inner transactions must succeed for any to succeed | The whole Batch is reverted and nothing is committed | A multi-step operation that must never stop half-done |
| tfOnlyOne (0x00020000) | The first inner transaction to succeed is the only one that succeeds | Later transactions are not tried, and the Batch still succeeds as a whole | Several offers at different slippage where only one should fill |
| tfUntilFailure (0x00040000) | Apply until the first failure, then drop the rest | Everything after the failure is left unapplied, and the outer transaction still returns tesSUCCESS | Ordered fallbacks, such as trying one account and then another |
| tfIndependent (0x00080000) | Apply every inner transaction regardless of failure | The remaining inner transactions still apply, and the outer transaction still returns tesSUCCESS | Best-effort cleanup or notifications that should run even when one leg fails |
The modes are not advisory: any result other than tesSUCCESS counts as a failure, and the outer transaction still returns tesSUCCESS even when inner processing fails, because each inner transaction is committed separately, with its own metadata and a pointer back through ParentBatchID. Legacy systems can process a Batch as if it were a set of normal transactions, with no changes on their side. That is the one design decision here I would call elegant: it protects every system that never wanted to know that Batch exists.
Where did this feature come from, and what hole was it filling?
Two generations ago the XRP Ledger made a bet: it would not put a general virtual machine on every step. That bet bought speed and a small attack surface, and it left a hole: without a programmable layer the ledger could not execute multiple transactions atomically, so a multi-step operation such as minting an asset and then offering it could stop half-done with no native way to unwind the first half. That is the hole XLS-56 fills, and it is a hole left by the previous generation’s choice, not by its bugs. Every generation hands the next one a hole. The design is written down in the XLS-56 standard, and its authors make the case with a house.
“Imagine building a house: you wouldn’t want to lay the foundation and build the walls, and then discover you can’t afford the roof, leaving you with an unfinished and unusable structure.” And: “If you’re unable to afford the roof, you won’t even bother laying the foundation.”
XLS-56, Atomic/Batch Transactions, Ripple
They shipped it, switched it off, and are switching it back on with a second patch still in the vote
Now the part that is actually a story. The Batch transaction type was introduced in rippled/xrpld 2.5.0. It did not survive contact with production. Pull request #6069, “fix: Inner batch transactions never have valid signatures”, added the fixBatchInnerSigs amendment, on the plain reasoning that unsigned inner transactions should never have been flagged as having valid signatures. Then release 3.1.1, on February 23, 2026, disabled the whole thing through pull request #6402. Its release note says more than it means to.
“Disable support for Batch and fixBatchInnerSigs.” And: “Thanks to Pranamya Keshkamat & Cantina AI for discovering and responsibly disclosing this issue.”
rippled 3.1.1 release notes, February 23, 2026
- rippled/xrpld 2.5.0 introduces the Batch transaction type defined by XLS-56.
- Pull request #6069 lands the fixBatchInnerSigs amendment, on the reasoning that unsigned inner transactions should never have had valid signatures.
- Release 3.1.1, on February 23, 2026, disables Batch and fixBatchInnerSigs through pull request #6402, after a bug-bounty disclosure.
- Release 3.3.0, on August 6, 2026, adds Batch (XLS-56) V1_1 through pull request #6446, refactors Batch transaction IDs through pull request #7736, and enables BatchV1_1 through pull request #7698.
- fixBatchV1_2 is listed by community explorers as introduced in 3.4.1, but the project’s public release list stops at 3.4.0 on September 17, 2026, so no public notes describe what it changes.
Read the vote table, not the roadmap
On 2026-09-29 the XRPScan amendments index, which counts 35 trusted validators, put the 80% threshold at 28 votes. BatchV1_1 shows 30 of 35 validators, or 85.7%, as standard XLS-56, introduced in 3.3.0, flagged for majority on 2026-09-25. fixBatchV1_2 shows 34 of 35, or 97.1%, introduced in 3.4.1. PermissionDelegationV1_1, the XLS-75 companion, shows 29 of 35, or 82.9%. Then the part a roadmap would never show you: the retired original Batch, from 2.5.0, still records 12 of 35 validators voting for it; the retired fixBatchInnerSigs, from 3.1.0, still records 10 of 35; the retired PermissionDelegation records 1 of 35. Four generations of one feature, Batch, fixBatchInnerSigs, BatchV1_1 and fixBatchV1_2, sit in the same live table at once, and two of them are dead code that validators still vote for. A table that accumulates the dead is a table you read the way I argued you should read consensus changes in the piece on Solana’s consensus swaps: start with the data, then decide. One caution, about a single node and not the network: the public cluster xrplcluster.com answered a feature request on 2026-09-29 with build version 3.4.1 and 105 amendments of which 11 were not enabled, and it carried the fixBatchV1_2 ID while its supported field reported it would not apply it. The cluster is load-balanced, so consecutive requests can hit different builds.
Two weeks is the entire governance model. Count the ways that can go wrong.
The rule is one sentence and it carries the whole system. If an amendment gets more than 80% support for two weeks, it passes and applies permanently, and disabling a passed amendment requires a new amendment. Support below 80% means temporarily rejected and the two-week clock restarts, as many times as it takes. Votes are evaluated around flag ledgers, roughly every 15 minutes, through an EnableAmendment pseudo-transaction flagged tfGotMajority or tfLostMajority. A server running an older build without the source code of an enabled amendment becomes amendment blocked and can no longer determine a ledger’s validity, and bug fixes that change transaction processing require amendments too, which is why two of these four generations are fix-type. The full rule set is short and it is on the amendments page at xrpl.org. What it does not do is guarantee order. Both batch amendments carry majority flags dated 2026-09-25, and the patch, fixBatchV1_2, was flagged at 22:12 UTC while the amendment it patches, BatchV1_1, was flagged at 22:46 UTC. The fix reached its majority 34 minutes before the thing it fixes. That is a ledger telling you the order in which its defects were found. Two weeks of sustained support puts activation near October 9, 2026; community reporting on September 28, 2026, citing the XRP Ledger Foundation community lead known as Vet and XRPScan data, put the countdown at about 11 days, with support between 85% and 94%. Permission Delegation sits inside the same window, its majority flag also dated 2026-09-25, and I will not put a separate date on it.
What you are actually buying, and what it costs you to maintain
Benefit first, because an architecture change that does not measurably reduce cost, risk or headcount is decoration. XLS-56 buys one concrete thing: an operation that cannot stop half-done. For an institution that removes the risk of funds sitting half-settled when one party fails its leg, and its companion XLS-75, Permission Delegation, lets an organization split operational roles without sharing the primary private key. The use cases the specification lists are honest and small: mint an NFT and create an offer for it at once; submit several offers at different slippage so only one fills; package platform fees inside the transaction; flash loans that borrow, use and repay in one transaction; and try one account before falling back to another. None of that is new capability in the world; it is new capability in this ledger, and it is the only benefit I am prepared to defend. The cost is a feature that now exists in four amendment generations, two disabled, and a fourth whose changes are undocumented. If the design needs more people to operate it, the design failed, so the only way to hold the operating cost down is to write down, before activation, what you will actually do. Four of those things, in order:
- Write down which of the four amendment IDs your node currently votes for, and confirm which build it runs, because a node that lacks the source code of an enabled amendment becomes amendment blocked and can no longer determine ledger validity.
- Test all four mode flags against a real inner failure, not a happy path, because the difference between tfAllOrNothing and tfUntilFailure is the difference between a reverted operation and a half-applied one.
- Decide who owns BatchSigners on multi-account flows, because the array must be strictly ascending, with no duplicates and no gaps, and it is the first place a signature-ordering bug will surface.
- Put a review date on the maintenance, because this one feature already has four generations and two of them are dead code that someone must eventually remove.
What I do not know, stated plainly. There are no public release notes for fixBatchV1_2, so I will not guess what it fixes; community explorers list it as introduced in 3.4.1, public releases stop at 3.4.0, and that gap is the fact, not a detail to fill in. Whether the two-week clock holds to October 9 depends on 35 validators who can change their vote at any time. I do not claim that any named validator or company flipped a vote, because the data does not show it, and the cluster reading is one load-balanced node, not the network.
What I am sure of is smaller and more useful. XLS-56 is a good small primitive and I expect it to work. The thing to watch is not the Batch but the process that needed two amendments and a disabled release to switch on a feature it had already switched on once. A network whose vote table is its changelog is judged by its maintenance record, not its roadmap. Read the table. The table does not spin.
