Introduction
We express our gratitude to the SingularityDAO team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
SDAO is a staking platform that allows users to earn rewards based on the staked ERC20 token deposit amount and the lock duration.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity |
| Tags | Staking, ERC20 |
| Timeline | 15/04/2024 - 16/04/2024 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/Singularity-DAO/staking-reward-contracts→ |
| Commit | 827be52 |
Review Scope
- Commit
- 827be52
Audit Summary
10/10
96.72%
10/10
8/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 SingularityDAO |
| Audited By | Seher Saylik |
| Approved By | Ataberk Yavuzer, Kaan Caglan |
| Website | http://singularitydao.ai/→ |
| Changelog | 18/04/2024 - Preliminary Report |
| 06/05/2024 - Secondary Report | |
| 15/08/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for SingularityDAO
- Audited By
- Seher Saylik
- Approved By
- Ataberk Yavuzer, Kaan Caglan
- Website
- http://singularitydao.ai/→
- Changelog
- 18/04/2024 - Preliminary Report
- 06/05/2024 - Secondary Report
- 15/08/2024 - Final Report
System Overview
SDAO is a staking protocol with the following contracts:
SDAOLinearSimpleReward — a reward management contract that allows the addition of rewards with an emission period, calculates claimable rewards for the users, and facilitates the claiming process. Additionally, it tracks user shares and reserves pending rewards for users to be claimed later. The owner of the protocol adds the rewards to the system and determines the emission durations. Platform owner charges a fee at a rate determined by them for each reward withdrawal transaction.
In this system, the reward ratio is calculated based on the staked duration and the amount deposited. Specifically, the reward is directly proportional to the product of the deposited amount and the stake duration. This means that users who stake a larger amount for a longer period will earn a higher proportion.
The formula used for calculating the reward ratio is typically something like:
Reward = Deposited Amount × Stake Duration - Commission
SDAOLockedStaking — the main staking contract that facilitates the staking of tokens with specified locking periods. Users can deposit tokens and extend their locking periods to increase their score. Withdrawals are allowed after the tokens unlock or immediately with an early unlock fee deducted. Important points include a maximum locking period of 1000 days, an early unlock fee capped at 50% of the deposited amount when users want to withdraw before the unlock date.
Clonable — a contract that provides functionality for creating and managing clones. It allows the creation of clones with a specified owner, enables ownership transfer, and ensures that only the owner can execute certain functions.
Privileged roles
The owner of the SDAOLinearSimpleReward contract can initialize the contract, add rewards, extend the reward duration, recover unsupported tokens,
The owner of SDAOLockedStaking contract can initialoize the contract, enable/disable new deposits, set early unlock fee per day, set zapper contract, recover unsupported tokens, withdraw the collected fees.
The owner of Clonable contract can set owner after cloning, transfer ownership.
Executive Summary
Documentation quality
The total Documentation Quality score is 8 out of 10.
Functional requirements are partially provided.
Technical description is provided.
NatSpec is provided but, could be improved.
Code quality
The total Code Quality score is 10 out of 10.
The development environment is configured.
Test coverage
Code coverage of the project is 95.45%(branch coverage).
Deployment and basic user interactions are covered with tests.
Interactions by several users and some important scenarios are not tested thoroughly.
Security score
Upon auditing, the code was found to contain 1 critical, 0 high, 1 medium, and 1 low severity issues. All identified issues have been addressed by the SDAO team, resulting in a final 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.7. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
The platform owner has the authority to extend or shorten the reward emission time, directly impacting the rewards that have been earned but not yet claimed. In such instances, users will receive the same amount of reward over an extended period of time.
Coarse-grained Authorization Model Risks: The broad authorization model increases the risk of protocol control loss if any authorized address is compromised, potentially leading to unauthorized actions and significant financial loss.
Single Entity Upgrade Authority: The token ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.
The lack of a cap on the commission rate for rewards allows it to potentially reach 100%, posing a risk that users could receive no rewards after fees are deducted
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-1336 | Miscalculated deltaScore Allows Malicious Users Earning Rewards For Free | fixed | Critical | |
| F-2024-1335 | Unlock Date Is Not Reset When The Entire Deposit Is Withdrawn | fixed | Medium | |
| F-2024-1343 | Return Values Of transfer()/transferFrom() Not Checked | fixed | Low | |
| F-2024-1374 | Missing Event Emitting | fixed | Observation | |
| F-2024-1372 | Constructor and initialize() Can Be Marked As Payable | fixed | Observation | |
| F-2024-1350 | Functions Not Used Internally Can Be Marked As External | fixed | Observation | |
| F-2024-1349 | Redundant State Variable Getters in Solidity | mitigated | Observation | |
| F-2024-1348 | State Variables That Are Used Multiple Times In a Function Should Be Cached In Stack Variables | fixed | Observation | |
| F-2024-1346 | Custom Errors In Solidity For Gas Efficiency | fixed | Observation | |
| F-2024-1345 | Unnecessary Casting As Variable Is Already Of The Same Type | 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/Singularity-DAO/staking-reward-contracts→ |
| Commit | 827be52 |
| Whitepaper | https://github.com/hknio/staking-reward-contracts/blob/main/README.md→ |
| Requirements | https://github.com/hknio/staking-reward-contracts/blob/main/README.md→ |
| Technical Requirements | https://github.com/hknio/staking-reward-contracts/blob/main/README.md→ |
Scope Details
- Commit
- 827be52
- Technical Requirements
- https://github.com/hknio/staking-reward-contracts/blob/main/README.md→