M0Labs

Introduction

M^0 Labs is designing a permissionless value transmission framework, enabling decentralized minting of stable on-chain currencies. The core utility token, $M, is intended to function as a digital representation of value, inheriting the low-risk profile of physical cash while offering the programmability of digital assets.

Why Did They Need an Audit?

Following the completion of a full-system audit, M^0 Labs commissioned a focused review of their WrappedMToken, IndexingMath, and proxy patterns to validate changes and assess dust handling, earning logic, and rounding operations. Due to the sensitivity of WrappedMToken’s accounting, which manages internal and external representations of value accrual, correctness at the arithmetic and indexing level was paramount. The team asked Three Sigma to conduct a short engagement to identify any latent bugs or assumptions that may affect balance integrity.

Scope of the Engagement

Results and Findings

Key Low-Severity Issues

Permissionless call to stopEarning creates unbacked balance risk

• Description: The MToken::stopEarning(address account_) function is permissionless, allowing anyone to stop WrappedMToken from accruing interest. However, if not called via WrappedMToken::disableEarning(), the necessary indexing update (_lastDisableEarningIndex) is skipped. This leads to inflated WrappedMToken balances without corresponding backing in MToken, potentially creating a mismatch that disadvantages late redeemers.
• Recommendation: Governance actions that disable earning in the registrar should be atomically paired with a call to WrappedMToken::disableEarning() to record the index state.

Unchecked arithmetic in subtractTotalEarningSupply can wrap supply

• Description: Due to mismatches in rounding logic between balance and principal calculations, the total supply accounting in WrappedMToken::_subtractTotalEarningSupply() may drift slightly. If the unchecked block remains, these mismatches can cause the value to wrap and inflate supply.
• Recommendation: Remove the unchecked block to ensure that rounding-induced drift does not cause overflow.

Informational Issues (Suggestions)

Re-enabling earning may inflate balances without MToken backing

• Description: Re-enabling earning (currently disabled) would resume from the latest MToken index, which may be significantly higher than the stored index in WrappedMToken. This would retroactively increase all balances without an increase in backing funds, causing unearned profit for some and a shortfall for others.
• Recommendation: If re-enabling is supported in the future, apply a corrective multiplier based on stored vs. current index to avoid artificial gains.

Assumption about stored index position may break with future re-enabling

• Description: The _lastDisableEarningIndex() function assumes that the second element in _enableDisableEarningIndices corresponds to the disable action. This is only true if the token is disabled once. If re-enabling is introduced, this logic breaks.
• Recommendation: Use _enableDisableEarningIndices.length - 1 to fetch the last index. If using index 1 for gas savings, add a comment to revisit this if re-enabling is implemented.

In conclusion

Three Sigma’s 3-day engagement focused on the wrapped earning logic and indexing arithmetic in the M^0 protocol. Although no critical or high-severity bugs were found, we identified subtle inconsistencies in permissionless operations and total supply calculations. The team proactively addressed one arithmetic issue and acknowledged others that are currently unreachable but may become relevant if features like re-enabling are added. We encourage continued testing and monitoring of index-based calculations, especially under potential future state transitions.