Audit name:
[SCA] Mesi | Mesi-Contracts | Aug2024
Date:
Sep 30, 2024
Table of Content
Introduction
We express our gratitude to the MESI team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Mesi is a new kind of social expression app that inspires to create, express, interact, and earn while providing a deep sense of community and self-sovereignty. The audit includes, the Token, Governance, Vesting, and Presale platform parts.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for MESI |
| Audited By | Stepan Chekhovskoi |
| Approved By | Grzegorz Trawinski |
| Website | https://www.mesi.app/→ |
| Changelog | 20/08/2024 - Initial Report |
| 30/09/2024 - Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | ERC-20, Governance, Vesting, Presale |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for MESI
- Audited By
- Stepan Chekhovskoi
- Approved By
- Grzegorz Trawinski
- Website
- https://www.mesi.app/→
- Changelog
- 20/08/2024 - Initial Report
- 30/09/2024 - Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- ERC-20, Governance, Vesting, Presale
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/BoostyLabs/mesi-sc→ |
| Initial Commit | dc256bccd456b188d27829906b5ddfdaa2020a22 |
| Final Commit | 10dfc32fb1f5a88ffd680e3226d9656108792a7b |
Review Scope
- Repository
- https://github.com/BoostyLabs/mesi-sc→
- Initial Commit
- dc256bccd456b188d27829906b5ddfdaa2020a22
- Final Commit
- 10dfc32fb1f5a88ffd680e3226d9656108792a7b
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
The code is covered with NatSpecs.
Functional requirements are partially provided.
Technical description is presented.
Code quality
The code contains some duplications.
In general, the code is well-written and self descriptive.
The architecture is clean and transparent.
Development environment is set up.
Test coverage
Code coverage of the project is 92% (branch coverage).
Most of the usage scenarios are covered with tests.
System Overview
The system includes the following contracts.
MESI - the ERC-20 token contract with infinite mint ability. Name: MesiToken. Symbol: MESI.
Controller - the Governance contract allowing for admins voting on new admins add or remove. The contract also plays for a configuration purpose, the Treasury contract address is retrieved by other system parts from the Controller contract.
Treasury - the Treasury contract allowing Controller admins to create proposals of funds transfer (compatible with ERC-20 tokens). The contract is designed to receive funds earned during the presale and other funding activities.
Seller - the Presale contract allowing admin to specify Merkle Tree of users available for presale. Presale happens in two phases having different number of tokens allocated for presale and different prices. Presale amounts are limited at per user and per round basis.
Vesting - the Vesting contract allowing admin to specify Merkle Tree of users vesting the tokens. The vesting is performed linearly in several groups, groups may have different start dates but the same end date. The vesting length is limited to 260 weeks.
Privileged roles
The MESI contract owner is able to infinitely mint the token to arbitrary address.
The Controller contract admins are able to vote for the registered Treasury contract address update, new admins add or old admins removal.
The Controller contract admins are able to vote for funds transfer from the Treasury contract.
The Controller contract admins are able to update whitelisted purchasers, change purchase limits and prices in the Seller contract.
The Controller contract admins are able to create and modify vesting groups, execute pause or revoke with total funds withdrawal in the Vesting contract.
Risks
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.
Lack of Vesting Funding Possibility: Merkle Tree is used in the Vesting contract to load all reward receivers data on-chain. While the functionality allows efficiently load significant amount of participants on-chain, it makes hard to validate if the contract is fully funded with the tokens and all vesters are able to claim their rewards.
Lack of Presale Funding Possibility: The Seller contract does not provide any guarantees on the funds allocated for presale are deposited to the contract.
Locked Vesting due to Merkle Tree Double Entry: The Vesting contract utilize Merkle Tree to specify vesters and their distribution amounts. Merkle Trees may contain same user several times what is not provided for by the contract. Users are able to withdraw only the biggest vesting registered in the Merkle Tree (vesting group).
Single Points of Failure and Control: The project is mostly 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.
Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
Absence of Upgrade Window Constraints: The contract suite allows for immediate upgrades without a mandatory review or waiting period, increasing the risk of rapid deployment of malicious or flawed code, potentially compromising the system's integrity and user assets.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-5419 | Invalid Vesting Distributions due to Invalid Calculations | fixed | High | |
| F-2024-5398 | Treasury Funds Lock due to Lack of Safe ERC-20 Operation Success Validation | fixed | High | |
| F-2024-5395 | Unreliable Governance due to Lack of Request Expiration | fixed | High | |
| F-2024-5394 | Voting Bypass due to Lack of Grant Role Override | fixed | High | |
| F-2024-5435 | Distribution Amount Mismatch Bought Amount | mitigated | Medium | |
| F-2024-5455 | Misleading Overcomplicated Price Calculations | fixed | Medium | |
| F-2024-5418 | Unimplemented Action Point on Vote Rejection | fixed | Medium | |
| F-2024-5406 | Unexpected Request Rejection due to Lack of Validation | fixed | Medium | |
| F-2024-5390 | Unflexible Governance due to Immutable Number of Admin Confirmations | fixed | Medium | |
| F-2024-5412 | Insufficient Oracle Validation | fixed | Low |
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/BoostyLabs/mesi-sc→ |
| Initial Commit | dc256bccd456b188d27829906b5ddfdaa2020a22 |
| Final Commit | 10dfc32fb1f5a88ffd680e3226d9656108792a7b |
| Whitepaper | https://mesi-1.gitbook.io/whitepaper→ |
| Requirements | NatSpec comments |
| Technical Requirements | README.md |
Scope Details
- Repository
- https://github.com/BoostyLabs/mesi-sc→
- Initial Commit
- dc256bccd456b188d27829906b5ddfdaa2020a22
- Final Commit
- 10dfc32fb1f5a88ffd680e3226d9656108792a7b
- Whitepaper
- https://mesi-1.gitbook.io/whitepaper→
- Requirements
- NatSpec comments
- Technical Requirements
- README.md