The XRP Ledger activated its BatchV1_1 batch-transactions amendment and the fixBatchV1_2 security amendment on Mainnet on Oct. 9, according to the XRP Ledger Foundation. The paired activation means the transaction-batching capability went live only after a rule change intended to remove a mixed-version consensus risk.
The rollout follows an emergency software release issued on Sept. 25. That release, xrpld 3.4.1, delivered the validation fix associated with Batch and made upgrades necessary for server operators seeking to remain synchronized after the amendments activated.
fixBatchV1_2 closes the Batch consensus risk
The XRP Ledger Foundation said fixBatchV1_2 eliminates a consensus risk that could arise when XRPL nodes run different software versions.
The amendment requires nodes to reject Batch inner transactions using any wrapper other than RawTransaction. It therefore narrows the permitted wrapper for those transactions and establishes the validation behavior required for Mainnet activation.
fixBatchV1_2 and BatchV1_1 became active together, rather than as separate feature and remediation events.
Batch processing is available under the revised validation rule.
xrpld 3.4.1 made operator upgrades necessary
The Foundation’s xrpld 3.4.1 release notice described the update as an emergency release carrying the Batch validation fix. It said server operators needed to upgrade to maintain synchronization once activation occurred.
That requirement placed the software update ahead of the Oct. 9 amendment activation. The available disclosures do not provide figures for operator adoption, transaction use, or any immediate change in network activity following the launch.
BatchV1_1 brings up to eight transactions into one submission
BatchV1_1 allows users to submit up to eight transactions as one unit. The feature supports an all-or-nothing mode, in which the grouped transactions are handled together, and an independent-execution mode, according to the Foundation’s Oct. 9 disclosure report.
The distinction gives submitters a choice between linking the outcome of transactions in a batch and allowing them to execute independently. The maximum remains eight transactions per submission under the activated feature.
