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 | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Amasa |
| Audited By | Ivan Bondar |
| Approved By | Ataberk Yavuzer |
| Website | https://www.amasa.io/→ |
| Changelog | 04/09/2024 - Preliminary Report |
| 06/09/2024 - Final Report | |
| Platform | Arbitrum |
| Language | Solidity |
| Tags | DEX |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Amasa
- Audited By
- Ivan Bondar
- Approved By
- Ataberk Yavuzer
- Website
- https://www.amasa.io/→
- Changelog
- 04/09/2024 - Preliminary Report
- 06/09/2024 - Final Report
- Platform
- Arbitrum
- Language
- Solidity
- Tags
- DEX
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Spritely-Apps/amasa-smart-contracts/→ |
| Commit | b4d16b8 |
Review Scope
- Commit
- b4d16b8
Audit Summary
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
depositManyfunction. 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
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-5706 | Exposure of Private Keys and API Keys in Hardhat Configuration File | fixed | High | |
| F-2024-5769 | Redundant Swaps Between Identical Tokens | mitigated | Low | |
| F-2024-5763 | Lack of Reentrancy Protection in depositMany Function | fixed | Low | |
| F-2024-5759 | Lack of User Control Over swapData Created by Paymaster | mitigated | Low | |
| F-2024-5758 | Lack of Validation for swapData Function Selector and SwapDescription Flags | fixed | Low | |
| F-2024-5705 | Lack of Fine-Grained Access Control for Admin Role | mitigated | Low | |
| F-2024-5704 | Unbounded Loop in Allocation and Deposit Functions Leads to Potential Denial of Service | mitigated | Low | |
| F-2024-5703 | Best Practices Violation | fixed | Observation | |
| F-2024-5702 | Lack of Explicit Visibility Modifiers for State Variables | fixed | Observation | |
| F-2024-5701 | Use of Generic uint Type Instead of Explicitly Sized Integer Types (e.g. uint256) | fixed | Observation |
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 | |
|---|---|
| Repository | https://github.com/Spritely-Apps/amasa-smart-contracts/→ |
| Commit | b4d16b839be04e75048cfb7ef91faeb523230af9 |
| Whitepaper | N/A |
| Requirements | README.md |
| Technical Requirements | NatSpec |
Scope Details
- Commit
- b4d16b839be04e75048cfb7ef91faeb523230af9
- Whitepaper
- N/A
- Requirements
- README.md
- Technical Requirements
- NatSpec