Risk

PCV.owner(), PriceFeed.owner(), and MUSD.owner() all resolve to the same Gnosis Safe, 0x98D8899c3030741925BE630C710A98B57F397C7a. That key can upgrade implementations, swap the oracle, and modify mint/burn lists. council() and treasury() both return the zero address, so effective control sits with a Thesis/Mezo multisig. Mezo documents immutability as a later-stage goal, so this is a disclosed choice. Maren cannot mitigate it, only disclose it, and avoid compounding it. Maren's own contracts take the opposite trade-off: they are not upgradeable at all — no proxy, no initialize, no admin implementation slot — so no key can change their logic. The cost of that choice is that a deployed bug is fixed only by deploying a new contract and migrating users, which is why the deployed vault still predates its own redemption reconciliation.

Total supply is roughly 30.55M (measured 2026-09-07; it moves, so re-read it rather than citing this). Trove-backed debt is roughly 1.60M, plus an outstanding PCV bootstrap loan of roughly 14.97M. The remainder sits in protocol-owned strategies and the Wormhole NTT bridge. "100% Bitcoin-backed" is true of the CDP portion but not of most circulating MUSD today. Maren does not repeat a blanket backing claim.

The docs state a borrower with an outstanding loan pays a zero redemption fee; isAccountFeeExempt appears only in BorrowerOperations, never in TroveManager, which applies the redemption rate unconditionally. Maren does not promise this waiver. The docs list the refinance fee as 0.1%; the code computes roughly 0.02% of old net debt. Maren follows the bytecode.

Not mitigated, and meant to be read as a single point of failure. liquidateUser is onlyRole(KEEPER_ROLE) by design: an open liquidation market pays the liquidator to push users over the line, so Maren runs it at cost and the 5% penalty goes to the insurance buffer rather than to the caller. The consequence is that if the keeper does not act, nobody else can. The keeper process is still not built as automation, and on matsnet KEEPER_ROLE is held by a single operator key. Keeper actions have now been run by hand in production: the trove refinance of 22 September 2026 in the incident log below was executed by an operator with tools/ops/refinance-trove.mjs. A human with a keystore is not a keeper; nothing watches the trove between those runs. Exits stay open regardless — withdraw, repay and closePosition carry no pause modifier — so a dead keeper cannot trap collateral outside the frozen state described in R-1. If the keeper halts, borrowing stops; withdrawals do not.

A full compromise of the relayer key costs Maren its BTC gas float and nothing else. The relayer is never an owner, approver, or custodian. It relays only to allowlisted Maren contracts, only for allowlisted selectors, and derives the payer from the recovered signature, not any client field. At Mezo gas prices a 100,000-gas transaction costs about $0.0092.

Full unit and fuzz coverage; invariant tests asserting the vault's per-user ledger cannot drift from the trove's real debt, with any rounding error required to fall in the protocol's favour; fork tests against the real MUSD contracts on matsnet. MarenVault and the forwarder are the audit scope.

Per-address and per-IP rate limits, a global daily BTC spend cap that halts relaying, and a 25-action free tier after which a fee is taken in-band in MUSD. Exhaustion returns a typed error, never a silent fallback that spends Maren's money.

Commit-reveal registration prevents front-running, [a-z0-9_] eliminates homoglyph attacks, and the payment interface shows the resolved address alongside the handle before any confirmation. Squatting itself is not mitigated. Registration is free and unpriced, so nothing stops one party committing to many names up front; pricing and renewals belong in a layer above MarenRegistry and are not built. The mitigation today is that a handle is a convenience label and the resolved address is always shown before any signature.

No third-party analytics anywhere in the app, and transaction simulation with a human-readable summary before every signature.

Not yet implemented: a strict Content-Security-Policy and subresource integrity. next.config.ts sets no security headers today. Both are mainnet gates, not shipped controls.

The borrow-ceiling defect recorded here is fixed in the shipped clients. borrowCeiling() in packages/sdk/src/borrow.ts now subtracts the whole trove's debt — gas compensation and accrued interest included — from Mezo's maxBorrowingCapacity, grosses the result up for the 0.1% origination fee, and additionally clamps to the pooled trove's headroom against the 180% floor. Both apps bound the slider by that figure, so "Max" no longer quotes an amount the protocol will refuse. The on-chain maxBorrowable() getter is unchanged and remains pool-blind by design — see Borrow for why a reviewer calling it directly still sees a higher number.

A liquidation of the pooled trove is not only a pro-rata loss. When the trove leaves Mezo's active set, every mutation on the vault reverts — deposit, borrow, repay, withdraw, close, and every admin function except skim() and the pause switches. Collateral the protocol did not take sits in Mezo's CollSurplusPool, and MarenVault never calls claimCollateral, so it cannot be reached. Idle BTC held in the contract that never entered the trove is frozen alongside it, even though paying it out needs no trove, no oracle and no protocol call. There is no admin recovery path: closePooledTrove syncs state first and so reverts in exactly that state.

Freezing is the deliberate choice — paying claims first-come-first-served after a shortfall is worse — but the honest description is everyone is locked out until a wind-down mechanism is designed, deployed and migrated to, and that is a governance decision that does not exist yet. Letting a debt-free account withdraw from idle collateral while frozen is the minimal fix and is not built.

Earn deposits MUSD into Mezo's Stability Pool. Cantina's mUSD audit §3.4.7 establishes — and Thesis explicitly agreed, marking it Acknowledged rather than fixed — that Stability Pool liquidations can be unprofitable: absorbing a trove whose ratio has fallen below about 100% returns depositors less value than the debt burned against them. A passive depositor, which is exactly what Earn is, takes that loss. A liquidation large enough to consume the pool zeroes deposits outright through the epoch mechanism. This is not a bug in Maren; it is what the Stability Pool is.

Two Maren-side gaps compound it. maxWithdraw and maxRedeem are not overridden, so the figure the app shows can exceed what the pool will actually pay. And BTC liquidation gains are counted in totalAssets() at the oracle price while swapRouter is address(0), so there is currently no path converting that BTC back to MUSD. Fixing both is a prerequisite to Earn holding real money.

Mezo's Stability Pool refuses every non-zero withdrawal while any trove on the whole chain sits below 110% ICR — the string is in the deployed bytecode verbatim: StabilityPool: Cannot withdraw while there are troves with ICR < MCR. This is precisely the moment a depositor most wants out, it is caused by a stranger, and no Earn depositor can clear it. Maren does not yet decode this revert, so today it surfaces as a generic failure.

Maren's contracts are not upgradeable, so no key can change their logic. Three roles still carry real power. DEFAULT_ADMIN_ROLE can raise or zero either deposit cap, set an Earn performance fee up to 20% effective immediately, point Earn's harvest at an arbitrary swap router, pull Earn out of the Stability Pool, and grant itself every other role. KEEPER_ROLE liquidates users under 140% and manages the pooled trove. GUARDIAN_ROLE pauses deposits and borrowing — and only those: withdraw, repay, closePosition and liquidateUser carry no pause modifier, so no guardian key can trap collateral, pinned by test_exitsWorkWhilePaused. MarenPay, MarenRegistry and MarenForwarder have no privileged functions at all.

MarenRelayHub's RELAY_ADMIN_ROLE can allowlist any target contract, not only Maren's — the contract enforces "allowlisted", not "Maren". Combined with the absence of a fee-token allowlist on executeWithFee, that key is more powerful than the relayer key in R-5.

Today all of these are held by one externally owned account on matsnet. No multisig, no timelock, no separation of duties. Only testnet funds are exposed. Splitting the roles across a Safe with a timelock is a hard mainnet gate.

On Mezo a trove's maxBorrowingCapacity is frozen at the BTC price the trove was opened at. Adding collateral does not raise it; refinance() is the only thing that does. A pooled trove held across a BTC rally therefore walks into a ceiling that has nothing to do with how well collateralised it is, and when the trove's debt reaches it every borrow reverts for every pooled user at once, however healthy their own position.

This is not hypothetical: it happened on 22 September 2026, and the incident log below gives the timeline. Nothing detects or clears it automatically today. MarenVault.refinancePooledTrove is deployed and works, but calling it is a manual keeper step, so the failure recurs the next time BTC moves far enough. Deposits, repayments and withdrawals are unaffected when it happens, which is the same direction as R-4: borrowing pauses, exits do not.