Introduction
We express our gratitude to the HedgeFarm team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Smart Farmooor is a vault that helps users earn a higher return on their cryptocurrency by analyzing and allocating their assets across multiple yield markets.
| title | content |
|---|---|
| Platform | Avalanche |
| Language | Solidity |
| Tags | Yield Farming |
| Timeline | 15/03/2023 - 11/04/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/HedgeFarm/smart-farmooor-contracts→ |
| Commit | da2e6465c12a5bcbcb524abb85850044bb86db88 |
Review Scope
- Commit
- da2e6465c12a5bcbcb524abb85850044bb86db88
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 HedgeFarm |
| Audited By | Hacken |
| Changelog | 22/03/2023 – Initial Review |
| 11/04/2023 - Second Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for HedgeFarm
- Audited By
- Hacken
- Changelog
- 22/03/2023 – Initial Review
- 11/04/2023 - Second Review
System Overview
Smart Farmooor is a vault that helps users earn a higher return on their cryptocurrency by analyzing and allocating their assets across multiple yield markets.
It uses complex calculations to ensure assets are allocated in the most optimal way, taking into account factors like performance, strength, and safety. It’s a great choice for those looking to maximize their returns while minimizing risk.
Each of the SmartFarmooor contracts is responsible for managing one asset. The main contract interacts with users who can deposit/withdraw a given asset. It mints/burns IOU for users and deploys assets to underlying yield modules according to a precalculated allocation.
Yield modules are connectors to external protocols where users' assets are deposited.
The vault is fully composable and built on top of trusted protocols (Aave, BenQi, Stargate, TraderJoe Lend).
The vault should be able to take the weight as parameters and do a reallocation of assets to supported yield markets.
The vault design should be modular and allow for the addition of new protocol supports (new modules) without redeploying the core of the vault.
Everything should be done on-chain and no access to the funds by the team should be possible (unruggable).
The vault must be fully liquid at any time without any lockup period, funds should be accessible to withdraw at all times (asynchronous withdrawal on the yield market should be supported).
The vault should support the following assets on the Avalanche Blockchain: BTC.b, USDC, USDT, sAVAX and AVAX.
The vault should have a method accessible (with access rights) to harvest the rewards/fees.
The files in the scope:
SmartFarmooor.sol - Upgradable contract. This is where all the modules are added.
BaseModule.sol - Abstract contract that inherits Rescuable.sol. The base module is inherited by all the modules (AaveYieldModule, CompoundV2Module, StargateYieldModule).
AaveYieldModule.sol - The Aave module is responsible for interacting with the Aave lending protocol.
CompoundV2Module.sol - The CompoundV2 abstraction is responsible for abstracting the logic of all forks of CompoundV2.
StargateYieldModule.sol - The Stargate Yield module is responsible for interacting with the Stargate protocol and managing liquidity on it.
TraderJoeDexModule.sol - Module to interact with Trader Joe DEX.
NativeGateway.sol - gateway to convert native tokens to wrapped native tokens.
Rescuable.sol - Can rescue tokens and native currency.
RoleManagement.sol - manages the different roles.
Modifier.sol - contains 2 modifiers.
IDex.sol - Interface which is a face for Dex handlers implementations.
IJoeRouter01.sol - Trader Joe’s DEX interfaces.
IJoeRouter02.sol - Trader Joe’s DEX interfaces.
INativeGateway.sol - Interface inherited by NativeGateway.sol.
ISmartFarmooor.sol - Interface inherited by SmartFarmooor.sol.
IYieldModule.sol - Interface inherited by BaseModule.sol.
IPool.sol - Aave interface used in AaveYieldModule.sol.
IPoolDataProvider.sol - Aave interface used in AaveYieldModule.sol.
IRewardsController.sol - Aave interface used in AaveYieldModule.sol.
IScaledBalanceToken.sol - Aave interface used in AaveYieldModule.sol.
WadRayMath.sol - Aave library that provides functions to perform calculations with Wad and Ray units.
ComptrollerInterface.sol - Compound v2 interface used in CompoundV2Module.sol.
CTokenInterface.sol - Compound v2 interface used in CompoundV2Module.sol.
ExponentialNoError.sol - Exponential module for storing fixed-precision decimals (from BenQi).
INativeWrapper.sol - Wrapped native token (wAVAX) interface used in CompoundV2Module.sol and NativeGateway.sol.
ILpStaking.sol - Stargate interface used in StargateYieldModule.sol.
IPool.sol - Stargate interface used in StargateYieldModule.sol.
IStargateRouter.sol - Stargate interface used in StargateYieldModule.sol.
Privileged roles
SmartFarmoor:
DEFAULTADMINROLE: can authorize contract upgrade, can add modules, can set the fee manager, can set the performance fee, can set the minimum and the maximum (cap) amount for deposits, can set automation rules, can pause/unpause, can rescue tokens and native tokens.
MANAGER_ROLE: can remove modules, can set module allocation, can finish panic, can set the minimum harvest threshold.
PANICOOOR_ROLE: can panic.
PRIVATEACCESSROLE: deposit and withdrawal functions can be open or limited to private access roles.
NativeGateway:
Owner: can rescue tokens and native tokens.
AaveYieldModule:
Owner: can set DEX contract address, can set a new rewards token, can approve a DEX, can rescue tokens and native tokens.
Smart Farmoor: can deposit, withdraw and harvest.
CompoundV2Module:
Owner: can set DEX contract address, can set a new rewards token, can approve a DEX, can rescue tokens and native tokens.
Smart Farmoor: can deposit, withdraw and harvest.
StargateYieldModule:
Owner: can set DEX contract address, can set a new rewards token, can approve a DEX, can rescue tokens and native tokens. Also has all the manager roles.
Smart Farmoor: can deposit, withdraw and harvest.
Manager: can set the stargate pool id, can set the Stargate redeem Chain id, can set the Stargate staking pool id, can set the minimum LP profit threshold to withdraw.
TraderJoeDexModule:
Owner: can set routes, can delete routes, can rescue tokens and native tokens.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional documentation is satisfactory.
Technical documentation is satisfactory.
NatSpecs are present and useful.
Code quality
The total Code quality score is 9 out of 10.
Solidity style guidelines are not fully followed.
There are some low code quality issues.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is present.
Interactions with several users are tested.
Security score
Upon auditing, the code was found to contain 0 critical, 1 high, 4 medium, and 13 low severity issues. Out of these, 16 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 claims to use multi sigs (GnosisSafe implementation) to manage the privileged roles. This can not be verified in this audit as this is out of the scope.
The system claims to use an “openZeppelin TimeLock Controller with 48h retention, used to trigger admin actions on SmartFarmooor”. This can not be verified in this audit as this is out of the scope.
“Dynamic allocation is at the heart of SmartFarmooor. An off-chain bot calculates the optimal allocation. Based on the result and quant review the Manager multisig applies the allocation to SmartFarmooor by calling setModuleAllocation().” This functionality depends on off-chain logic and is therefore out of the scope of this audit.
The system deposits users’ funds into other protocols. These protocols are out of the audit scope.
Contracts are upgradeable and are subject to future modification.
The rewards are swapped through the DEX module without setting slippage.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-130 | Requirements Violation | fixed | High | |
| F-2023-1304 | Redundant Inheritance | fixed | Medium | |
| F-2023-130 | Best Practice Violation - Uninitialized Implementation | fixed | Medium | |
| F-2023-1302 | Data Consistency | fixed | Medium | |
| F-2023-1301 | Non-Finalized Code - Requirements Violation | fixed | Medium | |
| F-2023-131 | Missing Events | fixed | Low | |
| F-2023-1316 | Missing Empty String Check | fixed | Low | |
| F-2023-1315 | Functions that can be declared external | unfixed | Low | |
| F-2023-131 | Unused Code | fixed | Low | |
| F-2023-1313 | Misleading Error Message | fixed | Low |
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/HedgeFarm/smart-farmooor-contracts→ |
| Commit | da2e6465c12a5bcbcb524abb85850044bb86db88 |
| Whitepaper | Not provided |
| Requirements | Provided |
| Technical Requirements | Provided→ |
Scope Details
- Commit
- da2e6465c12a5bcbcb524abb85850044bb86db88
- Whitepaper
- Not provided
- Requirements
- Provided
- Technical Requirements
- Provided→