2026-10-10

Is a Smart Contract Audit Worth It? Expected Loss Avoided vs. Audit Cost

A plain framework for deciding how much audit to buy: estimate the value at risk, what share of that risk an audit can actually reduce, and what it cannot touch.

Is a Smart Contract Audit Worth It? Expected Loss Avoided vs. Audit Cost

A skeptical CTO usually opens with the same question: "We're about to spend a large sum on an audit. What do we actually get back?" The honest answer is that an audit doesn't buy safety. It lowers the chance of one class of loss, for one version of your code, at one point in time. To decide whether the price is right, you need a rough figure for that reduction and a clear view of the losses the audit can't touch.

This guide gives you a simple model you can fill in with your own numbers in an afternoon. It's the first article in our series on what makes a good blockchain audit.

Start with the money that can actually leave

Expected loss is roughly probability of a successful attack × amount an attacker can take. Most teams get the second term wrong because they use total value locked (TVL). The better figure is extractable value: how much a single exploit could drain before you notice and pause.

  • Bridges and custody contracts often hold everything in one place, so extractable value is close to total value. When a bridge or custody contract can be emptied in a few withdrawals, there is almost no gap between total value and what one incident can take.
  • Lending markets and AMMs can be drained market by market. Per-market caps, rate limits and pause guardians shrink the number.
  • Upgradeable systems carry the worst case of whatever the upgrade key can do. If one signer can swap the implementation, the value at risk is all of it.

Write down three figures: the expected value at launch, at six months and at twelve months. Audit decisions are usually made on the launch figure, but losses happen on the later ones.

Estimate the probability honestly

Nobody has a precise per-protocol exploit rate, but public loss data shows the scale of the problem. Chainalysis counted over $3.4 billion stolen in 2025 through early December, with the February Bybit compromise alone accounting for $1.5 billion; the prior year (2024) was about $2.2 billion across 303 incidents, up from 282 in 2023. Rekt's leaderboard and DefiLlama's hacks database list individual incidents with root causes. Look up protocols like yours (same category, same chain, similar complexity) and note how often their loss came from contract logic and how often from something else.

That split matters, because it shows how much of the risk an audit can address.

Separate the risk an audit can reduce from the risk it can't

A code audit examines the contracts in scope, at a specific commit. It can't do much about:

  • Key and infrastructure compromise. Chainalysis attributes 43.8% of crypto stolen in 2024 to private key compromises (2024 data), and its 2025 report says the Bybit theft and other attacks on centralized services came through private key infrastructure and signing rather than contract code. No line of Solidity has to be wrong for that loss to happen.
  • Code that changes after the audit. Nomad's August 2022 loss of about $190 million traced to a contract upgrade on June 21, 2022. In its own root-cause analysis, Nomad says the upgrade made the Replica contract accept forged messages.
  • Dependencies outside scope. In July 2023, multiple Curve pools were exploited through a re-entrancy guard bug in Vyper compiler versions 0.2.15, 0.2.16 and 0.3.0. According to the Vyper team's post-mortem, the bug had been patched in 0.3.1 without affected protocols being notified.

So the useful formula is:

Expected loss avoided ≈ value at risk × probability of a code-level exploit × share of that probability the audit removes

The last term is never 100%. Trail of Bits analyzed 246 findings from its own audits and estimated that almost half (about 49%) are unlikely to ever be found by automated tools. Its point is that expert review catches a lot that tools miss, but no single method catches everything.

A worked example (assumed numbers, not data)

Say you're launching a lending market:

Input Assumption
Extractable value at 12 months $40M (caps limit a single drain to 40% of a $100M TVL target)
Annual probability of a code-level exploit without external review 8%
Share of that probability a strong audit plus fixes removes 50%

Expected loss avoided in year one ≈ $40M × 8% × 50% = $1.6M. If a quality audit plus a re-review of the fixes costs a fraction of that, the audit is worth buying. If your realistic extractable value is $2M, the same calculation gives $80K, and a contest, a bounty and strong automated testing may be the better spend. Our audit pricing guide covers what drives quotes.

Run the model three times with pessimistic, central and optimistic inputs. If the decision flips between them, the audit isn't the problem. You don't yet know your value at risk well enough. Fix that first.

Spend on the risk you can't audit, too

Because key compromise and operational failures are such a large share of real losses, part of the security budget belongs outside the audit:

  1. Key management. Use multisig or MPC with hardware keys and a quorum that no single team or vendor can meet alone.
  2. Monitoring and pause authority. An outflow that sits undetected is the difference between a bad incident and a terminal one.
  3. A bug bounty sized to the value at risk. Wormhole paid a $10 million bounty through Immunefi for an uninitialized-proxy bug. A whitehat is only paid well if the bounty is credible against what an attacker could take.
  4. Re-review for every upgrade. The audit you bought covers one commit. Budget for the next one.

What to tell the board

An audit is a risk-reduction purchase with a measurable but partial effect. Present it as one line in a security budget sized to extractable value, next to key management, monitoring, a bounty and re-reviews. Don't present it as insurance. When the board asks "are we safe?", the truthful answer is: "We reduced the probability of a code-level exploit in the reviewed version, and here is what we're doing about the rest."

Sources

Sponsored