- Hacken
- Audits
- neemo-finance
- [SCA] Neemo | Neemo-Restaked-Ether | Dec2024
Audit name:
[SCA] Neemo | Neemo-Restaked-Ether | Dec2024
Date:
Jan 24, 2025
Table of Content
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 is a non-custodial staking protocol that strengthens the security of ETH Layer 2 networks by offering Liquid Restaked Tokens (LRT). These tokens are issued against assets like ETH, eEth, wEth, WeETh and/or tokens utilized in ETH Layer 2 chain's Proof of Stake (PoS) systems. Currently, the protocol plans to support Soneium and Asta L2 blockchains.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Neemo Finance |
| Audited By | Grzegorz Trawinski |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://neemo.finance/→ |
| Changelog | 07/01/2025 - Preliminary Report |
| Retest | 24/01/2025 - Final Report |
| Platform | Ethereum, Soneium |
| Language | Solidity |
| Tags | Staking, Liquidity Staking, Bridge, |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Neemo Finance
- Audited By
- Grzegorz Trawinski
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://neemo.finance/→
- Changelog
- 07/01/2025 - Preliminary Report
- Retest
- 24/01/2025 - Final Report
- Platform
- Ethereum, Soneium
- Language
- Solidity
- Tags
- Staking, Liquidity Staking, Bridge,
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/neemo-finance/neemo-restaked-ether→ |
| Commit | 125f90afe7a1950cc3ff2e63034ebbf383c2bb90 |
| Retest Commit | a9328a2959de58310cf9fe645dd7666172559f68 |
Review Scope
- Commit
- 125f90afe7a1950cc3ff2e63034ebbf383c2bb90
- Retest Commit
- a9328a2959de58310cf9fe645dd7666172559f68
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Robust documentation available on: https://docs.neemo.finance/ →.
Sufficient technical documentation available in README.md file.
Code quality
The code represents mature protocol implementation.
Test coverage
Code coverage of the items in the security assessment scope is around 90% (branch coverage).
System Overview
DepositRouter.sol - it is an interface to StakingManagerL1 contract easing depositing of various assets such as: ETH, WETH, eETH, stETH and wstETH.
StakingManagerL1.sol - it allows depositing weETH and bridge LST tokens to the L2. Additionally, privileged user can recalculate the exchange rate and send its value via message to the L2. Contract is upgradable.
StakingManagerL2.sol - it allows depositing ETH and WETH in exchange of receiving the nrETH tokens, based on the exchange ratio received from the L1. It allows also to perform rapid withdraw of the staked assets. It accepts messages send from L1 related to minting nrETH tokens and exchange rate update. Contract is upgradable.
Privileged roles
The owner of the StakingManagerL1 can set configuration state variables such as: treasury, multichain minting activation, rewards fee, mint fee, exchange rate deviation, multichain manager address. Also, privileged user can recalculate the exchange rate. Finally, it can withdraw rewards fees.
The owner of the StakingManagerL2 can set configuration state variables such as: treasury, exchange rate deviation, multichain manager address, rapid withdrawal fee, minimum staking threshold, rapid liquidity threshold.
Potential Risks
Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.
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.
Flexibility and Risk in Contract Upgrades: The project's 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.
The Scope Represents Incomplete Solution: The current state of the project is declared as phase 1. Several functionalities are not implemented right now, e.g. withdrawal on L1 or rewards collecting for users. Additionally, several state variables are now implemented, but nowhere used, such as: minStakingThreshold and rapidLiquidityThreshold.
Limited Withdrawal Possibility: ~Currently the protocol allows to withdraw wrapped native tokens on L2 side. However, the withdrawal is limited only to the sum of deposits done on L2 side.~ Upon receiving the updated codebase for remediation phase, this functionality was removed.
Redundant NFT Support: The protocol implements ERC721Received interface, however it does not implement any NFT related functionality. It declares a need of implementation in phase 2 for unstake functionality.
Exchange Ratio Update Delay: The protocol assumes a synchronisation of exchange ratio between L1 and L2 chains. However, there can be significant delay between the synchronisation. Thus, L2 can use obsolete, underestimated exchange rate until the synchronisation is triggered.
Exchange Ratio Update Bottleneck Possibility: The protocol assumes that synchronisation of exchange ratio between L1 and L2 chains can be only triggered by the protocol owner. Whenever any issue occurs off-chain and re-pricing is not triggered the L2 can use obsolete, underestimated exchange rate.
ETH and eETH Exchange Ratio: the protocol assumes that the exchange ratio between ETH and eETH is 1:1. Whenever, the price between these two tokens fluctuates, it can impact the exchange rate used between L1 and L2 chains.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8076 | Incorrect ratio application leads to decreasing LST tokens mints | fixed | Critical | |
| F-2025-8072 | First depositor gets overestimated number of LST tokens | fixed | High | |
| F-2025-8070 | L2 may continue deposits when L1 is automatically paused | fixed | Medium | |
| F-2025-8060 | The reprice function can revert with arithmethic underflow error | fixed | Medium | |
| F-2025-8045 | Deposited tokens can be locked due to destination address mismatch | mitigated | Medium | |
| F-2025-8453 | The delegate's referrer can be front-runned | fixed | Low | |
| F-2025-8071 | Possibly unreachable code within the StakingManagerL2's syncStateFromL1 function | fixed | Observation | |
| F-2025-8053 | The validateAmount modifier can be insufficient | fixed | 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/neemo-finance/neemo-restaked-ether→ |
| Commit | 125f90afe7a1950cc3ff2e63034ebbf383c2bb90 |
| Retest Commit | a9328a2959de58310cf9fe645dd7666172559f68 |
| Whitepaper | n/a |
| Requirements | https://docs.neemo.finance/→ |
| Technical Requirements | README.md |
Scope Details
- Commit
- 125f90afe7a1950cc3ff2e63034ebbf383c2bb90
- Retest Commit
- a9328a2959de58310cf9fe645dd7666172559f68
- Whitepaper
- n/a
- Requirements
- https://docs.neemo.finance/→
- Technical Requirements
- README.md
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Neemo Finance protocol 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 Echidna 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 |
|---|---|---|
| Deposit a reasonable amount of ETH via DepositRouter is accepted without unexpected transaction revert. | Passed | 100k |
| Deposit a reasonable amount of WETH via DepositRouter is accepted without unexpected transaction revert. | Passed | 100k |
| Deposit a reasonable amount of eETH via DepositRouter is accepted without unexpected transaction revert. | Passed | 100k |
| Deposit a reasonable amount of stETH via DepositRouter is accepted without unexpected transaction revert. | Passed | 100k |
| Deposit a reasonable amount of wstETH via DepositRouter is accepted without unexpected transaction revert. | Passed | 100k |
Invariant
- Deposit a reasonable amount of ETH via DepositRouter is accepted without unexpected transaction revert.
Test Result
- Passed
Run Count
- 100k
Invariant
- Deposit a reasonable amount of WETH via DepositRouter is accepted without unexpected transaction revert.
Test Result
- Passed
Run Count
- 100k
Invariant
- Deposit a reasonable amount of eETH via DepositRouter is accepted without unexpected transaction revert.
Test Result
- Passed
Run Count
- 100k
Invariant
- Deposit a reasonable amount of stETH via DepositRouter is accepted without unexpected transaction revert.
Test Result
- Passed
Run Count
- 100k
Invariant
- Deposit a reasonable amount of wstETH via DepositRouter is accepted without unexpected transaction revert.
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.