Audit name:
[SCA] Kei Finance / ERC20 Presale / Sep2023
Date:
Sep 16, 2023
Table of Content
Introduction
We express our gratitude to the KeiFinance team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
DeFi simplified - KEI finance offers an extremely user friendly cross-chain algorithmic trading strategy platform with real world crypto payment solutions.
| title | content |
|---|---|
| Platform | Ethereum, Solana, Bitcoin, Arbitrum, Others |
| Language | Solidity |
| Tags | ERC20, Presale |
| Timeline | 15/08/2023 - 15/09/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/Kei-Finance/presale-contract→ |
| Commit | ea0fb67db4f129e91a85541fbd48a3003f19205f |
Review Scope
- Commit
- ea0fb67db4f129e91a85541fbd48a3003f19205f
Audit Summary
10/10
100%
9/10
10/10
The system users should acknowledge all the risks summed up in the risks section of the report
Document Information
This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.
The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for KeiFinance |
| Audited By | Hacken |
| Website | https://kei.fi/→ |
| Changelog | 22/08/2023 – Initial Review |
| 15/09/2023 – Second Rievew |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for KeiFinance
- Audited By
- Hacken
- Website
- https://kei.fi/→
- Changelog
- 22/08/2023 – Initial Review
- 15/09/2023 – Second Rievew
System Overview
Kei Finance is implementing a presale schedule with the following contracts:
Presale.sol — is a presale contract that allows people to participate by purchasing tokens with
PRESALE_ASSETtoken. Purchased tokens are distributed within the Presale contract during the purchase function call.IPresale.sol — interface of the Presale contract.
IPresaleErrors.sol - interface that stores all custom errors.
Privileged roles
The owner of the Presale contract can:
initialize the Presale contract.
close the presale.
set the
withdrawToaddress.transfer ownership.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Project overview is detailed.
Business logic is provided.
Use cases are described and detailed.
All interactions are described.
Run instructions are provided.
Technical specification is provided.
NatSpec is sufficient.
Code quality
The total Code quality score is 9 out of 10.
Deployment instructions description are provided.
The code largely adheres to the Solidity Style Guide, with a few areas that could benefit from further refinement: \-Function order is incorrect, private functions should go after internal ones.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage are present.
Interactions by several users are tested.
Security score
Upon auditing, the code was found to contain 2 critical, 3 high, 4 medium, and 4 low severity issues. Out of these, 9 issues have been addressed and resolved, leading to a security score of 10 out of 10.
All identified issues are detailed in the “Findings” section of this report.
Summary
The comprehensive audit of the customer's smart contract yields an overall score of 9.8. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
The system has external calls in the purchase() function, which creates a reentrancy risk.
The payment token contract is out of the scope of this review, indicating that it has not been assessed by Hacken. Consequently, assurance regarding the contract's safety or security cannot be provided.
The owner can stop the Presale process at any time using the close() function. Thus, it creates a centralization risk.
The contract employs an initialize() function intended for setting its initial states. While it uses a mechanism commonly associated with upgradable contracts, this specific contract is not upgradable. The initialize function, protected by the onlyOwner modifier, is crucial to be invoked post-deployment to set the contract in its intended operational state. Failure to call this function results in the contract remaining in an uninitialized state, which can cause unintended behaviors or inhibit users from interacting with it as expected. It is essential to verify that initialize was executed appropriately after deployment before any user interaction.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-1440 | Invalid Calculations | fixed | Critical | |
| F-2023-1439 | Data Consistency | fixed | Critical | |
| F-2023-144 | Requirements Violation | mitigated | High | |
| F-2023-144 | Data Inconsistency | fixed | High | |
| F-2023-144 | Unsafe Casting | fixed | High | |
| F-2023-1449 | Data Inconsistency | fixed | Medium | |
| F-2023-1448 | Incorrect Usage of Transfer | fixed | Medium | |
| F-2023-1447 | Missing Zero Address Validation | fixed | Medium | |
| F-2023-144 | Unchecked Return Value | fixed | Medium | |
| F-2023-1453 | Missing Zero Address Validation | fixed | Low |
Identify vulnerabilities in your smart contracts.
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/Kei-Finance/presale-contract→ |
| Commit | ea0fb67db4f129e91a85541fbd48a3003f19205f |
| Whitepaper | Provided→ |
| Requirements | Provided→ |
| Technical Requirements | Provided→ |
Contracts in Scope
contracts/interfaces/IPresaleErrors.solcontracts/interfaces/IPresale.solcontracts/Presale.sol