
Why Batch was replaced
4 minDifficulty Checked 2026-11-10- The original Batch amendment was pulled in rippled 3.1.1 after a signer-check bug.
- BatchV1_1 carried the fix. A second fix, fixBatchV1_2, delayed its start by ten days.
- Neither bug reached mainnet. Both were caught while the amendments were still in voting.
A new feature on the XRP Ledger switches on only after validators vote for it. That wait gives people time to find bugs. Batch shows the process at work.
First try. The original Batch amendment shipped in rippled 2.5.0 in June 2025. In February 2026, a researcher reported a flaw in how it checked signatures. A crafted batch could move money out of someone else's account without that person's keys. Batch was still in voting, so no funds were at risk. Validators were asked to vote No, and rippled 3.1.1 dropped support for it.
Second try. The fix shipped as a new amendment, BatchV1_1, in xrpld 3.3.0. It gained a majority and was set to switch on 2026-09-29.
One more stop. In September 2026, a recheck of audit findings showed the code skipped one check on how inner transactions are packed. Servers on different versions could disagree about whether a batch was valid, which could stall the network. Validators switched their BatchV1_1 votes to No, which reset its two-week clock. A small fix amendment, fixBatchV1_2, shipped in xrpld 3.4.1.
Live. Both regained support. fixBatchV1_2 switched on first and BatchV1_1 about half an hour later, on 2026-10-09.
Neither bug ever ran on mainnet.
Signer bug (original Batch). Reported on 2026-02-19 by Pranamya Keshkamat and Cantina AI's Apex tool. Inner transactions are unsigned, so authorization rests on BatchSigners. The check loop returned success as soon as it met a signer whose account did not exist yet and who signed with that account's own key. Later entries were never checked. An attacker could create a new account inside the batch, list it first, then add a forged entry for a victim.
rippled 3.1.1 (2026-02-23) marked Batch and fixBatchInnerSigs as unsupported. fixBatchInnerSigs, from rippled 3.1.0, fixed inner transactions being flagged as validly signed. BatchV1_1 includes that fix. Halborn audited the original design in early 2025 and re-audited the fix in March and April 2026.
Wrapper bug (fixBatchV1_2). Each element of RawTransactions must be a RawTransaction object. Under BatchV1_1 alone, other object fields with no template, such as Memo, were also accepted. xrpld 3.4.0 removed six unused object fields that 3.3.0 knew. A 3.3.0 node would accept a batch using one of them, while a 3.4.0 node could not parse it. With fixBatchV1_2, such a batch fails with temMALFORMED.
Timeline from the disclosure report:
| Date | Event |
|---|---|
| 2026-09-18 | Incomplete fix confirmed (finding F48, Sherlock Attackathon) |
| 2026-09-23 to 24 | Ripple and Vet pull their BatchV1_1 votes; its clock resets |
| 2026-09-25 | xrpld 3.4.1 ships fixBatchV1_2, default vote Yes |
| 2026-10-09 | fixBatchV1_2 enabled in ledger 107,540,481; BatchV1_1 in ledger 107,540,993 |
Servers older than 3.4.1 are now amendment blocked. Live status: BatchV1_1, fixBatchV1_2. See How amendments happen for the voting rules.
- Vulnerability Disclosure Report: XRPL Batch Amendment – Unauthorized Inner Transaction ExecutionRead 2026-11-10
- Introducing XRP Ledger version 3.1.1 and Upcoming Devnet ResetRead 2026-11-10
- Introducing XRP Ledger version 3.3.0Read 2026-11-10
- Vulnerability Disclosure Report for xrpld 3.4.1Read 2026-11-10
- Known AmendmentsRead 2026-11-10
- Batch TransactionsRead 2026-11-10
