M0

The M0 Protocol implements an ERC20 M Token system with a sophisticated minting and collateral management framework. The core architecture consists of the `MToken` contract (handling earning/non-earning accounts with continuous compounding interest), the `MinterGateway` (managing minter collateral, mint proposals, penalties, and the lifecycle of minters), and supporting rate models controlled by TTG (Two Token Governance). The protocol design centers around an invariant that `totalOwedM >= totalMSupply`, ensuring the M token remains fully backed.

The codebase demonstrates strong security engineering throughout. Rounding is consistently applied in favor of the protocol — principal amounts are rounded down on mint/deposit and rounded up on burn/withdrawal, following the checks-effects-interactions pattern for all state-modifying operations. Access control is correctly implemented: `mint`/`burn` on MToken are restricted to the MinterGateway, minter operations require active status and unfrozen state, and validator operations require TTG approval. The collateral update mechanism uses EIP-712 typed signatures with strict timestamp ordering (`_lastSignatureTimestamp` tracking per minter-validator pair) to prevent replay attacks. The `ContinuousIndexingMath` library uses a Padé R(4,4) approximation for the exponential function with well-bounded error characteristics, and all arithmetic uses Solidity 0.8.23 overflow protection with `unchecked` blocks limited to provably safe operations.

The protocol's economic design is sound. The `EarnerRateModel` uses a 30-day confidence interval with a 98% rate multiplier to ensure earner cashflow never exceeds minter cashflow over any reasonable horizon. Penalty mechanisms for missed collateral updates and undercollateralization are implemented with careful guard rails — including capping `principalOfTotalActiveOwedM` at `type(uint112).max` to prevent overflow. The `excessOwedM` function conservatively uses rounded-down calculations when minting surplus M to the TTG vault, and the `updateIndex` function correctly sequences minter index updates, excess minting, and earner index updates to prevent rate model inconsistencies within a single transaction. The protocol appears to have undergone extensive prior auditing and formal verification (Certora harnesses are present), and the comprehensive invariant and fuzz test suite confirms the primary solvency invariant across diverse scenarios.