🇺🇦 Hacken was born in Ukraine, and we stand with all Ukrainians in our fight for freedom!

🇺🇦 Hacken stands with Ukraine!

Learn more



Published: 26 Jun 2022 Updated: 2 Feb 2023

Crypto projects should realize the scope of risks associated with smart contracts and know how to address them. The most common threats related to smart contracts are operational, implementation, and design risks. 

No changes can be introduced into a smart contract once it is deployed. 

How does the Smart Contract Audit Help? – Best Practices

Most developers need guidance on how to write secure and high-quality smart contracts. 

The value of Hacken audit methodology for developers:

  • Understanding of the audit process and its phases.
  • Recommendations on how to ensure secure development of a project. 
  • Explanation of the mistakes made by a project.
  • Provision of best practices of how to develop a safe code.

Smart Contract Audit is the most robust security solution for the development phase and contract upgrades.

One of the key competitive advantages of Hacken is our transparency. In this material, we would like to share with you a brief overview of the Hacken smart contract audit methodology. Clients should be fully aware of the score of services they get when applying for a smart contract security audit. 

Smart Contract Audit Process – 6 Steps

Phases of Hacken smart contract audit

#1 Preparation for a Smart Contract Audit 

Preparation for an audit is as necessary as the audit itself. 

During the preparation, customers review their projects to make sure everything they have planned is correctly implemented. At this stage, clients themselves can detect many issues. 

To get maximum value from the audit, clients should make the following:

  • Prepare functional requirements for the project.
  • Prepare a technical description of the project.
  • Set up the development environment of the project.
  • Prepare unit tests.
  • Ensure that code follows best practices and security standards

Functional requirements

Answer the following question: “What do we want to achieve via these smart contracts?”

Functional requirements need to be clear, simple, and unambiguous. 

User stories can be useful as well.

Technical description

Information about the used languages and technologies, deployment instructions, instructions on how to run tests, etc. Non-functional requirements can also be included in this section.

Setup development environment of the project

A development environment for the project should be configured by the Customer. Truffle, Hardhat, or any other comprehensive development environment can be used. A customer should provide a proper description of the environment. An example of the project environment configuration can be found here.

Unit tests

The code should be covered with unit tests. Test coverage should be 100%, with both positive and negative cases covered. Test cases that imitate the usage of contracts by multiple users should be provided to ensure that contracts will not be vulnerable to DoS attacks and that operations of one user do not affect the other unless it is a part of the requirements. The test should be executed on the emulated VM without the need to run local VM’s or connect to testnets.

We recommend using TDD during the development process. 

Security standards

The Customer should ensure that the code is compliant with standards provided by the Ethereum Enterprise Alliance.

#2 Tools for Code review and analysis

Code review and analysis are performed by 2 separate auditors who don’t share results with each other during the initial phase of an audit. Additional review is performed by a lead auditor. All steps of this process:

  • Overall review
  • Scan by automated tools
  • Funds and data flow diagrams
  • Line-to-line review
  • Checked items
  • Analysis of received data

Overall review

2 auditors read the code to understand its structure and purpose and examine functional and technical requirements as well as other documents provided by clients. The main outcome of this step is a high-level description of the code provided by auditors that is used internally during the next steps of the audit.

Scan by automated tools

Automated tools are used to search for simple issues and find more information about smart contracts under review. The following tools are used: 

  • Slither – Static analysis of Solidity source code for security vulnerabilities and best practices. 
  • Mythril – Reversing and bug hunting framework for the Ethereum blockchain.
  • Solgraph – Generates a DOT graph that visualizes the function control flow of a Solidity contract and highlights potential security vulnerabilities.
  • Echidna – program designed for fuzzing/property-based testing of Ethereum smart contracts.
  • And other proprietary tools.

Funds and data flow diagrams

Auditors visualize all possible states of the contract and all its interactions with other contracts. All changes in data and funds flow should be displayed on those diagrams. 

During this step, some issues can be found and recorded by auditors and they can better understand smart contracts before line-to-line review.

BPMN and UML diagrams are used to visualize funds and data flows

Line-to-line review

Auditors thoroughly read each line of the code and record issues such as the ones described in SWC. We also look for possible data manipulations, access violations, flash loans, and other manipulations that can be performed through the interaction with other contracts. This step also includes validation of the code according to code-style guides and best practices. 

Checked Items

Auditors provide verification of the following items:

1Default VisibilitySWC-100SWC-108Functions and state variables visibility should be set explicitly. Visibility levels should be specified consciously.
2Integer Overflow and UnderflowSWC-101If unchecked math is used, all math operations should be safe from overflows and underflows.
3Outdated Compiler VersionSWC-102It is recommended to use a recent version of the Solidity compiler.
4Floating PragmaSWC-103Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly.
5Unchecked Call Return ValueSWC-104The return value of a message call should be checked.
6Access Control & AuthorizationCWE-284Ownership takeover should not be possible. All crucial functions should be protected. Users could not affect data that belongs to other users.
7SELFDESTRUCT InstructionSWC-106The contract should not be self-destructible while it has funds belonging to users.
8Check-Effect- InteractionSWC-107Check-Effect-Interaction pattern should be followed if the code performs ANY external call.
9Assert ViolationSWC-110Properly functioning code should never reach a failing assert statement.
10Deprecated Solidity FunctionsSWC-111Deprecated built-in functions should never be used.
11Delegatecall to Untrusted CalleeSWC-112Delegatecalls should only be allowed to trusted addresses.
12DoS (Denial of Service)SWC-113SWC-128Execution of the code should never be blocked by a specific contract state unless it is required.
13Race ConditionsSWC-114Race Conditions and Transactions Order Dependency should not be possible.
14Authorization through tx.originSWC-115tx.origin should not be used for authorization.
15Block values as a proxy for timeSWC-116Block numbers should not be used for time calculations.
16Signature Unique IdSWC-117SWC-121SWC-122EIP-155Signed messages should always have a unique id. A transaction hash should not be used as a unique id. Chain identifier should always be used.
17Shadowing State VariableSWC-119State variables should not be shadowed.
18Weak Sources of RandomnessSWC-120Random values should never be generated from Chain Attributes or be predictable.
19Incorrect Inheritance OrderSWC-125When inheriting multiple contracts, especially if they have identical functions, a developer should carefully specify inheritance in the correct order.
20Calls Only to Trusted AddressesEEA-Level-2 SWC-126All external calls should be performed only to trusted addresses.
21Presence of unused variablesSWC-131The code should not contain unused variables if this is not justified by design.
22EIP standards violationEIPEIP standards should not be violated.
23Assets integrityCustomFunds are protected and cannot be withdrawn without proper permission.
24User Balances manipulationCustomContract owners or any other third party should not be able to access funds belonging to users.
25Data ConsistencyCustomSmart contract data should be consistent all over the data flow.
26Flashloan AttackCustomWhen working with exchange rates, they should be received from a trusted source and not be vulnerable to short-term rate changes that can be achieved by using flash loans. Oracles should be used.
27Token Supply manipulationCustomTokens can be minted only according to rules specified in a whitepaper or any other documentation provided by the customer.
28Gas Limit and LoopsCustomTransaction execution costs should not depend dramatically on the amount of data stored on the contract. There should not be any cases when execution fails due to the block gas limit.
29Style guide violationCustomStyle guides and best practices should be followed.
30Requirements ComplianceCustomThe code should be compliant with the requirements provided by the Customer.
31Environment ConsistencyCustomThe project should contain a configured development environment with a comprehensive description of how to compile, build and deploy the code.
32Secure Oracles UsageCustomThe code should have the ability to pause specific data feeds that it relies on. This should be done to protect a contract from compromised oracles. 
33Tests CoverageCustomThe code should be covered with unit tests. Test coverage should be 100%, with both negative and positive cases covered. Usage of contracts by multiple users should be tested.
34Stable ImportsCustomThe code should not reference draft contracts, that may be changed in the future.

Each item can have one of the following statuses: Passed, Failed, Not Related.

#3 Testing

If unit tests are configured for the project, auditors check coverage and write their own test cases if required. Ideally, code coverage should encompass all positive and negative cases. Some issues can be reproduced with the invalid config of dependency contracts. Auditors create such configs and run corresponding tests. 

If unit tests are not configured, auditors deploy smart contracts on the local network and check all required cases. 

Some sophisticated issues require complex exploiting contracts. Usually, if it is unclear how the issue can be exploited, auditors provide the sample attacking contracts. 

#4 Reporting 

Both auditors review their findings and audit artifacts and share results with each other. All disputable points in the code are discussed internally with the team. Auditors prepare materials for the report. Lead auditor reviews all materials prepared by the two other auditors and performs his own code review. Most possible issues are already documented at this step.

After all code review, analysis, and tests, auditors prepare a report with the following structure:

  • Introduction
  • Scope
  • Executive Summary
  • Severity Definitions
  • Findings
  • Recommendations
  • Disclaimers

#5 Bug fixing

All issues are reported to the Customer in a draft report. If some points are unclear, we can provide more descriptions of issues or explain everything on a call.

The customer can receive one free remediation check when:

  • No more than 15% of all code has been changed. 
  • The fixes have been introduced within 10 business days
  • The code structure has not been changed. Except for the situation when a recommendation was provided by auditors.
  • The customer describes all changes introduced to the code.
  • The code contains only fixes of issues described in the Audit overview section of the report.

After all fixes are validated, the final report is provided to the customer.

#6 Scoring

The score contains several metrics: 

  • Documentation quality (D)
  • Code quality (C)
  • Architecture quality (A)
  • Security level (S)

Each metric has its own weight in the total score. The score has a decimal value with 1 decimal point. The score may vary between 0.0 and 10.0.

Maximum weights of each metric:

  • D – 1.0
  • C – 1.0
  • A – 1.0
  • S – 7.0
Score calculation

Documentation quality

The project code should be provided with corresponding documentation. Functional and technical requirements are required. 

Functional and technical requirements’ total weight is 5.0 each. The weight in the overall score is 1.0.

Code quality

The code should follow official language style guides and be covered with unit tests. If most of the code follows those guides, the score is 3. Partially follows – 2.5. Not follows – 0.0.

Test coverage has a maximum weight of 7.

The weight in the overall score is 1.0. 

Architecture quality

Smart contracts of the project should follow the best practices. 

Clean and clear architecture and well-configured development environment – 10.

The weight in the overall score is 1.0.

Security level

The most important metric of the score. 

Issues have 4 levels of severity: critical, high, medium, and low. Only actual issues are considered in the score calculation. Actual issues have the following statuses: “new” and “reported” (previously “acknowledged”).

Each critical, high, and medium issue decreases the score:

  • Minus 10 per critical.
  • Minus 5 per each high.
  • Minus 1 per each medium.

The minimum score is 0, maximum is 10.

The weight in the total score is 7.0.

Total Score Calculation

The total score calculation formula is D+C+A10+S710

Overall, a smart contract audit is an essential form of security testing for Web 3.0 projects allowing them to win users’ trust and confidence that their assets are in safety. Hacken smart contract audit methodology has been developed with regard to the deep expertise of our security engineers. We keep on improving this methodology to deliver a better quality of security services to clients. Only when cybersecurity grows faster than malicious hacking, then we can say “Web 3.0 is becoming a safer place”.  

share via social

Subscribe to our research

Enter your email address to subscribe to Hacken Research and receive notifications of new posts by email

Interested in getting to know whether your systems are vulnerable to cyberattacks?

Tell us about your project

  • This field is required
  • This field is required
    • telegram icon Telegram
    • whatsapp icon WhatsApp
    • wechat icon WeChat
    • signal icon Signal
  • This field is required
  • This field is required
This field is required
departure icon

Thank you for your request

Get security score on

  • certified logo
  • coingeco logo
  • coin market cap logo

1,200+ Audited Projects

companies logos

Apply for partnership

  • This field is required
  • This field is required
  • This field is required
  • This field is required
    • Foundation
    • VC
    • Angel investments
    • IDO or IEO platform
    • Protocol
    • Blockchain
    • Legal
    • Insurance
    • Development
    • Marketing
    • Influencer
    • Other
This field is required
This field is required
departure icon

Thank you for your request

Get security score on

  • certified logo
  • coingeco logo
  • coin market cap logo

1,200+ Audited Projects

companies logos

Get in touch

  • This field is required
  • This field is required
  • This field is required
  • This field is required
This field is required
By submitting this form you agree to the Privacy Policy and information beeing used to contact you
departure icon

Thank you for your request

Get security score on

  • certified logo
  • coingeco logo
  • coin market cap logo