Audit name:
[SCA] VIMworld | Staking | Jan2024
Date:
Feb 21, 2024
Table of Content
Introduction
We express our gratitude to the VIMworld team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Vim is a protocol used to handle user funds and deploy them into multiple strategies.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity |
| Tags | Autocompounder |
| Timeline | 30/01/2024 - 06/02/2024 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/vimworldinc/vimworld-contracts-eth→ |
| Commit Hash | d3b3fdf |
Review Scope
- Commit Hash
- d3b3fdf
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 VIMworld |
| Audited By | , Viktor Raboshchuk |
| Approved By | Przemyslaw Swiatowiec |
| Website | - |
| Changelog | 07/02/2024 - Preliminary Report, 21/02/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for VIMworld
- Audited By
- , Viktor Raboshchuk
- Approved By
- Przemyslaw Swiatowiec
- Website
- -
- Changelog
- 07/02/2024 - Preliminary Report, 21/02/2024 - Final Report
System Overview
Vim World is a protocol that uses various strategies, in partnership with other protocols, to enhance the yield earned in decentralized finance (DeFi)
Privileged roles
There are several privileged roles in the contracts. Every function requires privileged roles to be called because the strategies in this protocol are meant to be used and called from the vault. The following roles exists in the protocol:
Vault management - can sweep tokens from the contract.
Keepers - can only harvest and tend a strategy.
Governance can:
harvest and tend a strategy
call setEmergencyExit()
sweep tokens
change strategists, and set keeper
set minReportDelay and maxReportDelay
set profitFactor, debtThreshold and metadataURI.
make emergency withdrawal
prevent the strategist from adding questionable lenders.
Strategist can:
remove lenders for safety
harvest and tend a strategy
call setEmergencyExit()
set keeper or strategist
set minReportDelay and maxReportDelay.
set profitFactor, debtThreshold and metadataURI
change the reward address
Executive Summary
Documentation quality
The total Documentation Quality score is 10 out of 10.
Functional requirements are provided.
Technical description is provided.
NatSpec is sufficient.
Code quality
The total Code Quality score is 9 out of 10.
Initiliazing importart variables to the default value might be risky for the integrity of the contract.
Test coverage
Code coverage of the project is 100% (branch coverage)
Tests are missing.
Security score
Upon auditing, the code was found to contain 0 critical, 0 high, 0 medium, and 1 low severity issues. All issues were fixed in the remediation process of this audit 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 contracts in this repository are upgradeable, which allows for their modification and improvement over time. However, this feature also introduces potential risks. One significant risk is that an upgrade could inadvertently introduce vulnerabilities into the contracts. If the contracts' code is changed to a version that contains security flaws, it could expose the contracts to attacks
The contracts in this repository heavily utilize external contracts such as IVault and others that are out of the scope of this audit. This presents a significant risk as it limits the comprehensiveness and precision of the audit. The functionality and security of the audited contracts are closely tied to these external contracts. If these external contracts contain vulnerabilities, behave unexpectedly, or are upgraded in a way that is incompatible with the audited contracts, it could lead to failures or security issues in the audited contracts. Furthermore, the interactions between the audited contracts and these external contracts are complex and could contain subtle bugs or security issues that are difficult to detect without a thorough audit of the external contracts. To mitigate this risk, it is recommended to extend the scope of the audit to include these heavily utilized external contracts, or to obtain and review audit reports of these external contracts if they are available.
The contracts in this repository lack associated tests and documentation. This presents a significant risk as it hampers the ability to verify the correctness of the code and understand its intended behavior. Without tests, it's difficult to ensure that the contracts behave as expected under all conditions. Tests are a crucial part of the development process, providing a way to catch and fix bugs before they can cause problems in a live environment. The absence of tests increases the risk of undetected bugs and vulnerabilities in the contracts. The lack of documentation further compounds this risk. Without clear documentation, it's challenging for developers, auditors, and users to understand what the contracts are intended to do and how they should be used. This can lead to misuse of the contracts, unexpected behavior, and difficulties in auditing and maintaining the code. To mitigate this risk, it is recommended to develop a comprehensive suite of tests that cover all significant paths through the contracts. It's also recommended to create thorough documentation that describes the purpose and usage of each contract, its functions, and its interactions with other contracts.
In the contract WETHStrategyToLido.sol there is a parameter for the slippageProtectionOut that is set to 1.5% slippage, on big swaps this could lead to significant financial loss.
The project utilizes Solidity version 0.8.20 or higher, which includes the introduction of the PUSH0 (0x5f) opcode. This opcode is currently supported on the Ethereum mainnet but may not be universally supported across other blockchain networks. Consequently, deploying the contract on chains other than the Ethereum mainnet, such as certain Layer 2 (L2) chains or alternative networks, might lead to compatibility issues or execution errors due to the lack of support for the PUSH0 opcode. In scenarios where deployment on various chains is anticipated, selecting an appropriate Ethereum Virtual Machine (EVM) version that is widely supported across these networks is crucial to avoid potential operational disruptions or deployment failures.
The POWA token has unlimited minting capabilities, this might be a risk in case the minter role or owner role get compromised.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-0796 | Misinterpretation of minReportDelay and maxReportDelay as Block Numbers | fixed | Low | |
| F-2024-0797 | Lack of Initialization for Critical Parameters | accepted | Observation | |
| F-2024-0791 | Missing Checks for Zero Address | fixed | Observation | |
| F-2024-0788 | Cache State Variable Array Length In For Loop | fixed | Observation | |
| F-2024-0786 | Unsafe Approval | fixed | Observation | |
| F-2024-0785 | Using private rather than public for constants, saves gas | fixed | Observation | |
| F-2024-0783 | Custom Errors in Solidity for Gas Efficiency | fixed | Observation |
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/vimworldinc/vimworld-contracts-eth→ |
| Commit Hash | d3b3fdf |
| Whitepaper | - |
| Requirements | - |
| Technical Requirements | - |
Scope Details
- Commit Hash
- d3b3fdf
- Whitepaper
- -
- Requirements
- -
- Technical Requirements
- -