Audit name:
[SCA] Moonveil | Airdrop + Node Reward | Jan2025
Date:
Jan 24, 2025
Table of Content
Introduction
We express our gratitude to the Moonveil team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
The MoonveilAirdrop and MoonveilMuseNodeReward contracts are designed to ensure secure, transparent, and efficient token distribution. They leverage signature-based mechanisms, role-based controls, and flexible reward structures to promote fairness and incentivize active participation within the ecosystem.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Moonveil |
| Audited By | Ataberk Yavuzer |
| Approved By | Grzegorz Trawinski |
| Website | https://moonveil.gg/→ |
| Changelog | 21/01/2025 - Preliminary Report |
| 24/01/2025 - Final Report | |
| Platform | Polygon |
| Language | Solidity |
| Tags | Airdrop; Claims; Incentives; Upgradeable |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Moonveil
- Audited By
- Ataberk Yavuzer
- Approved By
- Grzegorz Trawinski
- Website
- https://moonveil.gg/→
- Changelog
- 21/01/2025 - Preliminary Report
- 24/01/2025 - Final Report
- Platform
- Polygon
- Language
- Solidity
- Tags
- Airdrop; Claims; Incentives; Upgradeable
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/MoonveilEntertainment/moonveil-contracts→ |
| Commit | 7d1bde3 |
| Final Commit | 788a706 |
Review Scope
- Commit
- 7d1bde3
- Final Commit
- 788a706
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are partially missed.
Technical description is present.
Whitepaper documentation is missed.
Code quality
Several template code patterns were found.
The development environment is configured.
Test coverage
Code coverage of the project is 74.84% (branch coverage), with a mutation score of 97.22%.
Deployment and basic user interactions are covered with tests.
Interactions by several users are not tested thoroughly.
System Overview
MoonveilAirdrop
The MoonveilAirdrop contract manages the distribution of MORE tokens through a robust signature-based claiming mechanism. This ensures that only authorized claims are processed while allowing claimers to designate alternate beneficiaries. Key features include:
Signature-Based Claim Verification: Claims are authorized via cryptographic signatures from an assigned signer role, ensuring that only pre-approved claims are valid.
One-Time Claim Restriction: Each beneficiary can claim tokens only once, preventing duplicate claims and ensuring fair distribution.
Flexible Beneficiary Settings: Claimers have the option to nominate different receiving addresses, allowing dynamic allocation of rewards.
Administrative Controls:
Pausing Functionality: The contract includes mechanisms to pause operations during emergencies, ensuring security under unforeseen conditions.
Token Withdrawal: Admins can withdraw unused tokens to optimize fund management and prevent locking up excess resources.
Transaction Security: The contract employs the
nonReentrantmodifier to safeguard against reentrancy attacks during critical operations.
MoonveilMuseNodeReward
The MuseNodeReward contract is designed to incentivize and reward node operators in the XYZ ecosystem, with a dual focus on airdrop rewards for license holders and operational rewards for active node runners. This contract ensures flexibility and security in reward distribution through innovative mechanisms. Key features include:
Airdrop Management
Configurable Airdrop Amounts: Admins can set specific airdrop amounts for eligible NFT license holders, aligning rewards with operational goals.
Eligibility Verification: The contract validates airdrop claims by checking NFT balances, ensuring that only eligible license holders can participate.
Time-Bound Distribution: Airdrop claims are restricted to a specified period, reinforcing timely participation.
One-Time Claim Enforcement: Each address can claim airdrop rewards only once, preventing misuse or over-allocation.
Operational Reward Management
Signature-Based Claiming: Rewards are authorized via signatures generated by the Reward Tracker, ensuring that only valid claims are processed.
Flexible Lock Periods: Node operators can choose from a range of lock durations, with corresponding multipliers to incentivize longer commitments.
Transaction Fee Mechanism: A small fee is deducted from each claim, supporting ecosystem sustainability.
Progressive Reward Withdrawal: Rewards are gradually released based on the lock period, promoting long-term engagement.
Security and Extensibility
Role-Based Access Control: Administrative functions are secured via granular roles, including signer and admin roles, ensuring robust permission management.
Pausability: Emergency pause functionality allows administrators to halt operations temporarily, protecting the ecosystem during unforeseen events.
Reentrancy Protection: All external calls are safeguarded with the
nonReentrantmodifier, mitigating risks of reentrancy attacks.Upgradeable Contract Pattern: The contract uses a proxy-based upgradeable pattern, enabling seamless future enhancements without disrupting the deployed infrastructure.
User Information and Tracking
Query Functions: Users can query their airdrop status, eligibility, and reward details, ensuring transparency.
Reward Tracking: The contract provides detailed tracking of claimed rewards, including lock periods and withdrawal timelines.
Real-Time Calculations: Users can view both their available and locked rewards in real-time, enhancing the user experience.
Potential Risks
The owner of the MoonveilAirdrop contract can withdraw all tokens from the contract while the airdrop is active. As a result, some users may be unable to claim their rewards, even if they were allocated through airdrop signatures.
The owner of the MoonveilMuseNodeReward contract can also withdraw all tokens from the contract while the airdrop is ongoing, which may prevent some users from claiming their rewards, despite being issued for airdrop signatures.
The owner of the MoonveilMuseNodeReward contract has the ability to change airdrop configurations while the airdrop is active.
The owner of the MoonveilMuseNodeReward contract can modify the transaction fee during the airdrop.
The signer of the MoonveilMuseNodeReward contract has complete authority over claim amounts. If this actor behaves maliciously, they could deplete node rewards.
The protocol relies heavily on a single role—the owner. If access to this address is lost, or if there is a leakage of its key, it could jeopardize the availability of the protocol.
Both contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security
Findings
receive()/fallback() MethodssafeTransfer() Method Instead of Standard Token TransfersCode ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8383 | One-Time Claim Restriction Applies to Claimer Address Instead of Beneficiary Address | fixed | Medium | |
| F-2025-8380 | Withdrawal of Rewards Can Potentially Block User Claims | accepted | Low | |
| F-2025-8379 | Missing Upper Bound on Tx Fees | accepted | Low | |
| F-2025-8377 | Owner Can Extend Airdrop Timeline Indefinitely | accepted | Low | |
| F-2025-8382 | Missing Role Segmentation for Pause Features | accepted | Observation | |
| F-2025-8378 | Unnecessary receive()/fallback() Methods | fixed | Observation | |
| F-2025-8375 | Use safeTransfer() Method Instead of Standard Token Transfers | accepted | Observation | |
| F-2025-8372 | Non-Disabled Implementation Contract | fixed | Observation | |
| F-2025-8371 | Using storage instead of memory | mitigated | Observation | |
| F-2025-8370 | Revert String Size Optimization | accepted | Observation |
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/MoonveilEntertainment/moonveil-contracts→ |
| Commit | 7d1bde3cd13ae45b6d88058725031604e6207003 |
| Whitepaper | N/A |
| Requirements | README.md |
| Technical Requirements | README.md |
Scope Details
- Commit
- 7d1bde3cd13ae45b6d88058725031604e6207003
- Whitepaper
- N/A
- Requirements
- README.md
- Technical Requirements
- README.md
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Moonveil contracts, 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 100K+ runs. This thorough testing ensured that the system worked correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Claims successfully work for very small and very high amounts | Passed | 100K+ |
| Claims always work even if the owner changes txFee with random amounts | Passed | 100K+ |
| Claims always work even if the time factor between other claims change | Passed | 100K+ |
| Reward withdrawals always work with randomized leftover amounts | Passed | 100K+ |
| Randomized reward amounts and time factors at the same time to identify edge cases. | Passed | 100K+ |
Invariant
- Claims successfully work for very small and very high amounts
Test Result
- Passed
Run Count
- 100K+
Invariant
- Claims always work even if the owner changes txFee with random amounts
Test Result
- Passed
Run Count
- 100K+
Invariant
- Claims always work even if the time factor between other claims change
Test Result
- Passed
Run Count
- 100K+
Invariant
- Reward withdrawals always work with randomized leftover amounts
Test Result
- Passed
Run Count
- 100K+
Invariant
- Randomized reward amounts and time factors at the same time to identify edge cases.
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.