Blog
Smart contract audits occur for security purposes, but most projects view it as a marketing strategy. Whatever the reason the project gets an audit, in the end, a report is produced with actionable information — the report details the scope, findings, severity, and recommendations. The projects generally have their development team read over the report and address any critical issues before publicly publishing a final draft. How to read a smart contract audit report could be a daunting task for investors.
Reading the report doesn’t need to be complicated. I’ll break down sections of an audit report, hopefully demystifying it. We’ll use the current AuditOne.io template.
This section of the report specifies auditors in charge of the audit and the project that requested the audit. A brief description of the project and its objectives.
This section also highlights the methodology. AuditOne has an internal automated testing tool that can quickly audit the contract. After that is complete, auditing experts can manually review the contracts using various methods. Automated analysis can spot common vulnerabilities giving the auditor more time to examine the contract thoroughly. A combination of these methods supports each other as manual analysis can identify false positives if they arise due to the automated analysis.
The scope of the audit is to analyze the smart contract files provided by the project located in their repository.
It explicitly states the type of contract auditors will audit, ERC20 or BEP20, for example. Smart contract language, most common is solidity, but some projects like Solana use Rust. The platform deals with what network the contract is on Ethereum, Polkadot, and Tezos, to name a few.
The code needs to be tested whether the dev team performed unit testing or not. Providing unit tests to the auditor goes a long way. A list of all the audited contracts is required; investors can check the network to see if they are the contracts with which they are interacting or are still in use.
Documentation is crucial as it helps auditors understand the project faster. It shows the team put effort into their project if they got that done.
Specific commit lets you know which version of the code was audited in their repository, and if the current version isn’t, the same changes could have been made that had a material impact on the audit.
Summary of the report findings. It contains essential information, such as the parties involved in the audit. What was audited, and how long does it take to finish the audit. Most importantly, a short explanation of the findings. A table with the number of vulnerabilities found, severity levels, and description of the vulnerabilities.
Finding a vulnerability doesn’t mean the contract or project is terrible. The purpose of the audit is to discover this. The most crucial point to note is the team taking action on the findings.
In most audit reports, you might have come across the terms critical, high, medium, low, informational, and undetermined. They usually appear in a table listed next to their definitions.
I will shorten it
Critical: Pull the fire alarm and fix this right away!
High: Be cautious; hackers might exploit this given the right conditions.
Medium: If you don’t lose anything from not fixing it, why not fix it?
Low: Using outdated syntax; stop it!
Informational: Not following best practices, you should do it. It’s not all cosmetics.
Undetermined: We don’t know what this could do; maybe it’s a mole or cancer.
Vulnerability Checklist [SWC Registry]
AuditOne requires its auditors to go through a specific checklist of known vulnerabilities during the testing. It is an extensive list of known smart contract weaknesses classification registries. It also contains solutions to fix some of these bugs.
We use an internal testing tool that generates a report. The tool extensively analyses the contract before providing a score and a list of vulnerabilities found. Automated test tools such as Slither are great for being able to instantly verify added/new code on vulnerabilities and bugs. Not directly related to the smart contract security, but the project itself often faces risks such as how the treasury wallet is accessed, e.g., a multi-sig to understand the risk of collusion or operational errors. Another essential aspect is the design of the token economics that ultimately decides on supply and emissions potentially leading to flaws and more sell pressure on a token. Projects being aware of such risks and managing these risks have a greater chance of long-term success
This section focuses on codebase maturity. It covers code quality, documentation, security, and architecture.
Arguably one of the most important parts of the report is buried at the end, which is valuable information to the users and investors of the protocol.
As stated before, findings are categorized into several levels ranging from critical to informational. Severity allows readers to understand which of the issues found can significantly impact the protocol released. Problems are defined and accompanied by a snippet of the affected code. After reading this section, you can generally know the issue’s impact if left unattended.
The auditor lists their recommendations for fixing this problem. It is essential since it might reveal flaws in the protocol or development process.
This section is simple; not because the project got an audit means it’s secure.
Audit != Secure
Audits do not mean secure; multiple audits can still miss bugs than total the protocol when exploited.
Heeding the auditors’ recommendations can go a long way in securing the codebase. Not all vulnerabilities can be discovered during the process of the audit. AuditOne.io can provide auditors to ensure your smart contracts are protected.
.png)
.png)