Introduction
We express our gratitude to the Destra Network team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The Destra Staking Pool is a smart contract that enables users to stake ERC-20 tokens (dsyncToken) for specified lock-in periods to earn rewards in ETH.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Destra Network |
| Audited By | Ataberk Yavuzer |
| Approved By | Grzegorz Trawinski |
| Website | https://www.destra.network/→ |
| Changelog | 15/01/2025 - Preliminary Report |
| 22/01/2025 - Secondary Report | |
| 24/01/2025 - Final Report | |
| Platform | EVM |
| Language | Solidity |
| Tags | Staking; ERC-20 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Destra Network
- Audited By
- Ataberk Yavuzer
- Approved By
- Grzegorz Trawinski
- Website
- https://www.destra.network/→
- Changelog
- 15/01/2025 - Preliminary Report
- 22/01/2025 - Secondary Report
- 24/01/2025 - Final Report
- Platform
- EVM
- Language
- Solidity
- Tags
- Staking; ERC-20
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/DestraNetwork/destra-staking-contracts→ |
| Commit | 8795c97 |
| Final Commit | a4ccf35 |
Review Scope
- Commit
- 8795c97
- Final Commit
- a4ccf35
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
NatSpec comments are sufficient.
Technical description is provided.
Code quality
The code is mostly Gas-efficient.
The development environment is configured.
Test coverage
Code coverage of the project is 80.00% (branch coverage).
Deployment and basic user interactions are covered with tests.
System Overview
Definition: The Destra Staking Pool is a smart contract that enables users to stake ERC-20 tokens (dsyncToken) for specified lock-in periods to earn rewards in ETH. The contract manages staking, reward distribution, and withdrawal while ensuring fairness and compliance with eligibility thresholds.
CONTRACTS
1\. DestraStakingPool
Type: Core Staking Contract
Functionality:
Facilitates staking of tokens for lock-in periods (30, 90, 180, or 360 days).
Distributes ETH rewards based on user stake weight and lock-in period.
Allows users to claim rewards after reward periods.
Supports unstaking with potential penalties for early withdrawals.
Enables owner configuration of reward distribution and eligibility thresholds.
ATTRIBUTES
Token Information:
Token Used:
dsyncToken(ERC-20 token).Interaction: Staking and transferring during rewards and penalties.
Staking Parameters:
Lock-in periods:
30 days
90 days
180 days
360 days
Stake Attributes:
Amount staked
Lock-in duration
Start time
Withdrawal status
Associated reward period index
Reward Distribution:
Rewards are distributed per reward period.
Reward Calculation Logic:
Weight is determined by the stake amount and lock-in period multiplier:
30 days: multiplier = 1
90 days: multiplier = 2
180 days: multiplier = 3
360 days: multiplier = 4
User reward =
(userWeight / totalWeight) * ethRewards.
Eligibility Requirements:
Stake must be active for at least
eligibilityThresholddays before the reward period ends.Stake duration must span through the end of the reward period.
PRIVILEGED ROLES
Owner:
Capabilities:
Set total weight for reward periods.
Deposit ETH rewards for distribution.
Adjust eligibility thresholds (between 5 and 20 days).
Restricted Access: All privileged functions are gated by
onlyOwner.
EVENTS
Staked: Emitted when tokens are staked.
Unstaked: Emitted when tokens are withdrawn, including penalty details.
RewardDeposited: Emitted when ETH rewards are deposited.
RewardClaimed: Emitted when a user claims their reward.
TotalWeightUpdated: Emitted when the owner updates the total weight for a reward period.
RewardPeriodTransition: Emitted when transitioning to a new reward period.
EligibilityThresholdUpdated: Emitted when the eligibility threshold is changed.
Potential Risks
Single Points of Failure and Centralization Risks: The project exhibits full or partial centralization, creating single points of failure and control. Such centralization introduces vulnerabilities in decision-making and operational processes, increasing the system's susceptibility to targeted attacks or manipulation.
Administrative Key Control Risks: The smart contract architecture depends on administrative keys for critical operations. This reliance poses a substantial security risk, as the compromise or misuse of these keys could result in unauthorized actions or significant financial losses.
Risks in the setTotalWeight Function of DestraStakingPool: The setTotalWeight function introduces critical vulnerabilities due to its dependency on off-chain calculations. Since the totalWeight is determined off-chain, users cannot independently verify its accuracy, exposing the system to potential errors or manipulation. Incorrect or failed off-chain calculations prevent updates to totalWeight, rendering users unable to claim rewards for the affected period. Additionally, an inaccurate totalWeight can lead to critical issues, such as underflows in the claimRewards function, which is fundamental to the protocol's functionality. Implementing on-chain calculations or decentralized validation mechanisms is strongly recommended to improve transparency and mitigate these risks.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8215 | Manually setting the totalWeight value can break the reward distribution | fixed | Medium | |
| F-2025-8214 | Irrecoverable total weight setting can break reward distribution | fixed | Medium | |
| F-2025-8437 | Calling the unstake() function before claiming rewards can lead to loss of rewards | accepted | Medium | |
| F-2025-8216 | Inconsistency between the code and comment | fixed | Low | |
| F-2025-8211 | Empty stakes can initiate staking periods earlier | fixed | Low | |
| F-2025-8213 | Custom errors in Solidity for gas efficiency | accepted | Observation | |
| F-2025-8212 | Revert string size optimization | fixed | Observation | |
| F-2025-8210 | Unneeded initializations of uint256 and bool variable to 0/false | fixed | Observation | |
| F-2025-8209 | Increments can be unchecked in for-loops | accepted | Observation |
Identify vulnerabilities in your smart contracts.
Appendix 1. Definitions
Severities
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. |
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.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/DestraNetwork/destra-staking-contracts→ |
| Commit | 8795c97d03a843f2e0743b469deb05dca63f085c |
| Whitepaper | N/A |
| Requirements | N/A |
| Technical Requirements | https://github.com/DestraNetwork/destra-staking-contracts/blob/main/README.md→ |
Scope Details
- Commit
- 8795c97d03a843f2e0743b469deb05dca63f085c
- Whitepaper
- N/A
- Requirements
- N/A
- Technical Requirements
- https://github.com/DestraNetwork/destra-staking-contracts/blob/main/README.md→
Appendix 3. Additional Valuables
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.