<aside> ‼️ We strongly encourage projects to incorporate the following best practices into their projects. While these may not significantly impact the time needed to complete the audit, they are simple steps you can take to drastically improve the security of your contracts. Additionally, following these practices will allow auditors to focus on deeper issues, increasing the odds that any critical or high severity issues will be caught.
</aside>
[ ] Use the latest major version of Solidity if possible.
[ ] Use known/established libraries where possible.
<aside> ℹ️ OpenZeppelin contracts are preferred because they prioritize security above all else, and most auditors are already familiar with them.
</aside>
[ ] Correctly set function visibilities.
<aside>
ℹ️ Any public function that can be made external should be made external. This is not just a gas consideration but also reduces the cognitive overhead for auditors because it reduces the number of possible contexts in which the function can be called.
</aside>
[ ] Use the Checks-Effects-Interactions pattern everywhere possible. Otherwise, use reentrancy guards. Treat all token and ETH transfers as 'interactions.’
[ ] Avoid using assembly as much as possible.
<aside> ℹ️ Significant use of assembly increases audit times because it throws away Solidity's guardrails and must be checked much more carefully.
</aside>
[ ] Document all uses of unchecked. Concretely describe why it is safe not to perform arithmetic checks on each code block. Preferably for each operation.
[ ] Make sure contracts with interfaces inherit from the corresponding interfaces.
[ ] Regularly reference these common pitfalls and avoid them like the plague.
[ ] Use static analysis tools such as Slither and Mythril.
<aside> ℹ️ They often raise flags for non-issues, but they can sometimes catch low-hanging fruit.
</aside>
[ ] Setup Continuous Integration.
[ ] Require PR reviews. No commit should be merged without a review.
<aside> ℹ️ The implementer is just the first line of defense. If you are a reviewer, confirm that the implementer followed the best-practices described in this document.
</aside>
<aside> ‼️ Red CI outputs should block merges.
</aside>
[ ] Document you Security and Trust Model Assumptions
[ ] Create a threat model.
[ ] Run the code and comments through a spellchecker.
[ ] If possible, have one trusted Solidity dev or security person outside your organization review your contracts.
<aside> ℹ️ If your code already requires significant changes, you will want to hear that before paying for an audit.
</aside>
What we need to deliver an estimate