- Hacken
- Audits
- aqua-patina
- [SCA] Aqua Patina | Ap-Contracts | Sep2024
Audit name:
[SCA] Aqua Patina | Ap-Contracts | Sep2024
Date:
Oct 3, 2024
Table of Content
Introduction
We express our gratitude to the Aqua Patina team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Aqua Patina is a platform for Ethereum ReStaking via Eigenlayer.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Aqua Patina |
| Audited By | Niccolò Pozzolini, Viktor Raboshchuk |
| Approved By | Ataberk Yavuzer |
| Website | https://www.aquapatina.com→ |
| Changelog | 19/09/2024 - Preliminary Report |
| 02/10/2024 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Liquid Staking; Upgradable; |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Aqua Patina
- Audited By
- Niccolò Pozzolini, Viktor Raboshchuk
- Approved By
- Ataberk Yavuzer
- Website
- https://www.aquapatina.com→
- Changelog
- 19/09/2024 - Preliminary Report
- 02/10/2024 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Liquid Staking; Upgradable;
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/AvadoDServer/ap-contracts→ |
| Commit | 9eb7842 |
Review Scope
- Commit
- 9eb7842
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are complete.
Technical description is provided.
Whitepaper is not provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 100%.
Deployment and basic user interactions are covered with tests.
Negative cases are covered.
Interactions by several users are tested thoroughly.
System Overview
Aqua Patina (AP) is a platform developed by AVADO AG that streamlines the Ethereum staking and ReStaking process, integrating with Eigenlayer to enhance security provisioning across multiple blockchain applications. Through AP, users can stake ETH, with the protocol managing complex configurations and automatically engaging in ReStaking by leveraging Eigenlayer’s security marketplace.
The audit scope is composed by the following contract:
APETH.sol - Solidity smart contract provides functionality for staking and earning rewards through the Eigenlayer. It includes features such as minting APETH tokens, managing validator stakes, and handling fee collection, but withdrawals are not yet enabled in the contract.
Privileged roles
DEFAULT_ADMIN_ROLE - default admin role for all roles.
ETH_STAKER - Users with this role are authorized to stake ETH on behalf of the contract by interacting with the
stakefunction.EARLY_ACCESS - This role restricts access to the
mintfunction, allowing only authorized users to mint APETH tokens during the early-access phase.UPGRADER - This role allows the holder to upgrade the contract implementation.
SSV_NETWORK_ADMIN - This role can call functions on the SSV Network to manage validator-related operations, such as registering validators or setting a fee recipient address.
EIGEN_POD_ADMIN - This role interacts with the EigenPod contract, allowing actions like token recovery or managing the non-Beacon Chain ETH balance.
EIGEN_POD_MANAGER_ADMIN - Holders of this role can call functions on the EigenPodManager contract, including stake operations and creating pods.
DELEGATION_MANAGER_ADMIN - This role is responsible for delegating and undelegating stake to operators.
MISCELLANEOUS - Users with this role can transfer out ERC20 tokens, potentially for airdrops.
Potential Risks
Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.
Manual Interaction Risks with Eigenlayer Contracts: The interactions with Eigenlayer and its associated contracts (EigenPodManager, EigenPod, SSVNetwork, DelegationManager) are manually executed by the administrators rather than being automated within the APETH smart contract. This reliance on manual operations introduces potential for human error and necessitates a higher degree of trust in the APETH protocol administrators. Similarly, the airdrop redistribution function, as mentioned in the NatSpec of transferToken, also relies on manual execution by administrators.
Lack of a withdrawal functionality: The current implementation lacks a withdrawal functionality, compelling users to rely on decentralized exchanges (DEXes) to liquidate their APEth tokens. This reliance on DEXes may result in users incurring losses due to slippage and price volatility, potentially leading to a significant deviation from the fair market value of the APEth tokens being sold.
Unimplemented AP Points feature: The AP Points feature, which is intended to serve as a reward mechanism to recognize and incentivize the engagement and loyalty of Aqua Patina stakers, is mentioned in the documentation but is not implemented in the contract. This discrepancy could lead to confusion among users and stakeholders, and may result in unmet expectations regarding the rewards system.
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.
Absence of Upgrade Window Constraints: The contract suite allows for immediate upgrades without a mandatory review or waiting period, increasing the risk of rapid deployment of malicious or flawed code, potentially compromising the system's integrity and user assets.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-6169 | Wallet Receiving Funds Are Immutable | fixed | Low | |
| F-2024-6168 | Lack of Validation for feeAmount Parameter in Constructor | fixed | Observation | |
| F-2024-6167 | Use of Magic Number for Fee Calculation | fixed | Observation | |
| F-2024-6158 | Floating Pragma | fixed | Observation | |
| F-2024-6157 | Unused Custom Error | fixed | Observation | |
| F-2024-6155 | Unsafe ERC20 Transfers | 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, 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.
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/AvadoDServer/ap-contracts→ |
| Commit | 9eb7842ee9aecdf5e52be9d5a897cb4f2975e984 |
| Whitepaper | N/A |
| Requirements | https://docs.aquapatina.com/→ |
| Technical Requirements | https://docs.aquapatina.com/→ |
Scope Details
- Commit
- 9eb7842ee9aecdf5e52be9d5a897cb4f2975e984
- Whitepaper
- N/A
- Requirements
- https://docs.aquapatina.com/→
- Technical Requirements
- https://docs.aquapatina.com/→