How to Prep for an Audit
It's no secret that smart contract auditing firms have long backlogs. Learn how to better prepare your project so it can get booked sooner than later.
As auditors, it’s no secret that we have long backlogs. Consequently, we’re always assessing projects on whether or not we should work with them, just as much as those projects are assessing us.
So, what are some things we look for that makes an audit customer a good fit?
Overview
Here we offer a quick set of tips on how you can prepare your smart contract project for an audit. The goal is to make your project attractive to work with, even for the busy top smart contract audit firms.
1. Write Great Documentation ✍️
Quality of documentation is a major factor in how auditors assess your project. Too often do we see projects with little to no documentation.
Poor documentation makes it a pain to give a proper estimate for how long an audit would take. Not everything is deducible from the code, and even if it is, it's much faster and more accurate to get intent from the authors themselves.
Poor documentation may even lengthen the audit itself, either costing you more money, or leaving less time for a high quality audit.
With that said, great documentation usually has at least these:
- High level intentions, features, and goals. What are you trying to accomplish?
- Detailed use case descriptions. Who is using your protocol, and why?
- Explanations of technical decisions. Why did you take your approach?
- Architecture diagrams. How do components of the system interact?
- Perhaps most importantly, how the contracts in question fit in the overall system. We often see projects provide overall documentation, but then leave us to ask or figure out which parts of those docs apply to which contracts they want audited.
For an example of great documentation, see any of ThirdWeb's design docs, such as their marketplace contract docs.
2. Write Great Tests 🧠
It goes without saying that testing is critical to writing secure code. A project with a lack of tests is guaranteed to have problems, and is not something we're interested in booking.
Of course, testing does not catch all bugs either. But here are some quick tips for writing tests for smart contracts.
Test all use cases
This may seem obvious, but it needs to be said. Every use case needs a proper test. Don't miss a single one.
Ideally, each use case has an end-to-end test. This isn't strictly necessary when developing smart contracts, but doing so helps you iterate on your contract's ABI design, since you'd be using it in frontend code.
Test as many edge cases as possible
Missed edge cases are the primary reason smart contracts lose money. But it's almost impossible to think of them all by yourself, and you shouldn't treat auditors as a bug-free guarantee.
The best, low-hanging fruit you can do for your project today is introduce fuzz testing. Fuzz testing is essentially an automated way of finding edge cases in your code. It will try input combinations on your code that you'd never thought to test.
Fuzz testing is built into Foundry. Hardhat users are not completely out of luck, but they will need to learn and implement a tool like Echidna.
Achieve high test coverage
High test coverage is not an end-goal, but it is a decent measurement of health. Low test coverage means you certainly don't have enough tests. High test coverage means you might. 100% coverage is desirable for smart contracts, but beware, as even that won't even save you – we've found bugs in a project with 100% test coverage before!
Use solidity-coverage to measure your test coverage in your hardhat projects. Foundry users are currently out of luck, but may have access to superior mutation testing in the future.
3. Prepare your Repo for the Audit 📐
Handing your code to the auditor is not a simple matter of git push and link to GitHub. There are certain things that you should do to save everyone valuable time you're paying for.
Be code complete
Changes to code are inevitable. However, during the audit, you should not make major changes to the codebase – doing so may change the audit timeline, and could even require a full re-audit!
Fixes to the issues an auditor finds are usually covered, given they are not large enough to trigger the above.
Tag the commit you want audited
Adding a git tag on a commit helps ensure everyone is on the same page on what exactly is being audited.
When auditors find issues and you fix them, create another tag when those fixes are ready for review.
Clean up the codebase
Another seemingly-obvious point, but be sure to do things such as:
- Write Natspec docs for your external/public functions
- Document expected invariants
- Use standard terminology over "cute" or "creative" terminology (e.g. "LendingPool" over "DragonHoard")
- Comment on unconventional design choices
- Remove any commented out code / unused files
Conclusion
Audit bookings are hard to get. By following this advice, you'll make your project more attractive to auditors and more likely to get booked.
We hope you found this post helpful. If you want to get in touch with us to chat about audits, please click the link below:
