Audit name:
[SCA] Zilliqa / Delegated Staking / Mar2025
Date:
Apr 4, 2025
Table of Content
Introduction
We express our gratitude to the Zilliqa team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Zilliqa's Delegated Staking system enables ZIL holders to participate in network security and earn rewards by delegating their assets to validator nodes.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Zilliqa |
| Audited By | Olesia Bilenka; Ivan Bondar |
| Approved By | Ataberk Yavuzer |
| Website | https://www.zilliqa.com/→ |
| Changelog | 02/04/2025 - Preliminary Report |
| 04/04/2025 - Final Report | |
| Platform | Zilliqa |
| Language | Solidity |
| Tags | LiquidStaking; Upgradable; Fungible Token |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Zilliqa
- Audited By
- Olesia Bilenka; Ivan Bondar
- Approved By
- Ataberk Yavuzer
- Website
- https://www.zilliqa.com/→
- Changelog
- 02/04/2025 - Preliminary Report
- 04/04/2025 - Final Report
- Platform
- Zilliqa
- Language
- Solidity
- Tags
- LiquidStaking; Upgradable; Fungible Token
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Zilliqa/delegated_staking/→ |
| Commit | 160eadc |
| Retest | 71bb565 |
Review Scope
- Commit
- 160eadc
- Retest
- 71bb565
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are detailed.
Project overview is detailed
All roles in the system are described.
Use cases are described and detailed.
For each contract, all futures are described.
All interactions are described.
Technical description is detailed.
Run instructions are provided.
Technical specification is provided.
The NatSpec documentation is sufficient.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 30.09% (branch coverage).
Deployment and basic user interactions are covered with tests.
Interactions by several users are tested thoroughly.
Not all branches are covered by tests.
System Overview
The Delegated Staking system comprises several core smart contracts, each fulfilling specific roles to facilitate staking operations:
BaseDelegation.sol: This abstract contract serves as the foundation for staking functionalities. It defines common behaviors and structures that both liquid and non-liquid staking contracts inherit, ensuring consistency across different staking implementations.
LiquidDelegation.sol: Extending from
BaseDelegation, this contract implements liquid staking. Delegators receive a non-rebasing Liquid Staking Token (LST) proportional to their staked amount. The LST represents the staked ZIL and accumulates rewards over time. Delegators can transfer LSTs, providing liquidity, and redeem them to withdraw their stake along with accrued rewards.NonLiquidDelegation.sol: Also extending from
BaseDelegation, this contract facilitates non-liquid staking. Delegators stake their ZIL without receiving transferable tokens. Instead, they can manually claim their rewards periodically and withdraw their principal stake after a specified unbonding period.NonRebasingLST.sol: This contract manages the Liquid Staking Tokens issued in the liquid staking model. As a non-rebasing token, its supply remains constant, but its value appreciates over time, reflecting the accrued staking rewards.
WithdrawalQueue.sol: This library handles the queuing mechanism for stake withdrawals. It ensures that withdrawal requests are processed in an orderly manner, adhering to the protocol's unbonding periods.
Privileged roles
NonRebasingLST.sol:
Owner (
LiquidDelegationcontract):Can
minttokens to any address, reflecting deposits/stakes.Can
burntokens from any address, reflecting withdrawals/unstakes.
BaseDelegation.sol(shared privileges for both NonLiquidDelegation & LiquidDelegation):
Owner:
Can upgrade contracts (
_authorizeUpgrade).Can add validators to staking pools (
_addToPool).Can set commission rates (
setCommissionNumerator).Can set commission receiver addresses (
setCommissionReceiver).
LiquidDelegation.sol:
Owner:
Can deposit ZIL directly into validator pools (
depositFromPool).Can onboard validators into the pool (
joinPool).Can stake accrued rewards from the contract balance (
stakeRewards).Can collect outstanding commissions (
collectCommission).
NonLiquidDelegation.sol:
Owner:
Can deposit ZIL directly into validator pools (
depositFromPool).Can onboard validators into the pool (
joinPool).Can collect outstanding commissions (
collectCommission).
Potential Risks
System Reliance on External Contracts: The functioning of the system significantly relies on specific external contract (DEPOSIT_CONTRACT). Any flaws or vulnerabilities in that contract adversely affect the audited project, potentially leading to security breaches or loss of funds.
Dynamic Array Iteration Gas Limit Risks: The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.
Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.
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.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-9429 | Potential Overwrite of Validator Data in _depositAndAddToPool function in BaseDelegation | mitigated | Medium | |
| F-2025-9437 | Potential Denial of Service due to Iteration Over All Validators During Deposits Updates | fixed | Medium | |
| F-2025-9420 | Missing New Address Staking Data Check for replaceOldAddress function | fixed | Medium | |
| F-2025-9408 | Unauthorized Reinitialization Permits Arbitrary State Migration | fixed | Medium | |
| F-2025-9442 | Delegator Can Forcibly Transfer Funds Leading to Reward Inflation and Price Manipulation | mitigated | Low | |
| F-2025-9502 | Inefficient Handling of Zero-Amount Stakings in Reward Calculation | fixed | Low | |
| F-2025-9456 | Commission Rate Configuration Allows Excessively High Rates | fixed | Low | |
| F-2025-9581 | Centralized Control Address Setting | fixed | Observation | |
| F-2025-9513 | Missing Non-Zero Address Validations | fixed | Observation | |
| F-2025-9460 | Redundant State Change in Activation Flag Results in Unnecessary Gas Usage | fixed | 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/Zilliqa/delegated_staking/→ |
| Commit | 160eadc6470c856dd555433e3b367dc40b32abd0 |
| Retest | 71bb565beb4850b97c72f2396783a3981c67d99d |
| Whitepaper | N/A |
| Requirements | NatSpec |
| Technical Requirements | NatSpec |
Scope Details
- Commit
- 160eadc6470c856dd555433e3b367dc40b32abd0
- Retest
- 71bb565beb4850b97c72f2396783a3981c67d99d
- Whitepaper
- N/A
- Requirements
- NatSpec
- Technical Requirements
- NatSpec
Assets in Scope
BaseDelegation.solIDelegation.solLiquidDelegation.solNonLiquidDelegation.solNonRebasingLST.solWithdrawalQueue.solAppendix 3. Additional Valuables
Verification of System Invariants
During the audit of Zilliqa, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Foundry fuzzing suite was prepared for this task, and throughout the assessment, 5 invariants were tested over 100,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
Index Consistency: The queue’s indices remain consistent (i.e. first <= last). | Passed | 100K+ |
Queue Length Accuracy: The active queue length (last - first) exactly equals the total enqueues minus dequeues. | Passed | 100K+ |
Item Readiness Consistency: For every active item (from first to last - 1), its ready status is determined by comparing block.number with the stored blockNumber (i.e. if block.number >= item.blockNumber then the item is ready and not marked as not-ready, and vice versa). | Passed | 100K+ |
Dequeued Item Clearance: Items that have been dequeued (indices less than first) are cleared (i.e. both amount and blockNumber equal zero). | Passed | 100K+ |
Ready Function Consistency: The overall ready function (which returns the ready status of the first item) is consistent with the specific check on the item at the first index. | Passed | 100K+ |
Invariant
- Index Consistency: The queue’s indices remain consistent (i.e.
first <= last). Test Result
- Passed
Run Count
- 100K+
Invariant
- Queue Length Accuracy: The active queue length (
last - first) exactly equals the total enqueues minus dequeues. Test Result
- Passed
Run Count
- 100K+
Invariant
- Item Readiness Consistency: For every active item (from
firsttolast - 1), its ready status is determined by comparingblock.numberwith the storedblockNumber(i.e. ifblock.number >= item.blockNumberthen the item is ready and not marked as not-ready, and vice versa). Test Result
- Passed
Run Count
- 100K+
Invariant
- Dequeued Item Clearance: Items that have been dequeued (indices less than
first) are cleared (i.e. bothamountandblockNumberequal zero). Test Result
- Passed
Run Count
- 100K+
Invariant
- Ready Function Consistency: The overall ready function (which returns the ready status of the first item) is consistent with the specific check on the item at the
firstindex. Test Result
- Passed
Run Count
- 100K+
Additional Recommendations
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.