{"id":492,"date":"2023-03-17T17:39:49","date_gmt":"2023-03-17T15:39:49","guid":{"rendered":"https:\/\/ackeeblockchain.com\/blog\/?p=492"},"modified":"2024-05-16T13:16:57","modified_gmt":"2024-05-16T11:16:57","slug":"how-to-prepare-for-a-smart-contract-audit-2","status":"publish","type":"post","link":"https:\/\/ackee.xyz\/blog\/how-to-prepare-for-a-smart-contract-audit-2\/","title":{"rendered":"How to prepare for a smart contract audit"},"content":{"rendered":"

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.\u00a0<\/em><\/p>\n

Preparing for an audit<\/b><\/h4>\n

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

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<\/span>.<\/span><\/p>\n

\"\"<\/b><\/p>\n

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

Maximizing\u00a0the audit output<\/b><\/h4>\n

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

Extending the unit<\/strong> and integration tests<\/strong> with property-based fuzz tests<\/strong> 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.<\/span><\/p>\n

\"\"<\/b><\/h4>\n

May the tooling be with you<\/b><\/h4>\n

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

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

Final remarks<\/b><\/h4>\n

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

For your convenience, check the pre-audit checklist below:<\/strong>\u00a0<\/span><\/p>\n

Pre-audit checklist<\/b><\/h4>\n

The more points from the following list you accomplish, the more valuable audit you will get.<\/span><\/p>\n

Your project:<\/strong><\/p>\n

    \n
  • is ready to be frozen for the auditing period<\/span><\/li>\n
  • is compilable<\/span><\/li>\n
  • is accessible for the auditors from day 1<\/span><\/li>\n
  • contains full NatSpec documentation<\/span><\/li>\n
  • has comprehensive technical documentation<\/span><\/li>\n
  • has a walkthrough video for auditors<\/span><\/li>\n
  • follows Solidity Style Guide<\/span><\/li>\n
  • contains an extensive test suite<\/span><\/li>\n
  • passed a static analysis<\/span><\/li>\n
  • has past audit reports<\/span><\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"

    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.\u00a0 Preparing for an audit First, a correctly scheduled time pipeline will help…<\/p>\n","protected":false},"author":6,"featured_media":488,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[61,10,80,103],"tags":[87,24,88],"class_list":["post-492","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education","category-ethereum","category-solidity","category-wake","tag-education","tag-ethereum","tag-how-to"],"aioseo_notices":[],"featured_image_src":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2023\/03\/Prepare-for-audits-600x400.png","featured_image_src_square":"https:\/\/ackee.xyz\/blog\/wp-content\/uploads\/2023\/03\/Prepare-for-audits-600x600.png","author_info":{"display_name":"Jan Kalivoda","author_link":"https:\/\/ackee.xyz\/blog\/author\/jan-kalivoda\/"},"_links":{"self":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/comments?post=492"}],"version-history":[{"count":0,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/posts\/492\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media\/488"}],"wp:attachment":[{"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/media?parent=492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/categories?post=492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ackee.xyz\/blog\/wp-json\/wp\/v2\/tags?post=492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}