XRPL Bug In Batch Feature Could Have Enabled Unsigned Fund Drains

TLDR

Table of Contents

XRPL found a signer validation bug in the proposed Batch amendment.
The flaw could allow inner transactions without victim signatures.
Validators voted no and rippled 3.1.1 blocked activation.
A corrected BatchV1_1 version is under review with added checks.

XRP Ledger nearly shipped a feature that could drain accounts without owners signing, but researchers identified the flaw before activation.

The issue was found in the proposed Batch amendment, which aimed to bundle multiple actions into one atomic transaction. Security researcher Pranamya Keshkamat and Cantina AI’s tool Apex reported the bug on Feb. 19. The XRPL Foundation disclosed the issue on Feb. 26 and confirmed that the feature did not reach mainnet.

Batch amendment introduced new authorization path

The Batch amendment was designed to allow users to combine several “inner” transactions into one “outer” transaction. All actions would succeed or fail together. This atomic structure was meant to reduce execution risk during multi-step operations.

Under the design, inner transactions were unsigned. Authority was delegated to a list of signers attached to the outer Batch transaction. This made signer validation a key control point in the system.

🚨SCARY: XRPL was one vote away from disaster.

A critical logic flaw in the Batch upgrade could’ve let attackers move funds without private keys.

If it activated, wallets could’ve been drained. It was caught just in time. pic.twitter.com/SAq849WMu5

— STEPH IS CRYPTO (@Steph_iscrypto) February 28, 2026

The flaw came from a loop error in the signer validation function. When the code encountered a signer account that did not yet exist on the ledger, it returned success early. It then stopped checking the remaining signers in the list.

That condition created risk because a Batch transaction can include steps that create new accounts. An attacker could add a valid signer entry for a not-yet-created account they controlled. The premature success would bypass checks for other forged signer entries.

Risk of unauthorized payments and account changes

If activated, the flaw could allow inner transactions to execute without proper authorization. According to the disclosure, attackers could perform Payment transactions from victim accounts. Funds could be drained down to the reserve balance.

The bug could also affect account-level operations. These include AccountSet, TrustSet, and possibly AccountDelete actions. Such actions could change account settings or trust lines without the owner’s approval.

The scenario represented a spend without keys condition. That means transactions could occur without the account holder’s private key signature. No funds were lost because the amendment was not activated.

XRPL has been expanding into tokenization and institutional decentralized finance. Data from DeFiLlama shows around $50 million in total value locked on XRPL. It also shows nearly $2 billion in tokenized real-world assets on the network.

Emergency release blocked amendment activation

After receiving the report, the XRPL Foundation contacted validators on the Unique Node List. Validators were advised to vote “No” on the Batch amendment. This prevented the feature from gaining approval.

On Feb. 23, XRPL released rippled 3.1.1 as an emergency update. The release marked both Batch and fixBatchInnerSigs as unsupported. As a result, the amendments could not receive validator votes.

The foundation stated that version 3.1.1 did not include the full logic fix. Instead, it acted as a containment measure. A devnet reset was scheduled for March 3, 2026, to align with the changes.

Replacement version under review

A revised version called BatchV1_1 has been implemented and is under review. The updated code removes the early exit in signer validation. It also adds extra authorization checks and narrows the signing scope.

The foundation reported plans for expanded static analysis and AI-assisted audits. It also noted a review of similar code patterns across the codebase.

The Batch feature was intended to support complex transaction flows. These flows are often required in tokenization and permissioned environments. The network’s response prevented the flawed feature from reaching production.

✨ Limited Time Offer