How to prepare for a smart contract audit

At first sight, auditors are here to help developers create safer smart contracts. However, more cooperation between both sides can help reduce audit costs and increase the chance of discovering more severe issues. The pre-audit part is essential for a smooth audit, and we will now guide you through it.

Preparing for an audit

First, a correctly scheduled time pipeline will help to avoid many difficulties. Suppose you are still building and considering an audit in the future. In that case, you’d better discuss it in advance , as during the audit, the codebase needs to be frozen and be almost production ready at a specific commit. The reason is: after the audit, fixes can only be made to ensure maximum safety.

In addition, take into account the importance of the audit scope. If it is not a full-repository audit, the scope should be clearly specified: enumerate all the contracts that should be audited and those that should be taken as a black box.

Another important part is the project’s readability. Ideally, the code should be continuously documented during the development process resulting in comprehensive documentation. Complex code parts should be documented inline , and it is recommended to use NatSpec format across the codebase in its full range (params, return values, …). Architecture graphs , project flows , and functional requirements alongside low-level documentation are also extremely useful. A whitepaper and video walkthrough through the codebase are vital for auditors. The last but not the least is compliance with Solidity Style Guide and Solidity linters usage. These steps will help to significantly speed up the onboarding process for third-party auditors.

Maximizingthe audit output

It is important that the project you want to be audited can be compiled. Auditors are deploying projects on local development chains to ensure correct functionality and to test various exploits. That’s why extensive test suite with various mocks are also very helpful. Moreover, these tests can discover bugs ; more bug s in the report result in more overhead. Thus, the audit output can be less confident because there is less time to check the rest of the project. Therefore, writing as many tests as possible to ensure the full coverage is strongly recommended.

Extending the unit and integration tests with property-based fuzz tests is a master move and will help you a lot. If you think that fuzz tests writing is challenging, let us tell you this: it is not.

May the tooling be with you

It is 2023, and testing frameworks like Foundry and Wake are at your service. Foundry is for Solidity fans; Wake is written in Python , so it is more practical in some ways, like differential fuzzing of math libraries/operations, it has plenty of helpful Python packages, easy-to-write tests for anyone, and much more.

The following discipline is a static analysis. Easy to run, and outputs are easy to understand and fix. We would single out two possibilities: Slither and Wake. Slither has a wide range of detectors with many false positives ; on the other hand, Woke has fewer detectors , but they are usually more relevant. Both tools are configurable , for example, to suppress some detections to make it more convenient for reviews. Each audit starts with a static analysis , so if you perform it before the audit, it can save you some time.

Final remarks

If you followed the recommendations from the previous paragraphs, your project should now be ready for an audit. Remember to give the auditors previous audit reports (if any). It will be really helpful.

For your convenience, check the pre-audit checklist below:

Pre-audit checklist

The more points from the following list you accomplish, the more valuable audit you will get.

Your project:

• is ready to be frozen for the auditing period
• is compilable
• is accessible for the auditors from day 1
• contains full NatSpec documentation
• has comprehensive technical documentation
• has a walkthrough video for auditors
• follows Solidity Style Guide
• contains an extensive test suite
• passed a static analysis
• has past audit reports