A security flaw in a proposed XRP Ledger (XRPL) upgrade could have enabled unauthorized transactions, but researchers flagged the issue before it could reach the blockchain’s main network.
The XRPL Foundation said Feb. 26 that the vulnerability was found in the proposed “Batch” amendment, a feature intended to let users bundle multiple actions into a single atomic transaction.
Security researcher Pranamya Keshkamat and Cantina AI’s autonomous static-analysis tool, Apex, reported the issue Feb. 19, according to the foundation.
If the amendment had been activated with the bug in place, an attacker could have executed inner transactions as if they were authorized by another account, without access to that user’s private keys.
That could have enabled unauthorized fund transfers and changes to ledger settings under a victim’s account, even though the victim did not sign the transaction.
The disclosure comes as XRPL has been positioning itself for use cases such as tokenization and other compliance-sensitive activities, where perceived security and reliability are central to institutional adoption.
Understanding XRPL’s critical Batch amendment security flaw
The proposed Batch amendment changed how authorization would work on the XRP Ledger by allowing multiple “inner” transactions to be bundled into a single “outer” Batch transaction, so that all steps either succeed or fail together.
That atomic structure can reduce execution risk for developers running multi-step operations. It also creates a new authorization boundary.
In the Batch design, inner transactions are intentionally unsigned. Instead, authority is delegated to a list of batch signers attached to the outer transaction, making the signer-validation code a critical control point.
If those checks fail, the ledger can treat unauthorized actions as valid.
The disclosure said the bug stemmed from a loop error in the function that validates batch signers.
When the code encountered a signer whose account did not yet exist on the ledger and whose signing key matched that same account, a normal state for a newly created account, it returned success immediately and stopped checking the rest of the signer list.
That condition was more dangerous in a batching system than it sounds. A batch can include steps that create accounts inside the same atomic sequence, meaning whether an account exists at validation time becomes part of the authorization boundary.
The report said an attacker could have inserted a valid signer entry for a not-yet-created account they controlled, triggered the premature-success condition, and bypassed validation of a forged signer entry claiming to authorize a victim account.
If Batch had activated before the flaw was caught, the consequences could have been serious.
The Foundation said an attacker could have executed inner Payment transactions that drained victim accounts down to the reserve. The same bug could also have enabled unauthorized account-level operations, including AccountSet, TrustSet, and potentially AccountDelete.
That would have amounted to a “spend without keys” scenario, the kind of security failure that can cause reputational damage even if losses are limited and addressed quickly.
The flaw could have shattered XRPL’s security veneer
The flaw could have damaged XRPL’s security narrative at a sensitive time for the network, which is aggressively expanding into real-world asset (RWA) tokenization and institutional DeFi.
Data from DeFiLlama shows that XRPL has around $50 million in total DeFi values locked on the platform, with nearly $2 billion in RWA assets.
In crypto markets, authorization failures often shape perception long after the underlying technical issue is resolved.
For a ledger positioning itself as infrastructure for regulated finance, such an incident would have carried broader implications.
This is especially true considering XRPL recently introduced a new set of institution-focused features, including Permissioned Domains and DEXs.
These features are designed to create gated trading venues where only approved participants can place and take orders. The model is aimed at institutions that want blockchain-based settlement without open access to all counterparties.
Thus, the security issue would have undermined that message. A network cannot easily be market-controlled or compliance-focused in on-chain environments, while a proposed transaction upgrade carries the risk of unauthorized actions involving arbitrary accounts.
How XRPL averted the security incident
XRPL’s response moved through governance and software channels quickly.
The unique Node List (UNL) of trusted validators was contacted and advised to vote “No” on the Batch amendment.
On Feb. 23, XRPL published rippled 3.1.1, an emergency release that marks both Batch and fixBatchInnerSigs as unsupported. That prevented the amendments from receiving validator votes or being activated on the network.
The release was designed as immediate containment, not a full repair. The disclosure explicitly stated that the 3.1.1 release does not include the underlying logic fix.
XRPL also scheduled a devnet reset for March 3, 2026, to coincide with the 3.1.1 change. That reset applies to Devnet only, not mainnet, but it shows the extent to which the network’s operators moved to keep the problem from affecting active amendment paths.
A corrected replacement, BatchV1_1, has already been implemented and is under review, with no release date set.
According to the disclosure, the full fix removes the early exit, adds extra authorization guards, and narrows the scope of the signing check.
The report also laid out a broader security roadmap, including more standardized AI-assisted audits, expanded static-analysis checks for dangerous loop exits, and a review of similar patterns elsewhere in the codebase.
The next test is shipping the replacement safely
For XRPL, February’s outcome will count as a governance success. The bug was found before activation. Validators coordinated. An emergency release blocked the amendment path. No funds were lost.
But the story does not end there.
BatchV1_1 will now be judged on two levels. The first is technical, whether it delivers the developer benefits of atomic transaction bundling without reopening authorization risk.
The second is procedural, whether XRPL’s governance and engineering systems can keep pace with an expanding feature set aimed at institutional adoption.
That is the real backdrop to this near-miss. XRPL is trying to grow into a broader financial platform, one that can host gated trading venues, permissioned environments, and more sophisticated transaction logic, while also attracting builders with ecosystem capital and product breadth.
The more ambitious that roadmap becomes, the more important boring things like signer validation and loop behavior become.
In this case, the brakes worked. The next challenge is to prove the system can accelerate again without losing that margin of safety.
