Asset Managers Ready for XRP Ledger Batch V1.1 Rollout

XRPL’s Batch V1.1 nearing activation as institutions build

The XRP Ledger's Batch V1.1 amendment remains above the validator threshold required to continue its activation countdown, and Ripple says asset managers and commercial projects are preparing integrations that will leverage the new transaction grouping feature if it activates later this month. Live validator readings show the amendment retains enough backing to keep a potential activation window open for September 29, while developers and security teams have completed an iterative review after an earlier version was halted for a critical flaw.

Activation status and how validator voting works

As of the latest snapshot, Batch V1.1 had the support of 30 out of 35 trusted validators tracked by XRPLDashboard — roughly 85% backing. The XRP Ledger requires at least 80% validator support for an amendment to be maintained for an uninterrupted 14-day window before it activates. That 80% supermajority equates to 28 votes in the current validator set, and the countdown clock began on September 15 at 14:06:41 UTC. If the level of support remains steady through the full period, activation could follow shortly after 14:06:41 UTC on September 29.

It is important to remember that XRPL amendments do not trigger merely by reaching 80% once. Validators must sustain the supermajority without interruption for the whole 14-day period. Votes can change while the clock runs; if support slips below the threshold, the running window stops and a fresh uninterrupted 14-day period would be required to restart the activation process.

Recent vote trajectory

Batch V1.1’s support has climbed quickly over the past month. Earlier in September the amendment had only 24 of 35 validator votes, leaving it below the activation threshold. By September 15 support had risen to 27 votes and then crossed the 28-vote threshold, beginning the current countdown. The latest published tally on September 20 remained at 30 of 35 tracked validators in favor.

What Batch V1.1 introduces to the transaction layer

Defined in the XLS-56 specification, Batch V1.1 enables a single transaction to package between two and eight inner transactions. This grouping operates with four processing modes: All or Nothing, Only One, Until Failure and Independent. Each mode alters how the ledger processes the inner transactions when one or more legs fail or succeed.

• All or Nothing: either every inner transaction succeeds together or none of them take effect. This is the atomic setting most relevant to delivery-versus-payment workflows.
• Only One: requires exactly one inner transaction to succeed; otherwise the batch fails.
• Until Failure: processes inner transactions in order until a failure occurs, after which remaining inner transactions are not attempted.
• Independent: inner transactions are processed separately; the success or failure of one leg does not determine others.

Batch V1.1 supports up to eight inner transactions, including atomic-swap structures and other multi-leg arrangements. That design enables complex settlement flows, such as pairing an asset transfer with a payment in a single atomic operation.

Delivery-versus-payment and atomic settlement

Ripple has emphasized delivery-versus-payment (DvP) as a commercial use case. Under DvP, asset settlement and the corresponding payment can be placed into the same atomic batch so that a failed payment prevents the linked asset transfer from completing. This reduces settlement risk in tokenized-asset workflows and institutional trading, where atomicity and finality are critical.

Security history: why the amendment was reworked

Batch V1.1 is a revised replacement for an earlier Batch proposal that was halted after security researchers discovered a critical signature-validation vulnerability in February. The vulnerability report, authored by an independent researcher and validated through automated tooling, showed that under specific conditions the original Batch signing logic could prematurely stop verifying signatures after encountering a newly created account. In a worst-case scenario this could have allowed an attacker to inject an inner transaction authorized by an account without possessing the rightful private key.

That first Batch proposal never activated on mainnet; it was still in voting when developers and validators were advised to block activation. The rippled release 3.1.1 (February 23) made Batch and fixBatchInnerSigs unsupported to ensure they could not activate while the vulnerability was addressed.

Remediation and redesign

Developers changed the signing and authorization logic when creating Batch V1.1. The remediation removed the premature success condition, tightened signature-checking rules, and added authorization safeguards. The improved amendment was incorporated into xrpld 3.3.0, which shipped on August 6, after further development and security review.

Security work did not stop there. Prior to the current validator vote, maintainers fixed another set of issues related to signatures, authorization checks and potential server stability concerns. RippleX reported that the review process included internal adversarial testing, AI-assisted analysis, a Sherlock security contest, and assessments from external security firms such as Halborn and Common Prefix. Those efforts aimed to reduce attack surface and harden the signing flow for multiple account patterns and edge cases.

Developer and tooling readiness

The evolving signing design required updates across the XRPL developer ecosystem. For example, the xrpl.js library needed changes because the revised Batch format binds additional account and sequence information to signatures. The JavaScript binary-codec added Batch signing support in version 2.9.0 in August. Server operators were advised to move to xrpld 3.4.0, released September 16, to maintain continuity; that release introduced separate lending and cleanup amendments but did not replace Batch V1.1, which remains in its own voting process.

Integration requirements for production use

Applications, wallets and marketplaces that want to adopt Batch will need to update signing logic, key management and transaction construction. Because a single Batch can include inner transactions from different accounts, implementations must manage multi-account authorizations, nonce and sequence coordination, and fee accounting. XRPL transaction fees remain relevant for Batch operations, even when the asset legs being moved are tokenized representations rather than XRP itself.

Potential use cases: tokenization, fees, swaps and flash loans

XLS-56 lists several potential applications beyond simple grouped payments. These include trustless multi-account swaps, platform fees bundled with customer payments, and flash-loan-like structures. For example, a marketplace could package a customer payment with a service charge in one atomic Batch rather than requiring two separate transactions. Different accounts can authorize individual legs of the same Batch, enabling custodial, marketplace and institutional workflows where multiple parties sign specific legs.

Importantly, Batch does not require using XRP as the moved asset. The feature operates at the transaction layer and can package XRPL-supported asset transfers, tokenized instruments and custom token structures alongside XRP or instead of it. XRP remains relevant for fee payment, but the underlying settlement can involve other tokens or issued currencies on XRPL.

Institutional interest and tokenized settlement experiments

Ripple's public commentary on Batch coincides with growing interest from financial institutions and asset managers in XRPL for tokenized assets and institutional settlement. Notable institutional tests and pilots over recent months have included tokenized U.S. Treasury redemption experiments involving JPMorgan, Mastercard, Ondo Finance and Ripple. In July, Aviva Investors launched a tokenized fund share class on XRPL, and Ripple has suggested RLUSD — its institutional stable token concept — as a potential cash leg for atomic DvP settlement.

On-chain tokenization metrics also show growth: one RWA data aggregator reported roughly $2.6 billion in tokenized real-world asset value added to XRPL over a six-month period, excluding stablecoins. Observers caution that represented asset value and actively distributed assets are different measures, but the trend signals rising activity around tokenized instruments.

Asset managers and undisclosed partners

RippleX head of engineering Ayo Akinyele told media outlets that work with asset managers is being prepared around Batch V1.1, but the company has not publicly disclosed specific partners or launch timetables. That leaves the current narrative at the level of in-development commercial integrations rather than formal partnership announcements. Ripple has indicated that more details will be shared after projects finalize their production plans and the amendment is live.

What market participants should watch next

Two near-term events will determine whether Batch V1.1 moves into production. First, the validator supermajority must be maintained without interruption for the full 14-day countdown. If any significant subset of validators removes support, the running window will stop and a new uninterrupted period will be necessary. Second, server operators and middleware providers must complete software upgrades and signing-tooling updates to support the final Batch signing format.

If activation occurs, expect a period of cautious, phased adoption by custodians, wallets and institutional clients. Projects that have been building to Batch will likely issue integration notes and partner announcements detailing how they plan to leverage atomic settlement, DvP and fee-bundling flows to reduce operational complexity and settlement risk.

Risk and compliance considerations

Entering production will require rigorous operational controls: key custody practices, signature coordination across accounts, monitoring for malformed batches, and conservative rate-limiting to avoid accidental mass failures. Regulators and institutional compliance teams will also evaluate how atomic multi-leg transactions fit into existing settlement, reconciliation and audit frameworks. Tokenized assets themselves carry custody, legal and regulatory considerations that extend beyond the technical features of Batch.

Conclusion: readiness and cautious optimism

Batch V1.1 represents a significant enhancement to XRPL's transaction model, enabling atomic multi-leg workflows that matter for tokenized asset settlement, DvP and marketplace payments. The amendment has recovered from an earlier security incident and moved through an intensive review cycle, and its current validator backing keeps the September 29 activation window open provided support remains steady.

For market participants, the coming weeks will be a period of preparation: final software upgrades, signing-tooling updates, and the potential of commercial rollouts from asset managers and institutional projects once the feature is live. If Batch activates as projected, it could materially streamline multi-legged settlements on XRPL and accelerate institutional tokenization use cases that demand atomicity and deterministic settlement outcomes.