Smart Contract Audit Checklist: What to Prepare Before Launch

A smart contract audit is one of the best investments a Web3 project can make, but its value depends heavily on preparation. Auditors work faster and find deeper issues when the code is stable, tested and well documented. Use this checklist before you book an audit.

1. Freeze the scope

Decide exactly which contracts and commit are in scope.
Stop adding features during the audit.
Remove unused and experimental code.

2. Document how it should work

A plain-language overview of the system and its users
A specification of each contract's functions and expected behaviour
Diagrams of how contracts interact
A list of privileged roles and what each can do
Known assumptions, limitations and trusted external contracts

3. Test thoroughly

Unit tests for every function, including failure cases
Integration tests for complete user flows
Fuzz and invariant tests for critical maths and balances
Fork tests against real deployed protocols you depend on
A coverage report you can share with auditors

4. Run automated checks

Static analysis tools such as Slither catch many common issues automatically. Fix or document every finding before the audit so auditors can focus on deeper logic problems.

5. Review common vulnerabilities

Reentrancy: external calls before state updates.
Access control: missing or incorrect permission checks.
Oracle manipulation: prices that can be moved within one transaction.
Integer and rounding errors: especially in fee and share calculations.
Unchecked external calls and return values.
Front-running and MEV exposure in trades and auctions.
Upgradeability risks: storage collisions and unprotected initialisers.
Denial of service: loops over unbounded arrays, blocked withdrawals.

6. Secure admin powers

Use multi-signature wallets for owner and admin roles.
Add timelocks to sensitive changes.
Limit what admins can do and document it publicly.
Plan emergency pause procedures.

7. Prepare deployment

Scripted, repeatable deployments
A list of constructor arguments and initial settings
A plan to verify contracts on block explorers
Monitoring and alerting for unusual activity after launch

After the audit

Fix the findings, ask auditors to review the fixes, and publish the final report. Consider a bug bounty after launch, and re-audit whenever you make significant changes.

How to choose an auditor

Look for published reports on projects similar to yours.
Check experience with your chain and language, such as Solidity or Rust.
Ask who will review your code and how many reviewers are involved.
Understand the timeline, including time for re-reviewing fixes.
Prefer clear severity ratings and practical recommendations.

Understanding audit findings

Audit reports usually rate findings by severity:

Critical / High: can lead to loss of funds or a broken protocol. Fix before launch, always.
Medium: real risk under specific conditions. Fix or document a clear mitigation.
Low: minor issues or deviations from best practice.
Informational / Gas: suggestions to improve readability or reduce costs.

Respond to every finding in writing, even if you choose not to change the code, so users can see your reasoning in the final report.

An audit isn't a guarantee

Audits significantly reduce risk, but they review code at a point in time within a limited scope. Combine them with strong testing, conservative launch limits, monitoring, a bug bounty and a clear incident response plan. Many teams launch with deposit caps that increase gradually as the protocol proves itself.

Incident response plan

Know who can pause contracts and how quickly they can be reached.
Prepare communication templates for users.
Have relationships with security responders ready before you need them.
Document how funds would be recovered or users compensated where possible.
Run a practice drill before launch.

Testing in more depth

Good test suites do more than check that functions work. They prove that important rules always hold. Examples of useful invariants include:

Total supply always equals the sum of all balances.
Users can always withdraw what they're owed, unless the contract is paused.
Fees never exceed the configured maximum.
Only authorised roles can change critical settings.
The protocol stays solvent after any sequence of user actions.

Fuzz testing tools generate thousands of random inputs and sequences to try to break these rules, often finding edge cases humans miss.

Code quality signals auditors appreciate

Small, focused contracts instead of one large file
Clear naming and consistent style
Comments explaining why, not just what
Events emitted for every important state change
No unused variables, functions or imports
Pinned compiler version and documented dependencies

Budgeting and scheduling

Audit cost depends mainly on code size and complexity, and good firms are often booked weeks ahead. Plan the audit into your launch timeline early, leave time for fixes and a re-review, and avoid scheduling your marketing launch until the final report is in.

Upgradeability: decide early

Upgradeable contracts let you fix bugs and add features after launch, but they also mean someone can change the code users rely on. If you choose upgradeability, use well-known proxy patterns, protect upgrades with multi-sig and timelocks, and test storage layouts carefully between versions. If you choose immutability, accept that fixes require deploying new contracts and migrating users. Either approach can be right; what matters is making the choice deliberately and explaining it clearly to auditors and users.

Launching safely after the audit

A careful launch reduces the impact of anything the audit didn't catch. Consider launching with deposit or borrowing caps and raising them gradually, running a public testnet period first, and using a guarded launch where only some features are enabled. Set up real-time monitoring for unusual transactions, large withdrawals and price movements, with alerts that reach someone who can act immediately. Publish your audit reports, admin structure and emergency procedures so users can judge the risks for themselves. Transparency builds trust, and trust is what brings users and liquidity to a new protocol.

Frequently asked questions

How long does an audit take?

Small token contracts can take days. Larger DeFi protocols often take several weeks, plus time for fixes and re-review.

Do I need more than one audit?

For protocols holding significant value, many teams use two independent auditors and a bug bounty, because different reviewers find different issues.

What if the audit finds critical issues close to launch?

Delay the launch. Launching with known critical issues puts user funds and your reputation at serious risk.

Key takeaways

Freeze scope, document behaviour and test thoroughly before the audit.
Fix static analysis findings yourself so auditors focus on deeper issues.
Protect admin powers with multi-sig and timelocks.
Combine audits with monitoring, caps, bug bounties and an incident plan.

Need secure contracts?

AnAInfo develops and reviews smart contracts and prepares them for independent audit, for tokens, DeFi and NFT projects. Talk to us before your next launch.