How to perform a smart contract audit?

Last year our HashEx team performed more than 50 smart contract audits and wrote more than 100 smart contracts. In this post we want to share HashEx smart contract audit framework. This framework is suitable for any DApp, not only the ones built on Ethereum network.

Before we start describing typical security issues in smart contracts, we want to say a few words about the audit report structure. HashEx audit report consists of 7 sections:

  1. Disclaimer. This part of report is actually more important than you would think. As auditor you need to explain to your client that passing your audit is not the ultimate security insurance. Everyone can make mistakes and you are not an exception.
  2. Background. Why do you do this audit? Who gave you permissions?
  3. Critical Severity Issues. This part is about issues and vulnerabilities which can cost your client unlimited amount of funds.
  4. High Severity Issues. Here you describe issues which can cost your client limited amount of funds. This amount can be calculated before contract deployment.
  5. Low Severity Issues. This part is not about losing funds. It is about minor problems or better solutions.
  6. General Recommendations. Here you provide recommendations on code improvement and best practices implementation.
  7. Conclusion. Here you describe the next steps for your clients after they read the report :)

Now that you know how to structure audit information, let’s talk about typical issues.

  1. Unit tests passing, checking tests configuration (matching the configuration of main network);
  2. Compilator warnings;
  3. Race Conditions. Reentrancy. Cross-function Race Conditions. Pitfalls in Race Condition solutions;
  4. Possible delays in data delivery;
  5. Transaction-Ordering Dependence (front running);
  6. Timestamp Dependence;
  7. Integer Overflow and Underflow;
  8. DoS with (unexpected) Revert;
  9. DoS with Block Gas Limit;
  10. Call Depth Attack. Not relevant in modern ethereum network :)
  11. Methods execution permissions;
  12. Oracles calls;
  13. Economy model. It’s important to forecast scenarios when user is provided with additional economic motivation or faced with limitations. If application logic is based on incorrect economy model, the application would not function correctly and participants would incur financial losses. This type of issue is most often found in bonus rewards systems.
  14. The impact of the exchange rate on the logic;
  15. Private user data leaks.

Once you checked against the issues above, you can use auto-testing tools to polish your audit report. Do not expect that they will make a serious contribution, but sometimes they could be useful.

HashEx website:

Connect with me via LinkedIn