XRP Ledger Nears a New Payments Update
XRP Ledger’s Batch V1.1 update is nearing the support needed for activation, giving apps a way to complete connected payment steps together or reject the entire operation.
Key Takeaways
- Batch V1.1 had 27 supporting validators.
- One more vote would reach 80%.
- Support must hold for two weeks.
- Each batch can contain eight transactions.
- The original Batch amendment was withdrawn.
XRP Ledger’s Batch V1.1 amendment had support from 27 of the 35 validators tracked by XRPScan at 06:25 UTC on September 15, 2026. One additional supporting validator would take it to the 80% threshold required to begin the activation period.
If adopted, Batch would allow applications to group up to eight connected transactions under one operation. Its practical purpose is to make payment and trading flows involving several dependent actions less vulnerable to partial completion.
Batch needs 80% support for two weeks
With 35 validators in XRPScan’s tracked set, Batch V1.1 needs support from at least 28 to reach 80%. The amendment would then need to maintain the required backing for two consecutive weeks before becoming part of the XRP Ledger’s active rules.
The activation process separates the availability of the code from its use on the live network. An amendment can be included in XRP Ledger server software, but it does not change mainnet behaviour until validators approve it and the required period is completed.
How a batch can prevent a half-completed payment
Batch V1.1 would allow up to eight linked transactions to be submitted together. The ledger could check and record the selected instructions during the same ledger close instead of requiring an application to submit and confirm each step separately.
Consider a marketplace sale involving three actions: the buyer sends payment, the seller transfers an asset, and the marketplace receives its fee. Under the all-or-nothing option, all three instructions must succeed or the complete batch fails. This prevents the buyer’s payment from being recorded when the corresponding asset transfer cannot be completed.
A batch can also coordinate instructions involving more than one account. That makes it relevant to applications in which several participants must authorise different parts of the same operation.
The amendment would not make ordinary XRP transfers faster or require every application to use batches. It would provide an optional transaction structure for developers building services with several connected steps.
V1.1 follows a Batch amendment that was stopped
The original Batch amendment contained a flaw in how it checked authorisation for transactions inside a batch. Security researchers identified the problem in February while the amendment was still awaiting activation.
Validators were advised to withdraw their support before the feature reached mainnet, meaning the vulnerability did not affect user funds. The XRP Ledger Foundation’s vulnerability disclosure describes the response and identifies the earlier implementation as unsupported.
Batch V1.1 replaces that version after the authorisation logic was corrected. According to RippleX, the revised implementation also went through additional code review, testing and external security assessments before returning to the validator voting process.
The renewed vote is therefore more than a second attempt to activate the same feature. Validators are deciding whether the replacement sufficiently addresses the problem that stopped the original amendment.
Batch is closer than XRPL’s planned lending system
Batch’s position can be compared with two other XRP Ledger changes progressing through the amendment process. The fixCleanup3_3_0 proposal addresses maintenance and safety issues involving vaults, automated market makers and permissioned trading. It improves existing transaction paths rather than introducing a new payment function for applications.
The planned institutional credit system remains further from implementation. Both Single Asset Vaults and Lending Protocol need sufficient validator backing, and activating only one would not create a functioning native lending market.
Batch has a narrower scope because it coordinates transactions that XRP Ledger already supports, including payments, asset transfers and fees. Its 27 supporting validators place it closer to the activation threshold than the two amendments needed for native lending.
That comparison also shows why amendment approval does not always translate directly into a finished product. Lending requires several connected protocol components, while Batch would give individual applications a tool they could choose to integrate independently.
What activation would mean for wallets and marketplaces
Completing the activation process would make Batch available on the live ledger, but wallets, marketplaces and payment services would still need to incorporate it into their products.
Users would not need to change how they make a standard XRP transfer. The difference would become visible inside applications that currently ask customers to complete several connected actions or retry an operation after one instruction fails.
Services combining a payment, asset transfer and platform fee are among the clearest potential users. Each provider would still have to determine which steps belong in a batch and whether all of them must succeed before the customer’s request is considered complete.
The vote is only the first test for Batch V1.1
Reaching the activation threshold would settle whether validators are prepared to run Batch V1.1, but it would not establish how much demand exists for the feature. That question can only be answered by adoption among wallets, marketplaces and payment applications.
Batch may have an advantage over XRPL’s more ambitious lending proposals because developers would not need to wait for several protocol components or an entirely new financial market. They could apply it to transaction flows that already exist. Its eventual importance will therefore depend less on the amendment vote than on whether XRPL services encounter enough multi-step failures to justify integrating it.
This article is provided for informational purposes only and does not constitute financial or investment advice. Validator support and amendment status can change.
Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work at Coindoo has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.
