Given the costs of auditing and the time & attention that will be invested from an auditor, it's critical to prepare appropriately.

We studied several auditing checklists from top auditors and compiled a master list of tips that should prepare you for any audit:

• How to Prepare for a Smart Contract Audit by ConsenSys Diligence
• How to prepare for a security review by Trail of Bits
• Follow this quality checklist before an audit by OpenZeppelin
• Audit Readiness Checklist by Nascent

Auditing

• Book an auditor months in advance (due to low availability, make sure you book an audit before you start going through this checklist)
• Identify goals, questions and primary areas of concern for the review
• Write down your security assumptions
• Share past reports & bugs
• Consider conducting an explicit internal security review

Team & community

• Choose an appropriate software license
• Build a resilient core team of maintainers (small team with redundancy and regular knowledge sharing)
• Develop your community to get extra eyes on your code over time
• Have a trusted Solidity dev or security person outside your organization sanity check your contracts before an audit

Code development tips

• Use test-driven development
• Write clean, simple and readable code
• Use continuous integration and enforce it for pull requests

Documentation

• Document the overall product and its goals/functionality
• Document code and tests using NatSpec
• Document use of unchecked

Code quality and cleanup

• Use the latest major version of Solidity
• Use known libraries where possible, e.g., OpenZeppelin or Solmate for gas optimized code
• Fix and address compiler warnings and fix issues from static analysis tools
• Get to 100% unit test coverage (especially for user stories / happy paths, but also negative tests of what users shouldn't be able to do)
• Remove dead and unused code and branches
• Write comprehensive scenario/fork/integration tests
• Prepare a clean build environment and build instructions (could come from CI)
• Review your dependencies for safety
• Make external any public function that could be made external
• Use Checks-Effects-Interactions where possible or reentrancy guards (NonReentrant). Treat all token and ETH transfers as “interactions”
• Avoid using assembly as much as possible (it increases audit times significantly)
• Run the code through a spellchecker

‍