- Hacken
- Audits
- mu-digital
- [SCA] MU Digital | MU-Protocol | Jul2025
Audit name:
[SCA] MU Digital | MU-Protocol | Jul2025
Date:
Aug 19, 2025
Table of Content
Introduction
We express our gratitude to the MU Digital team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Mu Digital facilitates staking and redemption of tokens using ERC4626 vaults, while also enabling minting and redemption of stablecoins and synthetic assets via a primary market governed by configurable parameters.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for MU Digital |
| Audited By | Seher Saylik, Kornel Światłowski |
| Approved By | Ivan Bondar |
| Website | https://mudigital.net/→ |
| Changelog | 01/08/2025 - Preliminary Report |
| 19/08/2025 - Final Report | |
| Platform | Monad, Ethereum |
| Language | Solidity |
| Tags | ERC20, ERC4626, Upgradable, Staking, Oracle |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for MU Digital
- Audited By
- Seher Saylik, Kornel Światłowski
- Approved By
- Ivan Bondar
- Website
- https://mudigital.net/→
- Changelog
- 01/08/2025 - Preliminary Report
- 19/08/2025 - Final Report
- Platform
- Monad, Ethereum
- Language
- Solidity
- Tags
- ERC20, ERC4626, Upgradable, Staking, Oracle
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Mu-Digital/mu-protocol→ |
| Commit | dc0f710bda7254a8ea9f09bc9a164fa40e61a983 |
| Remediation Commit | 3c2e5b23cc686c0d3c315dc3c96e94a1ae3a08a4 |
Review Scope
- Commit
- dc0f710bda7254a8ea9f09bc9a164fa40e61a983
- Remediation Commit
- 3c2e5b23cc686c0d3c315dc3c96e94a1ae3a08a4
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are present, but only at a high-level.
Basic system description is provided.
No futures description.
Technical description is detailed.
NatSpec is detailed.
Run instructions are provided.
Technical specification is provided.
Code quality
Insufficient Gas modeling.
Development environment is configured.
Best practice violations.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is present.
System Overview
The
ContractUUPSUpgradeableis a base contract designed for UUPS upgradeable contracts. It inherits from OpenZeppelin'sUUPSUpgradeableandAccessControlUpgradeable.The
ContractBaseUpgradeableserves as a foundational contract for creating upgradeable contracts, integrating access control, pausability, and reentrancy protection. It inherits fromUUPSUpgradeable,PausableUpgradeable, andReentrancyGuardUpgradeable.The
AccessManagercontract is a UUPS upgradeable contract due to its inheritance fromContractUUPSUpgradeable. It extendsAccessControlUpgradeableby adding functionality to grant and revoke roles in bulk.The
MuBONDcontract is a standard ERC20 token. It is minted and burned through thePrimaryMarketcontract.The
MuSDcontract is a standard ERC-20 token. It is minted and burned through thePrimaryMarketcontract.The
SMuSDcontract is an ERC4626 vault forMuSDtoken. Shares can be only minted and burned by theStakingEscrowcontract.The
PrimaryMarketcontract facilitates the minting and redemption ofMuSDandMuBONDtokens based on prices obtained from thePriceFeed. It accepts USDC and USDT for these operations.The
PriceFeedcontract stores direct token prices forMuSDandMuBOND.The
StakingEscrowcontract manages the staking and redemption of tokens with defined cooldown periods. It allows users to stake tokens into designated vaults and handles redeem requests, ensuring that only whitelisted addresses can participate.The
Timelockcontract inherits theTimelockControllerUpgradeableandContractUUPSUpgradeablecontracts without any additional logic.The
TreasuryManagercontract provides functionalities to withdraw any ERC20 tokens from itself to provided address.
Privileged roles
The system uses the AccessManager contract to restrict access to important functions. The system has defined following roles:
DEFAULT_ADMIN_ROLErole can:ContractUUPSUpgradeable::_authorizeUpgrade() - Authorize the upgrade of the contract
ContractBaseUpgradeable::setAccessManager() - Update the access manager address
PrimaryMarket::setDepositedTokens() - Update the status of tokens as deposited or not
PrimaryMarket::setReceivedTokens() - Update the status of tokens as received or not
PrimaryMarket::addWhiteList() - Add addresses to the whitelist
PrimaryMarket::removeWhiteList() - Remove addresses from the whitelist
PrimaryMarket::setTreasury() - Update the treasury address
PrimaryMarket::setPriceFeed() - Update the price feed address
PrimaryMarket::retrieveERC20Tokens() - Retrieve ERC20 tokens from the contract to a recipient address
StakingEscrow::setVault() - Set the vault address for a specific token
StakingEscrow::setCoolDownPeriod() - Set the cool down period for redeem requests
StakingEscrow::addWhiteList() - Add addresses to the whitelist
StakingEscrow::removeWhiteList() - Remove addresses from the whitelist
MuBOND::setAccessManager() - Update the access manager address
MuSD::setAccessManager() - Update the access manager address
PAUSER_ROLErole can:ContractBaseUpgradeable::pause() - Pause the contract
ContractBaseUpgradeable::unpause() - Unpause the contract
TREASURY_WITHDRAW_ROLErole can:TreasuryManager::withdrawFund() - Withdraw token for redemption
TREASURY_TRANSFER_ROLErole can:TreasuryManager::transferToCustodian() - Transfers funds to an off-chain custodian
ORACLE_ROLErole can:PriceFeed::updatePrice() - Update the price of a token
TOKEN_VAULT_MINTER_ROLErole can:SMuSD::deposit() - Deposit assets to the vault
SMuSD::mint() - Mint new vault shares
TOKEN_VAULT_BURNER_ROLErole can:MuSD::withdraw() - withdraws assets from the vault
SMuSD::redeem() - Redeem shares from the vault
REWARD_DEPOSITOR_ROLErole can:SMuSD::depositRewards() - Deposit rewards into the contract.
TOKEN_MINTER_ROLErole can:MuSD::mint() - Mint new tokens
MuBOND::mint() - Mint new tokens
TOKEN_BURNER_ROLErole can:MuSD::burn() - Burn tokens
MuBOND::burn() - Burn tokens
Potential Risks
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.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity and user trust, especially during critical operations like minting phases.
Single Entity Upgrade Authority: The ecosystem grants a single entity the authority to implement upgrades or changes. This centralization of power risks unilateral decisions that may not align with the community or stakeholders' interests, undermining trust and security.
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.
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.
Insufficient Multi-signature Controls for Critical Functions: The lack of multi-signature requirements for key operations centralizes decision-making power, increasing vulnerability to single points of failure or malicious insider actions, potentially leading to unauthorized transactions or configuration changes.
Coarse-Grained Authorization Model Risks: A single instance of AccessManager is used across all contracts within the protocol's scope. This creates a central point of failure—if the admin key is compromised, all contracts relying on the same AccessManager instance may be affected. The broad authorization model amplifies this risk, as a compromise of any authorized address could lead to unauthorized actions across multiple contracts, potentially resulting in a complete loss of protocol control and significant financial damage.
Token minting, burning, and vault operations are governed by external role assignments rather than fixed contract associations: The MuBOND, MuSD, and SMuSD contracts rely on role-based access control through the external AccessManager contract to authorize minting, burning, and vault operations. While the documentation implies these actions are restricted to specific contracts like PrimaryMarket, this is not enforced at the contract level. Any address granted the corresponding role (e.g., TOKEN_MINTER_ROLE, TOKEN_BURNER_ROLE, or TOKEN_VAULT_MINTER_ROLE) can perform privileged actions. Since role assignments can be modified post-deployment, this introduces potential governance and trust risks unless tightly controlled.
Admin Can Block Asset Redemption: The DEFAULT_ADMIN_ROLE has the ability to block asset redemption by removing addresses from the whitelist. Additionally, the DEFAULT_ADMIN_ROLE can remove deposit and receive tokens from their corresponding mappings, further disabling the redemption process. In the event of unfavorable market conditions, these actions can be used to unilaterally prevent access to protocol-held assets, introducing a high centralization and denial-of-access risk.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1197 | Redemption Logic Does Not Burn Tokens and Release Stablecoins as Documented | fixed | High | |
| F-2025-1198 | Inadequate Price Feed Validation and Oracle Design | fixed | Medium | |
| F-2025-1197 | Lack of Stablecoins On-Chain Custody Reduces Redemption Reliability | accepted | Medium | |
| F-2025-1197 | Burner Role Can Arbitrarily Burn MuBOND and MuSD ERC20 Tokens | fixed | Medium | |
| F-2025-1197 | Admin-Controlled Cooldown Period, Vault and PriceFeed Can Be Front-Run | accepted | Medium | |
| F-2025-1196 | Missing Slippage Protection in Minting | fixed | Medium | |
| F-2025-1196 | Stablecoin Is Assumed To Have A Fixed 1:1 Value (De-Peg Risk) | fixed | Medium | |
| F-2025-1198 | Incompatibility with Fee-on-Transfer Tokens | fixed | Low | |
| F-2025-1198 | Default Admin Role Misused for Operational Management | fixed | Low | |
| F-2025-1196 | Missing Storage Gap | fixed | Low |
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/Mu-Digital/mu-protocol→ |
| Commit | dc0f710bda7254a8ea9f09bc9a164fa40e61a983 |
| Remediation Commit | 3c2e5b23cc686c0d3c315dc3c96e94a1ae3a08a4 |
| Whitepaper | - |
| Requirements | https://github.com/Mu-Digital/mu-protocol/blob/main/README.md→ |
| Technical Requirements | https://github.com/Mu-Digital/mu-protocol/blob/main/README.md→ |
Scope Details
- Commit
- dc0f710bda7254a8ea9f09bc9a164fa40e61a983
- Remediation Commit
- 3c2e5b23cc686c0d3c315dc3c96e94a1ae3a08a4
- Whitepaper
- -
- Technical Requirements
- https://github.com/Mu-Digital/mu-protocol/blob/main/README.md→
Assets in Scope
Appendix 3. Additional Valuables
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.