HIP-3 Staking Maintenance Rate Guide: From Parameter Configuration to Risk Control Execution

Hyperliquid has implemented a new decentralized approach in the perpetual contract market through HIP-3 (Hyperliquid Improvement Proposal 3), which has been live on the mainnet for about three months. Third-party developers can deploy their own markets on its unified trading and clearing infrastructure, with total third-party market trading volume surpassing $13 billion. This innovation significantly lowers the barrier to entry but also introduces new security risks. Among them, the management of staking maintenance ratios becomes a key factor in determining whether the market can operate stably over the long term.

For Builders, staking is not only an “access ticket” to enter the market but also a framework of economic incentives and risk sharing. Through staking and maintenance ratio constraints, HIP-3 fosters open innovation while establishing a accountable risk control boundary.

HIP-3’s Staking Mechanism and Maintenance Ratio Framework

HIP-3 is built on Hyperliquid’s dual-layer architecture: HyperCore (a customized L1 chain optimized for contract trading, capable of processing 200,000 orders per second) and HyperEVM (an application layer compatible with EVM). The core advantage of this architecture is that order matching, liquidation, and settlement are provided uniformly by the protocol base, allowing Builders to reuse this high-performance engine without building from scratch.

Economic Significance of Staking

In HIP-3, Builders are required to stake 5 million HYPE tokens. This stake has three implications:

1. Access Control: Staking is a prerequisite for market deployment, ensuring participants have sufficient economic commitment.
2. Risk Sharing: If the market operates improperly, the stake may be penalized or confiscated, aligning Builder interests with user protection.
3. Maintenance Ratio Constraint: The scale of staking directly determines the number of markets a Builder can deploy and the risk capacity they can support.

Direct Relationship with Maintenance Ratio

The staking maintenance ratio (Maintenance Margin Ratio) relates to the size of the stake: it acts as a “risk buffer capital” for the Builder’s markets. When anomalies occur (such as price de-pegging, liquidity withdrawal, or liquidation gaps), this stake becomes the last line of accountability and compensation.

Validators decide whether to penalize or confiscate a Builder’s stake through stake-weighted voting. Conditions triggering penalties include:

• Causing market invalidity or prolonged downtime: up to 100% of the stake can be penalized
• Short-term downtime or performance degradation: up to 20%-50%
• Price manipulation due to private key theft: same penalty risks apply

This design essentially binds operational responsibility with economic interests—higher maintenance ratios mean more risk buffers, but once triggered, the losses borne by the risk taker are greater.

Stake Lock-up Period

Even if a Builder ceases operation of all their deployed markets, the stake remains locked for 30 days before it can be unlocked. This means risk responsibility does not immediately end with market suspension—if new security issues or user disputes are discovered during the suspension, the stake may still be frozen or penalized.

Parameter Settings and Maintenance Ratio Constraints in Market Operations

Once a market is deployed, the Builder must configure parameters to maintain market stability. These settings directly influence the conditions triggering liquidations and the scale of liquidation risk, thereby affecting the actual pressure on the staking maintenance ratio.

Oracle and Pricing Mechanisms

Builders need to continuously input three types of prices via the setOracle interface:

• oraclePx (mandatory): the asset’s benchmark price, used for funding rate calculations
• markPx (optional): 0-2 external mark prices
• externalPerpPx (mandatory): the weighted median of the mid-prices of multiple CEX perpetual contracts, serving as a de-pegging reference

The system ultimately uses the median of the local order book price and the submitted markPx as the final mark price. To prevent price manipulation, two hard constraints are set:

• Update Frequency Limit: at least 2.5 seconds between calls; if not updated for 10 seconds, it automatically reverts to the local mark
• Volatility Limit: each markPx fluctuation is limited to ±1%, and all prices are clamped within 10 times the opening price of the day

These constraints effectively protect the Builder’s stake—by limiting the scope for manipulation, they reduce the risk of penalties or confiscation.

Leverage and Margin Table Configuration

Builders define a margin table to constrain maximum leverage. Margin tables are typically tiered based on position size, with different tiers requiring different maintenance margin requirements.

For low-liquidity markets, setting excessively high leverage limits can trigger ADL (Auto-Deleveraging) more easily. For example, if a market has a daily volume of only $10 million but is configured with 20x leverage, once open interest (OI) reaches a critical point, any price fluctuation could rapidly trigger liquidations, causing gaps and ADL events.

Switching the marginTableId suddenly effectively modifies the maintenance margin ratio for all user positions at once, potentially turning safe accounts into liquidatable ones and causing chain reactions of liquidations. Such operations carry significant risk; if systemic liquidation occurs, the Builder’s stake faces heavy penalties.

Market Halt and Forced Settlement

Builders have the haltTrading permission, allowing them to suspend trading, cancel all orders, and forcibly settle all positions at the current mark price. While seemingly a risk management tool, improper use can amplify losses.

In extreme scenarios: if an attacker opens large short positions and manipulates prices maliciously, invoking haltTrading will settle positions at the mark price, effectively realizing the attacker’s unrealized gains. If the attacker lacks sufficient liquidity to find counterparties, the forced settlement results in a loss that becomes a bad debt for the system.

Such events will directly lead to penalties or confiscation of the Builder’s stake, as validators will vote to recognize that the Builder’s actions caused market invalidity and user losses.

Oracle Risks and Their Relationship with Maintenance Ratios

Oracles are the lifeblood of HIP-3 market pricing. Builders typically deploy independent relayer nodes to feed prices, but multiple risk points exist.

Pricing Differences for 24/7 Assets vs. Non-24/7 Assets

For assets like BTC traded 24/7, external prices from CEX/DEX sources are relatively continuous and stable. The Builder’s oracle mainly aggregates multiple trusted sources, deduplicates, and filters anomalies, which is less complex.

For non-24/7 assets like stocks, the situation is more complex. During market hours, Builders can rely on external oracle services like Pyth. During off-hours (night, weekends), external liquidity disappears, and Builders must use special internal pricing mechanisms: based on the last closing price plus internal order book pressure, with the mark price limited within ±10% of the last close (assuming 10x leverage).

The risk here is that when markets reopen, the external spot price may jump significantly from the internal off-market price. For example, a stock’s CFD price over the weekend might be 8% higher than the previous Friday’s close, but the internal mark price remains near the last close due to the ±10% cap. When the market reopens, the system must re-anchor to the external price, potentially causing large re-pricing and cascade liquidations.

This scenario also pressures the Builder’s stake, as users may blame the internal pricing mechanism during off-hours for mispricing and subsequent liquidations.

Centralization Risks of Oracle Relays

If the relayer servers operated by the Builder are attacked via DDoS or their private keys are leaked, the market’s oracle prices can be maliciously manipulated or remain de-pegged for extended periods. Once detected, the Builder’s stake faces immediate penalty risk.

Real-Time Monitoring: Dynamic Adjustment Strategies for Maintenance Ratios

While HIP-3 provides Builders with significant parameter configuration autonomy, the system also offers tools for dynamic adjustment. Understanding how to use these tools is critical for maintaining stake safety.

Price-Side Monitoring

1. Oracle Feed Failure: If relayer nodes are blocked, and two setOracle calls exceed 10 seconds apart, the system automatically reverts to the local mark price. Builders should immediately switch to backup relayers and report health status to validators. If the disruption persists, consider lowering open interest caps via setOpenInterestCaps to prevent new positions from amplifying risks during de-anchoring.

2. Price De-pegging: Monitor deviations between markPx and multiple CEX perp mid-prices:

   • Level 1 warning: deviation ≥3%, trigger setOpenInterestCaps to lower OI limits
   • Level 2 warning: deviation ≥5% sustained over 30 seconds, gradually reduce max leverage in margin table, enable clamp mechanisms
   • Level 3 warning: sustained high deviation, consider invoking haltTrading to suspend the market

Order Book Side Monitoring

1. Liquidity Withdrawal: Monitor real order volume, spread, and taker volume within a ±3% price band. When depth declines while spread and taker volume increase, risk level rises. Adjust open interest caps accordingly.

2. Fake Orders: Detect patterns of sudden large increases and drops in depth bands, indicating potential fake liquidity. Freeze OI limits immediately upon detection.

Position Side Monitoring

Track open interest (OI) relative to 24-hour trading volume. Rapid increases suggest a shift from trading to holding positions, amplifying the impact of external shocks. Also, monitor the profit/loss status of the majority side (more positions held by one side). When the majority’s profit/loss approaches extremes, price swings can trigger large reverse liquidations.

All these signals influence Builder decisions: whether to adjust leverage, lower OI caps, or activate risk modes. Misjudgments can threaten the safety of the stake.

Practical Application: Stake Maintenance Rate Calculator

Based on the above risk control system, Builders need a tool to evaluate and monitor the pressure on their staking maintenance ratio in real time.

Core Functions of the Calculator

A comprehensive stake maintenance calculator should be able to:

1. Assess Safety in Real-Time: Input current stake size, number of deployed markets, each market’s OI, and current liquidation probability to estimate worst-case penalty exposure.

2. Risk Level Tiering: Based on current market conditions (price stability, depth adequacy, OI-to-volume ratio), automatically evaluate risk levels and provide “stake consumption rate” forecasts.

3. Parameter Optimization Suggestions: Recommend optimal max leverage, margin tier divisions, OI caps, and associated staking pressures tailored to market features.

4. Multi-Market Portfolio Evaluation: For Builders with multiple markets, assess overall risk exposure and identify the most vulnerable markets to penalties.

5. Stress Testing: Simulate extreme scenarios like 5% de-anchoring, liquidity breaks, or ADL events to forecast worst-case staking losses.

Operational Scenarios

• Pre-Deployment: Use the calculator to evaluate risk levels and determine initial parameters and stake adequacy.
• During Operation: Monitor real-time risk indicators, identify early warning signals, and proactively adjust parameters.
• During Market Stress: Conduct rapid stress tests to decide whether to pause new deployments, lower leverage, or suspend markets.
• Post-Event Analysis: Backtest to estimate the scope of penalties or confiscations, informing future risk management.

Summary: Open Expansion Requires Accountable Constraints

HIP-3’s open interface transforms “listing” from a decision by a few into a protocol capability that can be invoked once conditions are met. The third-party markets have already surpassed $13 billion in total trading volume, demonstrating the viability of this approach. However, openness comes with costs: the risk management previously centralized within the platform now increasingly depends on the quality of input and operation by Builders.

The staking and maintenance ratio framework is essentially HIP-3’s defensive measure against this “risk outsourcing.” Builders express confidence in their ability to run markets stably through staking, while validators enforce “costs for instability” via penalties. The success of this system hinges on:

1. Builder’s Input Quality: Reliable oracle solutions, rational parameter settings, effective risk monitoring
2. Protocol-Level Constraints: Clear penalty authority, appropriate price fluctuation limits, comprehensive risk monitoring mechanisms
3. Tools and Systems Support: Risk control tools like the stake maintenance calculator providing timely decision support

Long-term security depends on whether Builders can truly implement these best practices, not just theoretically but in actual operation.