Sherlock Audit Found 96 XRPL Bugs Before Proposed Features Reached Mainnet

Five amendments under review

The audit covered five proposed areas of XRPL functionality: Batch Transactions, Permission Delegation, Multi-Purpose Token DEX integration, Confidential Transfers for MPTs, and Sponsored Fees and Reserves. Sherlock opened the contest on April 13, 2026, giving outside researchers two weeks to test the code across several new transaction and authorization paths.

Ripple described the engagement as one of the larger audit contests of 2026. By the end of the review, 96 submissions were accepted as valid findings, and the company distributed RLUSD-denominated rewards to contributors.

Critical flaw in Batch Transactions

The most severe issue involved the original Batch amendment, which lets up to eight operations execute atomically under one outer transaction. Security researcher Pranamya Keshkamat and Cantina’s AI audit tool Apex independently identified the problem on Feb. 19, 2026, while the feature was still in validator voting.

The flaw was in signature validation. An early-exit condition in the outer transaction checks could have allowed inner transactions to proceed without properly confirming who authorized them. In practical terms, an attacker could have built a batch containing Payment operations from a victim account and drained that account down to its reserve balance without possessing the private key.

RippleX responded with rippled 3.1.1 on Feb. 23, marking the original Batch amendment and its related fixBatchInnerSigs proposal as unsupported so validators could not activate them. A replacement version, BatchV1_1, was later included in xrpld 3.3.0 with the problematic logic removed and additional protections added.

Permission Delegation bug enabled fee draining

The second critical issue affected the original Permission Delegation design. On XRPL, some failed transactions still consume a fee if they fail at a later processing stage with a tec-class error, while earlier failures do not.

In the original implementation, the system checked whether a delegate had the required permission before verifying the transaction signature. That ordering meant an attacker could repeatedly submit invalid offline-signed transactions with elevated fees against a delegated account. Even though the transactions would fail, the victim account could still be charged each time.

The fix changed both the order of checks and the error handling. Signature verification now happens before fee-charging conditions are reached, and the relevant error was reclassified from tec to ter. The revised amendment, PermissionDelegationV1_1, shipped with a default No setting, meaning validators must actively support it before activation.

Release now, activate later

xrpld 3.3.0 was published on Aug. 6 with code for the proposed amendments present but not live. Under XRPL’s amendment process, a feature still needs more than 80% validator support for two straight weeks before activation.

That separation between shipping code and enabling functionality created a review window in which bugs could be found and fixed before user funds were exposed. According to the source material, no funds were lost because the Batch issue was caught during validator voting and the Permission Delegation flaw was patched before activation.

The broader backdrop remains a crypto sector where exploits are still frequent. The source article notes that DeFi losses topped $840 million across more than 50 incidents in the first five months of 2026, up 70% year over year, and says 70% of exploited contracts had been audited but lacked post-deployment monitoring.

What happens next

The immediate next step is validator voting on the amendments included with version 3.3.0, particularly BatchV1_1 and PermissionDelegationV1_1. Neither of the rewritten features was activated on mainnet when the release shipped.

Whether those proposals clear the 80% threshold and whether any further bugs emerge after activation will be the clearest confirmed tests of the audit-before-release approach highlighted by this contest. For now, the known vulnerabilities were addressed before the affected features reached live wallets.