Q2 2026 Security & Compliance Report67 incidents, $764M in losses, 88% from operational failures.
Get the report →

Audit name:

[SCA] Amasa | DEX | Sep2024

Date:

Sep 19, 2024

Table of Content

→Introduction
→Audit Summary
→System Overview
→Risks
→Findings
→Appendix 1. Severity Definitions
→Appendix 2. Scope
→Disclaimer

Want a comprehensive audit report like this?

Introduction

We express our gratitude to the Amasa team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.

Amasa is an easy-to-use DeFi platform that enables users to allocate crypto investments with fewer clicks.

Document

NameSmart Contract Code Review and Security Analysis Report for Amasa
Audited ByIvan Bondar
Approved ByAtaberk Yavuzer
Websitehttps://www.amasa.io/→
Changelog04/09/2024 - Preliminary Report
06/09/2024 - Final Report
PlatformArbitrum
LanguageSolidity
TagsDEX
Methodologyhttps://hackenio.cc/sc_methodology→
  • Document

    Name
    Smart Contract Code Review and Security Analysis Report for Amasa
    Audited By
    Ivan Bondar
    Approved By
    Ataberk Yavuzer
    Changelog
    04/09/2024 - Preliminary Report
    06/09/2024 - Final Report
    Platform
    Arbitrum
    Language
    Solidity
    Tags
    DEX

Audit Summary

12Total Findings
8Resolved
0Accepted
4Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are detailed.

    • Project overview is detailed.

    • All roles in the system are described.

    • Use cases are described and detailed.

    • For each contract, all futures are described.

    • All interactions are described.

  • Technical description is limited.

    • Run instructions are provided.

    • Technical specification is provided.

    • The NatSpec documentation is sufficient.

Code quality

  • The development environment is configured.

  • The code is well-structured with clear function separation.

  • Several functions contain unbounded loops that could lead to high gas costs or out-of-gas errors if input arrays are too large.

Test coverage

Code coverage of the project is 96.08% (branch coverage).

  • Deployment and basic user interactions are covered with tests.

  • Negative cases coverage is present.

  • Interactions by several users are tested.

System Overview

Amasa is an easy-to-use DeFi platform that enables users to allocate crypto investments with fewer clicks.

Amasa is an innovative DeFi platform that simplifies the process of investing in multiple cryptocurrencies by minimizing the number of steps required. It integrates seamlessly with the 1inch Aggregation Router V6 to facilitate efficient token swaps, allowing users to allocate their crypto investments across a range of supported ERC20 tokens. Amasa provides a user-friendly interface for setting allocation preferences, executing deposits, and managing investments directly from their wallets without requiring multiple transactions.

The platform supports two types of tokens:

  • Deposit Tokens: These are the tokens that users deposit into the platform, which are then used as input for swaps.

  • Investment Tokens: These tokens are the output from swaps and are directly transferred to the user's wallet as the underlying assets.

The platform's architecture includes mechanisms for setting up allocation preferences, supporting multiple investment tokens, managing fees, and performing bulk deposits on behalf of multiple users. All fees collected are directed to a community-controlled treasury, supporting the platform's sustainability.

The files in the scope:

  • Amasa.sol: The main contract that handles all user interactions on the blockchain. It manages deposits, allocation preferences, and swaps through the 1inch Aggregation Router V6. This contract defines the entire investment flow, including single and bulk deposits, fee management, and token approvals.

  • IAmasa.sol: The interface for the Amasa contract, defining all functions, events, and errors utilized in the main contract. It provides a blueprint for interacting with the Amasa smart contract system, ensuring a standardized approach for extensions and integrations.

Privileged roles

  • admin: Can add or remove other admins, set deposit and auto-deposit fees, manage the list of supported tokens (both deposit and investment tokens), set the paymaster, and assign the treasurer. Admins also have the authority to approve tokens for use with the 1inch Aggregation Router V6.

  • treasurer: Receives all deposit and swap fees collected by the platform. The treasurer can only be set or changed by an admin.

  • paymaster: This role is designated to process bulk deposits using the depositMany function. Only the paymaster can call this function.

Risks

System Reliance on External Contracts: The functioning of the system significantly relies on specific external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.

Interactions with External DeFi Protocols: Dependence on external DeFi protocols inherits their risks and vulnerabilities. This might lead to direct financial losses if these protocols are exploited, indirectly affecting the audited project.

Coarse-grained Authorization Model Risks: The broad authorization model increases the risk of protocol control loss if any authorized address is compromised, potentially leading to unauthorized actions and significant financial loss.

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.

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.

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.

Broad Authority of Paymaster Role: The paymaster role has broad authority over performing swaps on behalf of multiple users via the 1inch Aggregation Router V6. This role can transfer any tokens approved for the Amasa contract and define the swap parameters (swapData). If the paymaster is compromised or acts maliciously, it could exploit this authority to conduct unauthorized swaps, transfer user tokens in unintended ways, or cause financial loss.

Off-Chain Dependencies and Risks: The system rely on off-chain components or services for critical functions (such as the generation or management of swapData by the paymaster). Any flaws, bugs, or vulnerabilities in these off-chain processes, or the servers and services managing them, can directly affect the security and integrity of the protocol, leading to potential financial loss, incorrect swaps, or other unexpected behaviors.

Dynamic Array Iteration Gas Limit Risks: The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.

Findings

F-2024-5706Exposure of Private Keys and API Keys in Hardhat Configuration File
Status
fixed
Severity

High
F-2024-5769Redundant Swaps Between Identical Tokens
Status
mitigated
Severity

Low
F-2024-5763Lack of Reentrancy Protection in depositMany Function
Status
fixed
Severity

Low
F-2024-5759Lack of User Control Over swapData Created by Paymaster
Status
mitigated
Severity

Low
F-2024-5758Lack of Validation for swapData Function Selector and SwapDescription Flags
Status
fixed
Severity

Low
F-2024-5705Lack of Fine-Grained Access Control for Admin Role
Status
mitigated
Severity

Low
F-2024-5704Unbounded Loop in Allocation and Deposit Functions Leads to Potential Denial of Service
Status
mitigated
Severity

Low
F-2024-5703Best Practices Violation
Status
fixed
Severity

Observation
F-2024-5702Lack of Explicit Visibility Modifiers for State Variables
Status
fixed
Severity

Observation
F-2024-5701Use of Generic uint Type Instead of Explicitly Sized Integer Types (e.g. uint256)
Status
fixed
Severity

Observation
Code
―
Title
Status
Severity
F-2024-5706Exposure of Private Keys and API Keys in Hardhat Configuration File
fixed

High
F-2024-5769Redundant Swaps Between Identical Tokens
mitigated

Low
F-2024-5763Lack of Reentrancy Protection in depositMany Function
fixed

Low
F-2024-5759Lack of User Control Over swapData Created by Paymaster
mitigated

Low
F-2024-5758Lack of Validation for swapData Function Selector and SwapDescription Flags
fixed

Low
F-2024-5705Lack of Fine-Grained Access Control for Admin Role
mitigated

Low
F-2024-5704Unbounded Loop in Allocation and Deposit Functions Leads to Potential Denial of Service
mitigated

Low
F-2024-5703Best Practices Violation
fixed

Observation
F-2024-5702Lack of Explicit Visibility Modifiers for State Variables
fixed

Observation
F-2024-5701Use of Generic uint Type Instead of Explicitly Sized Integer Types (e.g. uint256)
fixed

Observation
1-10 of 12 findings

Identify vulnerabilities in your smart contracts.

Appendix 1. Severity Definitions

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.

Appendix 2. Scope

The scope of the project includes the following smart contracts from the provided repository:

Scope Details

Repositoryhttps://github.com/Spritely-Apps/amasa-smart-contracts/→
Commitb4d16b839be04e75048cfb7ef91faeb523230af9
WhitepaperN/A
RequirementsREADME.md
Technical RequirementsNatSpec

Contracts in Scope

contracts
Amasa.sol - contracts › Amasa.sol
interfaces
IAmasa - contracts › interfaces › IAmasa

Disclaimer