This article is for educational purposes only and does not constitute security, legal, or investment advice. Always engage licensed security professionals before deploying capital into any smart contract system.
Quick Answer
A smart contract audit’s scope is a negotiated boundary, not a guarantee. Reputable engagements combine automated static analysis, line-by-line manual review, and business-logic modeling of the specific contracts listed in a signed scope document — typically 60% to 90% of a protocol’s total codebase. Audits almost never cover off-chain infrastructure, admin key custody, front-end code, third-party oracle behavior, or any code deployed after the report’s cutoff commit. A meaningful share of protocols exploited between 2022 and 2025 had passed at least one prior audit, mostly because the exploited logic sat outside the audited scope or was added afterward. Reading the scope section of a report matters as much as reading the findings.
Why Audit Scope Became a Board-Level Question
Five years ago, “we got audited” was often treated as a marketing checkbox — a PDF badge slapped on a landing page next to a logo from whichever firm was cheapest that quarter. That casualness has largely disappeared, at least among protocols holding real institutional money. Insurance underwriters now ask which specific contracts were reviewed. Institutional allocators writing eight-figure checks into tokenized funds ask for the commit hash the auditors actually tested against, not just a report date. Compliance teams at banks piloting on-chain settlement rails want to know whether the audit covered the upgrade proxy pattern or just the logic contract behind it.
This shift tracks a pattern in the loss data. DeFi and broader Web3 exploits have cost the industry billions of dollars a year since 2021, and a meaningful share of the biggest losses hit contracts that carried an audit report somewhere in their GitHub history. Euler Finance lost roughly $197 million in March 2023 to a flaw in a donation-and-liquidation interaction that had been reviewed by multiple firms — the vulnerable logic was added in a later update that never went back through the original audit. Cream Finance, Nomad Bridge, and several other nine-figure incidents followed a similar pattern: the audited contracts weren’t necessarily the ones that failed, or the failure sat at a seam the scope never touched, like an oracle feed, a bridge relayer, or an admin multisig.
Corporate treasuries experimenting with on-chain payment rails and compliance automation have run into the same lesson from a different angle. As programmable money moves into everyday treasury operations, finance teams have discovered that a smart contract audit is not a single, standardized product — it is a scope document, a team roster, a time budget, and a severity taxonomy, and all four of those variables change what “audited” actually means for a given piece of code.
What a Real Audit Engagement Actually Reviews
Strip away the marketing language and a competent smart contract audit is built from four layers of scrutiny, each catching a different class of bug. No single layer is sufficient on its own, and a scope document that only pays for one or two layers is a materially weaker audit than one paying for all four.
Automated Static and Dynamic Analysis
Tools like Slither, Mythril, Semgrep for Solidity, and fuzzers such as Echidna or Foundry’s built-in fuzzing engine run thousands of synthetic transactions and pattern checks against the code in minutes. They reliably catch known bug classes: unchecked external calls, integer overflow in older compiler versions, missing access modifiers, and classic reentrancy patterns. Automated tooling is fast and cheap, which is exactly why it should never be the only layer — it catches the bugs that are already well-cataloged and misses anything novel to the protocol’s specific economic design.
Manual Line-by-Line Review
This is where senior auditors read every function, trace every state change, and ask what happens if a value is zero, negative, or manipulated by the caller in the same transaction. Manual review is what catches business-logic errors: a fee calculation that rounds in the wrong direction, a withdrawal function that doesn’t account for a paused state, a governance function that can be called before initialization completes. Firms like Trail of Bits, OpenZeppelin, Spearbit, and Zellic price this labor by auditor-day, and it’s the largest single line item in any serious engagement.
Business Logic and Economic Modeling
For protocols involving lending, liquidations, AMMs, or yield strategies, auditors increasingly model the economic incentives separately from the code. This layer asks whether a flash loan can be used to manipulate an internal price calculation, whether a liquidation bonus can be gamed by a single actor controlling both sides of a trade, and whether the protocol’s assumptions about collateral ratios hold up under extreme but plausible market moves. This is the layer most likely to be skipped by teams on a tight budget, and it is also the layer responsible for catching the exploit classes — like the Euler donate-function interaction — that pure code review sometimes misses because each individual function looks correct in isolation.
Access Control and Upgrade Path Review
Who can call the pause function? Who controls the proxy admin? What happens if the multisig signer set changes? A growing share of major incidents in 2024 and 2025 traced back not to a flaw in the core logic but to compromised or overly broad admin privileges — a single externally-owned account with upgrade rights, a timelock with a delay short enough to be meaningless, or a multisig threshold that was never actually met by independent signers. A scope that includes access control review will explicitly test what an attacker with a compromised deployer key, or a malicious insider, can and cannot do to user funds.
How the Engagement Actually Runs, Start to Finish
Most engagements follow a recognizable sequence, and knowing the shape of it helps a team plan a launch date without guessing. First comes scoping: the protocol team and the firm agree in writing on which contracts are in scope, which commit hash defines the frozen codebase, and what the deliverable looks like — usually a draft report, a remediation window, and a final report. Second comes the review itself, split between the automated pass in the first day or two and the manual, business-logic-driven review that occupies the bulk of the calendar time. Third is the draft report, delivered privately to the team rather than published, giving engineers a window to fix issues before anything becomes public. Fourth is remediation: developers patch what they can, document what they’re accepting as a known trade-off, and respond to each finding individually rather than in bulk. Fifth is the verification pass, where the same auditors confirm the fixes actually close the gap rather than just changing the symptom. Only after that does a final report get published, ideally alongside the exact commit hash it covers.
Skipping steps rarely saves as much time as teams expect. A rushed scoping conversation that leaves the upgrade proxy ambiguous, for instance, tends to cost more calendar days later when the auditors flag the ambiguity mid-review and the whole engagement pauses for a scope amendment. Firms that specialize in DeFi, including Zellic, Spearbit’s network of independent researchers, and Quantstamp, generally publish rough timelines on their own sites, and three to six weeks from kickoff to final report is a reasonable planning assumption for a mid-sized protocol, with simpler token contracts finishing faster and multi-chain systems with bridging components routinely running longer.
One detail worth building into any project timeline: the remediation window itself is not optional slack. Teams that try to compress it — fixing a dozen findings in two days to hit a marketing-driven launch date — are the same teams that show up in post-mortems six months later with a new bug introduced by a rushed patch that nobody re-verified. The Section on common mistakes below covers this in more depth, but it deserves saying plainly here: the fix is where new bugs get introduced almost as often as old ones get closed.
The Five Things Most Audit Scopes Quietly Leave Out
Reading a report’s executive summary is not the same as reading its scope section, and the gap between the two is where a lot of false confidence lives.
- Off-chain infrastructure. Keepers, relayers, indexers, and the servers that submit price updates or trigger liquidations sit outside almost every smart contract audit scope, even though a compromised keeper can be just as damaging as a contract bug.
- Front-end and API layers. The website users interact with is a different codebase entirely. Wallet-draining attacks via a compromised front end — swapping a legitimate contract address for a malicious one in the JavaScript — have hit otherwise well-audited protocols repeatedly.
- Admin key and multisig custody practices. An auditor can confirm that a multisig requires three of five signatures; they generally cannot confirm those five keys are stored on separate hardware devices by five genuinely independent people rather than one person with five laptops.
- Third-party oracle and bridge behavior. Audits typically review how a protocol’s contracts consume an oracle price feed, not whether that oracle itself can be manipulated — that’s a separate audit scope belonging to the oracle provider, and it’s frequently never commissioned at all for smaller or newer feeds.
- Any code shipped after the audit’s commit hash. This is the single most common source of “but it was audited” surprises. A report locks in against one specific git commit. Every line changed, added, or quickly patched after that commit is, by definition, unaudited until someone re-reviews it.
How Severity Ratings Actually Drive Remediation
Most firms converge on a five-tier severity taxonomy, even though the exact wording varies: Critical, High, Medium, Low, and Informational (sometimes labeled Gas or Best Practice). The rating combines two independent judgments — how bad the outcome is if exploited, and how easy the exploit is to pull off — and reputable firms document both dimensions rather than issuing a single unexplained label.
A Critical finding typically means direct, unauthenticated theft or freezing of user funds is possible today, by anyone, with no special privileges. A High finding usually means funds are at risk but the attack requires specific conditions — a particular market state, a governance vote, or a privileged role. Medium findings often describe logic that behaves incorrectly without directly enabling theft, such as inaccurate accounting that a protocol team could still catch and patch. Low and Informational findings cover gas inefficiencies, style issues, and defensive-coding suggestions that don’t represent an active threat.
The chart below reflects the rough shape of severity distribution across a large sample of public audit reports and public contest results, aggregated from disclosures by firms including OpenZeppelin and Trail of Bits and contest platforms such as Code4rena and Sherlock. Most findings in any given audit are low-severity noise, and Critical findings are genuinely rare per engagement — which is exactly why the two or three that do surface deserve disproportionate attention before launch.
Typical Finding Distribution by Severity (share of total findings in a full audit report)
Illustrative distribution compiled from publicly disclosed audit reports and open contest results. Individual engagements vary widely by protocol complexity.
Worked Example: Pricing an Audit for a $40 Million Lending Protocol
Numbers make scope decisions concrete faster than prose does. Consider a hypothetical lending protocol, call it Meridian Markets, preparing to launch with a target of $40 million in initial deposits. Its core contracts total 6,800 lines of Solidity across a lending pool, an interest rate model, a liquidation engine, and a governance timelock.
The team engages a mid-tier firm for a two-auditor, three-week engagement. At a blended day rate of $2,500 per auditor, fifteen business days per auditor comes to:
2 auditors × 15 days × $2,500/day = $75,000 base engagement fee
That works out to roughly $11 per line of code reviewed (6,800 lines ÷ $75,000), and about 227 lines per auditor per working day (6,800 ÷ 30 auditor-days) — a pace toward the fast end of the loose industry rule of thumb that careful manual review of financial logic runs somewhere between 150 and 250 lines per auditor per day, depending on how much of that code is straightforward storage-and-transfer logic versus dense conditional math.
The engagement surfaces 3 Critical, 6 High, 14 Medium, 21 Low, and 12 Informational findings — 56 total, broadly consistent with the industry-wide distribution shown above. Meridian’s engineering team spends nine business days remediating the Critical and High findings (the Medium and Low items get triaged, with several accepted as known trade-offs and documented rather than fixed). The audit firm then runs a verification pass confirming the fixes — three additional auditor-days at a $3,000 day rate for verification work:
3 verification days × $3,000/day = $9,000 remediation review
Total engagement cost: $75,000 + $9,000 = $84,000
Against a $40 million launch target, that’s 0.21% of deposited value — roughly twenty-one basis points spent to materially reduce the odds of a Critical bug reaching production. For comparison, the Euler Finance incident wiped out roughly half of that protocol’s total value locked in a single transaction. A single avoided Critical finding of even modest scale can pay for dozens of audit engagements the size of Meridian’s.
The comparison isn’t meant to suggest audits are insurance — they explicitly aren’t, and no reputable firm will claim otherwise in writing. It’s meant to show that the marginal cost of thorough scope is small relative to the tail risk it’s priced against, which is exactly the argument that gets audits funded at the board level once someone runs the numbers.
Comparing Audit Approaches Side by Side
Teams rarely pick just one approach in isolation; larger protocols increasingly layer several of the rows below rather than treating them as substitutes.
| Approach | Typical Cost | Typical Duration | Best At Catching | Common Blind Spot |
|---|---|---|---|---|
| Automated static/dynamic analysis | $0–$5,000 | Hours to 2 days | Known bug patterns, reentrancy, overflow | Novel business logic errors |
| Manual review (single firm) | $15,000–$150,000+ | 2–6 weeks | Logic errors, access control gaps | Auditor blind spots, single point of view |
| Formal verification | $30,000–$200,000+ | 3–8 weeks | Mathematical invariant violations | Requires precise, narrow spec; misses unspecified behavior |
| Public audit contest (crowdsourced) | $20,000–$100,000 prize pool | 1–2 weeks | Volume of eyes, diverse attack framing | Variable researcher quality, duplicate findings |
| Bug bounty (post-launch) | Pay-per-bug, capped by TVL % | Ongoing | Issues only visible in live conditions | Reactive, not preventive; race against malicious actors |
Common Mistakes Teams Make When Scoping an Audit
Most of the avoidable damage happens before the auditors even start typing.
- Freezing scope too late. Sending code for audit while still actively developing new features guarantees the shipped version diverges from the audited one, quietly reopening every closed finding.
- Treating a single audit as final. Complex protocols holding significant value increasingly commission two independent firms plus a public contest, because different auditors bring different mental models and reliably find different bugs — overlap between two independent reports is often surprisingly low.
- Excluding the upgrade mechanism from scope to save budget. Proxy patterns, storage layout collisions between implementation versions, and initializer functions that can be called twice are a recurring, expensive category of bug, and they’re exactly the kind of thing teams try to save money by skipping.
- Ignoring Low and Informational findings entirely. A handful of “just a gas optimization” notes have, in specific documented cases, pointed at an underlying accounting assumption that later broke under edge-case conditions.
- Not re-auditing after “small” post-report changes. A one-line fix meant to satisfy a Medium finding has, more than once, introduced a new Critical issue that nobody re-checked because it seemed too small to matter.
- Publishing the audit badge without publishing the report. A logo on a website proves nothing without the underlying document, the commit hash it covers, and the firm’s contact information for verification.
Practical Pre-Audit Checklist
- Freeze a specific commit hash before sending code to auditors, and record it in the engagement letter.
- Confirm in writing which contracts, libraries, and upgrade proxies are in scope — and which are explicitly out.
- Ask whether the quote includes a remediation and verification pass, or whether that’s billed separately.
- Request the firm’s severity rubric in advance so findings can be triaged consistently against internal risk tolerance.
- Run static analysis and an internal fuzz suite before the paid engagement starts, so auditor time isn’t spent on cheap, automatable findings.
- Document admin key custody, multisig signer independence, and timelock delay separately — most scopes won’t verify these operationally.
- Plan a re-audit trigger for any post-launch change touching money-moving logic, not just a vague “we’ll revisit if needed.”
- Publish the full report and commit hash publicly, not just a summary graphic or a badge.
- Budget for a second, independent review or public contest if total value at risk exceeds roughly $10 million.
- Set up a live bug bounty the day of launch — audits and bounties are complementary, not substitutes for each other.
Key Takeaways
- An audit scope is a negotiated, written boundary — read the scope section before trusting the executive summary.
- Four layers matter: automated tooling, manual review, economic and business-logic modeling, and access control review. Skipping any one weakens the whole engagement.
- Off-chain infrastructure, front-ends, admin key custody, oracle internals, and any post-audit code changes typically fall outside scope by default.
- Severity ratings combine impact and exploitability; Critical findings are rare but disproportionately important relative to the much larger volume of Low and Informational noise.
- A full engagement — base audit plus remediation verification — commonly runs a fraction of one percent of protocol TVL, a small price against the tail risk it addresses.
- Layering approaches (manual audit, contest, formal verification, bug bounty) catches more than relying on any single method.
Frequently Asked Questions
What does a smart contract audit typically cover?
A typical audit covers the specific smart contracts listed in a signed scope document, reviewed against a frozen commit hash using automated static analysis, manual line-by-line review, and often business-logic or economic modeling of the protocol’s core mechanics, such as lending, liquidation, or fee logic.
Does an audit guarantee a smart contract is safe?
No. An audit reduces the probability of common and identifiable bug classes going live, but it cannot guarantee safety, since it only reviews the code and time window defined in its scope, and novel attack techniques or code changes made after the audit fall outside that guarantee.
How much does a smart contract audit cost?
Costs vary widely by codebase size and complexity, ranging from roughly $5,000 for a small, simple token contract to well over $150,000 for a complex DeFi protocol with lending, liquidation, or cross-chain components reviewed over several weeks.
Why do audited protocols still get hacked?
Most post-audit exploits trace back to code changed after the audit’s commit hash, functionality that was explicitly out of scope such as admin key custody or oracle behavior, or business-logic edge cases that manual review and automated tooling did not anticipate.
What is the difference between an audit and a bug bounty?
An audit is a fixed-scope, time-boxed review performed before or around launch by a hired firm, while a bug bounty is an ongoing, pay-per-finding program that incentivizes independent researchers to report vulnerabilities in live, deployed code — the two are complementary rather than interchangeable.
References
- OpenZeppelin, public audit report archive and security methodology documentation.
- Trail of Bits, “How to Audit a Smart Contract” methodology notes.
- Code4rena and Sherlock contest result archives, aggregated finding severity data.
- Rekt News, incident post-mortem database.
- Chainalysis, annual crypto crime reports covering DeFi exploit trends.
- Immunefi, bug bounty and vulnerability disclosure statistics.
