# How to prepare for a smart contract audit

> How to prepare for a smart contract audit The pre-audit part is essential for a smooth audit, and we will now guide you through it.

- Canonical: https://ack3.ai/research/how-to-prepare-for-a-smart-contract-audit-2/
- Published: March 17, 2023
- Updated: May 16, 2024
- Authors: Jan Kalivoda
- Category: Technical guide
- Topics: education, ethereum, how-to, solidity, wake

_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.

**![](/research/media/2023/03/Picture-1-222x300.png)**

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](https://docs.soliditylang.org/en/v0.8.17/natspec-format.html) 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](https://docs.soliditylang.org/en/v0.8.17/style-guide.html) and Solidity linters usage. These steps will help to significantly speed up the onboarding process for third-party auditors.

#### Maximizing**the 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 l**ess 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.

#### ![](/research/media/2023/03/Picture-2-300x297.png)
#### May the tooling be with you
It is 2023, and testing frameworks like **Foundry** and [**Wake**](/wake/docs/latest/ "Woke, development & testing framework for Solidity") are at your service. [Foundry](https://github.com/foundry-rs/foundry) is for Solidity fans; [Wake](/wake/docs/latest/testing-framework/fuzzing) 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](https://github.com/crytic/slither) and [Wake](/wake/docs/latest/detectors/). Slither has a **wide range** of detectors with many **false positives** ; on the other hand, Woke has f**ewer 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