Image Credit: Shutterstock
Key Takeaways
- Batch V1.1 lets up to eight transactions settle together or fail together, aiding delivery-versus-payment use cases and bundled service fees.
- The amendment has backing from 30 of 35 tracked validators and is projected to activate around Sept. 29 if support holds above 80%.
- The redesign followed a critical signature-validation flaw found in Batch V1.0 in February, prompting an expanded review including AI-assisted analysis and outside security audits.
Ripple said asset managers and other commercial projects are preparing to use an upcoming XRP Ledger feature that links multiple transactions so they settle together or fail together. A rebuilt version of the upgrade nears activation following an extensive security review. The feature, called Batch V1.1, can combine as many as eight transactions into a single all-or-nothing operation.
How Batch V1.1 Works
Batch’s all-or-nothing structure ensures that every transaction in a linked group succeeds, or the entire group is canceled, preventing situations where one side of a deal settles while the other fails.
Ayo Akinyele, head of engineering at RippleX, said the feature is particularly suited to delivery-versus-payment transactions, where an asset and its corresponding payment need to move together rather than relying on one party to send first.
“Batch allows multiple transactions to be grouped together so they either all execute or none do. That is particularly important for use cases like delivery-versus-payment, where the asset and payment need to move atomically.”
He added that some projects are already being built with Batch in mind, so activation would allow that work to move closer to production. He further stated that they would share more on specific partners and launch timing as those plans are finalized.
Bundling Fees and Payments Into a Single Transaction
Beyond delivery-versus-payment settlement, Batch could let exchanges, wallets, and marketplaces attach service fees directly to a customer transaction, processing a payment and its associated platform fee as a single operation rather than through separate transfers.
That kind of atomic bundling addresses a common friction point in blockchain-based payment systems, where linked transactions handled separately can leave one leg of a transaction stranded if the other fails partway through. This then requires manual reconciliation or exposing a counterparty to settlement risk.
Consolidating related transactions into a single all-or-nothing operation removes that risk at the protocol level rather than requiring applications built on top of the ledger to manage it themselves.
Validator Support and Activation Timeline
The amendment has backing from 30 of the XRP Ledger’s 35 tracked validators, above the 28 votes required to enter its activation countdown, which began Sept. 15 at 14:06:41 UTC.
Batch V1.1 is projected to activate shortly after the same time on Sept. 29, provided validator support remains at or above 80% through the full 14-day window.
Validators can change their votes at any point, meaning the activation date remains conditional until the countdown concludes. If support drops below the threshold before then, the countdown resets and a new 14-day window must begin once support recovers.
A Redesign Following an Earlier Critical Flaw
The approaching activation follows the withdrawal of an earlier version of the feature after researchers found a critical flaw in Batch V1.0’s signature-validation process in February. Under certain conditions, the flawed code could stop checking signatures early, potentially allowing an attacker to include transactions from another account without that account’s authorization.
The vulnerable amendment was still being considered by validators and had not activated at the time the flaw was found, meaning the flawed code never governed the live ledger and no funds were exposed as a result.
Akinyele said RippleX used the incident as an opportunity to substantially expand the review process rather than simply patching the specific error.
“We used it as an opportunity to go much deeper on the implementation, redesign parts of the signing and authorization model, and significantly expand the security review.”
According to Akinyele, the bigger point is that they established a very high bar. They found a serious issue in V1.0 before activation, stopped it, redesigned and hardened the implementation, expanded the review considerably, and only then put V1.1 back in front of validators.
A Redesigned Version Backed by an Expanded Security Review
The redesigned implementation shipped in xrpld version 3.3.0, released Aug. 6, which is the same code validators are now voting to activate.
The expanded review included internal adversarial testing, AI-assisted code analysis, a bug-bounty style attack contest run through security platform Sherlock, and independent assessments from security firms Halborn and Common Prefix.
The extended timeline between the original flaw’s discovery in February and the current activation vote reflects a broader pattern in blockchain protocol development.
Features tied to financial settlement typically face a higher bar for security review than in other software contexts, given that a flaw discovered after activation could expose live funds rather than a system still under review.
