Risk Management
Overview
Risk management is central to the integrity and longevity of the Mynt (USDm) protocol. As an over-collateralized CDP stablecoin system inheriting Ethereum's security, USDm is exposed to multiple categories of risk—both internal and external. The protocol is designed with built-in mitigations, layered security, and modular control mechanisms to reduce exposure to loss, depegging, or insolvency.
8.1 Risk Categories
A. Collateral Risk
• Volatility: If collateral assets like MON, aprMON, or shMON suffer a sharp price drop, vaults may become undercollateralized.
• Liquidity: Some assets may lack deep markets, making liquidation inefficient or slow.
• Derivative Depegs: Liquid staking tokens (LSTs) may trade below their underlying due to validator risk or liquidity crises.
Mitigations:
• Security Operators and the Liquidity threshold
• Conservative LTVs and liquidation thresholds
• Dynamic debt ceilings per asset
• Strict listing criteria and oracle integration
B. Oracle Risk
• Incorrect Price Feeds: Malfunctioning or manipulated oracles could misrepresent asset prices.
• Delayed Updates: Stale prices may prevent timely liquidations or enable minting under false conditions.
Mitigations:
• Primary reliance on Pyth Network, which uses high-frequency publisher data
• Confidence interval checks and staleness thresholds
• Potential for fallback oracles (e.g., RedStone or TWAP modules)
C. Smart Contract Risk
• Exploits and Vulnerabilities: Bugs in the vault system, liquidation logic, or oracle handling could be exploited.
• Upgrade Bugs: Faulty contract upgrades could introduce unexpected behavior.
Mitigations:
• Formal third-party audits pre-launch and post-launch
• Modular, well-reviewed architecture
• Upgradeability only via secure multisig
• Bug bounty programs (to be launched)
D. Liquidation Risk
• Underperformance: Poor incentives or oracle lag can delay liquidations, risking bad debt.
• Auction Congestion: In volatile markets, too many liquidations at once may cause a cascade.
Mitigations:
• Instant liquidations (vs. slow auctions)
• Liquidation bonuses and gas subsidies for liquidators
• Partial liquidation architecture
E. Governance or Admin Risk
• Multisig Compromise: Keys controlling core parameters could be compromised.
• Parameter Misconfiguration: Errors in setting LTVs, penalties, or ceilings could destabilize the system.
Mitigations:
• Secure Gnosis Safe multisig with trusted signers
• All actions are on-chain and publicly verifiable
• Gradual decentralization plan to reduce reliance on multisig over time
F. Stablecoin Peg Risk
• Depegging: USDm may trade off-peg due to market imbalance, liquidity issues, or mass liquidations.
• Low Liquidity: Poor market depth can cause volatility in USDm price.
Mitigations:
• Threshold maintainance.
• Peg arbitrage via mint/burn flows
• Protocol-Owned Liquidity (PoL) pools seeded at launch
• Dynamic stability fees (future upgrade)
8.2 System-Wide Monitoring
The protocol will monitor:
• Vault health across all collateral types
• Total protocol-wide collateral ratio
• USDm minting pressure
• Oracle deviation logs
• Pending and ongoing liquidations
This monitoring will be automated via subgraphs or indexers and exposed via a public dashboard.
8.3 Emergency Measures (Safeguards)
The protocol includes emergency mechanisms to defend against extreme events:
• Mint Pause: Temporarily disable new minting
• Oracle Override: Set fixed prices if oracles are attacked
• Vault Freeze: Halt operations for specific collateral types
• Safe Mode: Restrict redemptions or vault access in the event of protocol breach
These actions are tightly scoped and only callable by multisig under strict thresholds.
Last updated