The four things that help Code4rena wardens to do their best work are:

1. A self-contained repository - with working commands that will build (at least) all in-scope contracts, and commands that will run tests producing gas reports for the relevant contracts

   <aside> <img src="/icons/info-alternate_purple.svg" alt="/icons/info-alternate_purple.svg" width="40px" /> Please check all code and tests on a fresh clone (using the specific commit that will be audited), and ensure that all tests are running smoothly.

   If some tests are expected to fail, and you don’t expect to fix them prior to your audit, please inform staff so we can note that for the auditors.

   </aside>

2. Organized repo & readme, including well-commented code

3. Video walkthrough, if possible (you can link this from the repo and also pop it into your warden-facing channel in our Discord). Here’s an example.

4. Your presence in the C4 Discord - easy access for questions via DM or private threads

Repo setup tips

• C4 staff will set up your audit repo using:

  • your code, using the commit sha you provided to the Booking team
  • your responses to the audit setup form

  …and send it to you for review.

• Submit changes to your repo 2 business days before launch: To launch your audit on schedule, your audit repo (including the README) must be completely set up and shared with us at least 48 business hours (2 business days) before your audit is scheduled to start. This ensures we have time to review it and help you finalize any last-minute details.

• Technical review: Your repo will be reviewed by a Code4rena Scout (technical reviewer).

Technical notes for your engineers

In order to increase the chances of wardens finding all bugs in your code, there are a few technical things your team can do to contribute to the quality of the audit:

• Clean code

  The easier your code is to understand, the more time and energy wardens can dedicate to finding bugs.

  • Using explanatory function and variable names
  • Using enums when relevant, rather than plain numbers

• Docs, ideally covering 3 levels:

  • High-level explanation of the aims, features and functionality of the project (less technical aspect, and more user end aspect)
  • High level overview of the system design: some projects include a flowchart, feel free to add it if it seems fit
  • Code comments: explain any nontrivial part of the code
    • Most functions
    • Any complex design or nontrivial design choice in the code
    • Anything in the code that might make an external reviewer scratch their head.

• Marking known issues: It's important that our wardens don't waste their time on known issues and focus their time and energy on finding relevant bugs, therefore it's important that you let us know if there are any known issues in the code, whether you intend to mitigate them or not.

• Incomplete code: Our wardens will work under the assumption that this is the final form of the code that's going to be deployed to the blockchain. If you plan on any modification of the code before deployment (except for mitigation of C4's findings), please note this clearly in your README file, so that the wardens will have the correct assumptions about the code.

• Tests:

  • Some bugs can easily be found by simple tests; therefore it's better to cover as much as possible with tests so that the wardens don't need to spend time on finding and reporting them and can focus on finding the more complicated bugs
  • We don't expect you to rewrite your tests, but just in case you haven't written them yet, C4 wardens prefer forge, as it's easier to write and debug.
  • Whenever possible, please ensure that
    • test line coverage is high, since wardens often will modify existing tests in order to provide POCs, and need similar test cases to modify
    • build/test commands are complete and that they can be run in order, without modification, to get all of the tests passing
    • all tests pass, or reasons for failures passing are clearly explained
    • slither . from the project root works without error, or that expected errors are documented in this README.md
    • commands for running the tests include the appropriate arguments for showing gas reports
    • if the project is using foundry, that a complete remappings.txt is provided, so that tools such as VS Code that do not read foundry.toml can work properly
    • any failing commands or errors during the running of the build/tests/slither are documented, with the specific error message expected

Next: Marketing and promotion