The Number That Should End “Audited” as a Trust Signal

The ack3 H1 2026 DeFi incident dataset verified 135 incidents with $939.86 million in attributed losses. For the 68 incidents where researchers could identify audit history, the result was stark: 46 attack paths — 67.6% by count — lay outside every identified audit scope, representing $680.97 million of $721.25 million in reported loss (94.4%) against just $35.21 million inside scope.

Two caveats keep this honest rather than sensational. First, the 67.6% figure describes the 68 incidents with identified audit history, not all 135. Second, two mega-incidents — Kelp DAO ($292 million) and Drift Protocol ($285 million) — dominate the loss weighting; excluding both still leaves 72.1% of remaining loss outside scope ($103.97M of $144.24M). The direction survives the concentration adjustment: most exploits of audited protocols did not defeat the audit. They went around it, through code or systems it never covered. Hacken’s Q1 2026 data tells the same story from the other side: six exploited projects had prior audits — including teams with three, five, even eighteen audits — and lost $37.7 million, with several vulnerabilities “outside the scope of traditional code reviews,” including oracle manipulation.

For CFOs, audit committees, and allocators, the takeaway is a question change: stop asking whether a protocol was audited and start asking what was audited, when, and what has changed since.

This guide pairs with DeFi Smart Contract Auditing Standards, Stablecoin Reserve Attestation, and Stablecoin Issuer Audits.

Why Coverage Goes Stale: The Version Problem

A smart-contract audit is a photograph, not a warranty. It covers a specific commit hash of specific contracts at a specific date. Everything after that moment is unreviewed by definition:

  • Additions: new vault strategies, new collateral types, new chain deployments, new periphery contracts (routers, zaps, staking wrappers) added post-audit inherit zero coverage.
  • Deletions and refactors: removing a check the audit relied on, or restructuring inheritance so an audited modifier no longer applies, silently voids conclusions the report still appears to support.
  • Modifications: parameter changes, oracle swaps, fee-logic tweaks, and access-control edits are the most common staleness vector — small diffs, large blast radius.
  • Proxy upgrades: the audited implementation at block N is irrelevant once the proxy points at unaudited implementation N+1. The May 2026 Renegade exploit — an unprotected initializer drained via proxy delegatecall — is the canonical case: the dangerous code path never passed through a reviewed deployment process.

The operational rule is binary: any post-audit addition, deletion, or modification to in-scope code resets coverage for the affected surface until re-audited. Publish the audited commit hash alongside the report, diff every deployment against it in CI, and treat unaudited diffs as findings, not footnotes.

Code Scope vs Operational Scope

Most audit statements cover only the former. Most 2026 losses came through the latter:

Layer Typically in code scope? 2026 loss pattern
Core protocol contracts at audited commit Yes Minority of losses
New modules added post-audit No — unless re-audited INK Finance workspace-treasury logic flaw; CrossCurve missing source validation
Proxy admin and upgrade keys Often excluded or noted only Unprotected initializer drains; malicious upgrades
Oracles and price feeds Usually out of scope Flash-loan price manipulation (e.g., SOF token burn-before-sync)
Governance keys and multisigs Out of scope Signer compromise, threshold gaps
Off-chain infra: relayers, keepers, bots Out of scope Cross-chain message spoofing (TAC bridge)
DNS, front end, registrar Out of scope CoW Swap DNS social-engineering redirect ($1.2M user losses)
Deployed-chain differences Partial — one chain reviewed Same code, different chain, different assumptions (TAC: TON side)

The pattern is consistent: attackers price the audit perimeter and walk around it. Oracle manipulation, donation attacks, access-control gaps in new modules, and pure operational compromises (DNS, keys, relayers) dominate the outside-scope ledger — precisely the categories a code-only review never touches.

Scope-Negotiation Checklist for Protocols

Negotiate these before the audit starts, in writing, in the engagement letter — not after the report lands:

  1. Freeze the commit. Named branch, commit hash, compiler version, and optimizer settings. Any deviation during the audit restarts affected coverage.
  2. List in-scope and explicitly excluded contracts. Exclusions should name names: periphery routers, test mocks, third-party imports, governance contracts, off-chain bots. Vague “all core contracts” scopes are where disputes — and exploits — breed.
  3. Cover the upgrade path. Proxy admin, timelocks, multisig thresholds, and the deployment process itself. If the team can upgrade without review, say who can and how.
  4. Cover access control end to end. Roles, initializers, ownership transfer, emergency pause — including the contracts added last sprint.
  5. Name the oracles and dependencies. Every price feed, keeper, relayer, and bridge dependency with its trust assumptions documented, even where the auditor only reviews the integration point.
  6. Define the re-audit trigger. Any post-audit addition, deletion, or modification to in-scope code, plus any new deployment target, triggers scoped re-review before mainnet. Put the diff-check in CI.
  7. Demand plain-language limitations. The report must state, in non-technical terms, what was not reviewed and that post-audit changes void coverage — suitable for quoting to an audit committee, not just engineers.

Retain the engagement letter, scope inventory, frozen commit references, and final report as one packet — the same binder discipline as Month-End Close evidence, because diligence teams and insurers will ask for exactly this file. Align vendor selection and re-testing cadence with Vendor Due Diligence and NIST CSF 2.0 review cycles rather than treating audits as one-off events.

Limitation Language Auditors Should Publish

Vague “this audit is not a guarantee” paragraphs protect the auditor while informing nobody. A useful limitation section names specifics — adapt freely:

Scope. This assessment covered [repository @ commit hash], specifically [list contracts], using [compiler/optimizer settings], during [dates]. Expressly out of scope: oracle and price-feed infrastructure; governance, multisig, and upgrade-key management; off-chain relayers, keepers, and bots; DNS, hosting, and front-end systems; deployments on chains other than [list]; and any code added, removed, or modified after the reviewed commit. Validity. Findings apply to the reviewed commit only. Post-audit changes — including proxy upgrades — are unreviewed until re-assessed. This report is a point-in-time security assessment, not a guarantee of safety, solvency, or correct economic design.

Protocols should refuse reports that will not say this plainly: an auditor unwilling to enumerate exclusions is selling a badge, not an assessment. Audit committees should demand the limitation section before the findings — see Audit Committee oversight expectations and Whistleblower channels for post-deployment anomaly reporting.

What CFOs and Audit Committees Should Ask Instead

Replace the binary “are we audited?” with a coverage interview, quarterly:

  1. What exact commit is deployed on each chain, and does it match an audited commit byte-for-byte?
  2. What changed since the audit — code, chains, oracles, keys, multisig membership?
  3. Who holds upgrade and pause authority right now, and when was it last exercised or tested?
  4. What percentage of TVL sits in contracts added after the last audit?
  5. When does the current assessment expire under our own policy — and what triggers re-assessment early?

If the answer to question 1 requires investigation rather than a dashboard, the audit program is already behind the attackers. The 2026 data does not say audits are worthless — the $35 million inside scope versus $681 million outside it says audits work roughly where they look, and attackers have learned exactly where that is.

FAQ

Do more audits fix the scope problem?

Not by count. Venus Protocol had five audit firms and Solv three, yet fell to out-of-scope vectors. One correctly scoped, current assessment beats eighteen stale ones — freshness and boundary completeness dominate auditor count.

Should protocols disclose unaudited changes publicly?

Yes — a changelog mapping deployments to audit coverage turns a trust liability into evidence of process maturity. Diligence teams increasingly treat undisclosed deltas as findings in themselves.

How does this interact with SOC 2 or ISO 27001?

Code audits test logic; SOC 1 vs SOC 2 and ISO 27001 test the organization around the code — change management, access reviews, incident response. Mature programs run both, since operational scope is where the 2026 losses concentrated.

Next Steps

  1. Pull the deployed bytecode or commit for every chain you operate and diff it against the last audited commit this week — log every delta as in-scope or accepted-risk with an owner.
  2. Renegotiate the next assessment using the checklist above, with exclusions named and re-audit triggers in the engagement letter.
  3. Put operational scope (oracles, keys, upgrades, DNS/front end, relayers) on the quarterly risk register with the same seriousness as code findings — see Enterprise Risk Management.