MUSD (Mezo USD) — Long-form Analysis

A Liquity-v2-style, BTC-collateralized CDP stablecoin native to the Mezo chain, with per-trove interest, a protocol-owned stability backstop, and a non-inflationary cross-chain bridge.

1. Executive Summary

MUSD is a BTC-backed collateralized-debt-position (CDP) stablecoin deployed on Mezo mainnet (chainId 31612) and built by Thesis, the team behind tBTC, Keep, and Fold. It is a faithful fork of Liquity v2: users open troves collateralized by native BTC (the Mezo gas token), mint MUSD against them, and the system maintains the peg through redemptions, a StabilityPool backstop, and recovery-mode collateralization thresholds. At assessment time the supply was ≈ 29.4M MUSD. The on-chain core is competently engineered — checks-effects-interactions (CEI) is verified on every native-BTC payout, interest accounting is symmetric, and mint/burn authority is scoped exactly to the canonical Liquity system contracts with no public mint path.

The assessment assigns a security score of 60.0 / 100, grade B, risk level Medium. The deal-breaker gate clears with no failures (15 PASS, 7 N/A, 1 Inconclusive across the 23-item checklist). The grade sits in the B band — not higher — because of three structural governance and operational gaps rather than code defects: an untimelocked 5-of-9 Gnosis Safe with full upgrade and mint-list authority; a single chain-native BTC/USD oracle with no fallback and no value-sanity bounds on the read path; and deployed bytecode that post-dates the only public audit and is unverified on the Mezo explorer.

A trust-model caveat frames all three. The 5/9 Safe is operated by the Mezo/Thesis team — the same entity that already runs the chain’s validators, the BTC/USD oracle precompile, and the native bridge. The admin power therefore does not introduce a counterparty beyond the one a Mezo user already trusts; it concentrates app-layer authority into the same hands as chain-layer authority. The residual concerns are that concentration and the mechanism — a 5/9 key compromise with no timelock leaves no reaction window.

2. Protocol Overview

MUSD’s mission is to provide a BTC-native dollar on Mezo. The collateral asset is native BTC (the chain’s gas token), and the debt asset is MUSD, a non-upgradeable ERC20Permit + Ownable token. The token contract is deliberately minimal: minting and burning are gated to an explicit allow-list, and on-chain the only live minters are BorrowerOperations and InterestRateManager, with burners BorrowerOperations, TroveManager, and StabilityPool — exactly the canonical Liquity wiring. There is no public mint function.

The borrowing flow follows Liquity v2 closely. A user opens a trove through BorrowerOperations, depositing native BTC and minting MUSD up to the minimum collateral ratio (MCR 110%). Interest accrues per-trove through InterestRateManager, which tracks an interestNumerator that the assessment verified is added to and removed from symmetrically across open, adjust, close, and liquidation flows (no underflow). System solvency is defended by TroveManager liquidations and by redemptions, which let any holder swap MUSD for collateral at face value against the least-collateralized troves. A critical-collateral-ratio (CCR 150%) recovery mode tightens behavior under system-wide stress.

The StabilityPool is the first-loss backstop: depositors supply MUSD that is burned to absorb liquidated debt in exchange for discounted collateral. A protocol-owned component, PCV (Protocol Controlled Value), seeds a bootstrap loan (on the order of 100M MUSD of protocol-owned StabilityPool capital) and, in its V2 form, distributes BTC fees and a savings rate. The assessment confirmed PCV/governance fund movements operate on PCV’s own capital — StabilityPool.withdrawFromSP acts on deposits[msg.sender], so governance cannot pull user SP deposits or trove collateral.

Operator roles are concentrated in a single 5-of-9 Gnosis Safe (0x98D8…7C7a, Safe v1.3.0) that owns the token, the PriceFeed, the PCV, GovernableVariables, and every ProxyAdmin. There is no governance token and no on-chain voting. InterestRateManager renounces ownership after setup, and a separate BorrowerOperationsSignatures contract supports EIP-712 meta-transactions (deadline, per-borrower nonce, chainId-bound domain — verified sound).

Pricing comes from a single source: PriceFeed reads the Mezo “Skip” BTC/USD precompile (0x7b7c…0015), a Chainlink-compatible consensus oracle. Verified on-chain at assessment time, the precompile refreshes every block (~3s block time, measured staleness 0s, 18 decimals), so the 60-second staleness window is appropriately sized. Liquity’s Tellor fallback was removed, leaving no secondary source.

The deployment scope is Mezo-only for the native token: 15 core contracts (the token plus 14 transparent proxies), wired to the Skip oracle precompile and a Wormhole NTT bridge. A single Cantina audit (2025-04-15) predates the current PCV V2 code. Full addresses are in §9.

3. Findings

3.1 Untimelocked 5/9 multisig holds full upgrade and mint authority

The defining trust assumption in MUSD is governance concentration. A single 5-of-9 Gnosis Safe (0x98D8…7C7a) owns every ProxyAdmin and the MUSD token. There is no timelock anywhere between the Safe and the contracts it controls.

With those powers, the Safe can, in one transaction: upgrade BorrowerOperations to mint MUSD freely; upgrade ActivePool to drain BTC collateral; or call addToMintList to register an arbitrary address as a minter and issue unlimited MUSD. Each of these is a complete loss vector. Because there is no timelock, there is no public delay, no veto window, and no opportunity for holders to react before execution. Mitigation is purely operational: the 5/9 threshold and the team’s key custody.

The mitigating context is the trust-model collapse described in §1 and §5: the Safe is the Mezo/Thesis team, who already control the chain’s validators, oracle, and bridge. A Mezo user is already trusting that entity at the chain layer. What this finding adds is concentration — app-layer mint/upgrade authority sits with the same party as chain-layer authority, unlike a neutral L1 where the two are separated — and mechanism risk: a 5/9 multisig key compromise is a different and faster failure mode than a consensus failure, and the absence of a timelock removes any reaction window. The team’s identity is credited as a positive (a green flag), not folded into the access-control score, to avoid double-counting.

3.2 Single chain-native oracle with no fallback and no read-path sanity checks

PriceFeed consumes exactly one source — the Mezo Skip BTC/USD precompile — and Liquity’s Tellor backup has been removed. The read path performs a staleness check but no price > 0, negative-value, or deviation/bounds checks, and answeredInRound is always 0 (which is why the standard round-completeness check was intentionally dropped).

The original concern was an oracle-lag liquidation freeze, but on-chain verification softened it: because the precompile updates every block (~3s), the 60s staleness window does not brick the system under normal operation. A revert only occurs if the chain’s oracle module itself stalls — in which case freezing is the safe behavior. The genuine residual is garbage-in: a single bad or zero price from the chain oracle is consumed directly for minting and liquidation with no sanity guard (tracked as C-02). Trust ultimately rests on the Mezo chain’s oracle module / Skip sidecar — a chain-level assumption that is not verifiable from the EVM.

A sharpening detail: a richer Pyth oracle (including an MUSD/USD feed) already exists on Mezo at 0x2880…7B43 and could serve as a fallback, but PriceFeed does not use it. The fix surface is therefore well understood — add a fallback plus deviation/circuit-breaker bounds — and is recommendation territory, not a deal-breaker.

3.3 Deployed code post-dates the only public audit and is unverified on-chain

Cantina audited MUSD on 2025-04-15, but the repository HEAD is a PCV V2 upgrade (May 2026, reinitializer(2)) that adds new BTC fee-distribution, distributor, and savings-rate logic. The deployed bytecode is unverified on Blockscout, so source-to-bytecode equivalence is assumed (review relied on the official GitHub repo), and the V2 delta has no confirmed re-audit.

The impact is epistemic rather than a concrete exploit: “audited” and “deployed” cannot be proven to be the same code, and the newest, most complex logic (fee distribution and savings rate) is precisely the part with the least external review. This drives the largest single score drag — Code Quality & Verification scored 39.0 (Contract Verification = 0) — and a -5 red flag for post-audit modification without confirmed re-audit. The assessment notes that confirming a V2 review and verifying bytecode would remove the red flag and lift the final score to roughly 65.

The softening context: the source is public and open, the team is doxxed and actively developing, and static analysis (Slither) over the project source returned 0 High / 0 Medium / 3 benign Low. So the unverified-bytecode gap is about provenance and re-audit coverage, not evidence of a defect.

3.4 Economic design weakened by a fixed redemption fee

The core CDP collateralization is sound — MCR 110% / CCR 150% with recovery mode, and a large protocol-owned StabilityPool backstop. The economic-design concern (C-03) is that the redemption fee appears to be fixed by governance rather than using Liquity’s dynamic base-rate spike-and-decay. A dynamic base rate makes redemptions progressively more attractive as the peg slips, pulling MUSD back toward $1; a fixed fee weakens that peg-restoration force under a sustained depeg. The practical constraint on exit is also liquidity depth: native-Mezo trading venues for MUSD are thin relative to the ~$29M supply.

3.5 Bridge cannot inflate native supply

The Wormhole NTT Manager on Mezo (0x7efb…e0bD) runs in locking mode — it holds roughly 1.2M MUSD in custody and is not on the mint or burn lists. Cross-chain bridging therefore cannot mint native MUSD; canonicality is enforced by the off-chain NTT lock/mint invariant. Wrapped MUSD on Ethereum and Base is a separate deployment and out of scope here. This is a positive finding: the bridge surface, often a source of inflation risk, does not threaten native supply integrity. Wormhole guardian trust applies only to the wrapped representations on other chains.

4. Deal Breaker Analysis

The framework’s deal-breaker gate is a fixed 23-item checklist; any FAIL halts the assessment with a Fail outcome. MUSD clears the gate with 15 PASS, 0 FAIL, 7 N/A, and 1 Inconclusive.

4.1 Access Control & Governance

4.2 Oracle & Price Integrity

4.3 Smart Contract Architecture

4.4 Audit & Verification

4.5 Economic & Liquidity

4.6 Cross-Chain & Bridges

5. Trust & Permissions

Authority concentrates almost entirely in one 5-of-9 Gnosis Safe.

Two observations follow. First, the dominant trust risk is the no-timelock upgrade/mint path, not any single contract. Every powerful lever — implementation replacement, mint-list mutation, oracle repointing — resolves to the same multisig with zero delay. The system has strong intra-protocol boundaries (PCV cannot reach user funds, the bridge cannot mint) but no temporal boundary on the admin itself.

Second, the trust posture is best understood as a single “trust the Mezo team + chain” bet rather than an independent extra risk. The same Safe already governs the validators, the oracle precompile, and the bridge; a user transacting on Mezo is already exposed to that party. The improvements that would most resolve the dominant risk are mechanical: a timelock on the ProxyAdmin owner (introducing a reaction window) and caps or delays on mint-list additions. Either change would materially shrink the blast radius of a key compromise without altering the protocol’s economics.

6. Architecture Notes

6.1 Upgrade pattern

The token is non-upgradeable (immutable Ownable ERC20Permit); all other core contracts are transparent upgradeable proxies whose ProxyAdmins are owned by the Safe. The PCV proxy is on its V2 implementation via reinitializer(2). The assessment verified the V2 storage layout is append-only (five new fields appended after the original storage, no collision), which is the correct pattern, though no migration tests or storage-layout tooling were available in the reviewed snapshot.

6.2 Oracle integration

PriceFeed wraps the Skip BTC/USD precompile (0x7b7c…0015), which implements latestRoundData() and decimals() (returning 18); description() and version() revert. Verification on-chain confirmed per-block updates with updatedAt == block.timestamp and zero measured staleness, validating the 60s window. The gap is the absent fallback and the missing read-path value checks (§3.2). The unused Mezo Pyth feed is the obvious fallback candidate.

6.3 Reentrancy and locking

The strongest category (Smart Contract Security scored 80.25, A−). Every native-BTC payout path — closeTrove, withdrawColl, redeemCollateral, StabilityPool withdrawals, gas compensation, and CollSurplus claims — updates state before the external .call{value}, with no double-spend or read-only reentrancy. mintBootstrapLoanFromPCV is single-trigger (guarded by PCV isInitialized). The PCV layer adds explicit nonReentrant guards for its semi-trusted recipients.

6.4 Interest and PCV mechanics

Interest accrues per trove through a scaled interestNumerator that is added and removed symmetrically across all flows — the assessment confirmed no underflow path. The PCV bootstrap loan provides a protocol-owned StabilityPool backstop, and the V2 distributor streams BTC fees and a savings rate. Crucially, all PCV/governance fund operations act only on PCV’s own capital; user StabilityPool deposits (deposits[msg.sender]) and trove collateral are out of reach.

6.5 Aggravating factors beyond the deal breakers

• No timelock anywhere on the admin path — the single most consequential non-breaker (§3.1).
• Non-standard token behavior: MUSD transfer/transferFrom revert on to == address(this) (D-2), which can break naive integrators.
• GovernableVariables is the one implementation missing _disableInitializers() (D-1); low impact behind a proxy.
• PCV withdraw* functions lack nonReentrant, and a malicious feeRecipient could DoS distributeMUSD (B-2/B-3) — griefing-class, limited.
• Off-chain dependency: the oracle’s operator set and the bridge’s lock/mint invariant are chain-level assumptions not verifiable from the EVM.

7. Open Issues

Eight issues are surfaced for the protocol team. Priorities reflect engineering urgency for the maintainers, not a position on the protocol from this site’s perspective.

7.1 P1 — within 1 month

1. Untimelocked 5/9 Safe can mint or upgrade to drain (A-1/A-2). High, Access Control. Latent total loss if the multisig is compromised or malicious. Recommendation: add a timelock to the ProxyAdmin owner; cap and/or timelock mint-list additions.
2. Deployed code post-dates the Cantina audit; bytecode unverified (RF). High, Code Quality. Audited code is not provably deployed; the PCV V2 delta carries unknown risk. Recommendation: re-audit the V2 delta and verify the deployed bytecode on the explorer.

7.2 P2 — within 3 months

3. Single chain-native oracle, no fallback, no sanity bounds (C-01). Medium, Oracle. Per-block updates keep the staleness window safe, but a single bad/zero price is trusted directly and a chain oracle stall freezes the system. Recommendation: add a fallback (e.g. the Mezo Pyth feed) plus deviation/circuit-breaker bounds.
4. fetchPrice lacks a price>0 / round-completeness check (C-02). Medium, Oracle. A zero or negative answer would mis-price collateral or disable liquidations. Recommendation: add value and round-completeness guards on the read path.
5. Fixed redemption fee with no dynamic base-rate decay (C-03). Medium, Economic. Weaker peg-restoration force under a sustained depeg. Recommendation: restore the dynamic base-rate mechanism.
6. MUSD transfer reverts on to==address(this) (D-2). Low, Dependencies. Integration/composability breakage. Recommendation: document the deviation and assess integrator impact.
7. GovernableVariables missing _disableInitializers() (D-1). Low, Code Quality. The implementation can be initialized (low impact behind a proxy). Recommendation: add a constructor disable for consistency.
8. PCV withdraw* lack nonReentrant; malicious feeRecipient can DoS distributeMUSD (B-2/B-3). Low, Smart Contract. Griefing/limited DoS. Recommendation: add guards and validate the feeRecipient.

8. Audit History

A single engagement with a top-tier firm (Cantina) is meaningful but does not reach the “3+ audits” bar, and — critically — it predates the deployed PCV V2 code. Cantina’s contest-and-review model surfaces a broad class of issues, but a 2025 scope cannot speak to 2026 logic. The provenance gap in §3.3 (unverified bytecode plus an unaudited V2 delta) is the practical consequence. The report PDF is linked from the dashboard’s Audit History section.

9. Contract Inventory

Deployed bytecode is unverified on the Mezo Blockscout explorer for all core contracts; review relied on the official mezo-org/musd GitHub source.

The Safe owner is 0x98D8899c3030741925BE630C710A98B57F397C7a (5/9, v1.3.0). A Mezo Pyth feed (including an MUSD/USD price) exists at 0x2880aB155794e7179c9eE2e38200202908C17B43 but is not wired into PriceFeed.

10. References

• Documentation — https://mezo.org/docs/users/musd/
• Source — https://github.com/mezo-org/musd
• Audit report (PDF) — Cantina 2025-04-15, linked from the dashboard’s Audit History section
• Explorer — https://explorer.mezo.org
• Structured, filterable view — see the protocol dashboard

Long-form companion to the dashboard. Descriptive technical analysis only — not financial advice.