A smart contract audit is an independent security review of a contract's code, design and assumptions, carried out before deployment to find vulnerabilities the developers missed. Ethereum.org calls it one way of conducting an independent code review and warns that audits "won't catch every bug," per its smart contract security page. The same page estimates that value stolen or lost to smart contract defects is easily over $1 billion.
This page covers how a security audit runs from scope to fix review, the main audit formats, what audits cost based on figures auditors publish themselves, and the tools that do the automated part of the work. Every claim comes from ethereum.org, the auditors' own pages or the tools' repositories, fetched on October 13, 2026.
What does a smart contract audit check?
An audit checks whether a contract does what its specification says and nothing else an attacker could exploit. Reviewers look at access control, upgrade paths, external calls, oracle use and economic assumptions, not just syntax. The output is a report of findings ranked by severity, with recommended fixes for each.
Trail of Bits, which publishes its methodology, says most catastrophic blockchain failures live in architecture layers such as upgrade paths, access control, oracle integration, governance and cross-chain message flow rather than in inner contract logic, per its blockchain services page. Classic code-level bugs still matter: ethereum.org walks through reentrancy, where a balance is not zeroed until after an external call, which lets an attacker withdraw repeatedly, on its security page. That page cites the 2016 DAO hack, in which 3.6 million ETH was stolen.
How does the audit process work?
Most firm-led audits follow five stages: scope and threat model, design review, implementation review with tooling, invariant testing, then reporting and fix review. The client freezes a commit, the auditors work against that exact code, and the team fixes findings before a final retest.
Smart contract audit lifecycle (stages per Trail of Bits' published process) [1 Scope + threat model] -> [2 Design / upgradeability review] | | v v [3 Implementation review: manual + Slither / Medusa / Echidna] | v [4 Invariant tests + exploit proofs for serious findings] | v [5 Report: severity, difficulty, exploit scenario] -> team fixes -> fix-review retest
The stages are taken from the engagement outline on the Trail of Bits blockchain page, which says its written report gives severity, difficulty and an exploit scenario for every finding, and that it re-tests patches when the work returns. Ethereum.org adds the client's side of the job: document the code with NatSpec, run analysis tools before every merged pull request and arrive with tests, so auditors spend their time on logic rather than basics, per its security guidance.
What types of smart contract audits are there?
Audits come in four common formats: a private engagement with one firm, a competitive audit contest open to many researchers, a collaborative audit that mixes the two, and a bug bounty after launch. Formal verification is a separate technique that proves specific properties rather than searching for bugs.
Format | How it works | Examples | Source |
Private firm audit | A fixed team reviews a frozen commit and issues a report | OpenZeppelin, Trail of Bits, ConsenSys Diligence, Nethermind | |
Competitive audit contest | Many researchers compete for a fixed prize pool over a set window | Code4rena, CodeHawks, Sherlock audit contests | |
Collaborative audit | Expert-led private audit with multiple auditors | Sherlock collaborative audits, Cantina hybrid audits | |
Bug bounty | Ongoing rewards for vulnerabilities found in deployed code | Immunefi, HackerOne, HackenProof | |
Formal verification | Mathematically proves stated properties hold | Certora Prover, Solidity SMTChecker, solc-verify |
Ethereum.org recommends sizing bug bounty payouts in proportion to the funds at stake, an approach it calls the scaling bug bounty, per its security page. Several firms now add AI review: Sherlock markets an Audit Engine that coordinates AI security approaches against client code, per Sherlock.
How much does a smart contract audit cost?
Most audit firms do not publish rate cards; they quote per engagement after scoping. Cost tracks the amount and complexity of code, the number of reviewers and the number of weeks. The clearest public price signals are contest prize pools and published effort data, which give a realistic range.
Private firms ask for a quote: OpenZeppelin's audit page directs buyers to talk to a security expert, per OpenZeppelin, and Trail of Bits uses a request-a-quote form, per Trail of Bits. Effort is the main cost driver. As of October 2026, the Trail of Bits publications repository lists 473 blockchain security reviews, with 2,137 person-weeks logged across the 471 that report effort, or about 4.5 person-weeks per review. Its blockchain reviews dated July to September 2026 range from 0.4 person-weeks for the Offchain Labs Tip Collection Toggler to 24 person-weeks for the Offchain Labs Arbitrum ArbOS 60/61 upgrade.
Contest platforms publish their prize pools. Code4rena contests run between December 2025 and May 2026 carried a $135,000 USDC pool for the K2 lending audit (April 17 to May 27, 2026), $101,000 for the LayerZero Stellar endpoint (April 1 to 14, 2026), $40,000 for Rujira (December 16, 2025 to January 16, 2026), $22,000 for Monetrix (April 24 to May 4, 2026) and $4,000 for an Intuition mitigation review (April 2 to 6, 2026). Mitigation reviews, which retest fixes, sit at the low end.
Cost signal (contests Dec 2025 to May 2026) | Figure | Source |
Code4rena K2 audit pool (Rust, Stellar) | $135,000 in USDC | |
Code4rena LayerZero Stellar endpoint pool | $101,000 in USDC | |
Code4rena Monetrix pool (Solidity) | $22,000 in USDC | |
Code4rena mitigation review pool | $4,000 in USDC | |
Trail of Bits average effort per blockchain security review (Oct 2026) | About 4.5 person-weeks |
Which smart contract audit tools do auditors use?
Auditors pair manual review with three classes of tools: static analyzers that scan source code for known bug patterns, fuzzers that throw generated inputs at contracts to break stated properties, and formal or symbolic tools that reason about every possible path. Teams can run all of them before an audit.
Tool | Type | Notes | Source |
Slither | Static analysis | Solidity and Vyper framework in Python; average under 1 second per contract | |
Echidna | Fuzzing | Haskell property-based fuzzer for Ethereum contracts | |
Foundry (forge) | Fuzzing | Automatically fuzzes Solidity test functions that take parameters | |
Mythril | Symbolic analysis | EVM bytecode tool using taint analysis, concolic analysis and control flow checking | |
Aderyn | Static analysis | Rust-based analyzer from Cyfrin | |
Certora Prover | Formal verification | Specifications written in CVL |
Slither and Echidna both come from Trail of Bits, which says it uses them, plus its Medusa fuzzer, in every engagement, per its services page. Echidna uses Slither to extract information before a fuzzing campaign, per the Echidna README. Solidity also ships a built-in SMTChecker for model checking, per Ethereum.org formal verification docs; see What Is Solidity? for the language itself.
How should a team choose an auditor?
Match the format to the risk. Code that will hold significant value usually gets a private audit plus a contest or bounty, because the formats find different bugs. Smaller or lower-value code may get by with tooling, internal review and one contest. Upgrades and new modules need fresh review either way.
If the contracts will custody user funds, book a private audit, then run a contest or open a bounty sized to the funds at stake.
Else if the code is a small module on audited libraries, run Slither and fuzz tests first, then consider a short contest or mitigation review.
If the system spans bridges, oracles or offchain services, pick a firm that scopes the full system, not only the contracts.
If the contracts are upgradeable, budget for a review of every upgrade, not only the first deploy.
Where smart contract audits fall short
An audit is a time-boxed review of one commit by a limited number of people. It lowers risk but does not certify code as safe, and its value decays as soon as the code changes. Ethereum.org treats audits as one layer among several.
No audit catches everything. Ethereum.org says audits are mostly an additional round of review and should not be treated as a silver bullet, per its security page.
Deployed code is hard to patch. The same page notes that contract code at an address cannot be changed after deployment, so a missed bug may need a migration or upgrade path that was planned in advance.
Scope gaps. Trail of Bits says failures often emerge between layers, per its methodology, so a contracts-only audit can miss the riskiest parts of a system.
Frequently asked questions
How long does a smart contract audit take?
Effort varies widely. Trail of Bits' blockchain security reviews dated July to September 2026 logged 0.4 to 24 person-weeks each, per its publications repository.
Is an audit the same as a bug bounty?
No. An audit reviews code before launch; a bug bounty rewards findings in deployed code, per Ethereum.org security docs.
Can I audit my own contracts with free tools?
Yes, as a first pass. Slither installs with pip, per its README, and Foundry fuzzes parameterized tests automatically, per the Foundry docs. That complements an independent audit rather than replacing it.
Does an audit make a contract safe?
No. Audits reduce risk, but ethereum.org states they won't catch every bug, per its security guide.
Related reading
Methodology and sources
Process, cost and tool details come from ethereum.org, auditors' own pages and tool repositories, fetched October 13, 2026. Cost figures are published contest pools and effort data, not quotes. The 4.5 person-week average divides the person-weeks logged for blockchain security reviews in the Trail of Bits publications repository (its Blockchain Reviews section plus the blockchain clients under Major Clients) by the reviews that report effort. Code4rena pools and dates come from each contest's own page.
Ethereum.org: Smart contract security, fetched October 13, 2026
Ethereum.org: Testing smart contracts, fetched October 13, 2026
Ethereum.org: Formal verification, fetched October 13, 2026
Trail of Bits: Blockchain security, fetched October 13, 2026
Trail of Bits: Publications repository, fetched October 13, 2026
OpenZeppelin: Security audits, fetched October 13, 2026
Code4rena: Audits, fetched October 13, 2026
Sherlock, fetched October 13, 2026
Cantina, fetched October 13, 2026
Slither README and Echidna README, fetched October 13, 2026

