Audit name:
[SCA] Aegis / Aegis-Contracts / Nov2024
Date:
Dec 13, 2024
Table of Content
Introduction
We express our gratitude to the Aegis team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Aegis delivers a fully transparent yield-generating stablecoin - USDa, backed with USDC, USDT and DAI. The protocol aims to distribute rewards weekly for USDa holders.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Aegis |
| Audited By | Grzegorz Trawinski, Ataberk Yavuzer |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://aegis.im/→ |
| Changelog | 04/12/2024 - Preliminary Report |
| 13/12/2024 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | Stablecoin, ERC-20, Yield |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Aegis
- Audited By
- Grzegorz Trawinski, Ataberk Yavuzer
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://aegis.im/→
- Changelog
- 04/12/2024 - Preliminary Report
- 13/12/2024 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- Stablecoin, ERC-20, Yield
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/zer0h1ro/aegis-contracts→ |
| Commit | c691e43890da838dc1a64a2b2719756fd9c98b61 |
Review Scope
- Commit
- c691e43890da838dc1a64a2b2719756fd9c98b61
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Clear functional and technical requirements are provided within the
SOFTWARE ARCHITECTURE.pdffile.
Code quality
The code represents mature solution with clear architecture and distinguished components.
Test coverage
Multiple tests are present in the solution to cover majority of functionality within the protocol. However, code coverage of the project could not be calculated due to hardhat issue.
System Overview
The protocol is a yield-generating stablecoin - USDa, backed with USDC, USDT and DAI.
AegisConfig - a contract that holds the configuration about the protocol, including operators, signer, whitelist.
AegisMinting - a contract that implements functionality related to the minting
USDatokens, store collateral tokens, allows collateral redemption, accounts income, among the others.AegisOracle - a contract that serves a price oracle for
USDatoken.AegisRewards - a contract that distributed yield to the
USDaholders.SingleAdminAccessControl - a custom extension of the
AccessControllibrary that extends a single admin management.USDa - an ERC20 token supporting minting.
OrderLib - a library that defines
Orderstructure and adds function support for signed-message verification.
Privileged roles
The owner of
AegisConfigcan enable and disable whitelist, update signer, update operator.The operator of
AegisConfigcan update the whitelist.The owner of
USDacan update miner,The minter of
USDacan mint tokens. The protocol assumes it is set to theAegisMintinginstance.The REWARDSMANAGERROLE - manages the rewards distribution within the
AegisRewards.The onwer of
AegisOraclecan update contract's configuration and operators.The operator of
AegisOraclecan update oracle price ratio.The DEFAULTADMINROLE - can update contract's configuration, collateral tokens whitelist, and custodians.
The SETTINGSMANAGERROLE - can update contract's addresses, fees. limits, and pause status
The FUNDSMANAGERROLE - deposits income and manages the redemption approval and rejection within the
AegisMinting. Also, it can freeze and unfreeze collateral funds.The COLLATERALMANAGERROLE - can transfer out the collateral tokens from the
AegisMinting.
Potential 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.
Centralized Control of Minting Process: The token contract’s design allows for centralized control over the minting process, posing a risk of unauthorized token issuance, potentially diluting the token value and undermining trust in the project's economic governance.
Arbitrary Oracle Address Setting by Admin: Allowing the admin to set oracle addresses without constraints or verification mechanisms introduces the risk of incorrect or malicious oracle selection, affecting the accuracy of data and potentially leading to financial losses.
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.
Centralized Oracles as Data Sources: The protocol utilizes centralized oracles for external data inputs. Dependence on a singular or limited set of data sources can introduce accuracy and manipulation risks, potentially affecting the DApp's operations and decision-making processes.
Yield-generating Mechanism: The mechanism for yield generation is done off-chain and it is managed by the centralised entity.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-7480 | The _checkMintRedeemLimit bypass is possible | fixed | Medium | |
| F-2024-7450 | Usage of IERC20Receiver may lead to reentrancy vulnerabilities | fixed | Medium | |
| F-2024-7405 | The mint can return underestimated number for USDa tokens | accepted | Medium | |
| F-2024-7374 | Any EOA can trigger mint with valid signature and allowance | fixed | Medium | |
| F-2024-7372 | Signature reply possible within mint and depositIncome functions | fixed | Medium | |
| F-2024-7390 | Protocol rely on insecure oracle implementation | fixed | Medium | |
| F-2024-7438 | The claimRewards signature check is not EIP-712 compliant | fixed | Low | |
| F-2024-7409 | Loss of precision possible within the _calculateRedeemMinCollateralAmount | fixed | Low | |
| F-2024-7414 | Slippage check within the requestRedeem function is redundant | accepted | Observation | |
| F-2024-7496 | The redeemption process can help bypassing the stable coin blacklisting feature | fixed | Observation |
Identify vulnerabilities in your smart contracts.
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/zer0h1ro/aegis-contracts→ |
| Commit | c691e43890da838dc1a64a2b2719756fd9c98b61 |
| Whitepaper | n/a |
| Requirements | n/a |
| Technical Requirements | SOFTWARE ARCHITECTURE AEGIS.pdf |
Scope Details
- Commit
- c691e43890da838dc1a64a2b2719756fd9c98b61
- Whitepaper
- n/a
- Requirements
- n/a
- Technical Requirements
- SOFTWARE ARCHITECTURE AEGIS.pdf
Assets in Scope
AegisConfig.solAegisMinting.solAegisOracle.solAegisRewards.solinterfaces/IAegisConfig.solinterfaces/IAegisMinting.solinterfaces/IAegisOracle.solinterfaces/IAegisRewards.solinterfaces/IERC20Receiver.solinterfaces/ISingleAdminAccessControl.solinterfaces/IUSDa.sollib/OrderLib.solSingleAdminAccessControl.solUSDa.solAppendix 3. Additional Valuables
Verification of System Invariants
During the audit of Aegis, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 2 invariants were tested over 100,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| A mint, redemption, income deposit and rewards distribution with correct accounting must be possible with collateral with 6 decimal points. | Passed | 100k |
| A mint, redemption, income deposit and rewards distribution with correct accounting must be possible with collateral with 18 decimal points. | Passed | 100k |
Invariant
- A mint, redemption, income deposit and rewards distribution with correct accounting must be possible with collateral with 6 decimal points.
Test Result
- Passed
Run Count
- 100k
Invariant
- A mint, redemption, income deposit and rewards distribution with correct accounting must be possible with collateral with 18 decimal points.
Test Result
- Passed
Run Count
- 100k
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.