Before the audit begins, compile a single document with all the of information we will need to complete the audit. Here is a showcase example. This document should include:

• [ ] A link to the documentation that describes the project’s:

  • Background (purpose and how it works)
  • High-level specification
  • Protocol design
  • Implementation details

  <aside> 👉 Here is an example from thirdweb

  </aside>

• [ ] A link to the code repository and the commit hash indicating the code-freeze for the audit

  <aside> ‼️ We will perform the audit on this commit hash; any changes made later won’t be in the scope of the audit, apart from the fixes review.

  </aside>

• [ ] Scoping details

  • Which contracts are in scope? Which are not in scope?
  • What parts of the codebase have been audited before, if any?

• [ ] A link to the specific branch that will contain fixes to issues we find during the audit

• [ ] A description of your internal security efforts. Include:

  • A list of artifacts for verifying system safety (tests - unit/integration, risk analysis, etc.)
  • Instructions on how to run/navigate the test suite, including any required environment variables
  • Your use of security assessment tools such as Slither
  • Your code coverage metrics

• [ ] Identification of code that may require more attention and time. For example:

  • Complex logic
  • Novel or nonstandard features
  • Code that you are not sure works as expected

• [ ] Identification of code, concepts, or ideas that are borrowed from or similar to other protocols

  • Is your approach commonly used?
  • Are there any known vulnerabilities?
  • Any other projects that implement the same thing?

Additional Checklists

What we need to deliver an estimate

How to get the best estimate and audit

General Security Best Practices

Preparing for the Audit

Compiling an Audit Handoff Document

Completing Your Fixes