Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • midas
  • [SCA] Midas / Vault / Dec2023
Midas logo

Midas

Audit name:

[SCA] Midas / Vault / Dec2023

Date:

Jan 11, 2024

Table of Content

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

Want a comprehensive audit report like this?

Introduction

We thank  the Midas team for allowing us to conduct a Smart Contract Security Assessment. This document outlines our methodology, limitations, and results of the security assessment.

The Midas Project consists of a couple of vaults: the first one is used for deposits and the other one is used for redemption.  The system allows users to mint mTBILL stablecoins by putting their USD-like stablecoins as collateral.

titlecontent
PlatformEVM
LanguageSolidity
TagsVault, Stablecoin, ERC20, Collateral.
Timeline21/12/2023 - 18/01/2024
Methodologyhttps://hackenio.cc/sc_methodology→

    Last Review Scope

    Repositoryhttps://github.com/RedDuck-Software/midas-contracts→
    Commitd84b0ed
    Remediation2004f60

    Audit Summary

    Total10/10
    Security Score

    10/10

    Test Coverage

    100%

    Code Quality Score

    10/10

    Documentation Quality Score

    10/10

    8Total Findings
    4Resolved
    4Accepted
    0Mitigated

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

    Document Information

    This report may contain confidential information about IT systems and the intellectual property of the client, as well as information about potential vulnerabilities and methods of their exploitation.

    The report can be disclosed publicly after prior consent by another party. Any subsequent publication of this report shall be without mandatory consent.

    Document

    NameSmart Contract Code Review and Security Analysis Report for Midas
    Audited ByDavid Camps Novi, Viktor Lavrenenko
    Approved ByAtaberk Yavuzer
    Websitehttps://midas.app/→
    Changelog27/12/2023 - Preliminary Report
    18/01/2024 - Final Report

    • Document

      Name
      Smart Contract Code Review and Security Analysis Report for Midas
      Audited By
      David Camps Novi, Viktor Lavrenenko
      Approved By
      Ataberk Yavuzer
      Website
      https://midas.app/→
      Changelog
      27/12/2023 - Preliminary Report
      18/01/2024 - Final Report

    System Overview

    Midas is a set of smart-contract vaults that allow the minting of mTBILL stablecoin. It consists of  the following contracts:

    • DepositVault - a contract that represents a vault to which users should deposit their USD-liked tokens to receive mTBILL stablecoins.

    • RedemptionVault - a contract that represents a vault, which should be used by users to get their USD-liked tokens.

    • DecimalsCorrectionLibrary - a library that is used for conversions with decimals.

    • DataFeed - a wrapper of ChainLink`s AggregatorV3 data feeds.

    • WithMidasAccessControl -  a base contract that consumes MidasAccessControl.

    • Pausable - a base contract that implements basic functions and modifiers with pause functionality.

    • MidasAccessControlRoles - a base contract that stores all role descriptors.

    • MidasAccessControl - a smart contract that manages all roles of the Midas project.

    • Greenlistable - a base contract that implements basic functions and modifiers to work with greenlistable.

    • Blacklistable - a base contract that implements basic functions and modifiers to work with blacklistable.

    • MidasInitializable - a base initializable contract that implements constructor() that calls _disableInitializers() to prevent initialization of the implementation contract.

    • ManageableVault - a contract with base vault methods.

    • IDataFeed - an interface, which is used to interact with the DataFeed contract.

    • IDepositVault - an interface, which describes the main functionality of the DepositVault.

    • IMTbill - an interface, which describes the main functionality of the mTBILL stablecoin.

    • IManageableVault - an interface, which describes the basic functionality of the vaults.

    • IRedemptionVault - an interface, which describes the main functionality of the RedemptionVault.

    mTBILL - ERC20 stablecoin that users can receive after depositing into the DepositVault with pausing, blacklist, and upgrade functionality.

    It has the following attributes:

    • Name: mTBILL

    • Symbol: mTBILL

    • Decimals: 18

    Privileged Roles

    • GREENLISTOPERATORROLE - can change green list statuses of addresses.

    • BLACKLISTOPERATORROLE - can change blacklist statuses of addresses

    • MTBILLMINTOPERATORROLE - can mint mTBILL stablecoin.

    • MTBILLBURNOPERATORROLE - can burn mTBILL stablecoin.

    • MTBILLPAUSEOPERATORROLE - can pause/unpause the functionality of mTBILL stablecoin.

    • DEPOSITVAULTADMIN_ROLE - can add/remove payment tokens in the DepositVault contract.

    • REDEMPTIONVAULTADMIN_ROLE - can add/remove payment tokens in the Redemption vault.

    • GREENLISTED_ROLE - can deposit USD-like tokens to get mTBILL tokens via DepositVault and redeem mTBILL tokens to get USD-like tokens back.

    • BLACKLISTED_ROLE - cannot use the functionality of the mTBILL contract.

    • DEFAULTADMINROLE - can grant/revoke roles, set Metadata, and change changeAggregator.

    Executive Summary

    Documentation quality

    The total Documentation Quality score is 10 out of 10.

    • Functional requirements are provided.:

    • Technical description is sufficient.

    Code quality

    The total Code Quality score is 10 out of 10.

    • The development environment is configured.

    • Best practices are followed.

    Test coverage

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

    • Deployment and basic user interactions are covered with tests.

    • Negative cases coverage is provided.

    • Interactions by several users are tested thoroughly.

    Security score

    Upon auditing, the code was found to contain 1 low severity issue, leading to a security score of 10 out of 10.

    All identified issues are detailed in the “Findings” section of this report.

    Summary

    The comprehensive audit of the Customer's smart contract yields an overall score of 10. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.

    Risks

    All system roles, as well as critical processes, are managed by system at the beginning, which makes the protocol highly centralized. The users should be aware of the risk they take when interacting with this project, in which they need to trust.

    The total supply of the mTBILL stablecoin is not limited, which can lead to a discrepancy between the number of assets in the bank and the number of minted tokens.

    The DEFAULT_ADMIN_ROLE can grant and revoke the GREENLISTED_ROLE and the BLACKLISTED_ROLE, which can affect users' capabilities at will, without previous notice.

    The mTBILL token is a stablecoin according to the provided documentation. However, there is no way to guarantee the reliability of the peg system of the token on-chain.

    The conversion of deposit tokens to mTBILL tokens and vice-versa is performed off-chain by the system and cannot be audited.

    Both DepositVault and RedemptionVault have _paymentTokens, which stores a set of allowed tokens used in the previously mentioned vaults. Both of them should store the same data. It creates a risk of discrepancy between data in both arrays if they are not managed properly off-chain.

    The minAmountToDepositInEuro is set via the function setMinAmountToDeposit()  by the vaultAdmin and has no limits. There is a risk that the vaultAdmin might manipulate the minAmountToDepositInEuro. As a result, users may not be able to deposit due to the high minAmountToDepositInEuro threshold.

    The admin with DEFAULT_ADMIN_ROLE role can delete the depositors from the list of greenlisted users by calling revokeRoleMult(), which might make it impossible for them to call redeem() and get their deposits back.

    The mTBILL stablecoin utilizes a blacklisting mechanism, which is managed by the DEFAULT_ADMIN_ROLE role. There is a risk that the DEFAULT_ADMIN_ROLE can abuse the blacklisting feature and blacklist users at their will.

    The mTBILL, DepositVault, and RedemptionVault contracts are upgradeable, hence there is a risk that the new implementation might be broken or malicious.

    The mTBILL token has a pausing feature, thus there is a risk that it can be paused at any moment.

    The role M_TBILL_BURN_OPERATOR_ROLE can burn tokens from the user address without previous notice.

    The token conversion rate is defined by the protocol off-chain, hence the users cannot know the amount of token they will get beforehand, either in the deposit or redeem process.

    The address tokenReceiver receives all deposited in the Vault. As such, there is no control over that contract, or how the tokens are managed. (see the Risk Statement below)

    Risk Statement

    This audit report focuses exclusively on the security assessment of the contracts within the specified review scope. Interactions with out-of-scope contracts are presumed to be correct and are not examined in this audit. We want to highlight that Interactions with contracts outside the specified scope, such as:

    /contracts/ManageableVault.sol: tokensReceiver have not been verified or assessed as part of this report.

    While we have diligently identified and mitigated potential security risks within the defined scope, it is important to note that our assessment is confined to the isolated contracts within this scope. The overall security of the entire system, including external contracts and integrations beyond our audit scope, cannot be guaranteed.

    Users and stakeholders are urged to exercise caution when assessing the security of the broader ecosystem and interactions with external contracts. For a comprehensive evaluation of the entire system, additional audits and assessments outside the scope of this report are necessary.

    This report serves as a snapshot of the security status of the audited contracts within the specified scope at the time of the audit. We strongly recommend ongoing security evaluations and continuous monitoring to maintain and enhance the overall system's security.

    Findings

    Code
    ―
    Title
    Status
    Severity
    F-2023-0292USD Tokens With Custom Decimals Are Not Handled Properly
    accepted

    High
    F-2023-0299Incorrect 1:1 Price Assumption Can Lead To Data Inconsistency
    accepted

    Medium
    F-2023-0288Missing Oracle Refresh Check Can Lead To Outdated Pricing
    fixed

    Medium
    F-2023-0290Highly Permissive Role Can Burn Tokens From Users
    accepted

    Low
    F-2023-0300 The Minimum Deposit Check Is Not Applied To Initial Depositors
    accepted

    Observation
    F-2023-0298Improperly Utilized AccessControlUpgradeable Leads To The High Level Of Centralization
    fixed

    Observation
    F-2023-0291Unused State Variables
    fixed

    Observation
    F-2023-0289Missing checks for address(0)
    fixed

    Observation
    1-8 of 8 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/RedDuck-Software/midas-contracts→
    Commitd84b0ed
    Final Remediation Commitd84b0ed
    WhitepaperN/A
    RequirementsREADME.md→
    Technical RequirementsNatSpec→

    Contracts in Scope

    DepositVault.sol - DepositVault.sol
    RedemptionVault.sol - RedemptionVault.sol
    mTBILL.sol - mTBILL.sol
    abstract
    ManageableVault.sol - abstract/ManageableVault.sol
    MidasInitializable.sol - abstract/MidasInitializable.sol
    access
    Blacklistable.sol - access/Blacklistable.sol
    Greenlistable.sol - access/Greenlistable.sol
    MidasAccessControl.sol - access/MidasAccessControl.sol
    MidasAccessControlRoles.sol - access/MidasAccessControlRoles.sol
    Pausable.sol - access/Pausable.sol
    WithMidasAccessControl.sol - access/WithMidasAccessControl.sol
    feeds
    DataFeed.sol - feeds/DataFeed.sol
    interfaces
    IDataFeed.sol - interfaces/IDataFeed.sol
    IDepositVault.sol - interfaces/IDepositVault.sol
    IManageableVault.sol - interfaces/IManageableVault.sol
    IMTbill.sol - interfaces/IMTbill.sol
    IRedemptionVault.sol - interfaces/IRedemptionVault.sol
    libraries

    Disclaimer