HIP-3 In-Depth Analysis: How Hyperliquid Turns "New Releases" into Developer Privileges

Written by: Blocksec

HIP-3 (Hyperliquid Improvement Proposal 3) has been live on the mainnet for about 3 months. Since its launch, the cumulative trading volume of third-party custom markets has exceeded $13 billion, which means that “listing” is shifting from an internal exchange process to a foundational 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 operational and risk control processes. Even on-chain, perpetual contracts—being a heavily infrastructural category—are often constrained by deployment and governance rhythms of a few teams.

The innovation of HIP-3 lies in transforming this from “platform approval” to “API openness”: as long as conditions are met, third parties can deploy new perpetual markets on the same trading and clearing base, allowing centralized listing authority 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 these markets operate compliantly and without malicious intent remains a critical issue in HIP-3’s design.

0x1 Hyperliquid: The Foundation 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: A customized L1 blockchain optimized for contract trading, capable of processing 200,000 orders per second with deterministic finality.

HyperEVM: Application layer, capable of running smart contracts, compatible with EVM.

The native perp markets of Hyperliquid (validator-operated perps) still resemble traditional CEX listing processes: the official list perpetual contracts based on community consensus; 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 perpetual listing process.

0x2 HIP-3: Developer-Deployable Markets

The core idea of HIP-3 is simple: without modifying Hyperliquid’s trading and clearing base, open the capability to add new perpetual markets to qualified builders. 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; thus, “listing” shifts from a platform process to a callable standard interface.

In simple terms: builders can list a perpetual market based on HyperCore engine, with their own price feeds and market parameter adjustments.

Builder Responsibilities and Boundaries

In HIP-3, a builder handles two types of work for a perp market: defining the market and operating the market.

Market Definition:

The official summary is oracle definition + contract specifications. Operationally, it includes at least:

Oracle Definition:

Includes initial oraclePx and data source definition. 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” (coin, szDecimals, maxLeverage, etc.) via API.

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. Each perp market corresponds to one DEX.

Market Operation:

The official list includes setting oracle prices / leverage limits / settling the market if needed, specifically:

Updating Feed Prices:

Use setOracle interface to continuously feed oracle prices.

Leverage Limits:

Constrain maximum leverage by configuring a margin table for the asset; leverage limits are tiered based on position size, restricting available leverage within preset bounds.

Settlement When Needed:

Builder can halt trading via haltTrading to trigger settlement—cancel all orders, settle positions at current mark price; this 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 500,000 HYPE; even if all their markets are halted, the stake must be maintained for 30 days.

2. Build

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

3. Set Collateral

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

4. Add Markets

The first three markets can be deployed directly; further markets require participation in a Dutch auction 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

Once 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 can still be penalized or forfeited.

Dutch Auction: current cycle is 31 hours per round, starting bid is twice the previous 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, and also for triggering TP/SL.

In native markets, mark price is not directly the feed price but 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)

At HIP-3, the roles of oracle price and mark price remain unchanged, but the calculation mechanism changes:

setOracle Input:

a. oraclePx (must ))

Core definition consistent with HyperCore.

b. markPx ( optional )

Can submit 0–2 external mark price candidates for actual mark price calculation.

c. externalPerpPx (must)

A reference value for mark price, used to prevent sudden deviations.

Builders often deploy relayer nodes for feeding prices, where:

oraclePx is computed by relayer based on external sources;

markPx is calculated via 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 feed price:

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

Combine local mark with one or more markPx (0–2) values, 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 divided into 7×24H (traded 24/7) and non-7×24H (only during specific trading hours, with spot markets unavailable outside trading hours). Their 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 keep such assets operational 24/7 in HIP-3, an alternative pricing mechanism is used during market close.

For example, on trade.xyz’s stock perpetual market:

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

During market close, adjust prices based on the last closing price, combined with internal order book pressure. Mark prices are limited to ±1/max_leverage of the last close price (e.g., Tesla 10x -> 10%).

Liquidation

HIP-3 markets largely reuse HyperCore’s liquidation logic: positions are liquidated when net value (isolated position value) falls below maintenance margin requirements.

Liquidation is based on mark price, not individual trade prices.

Liquidation Price Formula:

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

l: maintenance margin rate

The value of MAINTENANCE_MARGIN depends on the position’s margin tier: read the tier’s margin requirement (mmr). 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 liquidation, the system will prioritize closing positions via market orders on the order book; if risk is brought back to safe levels, remaining margin is returned to the trader.

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

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

ADL (Auto-Deleveraging):

In extreme cases, ADL mechanism can be triggered:

When isolated position value becomes negative, ADL is activated, which forcibly reduces or closes positions based on unrealized P&L and leverage, starting from the opposite side’s positions, at previous mark price, to cover the gap and prevent bad debt.

Order of deleveraging is based on:

previous mark price: last recorded mark price before ADL

Example:

Before ADL, system mark price = 3,000.

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

Order book is thin; after market sell orders, average fill price = 2,910 (~ -3%).

Long position losses settle at 2,910, possibly pushing isolated position value below zero (gap), triggering ADL.

ADL then selects opposite side positions (profitable shorts), and forcibly reduces/close at previous mark price (3,000), transferring the gap to the profit side as passive profit.

0x3 Risk Overview:

Accountability Constraints & Key Risks

Slashing (penalty) mechanisms: enforceable rules

HIP-3 assigns “listing and operation rights” to builders, but also embeds penalties: builders must stake HYPE; if found operating improperly, validators can vote to slash and burn their stake.

Staking requirement:

Mainnet requires 500k HYPE stake; even if all markets are halted, the stake must be maintained for 30 days.

Triggering & Voting:

In cases of malicious market behavior, validators can initiate stake-weighted votes to decide on slashing.

Judgment criteria:

Officially, penalties are not based on “maliciousness / incompetence / key theft” but on whether the builder’s actions cause invalid states, prolonged downtime, or degraded performance.

Penalty scale:

Voted by validators, with upper bounds:

• Invalid state or long downtime: up to 100%

• Short-term downtime: up to 50%

• Performance degradation: up to 20%

Penalized tokens are burned, not compensated to users.

Parameter Risks:

setOracle:

Oracle prices are usually sourced from builder relayer servers, centralization risk exists. If private keys leak or DDoS attacks occur, oracle prices may be maliciously manipulated or decoupled.

haltTrading:

Builder can halt trading to cancel all orders and settle positions at current mark price.

Use cautiously, e.g., if market manipulation is detected, halting and settling at mark price may realize attacker’s gains and cause bad debt.

setMarginTableIds / InsertMarginTable:

InsertMarginTable defines new margin requirements and max leverage for asset classes.

setMarginTableIds binds a market to a margin table.

Setting excessively high max leverage on low-liquidity markets increases ADL trigger risk.

Sudden margin table switches effectively change maintenance margin ratios, potentially causing mass liquidations.

setMarginModes:

Currently, HIP-3 only supports isolated margin; future support for cross margin may introduce systemic risks, especially in low-liquidity markets. Until mature solutions are available, cross margin is not recommended.

Oracle Risks

For 7×24H assets, risks mainly involve the accuracy and stability of external oracle services and the centralization of relayer servers.

For non-7×24H assets, larger risks include obtaining or calculating oracle prices during non-trading hours.

For example, trade.xyz uses last external oracle price plus internal market prices during off-hours. During weekends or illiquid periods, the lack of external prices can cause large deviations, leading to mass liquidations or ADL events, as happened on December 14, 2025, with XYZ100-USDC being manipulated, causing significant liquidations.

Without continuous, anchored oracle prices during non-trading hours, the system relies on the last external price plus internal order book, which can be insufficient during market gaps, increasing systemic risk.

0x4 Risk Control Strategies

1. Stable Oracle Price

For assets like stocks that are not traded 24/7, the main challenge is during market close: external stable quotes are insufficient, and the market can be manipulated or drift.

Common solutions include:

• Pausing oracle updates during off-hours, e.g., only allowing position reductions (Lighter protocol).

• Adjusting maximum leverage during off-hours, forcing liquidation of over-leveraged positions.

• Using internal pricing mechanisms (like trade.xyz) that rely on internal liquidity and algorithms when external data is missing.

These approaches reflect a trade-off between security and user experience. Strict risk controls reduce risk but impair trading experience; relying on internal prices maintains continuity but risks divergence from actual asset value.

During market close, avoid letting the protocol’s price fully become “internal-only”; instead, introduce external anchors to reduce de-anchoring and gaps. Possible references include:

• Blue Ocean ATS: post-market/night trading venues providing continuous price signals, useful for auxiliary oracle price generation or monitoring.

• IG weekend CFD quotes: weekend CFD prices as alternative signals for off-hours or risk alerts, helping anticipate opening gaps.

These sources provide price signals during off-hours but are not identical to spot markets; they serve as anchors, references, and risk warnings rather than direct substitutes.

2. Price Verification

HIP-3’s oracle prices are sourced from builder-set relayer servers, which may be centralized. To mitigate this, builders are encouraged to develop price verification mechanisms allowing anyone to verify the authenticity and fairness of prices off-chain, similar to RedStone, by packaging price data, source, and signatures on-chain.

Public Data:

• Algorithm specifications: disclose detailed algorithms and processes.

• Data source list: each source should be public, unmanipulated, with detailed API 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, with timestamps.

• Computation: intermediate values and step-by-step calculations.

• Outputs: the oracle price to be on-chain.

Serialize the proof to obtain proofHash, signed by oracleUpdater.

c. On-chain Proof

Maintain a list of proof hashes, stored in a Merkle tree, and periodically publish the Merkle root on-chain.

d. Verification

Provide open-source tools or web interfaces to input timestamps or transaction hashes, retrieve all related data, verify signatures, timestamps, Merkle roots, and compare computed oracle prices.

3. Risk Monitoring

Price verification makes the setOracle process auditable and reproducible but does not prevent market anomalies like feed interruptions, price deviations, or depth degradation, especially with large open interest (OI). These can lead to systemic risks like cascaded liquidations or ADL. Early detection and intervention are essential.

1. Price Side

a. Oracle Feed Failure

Monitoring:

• Use on-chain observables to detect feed blockage.

Thresholds:

• Action:

  • Level 1: Check relayer health, switch to backup relayer, issue alerts.

  • Level 2: Reduce open interest caps via setOpenInterestCaps.

b. Price Decoupling

Monitoring:

• Thresholds:

• Action:

  • Level 1: Reduce OI caps.

  • Level 2: During sustained deviations, adjust margin tiers and leverage limits; relayer clamps.

  • Level 3: Continuous alerts; builder may halt trading.

2. Order Book Side

a. Depth Draining

Monitoring:

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

• spread: bestAsk - bestBid.

• aggressiveVolume_Δt: taker volume over Δt.

• impact_ratio: taker volume / depth.

Risk increases when:

• depth decreases, spread and impact_ratio increase.

Actions:

• Level 1: Reduce OI caps.

• Level 2: Force lower leverage via setMarginTableIds, close risky high-leverage positions.

b. Fake Orders

Monitoring:

• Sudden increase and drop in depth_band.

Actions:

• Level 1: Reduce OI caps.

• Level 2: If price decouples severely, consider market halt.

3. Position Side

Monitoring:

• Not for predicting direction, but detecting market shift from trading to position battles: rapid OI growth, position concentration, P&L approaching limits.

• High OI / volume ratios, concentrated positions, and near-limit P&L can amplify external shocks.

Actions:

• Level 1: Warning on OI/volume thresholds.

• Level 2: Persistent triggers may lead to lower OI caps.

0x5 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 to launch their perp DEXs, initially free, then expand via auctions, turning market expansion from “waiting for approval” into “rule-based scaling.”

But clearly, HIP-3 does not eliminate risk; it merely shifts its form and location. Previously, platform risk controls covered some risks; now, more responsibility lies with builders’ input and operations: oracle feed quality, mark price constraints, margin tier settings, off-hours internal pricing, and powers like haltTrading that can both stop and amplify losses. Mishandling any step 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 rights: staking plus validator voting for penalties creates clear consequences for misoperation; meanwhile, constraints on prices and leverage (clamps, update intervals, volatility caps, isolated margin) aim to contain tail risks within manageable bounds. Ultimately, HIP-3’s true proposition is: growth through openness, safety through constraints, and long-term reliability through verifiability and accountability.