XRP Ledger Batch V1.1 Nears Activation After Security Rebuild

The XRP Ledger’s Batch V1.1 amendment is one validator vote short of reaching the 80% threshold needed to begin its 14-day activation countdown, after a security rebuild that followed a critical flaw in the original version.

The revised code has gone through senior engineering review, adversarial testing, two external security reviews, and AI-assisted analysis before its current validator vote.

Batch V1.1 Reaches Final Vote Before Activation Countdown

RippleX developer Mayukha Vadari said the amendment shipped with xrpld 3.3.0 and is now up for voting. The update replaces Batch V1.0, whose signature-validation bug was found in February while the amendment was still pre-mainnet, meaning no funds were at risk.

The original flaw involved an early return in the checkBatchSign function. If a signer account did not yet exist on the ledger, validation could return success without checking the remaining signers. That could have allowed transactions to be executed on behalf of other accounts without their private keys.

Batch V1.1 removed that flaw and also addressed several other issues found during the rebuild. The process included review by four senior engineers, a Sherlock Batch Attackathon, a Halborn reassessment, a Common Prefix audit, Cantina AI scanning, and Devnet and testnet regression testing.

Vadari also said the team fixed additional bugs found through its newer AI red-teaming work. The changes include fixes for MPT validation bypasses, node crashes, path size validation, signature verification, signer ordering, and transaction hashing.

Validator sentiment is close to the required threshold, with one account, FrancisBovineSwift, describing the Batch voting as “nearly there,” with the most recent snapshot showing 27 trusted validators have voted for the amendment and eight against it, putting support at roughly 77% against the 80% threshold required to sign off on changes, with just one more vote needed to hit that mark.

Why the Batch Amendment Matters to XRPL Developers

Batch, also known as XLS-56, allows multiple transactions from different accounts to execute atomically in a single ledger close. If one transaction in an all-or-nothing batch fails, the entire operation reverts. The design does not require smart contracts.

The feature is intended for atomic swaps, coordinated settlements, and other transactions where multiple parties need to act together. It could also reduce the number of steps needed for NFT minting and transfers.

The security rebuild follows other recent XRPL scrutiny, after the network pulled its Permission Delegation amendment when a high-severity bug was found before mainnet deployment, with V1.1 undergoing additional review.

Furthermore, an XRPL testing dashboard launched this month has also made amendment testing more visible by tracking which transaction types, fields, and result codes have been exercised on Devnet.