# Security Design
Operational Security — logic is fully automated and hardcoded on-chain
{% hint style="info" %} **TL;DR for LPs** **What it is:** USDC deposits are minted into USDM and allocated into a transparent delta-neutral portfolio on Hyperliquid: USDC reserve, spot BTC/ETH/HYPE, and matching short perp hedges. **Main risks:** smart contract risk, Hyperliquid venue risk, hedge execution risk, funding-rate variability, liquidity and redemption risk, and operational risk. **External dependency:** Hyperliquid is the primary platform dependency. There is no CEX execution path. **Verification goal:** make backing, hedge, margin, and allocation data visible and measurable in real time, so LPs do not have to rely on a black-box strategy. {% endhint %} Monetrix takes USDC deposits, mints USDM, and allocates the backing capital into a transparent delta-neutral portfolio on Hyperliquid. The goal of this page is to make the protocol's risk surface explicit, not to claim it away. Beyond the [Anti-ADL Shield](/risk-and-security/anti-adl-shield.md), the security model rests on four layers: an external audit program, fully automated on-chain logic, dynamic risk-aware allocation, and conventional smart contract hardening, plus a transparency layer that lets LPs verify backing and hedge state at any time. ## 1. Audit program ### Code4rena (C4) competitive audit Monetrix's core contracts are reviewed through a [Code4rena (C4)](https://code4rena.com) competitive audit. C4 puts the codebase in front of a large pool of independent security researchers competing on the same scope, which complements the depth of a single-firm engagement with breadth of perspective. * **In scope.** USDM, sUSDM, `MonetrixVault`, `MonetrixConfig`, strategy execution modules, access control, and emergency paths. * **Outcome.** All findings within scope are triaged, severity-rated, and either fixed before mainnet or explicitly acknowledged with mitigations. * **Report.** The final C4 report and the remediation log will be linked here as soon as the audit closes. ### Additional review and bug bounty * **Tier-1 firm review** scheduled pre-mainnet, recurring post-mainnet on every material upgrade. * **Ongoing bug bounty** after launch, with severity-scaled payouts to give researchers economic incentive for responsible disclosure. * **Dedicated insurance fund** sized to absorb black-swan funding events and bridge temporary hedge imbalances, funded from protocol reserves. ## 2. Fully automated, on-chain logic * All protocol logic (position management, rebalancing, sUSDM rate updates, HLP allocation) is hardcoded on-chain. * No off-chain keeper is required for correctness. * No admin action is required for normal operation. * No CEX API, no off-chain oracle, no manual intervention. This is the structural difference from CEX-dependent synthetics. When execution is off-chain, users must **trust** the operator. When execution is on-chain, users **verify**. ## 3. Dynamic HLP rebalancing Monetrix doesn't set a static allocation between hedging capital and HLP. The allocation floats based on market conditions. * **When funding is high:** more capital on the hedge side, less in HLP. * **When funding compresses:** more capital shifts into HLP to maintain the yield floor. * **During extreme volatility:** allocation tilts toward conservative positioning to reduce liquidation and ADL risk. This keeps the protocol out of the "all eggs in one basket" trap that hurts single-source delta-neutral vaults. A protocol that's 100% committed to one yield engine breaks when that engine breaks; Monetrix shifts weight before that happens. ## What you can verify on-chain Backing capital lives in three buckets, all visible on-chain: * **USDC reserve.** Operational liquidity supporting redemptions, rebalancing, and risk buffers. * **Spot positions.** BTC, ETH, and HYPE held as backing. Not directional bets; each spot exposure is paired with an equivalent short perp. * **Short perpetual hedges.** Opened against each spot exposure to neutralize price movement and capture funding when available. The key portfolio metrics are public Hyperliquid state, so LPs and integrators can monitor the system at any time: * USDC reserve balance * Spot position balances * Short perpetual hedge sizes * Hedge ratio * Net delta exposure * Margin health * USDM outstanding * Backing ratio * Strategy PnL and funding performance This is the practical meaning of "not a black box": every input to the backing claim is a public on-chain value, not a self-reported number. ## Risk framework Monetrix is not risk-free. The goal is to make each risk explicit and continuously measurable. ### Smart contract risk Risk concentrates around deposit and withdrawal logic, USDM mint and redeem accounting, access control, strategy execution permissions, and emergency controls. Mitigations: external audit before mainnet, ongoing bug bounty, and phased TVL caps during the initial deployment period. Audits and bounties reduce but do not eliminate this risk; size your position accordingly. ### Hyperliquid venue risk Hyperliquid is the primary external platform dependency. There is no additional CEX in the execution path, which removes one class of counterparty risk, but it concentrates dependency on a single venue. The risk surface includes execution, the margin system, oracle and mark price, the liquidation engine, infrastructure downtime, and liquidity under stress. The protocol inherits Hyperliquid's security properties; it does not stand above them. ### Hedge execution risk The strategy depends on keeping spot and short perpetual positions matched. The relevant failure modes are hedge ratio drift, execution slippage, insufficient perp liquidity, funding-regime changes, and rapid market moves arriving faster than rebalancing. The [Anti-ADL Shield](/risk-and-security/anti-adl-shield.md) addresses the most acute version of this, being force-closed by Hyperliquid's ADL mechanism, through queue-rank monitoring, automated re-open, and rolling queue hygiene. Net delta, hedge ratio, and margin health are monitored continuously. ### Funding-rate risk Yield is strategy-driven and market-dependent. Funding rates can decline, turn negative, become asset-specific, or shift quickly under stress. Dynamic HLP rebalancing and the four-source yield composition (see [Yield Composition](/yield/composition.md)) are designed to hold the floor when funding compresses, but **Monetrix does not offer a fixed yield**. ### Liquidity and redemption risk A portion of assets is deployed in active positions. In normal conditions, redemptions are supported by reserves and routine position unwinds. Under stress, expect wider spreads, slower unwinds, higher slippage, and potentially temporary redemption constraints. Reserve buffers, TVL caps, and phased onboarding are the launch-period mitigations. ### Operational risk Risk arises around rebalancing execution, monitoring systems, keeper reliability, and emergency response. Defined roles, monitoring, and incident procedures cover rebalancing, margin health, and abnormal market conditions. As more logic moves on-chain over time, the surface narrows. ## Governance and parameters Early-stage parameters (fees, allocation bounds, ADL thresholds, TVL caps) are set conservatively and documented on-chain. Over time, these will migrate to governance. Current parameter values and any proposed changes will be disclosed on this page. ## Reporting a vulnerability Responsible disclosure details will be published at mainnet launch. If you believe you've found a critical issue before then, reach out via the channels on the [Resources](/resources/resources.md) page. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.monetrix.xyz/risk-and-security/security-design.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.