Audit name:
[SCA] XPower / ERC20 + ERC1155 + Staking / Dec2023
Date:
Jan 12, 2024
Table of Content
Introduction
We thank XPower for allowing us to conduct a Smart Contract Security Assessment. This document outlines our methodology, limitations, and results of the security assessment.
XPower aims to be a fairly distributed currency, leveraging CPU power to mine and distribute PoW coins.
| title | content |
|---|---|
| Platform | EVM |
| Language | Solidity |
| Tags | ERC20; ERC1155; Staking |
| Timeline | 19/12/2023 - 10/01/2024 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Last Review Scope | |
|---|---|
| Repository | https://github.com/blackhan-software/xpower-hh/→ |
| Commit | 272f69a |
Last Review Scope
- Commit
- 272f69a
Audit Summary
10/10
80.31%
9/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 XPower |
| Audited By | Ivan Bondar |
| Approved By | Ataberk Yavuzer |
| Website | https://www.xpowermine.com/→ |
| Changelog | 10/1/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for XPower
- Audited By
- Ivan Bondar
- Approved By
- Ataberk Yavuzer
- Website
- https://www.xpowermine.com/→
- Changelog
- 10/1/2024 - Final Report
System Overview
XPower introduces XPOW tokens, leveraging a hybrid of Proof-of-Work (PoW) and Proof-of-Stake (PoS) on the Avalanche C-Chain. These tokens are minted through a PoW process, ensuring fair distribution without pre-mining or pre-minting. Anyone can mint XPOW tokens by submitting a valid nonce number.
The project combines the equitable distribution aspect of PoW with the efficient transaction capabilities of PoS. XPOW tokens can be transformed into NFTs, which are stakable for earning APower (APOW) tokens, representing matured XPower. Burning APower tokens releases the contained XPower based on the current conversion rate. Additionally, a portion of each mint contributes to the project's treasury, supporting its sustainability.
XPower aims to enhance the Avalanche ecosystem by merging the strengths of PoW and PoS, promoting a balanced and energy-efficient economy.
The files in the scope:
XPower.sol - Manages XPOW tokens, mintable through proof-of-work without pre-mining. Tokens are minted by providing a valid nonce.
APower.sol - Handles APOW tokens, mintable exclusively by the contract owner (MoeTreasury) at a controlled rate.
XPowerNft.sol - Manages XPOW NFTs, mintable by depositing corresponding XPOW token amounts.
XPowerPpt.sol - Manages staked XPowerNft tokens, allowing only the contract owner (NftTreasury) to mint and burn these tokens.
MoeTreasury.sol - Treasury contract for minting APower tokens in exchange for staked XPowerNft tokens.
NftTreasury.sol - Treasury contract for staking and unstaking XPowerNft tokens.
FeeTracker.sol - Tracks fees using cumulative moving averages.
Migratable.sol - Facilitates token migration from old contracts up to a specified deadline.
NftMigratable.sol - Enables NFT migration from old contracts, including batch migration and manual sealing.
NftBase.sol - Abstract base class for NFTs, incorporating multiple ERC1155 functionalities and extensions.
NftRoyalty.sol - Manages NFT royalties, allowing changes in beneficiary with a default royalty fraction of 0.5%.
URIMalleable.sol - Allows changing NFT URIs, with permanence conditions based on time, and supports contract-level metadata URI.
Supervised.sol - Base contract for role management across the project.
Array.sol - Library for array operations, including sorting and duplicate checking.
Constants.sol - Stores constants used throughout the project's contracts.
Integrator.sol - Library for integrating over arrays of tuples and calculating weighted arithmetic means.
Nft.sol - Library for NFT-related operations, including ID composition and level denomination.
Polynomials.sol - Library for evaluating values using linear functions defined by polynomial coefficients.
Power.sol - Library for exponentiation operations, particularly raising numbers to specified powers.
Rpp.sol - Library for rug pull protection, ensuring valid parameter changes and invocation frequencies.
Privileged roles
XPower.sol:
owner: Can transfer ownership, renounce ownership. Co-mints extra XPower tokens for the treasury with each new minting.
MOE_SEAL_ROLE (from MoeMigratable): Grants the right to seal MOE immigration.
MOE_SEAL_ADMIN_ROLE (from MoeMigratable): Admin role for MOESEALROLE, can set or revoke MOESEALROLE.
APower.sol:
owner: Only the owner can mint new APower tokens. Can also transfer and renounce ownership.
SOV_SEAL_ROLE (from SovMigratable): Grants the right to seal SOV immigration.
SOV_SEAL_ADMIN_ROLE (from SovMigratable): Admin role for SOVSEALROLE, can set or revoke SOVSEALROLE.
XPowerNft.sol:
NFT_SEAL_ROLE: Grants the right to seal NFT immigration.
NFT_SEAL_ADMIN_ROLE: Admin role for NFTSEALROLE, can set or revoke NFTSEALROLE.
NFT_ROYAL_ROLE: Grants the right to set the NFT's default royalty beneficiary.
NFT_ROYAL_ADMIN_ROLE: Admin role for NFTROYALROLE, can set or revoke NFTROYALROLE.
URI_DATA_ROLE: Grants the right to change metadata URIs.
URI_DATA_ADMIN_ROLE: Admin role for URIDATAROLE, can set or revoke URIDATAROLE.
XPowerPpt.sol:
owner: Only the owner can mint and burn XPowerPpt tokens. Can also transfer and renounce ownership.
NFT_SEAL_ROLE: Grants the right to seal NFT immigration.
NFT_SEAL_ADMIN_ROLE: Admin role for NFTSEALROLE, can set or revoke NFTSEALROLE.
NFT_ROYAL_ROLE: Grants the right to set the NFT's default royalty beneficiary.
NFT_ROYAL_ADMIN_ROLE: Admin role for NFTROYALROLE, can set or revoke NFTROYALROLE.
URI_DATA_ROLE: Grants the right to change metadata URIs.
URI_DATA_ADMIN_ROLE: Admin role for URIDATAROLE, can set or revoke URIDATAROLE.
MoeTreasury.sol:
APR_ROLE: Grants the right to change APR parametrization.
APR_ADMIN_ROLE: Admin role for APRROLE, can set or revoke APRROLE.
APB_ROLE: Grants the right to change APB parametrization.
APB_ADMIN_ROLE: Admin role for APBROLE, can set or revoke APBROLE.
Executive Summary
Documentation quality
The total Documentation Quality score is 10 out of 10.
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 limited.
Run instructions are provided.
Technical specification is provided.
The NatSpec documentation is sufficient.
Code quality
The total Code Quality score is 9 out of 10.
The development environment is configured.
Solidity Style Guide violations.
Test coverage
Code coverage of the project is 80.31% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage are partially missed.
Interactions by several users are tested.
Not all branches are covered with tests.
Security score
Upon auditing, the code was found to contain 1 critical, 2 high, 0 medium, and 2 low severity issues, 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.1. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
Variation in APOW Token Supply Due to Claiming Frequency: It is important to note that the actual minting amounts of APOW tokens may significantly deviate from initial projections due to the frequency of user claims. Particularly in the early stages of the token's existence, if users claim their rewards more frequently than the assumed annual rate, this behavior could lead to a substantially higher rate of token supply growth. Such an increase in the minting rate, driven by frequent claiming, presents a risk of accelerating the token supply beyond expected limits, potentially affecting the token's value and the ecosystem's economic balance.
Migration Risks with New Version Releases: Users have the option to migrate their ERC20 and ERC1155 tokens to newer versions. However, migration is subject to deadlines and can be prematurely sealed by addresses with SEAL_ROLE, potentially impacting users' ability to migrate after the deadline.
Impact of Staking Different NFT Levels on Rewards: The system auto-adjusts target reward rates to balance income across NFT levels (UNIT, KILO, MEGA). Staking higher-level NFTs can significantly alter rewards for all levels, leading to substantial changes in claimable rewards, especially for lower-level NFTs.
Administrative Control Over APR and APB Parameters: The protocol incorporates roles like APRROLE and APBROLE, which enable the modification of APR and APB parameters. This structure is designed to allow flexible re-parametrization while preventing arbitrary changes. It ensures that participants have sufficient time to assess the reasonableness of target settings. Over time, the values tend to become more entrenched, making changes increasingly challenging. This mechanism balances flexibility with stability, but users should remain vigilant about potential adjustments.
Risk of Reward Reset on PPT Transfers: Transferring PPTs (staked NFTs) without claiming accumulated rewards can lead to potential reward losses. Users are advised to claim rewards before any transfer.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-0296 | Extended Validity of Block Hashes in XPower Contract Leads to Inflation Vulnerability | fixed | Critical | |
| F-2023-0322 | Reward Accumulation Issue in MoeTreasury Contract Affecting Restaking and Transfers of XPowerPpt NFTs | fixed | High | |
| F-2023-0321 | Inadequate Handling of NFT Transfers and Restaking in XPowerPpt.sol Impacts Reward Accumulation | fixed | High | |
| F-2024-0333 | Forced Migration in Token Contracts | fixed | Low | |
| F-2024-0330 | Potential Forced Unstaking in unstake() and unstakeBatch() Functions During Migration | fixed | Low | |
| F-2024-0332 | Lack of Events in Key Functions | fixed | Observation | |
| F-2024-0331 | Redundant Assert Statements in init() Function of XPower Contract | fixed | Observation | |
| F-2024-0329 | Variable Shadowing in Inherited Contracts Leads to Ambiguity in APower and SovMigratable | fixed | Observation | |
| F-2023-0328 | Inefficient Gas Usage in burnBatch() Function Due to Redundant Operations of the XPowerNft.sol contract | fixed | Observation | |
| F-2023-0327 | Optimization and Enhancement of claimBatch() Function in MoeTreasury | accepted | Observation |
Identify vulnerabilities in your smart contracts.
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/blackhan-software/xpower-hh→ |
| Commit | bd660e12ee394e736d1a65f4d2282ed16df21756 |
| Whitepaper | N/A |
| Requirements | https://www.xpowermine.com/about→ |
| Technical Requirements | https://www.xpowermine.com/about→ |
Scope Details
- Commit
- bd660e12ee394e736d1a65f4d2282ed16df21756
- Whitepaper
- N/A
- Requirements
- https://www.xpowermine.com/about→
- Technical Requirements
- https://www.xpowermine.com/about→