What a Smart Contract Audit Actually Covers

If you are about to hire an auditor, or you are deciding whether to trust a protocol because it says “audited”, the question is the same: what did the review actually look at? This guide explains what an audit covers, what it leaves out, what it costs and how to read a report so you know what the word is worth.

What does a smart contract audit do?

An audit is a time-boxed security review of smart contract source code. Auditors read the code line by line, compare it with the documentation that describes what it should do, and try to find ways it can be made to do something else: drain funds, lock funds, bypass access controls, or behave differently from what users are told.

Because deployed contracts are hard or impossible to change, finding problems before launch is far cheaper than fixing them afterwards. That is the whole point of the exercise.

What an audit covers

A credible engagement usually includes these parts. The detail varies by firm, so ask for each one in writing.

• Scope definition. The exact repository, commit hash and list of contracts under review. Everything else is out of scope.
• Manual review. Engineers read the code and reason about how it can fail. OpenZeppelin, for example, says it assigns at least two auditors to the same codebase so each issue is seen twice.
• Automated analysis. Static analysers and fuzzers (tools that throw large numbers of random inputs at the code) catch classes of bug that people miss.
• Common vulnerability classes. Reentrancy, broken access control, unchecked external calls, oracle manipulation, rounding and accounting errors, and input validation.
• Business logic. Whether the code does what the specification says, which is where many of the expensive bugs live.
• A severity-ranked report. Findings rated Critical, High, Medium, Low or Informational, each with a description and a recommended fix.
• Fix review. The auditor checks the team’s fixes. Many firms include one round only, so further changes cost extra.

Some engagements add formal verification, a mathematical proof that specific properties of the code always hold. Ethereum’s developer documentation notes that formal verification can prove the absence of certain errors, which ordinary testing cannot.

What an audit does not cover

This is the part most audit marketing leaves out. Unless the report says otherwise, assume these are outside the review:

• Code that changed after the audit. New features, upgrades and “small” patches are not covered by the original report.
• Off-chain components. Front ends, back-end servers, bots, keepers, bridges and APIs that the contracts rely on.
• Key management and admin powers. Who holds the owner or upgrade keys, whether a multisig or timelock protects them, and what those keys can do.
• Economic design. Whether the incentives, token model or liquidation logic hold up under stressed markets, unless an economic review was part of the scope.
• Third-party dependencies. External protocols, oracles and libraries are usually trusted, not re-audited.
• Deployment. Whether the contracts were deployed with the same code and settings that were reviewed.

Ethereum’s own security guidance is blunt about it: audits will not catch every bug and should not be treated as a silver bullet.

Why audited protocols still get exploited

Euler Finance is the standard example. In March 2023 an attacker took about $197 million from the lending protocol, which had been reviewed by several audit firms. According to Rekt’s write-up, the flaw sat in a donation function added in a later code update, and Sherlock, which had reviewed that update, later paid a $4.5 million claim under its audit coverage, as reported by The Block. The lesson is not that audits are worthless. It is that an audit covers a snapshot, and every change after it reopens the risk.

Other common reasons audited code fails: the exploited contract was never in scope, the team deployed different code from what was reviewed, a high-severity finding was acknowledged but not fixed, or the failure was operational (a stolen key) rather than a code bug.

How much does a smart contract audit cost?

Most firms do not publish prices, because the quote depends on the amount and complexity of code, the number of engineers, the deadline and whether re-audits or formal verification are included. Treat any range as directional and get a scoped quote. A price far below the market usually means fewer engineer-days, a single reviewer or mostly automated output.

What an audit costs in 2026

One of the few firms that publishes figures is the audit firm Sherlock. Its pricing post, Sherlock’s 2026 market reference (18 February 2026, checked 18 October 2026), gives these bands. They are a vendor’s own figures, not independent survey data:

The same post names the main cost drivers: code size, priced in nSLOC (non-comment source lines of code), is the biggest; Rust-based Solana programs carry a 25 to 40 percent premium because fewer reviewers can audit them; and urgency adds 20 to 40 percent.

How long does a smart contract audit take?

Sherlock ties duration to code size rather than a fixed number of weeks: roughly 3 days for 500 nSLOC, around 18 days for 3,000 nSLOC and about 38 days for 6,000 nSLOC, on its contest model. Add time for your team to fix findings and for the fix review.

A worked budget, using those figures: a mid-complexity lending protocol of about 3,000 nSLOC would fall in the $40,000 to $100,000 band and take about 18 days, plus one re-audit pass at $5,000 to $20,000, so $45,000 to $120,000 in total. Needed in a hurry, the same audit could cost 20 to 40 percent more; written in Rust for Solana, another 25 to 40 percent.

Is a smart contract audit mandatory?

Not as a general legal requirement in most jurisdictions. In practice, many exchanges, launchpads and institutional partners ask for a recent, public audit before they list a token or integrate a protocol, so for most launches it is a commercial requirement.

Audit models: private firm, collaborative review or contest

Audits are sold in four main formats, and many launches combine two of them:

Firms that appear often in published audit reports include OpenZeppelin, Trail of Bits, Spearbit/Cantina, Sherlock, Code4rena, Zellic, Cyfrin, Halborn and CertiK; this is an illustrative list, not a ranking or recommendation. The smart contract development comparison shows how audit and exploit records were checked for 12 builders. Use the questions in our guide to smart contract auditors to compare them, rather than the size of their client list.

How to prepare your code for an audit

1. Freeze the code on a single commit and agree that nothing changes during the review.
2. Write documentation: what each contract should do, who can call what, and which assumptions must always hold.
3. Ship a test suite that runs cleanly, ideally with fuzz or property tests for the core accounting.
4. List your dependencies, admin roles and upgrade mechanism so the auditor can judge them.
5. Book time for fixes and the fix review before launch, not after.

Teams that arrive with unclear code and no tests spend part of an expensive audit paying engineers to understand the basics. If an outside studio is writing the contracts, make audit readiness part of the contract; see how to vet a blockchain development studio.

How to read an audit report as a user or buyer

• Is the report public, from the auditor’s own site, and dated?
• Does the scope name the commit and contracts that are actually deployed today?
• Does the verified source on the block explorer match the audited commit?
• Were all Critical and High findings fixed and confirmed in the fix review, not just “acknowledged”?
• Has the code been upgraded since, and was the upgrade reviewed?
• Who controls admin and upgrade keys, and is there a timelock or multisig?
• Is there an active bug bounty that scales with the funds at risk?

A logo on a homepage with no report behind it is not evidence of anything. A report that covers last year’s code is evidence about last year’s code.

Worked example: reading one audit report

An illustrative report for a staking contract, read in the order that matters:

1. Cover page. Auditor, client, review dates and a commit hash. The report is dated six months before launch, which is fine if nothing changed since.
2. Scope table. Four contracts are listed; the rewards distributor that went live later is not. That contract is unaudited, whatever the homepage badge says.
3. Findings summary. One High, three Medium, five Low. The High is an accounting error that let a user claim rewards twice.
4. Status column. The High and two Mediums are marked “Fixed” with a fix-review commit; one Medium is “Acknowledged”, meaning the team accepted the risk. Read why.
5. Deployed code. On the block explorer, the verified source matches the fix-review commit for the four audited contracts.

Conclusion for this example: the four contracts are covered as fixed, one accepted risk needs a decision, and the rewards distributor needs its own review before you rely on it.

Is an audited protocol safe?

For a team, an audit is one layer: alongside it you need tests, careful key management, monitoring after launch and a bug bounty. For a user or partner, an audit is a reason to read further, not a reason to stop. Our methodology explains how we weigh audits and incident history when we assess providers, and you can browse all topics for related guides.