What Does An Audit Actually Cover? A Buyer’s Guide to Smart Contract Audit Scope
Two firms quote the same repository. One comes back at $18,000 across two weeks. The other quotes $95,000 across five. Same contracts, same commit, same launch date. Neither statement of work contains a section headed “exclusions.”
That gap is where buyers lose money. Price is the visible variable. The invisible one is what each team actually intends to read, and what each team will quietly treat as somebody else’s problem. Smart contract audit scope is the boundary of the engagement: which files, which commit, which vulnerability classes get tested, and which assumptions get accepted as given.
This guide does four things. It defines scope precisely, lists what a standard review covers and what it typically leaves out and it gives you arithmetic you can run on your own repository tonight, before your first sales call. And it corrects pricing figures that are still circulating well below the current market. No fear-selling, no exploit statistics. This is a buyer’s guide, written for the person holding the SOW.
Key Takeaways
- Scope is defined by a repository, branch, and commit hash. Sherlock’s process guide describes it as “selecting a specific repository, branch, and commit hash,” and anything pushed after the freeze wasn’t audited.
- Immunefi’s recommended bug bounty defaults list centralization risks and “basic economic and governance attacks” as out of scope, but explicitly decline to exclude “oracle manipulation/flash loan attacks.” Audit firms draw similar lines. Do not assume a blanket oracle exemption in either direction.
- Sherlock’s 2026 reference anchors elapsed review windows at roughly 500 nSLOC to 3 days and 6,000 nSLOC to 38 days. Use it to sanity-check a quoted timeline before your first call.
- Sherlock puts typical DeFi audits at $25,000 to $100,000 and mid-complexity pre-launch budgets at $60,000 to $120,000. Guidance still quoting $5,000 to $15,000 understates the market.
- Budget remediation passes at $5,000 to $20,000 each, and treat firm audit, competitive audit, and bug bounty as a sequence rather than a choice.
What a Smart Contract Audit Is, and What Smart Contract Audit Scope Actually Means
The Definition, Precisely
A smart contract audit is a time-boxed manual review of a fixed set of source files at a fixed commit hash, performed by named engineers and supported by automated tooling, producing a written report of findings ranked by severity with remediation guidance.
Every clause in that sentence does work. Time-boxed. Fixed set. Fixed commit. Ask what a smart contract audit is in a sales call, and you’ll usually get “a security review of your code,” which tells you nothing about boundaries.
Scope vs Coverage vs Guarantee
Buyers routinely collapse three separate things into one word.
Scope is the declared boundary: the files, the commit, and the classes of issue in play. Coverage is how much of that scope the team genuinely got through in the hours available. Guarantee doesn’t exist. An audit reduces risk on what it read, on the day it read it. That’s the whole claim, and no reputable firm makes a larger one.
Coverage is the sneaky one. A scope can list twelve contracts, while the effort budget realistically supports deep review of five. Ask which contracts get the majority of reviewer hours, and ask for that in writing. A smart contract audit scope that lists everything and prioritizes nothing is a scope you should push back on.
The Commit Hash Is the Contract
Serious engagements pin to a repository, a branch, and a specific commit hash. Sherlock’s published process guide is unusually explicit about this, describing scoping as “selecting a specific repository, branch, and commit hash, then agreeing on what is in scope.” Anything pushed after that freeze sits outside the smart contract audit scope you paid for.
Scope drift is normal. You’ll find a bug on day three of a fourteen-day review and want to fix it. Fine, but understand the mechanics. A mid-engagement re-pin means reviewers re-read changed files, re-run tooling, and re-validate findings already written up. Firms charge for it because it costs them days. Budget for one re-pin rather than pretending you’ll freeze perfectly.
How Auditors Scope and Price an Engagement
Smart contract auditing is a labor market. You’re buying senior engineer-days, and everything in a proposal is a proxy for how many of them the firm thinks your code needs. Smart contract audit scope and price are the same conversation held with different vocabulary.
nSLOC, the Unit Everything Is Priced In
nSLOC means normalized source lines of code: executable Solidity, Rust, or Move, counted after stripping the noise. Comments don’t count. Blank lines don’t count. Interfaces, test files, and unmodified libraries are usually excluded from the count, too, though the last one gets argued about, so confirm it.
Two repositories of identical nSLOC can price very differently. Four factors drive the spread:
- Novelty of the mechanism. A fork of a well-understood AMM reviews faster than a new liquidation engine nobody has seen before.
- Number of external integrations. Each one adds an assumption surface.
- Mathematical complexity. Curve math, interest accrual, and share accounting consume disproportionate reviewer time.
- Cross-chain surface. Messaging, bridging, and replay logic multiply the state space.
The Calibration Table Buyers Never Get
Sherlock’s 2026 pricing market reference gives two anchor points, describing “approximately 500 nSLOC at a 3-day contest window and 6,000 nSLOC at 38 days, with cost scaling in proportion.”
Read those as elapsed calendar windows rather than reviewer-days. Sherlock notes that “contest-based platforms deploy 100 to 500 independent researchers simultaneously,” so the figures tell you how long an engagement takes, not how fast one auditor reads. The same reference adds a middle anchor, “a 3,000 nSLOC scope takes around 18 days,” which is a useful check on anything you interpolate.
| Approximate nSLOC | Approximate elapsed review window |
|---|---|
| ~500 | ~3 days (Sherlock anchor) |
| ~1,000 | ~6 to 7 days (interpolated) |
| ~2,000 | ~13 days (interpolated) |
| ~4,000 | ~25 days (interpolated) |
| ~6,000 | ~38 days (Sherlock anchor) |
The two anchor rows are Sherlock’s; the middle rows are straight-line interpolation between them, which is our arithmetic rather than theirs. Run cloc or a Solidity line counter over your contracts folder, subtract tests and interfaces, and you’ll walk into your first call with a defensible number. If a proposal quotes a fraction of that window, you’re being sold a scan. If it quotes triple, ask which contracts are eating the excess.
What Makes Your Audit Cheaper
This part is entirely under your control, and it’s the highest-leverage prep work a founder can do. Both OpenZeppelin and Quantstamp publish free audit readiness guides, and working through one before you request quotes is the cheapest thing on this list.
Quantstamp’s guide asks for NatSpec specifically: “Document all functions inline. Use NatSpec documentation for public and external functions.” It also asks you to write down your trust model, in its words, “If the system is NOT intended to be completely trustless, document who the trusted actors are and what they should be trusted with.” On testing, Quantstamp suggests “aiming for at least 80% coverage, with good quality projects aiming for 90+% branch coverage.”
Add to that: invariants already specified in plain English, such as “total shares must never exceed total assets,” and no half-finished features sitting in the audited branch behind a feature flag.
Each of these removes reviewer hours spent reconstructing intent instead of hunting bugs. Teams that plan this into the build phase, the approach we take in our Web3 development engagements, typically shave a meaningful slice off both the quote and the calendar.
What’s In Scope: The Vulnerability Classes a Standard Audit Covers
A standard smart contract security audit covers recognized classes of defects rather than a checklist of famous incidents. Below, each class gets what auditors look for, and the one adjacent thing teams assume is checked when it usually isn’t.
Access Control and Privilege
Reviewers map every state-changing function to the set of addresses that can call it: modifiers, role assignment, initializer protection, two-step ownership transfer, delegatecall context. Commonly assumed and typically not covered: whether the humans holding those roles should hold them, and whether your multisig signers are genuinely independent parties. That’s operational, and it lives outside the code.
Reentrancy and State Handling
Cross-function and cross-contract reentrancy, read-only reentrancy against view functions your integrators call, checks-effects-interactions ordering, and callback hooks in token standards that hand control back mid-execution. What falls outside: reentrancy paths introduced by a protocol you integrate with that ships an upgrade after your commit freeze.
Arithmetic, Rounding, and Precision
Rounding direction at every division, precision loss in share-to-asset conversions, fee math, first-depositor exchange-rate manipulation, unchecked blocks, and unsafe casting. Auditors verify the implementation matches the specification. Whether the specification describes the right economic formula is a separate question, and usually, your answer to give.
External Calls and Integration Assumptions
Return-value handling, non-standard ERC-20 behavior such as fee-on-transfer, rebasing, and missing return values, failure paths on low-level calls, and approval race patterns. The ongoing solvency and behavior of the third-party protocol you’re calling sits outside the engagement. Auditors document the assumption; they don’t underwrite it.
Upgradeability and Storage Layout
Proxy patterns, storage slot collisions, storage gaps, initializer protection, implementation contract self-destruct exposure, and admin slot handling. The review covers proxy mechanics at the audited commit. Logic you deploy behind that proxy three months later is a new engagement.
Gas, Denial of Service, and Griefing
Unbounded loops over user-controlled arrays, gas griefing through external calls, block-stuffing sensitivity in auctions and liquidations, push-versus-pull payment design. Chain-level conditions, such as sequencer downtime or sustained congestion on an L2 are normally recorded as stated assumptions rather than tested.
What’s Out of Scope: The Gaps Buyers Find Too Late
Here’s the section your vendor’s proposal probably doesn’t have.
The clearest public statement of default exclusions comes from the bug bounty side. Immunefi’s Vulnerability Severity Classification System v2.3 lists “Impacts involving centralization risks” and “Impacts requiring basic economic and governance attacks (e.g., 51% attack)” among its out-of-scope items, and adds a general downgrade rule: “if the exploit requires elevated privileges or uncommon user interaction, the level of the bug may be downgraded to reflect that or rejected.”
Read that as a starting point rather than a rulebook. Immunefi is explicit that these are “the default impacts recommended to projects to mark as out of scope for their bug bounty program,” and that “the actual list of out of scope impacts differ from program to program.” Audit firms draw their exclusions along broadly similar lines, but yours will be whatever your SOW says.
Read that list carefully before you assume it covers everything, because it contains an important carve-in. Immunefi excludes “Incorrect data supplied by third party oracles” while stating plainly that this is “Not to exclude oracle manipulation/flash loan attacks.” Bad oracle data is out. Manipulating the oracle is in. Firms differ on where they draw that same line, which is exactly why you ask.
Every item below is typically excluded unless explicitly contracted. All of them can be brought into smart contract audit scope. All of them cost more when you do.
Economic and Tokenomics Design Risk
Emission schedules, incentive alignment, liquidity depth assumptions, and whether your protocol survives a severe drawdown in collateral value. Auditors verify that the code implements your model. They rarely stress the model itself. Immunefi’s out-of-scope list names “basic economic and governance attacks” directly. Economic review is a distinct discipline with distinct practitioners, and it’s priced separately.
Oracle Assumptions, and Where the Line Actually Falls
This one is more nuanced than most buyer guides admit. Reviewers will check that you call your oracle correctly, handle staleness, and bound deviation. Whether your chosen feed has enough independent publishers, and whether your asset’s real liquidity supports the caps you set, are your assumptions to defend.
Manipulation itself is often in scope rather than out. Immunefi’s classification explicitly declines to exclude “oracle manipulation/flash loan attacks,” so do not assume a blanket exemption in either direction. Ask your firm to state in writing whether price manipulation via thin external liquidity is a finding they will raise or an assumption they will record.
Centralization and Admin Key Management
The report will note that an admin can pause, upgrade or drain. It usually stops there, and Immunefi lists “Impacts involving centralization risks” as out of scope by default. Key custody, HSM policy, signer geography, timelock duration and emergency-response runbooks are all governance and operational territory. A finding that says “owner has excessive privileges” is a description of your design, not a bug the auditor can fix.
Off-Chain Infrastructure, Frontend, and Indexers
Sherlock’s process guide names the excluded surface directly: “frontends, off-chain indexers, third-party dependencies the team is not modifying.” Your web app, your API keys, your DNS and your keeper bots go untouched by a contract review. Several of the most damaging incidents in this industry have been frontend and DNS events, and no contract audit would have caught them.
Governance Process and Parameter Setting
Quorum thresholds, proposal delay windows, delegation concentration, the possibility that a whale passes a hostile proposal legitimately. Immunefi groups governance attacks with basic economic attacks in its exclusions. Auditors check the governance contract. The governance process is a political system, and reviewing it requires a separate mandate.
Unmodified Third-Party Dependencies
Standard libraries you imported without changes are generally excluded from both the nSLOC count and the review, and Sherlock names them explicitly in the same exclusion list as frontends and indexers. If you’ve forked and modified a library, say so loudly during scoping, because modified code is your code now.
| Typically in scope | Typically out of scope unless contracted |
|---|---|
| Access control, roles, privilege escalation | Whether role-holders are trustworthy; key custody policy |
| Reentrancy, state-handling, CEI ordering | Reentrancy via integrations deployed after the freeze |
| Arithmetic, rounding, precision loss | Whether the economic formula itself is sound |
| External call handling, token non-conformance | Solvency and future behavior of integrated protocols |
| Proxy mechanics, storage layout, initializers | Logic deployed behind the proxy after the audit |
| Gas, DoS, griefing vectors | Sequencer downtime, sustained chain congestion |
| Oracle integration correctness and staleness | Whether your feed’s publisher set and liquidity depth are adequate |
| Governance contract logic | Governance process, quorum politics, delegation risk |
| Code you wrote and code you forked and modified | Unmodified third-party libraries (Sherlock) |
| On-chain contracts at the pinned commit | Frontend, API, DNS, indexers, keepers (Sherlock) |
| Tokenomics implementation | Basic economic and governance attacks (Immunefi) |
| Deployment scripts, when listed | Centralization risks (Immunefi) |
Confirm every right-hand row with your own firm. These are the common defaults across two published classification systems, and individual scopes vary.
The Engagement, Stage by Stage
The smart contract audit process is more standardized than the pricing is, which makes the stages a useful thing to check a proposal against. A proposal that skips or merges stages is usually describing a narrower smart contract audit scope than the price implies. Walk the smart contract audit process below against whatever SOW is on your desk.
Scoping Call and Commit Freeze
Thirty to sixty minutes. You walk the architecture, name your trust assumptions, and hand over documentation and test coverage numbers. The output is a file list, an nSLOC count, a day estimate, and a pinned commit. Get the file list in the SOW as an appendix. Our own smart contract audit engagements start here, and the file list is the artifact everything else hangs from.
Automated Tooling Pass
Runs first, takes hours, clears the floor of low-hanging findings so human time goes to logic. Any firm charging you senior rates for tooling output alone is selling you a report generator.
Manual Review, Where the Money Goes
The bulk of the cost. Engineers read code line by line, build a mental model of state transitions, write adversarial tests, and try to break the invariants you specified. This stage is why day estimates matter more than headcount claims.
Severity Classification and the Interim Report
Sherlock’s process guide describes findings ranked “critical, high, medium, low, and informational,” derived from likelihood combined with impact. Immunefi’s v2.3 tables use a four-tier Critical, High, Medium and Low scale with no informational tier, which is one reason two firms can rate the same bug differently. Ask which scale and which philosophy applies before findings land, because a report’s severity distribution is the first thing an investor reads.
Remediation Rounds and Re-Audit
You fix, they re-review. Sherlock’s pricing reference puts remediation at “$5,000 to $20,000 per pass” and states that “almost every protocol requires at least one remediation review after initial findings, and that cost should be budgeted at the outset rather than treated as a surprise.” Budget two. A fix that introduces a new bug is common enough that skipping the re-review is false economy.
Final Report, Public or Private
A public report signals maturity to exchanges, investors, and integrators. It also publishes your architecture, your acknowledged risks, and your unfixed low-severity findings to anyone curious. Keep it private when you’re pre-launch, when findings remain open, or when the report describes infrastructure you haven’t hardened yet. Publish once remediation is complete.
The Tooling Layer: What It Covers and Where It Stops
Static Analysis
Static analyzers parse your code without running it and flag known-bad patterns. Slither describes itself as “a Solidity & Vyper static analysis framework written in Python3” that “runs a suite of vulnerability detectors.” Aderyn is “a Rust-based solidity smart contract static analyzer.” Solhint “provides both Security and Style Guide validations.” Semgrep offers broader SAST coverage, though its Solidity support is still listed as experimental.
Expect noise, and expect to triage it. Slither’s own documentation claims “low false positives,” so the volume varies considerably by tool and configuration. Every credible smart contract auditing engagement runs these, and none of them constitutes an audit.
Fuzzing and Invariant Testing
Echidna is “designed for fuzzing/property-based testing of Ethereum smart contracts” and works “to falsify user-defined predicates or Solidity assertions.” Medusa is “a cross-platform go-ethereum-based smart contract fuzzer inspired by Echidna.” Foundry’s invariant testing “verifies properties that should always hold true, regardless of the sequence of actions taken.”
The catch sits in the phrase “user-defined.” Echidna’s docs specify that invariants are “expressed as Solidity functions with names that begin with echidna_.” A fuzzer can only violate invariants somebody wrote down. If you never specified that total shares must not exceed total assets, no amount of fuzzing hours will notice when it does. Property specification is the expensive intellectual work; running the fuzzer is the cheap part.
Formal Verification
Certora’s Prover “tests your code properties mathematically so you know they will hold given any contract state,” and unlike fuzzing, it “compiles your contract down into math to evaluate every possible contract state and contract path.” Halmos is “a symbolic testing tool for EVM smart contracts,” and hevm supports “symbolic execution, equivalence checking, and (symbolic) unit testing.”
Powerful for core accounting, liquidation math, and token conservation. Expensive, slow, and entirely dependent on the quality of the specification you write. Formal verification is normally a separate line item quoted on top of a standard smart contract security audit, so treat any proposal that implies it’s bundled with some skepticism.
Audit Firm vs Competitive Audit vs Bug Bounty
Firms give you accountability: a named team, a fixed window, a report you can hand to an exchange listing desk or a lead investor, and someone to call when a finding needs interpretation.
Competitive platforms put many eyes on the code with variable depth. Sherlock runs contests that “apply large-scale adversarial pressure to your code, with top auditors competing to surface the most impactful issues,” and reports over 11,000 registered security researchers. Cantina bills itself as “the most innovative and familiar platform for competitive code review” and reports $52.4M paid out across competitions. You get high findings volume and genuine breadth, plus a real triage burden on your side, because judging and deduplicating submissions consumes your engineers’ time.
One note on vendor currency
Code4rena, long the reference name in this category, announced its wind-down in May 2026, committing that “every active competition and bounty will be seen through to a full and proper close.” If a proposal or a checklist still lists it as an option, that document predates the announcement.
Bug bounties buy continuous coverage. Immunefi describes itself as “the trusted security layer of Web3” and reports protecting more than $190 billion across Web3. Payouts scale to funds at risk rather than headline TVL: Immunefi’s own guidance caps payouts “at 10% of funds at risk,” so “if you want the $500,000 payout, you’d have to definitively prove that $5,000,000 is at real, immediate risk.” No guarantee anyone looks at all.
| Option | Best for | What you actually get | Typical cost basis | Main weakness |
|---|---|---|---|---|
| Audit firm | Pre-launch, investor and exchange diligence | Named reviewers, fixed window, citable report | Priced per nSLOC and elapsed window | Point-in-time; bounded by scope |
| Competitive audit | Hardening before a high-TVL launch | Breadth of perspectives, large findings volume | Prize pool, set by you | Variable depth; heavy triage load |
| Bug bounty | Live protocols with real funds at risk | Continuous, adversarial, ongoing coverage | Payout scaled to funds at risk | No coverage guarantee; reactive |
For most protocols, the honest answer is a sequence rather than a choice: firm audit first, competitive audit before a major launch or a big TVL step-up, standing bounty from the day funds go live. Sequencing that against your runway is a planning exercise, and it’s the kind of thing our blockchain consulting practice maps out alongside launch timelines.
Non-EVM and Specialist Smart Contract Audit Scope
Non-EVM work changes methodology as well as price, which means smart contract audit scope has to be redrawn per language rather than translated. Sherlock’s pricing reference gives premiums over an EVM baseline, and any firm selling non-EVM smart contract audit services should be able to explain the methodology difference without prompting.
Rust and Solana
A rust smart contract audit is the most commonly mis-scoped engagement in this list, because teams assume EVM pricing carries across. It trades Solidity’s reentrancy taxonomy for account-model concerns. Solana’s program security course covers signer checks, which it describes as “essential to verify that specific accounts have signed a transaction,” alongside account data validation, owner checks, account type validation, and PDA bump canonicalization. A solana smart contract audit also covers cross-program invocation depth, which Solana caps at a maximum instruction stack depth of 5, or 9 under SIMD-0268, plus rent exemption (“Every account must hold a minimum lamport balance proportional to its data size to remain onchain”) and compute budget exhaustion against the 1,400,000 CU per-transaction ceiling. Sherlock puts the premium at “25 to 40 percent.”
Move (Sui and Aptos)
A move smart contract audit inherits strong resource safety from the language itself. The Move Book states that structs “are linear and ephemeral,” meaning they “cannot be copied, cannot be dropped, and cannot be stored in global storage” without explicit abilities. That compiler enforcement removes several EVM bug classes outright and shifts review effort toward capability handling, object ownership transitions and module upgrade policy. Sherlock groups Move with Cairo at “30 to 45 percent above EVM equivalents.”
Cairo and StarkNet
Different proving assumptions, a young tooling ecosystem, and field arithmetic that surprises engineers coming from 256-bit integers. The Cairo Book warns that “division of field elements (and therefore division in Cairo) is unlike regular CPUs division,” giving the example that “the value of 1/2 in Cairo is (P + 1)/2 (and not 0 or 0.5).” Same 30 to 45 percent band as Move.
ZK circuits
Under-constrained circuits are the defining risk. Veridise’s research on automated detection explains that such circuits “admit multiple witnesses for a given input, so a malicious party can generate bogus witnesses, thereby causing the verifier to accept a proof that it should not,” and notes that “several million dollars worth of cryptocurrency have been stolen due to underconstrained arithmetic circuits.” Reviewers need to read constraint systems rather than only application code. Sherlock puts ZK circuit audits at “80 to 120 percent above EVM baseline.”
Bridges
A bridge smart contract security audit spans two or more chains at once: message verification, replay protection, validator or relayer trust assumptions, finality mismatches, and the failure behaviour when one side halts. Scope must name both deployments and the off-chain relayer’s trust model explicitly, or half the attack surface goes unexamined by default.
Reading the Smart Contract Audit Report: Verifying You Got What You Paid For
A complete smart contract audit report contains six things. A scope section naming the repository, branch, and commit hash. A methodology section describing what the team did. Findings, each with a severity, a location, a description, and a status. Remediation responses from your team, with the fix commit. A disclaimer. An appendix listing every file reviewed.
Red flags read fast. No commit hash. No file list. Findings that are uniformly informational, which usually means nobody went deep. No remediation section, meaning nothing was verified as fixed. A severity scale with no definitions behind it, which lets a firm call anything “low.”
The same document reads three ways depending on who’s holding it. An investor reads the severity distribution and the remediation status, since open criticals kill deals. An exchange listing reviewer reads the scope section first, checking whether the audited commit matches the deployed bytecode. A prospective integrator reads the out-of-scope declarations and the stated assumptions, because those describe exactly the risk they’re about to inherit.
Budget: What a Smart Contract Audit Costs in 2026
Current Ranges
Older guidance still circulating puts audits well below the current market. Blockstack’s pricing guide is one example, pricing basic ERC-20 tokens at $1,500 to $5,000 and putting “intermediate-level contracts, such as staking contracts” at $5,000 to $15,000.” Compare that against the figures below before you use any of it as a negotiating anchor.
Sherlock’s smart contract audit pricing market reference, published 18 February 2026, gives the current picture. Treat it as a sanity check on any quote, since smart contract audit pricing varies more by firm reputation than by code quality.
| Engagement profile | Range (Sherlock, Feb 2026) |
|---|---|
| Simple ERC-20 token | $5,000 to $20,000 |
| Typical DeFi protocol audit | $25,000 to $100,000 |
| Mid-complexity protocol, realistic pre-launch budget | $60,000 to $120,000 |
| Enterprise, multi-chain engagement | $150,000+ |
| Full observed market range | $5,000 to $250,000+ |
Sherlock’s own wording, in order: “A simple ERC-20 token typically costs $5,000 to $20,000”; “most DeFi protocol audits landing between $25,000 and $100,000”; “A realistic pre-launch budget for a mid-complexity DeFi protocol in 2026 is $60,000 to $120,000”; “Enterprise multi-chain systems routinely exceed $150,000”; and “Smart contract audit costs range from $5K to $250K+ in 2026.”
Pricing figures verified August 2026 against the February 2026 Sherlock reference.
If your quote sits far below the band for your complexity tier, the smart contract audit cost isn’t the thing that’s been discounted. The reviewer-days have.
Premiums and Add-Ons
On top of the base, from the same Sherlock reference: Rust/Solana carries “a 25 to 40 percent premium,” while “Cairo (StarkNet) and Move (Sui, Aptos) sit at 30 to 45 percent above EVM equivalents.” ZK circuit audits “routinely run 80 to 120 percent above EVM baseline.” On timing, “urgency adds 20 to 40 percent to base fees.” Remediation passes “typically add $5,000 to $20,000 per pass.” Formal verification is a separate engagement with its own scope and its own quote.
Two practical notes. Rush fees buy calendar position rather than extra reviewer hours, since you’re paying a firm to displace another client. And the total smart contract audit cost on a real project is base plus one or two remediation passes, which is the line most first-time buyers forget when they compare quotes.
What “Cheap” Actually Buys
Free and sub-$5,000 smart contract audit services are usually static analysis output with a logo on the cover. You can identify one from the proposal alone, before any call:
- No named reviewers, only a company name
- No file list and no nSLOC count
- No methodology section
- Turnaround measured in days for a multi-thousand-line codebase
- A price that doesn’t move when you add contracts
Any two of those together is enough to walk.
Questions to Ask Before You Sign
- Which exact files, at which commit hash, and can that appendix go in the SOW?
- What is explicitly out of scope, covering economic design, oracle manipulation, admin key handling and off-chain components?
- Who are the named reviewers, and what have they audited in this language?
- How many reviewer-days, and how do they map to our nSLOC count?
- How many remediation passes are included, and what does an extra one cost?
- What are your severity definitions, and who makes the final call on a disputed rating?
Ask a smart contract audit firm all six. The ones worth hiring answer without hedging, and a smart contract audit firm that treats question two as adversarial has told you something useful. If you’re vetting a build partner and an auditor at the same time, our 12-point checklist for hiring a Web3 developer covers the engineering side of the same diligence.
After the Audit: Re-Audit Triggers, Monitoring and Scope Drift
“How often should smart contracts be audited” is the wrong shape of question. Re-audits are event-driven rather than calendar-driven.
The triggers: any contract upgrade, any new external integration, any parameter change that moves you into a different risk regime, any dependency version bump, any redeploy to a new chain. That last one catches people, because the same bytecode on a different chain meets different block times, different oracle infrastructure, different MEV conditions and different finality guarantees.
Scope drift accumulates quietly. Six months of small upgrades and your deployed system can share only a fraction of its code with the version that got reviewed. Keep a written record of every change made since the audited commit; it turns your next scoping call into a twenty-minute conversation. Firms handling ongoing smart contract audit work will ask for exactly that log.
Monitoring is the layer a blockchain security audit structurally cannot provide. Real-time invariant checks, anomaly alerting on TVL and privileged calls, a pause runbook with named humans on rotation, and a documented incident-response path. An audit tells you what your code did on one day. Monitoring tells you what it’s doing now, and no blockchain security audit, however wide the smart contract audit scope, substitutes for it.
Conclusion: Buy the Boundary Rather Than the Badge
An audit is a scoped, time-boxed review of a fixed commit by named engineers. It’s one of the highest-value things you’ll buy before launch, and it comes with a hard edge that every honest firm will describe if you ask.
Three fixes for your next statement of work. Get the file list into an appendix with the commit hash, the exclusions written down, covering economic design, oracle assumptions, admin key custody, frontend and off-chain infrastructure, and unmodified dependencies. And then get the number of included remediation passes stated in numerals.
Do those three things and your smart contract audit scope stops being an assumption and becomes a document. That’s the difference between a review you can hand an exchange and a PDF you hope nobody reads closely.
FAQs
What does a smart contract audit cover?
A standard audit covers code-level vulnerability classes at a pinned commit: access control and privilege escalation, reentrancy and state handling, arithmetic and rounding errors, external call handling, proxy and storage layout issues, and gas or denial-of-service vectors. Reviewers combine automated tooling with manual line-by-line reading and adversarial testing against your specified invariants.
What is NOT covered by a smart contract audit?
Economic and tokenomics design, admin key custody, governance process, frontend and off-chain infrastructure, and unmodified third-party libraries are typically excluded unless explicitly contracted. Immunefi’s recommended bug bounty defaults list centralization risks and basic economic and governance attacks, while Sherlock names frontends and off-chain indexers. Exclusions vary by firm, so ask in writing.
Is oracle manipulation covered by an audit?
Less clear-cut than most guides suggest. Immunefi’s default bug bounty exclusions cover “incorrect data supplied by third party oracles” while stating this is “not to exclude oracle manipulation/flash loan attacks.” Auditors reliably check your integration code, staleness handling and deviation bounds. Whether they underwrite your feed’s manipulability varies by firm, so get it in writing.
How much does a smart contract audit cost in 2026?
Sherlock’s February 2026 market reference puts most DeFi protocol audits at $25,000 to $100,000, a realistic mid-complexity pre-launch budget at $60,000 to $120,000, and enterprise multi-chain engagements above $150,000. A simple ERC-20 token runs $5,000 to $20,000. The full range reaches $250,000 and beyond.
How long does a smart contract audit take?
Duration tracks code size. Sherlock’s figures give roughly a 3-day contest window for about 500 nSLOC, around 18 days at 3,000 nSLOC, and about 38 days at 6,000. Read those as elapsed calendar windows rather than reviewer-days, since a contest runs researchers in parallel. Add scheduling lead time plus remediation.
How often should smart contracts be audited?
Treat re-audits as event-driven. Trigger one on any contract upgrade, any new external integration, any parameter change that shifts your risk regime, any dependency version bump, and any redeploy to a new chain. Calendar-based annual reviews miss upgrades and catch nothing when the code hasn’t changed.
Does an audit guarantee my protocol is secure?
No. An audit reduces risk on the code it read, at the commit it read, within the scope it declared. Findings outside that boundary aren’t the auditor’s to catch. Pair the audit with monitoring, an incident response runbook, a standing bug bounty and disciplined re-audits on every material change.
Should I use an audit firm, a competitive audit, or a bug bounty?
Most protocols need all three in sequence. A firm gives you named reviewers, a fixed window and a citable report. A competitive audit on Sherlock or Cantina adds breadth before a major launch. Note that Code4rena announced its wind-down in May 2026, so older vendor checklists are out of date.
What should I do if I need to change code after the audit starts?
Tell the firm immediately and expect a chargeable re-pin. Reviewers must re-read changed files, re-run tooling and re-validate findings already written. Silent pushes are worse, because the report will reference a commit that no longer matches what you deploy, which exchanges and integrators will notice.
How do I choose a smart contract audit firm?
Check named reviewers and their prior work in your language rather than only the company logo. Require a file list, an nSLOC count and a day estimate, a written exclusions section, defined severity criteria, and stated remediation passes. Ask for two recent public reports in your domain and read the scope sections first.