- Hacken
- Audits
- venom-foundation
- [SCA] VenomStake | LiquidStaking | Sep2023
Audit name:
[SCA] VenomStake | LiquidStaking | Sep2023
Date:
Sep 26, 2023
Table of Content
Introduction
We express our gratitude to the Venom Foundation team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Venom Staking is a smart contract system designed for the EVER liquid staking. By aggregating real network validators into one platform, it ensures an automatic balance of staked EVER across these validators.
| title | content |
|---|---|
| Platform | Venom |
| Language | TON-Solidity |
| Tags | Liquid Staking |
| Timeline | 25/08/2023 - 25/09/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/broxus/stEver-contracts/tree/venom-main→ |
| Commit | bb9497b55bddbcec5767e3c2d5caa6f4239f9697 |
Review Scope
- Commit
- bb9497b55bddbcec5767e3c2d5caa6f4239f9697
Audit Summary
10/10
80%
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 Venom Foundation |
| Audited By | Hacken |
| Website | https://venomstake.com→ |
| Changelog | 25/08/2023 – Initial Review |
| 18/09/2023 - Second Review | |
| 25/09/2023 - Third Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Venom Foundation
- Audited By
- Hacken
- Website
- https://venomstake.com→
- Changelog
- 25/08/2023 – Initial Review
- 18/09/2023 - Second Review
- 25/09/2023 - Third Review
System Overview
Venom Staking — a smart contract system designed for the EVER liquid staking. By aggregating real network validators into one platform, it ensures an automatic balance of staked EVER across these validators (achieved by Governance software system). This design eliminates the decision-making burden on users to select individual validators.
Furthermore, upon staking their EVER, users are issued a staked version of the SEVER token. This token representation can then be utilized across other DeFi platforms, allowing users to leverage the locked value of their stake.
In-scope contracts:
StEverVault — This central contract oversees the majority of operations. It serves as the primary interface for user interactions, such as deposits and withdrawals, as well as administrative and governance tasks. Additionally, it manages strategy, emergency protocols, and validator interactions, drawing on the capabilities of several abstract contracts it inherits from.
StEverStrategiesManager — An abstract contract that enriches the
_StEverVault_with functionalities for Cluster and DePool strategy management.StEverVaultBase — This abstract contract establishes the foundation for the
_StEverVault_. Extending the_StEverVaultStorage_, it incorporates a plethora of modifiers, utility functions, and external functions to ensure the vault operates seamlessly.StEverVaultEmergency — An abstract contract designed to offer emergency features for users, especially when the Governance system becomes inactive and fails to process user withdrawal requests.
StEverVaultStorage — An abstract contract where all storage variables are defined and maintained.
StEverVaultStrategiesController — An abstract contract equipped with functionalities for deposits, withdrawals from strategies, and rewards processing. It also facilitates the Governance rebalancing process.
StEverVaultValidators — An abstract contract providing helper view functions. These are utilized to pre-verify the accuracy of Governance deposits and withdrawal requests.
StEverAccount — A contract representing individual user accounts, recording their withdrawal requests.
StEverCluster — The contract represents a Validator's account. Once validated, a dedicated contract is created for them. This contract facilitates the deployment of new strategies via the DepoolStrategyFactory and manages the addition or removal of these strategies within the StEverVault.
StrategyDePool — A contract bridging to the DePool contract, streamlining the integration of the staking process with DePool functionalities.
DepoolStrategyFactory — A factory contract utilized by StEverCluster validators to deploy StrategyDePool contracts.
Privileged roles
StEverVault
User - Permitted to deposit and withdraw from the StEverVault. Additionally, the user can invoke an emergency state if the Governance system becomes inactive.
Owner - Has the authority to create new Cluster accounts for validators, approve strategies, and oversee the upgradability of contracts.
Governance - Tasked with processing withdrawal requests for users. It also manages the rebalancing of deposits among Validator strategies.
StEverAccount
Vault - All functions inside the StEverAccount are executed by the StEverVault.
StEverCluster
ClusterOwner - Empowered to deploy new strategies and add these deployed strategies to the StEverVault.
StEverOwner - Has the authority to remove a Cluster from the system, with an option to penalize the validator. Can also set the assurance limit value.
Vault - Validates responses to contract actions, ensuring they originate from the StEverVault.
StrategyDePool
Vault - Ensures that function calls made to StrategyDePool are initiated by StEverVault.
DePool - Ensures that function calls made to StrategyDePool are initiated by DePool.
DepoolStrategyFactory
Owner - Granted the capability to introduce new StrategyDePool code and upgrade existing strategies to the latest code.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional requirements are in place.
Technical description is robust.
Exceptional NatSpec comments are provided, including functional and technical descriptions.
Code quality
The total Code quality score is 10 out of 10.
Code is well-written and designed.
The development environment is configured.
Test coverage
Code coverage of the project is 80% (branch coverage).
The positive paths of major functionalities have been tested.
Most of the "set" functionalities have been subjected to testing.
Tests have been conducted on the view functions.
There is sometimes a lack of coverage for negative cases.
Security score
Upon auditing, the code was found to contain 2 critical, 4 high, 13 medium, and 17 low severity issues. Out of these, 33 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.3. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Contracts sourced from the "@broxus/contracts" and "broxus-ton-tokens-contracts" from npm.js were not included in the scope of this audit.
The withdrawal process from StEverVault has dependencies on specific user transaction settings, which the audited contract does not enforce. For a successful withdrawal: \-Users must transfer SEVER tokens to StEverVault. \-The notify setting must be set to true. \-At least 3 EVER should be included as _msg.value_ to cover gas costs. Not following these steps can result in a significant risk of losing SEVER tokens.
The deployStrategy() function in DepoolStrategyFactory lacks access control, allowing any user to deploy a StrategyDePool contract. While this does not directly compromise the audited code, the emitted NewStrategyDeployed event could cause unexpected backend behaviors if not properly filtered.
The system is highly centralized; each privilege role, if compromised, can lead to a loss of user funds. Multi-signature wallets for all privileged roles in the system should be used.
The startEmergencyProcess() function lets users initiate a withdrawal if the centralized system fails, once the timeAfterEmergencyCanBeActivated value is reached after withdrawal request unlock time. This timeframe can be up to 365 days, creating potential delays and inconvenience.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-139 | Transaction Replay Attack | fixed | Critical | |
| F-2023-1398 | Transaction Replay Attack | fixed | Critical | |
| F-2023-1403 | Data Consistency | fixed | High | |
| F-2023-140 | Lack of Validation | fixed | High | |
| F-2023-140 | Incorrect Gas Management | fixed | High | |
| F-2023-1400 | Incorrect Function Used | fixed | High | |
| F-2023-1416 | Missing Validation | fixed | Medium | |
| F-2023-141 | Invalid Validation | fixed | Medium | |
| F-2023-1414 | Incorrect Gas Management | fixed | Medium | |
| F-2023-141 | Division By Zero | fixed | Medium |
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/broxus/stEver-contracts/tree/venom-main→ |
| Commit | bb9497b55bddbcec5767e3c2d5caa6f4239f9697 |
| Whitepaper | Not provided |
| Requirements | Provided |
| Technical Requirements | Provided |
Scope Details
- Commit
- bb9497b55bddbcec5767e3c2d5caa6f4239f9697
- Whitepaper
- Not provided
- Requirements
- Provided
- Technical Requirements
- Provided