The XRP Ledger’s Batch V1.1 amendment is now one trusted validator vote away from clearing the threshold needed to begin its 14-day activation countdown. The proposal has 27 votes in favor and eight against, leaving support just below the 80% level required for XRPL amendments to advance.
The vote comes after RippleX rebuilt the feature following the discovery of a critical bug in the original Batch V1.0 code. According to RippleX developer Mayukha Vadari, the revised version was shipped in xrpld 3.3.0 and has since gone through multiple internal and external security checks before reaching the current stage.
A rebuilt version after a pre-mainnet flaw
Batch V1.1 replaces Batch V1.0, which was found in February to contain a signature-validation bug while still in pre-mainnet testing. Vadari said no funds were at risk because the issue was identified before deployment to mainnet.
The flaw centered on an early return in the checkBatchSign function. If a signer account did not yet exist on the ledger, validation could incorrectly return success without verifying the remaining signers. In practice, that could have allowed transactions to be carried out on behalf of other accounts without their private keys.
Vadari said the rebuilt release removes that vulnerability and also fixes several other issues uncovered during the review process. Those changes include work on MPT validation bypasses, node crashes, path size validation, signature verification, signer ordering, and transaction hashing.
Security review widened before the vote
RippleX said the new version was subjected to a broader review process before being put forward for activation. Vadari described that process as including review by four senior engineers, a Sherlock Batch Attackathon, a Halborn reassessment, a Common Prefix audit, Cantina AI scanning, and regression testing on Devnet and testnet.
She also said the team addressed additional bugs identified through newer AI red-teaming work. The article describes the overall effort as a security rebuild, combining conventional engineering review, external audits, adversarial testing, and AI-assisted analysis before validators were asked to vote.
That extra scrutiny follows other recent caution around XRPL amendments. The network previously withdrew its Permission Delegation amendment after a high-severity bug was discovered before mainnet deployment.
What Batch is designed to do
Batch, also referred to as XLS-56, is designed to let multiple transactions from different accounts execute atomically within a single ledger close. Its all-or-nothing structure means that if one transaction in the batch fails, the entire set is reverted.
The feature is intended for cases where several parties need to coordinate actions at the same time, including atomic swaps and coordinated settlements. The design does not require smart contracts.
The source article also notes that Batch could simplify some NFT-related workflows by reducing the number of separate steps needed for minting and transfers.
Next step is the activation countdown
At the latest snapshot cited in the report, support stood at roughly 77%, with 27 trusted validators voting yes and eight voting no. One account, FrancisBovineSwift, described the amendment as “nearly there,” reflecting how close the vote is to the required line.
If Batch V1.1 gains one more trusted validator vote and reaches the 80% threshold, it can begin the 14-day countdown required for activation. Separately, an XRPL testing dashboard launched this month has made amendment testing more visible by tracking which transaction types, fields, and result codes have been exercised on Devnet.
Source: cryptopotato.com