Contract audits

Why smart contracts get audited

Most software can be fixed after a bug is found. A smart contract on a public chain usually cannot. ethereum.org notes that deployed contract code usually cannot be changed to patch security flaws, and estimates that the value stolen or lost to security defects in smart contracts is easily over $1 billion ^[1]. The code often holds money directly, it is public for anyone to study, and an attacker needs to find only one mistake.

That combination is why contracts that hold value are reviewed by specialists outside the team that wrote them, before they are deployed. The question is not whether to have that review, but what it can and cannot do for you.

What an audit does

An audit is a time-boxed review of a specific version of your contracts by security engineers who did not write them. A typical engagement looks like this.

1. 01

   Scope

   The auditors agree which contracts, at which commit, are in scope, and read your documentation on what the system is meant to do.

2. 02

   Manual review

   Experienced reviewers read the code line by line, looking for known classes of vulnerability (reentrancy, access control mistakes, unchecked calls, arithmetic and rounding errors) and for logic that does not match the stated intent.

3. 03

   Automated analysis

   Static analysers, fuzzers and sometimes formal tools search for patterns and edge cases a person might miss.

4. 04

   Report

   Findings are listed by severity, from critical to informational, each with an explanation and a recommended fix.

5. 05

   Fix review

   Your team fixes the findings, and the auditors check the fixes. The final report states which findings were resolved, acknowledged or left open.

The flaws auditors find most, in plain language

• Reentrancy: the contract sends funds or calls another contract before updating its own records, and the other contract calls back in to take the same funds again.
• Access control: a function that should be restricted to an administrator can be called by anyone, or an administrator role can be taken over.
• Price manipulation: the contract reads a price from a source an attacker can move within one transaction, such as a thin trading pool.
• Rounding and precision: small errors in division that an attacker repeats thousands of times, or that let a first depositor distort shares for everyone after.
• Upgrade mistakes: a proxy pointing at the wrong code, storage that collides between versions, or an initialiser anyone can call.
• Logic that does what the code says but not what the business meant: a fee taken twice, a deadline checked the wrong way round.

What an audit does not cover

ethereum.org is direct about this: audits will not catch every bug, and are mostly designed to provide an additional round of review ^[1]. Beyond that, most audits are scoped to the contract code alone. Plenty of losses come from somewhere else.

How to read an audit report

1. 01

   Check the commit

   The report names the exact version reviewed. Make sure it matches what you deployed, byte for byte, and that the deployed contracts are verified on chain.

2. 02

   Read the scope and the assumptions

   Which contracts were in, which were out, and what the auditors assumed about admins, oracles and other contracts.

3. 03

   Look at the status of every finding

   Resolved, acknowledged or open. An acknowledged critical finding is a business decision someone should be able to explain.

4. 04

   Read the informational notes too

   They often describe design choices the auditors found risky but not wrong, which is useful for your next version.

How to prepare, so the audit is worth it

Auditors' time is scarce and expensive, so every hour they spend understanding unclear code or finding bugs your tests should have caught is an hour not spent on the subtle problems you are paying them for. OpenZeppelin's readiness guide sets out what it expects before an audit.

• Documentation that explains the intent, the design choices and the assumptions, from a README and architecture notes down to comments on each function ^[2].
• Tests that cover edge cases and integration with other contracts, aiming for at least 90% code coverage, with fuzzing where it helps ^[2].
• Clean, readable code that follows a consistent style, uses established patterns such as checks-effects-interactions, and imports dependencies through a package manager rather than copying them ^[2].
• Code that is mature: tested, documented and ready to deploy, rather than still changing ^[2].

We add two habits of our own. The code is frozen at a tagged commit for the duration of the audit, and every fix afterwards goes through the same review and test suite as the original work before the auditors see it.

Checklists and standards, and their limits

Checklists help both sides agree on what was checked. They also age. The Smart Contract Weakness Classification registry, long a common reference, states that its content has not been thoroughly updated since 2020 and may be incomplete, and points readers to the EEA EthTrust Security Levels specification and the Smart Contract Security Verification Standard instead ^[3]. Ask any auditor which standard they check against, and treat a finding list mapped only to an old registry with some caution.

No checklist replaces understanding. Consensys Diligence's guidance starts from the premise that defending against known vulnerabilities is not enough, and that contract development needs the discipline of fields like financial systems, preparing for failure and rolling out carefully ^[4].

Security beyond the audit

An audit is a snapshot. The contract will run for years, the code around it will change, and attackers will keep studying it. The practices below are what keep a system safe between audits, and most of them cost little compared with what they protect.

• Property-based tests and fuzzing that keep running as the code changes, alongside unit tests ^[1].
• Formal verification for the most critical invariants, where the cost is justified ^[1].
• A bug bounty after launch, so people who find a problem are paid to report it rather than exploit it ^[1].
• A gradual rollout: limits on deposits or users at first, raised as the system proves itself ^[4].
• An emergency pause and an upgrade path, if the design allows them, controlled by a multi-signature wallet with a timelock so changes are visible before they take effect.
• Monitoring of on-chain activity and alerts on unusual transactions, with a written plan for who does what if something goes wrong.

Two web3 projects, priced from our rate card

The worked examples below show the range from our rate card today, with the hours by role and the payment schedule. The build includes our own testing and internal security review. An external audit, where the contract warrants one, is quoted by the audit firm and billed up front at cost, outside the milestones.

Choosing an auditor

1. 01

   Read their public reports

   Reputable firms publish past reports. Look for clear findings, sensible severities and honest scope sections.

2. 02

   Ask who will do the work

   The names and experience of the reviewers on your engagement matter more than the brand.

3. 03

   Agree the scope in writing

   Which contracts, which commit, which assumptions, and whether a fix review is included.

4. 04

   Match the effort to the risk

   A contract that will hold significant value may justify more than one independent audit. A simple contract built on audited libraries may need less.

5. 05

   Book early

   Good auditors are booked weeks ahead. Schedule the audit when you start building, not when you finish.

We build and test contracts, review them internally, help you choose and brief an auditor, and fix the findings. We do not audit our own work and call it independent.