Introduction
We express our gratitude to the Imagine Replay Inc team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Replay powers a decentralized and transparent video streaming ecosystem, rewarding content owners and fans for the value they bring to video.
| title | content |
|---|---|
| Platform | Tetha |
| Language | Solidity |
| Tags | ERC20 |
| Timeline | 20/07/2023 - 14/08/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/imaginereplay/smart-contracts/tree/pre-audit→ |
| Commit | 0755d4bfb100169b3c1ab4353e9592d6e06a1530 |
Review Scope
- Commit
- 0755d4bfb100169b3c1ab4353e9592d6e06a1530
Audit Summary
10/10
80.56%
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 Imagine Replay Inc |
| Audited By | Hacken |
| Changelog | 25/07/2023 – Initial Review |
| 07/08/2023 - Second Review | |
| 11/08/2023 - Third Review | |
| 14/08/2023 - Fourth Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Imagine Replay Inc
- Audited By
- Hacken
- Changelog
- 25/07/2023 – Initial Review
- 07/08/2023 - Second Review
- 11/08/2023 - Third Review
- 14/08/2023 - Fourth Review
System Overview
ReplayToken is an ERC20 reward contract with the following contracts:
ReplayToken — simple ERC-20 token that mints initial supply to a passed
initDistrWallet_address and allows to mint new tokens to reward the Subchain validator stakers.
Privileged roles
PendingAdminis an Intermediary role that is used for the update of admin.Admin is an address that is allowed to mint new tokens, change the
pendingAdminand change the value of rewards that will be shared between stakers.Minter roles is an address that is allowed to mint new staker rewards.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Functional and technical requirements are provided.
Code quality
The total Code quality score is 10 out of 10.
The development environment and deployment instructions are sufficient.
Test coverage
Code coverage of the project is 80.56% (branch coverage).
The audit Lines of Code do not exceed 250, this does not affect the score.
Security score
Upon auditing, the code was found to contain 0 critical, 0 high, 1 medium, and 5 low severity issues. Out of these, 3 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 10. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
The out-of-scope ValidatorStakeManager contract and admin are responsible for the minting of tokens. The secureness of the supply depends on the secureness of key storage. If an admin or a minter goes malicious, they will be able to mint all the token supply at once and prevent other users from receiving rewards.
The total supply of the token is determined during the deployment. It cannot be verified until the contract is deployed.
There is no strict restriction on when the admin can change the _stakerRewardPerBlock variable. They might set a smaller reward per block by calling the updateStakerRewardPerBlock() function. As a result, the stakers might receive fewer or no rewards, contrary to what they initially expected. It is recommended to use a timelock mechanism for such critical functionality.
Since ReplayToken will be used as the Governance token, a malicious admin or minter will be able to manipulate the voting power.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-1037 | Missing Event for Critical Value Updation | fixed | Medium | |
| F-2023-1042 | Copy Of Well-Known Contract | unfixed | Low | |
| F-2023-1041 | Public Variable Read in the External Context | unfixed | Low | |
| F-2023-1040 | State Variables Can Be Declared Immutable or Constant | fixed | Low | |
| F-2023-1039 | Missing Zero Address Validation | fixed | Low | |
| F-2023-103 | Redundant Use of SafeMath | unfixed | Low | |
| I-2023-0289 | Optimization by Replacing the Previous State Values of the Roles with the Values that Are Stored in the Memory | unfixed | Observation | |
| I-2023-0288 | Code Duplication | unfixed | Observation | |
| I-2023-0287 | Events Are Missing Relevant Data | fixed | Observation | |
| I-2023-0286 | Outdated Solidity Version | unfixed | 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/imaginereplay/smart-contracts/tree/pre-audit→ |
| Commit | 0755d4bfb100169b3c1ab4353e9592d6e06a1530 |
| Whitepaper | Not provided |
| Requirements | Not provided |
| Technical Requirements | Provided |
Scope Details
- Commit
- 0755d4bfb100169b3c1ab4353e9592d6e06a1530
- Whitepaper
- Not provided
- Requirements
- Not provided
- Technical Requirements
- Provided