Builder must-read: How to identify and mitigate risks in the HIP-3 market

HIP-3 (Hyperliquid Improvement Proposal 3) has been live on the mainnet for three months, and the total trading volume of custom markets deployed by third-party builders has exceeded $13 billion. What is behind this number? It is the decentralization of platform authority: the “listing” power, once monopolized by centralized exchanges, has been transformed into an open standard interface. Builders only need to stake 500,000 HYPE tokens to deploy perpetual markets on Hyperliquid’s unified trading and clearing infrastructure.

However, along with the decentralization of authority, risks are also shifted outward. How to identify these risks and how to detect warning signals in operations has become a core competency that every builder must master.

Architectural Foundation: Understanding the Risk Sources of HIP-3

To identify risks within HIP-3, one must first understand its architectural design.

HIP-3 is built on Hyperliquid’s dual-layer architecture. HyperCore is a customized L1 blockchain optimized for contract trading, capable of processing 200,000 orders per second with deterministic finality; HyperEVM is the application layer that can run smart contracts. The elegance of this architecture lies in: matching, clearing, and settlement are provided uniformly by the protocol, so builders do not need to build trading systems from scratch.

But because of this, the responsibilities of builders are clearly defined yet fragile—clarity means well-defined responsibilities (market definition + operation), fragility means responsibilities are fully outsourced (risk control rights are entirely in the hands of the builder).

Builders need to stake 500k HYPE and undertake two major responsibilities:

• Market Definition: determine oracle price sources, contract specifications (leverage, minimum order size, etc.), collateral asset choices
• Market Operation: continuously feed prices, adjust margin tables (leverage limits), and halt markets when necessary

Once a market is launched, the stake is locked for 30 days before it can be unlocked. This means any operational misstep can face validator penalties through voting— but before voting, the builder must first identify the existence of issues.

Three-tiered Pricing Mechanism: How to Judge Oracle Price Health

The most critical and risk-prone component in HIP-3 is the price feeding mechanism. Builders need to understand the three price inputs of the setOracle interface:

oraclePx (mandatory): computed by the builder’s relayer server, serving as the anchor for funding rates.
markPx (optional): 0–2 external mark prices submitted by the builder, serving as candidate values for the mark price.
externalPerpPx (mandatory): a weighted median from CEX perpetuals, used to prevent the mark price from deviating sharply.

The final mark price is not directly the fed oraclePx, but rather the median of the local order book’s best bid/ask/last trade prices and the markPx. What does this imply?

It means there are multiple failure points in price calculation:

• If the relayer is offline or DDoS’d, oraclePx feeding stops
• If the builder’s markPx algorithm is flawed, arbitrage opportunities may arise
• If the local order book is too thin, median calculation can distort prices

The constraints on setOracle seem strict:

• Update frequency: at least 2.5 seconds between calls; if not updated for 10 seconds, it reverts to local mark price
• Price fluctuation limit: markPx can only vary within ±1% per update; all prices are clamped within 10x the opening price of the day

But these constraints are less effective for assets that are not traded 24/7 (like stocks).

Hidden Risks for Non-24/7 Assets: Price Traps During Market Closure

For assets like BTC, which trade 24/7, builders can rely on continuous external price sources from CEX/DEX. But for non-all-day assets like stocks, how to determine the price during market closures?

Current approach: depend on the last closing price plus a special internal order book pressure-based pricing mechanism. Specifically, the mark price is limited within ±10% (for 10x leverage) of the last close price.

The problem? When external liquidity is lacking, the internal order book depth is thin. Large orders entering during market closure can cause false price swings, especially when long positions are concentrated.

On December 14, 2025, trade.xyz’s XYZ100-USDC market (pegged to NASDAQ100) was manipulated: an attacker created 398 short positions (~$10M USDC), artificially lowered the price, causing many longs to be liquidated in a short period, with about $13M USDC of long positions forcibly closed.

The root causes are:

• Lack of external price anchors during market closure
• Insufficient internal depth to support price discovery beyond volatility limits
• Once liquidation starts, price feedback amplifies downward movement

Oracle Risks: How to Detect Centralization Threats and Decoupling Risks

The relayer server deployed by builders is inherently centralized. Key risks include private key leaks, DDoS attacks, algorithm errors—all capable of causing feed interruption or manipulation.

Four key signals to identify oracle risks:

1. Feed delays or interruptions

   • Monitoring: timestamp of last setOracle call observable on-chain
   • Alert threshold: if not updated for >10 seconds, system reverts to local mark, increasing de-coupling risk
   • Response: switch to backup relayer, issue health alerts

2. Price decoupling

   • Monitoring metrics:
     • deviation between oracle price and CEX perp mid
     • difference between mark price and oracle price
     • divergence between local order book and external market
   • Detection: if ≥2 metrics exceed thresholds simultaneously, mark as decoupling
   • Response: gradually lower max leverage, enable stricter clamp mechanisms

3. Opening gap for non-24/7 assets during market closure

   • Monitoring: expected difference between internal price and opening price
   • Reference sources: Blue Ocean ATS (after-hours trading) or weekend CFD quotes
   • Warning: if gap risk >5% before market open, issue early warning

4. Fake liquidity

   • Monitoring: order book depth and order flow ratio (active taker volume / resting orders)
   • Detection: rapid increase in depth followed by sudden disappearance
   • Response: lower OI limits, restrict new positions

Parameter Configuration Traps: Common Pitfalls for Builders

Many builders think setting parameters once is enough, but dynamic adjustment of parameters is the real test of operational skill.

Key configuration risks:

1. Excessive leverage In low-liquidity markets, setting too high max leverage greatly increases the likelihood of ADL (auto-deleveraging) triggers. Rapid position accumulation and near-extreme profit/loss margins mean any price fluctuation can trigger cascading liquidations.

2. Sudden margin table adjustments Changing margin requirements overnight effectively alters all users’ maintenance margin ratios. Many accounts can instantly shift from “safe” to “liquidatable,” causing mass forced liquidations. Such operations must be announced in advance and phased.

3. Abuse of haltTrading Builders can call haltTrading to suspend markets, cancel all orders, and settle at current mark prices. But misusing this “double-edged sword” can lock in attacker profits—attackers find it hard to find counterparties, but haltTrading allows settlement at mark price, potentially benefiting attackers.

4. Cross-margin mode (future risk) Currently, HIP-3 only supports isolated margin. Future support for cross-margin could transmit risks from low-liquidity markets to high-liquidity ones. Builders should avoid attempting this until mature solutions are available.

Multi-Dimensional Risk Monitoring System: A Complete Early Warning Framework

Since risks are everywhere, builders need to establish a multi-layered, real-time monitoring system.

Price-side Monitoring

Level 1 Alert (Feed anomalies):

• Indicator: setOracle call interval >5 seconds
• Action: check relayer health, switch backup nodes
• Output: alerts containing all relayer info

Level 2 Alert (Price decoupling):

• Indicator: deviation between oracle and CEX perp mid >2% sustained >5 seconds
• Action: lower open interest caps via setOpenInterestCaps
• Further: gradually reduce max leverage in margin tables

Level 3 Alert (Long-term deviation):

• Indicator: decoupling persists >30 seconds
• Action: enable clamp to restrict volatility
• Final: builder decides whether to call haltTrading to stop the market

Order Book Monitoring

Depth extraction signals:

• Indicator: real order depth within ±2% price band (depth_band)
• Alert: depth_band drops, bid-ask spread widens, impact_ratio (active taker volume / depth) rises
• Judgment: all three signals together indicate rapid liquidity deterioration
• Response: lower OI limits, restrict new positions

Fake order detection:

• Signal: depth_band rapidly increases then suddenly disappears
• Response: lower OI to current level (disable increases), consider stopping market if severe decoupling occurs

Position Monitoring

The goal is not to “predict prices” but to detect whether the market has shifted from trading-driven to position-driven.

OI overload signals:

• Calculation: OI notional / 24h volume notional
• Judgment: rapid increase indicates potential volatility
• Response: issue warnings, prepare to reduce leverage

Majority PNL signals:

• Indicators: average entry price, position size, current profit/loss ratio of the dominant side
• Warning: if the majority’s profit/loss approaches extremes (e.g., longs all +20%), any external shock can trigger cascade liquidations
• Response: lower leverage in advance to reduce extreme losses

Risk Verification: Making Oracle Auditable and Recomputable

Monitoring alone is not enough; builders need to make the feeding process itself “verifiable.”

Establish a price proof system:

1. Publicly disclose algorithms and data sources

   • Full logic and parameters of setOracle
   • List all data sources and their weights
   • Update frequency and volatility limits

2. Generate off-chain verifiable proofs

   • For each setOracle call, produce a proof containing:
     • Inputs: raw data responses and timestamps
     • Computation: intermediate results
     • Outputs: on-chain oracle price
   • Serialize proof and sign with builder’s key to produce proofHash

3. Publish Merkle root periodically

   • Aggregate all proofHashes into a Merkle tree
   • Publish Merkle root on-chain hourly/daily
   • Anyone can verify the authenticity of each feed

4. Provide open-source verification tools

   • Users input timestamps or tx hashes
   • Automatically retrieve data, verify signatures, timestamps, Merkle proofs
   • Recompute oracle prices and compare with on-chain data

This system ensures that even if the builder’s relayer is compromised, users can verify the feed’s authenticity off-chain, providing evidence for protocol accountability.

Asset-Specific Risk Isolation Strategies

Different assets have distinct risk profiles; monitoring thresholds should be tailored accordingly.

24/7 assets (BTC, ETH):

• Advantages: continuous external price anchors
• Key monitoring: relayer stability, oracle vs. CEX perp deviation
• Thresholds: relatively loose (deviation >3% triggers alert)

Non-24/7 assets (stocks):

• Disadvantages: no external anchor during market closure
• Key monitoring: gap risk at open, false volatility during closure
• Thresholds: stricter (deviation >1% triggers alert)
• Reference sources: Blue Ocean ATS after-hours trading, weekend CFD quotes
• Special handling: during high-risk periods (1 hour before close, 30 minutes after open), reduce max leverage

Liquidation and ADL: Understanding Risks in Extreme Scenarios

Liquidation itself is not a risk; the risk lies in the chain reaction triggered by liquidations.

HIP-3 inherits HyperCore’s liquidation logic: when position net worth falls below maintenance margin, liquidation is triggered. The system prioritizes market orders from the order book, but if depth is insufficient, actual execution prices can deviate significantly from mark price, creating a “liquidation gap.”

When such gaps occur, ADL (auto-deleveraging) activates:

• Select profitable counterparties
• Force reduce positions at last known mark price
• Use counterparties’ profits to fill the gap, preventing bad debt

However, ADL indicates the market is in an extreme state. Once triggered, profitable traders are forced to take smaller gains, which can undermine confidence and trigger further risks.

How can builders anticipate ADL activation?

• Monitor: position concentration, OI scale, order book depth
• Signal: rapid increase in OI / depth_band ratio
• Prevention: lower max leverage, restrict new positions before reaching critical levels

Accountability and Future-Proofing: Standardization, Verification, and Oversight

The core innovation of HIP-3 is: decentralizing authority while embedding responsibility into the protocol.

Verifiers can vote to penalize builders for misoperations, with penalties scaled by severity:

• Severe failures or prolonged downtime: up to 100% stake slashed
• Short-term downtime: up to 50%
• Performance degradation: up to 20%

Staked tokens are burned, not redistributed, incentivizing builders to operate responsibly. This creates a strong motivation to maintain integrity.

For penalties to be effective:

1. Risks must be observable: comprehensive monitoring detects anomalies promptly
2. Responsibility must be traceable: verifiable proof of feed integrity allows source attribution
3. Decisions must be executable: transparent voting mechanisms ensure swift enforcement

Summary: From “Deployment” to “Stable Operation”

HIP-3 replaces platform approval with open interfaces, and the $13 billion trading volume of third-party markets demonstrates the viability of this approach. But openness comes at a cost: the risk control previously handled by the platform now largely depends on the input quality and operational standards of builders.

From a builder’s perspective, mastering not only “how to deploy markets” but more critically “how to identify risks” and “how to respond promptly” is essential. This involves:

1. Understanding risk sources: from architecture, pricing, parameters, to liquidity
2. Building monitoring systems: real-time multi-layered alerts across price, order book, and positions
3. Implementing verification mechanisms: transparent, reproducible feed proofs for accountability
4. Preparing contingency plans: when to reduce leverage, limit OI, or halt markets

Long-term safety hinges on whether builders can implement reliable oracle solutions, rational parameter settings, and effective market monitoring.

HIP-3 is not about making listing easier; it’s about standardizing the process—deployment, operation, and accountability. Ultimately, the stability of this standard depends on the builder’s deep understanding of risks and execution capability.

If you are designing market access standards based on HIP-3, creating parameter templates, building early warning systems, or require risk auditing and ongoing security support, BlockSec and other professional security teams can provide in-depth technical consulting and auditing services.