TL;DR

  • A small set of recurring classes accounts for most contract-layer losses: reentrancy, oracle manipulation, access control failures, arithmetic and validation errors, and flawed business logic that works exactly as written. Every class has a famous corpse attached, which is how the industry learned to name them.
  • An audit examines a frozen snapshot of code against known vulnerability classes and the team's stated intentions, within a budget of expert hours; nearly everything else, economics, oracles, governance, operations, dependencies, the future, sits outside the frame. Reading an audit report's scope section is more informative than reading its badge.
  • Because the loss distribution follows what audits leave out: post-audit changes, excluded components, cross-protocol interactions, compromised operations and economic design, on top of the residual bugs sampling inevitably misses. The audited-and-hacked list is long enough to be a genre.
  • Layered and assuming failure: multiple independent reviews, formal methods and fuzzing where they bite, continuous monitoring, economic circuit breakers, timelocked changes, bug bounties, and a rehearsed plan for the day something gets through. Each layer catches a different miss profile, which is the whole point of layering.
In one block

A smart contract audit is a structured expert review of contract code that hunts for known vulnerability classes, deviations from specification and dangerous patterns before deployment. It is a point-in-time assessment of one code version under stated assumptions.

What actually breaks in smart contracts?

Quick answer

A small set of recurring classes accounts for most contract-layer losses: reentrancy, oracle manipulation, access control failures, arithmetic and validation errors, and flawed business logic that works exactly as written. Every class has a famous corpse attached, which is how the industry learned to name them.

Reentrancy is the classic. A contract sends value to an external address before updating its own state, and the recipient, being a contract, calls back in before the update lands, draining in a loop. The DAO hack of 2016, around 60 million dollars at the time, established the class and split Ethereum in two. A decade later reentrancy still appears, sometimes in exotic forms: the 2023 Curve incident, roughly 70 million dollars across pools, arose from a reentrancy guard failure inside specific versions of the Vyper compiler itself, meaning contracts whose source logic was sound were compiled into unsound bytecode. Auditors reading source could stare straight through it.

Oracle manipulation attacks the inputs. A contract that trusts a price feed can be robbed by distorting the price, and flash loans supply the distortion capital within a single atomic transaction. Mango Markets, about 114 million dollars in 2022, is the canonical case and the mechanics remain routine; this cluster's pillar dissects the pattern.

Access control failures are the embarrassing class: functions that anyone can call because a modifier is missing, initialisers left open, privileged roles retained by deployer keys. The 2017 Parity wallet incidents, tens of millions stolen and over 150 million dollars permanently frozen, both trace here.

Arithmetic and validation errors persist despite safer languages. Cetus, the largest DEX on Sui, had about 223 million dollars exploited in May 2025 because one overflow check compared against the wrong constant, letting a crafted value pass validation and corrupt liquidity accounting. The contract had been audited more than once, per the incident post-mortems. The aftermath matters for the record: roughly 162 million dollars was frozen through coordinated validator action and moved into a recovery and compensation process by community vote. Gross exploited value and frozen or recovery-routed value should be reported separately, and a final net-loss figure stated only once a dated accounting exists, rather than assumed.

Finally, pure logic error: code that compiles, passes tests, does what it says, and says the wrong thing. Euler Finance's 197 million dollar loss in 2023 combined a donation mechanism with liquidation logic in a way no individual line made obvious. This class has no scanner, because nothing is technically broken except the idea.

What does an audit actually examine, and what is out of scope by design?

Quick answer

An audit examines a frozen snapshot of code against known vulnerability classes and the team's stated intentions, within a budget of expert hours; nearly everything else, economics, oracles, governance, operations, dependencies, the future, sits outside the frame. Reading an audit report's scope section is more informative than reading its badge.

A serious audit brings manual review by experienced researchers, static analysis, testing against the specification, and a report grading findings by severity. Where the team's specification is wrong, the audit checks the code against a wrong target; where the specification is silent, auditors infer intent. Both are quiet sources of misses.

The structural limits are worth listing plainly. An audit is point-in-time: the reviewed commit is what was examined, and the upgrade shipped three months later was not. It is scope-bounded: peripheral contracts, deployment scripts, admin tooling and integrations are frequently excluded for budget. It is assumption-laden: reports routinely assume honest oracles, sane tokens, and trusted admin keys, which are precisely the assumptions attackers refuse to share. It is economically blind unless economic review is bought separately: solvency under manipulation, incentive failure and toxic composability with other live protocols are a different discipline. And it is stack-shallow: the compiler, the virtual machine and the node software underneath are almost never in scope, which is exactly where the Curve incident lived.

Time pressure compounds all of it. Audit firms sample the search space where attackers, post-deployment, get unlimited time, live state, and the composability of the entire chain as instruments. The asymmetry is structural: reviewers must think of everything within a fixed engagement; an attacker needs one thing everyone missed, forever.

None of this is an argument against audits. It is an argument for reading "audited" as "sampled by experts under constraints", which calibrates the badge to what it can bear.

Figure from Smart Contract Risk: Audits, Exploits, and What They Miss
Figure 1. What a smart contract audit covers, and the failure surface outside its frame.

Why do audited protocols still lose hundreds of millions?

Quick answer

Because the loss distribution follows what audits leave out: post-audit changes, excluded components, cross-protocol interactions, compromised operations and economic design, on top of the residual bugs sampling inevitably misses. The audited-and-hacked list is long enough to be a genre.

Recent data makes the pattern quantitative. TRM Labs counted 207 incidents in the first half of 2026, a record number, yet under a billion dollars in total losses, down 58 percent year on year; smart contract exploits were about 60 percent of the incidents and a small fraction of the value, while infrastructure attacks, keys, signing environments, operational access, took roughly 76 percent of the money from about 15 percent of the incidents. The 2025 numbers told the same story more brutally: around 3.4 billion dollars stolen, dominated by the 1.5 billion dollar Bybit theft, which attacked a signing workflow rather than any contract. Attackers migrate to the softest layer, and years of auditing have made contract bugs the harder trade relative to operations.

When audited code itself fails, the taxonomy from the earlier sections usually explains why. Cetus: a validation subtlety in an unusual language context, sampled past by several firms, with most of the exploited value later frozen and routed to recovery. Euler: emergent logic across features, each locally correct. Curve: the layer below the source. Beyond these, a steady stream of smaller incidents comes from upgrades shipped after review, from admin keys handled casually despite immaculate contracts, and from protocols interacting with tokens and markets their model never imagined.

There is also an economics of scarcity: top-tier review capacity is limited and expensive, so projects ship with one audit where the risk warranted three, or with a marketing-grade review from a firm chosen for turnaround time. The audit badge compresses all of this variance into one word, which is why sophisticated allocators read the reports, check the commit hashes against what is deployed, and treat an unaudited upgrade to an audited protocol as unaudited code.

Figure from Smart Contract Risk: Audits, Exploits, and What They Miss
Figure 2. H1 2026: incident share versus value share by attack type.

What does a serious security stack look like beyond the audit?

Quick answer

Layered and assuming failure: multiple independent reviews, formal methods and fuzzing where they bite, continuous monitoring, economic circuit breakers, timelocked changes, bug bounties, and a rehearsed plan for the day something gets through. Each layer catches a different miss profile, which is the whole point of layering.

Redundant review catches reviewer-shaped gaps: different firms, different methods, different blind spots, plus contest platforms that throw hundreds of independent researchers at the same code. Formal verification proves specific properties, conservation, access invariants, against a mathematical model; its limit is that it verifies the properties someone thought to state. Fuzzing and invariant testing hammer the state space mechanically and excel at the Cetus class of validation edge; they are cheap enough that their absence is now a signal.

Bug bounties change the market: a standing offer, sized meaningfully against value at risk, gives the researcher who finds the miss a legal payday competitive with crime. The largest DeFi bounties have paid out millions and been cheap at the price.

Runtime defences accept that prevention ends at deployment. Monitoring watches mempools and state for attack shapes; circuit breakers cap outflows per block or pause on anomaly; timelocks on upgrades and parameter changes give the world days to inspect what governance approved before it goes live, converting stealth changes into public ones. Rate limits convert total drains into partial ones, the same philosophy of bounded blast radius that runs through this academy's custody articles.

And because the loss data says operations now outweigh code: the keys that administer contracts deserve contract-grade rigour. Distributed signing authority, quorum approval, clear signing on independent devices, and no single operator able to upgrade a treasury contract alone. The Bybit incident is the standing reminder that a perfect contract administered through a corruptible workflow is a perfect contract with a side door.

For a user or allocator, the checklist compresses to questions: how many independent reviews, of the deployed commit; what can admin keys do, behind what delay and what quorum; what breaks the protocol economically, and does the team publish that analysis; what is the bounty; what is the pause plan. Protocols that answer these in public documentation are telling you their security culture; protocols that answer with a badge are telling you something too.

How should an expert read an audit report?

Quick answer

Backwards: scope and assumptions first, unresolved findings second, the deployed-commit match third, and the marketing summary last if at all. A report is evidence about process quality, and it is read most usefully as a map of what was NOT covered.

Start with scope. Which contracts, which commit, what was excluded, and does the deployed bytecode correspond to the reviewed code; block explorers make verification practical, and mismatches are common enough to check routinely. An audit of commit A is silent about commit B.

Read the assumptions as an attack surface list. "We assume the admin is honest" means admin key compromise is your risk to price. "Oracle behaviour is out of scope" means the Mango pattern is unexamined. Every stated assumption is a boundary the review stopped at, and boundaries are where attackers shop.

Weigh findings by response, more than by count. A report with a dozen resolved criticals can reflect an engaged team and thorough reviewers; a clean report can reflect a shallow pass. The alarming pattern is findings acknowledged and shipped anyway, or fixed in ways the auditors never re-reviewed. Check whether a re-audit of fixes happened; the fix-introduced bug is a recurring species.

Finally, place the report in time. How old is it, how many upgrades have shipped since, and does the protocol's changelog respect the principle that changed code is unaudited code. For a protocol under active development, the meaningful object is a security pipeline, review on every release, standing bounty, monitoring, rather than any single document. One strong report from years ago is an artefact, and artefacts do not secure live systems.

The disciplined summary: audits are necessary, informative and insufficient, and the professionals who commission them would say the same. Their real product is a reduced unknown, and unknowns are managed, never eliminated.

Frequently asked questions

Is an audited protocol safe to use?

Safer, with wide error bars. An audit reduces the chance that known vulnerability classes survive in the reviewed code. It leaves economic design, oracles, upgrades, operations and undiscovered classes on the table, and the recent loss data shows most stolen value now exits through those doors. Treat the audit as one input alongside admin key policy, timelocks, bounty size, monitoring and track record.

Why not just audit until nothing is left to find?

Because review samples an effectively unbounded search space under a budget, while attackers search it indefinitely against live state. More review shrinks residual risk with diminishing returns; it cannot reach zero, and the classes audits are structurally blind to, future changes, emergent composability, compromised operators, do not shrink with extra reviewer hours. That is why mature stacks spend the marginal pound on bounties, fuzzing, monitoring and blast-radius limits instead of a fifth identical audit.

What is the difference between an audit and formal verification?

An audit is expert review: humans and tools hunting for problems. Formal verification is mathematical proof that the code satisfies explicitly stated properties under a model. Verification is stronger where it applies and only as good as the properties and the model; a proven-correct contract with an unstated property, or a wrong specification, fails formally intact. The strongest pipelines use both, on the components that matter most.

Do bug bounties actually work?

The incentive logic is sound and the record supports it: major platforms have mediated payouts in the millions for critical findings that would have cost protocols hundreds of millions live. A bounty's credibility matters more than its headline: clear scope, fast triage, reliable payment and no history of stiffing researchers. An unfunded or adversarial bounty programme is worse than none, because it teaches researchers to sell elsewhere.

As a user, what is the single best proxy for a protocol's security culture?

Look at what happens to power: what admin keys can do, who holds them, behind what timelock and quorum, and whether that is documented in public. Teams that constrain themselves visibly, delayed upgrades, distributed signing, published economic analysis, funded bounties, are showing you a culture. The badge count is the least informative number on the page.

Sources and further reading

Key references for this article, current as of July 2026. Volatile figures are re-checked at each quarterly review.

Quick quiz: did it stick?

A few questions to check the fundamentals landed. Answers with explanations follow, and nobody is grading you except your future portfolio.

1/5 question
What is a smart contract audit, precisely?

Was this helpful?