[Asset Technical Assessment] mUSD on Aave V3 Monad
Author: Aave Labs
Date: 2026-06-30
## Summary
Technical assessment of mUSD (MetaMask USD) for onboarding to Aave V3 Monad, following the [Technical Asset Listing Framework]([ARFC] Technical Asset Listing Framework).
**Overall result:** 
MEDIUM
mUSD on Monad is a well-audited, standard M0 stablecoin wrapper with clean, non-rebasing ERC20 behaviour, a single canonical deployment, and a token role-administration and upgrade path that are well-governed (each sits behind a 72-hour timelock controlled by a 3-of-5 multisig). At launch it is priced using a fixed price consistent with its 1:1 dollar peg: given thin secondary on-chain liquidity, a fixed price is well suited, an approach used on other Aave instances for borrowable-only assets. The cross-chain route that creates Monad’s mUSD supply has no rate limit on minting, which is acknowledged as acceptable for a borrowable-only listing; the residual items are that its operator and pause roles sit on a single externally owned account (EOA) and that message verification is left on Hyperlane’s shared default verifier, which the issuer does not control. The issuer’s freeze-and-seize capability is inherent to this permissioned, issuer-controlled stablecoin and is accepted as a characteristic of the asset class.
### Listing Recommendation
From a technical standpoint, mUSD on Aave V3 Monad is eligible for listing as a borrowable-only asset, with conditions to surface and revisit as exposure grows. mUSD is priced at a fixed value consistent with its 1:1 dollar peg; given thin secondary on-chain liquidity, a fixed price is well suited, an approach used on other Aave instances for borrowable-only assets. On the cross-chain mint path, the absence of a rate limit is acceptable for a borrowable-only listing, while moving the bridge operator and pause roles off a single key and pinning an issuer-reviewed message verifier in place of the shared default are recommended hardening measures. The freeze and forced-transfer (recovery) capability is inherent to the asset’s permissioned design and is accepted as such; placing those roles behind a timelock, and ideally a multisig, is a recommended hardening. mUSD also has no permissionless on-chain redemption (unwrapping to M is restricted to whitelisted swappers), so a liquidator’s only on-chain exit is a decentralized exchange (DEX) sale; this should be documented and supported by sufficient on-chain liquidity as the market develops.
## Asset under review
| Field | Value |
|—|—|
| Asset | MetaMask USD (mUSD) |
| Target chain | Monad (chain ID `143`) |
| Target market | Aave V3 Monad |
| Token contract | `0xaca92e438df0b2401ff60da7e4337b687a2435da` |
| Native to target chain? | No. Bridged. mUSD is a non-rebasing wrapper of M0’s M token; on Monad, M is minted and burned by the M0 SpokePortal, which receives M from Ethereum over a Hyperlane message route. |
| AAcA classification | Stablecoin (issuer-controlled, permissioned wrapper; yield does not accrue to the token) |
mUSD is MetaMask’s US-dollar stablecoin, built on the M0 protocol. It is a thin, non-rebasing ERC20 wrapper around M0’s yield-bearing M token: a user’s M is locked inside the mUSD contract and an equal amount of mUSD is minted, with all of M’s yield diverted to a single designated recipient, so a holder’s balance stays flat and one mUSD always redeems for one M (approximately one US dollar). Each mUSD is backed 1:1 by an M token held inside the mUSD contract, and M is in turn backed by short-term US Treasuries held off-chain by the M0 issuer. On Monad, neither mUSD nor M is issued locally: M arrives from Ethereum across the M0 cross-chain route, and the local portal mints the M that backs Monad’s mUSD.
## 0. Pre-screening
mUSD is deployed and verified on Monad at `0xaca92e…435da`, reporting name “MetaMask USD”, symbol “mUSD”, 6 decimals, and a total supply of roughly 1.43 million tokens. It is a US-dollar stablecoin, an established asset that is not in any non-approved or sanctioned category. The ticker mUSD is shared with an older, unrelated token (mStable USD), which is not deployed on Monad and is not the asset under review; the candidate assessed is the MetaMask USD token built on M0, the only mUSD-symboled token actually deployed on Monad and the one MetaMask and M0 publicly associate with the chain. No Aave listing of mUSD exists elsewhere on-chain. The deployed implementation exposes exactly the audited M0 function surface and has never rotated since deployment, but the Monad implementation is not source-verified on a public explorer, so its bytecode cannot be matched to the audited commits (see Section 7).
**Rating:** 
GOOD
## 1. ERC20 Compliance
mUSD on Monad is a standard, non-rebasing ERC20 with 6 decimals: `transfer()` and `transferFrom()` return bool, with no fee on transfer, no rebasing, no ERC777 or ERC1363 hooks, and no flash mint. Balances are held in dedicated storage and do not grow; yield accrues to a separate recipient rather than to holder balances (see Section 4). There is no general transfer whitelist, so smart contracts can hold and transfer the token without restriction; the only transfer restriction is the targeted account freeze, which is assessed under access control (see Section 3) rather than as an ERC20-compliance defect. The 6-decimal precision sits within Aave’s accepted band.
**Rating:** GOOD
## 2. Oracle
Given that secondary on-chain liquidity is thin, a fixed price set to its 1:1 dollar peg may be well suited for mUSD, an approach already used on other Aave instances where the asset is listed as borrowable only. As a permissioned dollar stablecoin that redeems 1:1 for M (approximately one US dollar), mUSD is valued at a fixed price consistent with that peg, a conservative reference that does not depend on a live feed.
**Rating:** MEDIUM → given thin secondary on-chain liquidity, a fixed price set to the peg may be well suited, an approach used on other Aave instances for borrowable-only assets.
## 3. Access Control
mUSD uses OpenZeppelin AccessControl. The token’s role-administration and its logic-upgrade path are well-governed: the role-admin authority and the upgrade authority (the proxy admin) each sit behind a 72-hour timelock whose proposer, executor, and canceller are a 3-of-5 multisig, with no open public executor, so a logic upgrade or role change must pass a 72-hour delay behind a multisig. The token exposes an issuer freeze-and-seize capability: a freeze role can block any account from sending, receiving, wrapping, or unwrapping mUSD, and a forced-transfer role can then move a frozen account’s balance to another address. These two roles are held by single externally owned accounts, acting with no multisig and no timelock. This recovery and compliance capability is inherent to a permissioned, issuer-controlled stablecoin of this class and is accepted as a characteristic of the asset rather than a barrier to listing, though placing it behind a timelock or multisig is a recommended hardening. The controlling access-control concern is instead on the supply path: the operator and pause roles of the cross-chain route that mints Monad’s mUSD supply are held by a single externally owned account, so one key can re-point the route and halt bridging; this is carried into Section 6. mUSD mint and burn are gated to the M0 wrap-and-unwrap router (one mUSD minted per M deposited, burned per M withdrawn), and burning cannot reach an arbitrary wallet outside the forced-transfer path.
**Rating:** MEDIUM → the token’s role-admin and upgrade paths are well-governed (72-hour timelock behind a 3-of-5 multisig) and the freeze-and-seize capability is an accepted by-design control of this permissioned stablecoin; the residual item is that the supply-creating route’s operator and pause roles sit on a single externally owned account (see Section 6).
## 4. Exchange Rate and Yield
mUSD is yield-bearing at the protocol level, but the yield does not accrue to the token: it is diverted to a single designated recipient, so each mUSD is a fixed 1:1 claim on M (approximately one US dollar) and does not appreciate per token. The token exposes no exchange-rate method (there is no `convertToAssets` or `pricePerShare`), and the M held inside the contract reconciles to mUSD minted plus accrued yield owed to the recipient, so each mUSD remains fully 1:1 backed by M. Because mUSD does not appreciate, no Correlated-Asset Price Oracle (CAPO) adapter is required; Aave would price it as an approximately one-dollar stablecoin. The material caveat is redemption: mUSD is a permissioned extension of the M0 wrap-and-unwrap router, so only whitelisted swappers can unwrap mUSD back into M, and redeeming M to dollars is an off-chain process. A liquidator therefore has no permissionless on-chain redemption path and must sell mUSD on a DEX to exit.
**Rating:** MEDIUM → the 1:1 non-rebasing design is simple and needs no CAPO, but there is no permissionless redemption path, so a liquidator’s only on-chain exit is a DEX sale.
## 5. Token Architecture
mUSD on Monad is a single canonical deployment with no duplicate or legacy entry point to the same supply, and the underlying M is likewise a single canonical contract. Supply moves only through the wrap-and-unwrap router (mUSD) and the cross-chain mint and burn (the underlying M), with standard `Transfer` events emitted for observability. The token logic contains no `tx.origin` authorization and no `delegatecall` beyond the proxy’s own delegation to its implementation, and all privileged functions are access-controlled. The only transfer restriction is the targeted freeze, with the liquidation implication noted in Section 3.
**Rating:** GOOD
## 6. Bridge and Cross-Chain Risk
Monad’s mUSD supply integrity depends on a cross-chain route: M is minted on Monad by the M0 SpokePortal when it receives a message over Hyperlane from the Ethereum HubPortal. The model is hub-and-spoke: the HubPortal on Ethereum locks M (lock-and-release on the hub) and the SpokePortal mints and burns M on Monad with no local escrow. The Ethereum route is wired reciprocally, and the Ethereum hub lockbox is over-collateralised against Monad’s slice, holding roughly 87.31 million M against roughly 1.43 million M on Monad (the lock backs all spokes collectively). The residual items are as follows. The route does not pin its own message verifier (an Interchain Security Module, ISM); it falls back to Hyperlane’s shared default, which resolves to a 6-of-10 Hyperlane validator quorum that the issuer does not control and that Hyperlane can change under the route without the issuer’s consent. There is no rate limiter or cap on the mint path, so mint capacity is unbounded; for a borrowable-only listing this is acknowledged as acceptable, with a forged or erroneous inbound message bounded by message verification rather than an on-chain ceiling. The operator and pause roles on the route are held by a single externally owned account that can re-point which remote contract is trusted to authorise minting (`setPeer`) and halt bridging, with no timelock. The route also uses a single provider on Monad with no independent second transport. The bridge upgrade authority has been moved to a separate 3-of-5 multisig (an improvement), though without a timelock, while the operational route control that governs supply integrity remains on the single key.
**Rating:** MEDIUM → the mint path has no rate limit, acceptable for a borrowable-only listing, but a single-key operator can re-point the route and message verification rests on an issuer-uncontrolled default verifier behind a single provider, recommended hardening items.
## 7. Audit and Security History
Both the token and the cross-chain route carry multiple reputable audits with no open Critical or High findings. The mUSD token was reviewed by ChainSecurity (a clean report with no findings), with the wrapper base it inherits covered by a separate ChainSecurity review, alongside a ConsenSys Diligence review of the MetaMask USD token, a Guardian review, and an independent review that reported no security or economic findings and recommended a timelock between the token and the recovery (forced-transfer) controller. The M0 Portal cross-chain framework was reviewed by ChainSecurity (all Critical and High findings corrected, with the only items left open at report close being low-severity, risk-accepted points) and by four further firms (Adevar, Halborn, Sherlock, and Guardian). The deployed Monad implementations of the token, the portal, and the bridge adapter expose exactly the audited function surface and have not rotated since deployment, so there is no post-audit implementation swap. The residual item is that the Monad implementations are not source-verified on a public explorer, so a byte-for-byte match to the exact audited commits could not be completed. The Hyperlane transport itself sat outside the scope of the M0 Portal audits.
**Rating:** MEDIUM → the token and the cross-chain framework are covered by multiple reputable audits with no open Critical or High, but the deployed Monad implementations are not explorer-verified and so were not byte-matched to the audited commits.
## 8. Dependencies
mUSD rests on M0’s M token (the asset it wraps, minted on Monad only by the SpokePortal), the M0 wrap-and-unwrap router (which gates the permissioned redemption), the M0 Portal and its Hyperlane adapter (the cross-chain mint path, a single provider on Monad with a single-key operator and no rate limit), Hyperlane (the message layer, whose 6-of-10 validator set is Hyperlane-controlled and which sat outside the M0 audit scope), and the off-chain Treasury custody and redemption that ultimately back M. These dependencies are audited and in production, but the critical path concentrates on a single bridge provider with a single-key operator, relies on a transport layer outside the M0 audit scope, depends on off-chain peg backing that is not observable on-chain, and offers no permissionless redemption.
**Rating:** MEDIUM → the dependencies are audited and in production, but the supply path concentrates on a single bridge provider with a single-key operator and a transport outside the audit scope, the peg backing is off-chain, and redemption is permissioned.
## 9. Summary
### Findings table
Ratings in this table are plain text (Good / Medium / Critical / N/A), no icons.
| Area | Key finding | Rating |
|—|—|—|
| 0. Pre-screening | MetaMask USD on M0 at `0xaca92e…435da`, 6 decimals, roughly 1.43 million supply; distinct from the unrelated mStable USD (not on Monad); implementation never rotated but not explorer-verified on Monad. | Good |
| 1. ERC20 | Standard non-rebasing ERC20, 6 decimals; returns bool, no fee on transfer, no rebase, no hooks, no flash mint; only restriction is the targeted freeze. | Good |
| 2. Oracle | Given thin secondary on-chain liquidity, a fixed price set to the 1:1 dollar peg is well suited, an approach used on other Aave instances for borrowable-only assets. | Medium |
| 3. Access control | Role-admin and upgrade paths well-governed (72-hour timelock behind a 3-of-5 multisig); freeze-and-seize on single keys, accepted as a by-design issuer control; supply-creating route operator and pause on a single externally owned account (see Section 6). | Medium |
| 4. Exchange rate / yield | Non-rebasing 1:1 claim on M, yield diverted to a recipient, no per-token appreciation, no CAPO needed; no permissionless redemption, so liquidators exit via a DEX. | Medium |
| 5. Token architecture | Single canonical deployment, supply observable via standard events; no `tx.origin`, no `delegatecall` beyond proxy delegation; only the targeted freeze restricts transfers. | Good |
| 6. Bridge and cross-chain | M0 Portal over Hyperlane (mint-and-burn spoke off an Ethereum lock-and-release hub); hub over-collateralises Monad’s slice; no rate limit on mint (acceptable for borrowable-only), issuer-uncontrolled default verifier, single-key operator, single provider. | Medium |
| 7. Audit and security | Token and cross-chain framework covered by multiple reputable audits with no open Critical or High; deployed Monad implementations not explorer-verified, so not byte-matched to the audited commits. | Medium |
| 8. Dependencies | M0 M token, the wrap-and-unwrap router, the M0 Portal and Hyperlane adapter, Hyperlane (outside the M0 audit scope), and off-chain Treasury custody; single bridge provider, single-key operator, off-chain peg, permissioned redemption. | Medium |
## Disclaimer
Aave Labs has no formal or informal affiliation with MetaMask, M0, or the mUSD issuer beyond this technical assessment. Aave Labs has not been compensated by MetaMask, M0, or any related party in connection with this work.
## Copyright
Copyright and related rights waived via [CC0](Deed - CC0 1.0 Universal - Creative Commons).