XRP Ledger Batch goes live, enabling bundled transactions

The XRP Ledger has activated its Batch feature on mainnet with support from 30 validators, allowing users to bundle between two and eight transactions into one operation.

XRPScan’s dashboard shows BatchV1_1 as active on mainnet, according to the reported amendment data, following the network’s two-week validator approval period.

With 30 of 35 validators supporting the change, the reported vote count puts approval at about 85.7%. Under XRPL’s amendment process, proposals must sustain the required validator supermajority for two consecutive weeks before their rules take effect.

According to XRPL’s documentation, Batch contains an outer transaction and a list of two to eight inner transactions. The chosen execution mode determines whether the actions depend on each other or can complete separately.

XRP Ledger Batch supports linked trades and payments

XRPL validator Vet described the feature as useful for institutions and retail developers, pointing to over-the-counter trades, delivery-versus-payment settlement, NFT-for-NFT exchanges and transactions whose execution depends on another action.

“Its a massively important functionality for the XRP Ledger to allow crucial use cases for institutions and also retail builders,” Vet said.

In his assessment, developers have considerable room to build around the feature, which he described as a “big unlock.”

For linked exchanges, the official Batch specification describes an all-or-nothing setting that requires every included action to succeed. Under that setting, a failed transfer prevents the rest of the group from completing independently, according to the specification.

In its Sep. 15 coverage, crypto.news previously reported that developers had fixed 11 software issues before the latest approval process, while RippleX said commercial projects using Batch were already under contract or development.

RippleX’s examples included a token swap between two users and a customer payment paired with a platform fee. Its account described projects in development without naming the companies involved.

According to the published specification, participating accounts must approve the transaction collection in a multi-account Batch. The signing rules bind their approval to the bundled actions, preventing one participant from treating another party’s transfer as a separately authorized payment.

Four execution modes determine which actions complete

The official specification gives users four choices: All or Nothing, Only One, Until Failure, and Independent.

Under All or Nothing, the group completes only if every included action succeeds, the specification says. Only One instead permits a single successful action, supporting a sequence of alternatives rather than requiring the entire collection to complete.

For ordered operations, Until Failure processes actions until an action fails, retaining earlier successful steps under the specification’s rules. Independent attempts the included actions separately, without requiring every action to succeed.

According to XRPL’s transaction reference, users must select one execution mode for the Batch. The reference also prohibits nesting a Batch transaction inside another Batch and rejects duplicate inner transactions.

In its Sep. 29 review of Batch mechanics, earlier reporting detailed a Sep. 25 emergency software release that introduced fixBatchV1_2 to address security-sensitive issues.

The XRPL Foundation’s version 3.4.1 notice urged operators to upgrade promptly and identified Oct. 9 as the expected activation date for that security amendment, conditional on sustained validator support.

For applications handling completed payments, XRPL’s tutorial warns that a successful outer Batch result does not guarantee that its inner transactions succeeded.

The tutorial instructs developers to inspect the individual transaction results and verify account balances. In its all-or-nothing example, a failed inner payment causes all included payments to fail, while the Batch transaction fee is still deducted.

XRPL lending revision adds defined vault periods

Separate from Batch, XRPL’s LendingProtocolV1_1 amendment adds closed-ended vaults and cash-basis accounting, according to the network’s version 3.4.0 release notes.

A Sep. 18 report on the lending and protocol revisions documented the software release issued on Sep. 16 and explained that distributing the software did not itself activate the amendments.

Under the release’s lending design, vaults have defined subscription, investment, and redemption periods. XRPL’s documentation says depositors can add or withdraw assets during subscription, while the investment period stops deposits and withdrawals as funds become available for loans.

Once the investment period ends, the documentation provides for redemption so depositors can recover their share after loans mature.

For newly created vaults, the proposed accounting rules recognize interest when borrowers pay it, rather than recording all scheduled interest when a loan begins. According to XRPL’s documentation, older vaults retain their existing accounting model after the V1.1 amendment activates.

Evernorth’s Nasdaq plan sets out U.S. shareholder exposure

For U.S. stock-market investors, Evernorth’s planned Nasdaq listing provides a separate XRP-related corporate development documented in an Oct. 6 SEC filing.

An Oct. 7 report covered Evernorth’s revised Nasdaq trading timetable, after the company said an administrative delay had moved its expected XRPN debut from Oct. 8 to Oct. 12.

According to Evernorth, the transaction with Armada Acquisition Corp. II was expected to close on Oct. 9, with trading subject to customary closing conditions and Nasdaq listing requirements.

The company said it expected to hold approximately 473 million XRP at closing. Its Oct. 6 SEC filing also confirmed that Armada shareholders had approved the business combination at their Sep. 30 extraordinary general meeting.