Guides What a smart contract audit costs, and why

An audit is a fixed amount of expert attention applied to your code. Understanding what consumes that attention is the way to predict the price — and to get more for it.

What auditors price on

• Lines of code in scope, usually counted without comments and tests.
• Complexity: heavy mathematics, assembly, unusual token behaviour, or many contracts interacting.
• Novelty: a fork of a well-reviewed protocol with small changes takes less time than a new mechanism.
• External integrations: oracles, bridges and other protocols each widen what has to be reasoned about.
• Language and chain: Solidity on an EVM chain has the widest pool of reviewers; other stacks have fewer.
• Urgency: audit firms are booked ahead, and a rush costs more.

Notice what is not on the list: the value the contract will hold. That value should decide how much review you buy — one audit or two, a competition, a bounty — not the price of each.

The kinds of review

• Traditional audit: a small team from one firm reviews a frozen codebase over an agreed period and writes a report.
• Competitive audit: many independent researchers review the code during a fixed window for a prize pool. Breadth is high; depth varies.
• Formal verification: selected properties are proven mathematically. Valuable for core accounting logic, expensive to apply everywhere.
• Bug bounty: a standing reward for vulnerabilities reported after launch.
• Pre-audit review: a second team reads the code adversarially before the external audit begins.

What makes an audit cost more than it should

Auditors lose time — time you are paying for — when the code changes during the review, when nothing documents the intended behaviour, when tests are missing so basic behaviour has to be established by hand, and when the scope includes code that could have been deleted. Every hour spent working out what a contract is supposed to do is an hour not spent finding out how it fails.

How to spend less and get more

• Freeze the code at a tagged commit before the audit starts.
• Write down the invariants: what must always be true, in plain language.
• Reach high test coverage, including fuzz and invariant tests, and make the suite easy to run.
• Run static analysis and fix or explain every finding beforehand.
• Cut scope: delete unused code, and use well-reviewed libraries unmodified where you can.
• Have someone who did not write the code review it first.

Budget for what comes after the report

The report is the midpoint. Fixes have to be written, tested and reviewed again, and a fix that changes the design may need more review time than the original finding. Leave room for that in the launch plan. Then plan for the next change: any upgrade that touches audited code needs review again, in proportion to what changed.