From Beginner to Risk Control: A Builder's Practical Guide to HIP-3 Security

HIP-3 (Hyperliquid Improvement Proposal 3) has been live on the mainnet for about 3 months. Since its launch, the total trading volume of third-party custom markets has exceeded $13 billion, which means that “listing” is shifting from an internal exchange process to an infrastructure capability that external developers can directly invoke.

In centralized exchanges, “listing” is inherently a platform authority: which assets can be traded, when they go live, and parameter settings are mostly determined by operations and risk control processes. Even on-chain, perpetual contracts—being a heavily infrastructure-dependent category—are often constrained by the deployment and governance rhythm of a few teams.

The innovation of HIP-3 lies in transforming this from “platform approval” to “interface openness”: as long as conditions are met, third parties can deploy new perpetual markets on the same trading and clearing base, allowing centralized listing rights to be systematically outsourced to the ecosystem. This improvement not only lowers the barrier to innovation but also enhances market scalability. However, the potential security risks brought by open interfaces cannot be ignored. Ensuring that these markets operate compliantly and without malicious intent remains a critical issue in HIP-3’s design.

0x1 Hyperliquid: The Base of HIP-3

Hyperliquid is a perpetual trading infrastructure running on its own chain. For HIP-3, the key point is: matching, clearing, and settlement are provided uniformly by the protocol base, enabling market capabilities to be reused rather than building a trading system from scratch.

Hyperliquid adopts a dual-layer architecture: #HyperCore：为合约交易优化的定制化 L1 区块链，每秒可处理 20 万笔订单，并具备确定性最终性。#HyperEVM: Application layer, capable of running smart contracts, compatible with EVM.

Hyperliquid’s native perp markets (validator-operated perps) still resemble traditional CEX listing processes: the official lists perpetual contracts based on community demand; delisting is decided by validator node voting.

The Hyperliquid protocol will support builder-deployed perps (HIP-3), a key milestone toward fully decentralizing the perp listing process.

Hyperliquid protocol will support builder-deployed perpetual contracts (HIP-3), which is a crucial milestone for fully decentralizing the listing process.

0x2 HIP-3: Developer-Deployable Markets

HIP-3’s core idea is simple: without modifying Hyperliquid’s trading and clearing base, open the ability to add new perpetual markets to builders who meet certain conditions. Builders define key market parameters and price/feed/operation responsibilities, while the protocol uses a unified margin and liquidation engine to handle execution and risk control boundaries. As a result, “listing” shifts from a platform process to a callable standard interface.

In simple terms: builders can list a perpetual market based on HyperCore engine, providing their own price feeds and adjusting market parameters.

Builder’s responsibilities: In HIP-3, a builder handles two main tasks for a perp market (market): defining the market and operating the market.

Market definition: The official summarizes this as oracle definition + contract specifications. At the operational level, it at least includes:

• Oracle definition: including initial oraclePx and data source. When defining a market, the builder should clearly specify a target asset or data source that is unmanipulable and economically substantive; an initial oraclePx must be provided during asset registration.

• Contract specifications: explicitly define market parameters such as “asset symbol / minimum order size / maximum leverage” via API (coin, szDecimals, maxLeverage, etc.).

• DEX selection: the builder first deploys a perp DEX (each DEX has independent margin, order book, deployer settings), and can choose any quote asset (e.g., USDC) as collateral for that DEX. Each perp market corresponds to one DEX.

Market operation: The official lists setting oracle prices / leverage limits / settling the market if needed, specifically:

• Updating feed prices: via setOracle interface to continuously feed oracle prices.

• Leverage cap: constrained by configuring a margin table for the asset, with maximum leverage set in tiers based on position size, limiting available leverage within preset bounds.

• Settlement when necessary: builders can halt trading via haltTrading, triggering settlement—cancel all orders, settle positions at current mark price; the same action can also resume trading.

Currently, HIP-3 markets only support isolated margin mode; in the future, cross margin may be supported.

Market Listing Process

1. Stake: Mainnet requires builders to stake 500k HYPE; even if they suspend all their markets on their DEX, the stake must be maintained for 30 days.

2. Build: After meeting the stake threshold, builders can deploy a perp DEX. Each perp DEX is an independent trading domain: independent margin, order book, deployer settings.

3. Set collateral: The collateral for the DEX can be any quote asset, but if that quote asset loses permissionless quote status (voted by validators), the perp DEX using it as collateral will be disabled.

4. Add markets: The first 3 markets can be deployed directly; to add more, a Dutch auction is required to obtain “additional slots.”

5. Operate markets: After listing, the builder’s task is to “run the market stably,” i.e., market operation.

6. Unstake: When all markets on the DEX are settled, the 500k HYPE stake can be unlocked. Initiating unstake enters a 7-day unstaking queue, during which the stake may still be penalized or confiscated.

Dutch auction: current cycle is 31 hours per round, starting price is 2× the previous round’s final/lowest price.

SetOracle: Three Types of Price Inputs

In HyperCore, oracle price mainly anchors and calculates funding rates, while mark price is used as a reference for margin and liquidation scenarios (also for TP/SL triggers).

In native markets, mark price is not directly the result of a single feed but is calculated as the median of three prices:

• oraclePx + EMA(midPx - oraclePx)

• median(best bid, best ask, last trade) (local order book prices)

• weighted median of perp mid prices from multiple CEXs (perp mid prices)

In HIP-3, the roles of oracle price and mark price remain unchanged, but the calculation mechanism has changed:

1. setOracle input

a. oraclePx (must be )

• Core definition consistent with HyperCore.

b. markPx ( optional )

• Can submit 0–2 external mark price sets as candidates for the true mark price.

c. externalPerpPx (must)

• Used as a reference for a mark price to prevent sudden deviations.

Builders often deploy relayer nodes for feeding prices, where oraclePx

is computed by relayer combining external sources; markPx is calculated by custom algorithms; externalPerpPx is a weighted median of perp mid prices from multiple CEXs.

2. Actual mark price

HIP-3’s mark price is not directly the setOracle feed:

• Compute local mark: median(best bid, best ask, last trade).

• Combine local mark and markPx (0–2 sets), take the median to get the new mark price.

3. setOracle restrictions

• Update frequency: at least 2.5 seconds between calls; if markPx is not updated within 10 seconds, it reverts to local mark.

• Amplitude limit: markPx cannot fluctuate more than ±1% per update; all prices are clamped within 10× the start-of-day value.

7×24H & Non-7×24H: Pricing Mechanism Differences

In HIP-3, perpetual markets support assets that can be categorized as 7×24H (traded around the clock) and non-7×24H (only during specific trading hours, with spot markets unavailable outside trading hours). The trading time characteristics influence their price acquisition methods.

For 7×24H assets (e.g., BTC), stable prices can be obtained from CEX/DEX or trusted oracles:

For non-7×24H assets (e.g., stocks), liquidity and stable external quotes are only available during trading hours. To maintain normal operation of such assets in HIP-3 around the clock, an alternative pricing mechanism is used during market closure.

Taking stock perpetual markets on trade.xyz as an example:

• During market hours, use stable feeds from external oracles like Pyth.

• During market closure, adjust prices based on the last closing price, combined with internal order book pressure. The mark price is limited to fluctuate within 1/max_leverage of the last close (e.g., Tesla 10x -> 10%).

Liquidation

HIP-3 markets largely reuse HyperCore’s liquidation logic, which triggers when position net value (isolated position value) falls below maintenance margin requirements.

Liquidation decisions are based on the mark price, not a specific trade price.

Liquidation price formula:

side = 1 (long), -1 (short)

l: maintenance margin rate

MAINTENANCE_LEVERAGE value is derived from the position’s margin tier: read the maintenance margin rate (mmr) for that tier:

If tiers are defined, the liquidation price corresponds to the tier where the position’s nominal value falls, using that tier’s mmr.

• margin_available

• isolated: isolated_margin - maintenance_margin_required

Once in a liquidatable state, the system will prioritize closing positions via market orders on the order book; if risk is brought back to safe levels, remaining margin stays with the trader.

However, in cases of insufficient depth or gaps, actual execution prices may significantly differ from the mark price, creating a “liquidation gap.”

Isolated position value: the net value of a specific isolated position at the current mark price (including P&L, minus the margin bound to the position).

ADL (Auto-Deleveraging):

In extreme cases, the ADL (Auto-Deleveraging) mechanism can be used as a safety net:

When an isolated position value becomes negative, ADL is triggered, forcibly reducing or closing positions on the opposite side based on unrealized P&L and leverage, starting from the previous mark price, using the profitable side to fill the gap, preventing bad debt.

Sorting criteria:

• previous mark price: the last recorded mark price before ADL trigger.

Example:

Before ADL trigger, system mark price = 3,000.

Due to setOracle constraints, the new mark price can only update to 2,970 (-1%).

But the order book is thin, and a market sell order at this price results in an average fill price of 2,910 (-3% from 3,000).

A long position’s loss is settled at 2,910, potentially pushing the isolated position value below zero (creating a gap), thus triggering ADL.

ADL then selects positions from the profitable short side, settling at previous mark price = 3,000, forcibly reducing/closing positions, transferring the gap to the winning side as passive profit.

https://x.com/bartdothl/status/2000292798755684839

On the other hand, during non-trading hours, the lack of continuous, anchored oracle prices means the market can only rely on “last external price + internal order book” to form a limited internal pricing range (e.g., trade.xyz limits maximum fluctuation to 1/max_leverage).

Risks appear at reopening points: external market prices may suddenly give a clear external price, which could significantly gap from the internal price during the closure, causing the system to either continue to be clamped, leading to divergence between external and tradable prices, or to reprice rapidly when switching back to external anchoring; both scenarios can trigger concentrated liquidation pressure or ADL events.

Risk Control Strategies

1. ( Stable Oracle Price

For assets like stocks that are not traded 24/7, the main challenge is pricing during market closure: external anchored prices are insufficient, and the market is more susceptible to manipulation or drift under low depth.

Common industry solutions mainly fall into two categories:

• Directly stop updating oracle prices, pause or restrict trading during that period )e.g., Lighter protocol only allows reducing positions during market close(. Optium and others also lower maximum leverage during market closure, forcibly liquidating positions exceeding limits.

• Use internal pricing mechanisms like trade.xyz, relying on internal market liquidity and algorithms when external data is missing.

These approaches reflect a trade-off between security and user experience. The first enforces stricter risk controls but sacrifices trading continuity; the second maintains trading but risks internal price divergence from actual asset value.

During market closure, the protocol should avoid fully internal pricing, instead referencing external anchors to reduce divergence and gap risks. Possible references include:

• Blue Ocean ATS

As a post-market/night trading venue, it can provide some continuous price signals during closure (more timely than last close), assisting in generating oracle prices or monitoring for price divergence.

• IG weekend CFD quotes

Weekend CFD quotes can serve as alternative signals for “market expectations” during closure, useful as external anchors or monitoring references, helping to detect potential gaps at open.

Both sources provide price signals during market closure but are not identical to the underlying spot market; they are better used as anchors, references, or risk alerts rather than direct substitutes.

2. ) Price Verification

HIP-3’s oracle prices originate from builder-configured relayer servers, which may raise centralization concerns. It is recommended that builders develop a price verification mechanism allowing any user or institution to verify the authenticity and fairness of prices off-chain )similar to RedStone, packaging the price along with data source and signature proof on-chain(.

Public Data

• Algorithm specification: disclose detailed algorithms and process mechanisms.

• Data source list: each data source should be public, uncontrollable by builders, with detailed interface and parameters.

• Price push standards: permissions, trigger frequency, and volatility limits for setOracle calls.

b. Proof of Price

Generate a proof )Proof) for each setOracle call, including:

• Inputs: raw responses (or normalized fields) from each data source at that time, with sampling timestamp.

• Computation: intermediate values that can be recomputed, with intermediate results for each step.

• Outputs: the oracle price uploaded on-chain.

Serialize the proof to obtain proofHash, signed by oracleUpdater.

c. Proof On-Chain

Maintain a list of proof hashes, stored in a Merkle tree in chronological order.

Periodically (e.g., hourly/daily), publish the Merkle root and submit it on-chain.

d. Verification

Provide open-source tools or web interfaces where users can input a timestamp or specific setOracle transaction hash to retrieve all related data, verify signatures, timestamps, Merkle root, and compare computed oracle prices.

3. ( Risk Monitoring

Price verification makes the setOracle process “recomputable and auditable,” addressing the trustworthiness of feeds; but it cannot prevent market from going out of control—feed interruptions, price deviations, and depth degradation, especially with large open interest )OI(, can quickly lead to systemic risks like cascade liquidations or ADL. Therefore, early detection of abnormal market signals and timely intervention are essential to keep risks within manageable bounds.

1. Price Side

a. Oracle Feed Failure

Monitoring indicators:

• Use on-chain observable metrics to judge if the feed is blocked:

![图片])https://img-cdn.gateio.im/webp-social/moments-0b00e6148b093547c349b784ee8a5d73.webp)

Threshold levels:

Actions:

• Level 1: Check relayer health, switch to backup relayer nodes; issue alerts with health reports and relayer info.

• Level 2: Call setOpenInterestCaps to lower OI caps.

b. Price Divergence

Monitoring indicators:

Thresholds:

• Level 1: ≥2 of A, B, D exceed thresholds.

• Level 2: ≥3 of A, B, C, D exceed thresholds and persist for X seconds.

Actions:

• Level 1: Call setOpenInterestCaps to lower OI limits.

• Level 2: With prolonged deviation, gradually update margin tables, reduce max leverage tiers, enable clamp mechanisms.

• Level 3: Continue alerts; ultimately, the builder decides whether to call haltTrading to stop the market.

2. Order Book Side

a. Depth Dislocation

Monitoring:

• depth_band(±x%): real order volume within ±x% of mid-price.

• spread = bestAsk - bestBid: to measure market fragmentation.

• aggressiveVolume_Δt: taker volume within Δt.

• impact_ratio = aggressiveVolume_Δt / depth_band: absorption ratio.

Risk increases when:

• depth_band decreases, while spread and impact_ratio increase.

Actions:

• Level 1: Call setOpenInterestCaps to lower OI cap to current OI.

• Level 2: Force lower leverage via setMarginTableIds, and forcibly close some high-risk high-leverage positions.

b. Fake Orders

Monitoring:

• Sudden increase and drop in depth_band over short periods.

Actions:

• Level 1: Call setOpenInterestCaps to lower OI cap.

• Level 2: If accompanied by severe price divergence, consider stopping the market.

3. Position Side

The goal is not to predict direction but to detect whether the market shifts from trading-driven to position-driven: rapid OI accumulation, high concentration, and P&L approaching extremes make the market more susceptible to amplification of external shocks into cascade liquidations or ADL. Therefore, position-side actions are generally lower priority than price and order book monitoring.

a. Short-term OI Overload

Monitoring:

• OI_notional: open interest size.

• Volume_24h_notional: 24h trading volume.

• Compute ratio: OI_notional / Volume_24h_notional; rapid increase indicates shift from short-term trading to position battles, often foreshadowing volatility.

Actions:

• Level 1: Trigger alerts when exceeding limits.

b. Majority P&L

Monitoring:

• Majority Side: the side with more open positions in a window (Long or Short).

• avgEntry_major: average entry price of majority positions.

• size_major: size of majority positions.

Majority P&L:

Majority P&L ratio:

Actions:

• Level 1: Trigger alerts when exceeding limits.

• Level 2: Continuous exceeding may trigger setOpenInterestCaps to lower OI limits.

Conclusion

The core narrative of HIP-3 is: transforming “listing” from a decision made by a few into a protocol capability accessible upon meeting certain thresholds—builders stake tokens to launch their perp DEXs on HyperCore, initially listing a few markets for free, then expanding through auctions for more slots, turning market expansion from “waiting for approval” into “rule-based scaling.”

But it’s also clear that HIP-3 does not eliminate risks; it only redefines their location and form. Previously, platform risk controls covered some risks; now, more responsibility shifts to the builder’s input and operational quality: feed frequency and accuracy, markPx constraints, margin tier leverage, non-24H asset pricing intervals, and powers like haltTrading that can both stop losses and amplify losses. Mishandling any link can lead to concentrated liquidations, gaps, and ADL events—making the problem less about “whether it can list” and more about “whether it can run stably after listing.”

The protocol’s core approach to “risk outsourcing” is to turn permissions into accountable permissions: staking plus validator voting for penalties create clear consequences for builder misoperation; meanwhile, constraints on prices and leverage (clamp, update intervals, volatility caps, isolated margin) aim to contain the most dangerous tail risks within controllable bounds. Thus, the true proposition of HIP-3 is: growth through openness, safety through constraints, and long-term security through verifiability and accountability.

HIP-3 does not make listing more free but more standardized—deployable, operable, and accountable. Achieving stable operation ultimately depends on the implementation quality of oracles, leverage, risk parameters, and runtime monitoring. If you are designing market access, parameter templates, alerts, emergency procedures, or require auditing and ongoing security support based on HIP-3, welcome to contact BlockSec.