Mundus Security is thrilled to announce the release of the Deployment Check Report for the ARTH Value Token and Governance Token of the MahaDAO (https://mahadao.com/) project. If you want to bring trust to your users, we are here to talk (calendly).
To learn more about Deployment Check check our previous article: What is Deployment Check? (mundus.dev).
ARTH Value Token Deployment Check
Codebase analysis
Inconsistency between the same project files across contracts (excluding dependencies)
The goal is to check for any differences and inconsistencies in the source code of the same parts of the contracts. We compare each pair of smart contracts in the scope of work (SoW). Files with the same name and relative path included (imported) in both contracts should have the same content.
Summary
Severity: High.
The team found inconsistencies in source code files across contracts in the SoW. These inconsistencies indicate that the smart contracts were from different source code repositories. In the case of USDCCurveStrategy contract these inconsistencies lead to insufficient access control over one of its methods.
Searching for the original commit in the client's repository
At this stage, we are looking for the original commit in the client's repository. In the best case, all contracts should be deployed from a single codebase revision to decrease the probability of inconsistency in the contract logic. See exact way of figuring out this information in section A2 of our report
Summary
Severity: Medium
The project is composed of six repositories, each containing a variety of contracts. We dentified the original commit for each group of contracts in their respective repositories. However, we also evaluated the consistency of the contracts across all repositories. We noticed that differences in the codebase, especially in the interfaces of the deployed contracts from different repositories, suggest that the revisions from which they were deployed may have logical inconsistencies. This issue is covered by conducting security audit. See the Interim Result here: MahaDAO Interim Security Audit (mundus.dev)
Analyzing the dependencies of the contracts
The goal is to check the consistency of every dependency version and identify any changes across every dependency codebase.
Summary
Severity: Medium
The contracts in the SoW use OpenZeppelin dependencies. Four different versions of the OpenZeppelin smart contracts are used in the SoW's contracts: 4.3.3, 4.5.0, 4.7.3 and 4.8.2. The security issues of using four different versions of OpenZeppelin is additionally investigated during the security audit of the deployed smart contracts code. See the Interim Result here: MahaDAO Interim Security Audit (mundus.dev)
Deployment check: storage
We thoroughly examine both its public and private storage to ensure that there are no misconfigurations, especially:
- Incorrect or outdated addresses to other smart contracts referenced in the scope of work (SoW) - this includes addresses stored in variables, mappings, and other data structures.
- Any references to other smart contracts or externally owned accounts (EOAs) that may be incorrect or outdated.
- Any incorrect protocol settings stored in variables or other data structures.
- Misconfigurations related to the roles and permissions of the contract.
- Governance issues that may impact the operation and business logic of the smart contract.
Summary
You can find the detailed description of the issues in the smart contract audit eport.
Governance Token Deployment Check
Codebase analysis
Inconsistency between the same project files across contracts (excluding dependencies)
The goal is to check for any differences and inconsistencies in the source code of the same parts of the contracts. We compare each pair of smart contracts in the scope of work (SoW). Files with the same name and relative path included (imported) in both contracts should have the same content.
Summary
Severity: Low.
The team found inconsistencies in interfaces across contracts in the SoW. These inconsistencies indicate that the smart contracts were deployed at different times and from different source code revisions. However, these differences are classified as compatible changes.
Searching for the original commit in the client's repository
At this stage, we are looking for the original commit in the client's repository. In the best case, all contracts should be deployed from a single codebase revision to decrease the probability of inconsistency in the contract logic. See exact way of figuring out this information in section A2 of our report
Summary
Severity: High
There is no original commit or timestamp to which all contracts in the SoW could be matched. Even after considering the differences between the contract files discussed in the previous section, there is no point in time when the code deployed to the network can be matched to. This could result in significant inconsistencies in the protocol logic. This issue is covered by conducting a smart contract security audit.
Analyzing the dependencies of the contracts
The goal is to check the consistency of every dependency version and identify any changes across every dependency codebase.
Summary
Severity: Medium
The contracts in the SoW use two dependencies: UniswapV3 and OpenZeppelin. The version of the UniswapV3 dependency can be matched to 1.0.0. Three different versions of the OpenZeppelin smart contracts are used in the SoW's contracts: 4.3.3, 4.6.0, and 4.7.3. We also found changes to the OpenZeppelin dependency code in the MahaToken smart contract (see Changes to External Dependency section) that are not tracked in the project's repositories. However, we consider them to be safe. The security issues of using three different versions of OpenZeppelin will be investigated during the security audit of the deployed smart contracts code.
Deployment check: storage
We thoroughly examine both its public and private storage to ensure that there are no misconfigurations, especially:
- Incorrect or outdated addresses to other smart contracts referenced in the scope of work (SoW) - this includes addresses stored in variables, mappings, and other data structures.
- Any references to other smart contracts or externally owned accounts (EOAs) that may be incorrect or outdated.
- Any incorrect protocol settings stored in variables or other data structures.
- Misconfigurations related to the roles and permissions of the contract.
- Governance issues that may impact the operation and business logic of the smart contract.
Summary
You can find the detailed description of the issues in the report
Conclusion
We are happy to work with the MahaDAO team to improve security and build trust for the community and investors. Stay tuned to receive the following security updates soon!
Appendix
About MahaDAO
MahaDAO is a mission to create a decentralized and stable economy. That is driven by the people, for the people. This document explains various parts of the DAO and its governance.
MahaDAO is a community-powered, decentralized organization on a mission to empower billions with a stable economy through the world’s first valuecoin.
To do this, MahaDAO uses two tokens to achieve this vision - the governance token MAHA, and the valuecoin.
About ARTH value token
ARTH is a stablecoin that is designed to appreciate overtime against the US dollar while at the same time it remains relatively stable.
ARTH is minted/burnt using decentralized smart contracts that use ETH as collateral to maintain its peg. The interest rate charged to mint ARTH using ETH is 0%, which makes it very cost-effective for borrowing/lending.
ARTH is fully collateralized with mechanisms that give it a backing of at least 110% in ETH.