9 Nov 2026/ Chuks Agu

Smart Contract Audit Checklist: 15 Fixes to Make Before You Pay for an Audit in 2026

Your audit slot opens Monday. The repo is still taking pull requests, nobody has written down what the contracts must never do, and the first paid days will go to questions a README should have answered.

That is the most expensive way to buy a blockchain security audit, and a smart contract audit checklist exists to prevent it. The audit firms’ own prep guides list the right items. Yet they are written for the developers doing the work, and none says what a skipped item costs the person paying.

We run smart contract audits, so this is the list we wish every client handed us on day one. It covers 15 fixes, how to check each one without reading Solidity, what skipping it costs, and a readiness score to run before you request quotes.

Fix the repo first. Then book.

Key Takeaways

Freeze one commit hash before the audit starts, because code that changes mid-engagement invites a paid re-audit.
Reach at least 90% test coverage on a fresh install, which OpenZeppelin treats as a sign of effort, not proof of correctness.
Hand over a threat model and a privileged-role map, or your blockchain security audit spends paid hours working out who can do what.
Book the fix review the day you book the audit, because an unbooked review delays launch.

What a “Smart Contract Audit Checklist” Actually Means in 2026
Why Prep Decides What the Audit Is Worth
The 15-Point Smart Contract Audit Checklist
dApp Audit Prep: The Front-End and Off-Chain Items Auditors Skip
Solidity Audit Prep: The Language-Specific Items
Score Your Readiness: The Smart Contract Audit Checklist Test
Red Flags: Why Smart Contracts Fail Security Audits
Internal Review vs. Automated Tools vs. Audit Firm
Conclusion
FAQs
Related Reading

What a “Smart Contract Audit Checklist” Actually Means in 2026

A smart contract audit checklist is a pre-audit list of fixes that freezes the code, documents its intent, and proves its tests pass, before a paid auditor starts work.

It is preparation for the review, not a substitute for it. It is the buyer’s work, not the auditor’s method, and it will not teach you how to audit a smart contract.

The fixes cover scope, evidence (tests and specs), and operating context (roles, upgrades, and deployment). Prepared code lets auditors spend paid hours on logic and economic attacks, which is where smart contract security is decided.

A Web3 security audit is the umbrella term for that review. Still deciding whether you need one? Read what a smart contract audit is.

Why Prep Decides What the Audit Is Worth

According to CertiK’s H1 2026 Hack3D report, Web3 security incidents cost $1.32 billion in the first half of 2026, down 46.8% year on year. Code vulnerabilities caused 204 of those incidents, more than any other vector. TRM Labs counted 207 hacks in the same half, up from 83 a year earlier, and 125 of them were smart contract exploits.

Fewer dollars lost does not mean fewer exploitable contracts.

Auditors price by scope and time, so every hour spent asking what a function does is not spent on attack paths. An unprepared repo costs you a padded quote, a report full of hygiene findings, and a re-audit when code changes mid-engagement.

Prep buys auditor attention.

The 15-Point Smart Contract Audit Checklist

The table covers the smart contract security work an auditor expects to see done before day one. Forward it to your developers, then use the items below to check their answers.

Item	How a founder verifies it	Cost of skipping
1. Freeze the commit hash	The statement of work names it	A paid re-audit
2. Write the scope document	The quote lists the same files	A padded quote
3. Document intent	A plain-language spec exists	Paid days rebuilding intent
4. Add NatSpec	Generated docs load	Billed questions
5. Hand over a threat model	A known-issues list exists	Paying to rediscover risks
6. Pin the compiler	An outsider builds it in one command	Billed setup time
7. Remove dead code	No TODOs in the repo	Dead code billed
8. Import audited libraries	A package manager supplies them	Copies audited as new code
9. Triage Slither output	A triage file exists	Known findings reported
10. Reach 90% coverage	A coverage report from a fresh clone	Low-severity noise
11. Write invariant tests	A written property list	Logic flaws found late
12. Test on a mainnet fork	The suite names a fork block	Flaws that mocks hide
13. Map privileged roles	A role map exists	High-impact findings
14. Script the deployment	Scripts sit in the repo	Unreviewed deployment risk
15. Name a contact, book the fix review	A name and a date	A late launch

Scope and documentation (items 1 to 5)

1. Freeze the commit hash (no moving targets)

Freeze one commit hash before the audit starts. ConsenSys Diligence notes that most audit firms require a frozen commit hash. The signed statement of work should name it. Without a commit freeze, findings go stale.

Red flag: “We will push a few fixes during the audit.”

2. Write the scope document (files, lines, out of scope)

List every in-scope contract with its line count, plus what is out of scope. The auditor’s quote should name the same files, because a vague scope document gets priced for the worst case. Our scope guide explains what a smart contract audit actually covers.

Red flag: “Scope is the whole repo.”

3. Document intent, not just code (spec and assumptions)

Write a plain-language spec of what each contract does, what it must never do, and why. OpenZeppelin’s audit readiness guide asks for intent, design choices, and assumptions in writing. Without a spec, you pay the auditor to work out intent from code.

Red flag: “The code is the documentation.”

4. Add NatSpec to every public and external function (readable comments)

NatSpec is Solidity’s standard comment format for functions. Ask for the generated docs page. Each undocumented function becomes a billed auditor question.

Red flag: Functions with no comment above them.

5. Hand over a threat model and a known issues list (known risks)

Write down your trust assumptions: who can call what, which risks the team already knows about, and which it accepts. Name attackers and assets, not features. Skip it, and you pay to hear what you already knew.

Red flag: “We have no known issues.”

Code hygiene (items 6 to 9)

6. Compile clean on a pinned compiler version (one-command build)

Pin one compiler version, clear every warning, and build from a fresh clone with one command. Ask an outside engineer to try it, because fixing the build takes review time.

Red flag: A floating pragma such as ^0.8.0.

7. Remove dead code, TODOs, and debug paths (nothing half-built)

Resolve every TODO before the audit, as OpenZeppelin’s guide asks, so a repo search for TODO comes back empty. Dead code still gets billed.

Red flag: Test-only functions in production contracts.

8. Import audited libraries, do not copy them (OpenZeppelin Contracts)

Install OpenZeppelin Contracts or an equivalent through a package manager, with the version pinned. Copied and edited library code is new code to audit.

Red flag: A library folder pasted into the repo.

9. Run static analysis and triage every finding (Slither)

Trail of Bits’ secure development workflow opens with Slither, a static analyzer for Solidity. Mark each finding as fixed or accepted, then give the triage file to your Solidity audit team. A clean run is not a clean contract, since business logic is what automated audit tools miss.

Red flag: “We ran Slither once last year.”

Testing (items 10 to 12)

10. Reach 90% test coverage on a fresh install (a floor, not a finish)

OpenZeppelin’s readiness guide asks whether tests cover at least 90% of the code and pass on a fresh installation. Ask for a forge coverage or Hardhat report from a clean clone. Coverage is a floor, not proof of correctness.

Red flag: Tests that pass on only one laptop.

11. Write invariant and fuzz tests (Echidna or Foundry)

List the properties that must always hold, such as supply, solvency, and access rules. Trail of Bits calls documenting them its single most important step. Run invariant testing with Echidna or Foundry, both built on fuzzing. Skip Manticore, a symbolic execution tool Trail of Bits archived in June 2026.

Red flag: No property list anywhere.

12. Test against a mainnet fork for every external dependency (not mocks)

Oracles, exchange pools, bridges, and unusual tokens behave differently on a mainnet fork than in mocks. The suite should pin a block, as Foundry fork testing recommends.

Red flag: Every external call is mocked.

Operations and the engagement (items 13 to 15)

13. Map every privileged role and upgrade path (keys and powers)

List owner keys, proxy admins, multisig thresholds, and timelock delays in one table. CertiK ranked wallet compromise as the costliest attack vector of H1 2026, at $444.5 million across 33 incidents. Without a role map, your highest-impact risk goes unreviewed.

Red flag: One externally owned account (EOA) controls upgrades.

14. Script and document the deployment (repeatable launches)

Write down the deployment process, as OpenZeppelin’s guide asks, and keep the scripts and constructor arguments in the repo. Ask which script ships to mainnet.

Red flag: “We deploy from a laptop.”

15. Name one point of contact and book the fix review (no stalls)

Name one engineer to answer auditor questions within a business day, and book the fix review with the audit. Unanswered questions stall the engagement, and a late fix review delays launch.

Red flag: Nobody owns the auditor’s inbox.

dApp Audit Prep: The Front-End and Off-Chain Items Auditors Skip

A dApp audit covers a decentralized application’s front end and off-chain services, which most smart contract audits leave out unless you name them in scope. Add these to scope or test them yourself:

Signing prompts: The wallet shows what the transaction does.
Front-end dependencies: Packages are pinned to a lock file.
Admin dashboards: Privileged actions need the contracts’ multisig.
Keeper and relayer keys: Bot keys are rotated and tightly scoped.
Oracle update jobs: Price pushers have alerts and failover.

If your team shipped AI-generated front-end code, test it before launch. An audited contract behind an unreviewed front end is half a defense.

Solidity Audit Prep: The Language-Specific Items

A Solidity audit moves faster when five patterns are in place. Follow the Checks-Effects-Interactions pattern, so external calls come last. Add reentrancy guards where an external call cannot come last. Comment every unchecked block with the reason overflow cannot happen. Lock the storage layout of upgradeable contracts, since OpenZeppelin’s upgradeable contracts guide forbids reordering state variables. Test each token against the Ethereum Request for Comments (ERC) standard it claims, such as ERC-20.

Building in Rust or Move? Read our guide to Solana and Move audits instead.

Score Your Readiness: The Smart Contract Audit Checklist Test

Our scoring gives one point per item fully met. It is our rubric, not an industry standard.

13 to 15: Request quotes now.
9 to 12: Fix the gaps first, then request quotes.
8 or below: Do not book an audit yet.

Audit readiness is a number you can check before the clock starts. At 13 or higher, our honest comparison of smart contract audit firms helps you build the shortlist.

Red Flags: Why Smart Contracts Fail Security Audits

Most smart contracts fail security audits because of preparation gaps, not exotic attacks. Five recur:

No commit freeze: Findings describe code that no longer exists.
Happy-path tests only: Nobody tested bad inputs.
A single EOA owning upgrades: With no timelock, one stolen key can replace the contract.
Scope that excludes the contract holding funds: The riskiest code goes unreviewed.
No one answering auditor questions: Questions wait while the clock runs.

If two of these describe your repo, fix them before you compare smart contract audit services.

Internal Review vs. Automated Tools vs. Audit Firm

A Web3 security audit works best in layers, and no layer replaces another.

Option	What it catches	What it misses	When it is enough	Typical timing
Internal review	Intent errors the team can see	Blind spots the team shares	Never on its own before mainnet	Every pull request
Automated tools	Known patterns, fast	Business logic and economic attacks	Pre-audit cleanup	Every commit
Audit firm	Logic, integration, and trust flaws	Anything outside the agreed scope	Before mainnet and after major changes	Booked ahead of launch

Still setting a budget? See the budget section of our scope guide.

Conclusion

A smart contract audit checklist comes down to three moves: freeze, document, and test.

Freeze the hash. Write the threat model. Hit 90% coverage. Book the fix review.

Do that, and you pay auditors to find vulnerabilities, not to read your code for the first time.

If you want a second read on your repo before you book an auditor, book a free 30-minute audit-readiness call. We’ll go through your repo against the 15 points, flag the items likely to cost you audit days, and tell you whether you’re ready to request quotes. Book your call here.

FAQs

What should I prepare before a smart contract audit?

Prepare six items before booking. Freeze a commit hash, write a scope document and a plain-language spec, add NatSpec to public functions, reach at least 90% test coverage, and map every privileged role. Those six answer most questions auditors would otherwise bill to ask, so paid hours go to finding vulnerabilities.

How long does a typical smart contract audit take?

Ten to twenty business days is typical, counted from code freeze to the final report. Lines of code and complexity set the length, and the scope document sets the timeline. Unprepared code stretches it, because auditors spend early days on setup. Book the fix review separately, since remediation adds time.

How often should smart contracts be audited?

Audit before every mainnet deployment, then again after any change to in-scope logic, upgrade paths, or privileged roles, and after any new external integration. Event-based triggers matter more than a calendar, so an annual audit of unchanged code adds little value. Our guide to re-audit triggers lists them in full.

Why did our smart contract fail a security audit?

Most failures come from preparation gaps, not exotic attacks. Access control flaws, untested edge cases, and code that changed mid-audit are the most common causes. Before the re-audit, freeze the commit hash, write invariant tests for the properties that must always hold, and map every privileged role and upgrade key.

What test coverage do auditors expect?

At least 90% is the usual bar. OpenZeppelin’s readiness guide treats that figure as a sign of adequate effort and expects every test to pass on a fresh install. Coverage is a floor, not proof of correctness. Invariant testing and fuzzing matter more than the number, because they test behavior.

Do I need a dApp audit as well as a smart contract audit?

Usually yes, if users sign transactions through your front end. Contract audits stop at the contract boundary unless the front end and off-chain services are named in scope. Signing prompts, front-end packages, admin dashboards, and keeper keys can all lose user funds while the contracts themselves work exactly as written.

What is the difference between a pre-audit checklist and an audit?

A pre-audit checklist is your work, and an audit is an outside review. Your team completes the checklist before the engagement, and the auditor then reviews that prepared code for flaws. The checklist makes the audit cheaper and its findings sharper, because reviewers spend their hours on attack paths, not setup.

Does Web Three Consulting review repos before an audit?

Yes, on a free 30-minute readiness call. We check your repo against these 15 points, flag the gaps likely to cost audit days, and say whether you are ready to request quotes. Our audits are a separate engagement, and if your review does not fit our service, we say so first.