Smart contract audits: process, cost and what gets found

Deployed contract code is immutable and holds value directly. There is no patch on Tuesday and no rollback. That combination is why auditing exists as a distinct discipline in this space, and why the economics of getting it wrong are so unlike ordinary software.

What actually happens

A serious audit runs in phases rather than as one pass.

Scoping fixes exactly which contracts and which commit are under review. Scope creep mid-audit is how things get missed.

Specification review comes before any code reading. The auditors need to know what the protocol is supposed to do economically — who can do what, under which conditions, and what invariants must always hold. Without that, they can only find generic bugs, not the ones specific to your design.

Manual review is the core of it. Experienced reviewers read the code adversarially, asking what happens if this is called twice, in a different order, by a contract rather than a wallet, in the same block as this other call.

Tooling runs alongside — static analysis, fuzzing against stated invariants, and increasingly symbolic execution. Tools catch known patterns cheaply. They do not catch design flaws.

Reporting and remediation. Findings are rated by severity with reproduction steps. You fix, they retest. The retest matters: a report describing fixed issues means nothing without confirmation they were fixed correctly and nothing new was introduced.

What gets found, in rough order of frequency

Access control. Functions that should be restricted are not, initialisers can be called again, ownership transfer is single-step and can be sent to an address nobody controls, or a privileged role can do more than the documentation implies.

Arithmetic and rounding. Division before multiplication losing precision, rounding that consistently favours one party, fee calculations that can be gamed by splitting a transaction, unchecked blocks reintroducing overflow.

External call ordering. State updated after an external call rather than before, enabling reentrancy — still, years after the pattern became famous. Also unchecked return values and calls to addresses that can behave arbitrarily.

Oracle and price assumptions. Spot prices read from a pool that can be moved within one transaction, single-source oracles, missing staleness checks on feeds.

Economic design flaws. The contracts do exactly what they were written to do, and what they were written to do can be exploited profitably. These are the most damaging and the least likely to be caught by tooling.

What it costs

For a straightforward token or staking contract, expect roughly $5,000–15,000 and one to two weeks. A mid-size DeFi protocol with several interacting contracts and non-trivial economics runs $25,000–75,000 over three to six weeks. Large or novel protocols go well beyond that, and are often audited by more than one firm.

Price tracks reviewer time, and reviewer time tracks complexity — specifically the number of interacting components and how unusual the economic design is. A protocol that resembles well-understood patterns audits faster than one that does not.

What an audit does not give you

It does not certify that your contracts are safe. It says that specific people, in a specific window, looking at a specific commit, found these things. Deploy different code and the report no longer applies.

It does not cover your frontend, your keys, your deployment process, or your multisig practice. A significant share of losses in this space come from compromised deployment keys and social engineering, neither of which a contract audit examines.

It does not validate your economics under adversarial market conditions. That is closer to modelling than auditing, and it is a separate engagement.

Before you commission one

Get your own tests to a state you are not embarrassed by. Auditors spending the first week discovering your contracts do not compile cleanly are billing you to do work you could have done. Freeze the code. Write the specification, including the invariants you believe must always hold — the act of writing them down frequently finds the bug on its own.

---

We build and review blockchain systems, and we tell clients when a protocol does not need one at all. See our blockchain engineering work, do you actually need a blockchain?, or ask us to scope a review.