Introduction
We express our gratitude to the Neemo Finance team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Neemo Finance provides a multi-asset liquid staking and restaking token on Soneium.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Neemo Finance |
| Audited By | Nataliia Balashova |
| Approved By | Grzegorz Trawinski, Ataberk Yavuzer |
| Website | https://neemo.finance/→ |
| Changelog | 05/02/2025 - Preliminary Report |
| 12/02/2025 - Final Report | |
| Platform | Ethereum and Soneium |
| Language | Solidity |
| Tags | Liquid Staking |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Neemo Finance
- Audited By
- Nataliia Balashova
- Approved By
- Grzegorz Trawinski, Ataberk Yavuzer
- Website
- https://neemo.finance/→
- Changelog
- 05/02/2025 - Preliminary Report
- 12/02/2025 - Final Report
- Platform
- Ethereum and Soneium
- Language
- Solidity
- Tags
- Liquid Staking
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/neemo-finance/neemo-staked-astar→ |
| Commit | f6a2c88806daee4d75cb188a699c8d489e5d3b8f |
| Remediation Commit | f2356864d176f95121e1f497b3dbf6a11f7eefd5 |
Review Scope
- Commit
- f6a2c88806daee4d75cb188a699c8d489e5d3b8f
- Remediation Commit
- f2356864d176f95121e1f497b3dbf6a11f7eefd5
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 partially missed.
Code quality
The development environment is configured.
Template code patterns were found.
Test coverage
Code coverage of the project is 94.74% (branch coverage), with 100.00% function coverage.
Deployment and basic user interactions are covered with tests.
Negative cases are covered .
Interactions by several users are not tested thoroughly.
System Overview
The NeemoLiquifier contract is responsible for managing liquidity pools and enabling token swaps between two types of tokens: nsASTR (lstToken) and ASTR (underlyingToken). This contract provides functionalities for users to deposit, withdraw, and swap between these tokens. It also integrates with external systems such as the DappStakingManager and PauseController to manage liquidity, paused states, and permissions.
Privileged roles
NEEMO_DEV_ROLE:
Manage configuration, including treasury and fees.
Add/remove users from the whitelist and fee-exempt list.
Set swap fees.
TIMELOCK_ROLE:
Authorize contract upgrades.
Manage protocol withdrawals in emergency situations.
PAUSER_ROLE:
Pause and unpause actions like liquidity additions, withdrawals, and token swaps.
Potential Risks
Withdrawal functionality are disabled when paused, preventing users from accessing funds.
Fees on swaps can be adjusted, potentially reducing users' returns.
Users may be unable to withdraw liquidity if the pool lacks sufficient liquidity.
Functions like adding liquidity or swapping tokens can be paused, restricting user actions.
TIMELOCK_ROLE role can withdraw all the funds from the contract.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8648 | Missing nonReentrant Modifier | fixed | Low | |
| F-2025-8649 | Event Emission Before State Change | 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/hknio/neemo-finance___neemo-staked-astar/commits/main/→ |
| Commit | f6a2c88806daee4d75cb188a699c8d489e5d3b8f |
| Remediation Commit | f2356864d176f95121e1f497b3dbf6a11f7eefd5 |
| Whitepaper | https://hackenio.cc/hacken-methodologies→ |
| Requirements | - |
| Technical Requirements | - |
Scope Details
- Commit
- f6a2c88806daee4d75cb188a699c8d489e5d3b8f
- Remediation Commit
- f2356864d176f95121e1f497b3dbf6a11f7eefd5
- Requirements
- -
- Technical Requirements
- -
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Neemo Finance, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry 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 Echidna fuzzing suite was prepared for this task, and throughout the assessment, 4 invariants were tested over 80,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
Add liquidity must work for every amount of astr token within a specified range, with checks for edge cases | Passed | 20k+ |
Withdraw liquidity should work for any valid amount of astr token, with checks for edge cases. | Passed | 20k+ |
Withdraw liquidity should work for any valid amount of lstToken, with checks for edge cases. | Passed | 20k+ |
Add liquidity must work for every amount of lstToken within a specified range | Passed | 20k+ |
Invariant
- Add liquidity must work for every amount of
astrtoken within a specified range, with checks for edge cases Test Result
- Passed
Run Count
- 20k+
Invariant
- Withdraw liquidity should work for any valid amount of
astrtoken, with checks for edge cases. Test Result
- Passed
Run Count
- 20k+
Invariant
- Withdraw liquidity should work for any valid amount of
lstToken, with checks for edge cases. Test Result
- Passed
Run Count
- 20k+
Invariant
- Add liquidity must work for every amount of
lstTokenwithin a specified range Test Result
- Passed
Run Count
- 20k+
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.