EN

Why Batch was replaced

4 minDifficulty Checked 2026-11-10
Key takeaways
  • 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.

Check yourself3 questions
1. What could the original Batch bug have allowed?
2. In September 2026, BatchV1_1 had a majority. Why did some validators switch to No?
3. What happens to a server older than 3.4.1 now that fixBatchV1_2 is enabled?
Next modulePermission delegationT11 · 12 min