A smart contract audit is a time-boxed security-based code review on your smart contract/web3 system. An auditor’s goal is to find as many vulnerabilities as possible and educate the client on ways to improve the security of their codebase moving forward.
Auditors use a combination of manual and automated tools to find these vulnerabilities.
According to a research study by Chainalysis, 2022 was the year the most value was stolen from smart contracts. Due to the immutability of the blockchain, once a smart contract is deployed, you can’t change it, so you’d better get it right. The blockchain is an adversarial environment, and your protocol needs to be prepared for malicious users.
But even more than just saving your protocol from hacks, an audit can improve your developer’s understanding of code, improving their speed and the effectiveness of features moving forward.
Additionally, there is an entire website dedicated to how many hacks happen, and we need to do our best as a community to prevent that list from growing further.
Find vulnerabilities
Level-up developers
Teach best practices and the most modern tooling
Often, one audit isn’t enough. Many protocols go on a security journey that includes multiple audits and services like:
Formal Verification
Competitive Audits
Bug Bounty Programs
We’ll break these down in a future post.
There are a lot of companies that offer smart contract auditing services, like
You can see a more detailed list of the top 7 smart contract auditors here.
Additionally, there are a lot of independent auditors that do great work as well.
A typical audit looks like this:
A protocol can reach out before or after their code is finished. Ideally, they reach out some time before so the auditor can have enough time to schedule them.
Once they reach out, the teams will discuss how long the audit will take based on the scope and code complexity.
How long the audit will take depends on how many lines of code the smart contract is made of. A very rough approximation of how long an audit takes depending on how many source lines of code you have can be found here:
The duration sets the price, and prices can range widely based on the different auditors at the time of writing.
At the time of recording, a one-week-long audit can go anywhere from:
Duration: Price
- 1 week: $5,000 - $100,000
The range is massive, but I have seen pricing anywhere in this range.
Auditors need to know exactly what code they are auditing and use the commit hash of your repo to do so. Once you have a commit hash, you can reach a start date and finalize the price.
Then the audit starts! Your auditors will use every tool in their arsenal to find vulnerabilities in your code.
After the period ends, the auditors will give you an initial report that looks like this.
All their findings are listed by severity, usually formatted into:
High, medium, and low represent the severity of the impact and the likelihood of each vulnerability. Informational, Gas, and Non-Critical are findings that don’t highlight vulnerabilities, but instead, opportunities to improve the efficiency and structure of your cod
The protocol team will then decide on a time to fix the vulnerabilities found in the initial audit report. Sometimes, depending on the severity of the findings, this may be long but is often much shorter than the audit itself.
After the protocol makes the changes, the audit team will do a final audit report exclusively on the fixes made to address the issues brought up in the initial report. And then, hopefully, the auditors and protocols have had a great experience and will work together to stay secure in the future!
To get the most out of an audit, you should:
However, the most important part of the process comes during the audit.
You want to think of you and your auditor as a team to get the best results out of your audit. One of the best ways to do this is to have a dedicated channel where auditors can ask questions to the developers.
Additionally, the more context, documentation, and information they can read, the better. Be sure it’s easy for anyone to walk through your code and understand what it’s supposed to do.
80% of all bugs are due to business logic issues, so the auditors need to understand what the protocol should do more than they should understand the actual code!
Having a modern test suite & tooling can also make it so auditors spend less time fidgeting with your tooling and more time finding issues. A high-level video walkthrough of your code should be the first thing you and the auditors do together.
We highly encourage you to act on the recommendations of an audit report, we’ve seen too many protocols not take warnings seriously, and eventually suffer from that attack vector getting exploited.
Additionally, if you change your codebase, that is now unaudited code, and should not be pushed, no matter how small the change may be. If you change your code, consider getting that piece of code audited.
And often, depending on how much money your protocol will secure, you should consider getting another audit anyway!
One audit does not mean your code is bug-free. It’s a security journey where your team should level up on security. No matter how experienced an auditor or audit firm is, people at all levels of experience will miss something. On the sad day that it happens, get together on an emergency communication channel with your auditors and figure out how to remedy the situation quickly.
Insurance is often a good idea for even the most audited protocols.
With that, you have a good idea of the smart contract audit process end-to-end and what to expect. A smart contract audit is more of a security journey between the protocol and the auditors, and having a security-focused mindset doesn’t end even after the audit.
And as always, stay safe out there!
Also published here.