XRP Ledger Batch Goes Live After Two Security Resets

The XRP Ledger switched on BatchV1_1 at 2:47 p.m. UTC on October 9, 2026, letting users wrap two to eight transactions into one signed unit.

Thirty trusted validators voted yes and five did not. The change is settlement plumbing, and it came on only after two security pullbacks.

BatchV1_1 Went Live at 2:47 p.m. UTC

XRPSCAN’s amendment record shows BatchV1_1 was enabled at 2:47 p.m. UTC on October 9, 2026, in ledger 107,540,992. The yes camp had held a majority since 2:46 p.m. UTC on September 25, which is the two-week window the ledger requires.

An amendment needs more than 80% support from trusted validators, held for 14 days without a dip. With 35 names on that list, 28 votes equal 80%, so 29 yes votes are the real bar. BatchV1_1 cleared it with 30 in favor and 5 not voting for it.

THE BATCHV1_1 TALLY

• Enabled: October 9, 2026, at 2:47 p.m. UTC in ledger 107,540,992.
• Yes votes: 30 trusted validators, with 5 not voting for the change.
• Majority clock: Held since 2:46 p.m. UTC on September 25, 2026.
• Bar: More than 80% for 14 days, which is 29 of 35 on this UNL.

The five that did not back it, on XRPSCAN’s final roll call, were cabbit.tech, gen3labs.xyz, tequ.dev, v2.xrpl-commons.org, and validator.xrpl-labs.com. None of those operators published a reason on the amendment page.

Vet, an XRPL validator who posts as @Vet_X0, called the switch-on a big moment for both institutions and retail builders, pointing to OTC trades, delivery-versus-payment, NFT-for-NFT swaps, and trustless execution dependencies.

Batch feature is now LIVE !!

Major props to all the engineers and validators to get this over the finish line.

Its a massively important functionality for the XRP Ledger to allow crucial use cases for institutions and also retail builders.

Think of OTC trades, DvP, NFT for NFT… https://t.co/gbRj0MwuJG pic.twitter.com/NxjnnyFEWt

— Vet (@Vet_X0) October 9, 2026

Replies under that post treated Batch as a throughput bump, asking whether the ledger was now eight times faster or whether eight NFTs could burn in one shot. It is not a speed upgrade. It is a wrapper that binds existing transaction types so they succeed or fail on rules the sender picks, inside one ledger close.

What Batch Does in a Single Ledger Close

Official docs say users can package multiple transactions together and run them as a single unit, which cuts the risk that one leg settles and the next does not. The XLS-56 batch specification allows 2 to 8 inner transactions, from one account or several.

Each inner transaction must set the tfInnerBatchTxn flag, put its fee at “0”, and arrive unsigned. The outer Batch pays the fee, signs for the collection, and picks one of four modes that decide what happens when an inner step fails.

THE FOUR BATCH MODES

All or Nothing is the mode people mean when they say atomic settlement. The other three are not atomic in that sense, and Independent is closest to sending the inners one by one.

The docs walk through a swap that shows why the wrapper exists. Alice wants to send 1,000 XRP and Bob wants to send 1,000 USD. If Alice hands Bob a fully signed inner payment, Bob can submit her leg and skip his. If she signs only her slice of the outer Batch, Bob can edit his inner payment down to 1 USD. So inner transactions stay unsigned, and every account in the batch signs the whole collection, including the hashes of every inner transaction and the mode flags.

The outer result is an accounting trap. A Batch can return tesSUCCESS because the wrapper paid its fee and consumed its sequence even when inner payments failed. Software that stops at the outer code will book a done trade that did not happen. Inner metadata, each with its own result code and a ParentBatchID back to the wrapper, is what actually settled.

The outer fee is (n + 2) times the 10-drop base fee, plus the sum of the inner fees, where n is the number of signatures on the outer transaction. With one signature and no load spike, that overhead is 20 drops. Inner fees are paid on the wrapper so fee escalation sees the full cost, not a cheap shell.

February’s Signature Bug Never Reached Mainnet

Batch did not arrive as a clean first try. On February 19, 2026, security researchers and Cantina AI found a critical logic flaw in checkBatchSign, the routine that confirms each inner-transaction account has authorized the batch.

When the function hit a signer whose account did not yet exist on the ledger, it returned success and skipped every remaining signer. Mayukha Vadari, the RippleX engineer who wrote the standard, spelled out the consequence in a September 14 review for RippleX Developers.

This would have allowed an attacker to essentially execute arbitrary transactions on behalf of any victim accounts without their private keys.

Mayukha Vadari, RippleX software engineer, Batch V1.1 review

The original amendment was still in its voting phase and had not been enabled, so no funds moved. Validators were told to vote no within hours, and an emergency release marked both Batch and fixBatchInnerSigs as unsupported.

BatchV1_1, shipped in xrpld 3.3.0, is a replacement, not a patch. Vadari’s checklist included a root-cause fix in PR 6446, review by four senior engineers, a Sherlock Batch Attackathon, a Common Prefix audit, and a Halborn re-audit of Batch after Halborn’s first pass in January and February 2025. Reviewers also closed 11 further defects, from MPT checks that could crash a node to signer-order tricks that let an attacker control who got validated first.

Vadari wrote that Batch is a prerequisite for multi-party settlements already under contract or in the pipeline, including custody transfers, DvP, and cross-border payment finalization, because it removes trust in execution order. RippleX has not named those counterparties.

The Fix Landed 32 Minutes Earlier

The rebuild still was not the last gate. During a re-check of Sherlock findings, Denis Angell of the XRPL Foundation confirmed on September 18, 2026, that a wrapper check believed fixed in BatchV1_1 was incomplete.

The spec says each inner transaction must sit inside a RawTransaction field. The server did not enforce that name. A hand-crafted Batch that wrapped an inner transaction in a different object field could still apply. On a mixed-version UNL that gap could halt validation, because xrpld 3.3.0 and 3.4.0 did not agree on which wrapper fields they knew.

No funds were at risk, and no SDK would emit the bad wrapper. The payoff for an attacker was a permanently malformed ledger record and a chance to break parsers that assume RawTransaction. Vadari raised the finding from low to a pre-activation blocker after she mapped the consensus stall.

HOW THE SECOND PULLBACK RAN

1. September 18, 2026: Denis Angell confirms the wrapper fix is incomplete and opens a public rippled pull request.
2. September 22, 2026: Mixed-version consensus risk is identified and BatchV1_1 is treated as a blocker.
3. September 23-24, 2026: Ripple and Vet pull their BatchV1_1 votes so the 14-day clock resets.
4. September 25, 2026: xrpld 3.4.1 ships fixBatchV1_2 as default-yes; BatchV1_1 regains a majority about 30 minutes behind that fix.
5. October 9, 2026: fixBatchV1_2 enables at 2:15 p.m. UTC with 35 yes votes, and BatchV1_1 enables 32 minutes later.

The public disclosure says Ripple and other operators chose to reset its activation clock rather than turn Batch on with a known bug and patch later. That second path would have risked a halt on a mixed UNL and a bad transaction that SDKs would have to special-case forever. The wrapper fix therefore had to land first. It did, at 2:15 p.m. UTC, 32 minutes before BatchV1_1.

The same 3.4.1 disclosure also records a separate payment-engine overflow, present since 2015 in the current engine, that could have minted XRP by wrapping a 64-bit sum. That bug was not tied to Batch, had not been exploited on a public network, and was patched in the same server release. It is a reminder that the ledger’s safety model is still catching long-dormant arithmetic, not only new features.

One Prompt Can Now Hide Eight Actions

Protocol risk from the February bug is closed. Signing-surface risk is not, and it got larger the hour Batch went live.

A Batch is one approval covering as many as eight inner transactions. If more than one account is in the wrapper, every listed account still has to sign. A user who only reads the word Batch, and not the inners, can approve a Payment beside a SetRegularKey, a SignerListSet, or an AccountSet that disables the master key. That is a full account handoff in a single prompt.

The protection is on the wallet screen before the signature, not in an explorer after the fact. Outer tesSUCCESS will not undo a key change that already applied.

REJECT THE BATCH IF AN INNER SHOWS

• SetRegularKey: Sets or removes a regular key the owner did not ask to change.
• SignerListSet: Creates or edits a signer list that can take over the account.
• AccountSet: Flips flags, including a master-key disable, that were not part of the intended flow.
• Unknown counterparty: A second account in the batch that the signer does not recognize.

Wallets that implement the docs will show every inner transaction, name the mode, and warn when other accounts are in the collection. Wallets that do not will look like a normal Payment screen with extra payload behind it. That gap, not a leftover signature bug, is the new retail failure mode.

Official guidance already tells wallet authors not to auto-increment sequences off a Batch result, because the number of committed inners depends on the mode. Explorers are told to group inners under the outer hash using ParentBatchID, rather than listing them as orphan payments.

Key Splits Arrived 17 Hours Before Batch

PermissionDelegationV1_1 enabled at 21:29:50 UTC on October 8, 2026, in ledger 107,524,865, about 17 hours before BatchV1_1. Together the two changes are the settlement pair people keep describing as a repo: a treasury keeps master keys offline, a desk receives a narrow right to move a specific token, and Batch forces that token and the cash leg to move in the same close.

Delegation lets an owner grant another account up to 10 granular permissions and revoke them later. It is built for issuers that want a compliance desk to approve customers, or a payments desk to send, without sharing the keys that control the main balance. Restrictions are by action type, not a spending cap, so operational controls still sit with the institution.

One caution remains on the official amendment record: do not delegate PaymentBurn until fixCleanup3_4_0 enables, because that permission can let a helper create issued tokens as well as destroy them. Other granular permissions are not covered by that warning.

Denis Angell, CTO of the XRPL Foundation, did not wait for a bank demo. On the evening of October 9 he posted a mainnet proof of concept that used Batch itself: two inner transactions, a Payment of 1 drop and a SetRegularKey to a fresh key, so the signing key is dead the moment the batch validates and the next key is never stored on the ledger.

Quantum resistant account on XRPL mainnet using Batch.
https://t.co/bqCKTbnIbR

The account only stores hashes. Your public key hits the ledger when you sign.

So every tx is a Batch with 2 inner txns;
1. Payment (1 drop lol)
2. SetRegularKey to a brand new key

The key that… https://t.co/omDIYzRepe pic.twitter.com/rMvYuaXBqT

— Denis Angell (@angell_denis) October 9, 2026

That is a working Batch on day one. It is also a reminder that the first uses will look like specialist tooling, not a flood of DvP volume. XRPL Commons had already shown a multi-account swap between RLUSD and a multi-purpose token on the design. Asset managers preparing for Batch still have to finish wallet flows, mode selection, and the inner-result checks the spec warns about.

10 Votes Still Separate Lending From Mainnet

Native lending is the product that would actually consume this plumbing for credit, and it is not live. RippleX opened validator voting on LendingProtocolV1_1 on September 30, 2026. That amendment adds closed-ended vaults, with subscription, investment, and redemption phases, and shifts vault accounting to a cash basis so interest counts as income only when borrowers pay.

RippleX says LendingProtocolV1_1 must enable before LendingProtocol and SingleAssetVault can proceed. New loan brokers, once the set is on, can only be created against closed-ended vaults. Closed-ended terms can run from 60 seconds to just under 30 years, and once the investment phase starts the protocol holds the advertised window even if a depositor wants out.

WHERE THE OCTOBER 9 VOTES STOOD

An October 9 XRPL Dashboard snapshot recorded both lending amendments at 19 yes votes, 10 short of 29. Default votes in the 3.4.0 release were listed as no, so the clock has not even started. Batch can already bind a token transfer to an RLUSD payment. It cannot yet bind that payment to a native on-ledger loan, because the loan objects are still gated.

The second-order result of October 9 is therefore narrow and real. The ledger can now settle several authorized actions in one close, after pulling the feature twice rather than shipping a known hole. The credit stack that would turn that into a money-market product is still a supermajority short, and the wallets that stand between users and an eight-action prompt are the layer that has to catch up first.

Frequently Asked Questions

How Many Transactions Can One XRPL Batch Contain?

A Batch must hold at least two inner transactions and at most eight; a wrapper with a single inner is invalid. The XLS-56 spec says the cap of eight can be raised later by another amendment, so eight is a protocol limit now, not a permanent ceiling.

Can You Dry-Run a Batch Before Submitting It?

No. Batch is incompatible with the simulate method, because that RPC is a dry run for one transaction and cannot model inner transactions joining the consensus set. Builders have to test the full wrapper on Devnet or Testnet instead.

Do You Still Pay Fees if Every Inner Transaction Fails?

Yes. Inner fees are collected on the outer Batch so fee escalation is computed on the full cost, and those fees are still charged if every inner transaction fails. Independent mode also skips the reserve that Tickets would lock, at a cost of 10 extra drops of overhead.

What Software Must Node Operators Run for Batch?

BatchV1_1 shipped in xrpld 3.3.0, but operators who skipped 3.4.1 become amendment-blocked once fixBatchV1_2 is on, because that fix also enabled on October 9, 2026. Servers that never upgraded stop following validated ledgers rather than processing Batch with the old wrapper rules.

Who Wrote the XLS-56 Batch Standard?

Mayukha Vadari of Ripple authored XLS-56, created December 13, 2023, with status Final. The spec adds one new transaction type, Batch, plus the tfInnerBatchTxn flag on common fields, and it does not create new ledger objects or change existing ones.

Denis Angell’s two-inner Batch on the evening of October 9 is already on the ledger. LendingProtocolV1_1 is not.

Disclaimer: This article is news reporting and analysis of an XRP Ledger protocol change and is for information only. It is not investment advice, trading advice, or a recommendation to buy, sell, or hold XRP or any token issued on the ledger, and it is not a security or wallet-integration guide. Readers should consult a qualified financial adviser and, for any funds they custody, a competent security engineer before acting on settlement features described here. Vote counts, amendment status, and software versions reflect the cited records as of the dates named in the piece and can change at the next flag ledger.