A smart contract audit is essential if your company plans to use blockchain technology effectively. Above all else, you must ensure that the smart contracts are secure. Every now and then the community buzzes with news about companies that forgo an audit and end up getting hacked. Millions of dollars disappear as a result. You don’t want to make the headlines here. How can you mitigate the risk? A professional set of eyes scouring the code helps secure a product. Here are some steps an effective smart contract audit should include.
First steps
Before you submit your STO audit request, get organized. It’s good to spend some time preparing yourself to save the auditor from the most basic checks. Begin by running automated checks. All unit tests should pass and the code formatting should be verified using a linter and the compiler should not report warnings. There are also more sophisticated tools such as Mythril which can analyze the code for potential security issues.
After the automated checks are complete you may want to ask the developers if they see any so-called code smells or deep flaws that need immediate attention. Perhaps there are some good practices that they know to introduce. A few hours of refactoring bad code can go a long way in terms of readability, which facilitates the STO audit overall.
Specify your requirements
Once the stuff that can be done in-house is out of the way you can specify your requirements with the auditor. For example, define how the smart contracts should behave. No active development on the code itself should continue at this point. There are a few ways to hand over a specific version of the code for your smart contracts. A public GitHub repository is usually fine — the smart contract audit report can mention a git commit ID to exactly point to the checked smart contracts. Alternatively, you can deploy a working version of the smart contracts to a public network and verify their code, e.g. on etherscan.io, to employ the immutable nature of the blockchain.
With the specifications in mind, the auditor can check the business logic of the smart contracts. Are all use cases implemented correctly? Are there any execution paths that can break the contract? Have you missed a zero somewhere? Is the tokenomics model fair or are there loopholes for someone to exploit? These are just a few of the questions an auditor may ask in the STO audit.
Finally, the auditor can dive deep into your smart contracts. There are a few different perspectives to analyze the smart contracts. Business, security, and best practices all play a role in the analysis.
Security in a smart contract audit
Looking for security vulnerabilities is usually the core value of a smart contract audit. Finding them requires experience so it’s not easy to do in-house. These kinds of bugs are hard to spot. Take the DAO hack as an example — a reentrancy vulnerability that resulted in huge losses and even a split in the Ethereum community. This bug is only one of the rare conditions that auditors need to look for during a smart contract audit.
Other typical Ethereum smart contract security issues to check are incorrectly set permissions (e.g. calling admin functions from an unprivileged account), integer under and overflows, timestamp dependence and forcibly sending Ether to a contract. Some argue the ERC-20 token standard is unsafe because it allows token transfers to smart contracts. Attackers may also exploit the allowance mechanisms. The list goes on, that’s why the auditors keep up to date with the latest exploits and learn what to focus on in smart contract code.
The last perspective I’d like to shed some light on is the one of an engineer. Some clients view audits as a thorough code review. As such, these can include remarks on the code quality and best practices. The rule of thumb is that the simpler the smart contracts are the better — there are fewer bugs that way. The project may also use some outdated or unsafe language features or libraries. It may even use up-to-date stuff incorrectly. Lastly, there are usually some best practices for writing smart contracts for specific platforms, such as Ethereum Smart Contract Best Practices by ConsenSys.
STO audit report
A good STO audit should produce a detailed report. Let me reiterate a few key sections that you should look for.
- The audit background, which is basically a description of the request. It may link the specification of requirements and should point out the version of the code under audit.
- The core of the report — found issues. Some suggest ordering them only by severity (critical, medium, low) but I’d also find it useful to additionally group them by perspective (business, security, best practices). Each issue should have a title, severity, description (pointing out the vulnerable code as precisely as possible) and a recommendation on how to fix it. Code snippets or unit tests that show how to exploit the vulnerability are very welcome.
- To conclude the report some recommendations are in order. An auditor may suggest next steps such as delaying the production deployment until critical issues are resolved or running a bug bounty.
What Next?
After reading the report you need to decide on your priorities. Can you squeeze in a few days of bug fixing before going live on production networks? Bear in mind that once a smart contract is on the blockchain you can’t change it. Ideally, you should resolve all outstanding issues and have the auditor look at the updated code (re-audit). To increase transparency and gain trust you can publish the STO audit report and results of the re-audit. You can also consider auditing the other parts of your solution such as frontend or backend modules, especially where blockchain integration happens. After all, even the smartest of contracts can’t protect you from private key theft.
Summing up, an STO audit that includes a smart contract audit should cover all the elements described above. It’s is a complex task but such a thorough analysis can save you and your investors from potential hacks, loss of funds, and bad PR. Don’t stop at the audit though, as it’s not a perfect tool and it might not find every issue. From the beginning of the project invest in a development team with experience and technical knowledge that follows security best practices, knows the common vulnerabilities, and how to write code effectively.