NewsCryptoSherlock Audit Uncovered 96 Bugs in XRP Ledger Code Before Release

Sherlock Audit Uncovered 96 Bugs in XRP Ledger Code Before Release

Author: CoinLineup·

Key Takeaways

  • Sherlock’s competitive audit identified 96 bugs in the XRP Ledger codebase before the release shipped to users.
  • The review targeted rippled, the open-source server software that underpins the XRP Ledger network.
  • The audited release was tied to the rippled 3.3.0 update documented in the network’s changelog.
  • XRP Ledger’s operations team referenced the audit on X as part of the release process, not as a response to an incident.
  • The available reporting did not specify severity levels or how each issue was resolved.
Sherlock Audit Uncovered 96 Bugs in XRP Ledger Code Before Release

A Sherlock security audit identified 96 bugs in XRP Ledger code before the release reached users, marking one of the more substantial pre-deployment reviews reported for the network's software.

What the Sherlock audit found

The audit was run through Sherlock's competitive review platform, which hosted the contest covering the XRP Ledger codebase. Under this model, independent security researchers examine a codebase during a defined review window, with issues flagged before the code ships. The review targeted the ledger's core software rather than a single application. That core is rippled, the open-source server implementation, written primarily in C++, that validators and other servers run to operate the network, which places flagged issues closer to the ledger's foundation than bugs confined to one application or wallet.

Contest-driven reviews of this type, where independent researchers compete for payouts on verified findings, have become a fixture of smart-contract security through platforms such as Sherlock and Code4rena. Running one against a major ledger's node software extends the same model deeper into the stack, from application-level contracts to the code that processes every transaction.

According to reporting, the process surfaced 96 bugs before the code shipped to a single wallet. The figure refers to issues flagged during the review window, not confirmed exploits in production.

The release tied to this cycle is documented in the network's own changelog for the rippled 3.3.0 update, the version that sits at the center of the audited work.

Why finding the bugs before release matters

Catching flaws before deployment means they can be addressed while the code is still in review, rather than after it is running live on validators and in user wallets. That timing is the core value of a pre-release audit.

For a settlement-focused ledger, pre-release discovery lowers the risk that a defect reaches production, where funds, transaction processing, or consensus behavior could be affected. The audit functions as a filter between development and live use. The stakes are particular to infrastructure of this kind: the XRP Ledger confirms payments through an agreement process among its validator set rather than proof-of-work mining, so defects touching transaction handling or consensus sit in the layer every user of the network depends on.

The XRP Ledger operations team pointed to the review through its official channel on X, underscoring that the audit was part of the release process rather than a response to an incident.

What this means for XRP Ledger oversight going forward

Bringing in an external, third-party review adds a layer of scrutiny beyond internal testing, and the reported bug count shows such reviews still surface a meaningful volume of issues even on established infrastructure.

External audits have become a routine trust signal across crypto, similar to how reserve attestations shaped the debate around stablecoin backing when Tether's Big Four audit reported reserves exceeding liabilities. Code review and financial attestation both aim at the same goal: verifiable assurance for users.

That assurance question extends to wallet-level safeguards as well, an area highlighted recently when CyberWallet and Passkey users faced a withdrawal cutoff. Release readiness at the protocol layer and reliability at the wallet layer together determine how much users can depend on a network.

The details of severity tiers and how each issue was resolved were not established in the available reporting, so the significance here rests on the scale of the review and its pre-release timing rather than the specific nature of individual bugs. The signals to watch from here are whether a severity breakdown and remediation notes accompany the release documentation, and whether third-party contests recur as a standing part of XRPL release cycles.

Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Cryptocurrency and digital asset markets carry significant risk. Always do your own research before making decisions.