At 1:30 p.m. UTC on Feb. 21, 2025, Bybit began moving funds from an Ethereum cold wallet to a warm wallet, the sort of routine transfer designed to make custody look boring. Authorized signers reviewed the destination on their screens and approved it, unaware that their screens were actually lying.
Bybit later said the signing interface had been manipulated so that the signers saw the address they expected while the transaction underneath gave an attacker control of the wallet. The exchange’s account of the incident put the loss at $1.46 billion, and the FBI attributed the theft to North Korea.
CryptoSlate reported at the time that the attackers took roughly 401,347 ETH along with several staked Ethereum assets.
Safe said a compromised developer machine enabled a disguised malicious transaction and that external researchers found no vulnerability in Safe’s smart contracts or the source code for its front end and services. The private keys didn’t need to leave their devices because valid signatures were enough once the humans producing them had been shown a false description of what they were authorizing, the same separation between key security and transaction intent that CryptoSlate examined earlier this year.
Every line of the relevant contracts could be reviewed, but a human still had to decide what the screen meant. And it’s that distance between code and intent where crypto’s most reassuring security word begins to fall apart.
The badge became a warranty
The term “Audited” appears on protocol websites as a badge, usually beside a security firm’s logo and a link to a PDF. Users can reasonably read that badge as shorthand for safe funds, competent operators, and software that has been checked from end to end. The engagement behind it may have covered several files from one repository during one week.
Think of a building owner hiring an electrician to inspect the breaker box, then advertising the certificate as proof that the whole property is burglar-proof. The electrician may have done excellent work, and the certificate has been promoted into a promise about doors, alarms, and guards that the electrician was never paid to inspect.
Smart-contract auditors tend to describe their assignments with far more precision than the projects marketing them. An OpenZeppelin report, for example, identifies four pull requests by commit hash, names the contracts included and records a three-day review period. A commit hash is essentially the fingerprint of one code snapshot; once the code moves on, the report doesn’t automatically move with it.
Later edits and the configuration used in production may receive separate testing. An employee’s laptop or cloud account belongs to another layer; signing devices and the interface explaining a transaction require their own review. The arrangement is normal professional practice because a finite engagement needs a finite perimeter.
The distortion begins when a carefully limited report reaches a project website and becomes a general claim about the organization operating the code.
A June preprint by Oak Security’s Stefan Beyer gives that gap a very large set of numbers. Beyer examined 23,818 public findings from 22 security firms, then compared them with 218 incidents cataloged by rekt.news between Jan. 1, 2022, and March 27, 2026. Those incidents produced an estimated $7.764 billion in losses.
The audit findings look exactly like the output of people hired to inspect code. Logic and business-logic defects made up 14.6% of the total, and code-quality problems accounted for 13%. Input-validation flaws contributed 10%, with access-control issues close behind at 9.8%. Around one in six findings was rated critical or high, giving the dataset 1,439 critical issues and 2,659 high-severity ones.
An audit finding describes a defect found during a review; an exploit loss records a successful theft from a live system. Many findings were fixed before deployment, while some vulnerable code never even reached production. The two datasets describe different populations, so their percentages aren’t conversion rates.
What audits find, and where the money goes
| Rank | Most common audit findings | Largest sources of exploit losses |
|---|---|---|
| 1 | Logic and business logic: 14.6% | Private-key compromise: $1.894 billion / 24.4% |
| 2 | Code quality: 13.0% | Phishing and social engineering: $1.511 billion / 19.5% |
| 3 | Input validation: 10.0% | Access-control failures: $994 million / 12.8% |
| 4 | Access control and authorization: 9.8% | Oracle and price manipulation: $666 million / 8.6% |
The rankings describe different populations and aren’t row-by-row equivalents. The audit side counts 23,818 findings; the loss side covers $7.764 billion stolen across 218 incidents from January 2022 through March 2026. Source: The Audit Gap in Blockchain Security.
Placed next to each other, the rankings show the gap. The three leading audit categories account for 37.6% of published findings, while private-key theft and phishing, both largely outside conventional contract review, account for 43.9% of stolen value.
Adding dependency and governance attacks takes the paper’s “human-vector” category to 49.6% of losses. Those failures begin in people, operations, and third-party systems that a standard code review wasn’t hired to inspect.
That 49.6% number needs a warning label of its own. Bybit supplied $1.43 billion of the $1.51 billion phishing total and 18.4% of every dollar in the incident dataset. Eight incidents produced half of all losses, leaving the other 210 to share the remainder.
Crypto theft is a market of catastrophic outliers, which means one enormous event can rearrange an entire category.
Nonetheless, the broader pattern extends beyond Bybit. Private-key compromise appeared across 45 incidents, making it the most expensive root cause even before phishing entered the calculation.
From 2023 through 2025, attacks involving keys, people, dependencies, or governance absorbed between roughly two-thirds and three-quarters of the value lost each year. Attackers had learned to go around the code while the industry concentrated its professional effort on examining it.
Attackers audit the organization
A smart contract is one room in a huge house. Users reach it through a website and wallet, and the contract may depend on outside price data before it can act. Multisig procedures govern sensitive transfers; admin permissions decide who can alter the software.
Users experience that entire structure as one product. Attackers, however, see a collection of doors, each guarded by different people and different software.
Bybit’s onchain components carried out a properly signed transaction. The failure began on a developer machine that shaped the proposal, then passed through an interface that told the signers they were approving something routine. Safe rebuilt its infrastructure, rotated credentials, and committed to making transactions easier to verify. Those were operational and interface repairs for an event that valid onchain code had faithfully executed.
The preprint found that 105 of the 218 incidents involved a protocol with at least one public audit before the event. They represented about $4.3 billion, or 55% of observed losses, a statistic practically engineered for misuse.
It doesn’t establish that auditors missed $4.3 billion of exploitable code. “Previously audited” can describe another version, another set of contracts, or a review unrelated to the eventual route into the system.
Nine of the 12 largest cases in that group came through phishing, stolen keys, dependencies, infrastructure, or governance. The code-driven cases also resist the easy verdict. For Nomad, Euler and others, the paper found later code, excluded paths or other differences between the reviewed material and the software that eventually held funds. Calling all of this an audit failure would make the same scope error the paper is trying to expose.
The research also needs a skeptical interpretation because it’s a preprint written by someone inside the audit industry. Its 22 firms are unnamed, which blocks firm-level checks, and the incident set comes from one publisher’s archive. PDF extraction makes things even murkier, and part of the classification was done with an LLM under human oversight.
The paper also lacks a matched population of unaudited protocols, which makes it impossible to calculate how much protection an audit provided. Valuable projects tend to buy more audits and attract more capable attackers, so their presence on both sides of the dataset tells us absolutely nothing about cause and effect.
The paper’s strongest claim is about language. Crypto has become good at commissioning one type of inspection and bad at telling users where that inspection ends. An audit firm can review contracts competently, and a custody vendor can secure keys exactly as promised. Cloud providers, monitoring companies and bug-bounty platforms can all deliver their assigned pieces while the full path from a developer’s laptop to a signer’s screen and finally to the deployed code goes untested.
Some technical documentation already assigns that responsibility to the project. Chainlink’s shared-accountability model puts code and imported packages on developers, then gives them responsibility for configuration, monitoring, and communication with users.
The fine print understands that an application owns the combined system, even when public-facing audit language still treats security as a certificate attached to a repository.
Replace the “audited” badge with a nutrition label
The audit badge needs to become less eloquent and more factual. A standardized security label would make the missing work visible, especially when a project has paid for contract review and skipped everything surrounding it.
The top section should identify the audited commit and review dates, then name the included contracts and any unresolved critical or high findings. Another section should state whether the deployed bytecode matches the reviewed version. Production configuration needs its own verification date, so a user can tell whether the report applies to the software holding funds today.
Key management and signer procedures deserve a separate assessment, and front-end infrastructure and cloud access need another. Build systems should show whether releases can be altered by one compromised machine. Monitoring and incident exercises should carry dates because both decay as staff, vendors, and software evolve. A material release would expire the relevant entries until they were tested again.
That format would help auditors as much as it would help users. A project could say its smart contracts were audited while also disclosing that production deployment wasn’t verified and signer security wasn’t reviewed. The auditor would no longer inherit a promise its contract rejected, and the project would have a public incentive to commission the missing work.
Bybit had enough money to absorb the lesson without hurting too many of its users. CryptoSlate reported that the exchange restored its ETH backing within days. But most protocols can’t find $1.46 billion when the screen and the transaction disagree, and replenishing reserves repairs the balance sheet rather than the approval process that emptied it.
The next “audited” badge beneath a token launch or beside a deposit button should come with a precise description of what was reviewed, what was excluded, and how long the work still applies. The word should describe the inspection that took place and name every major system left beyond it, instead of serving as a promise no professional was hired to make.
Be the first to comment