Audit name:
[SCA] Soil | ERC20 | Aug2023
Date:
Aug 4, 2023
Table of Content
Introduction
We express our gratitude to the Soil.co team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Soilfarm is a DeFi system aiming to provide users the ability to lend money to selected traditional funds, then yield SOIL tokens and USDC.
| title | content |
|---|---|
| Platform | Polygon |
| Language | Solidity |
| Tags | Fungible Token, Vesting, Staking, Yield Farming, Centralization, Signatures |
| Timeline | 01/06/2023 - 03/08/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://gitlab.nextrope.com/client/soil/soil-blockchain/-/tree/develop/→ |
| Commit | d71b55edbf34fb3e1e94f3a991aa5b8440cbc299 |
Review Scope
- Commit
- d71b55edbf34fb3e1e94f3a991aa5b8440cbc299
Audit Summary
10/10
97.71%
10/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 Soil.co |
| Audited By | Hacken |
| Website | https://soil.co/→ |
| Changelog | 02/06/2023 – Initial Review |
| 03/07/2023 – Second Review | |
| 03/08/2023 – Third Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Soil.co
- Audited By
- Hacken
- Website
- https://soil.co/→
- Changelog
- 02/06/2023 – Initial Review
- 03/07/2023 – Second Review
- 03/08/2023 – Third Review
System Overview
Soilfarm is a DeFi system aiming to provide users the ability to lend money to selected traditional funds, then yield SOIL tokens and USDC. Apart from that users will be able to buy SOIL tokens and stake them to receive more. To be able to join a pool or stake, users must complete KYC approval from the backend app. Then, for every action backend signature must be obtained. Smart contracts are not responsible for calculating the rewards.
The files in the scope:
SoilToken.sol — ERC-20 token that features burn and snapshot functionalities. All initial supplies are minted to predefined addresses during the construction phase for initial holders. It does not permit any additional minting.
Staking.sol — the Staking contract is a smart contract designed for staking and unstaking SOIL tokens, as well as claiming rewards and performing administrative functions. The contract allows users to stake their SOIL tokens, earn rewards, and withdraw their staked tokens along with the rewards. For every non-administrative function, the user has to provide a signature as a parameter in the function. The signature is generated in the backend, and smart contract checks if the provided signature is signed by the backend signer.
Vesting.sol — token holder contract that releases tokens based on parameters provided by the admin that created it (the address for which vesting is created, amount of locked tokens, unix timestamp from which tokens are releasing, time between release intervals, amount of tokens released per interval, boolean indicating whether withdrawing on demand by admin is enabled).
PoolsContract.sol — the pools contract is designed to allow users to gain rewards in USDC tokens and potentially in SOIL tokens by depositing to the pool. Pools are updatetable for the admin role. In order to withdraw from the pool users must wait a specified amount of time by the admin, unless early withdrawals are enabled. Just like in staking contracts, users have to provide signatures generated by the backend server as the parameter in the function call.
ProtocolSettings.sol — provides an access control system to the protocol.
VerifySignatureSystem.sol — provides signature verification to the protocol.
Privileged roles
DEFAULT_ADMIN_ROLE: super admin that can grant and revoke roles. This role can call withdrawFunds function and withdraw all deposited funds by users in the Pools Contract.
ADMIN_ROLE: this role is able to perform any action with an onlyAdmin modifier (creating pools, updating pools, withdraw collected fees from pools, update backend signer, disable and enable staking, unlock vested tokens in vesting on demand, send rewards to pool and staking contract).
TokenSpender: address that can create vaults in vesting and from which vested tokens come from.
Backend Signer: the address which the signatures provided by the user should come from.
Rewards Holder Wallet: address that holds the rewards for Pools and Staking users.
Soil Token Owner: The only role that can update a list of snapshooters.
Snapshooter: Has the permission to make a snapshot on soil token.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional requirements have some gaps.
Project overview is provided with roles and use cases.
Tokenomics is provided.
Dev env instructions are provided.
Technical specification is provided.
NatSpec is sufficient.
Code quality
The total Code quality score is 10 out of 10.
The development environment is configured.
Solidity Style Guide violations.
Project contains redundant functionality.
Test coverage
Code coverage of the project is 97.71% (branch coverage), with a mutation score of 53.31%.
Deployment and basic user interactions are covered with tests.
Negative cases coverage is partially missing.
Interactions with several users are tested thoroughly.
Low test mutation score indicates the code logic is not validated well by tests, and that the tests would not catch code changes.
Security score
Upon auditing, the code was found to contain 2 critical, 10 high, 8 medium, and 4 low severity issues. Out of these, 18 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.9. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
The contract design provides administrators with a significant degree of control over contract operation. If the keys of these admin accounts are compromised, the operation of the contract, including user funds and important parameters, could be affected.
The project's contract design shows a high degree of centralization. This centralization means that control over key operations and parameters is vested in a few accounts or roles. The risks associated with such centralization include potential misuse of power, single points of failure.
Part of the project's functionality, particularly the creation of signatures and rewards calculation, is handled off-chain and was not part of the audit. As a result, the security of these off-chain components cannot be verified.
The contract architecture currently lacks a reentrancy guard for operations that interact with tokens. While this might not pose a direct threat with the current tokens supported, it could potentially be a security concern if the contract is updated to support other token standards, such as ERC777.
The security of the funds in the system depends on the out-of-scope legal process.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-151 | Funds Lock, Data Consistency | fixed | Critical | |
| F-2023-1509 | Signed Message Replay Attack; Irrevocable Signed Message | fixed | Critical | |
| F-2023-152 | Data Consistency | fixed | High | |
| F-2023-151 | Coarse-Grained Access Control | fixed | High | |
| F-2023-151 | Coarse-Grained Access Control | mitigated | High | |
| F-2023-151 | Data Consistency, Fund Lock, Highly Permissive Role Access | fixed | High | |
| F-2023-151 | Hidden Fees | fixed | High | |
| F-2023-151 | Funds Lock, Highly Permissive Role Access | fixed | High | |
| F-2023-151 | Data Consistency, Highly Permissive Role Access | fixed | High | |
| F-2023-151 | Hidden Fees | mitigated | High |
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://gitlab.nextrope.com/client/soil/soil-blockchain/-/tree/develop/→ |
| Commit | d71b55edbf34fb3e1e94f3a991aa5b8440cbc299 |
| Whitepaper | Provided→ |
| Requirements | Provided |
| Technical Requirements | Provided |
Scope Details
- Commit
- d71b55edbf34fb3e1e94f3a991aa5b8440cbc299
- Whitepaper
- Provided→
- Requirements
- Provided
- Technical Requirements
- Provided