Ripple’s Sherlock audit found 96 bugs before they reached a single wallet

A $550,000 community audit contest uncovered two critical vulnerabilities in $XRP Ledger features that could have drained user accounts without private keys. The findings reveal how Ripple’s audit-before-release model diverges sharply from the broader crypto industry’s patch-after-exploit norm.

$XRP Ledger version 3.3.0 shipped on August 6, 2026, carrying five proposed amendments and a bundled cleanup patch. On paper it looked like a routine infrastructure release. Underneath, the update represented the conclusion of a six-month security gauntlet that caught two account-draining bugs, rewrote two entire feature implementations from scratch, and paid hundreds of thousands of dollars to outside researchers who found problems the internal team had missed. The process raises a pointed question for the wider blockchain industry: if Ripple can catch critical flaws before deployment, why does so much of crypto still treat security audits as a post-launch checkbox?

This piece breaks down what the two critical vulnerabilities actually were at a technical level, examines how the audit-vote-activate pipeline compares to competing chains’ security models, and assesses whether the findings strengthen or undermine the case for XRPL as institutional-grade infrastructure.

What the Sherlock contest actually found

The scope covered five pillars of upcoming XRPL functionality: Batch Transactions, Permission Delegation, Multi-Purpose Token (MPT) DEX integration, Confidential Transfers for MPTs, and Sponsored Fees and Reserves. Sherlock, a Web3 security firm that ranks researchers by performance and structures engagements as adversarial contests, opened the audit on April 13, 2026, with a $550,000 $RLUSD prize pool. The contest page on Sherlock’s platform listed the engagement as “$XRP Ledger – April 2026 Contest – 550,000 $RLUSD,” signaling that Ripple paid the bounties in its own stablecoin.

Over two weeks, participants submitted reports that surfaced 96 valid findings: 2 critical, 6 high, 29 medium, and 59 low-severity issues. Ripple distributed $309,000 in $RLUSD to contributors. The remaining pool covered Sherlock’s operational costs and lower-tier findings that did not meet the payout threshold.

The contest marked the first formal collaboration between Sherlock and Ripple, and it arrived at a moment when the $XRP Ledger’s feature pipeline was expanding faster than at any point in its history. Five amendments shipping simultaneously meant five distinct attack surfaces, each with its own transaction logic, authorization model, and cryptographic requirements. For context, Sherlock’s audit contest model has previously been used by protocols including Aave, Euler, and Olympus DAO, but an engagement covering C++ protocol-level code for a layer-one blockchain was atypical for a platform more commonly associated with Solidity smart contracts.

The severity distribution itself tells a story. The 29 medium-severity findings suggest a category of bugs that would not individually compromise accounts but could create unexpected behavior under specific transaction sequences. The 59 low-severity issues likely include code quality concerns, documentation gaps, and edge cases that could compound under adversarial conditions. The two critical and six high-severity bugs, however, represented exploitable vulnerabilities that warranted immediate remediation.

The Batch amendment bug that could have emptied accounts

The most dangerous vulnerability predated the Sherlock contest by two months. On February 19, 2026, security researcher Pranamya Keshkamat and Cantina’s autonomous AI audit tool Apex independently identified a signature-validation flaw in the original Batch amendment while it was still in its validator voting phase.

The technical failure was precise. Batch Transactions allow up to eight operations to execute atomically under a single outer transaction. The outer transaction’s signature-validation code contained an early-exit condition that could be satisfied without properly verifying who was authorizing the inner transactions. In practice, an attacker could have constructed a Batch transaction containing inner Payment operations targeting a victim account, draining it down to its reserve balance, without ever holding that account’s private keys. The same logic gap would have permitted unauthorized AccountSet, TrustSet, or AccountDelete operations.

The vulnerability disclosure report published on xrpl.org detailed the mechanics: the signer check in the outer transaction could pass without confirming that the entity submitting the batch actually controlled the accounts referenced in the inner transactions. This meant that the atomicity feature designed to improve user experience could have been weaponized to empty any account on the network in a single transaction.

RippleX responded with an emergency release. Rippled version 3.1.1, published on February 23, 2026, four days after discovery, marked both the original Batch amendment and its companion fixBatchInnerSigs as unsupported, preventing validators from voting on or activating them. No funds were lost because the amendment had not yet cleared the 80% validator threshold required for activation. The replacement, BatchV1_1, shipped in version 3.3.0 with the early-exit condition removed, additional authorization guards added, and the signing check scope tightened to verify each inner transaction against the correct signer independently.

Permission Delegation’s silent fee-drain exploit

The second critical vulnerability operated through a subtler mechanism. A September 2025 disclosure documented how the original Permission Delegation implementation allowed an attacker to silently bleed a victim account’s $XRP balance without accessing its keys.

The exploit relied on a design feature of the $XRP Ledger’s transaction processing that has existed since the network’s earliest days. On XRPL, a transaction that fails with a “tec”-class error still incurs a fee charge, while errors caught earlier in the pipeline, before signature verification, do not. This distinction exists because tec-class failures indicate transactions that were properly formed and signed but failed for business-logic reasons, and the fee prevents spam. Permission Delegation’s original code checked whether a delegate account held the relevant permission before it verified the transaction’s signature. An attacker could repeatedly submit invalid offline-signed transactions with elevated fees against a delegated account, and each failed transaction would still deduct the fee from the victim’s balance.

The economic impact would have compounded quickly. Because the attacker could set arbitrarily high fees on these transactions, a sustained attack could drain an account far faster than normal transaction fees would suggest. The victim would see their balance declining with no corresponding outbound payments, making the attack difficult to diagnose without examining raw transaction metadata.

The fix reclassified the relevant error from tec to ter and reordered the checks so that no fee can be deducted before signature verification passes. The replacement amendment, PermissionDelegationV1_1, carries a default “No” designation in the 3.3.0 registry, meaning validators must actively vote to enable it. This conservative default reflects the sensitivity of the original flaw: even after the rewrite, Ripple chose to require explicit validator opt-in for the feature.

Why both rewrites shipped in a single release

Packaging two security-rewritten amendments alongside three entirely new features in one version was a deliberate choice. RippleX published xrpld 3.3.0 on August 6, 2026, with the code for all six proposals (including a bundled cleanup amendment called fixCleanup3_3_0) present but none of them activated. Under the $XRP Ledger’s amendment process, each proposal must sustain more than 80% validator support for two consecutive weeks before going live.

This separation between code availability and feature activation is a structural advantage that most smart-contract platforms lack. On Ethereum, a deployed contract is live the moment it hits the blockchain. On XRPL, code can ship, undergo further review during the voting window, and still be blocked if validators lose confidence. The Batch and Permission Delegation rewrites had already survived the Sherlock contest, a Halborn re-audit that found zero critical or high-risk issues, and months of internal testing. The voting period adds yet another layer of defense before any code touches real funds.

The version also retired five legacy amendments, including Clawback, fixDisallowIncomingV1, fixInnerObjTemplate, fixNFTokenReserve, and fixUniversalNumber, removing dead code paths that could otherwise accumulate as latent attack surface over time.

The five feature amendments in 3.3.0 represent the broadest single expansion of XRPL capabilities to date. Confidential Transfers bring EC-ElGamal encryption and zero-knowledge proofs to Multi-Purpose Tokens, shielding individual balances and transfer amounts from public view while preserving compliance access for authorized parties. Sponsored Fees allow applications to cover network costs on behalf of users, addressing the onboarding friction that has kept consumer-facing applications off decentralized networks. DynamicMPT lets issuers modify token properties after creation, supporting evolving regulatory and business requirements. Together with the Batch and Permission Delegation rewrites, these features target a specific audience: regulated financial institutions that need privacy, atomic settlement, and delegated operations without sacrificing auditability.

Audit before release versus patch after exploit

The contrast between Ripple’s approach and the broader industry’s security track record is stark. DeFi exploits exceeded $840 million across more than 50 incidents in the first five months of 2026, a 70% year-over-year increase over the same period in 2025. North Korea-linked actors accounted for 76% of global crypto hack losses in the first four months of the year. And the most damning statistic: 70% of exploited contracts had been audited but lacked any form of post-deployment monitoring. Only 4% of tracked projects combined audits, active bug bounties, and third-party monitoring controls together.

The Ethereum ecosystem, home to the largest concentration of smart-contract value, operates under a fundamentally different security model. Contracts deploy to mainnet through an immutable transaction. If a vulnerability surfaces afterward, the options are limited: deploy a new contract and migrate users, implement a proxy upgrade pattern that introduces its own attack surface, or accept the risk. The Wormhole bridge hack of 2022 cost $320 million because a deprecated verification function remained in production code. Ronin’s August 2024 exploit cost $12 million because a contract upgrade failed to initialize operator weights correctly. In both cases, audits had been performed; the failures happened after deployment.

The KelpDAO hack on April 18, 2026, which drained approximately $293 million, was the largest single DeFi exploit of the year. The Drift Protocol exploit on Solana on April 1, which cost roughly $286 million, was the largest ever recorded on that chain. These figures are not fringe events. They represent the baseline failure rate of an industry that has collectively lost $16.69 billion to hacks, bridge exploits, and security incidents according to DeFiLlama data.

XRPL’s amendment voting process inverts this sequence. Code ships in a release, but features remain dormant until validators approve them. During the voting window, researchers, node operators, and competing auditors can examine the live codebase with full context. If a problem surfaces, validators simply withhold their votes. No emergency patch, no migration, no proxy contract. The February 2026 Batch bug followed exactly this path: the amendment was in its voting phase, the vulnerability was identified, and an emergency release prevented activation. Zero funds at risk, zero user impact.

This is not to say that the XRPL model is flawless. The amendment process works for protocol-level features but does not extend to applications built on top of the ledger. A poorly coded trust line or MPT integration could still lose funds. And the 80% validator threshold creates its own risks: if too few validators upgrade to a new version, legitimate security patches can stall. But for core protocol changes, the audit-vote-activate pipeline represents a materially different security posture than deploy-and-hope.

What this means for XRPL’s institutional pitch

Ripple has spent 2026 building an institutional infrastructure stack at an aggressive pace. The $1.25 billion acquisition of Hidden Road, a multi-asset prime broker rebranded as Ripple Prime, gave the company a regulated on-ramp for traditional finance. $RLUSD reached a $1.72 billion market capitalization in under a year and moved more than $18 billion in transaction volume during Q1 alone. Goldman Sachs disclosed a $153.8 million position across four $XRP ETFs. Ripple secured a full Electronic Money Institution license from Luxembourg in February, UK Financial Conduct Authority permissions in January, and a MiCA Crypto-Asset Service Provider license on July 6.

The institutional DeFi features arriving in version 3.3.0 are the technical counterpart to this business development push. Confidential Transfers address the privacy requirements of banks that cannot expose transaction details on a public ledger. Sponsored Fees solve the onboarding friction that has kept retail banking applications off decentralized networks. Permission Delegation, once its rewrite clears the voting process, enables the kind of controlled access models that compliance departments require.

But institutional adoption depends on trust, and trust in blockchain infrastructure ultimately comes down to security track record. The fact that Ripple caught two critical bugs, rewrote two entire feature implementations, paid outside researchers $309,000 to find problems, and still delivered all five features on schedule is a stronger institutional selling point than any individual feature. It suggests a security culture where finding bugs is rewarded and where shipping is subordinate to verification.

Over 300 financial institutions across 55 countries currently use RippleNet, with active On-Demand Liquidity corridors in more than 70 markets. For those institutions, the Sherlock audit results are not abstract. They are evidence that the code running their cross-border payments has been stress-tested by adversarial researchers with financial incentives to break it. Ripple’s four-phase quantum-resistance roadmap, targeting completion by 2028, further signals that the company is engineering for institutional time horizons measured in decades, not deployment cycles.

The opposing case: why skeptics are not convinced

The strongest argument against reading too much into the Sherlock audit runs in two directions.

First, finding 96 bugs before release can be framed as evidence of thorough testing or evidence of sloppy development. Both the Batch and Permission Delegation vulnerabilities were in the original implementations, meaning they cleared internal review before external researchers caught them. The February 2026 Batch bug was not identified by Ripple’s own team but by an independent researcher and an AI tool. If external auditors are the primary safety net, the internal development process may have quality gaps that will eventually produce a vulnerability that no external reviewer catches in time.

Second, the XRPL amendment model’s strength, the ability to prevent activation during the voting window, is also a speed constraint. Ethereum’s willingness to deploy and iterate has enabled a pace of innovation that XRPL cannot match. The five amendments in version 3.3.0 have been in development and review cycles for months. The original Batch amendment was proposed in 2025. For protocols competing for developer attention in fast-moving markets, a six-month security pipeline may be too slow to attract the builder ecosystem that drives network effects.

There is also a concentration risk in the validator set. The 80% activation threshold means that a relatively small number of validators, many of which are operated by entities with close ties to Ripple, control whether amendments go live. Critics argue this is not truly decentralized governance but a curated approval process dressed in consensus language. When Ripple’s own validator voted “yes” on lending amendments in recent weeks, it underscored how much influence the company retains over its nominally decentralized network.

Finally, the $309,000 payout from a $550,000 pool raises a practical question about incentive alignment. Top-tier security researchers command rates that exceed what contest models typically pay per hour of effort. If the most skilled auditors skip XRPL contests because the expected payout per finding is lower than private engagements, the adversarial review may be broad but not deep enough to catch the most sophisticated attack vectors.

These objections have weight. $XRP traded near $1.03 in late July 2026, roughly 71% below its $3.65 cycle high set on July 17, 2025, suggesting the market has not yet priced in the institutional narrative. Whether the security track record translates into adoption depends on factors beyond code quality: regulatory clarity, competitive positioning against Ethereum layer-2 solutions, and whether institutions care more about pre-deployment audits than they do about ecosystem size.

What to watch

– **Validator voting thresholds for the five 3.3.0 amendments**: if BatchV1_1 and PermissionDelegationV1_1 clear 80% support within the first voting cycle, it signals validator confidence in the rewrites. A stall would suggest lingering concerns about the rewritten code.

– **Post-activation bug reports**: the real test of the Sherlock audit’s thoroughness comes after features go live. Zero critical findings in the first 90 days would validate the pre-release model; any post-activation vulnerability would undermine the entire thesis.

– **$RLUSD adoption on Confidential Transfers**: institutional stablecoin usage on shielded rails would confirm demand for privacy-compliant settlement. Volume metrics in the first quarter after activation will be the clearest signal of whether banks are ready to transact on a public ledger with privacy guarantees.

– **Sherlock’s next XRPL engagement**: whether Ripple continues with adversarial audit contests for future amendments or reverts to traditional private audits will indicate how deeply the pre-release model is embedded in the development culture.

– **Competing chain security incidents**: every major exploit on Ethereum or Solana that traces back to a post-deployment vulnerability strengthens the case for XRPL’s audit-vote-activate pipeline. The comparison is only as strong as the industry’s continued failure to adopt similar processes.