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.
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:
When inheriting multiple contracts, especially if they have identical functions, a developer should carefully specify inheritance in the correct order.
Funds are protected and cannot be withdrawn without proper permission.
24
User Balances manipulation
Custom
Contract owners or any other third party should not be able to access funds belonging to users.
25
Data Consistency
Custom
Smart contract data should be consistent all over the data flow.
26
Flashloan Attack
Custom
When 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.
27
Token Supply manipulation
Custom
Tokens can be minted only according to rules specified in a whitepaper or any other documentation provided by the customer.
28
Gas Limit and Loops
Custom
Transaction 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.
29
Style guide violation
Custom
Style guides and best practices should be followed.
30
Requirements Compliance
Custom
The code should be compliant with the requirements provided by the Customer.
31
Environment Consistency
Custom
The project should contain a configured development environment with a comprehensive description of how to compile, build and deploy the code.
32
Secure Oracles Usage
Custom
The 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.
33
Tests Coverage
Custom
The 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.
34
Stable Imports
Custom
The 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”.
The blockchain industry has been grappling with scalability issues, which have hindered widespread adoption due to its technical constraints. As the demand for blockchain, decentralized applications (dApps), and transactions increases, the limitations of existing networks become increasingly apparent. High transaction fees and network congestion have plagued platforms like Ethereum, hampering their ability to support large-scale
The experimental semi-fungible token standard, ERC-404, combines elements from ERC-20 and ERC-721 tokens. Despite rising popularity, it has yet to secure an official Ethereum Improvement Proposal (EIP) designation. However, its unique attributes, such as enabling fractional ownership of NFTs and enhancing liquidity, coupled with the potential for automated NFT minting and burning processes, suggest a
Decentralized applications (dApps) are software that run on a decentralized network, often using blockchain technology. These applications can serve various purposes for end users, such as brokers, art collectors, traders, investors, and documents of public trust. However, their functionality and value attract malicious groups aiming to exploit vulnerabilities for financial gain. This article explores real-world examples of dApp security breaches, their attack vectors, and the lessons learned.
