Audit name:

[SCA] Aqua Patina / Ap-Contracts / Sep2024

Date:

Oct 3, 2024

Table of Content

Introduction

Audit Summary

System Overview

Potential Risks

Findings

Appendix 1. Definitions

Appendix 2. Scope

Disclaimer

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
    Changelog
    19/09/2024 - Preliminary Report
    02/10/2024 - Final Report
    Platform
    Ethereum
    Language
    Solidity
    Tags
    Liquid Staking; Upgradable;

Audit Summary

6Total Findings
6Resolved
0Accepted
0Mitigated

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 stake function.

  • EARLY_ACCESS - This role restricts access to the mint function, 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
1-6 of 6 findings

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

    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:

Contracts in Scope

src
APETH.sol - src/APETH.sol

Disclaimer