Smart Contract Audit Checklist · 12 Questions to Answer Before Mainnet

Why a pre-audit checklist matters

External audits are expensive. They are also calendar-blocking · once you commit to an audit window, that team is yours for two to four weeks and you cannot easily swap them out. If your code shows up half-baked, half the audit budget gets spent on findings you could have caught yourself with free tools.

The point of this checklist is simple. Before you ever email an audit firm, walk through these 12 questions. If you can answer every one with confidence, you will get a sharper, cheaper, more useful audit. If you cannot, you have a punch list of things to fix this week.

1. Is your code feature-complete?

The fastest way to waste audit budget is to keep editing contracts during the audit. Every changed line invalidates earlier findings and forces the auditor to re-check assumptions. Lock the feature set before the audit starts. If you cannot lock it, postpone the audit by a week · that week is cheaper than the audit overrun.

2. Have you run static analysis?

Slither is free, fast, and catches an enormous class of known issues · reentrancy patterns, uninitialized storage, dangerous delegate calls, shadowed variables, and many more. Run it. Fix every high and medium finding. For Solidity projects, also run solhint and solc with all warnings enabled. For Rust on Solana, run cargo clippy and cargo audit.

If your audit firm has to file the same findings Slither would have caught, you are paying senior engineers to do work a free tool can do in 30 seconds.

3. Do you have invariant tests?

Unit tests check that a function returns the right value for one input. Invariant tests check that a property of your system never breaks across millions of randomized call sequences. They are the single most valuable test type for catching real bugs.

Examples of invariants worth writing:

• Token total supply always equals the sum of all balances.
• AMM constant product never decreases after a swap (modulo fee).
• Lending market total borrows never exceeds total supply.
• Vesting contract released amount never exceeds vested amount.
• Multisig cannot execute a transaction with fewer than threshold signatures.

Foundry's built-in invariant runner and Echidna both work well. Aim for at least 100,000 sequences with zero failures before going to audit.

4. What are your oracle dependencies?

Oracles are the most common source of catastrophic loss in DeFi. The audit firm cannot fix this for you because the design decision is yours. Document, before the audit:

• Which oracle provider you use (Chainlink, Pyth, RedStone, custom).
• Update frequency and staleness threshold (what happens if the feed stops updating?).
• Whether you accept a single feed or require agreement between multiple feeds.
• Whether the feed is manipulable by a single block of trading volume (TWAP length, sample count).

If you use a DEX as a price source, write down exactly how a flash-loan attacker could move that price and what your contract does in that case.

5. Have you mapped admin powers?

Every audit will ask, "What can the owner do that would harm users?" Write the answer down before they ask. Common admin powers worth documenting:

• Pause / unpause transfers.
• Mint new tokens.
• Change fee parameters.
• Update oracle addresses.
• Withdraw treasury funds.
• Upgrade contract logic (if upgradeable).

For each one, decide which are behind a multisig, which are behind a timelock, and which are immutable. A clear table at the top of your audit brief saves auditor hours and reduces back-and-forth.

6. Is upgradeability handled cleanly?

If your contracts use a proxy pattern (UUPS, Transparent, Beacon, Diamond), audit firms will ask: who can upgrade, can the new implementation drain the old one, and is storage layout protected? Document the upgrade path and run a storage-layout diff against the previous version using forge inspect or openzeppelin-upgrades.

If you do not need upgradeability, do not add it. Every proxy is a new attack surface.

7. What is your multisig and timelock setup?

Audit firms want to see the operational story, not just the code. Before the audit, configure:

• A multisig (Safe on EVM, Squads on Solana) with at least three signers.
• A timelock for any sensitive parameter change · usually 24 to 72 hours.
• Documented signer rotation procedure for when a signer leaves.
• Emergency-pause access on a separate, lower-threshold path.

The combination of multisig and timelock is what gives users time to exit if you ever try (or are forced) to make a hostile change. Auditors will note its absence as a finding.

8. Have you considered the external token surface?

If your protocol accepts arbitrary ERC-20 tokens (e.g. a DEX, a lending market, a vault), assume those tokens will behave badly. Fee-on-transfer tokens, rebasing tokens, missing-return-value tokens, double-entry-point tokens · all of these have caused real exploits. Either restrict to an allowlist of known-good tokens or add explicit handling for each behavior.

9. Is your access control sane?

Most contracts have a few roles · owner, pauser, minter, treasurer. Use OpenZeppelin's AccessControl or a similar role-based pattern, not raw onlyOwner. Document which functions check which role. Auditors will trace every external function back to its access-control modifier; if any is missing or wrong, that is a finding.

10. What is your deployment story?

An audit covers the code in your repo at a specific commit. It does not cover what happens during deployment · wrong constructor parameters, missed initialization calls, mismatched proxy admins. Write a deployment script (Foundry or Hardhat) that is itself reviewed and committed. Treat it as production code. Run it on testnet first, end to end, with the same multisig configuration you will use on mainnet.

11. Have you picked the right audit firm tier?

Not every protocol needs a Trail of Bits review. Match the firm to the risk:

• Top tier (Trail of Bits, OpenZeppelin, Spearbit) · high-TVL DeFi, novel cryptography, large public launches.
• Boutique (Pashov, yAudit, individual reviewers) · well-scoped protocols, mid-six-figure TVL targets, fast turnaround.
• Contests (Cyfrin Codehawks, Sherlock, Code4rena) · crowdsourced reviews, large finding surface, time-bounded.

Request quotes from three firms in your target tier. Compare not just price but engineer-weeks, expected finding count, and re-audit policy.

12. Do you have budget for a re-audit?

The audit will produce findings. Some you will fix in a way that changes the architecture. Those changes need a second look. Budget for a re-audit pass · typically 25:40% of the original audit cost. Without it, you ship a contract that was audited before your fixes, which is not the same as an audited contract. (Wondering what the whole review will run you? See smart contract audit cost in 2026.)

Putting it all together

Here is the order we work through with founders at Shazra Labs before any external audit:

1. Lock feature scope. No new features until after launch.
2. Slither, solhint, full warning sweep. Zero high or medium findings.
3. Foundry invariant suite. 100k+ runs, zero failures.
4. Oracle dependency document. One page, signed off by the team.
5. Admin powers table. One page, included in the audit brief.
6. Multisig and timelock configured on testnet, same as planned mainnet.
7. Fresh-eyes internal review by an engineer who did not write the code.
8. Three audit-firm quotes. Pick on fit, not just price.
9. Audit window. Address findings same-day where possible.
10. Re-audit pass for any meaningful change.
11. Testnet rehearsal of the full deployment script.
12. Mainnet deploy from the multisig.

If you are about to launch and want a second pair of eyes on any of these steps, we read briefs every day. See our Web3 specialty page for the audit firms we coordinate with and the chains we ship on, or jump straight to contact.

FAQ

How much does a smart contract audit cost in 2026?
Pricing scales with contract complexity and firm tier. Get three quotes once your code is feature-complete and statically clean. Budget for a re-audit pass on top.

Can I skip the audit if my contract is simple?
No on-chain mistake is reversible. Even simple ERC-20 contracts have been drained. At minimum: Slither, Foundry invariants, fresh-eyes internal review.

What is the difference between Slither and Echidna?
Slither does static analysis · reads source, flags known bad patterns. Echidna (and Foundry's invariant runner) does property-based fuzzing · millions of random sequences against your invariants. Use both.

How long does an audit take?
Two weeks for one auditor on a moderate codebase. Four to six weeks for complex protocols. Add a week for fix iteration and a re-audit pass.