- Hacken
- Audits
- pools-finance
- [SCA] Pools Finance | Pools-Contracts | May2025
Introduction
We express our gratitude to the Pools Finance team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Pools Protocol is an Automated Market Maker (AMM) implementation that enables decentralized trading between token pairs through liquidity pools. It supports both classic constant product pools and stable pools with customizable amplification parameters for tokens that should trade near parity.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Pools Finance |
| Audited By | Ataberk Yavuzer, Turgay Arda Usman, Khrystyna Tkachuk |
| Approved By | Ataberk Yavuzer |
| Website | https://www.pools.finance/→ |
| Changelog | 17/06/2025 - Preliminary Report |
| 01/07/2025 - Final Report | |
| Platform | IOTA |
| Language | Move |
| Tags | AMM, Staking |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Pools Finance
- Audited By
- Ataberk Yavuzer, Turgay Arda Usman, Khrystyna Tkachuk
- Approved By
- Ataberk Yavuzer
- Website
- https://www.pools.finance/→
- Changelog
- 17/06/2025 - Preliminary Report
- 01/07/2025 - Final Report
- Platform
- IOTA
- Language
- Move
- Tags
- AMM, Staking
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Pools-Finance/pools-protocol→ |
| Initial Commit | 04de3da |
| Final Commit | 7d9c596 |
Review Scope
- Initial Commit
- 04de3da
- Final Commit
- 7d9c596
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.
NatSpecs are missing for the AMM part.
Staking NatSpecs are partially outdated.
Technical description is provided.
There is no explanation in the documentation regarding the staking module.
Code quality
The code mostly follows best practices and style guides:
See informational findings for more details.
The development environment is configured.
Test coverage
Deployment and basic user interactions are covered with tests.
Staking and unstaking cases are covered.
Staking admin operation cases are not covered.
Interactions by several users are not tested thoroughly.
Adding and removing liquidity cases are covered.
Classic and stable pool creation and trading cases are covered.
Some edge-case scenarios are not covered.
System Overview
Pools Protocol is an Automated Market Maker (AMM) implementation built on the Iota blockchain. The protocol enables decentralized trading between token pairs through liquidity pools. It supports both classic constant product pools (similar to Uniswap V2) and stable pools with customizable amplification parameters for tokens that should trade near parity.
Classic pools use the constant product formula (x*y=k) for determining prices and swap amounts. These pools are suitable for token pairs that can have significant price differences. Stable pools use a modified formula with an amplification parameter to allow for more efficient trading of tokens that should maintain similar values (like stablecoins). The amplification parameter (A) determines how close to a constant sum curve (x*y=k) the pool behaves.
The protocol implements both swap fees and protocol fees. Swap Fees are charged on each trade (0.3% for classic pools, 0.05% for stable pools). Protocol Fees a portion of swap fees collected by the protocol (25%)
Pools Protocol is an AMM and staking protocol with the following contracts:
AMM:
amm_swap: core pool implementation and liquidity management
amm_router: trading path logic and user interface interactions
amm_entries: public entry points for user interactions
amm_config: protocol configuration and pause functionality
amm_math: basic mathematical operations
amm_stable_utils: stable pool-specific math operations
amm_utils: swap calculations and math utilities
Staking:
stake: core staking implementation with the emergency mechanism
stake_entries: public entry points for user interactions
stake_config: protocol configuration
Privileged roles
The AMM admin account (
AdminCap) is responsible for managing core protocol parameters. This includes setting the global pause status for swap activities, updating the amplification parameter for stable pools, switching pool types between classic and stable modes, and claiming protocol fees accumulated through trading activity.The emergency admin account
emergency_admin_addressofstakemodule is responsible for activating global or pool-specific emergency states. When a global emergency is triggered, all pools become permanently locked. Alternatively, inner (local) emergencies affect only a specific pool. Once an emergency is activated, it is irreversible, rendering the affected pool invalid for future use. However, users can still unstake their tokens via theemergency_unstakefunction. The emergency admin also has the authority to assign a new emergency admin address.The treasury admin account
treasury_admin_addressofstakemodule is responsible for withdrawing accumulated rewards either after an emergency has been triggered, or once three months have passed since the end of a staking harvest period (enabling the withdrawal of any unclaimed or excess rewards). The treasury admin also has the authority to assign a new treasury admin address.
Potential Risks
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. The emergency admin can trigger the contract's emergency mode at any time, and the treasury admin is authorized to withdraw rewards immediately once it's activated
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.
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.
The global staking contract's emergency mode is irreversible: Once the global emergency is triggered, it locks all unharvested rewards across all existing pools. Even if some pools were not affected by the underlying issue or if the issue is temporary and can be resolved (e.g., if it relates to an external protocol dependency), there is no way to revert the emergency state or allow users to harvest their accumulated rewards from those unaffected pools even after the system returns to normal and the staking pools could otherwise operate as expected.
The absence of an early unstaking penalty allows users to withdraw their stake after duration_unstake_time_sec passed, utilize the tokens externally, and restake without restriction. This flexibility introduces potential risks, as users may temporarily unstake tokens to influence market dynamics or liquidity conditions—potentially manipulating the market in a way that impacts other participants. Such behavior may also create misleading signals that encourage other users to stake under false assumptions.
The protocol allows administrators to instantly change a pool's type between Classic (constant product AMM like Uniswap) and Stable (stable swap AMM like Curve) using the change_pool_type function. When a pool type is changed, immediately without user notice, users trading in the same block or immediately after may experience different pricing curves affecting trade outcomes.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1094 | Pool Creation Logic Flaw Allows Single-Asset Liquidity to Generate Dual-Asset Rewards | fixed | Critical | |
| F-2025-1096 | Arithmetic Overflow in Liquidity Pricing Causes Complete DOS | mitigated | Critical | |
| F-2025-1099 | Lack of Oracle Usage Claims the System Vulnerable Against Depeg Risks | accepted | High | |
| F-2025-1096 | Incorrect Stable Swap Invariant Recalculation Leads to Incorrect Pricing | accepted | High | |
| F-2025-1095 | Initial Liqudity Price Manipulation | accepted | Medium | |
| F-2025-1094 | Extreme Amplification Parameter Can Lead to Potential Overflow | accepted | Medium | |
| F-2025-1102 | Unsafe Numeric Cast in updateuserearnings Leads to Permanent Denial of Service and Locked Funds | fixed | Medium | |
| F-2025-1101 | Pool Griefing Possibility | fixed | Medium | |
| F-2025-1102 | Emergency State Allows Immediate Treasury Withdrawal Bypassing Time Restrictions | accepted | Low | |
| F-2025-1102 | Zero-Stake Period Leads to Reward Loss | fixed | Low |
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/Pools-Finance/pools-protocol→ |
| Initial Commit | 04de3da06dcf309f34b8fed1063bfe51545c1ec3 |
| Final Commit | 7d9c59693472a796fc6091dcffd0ca4a6bc1d83e |
| Whitepaper | n/a |
| Requirements | https://github.com/Pools-Finance/pools-protocol/tree/main/README.md→ |
| Technical Requirements | https://github.com/Pools-Finance/pools-protocol/tree/main/README.md→ |
Scope Details
- Initial Commit
- 04de3da06dcf309f34b8fed1063bfe51545c1ec3
- Final Commit
- 7d9c59693472a796fc6091dcffd0ca4a6bc1d83e
- Whitepaper
- n/a
- Technical Requirements
- https://github.com/Pools-Finance/pools-protocol/tree/main/README.md→
Assets in Scope
Appendix 3. Additional Valuables
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.