Audit Readiness Checklists

Prepare the documentation, summarize what your project intends to do and its features (e.g., yield aggregator, staking, DEX). Include appropriate references and documents (e.g., places of concern, documentation, white paper).

Define the role model for the project (e.g., ROLE_ADMIN will be governed by DAO, ROLE_EMERGENCY_MANAGER will be governed by 5/9 msig)

State any assumptions for the external contracts or configuration, e.g., “only integrating with ERC20 tokens without the callback functionality (no ERC777)” or “only integrating with ERC20 tokens with 18 decimals”.

Use the latest major compiler version.

Use established and well-tested libraries whenever possible (e.g., OpenZeppelin for Solidity smart contracts) to avoid code clones.

Ensure that the code compiles without any errors. Provide precise instructions for building the project, including any implicit dependencies and their versions (e.g., the npm version).

Conduct at least two independent in-house reviews of the project by developers.

Naming should be as straightforward as possible.

The code’s style should be consistent throughout the codebase. It is a good idea to follow Solidity’s style guide.

The code should be given in short and straightforward segments. If functionality is split into multiple modules (such as libraries or other contracts), it should be well encapsulated and the codebase should be navigable without too much jumping around.

Document the use of unchecked{}. Describe why it is safe to skip arithmetic checks on each code block.

All complex math equations should be well-commented in the code.

All delegatecall and selfdestruct operations should be well-commented in the code.

Ensure that the code comes with an extensive test suite. Tests help to express your intent and to assure code quality.

Provide step-by-step instructions for running the test suite. Include any necessary information related to the setup and environment.

All tests should be passing.

Prepare a template test that contains as many protocol contracts as possible (if some of the contracts cannot be used in one test, add comments for them). Initialize these contracts with the values you plan to use after deployment. Provide detailed comments on this test. This will help auditors to prepare PoC for findings.

Have tests for all essential user stories.

Test access controls and all the roles, such as owners and non-owners.

Write negative tests. E.g., try to negatively test all require statements (especially the most important ones that check different invariants in the code).

Measure test coverage. A good rule of thumb is to ensure at least 80% coverage.

If you rely on external protocols, implement tests with a mainnet fork so that the integration points are tested.

If you rely on off-chain services, do your best to implement their mocks in tests and cover all positive and negative scenarios (e.g., if you are building a bridge or a bridge aggregator, then it is better to test a broken oracle scenario).