Author: 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, indicating that the process of "listing new assets" is transitioning from an internal exchange procedure to a foundational capability that can be directly invoked by external developers.
In centralized exchanges, "listing new assets" is inherently a platform power: which assets can be traded, when they go live, and how parameters are set are primarily determined by operational and risk control processes. Even on-chain, perpetual contracts, which are a heavy infrastructure category, are often constrained by the deployment and governance rhythm of a few teams.
The innovation of HIP-3 lies in transforming this process from "platform approval" to "interface openness": as long as conditions are met, third parties can deploy new perpetual contract markets on the same trading and clearing foundation, systematically outsourcing the centralized listing power to the ecosystem. This improvement not only lowers the innovation threshold 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 behavior remains a key issue that needs to be rigorously examined in the design of HIP-3.
0x1 Hyperliquid: The Foundation of HIP-3
Hyperliquid is a perpetual trading infrastructure running on its own chain. For HIP-3, the most critical point is that matching, clearing, and settlement are uniformly provided by the protocol foundation, allowing 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: An application layer that can run smart contracts and is EVM compatible.
The native perp market of Hyperliquid (validator-operated perps) still resembles the traditional CEX process for listing: the official team lists perpetual contracts based on community willingness; delisting is decided by a vote from validator nodes.
The Hyperliquid protocol will support builder-deployed perps (HIP-3), a key milestone toward fully decentralizing the perp listing process.
0x2 HIP-3: Developer-Deployed Markets
The concept of HIP-3 is simple: without changing the Hyperliquid trading and clearing foundation, the capability to "add new perpetual markets" is opened to qualified builders. Builders are responsible for defining key market parameters and pricing/operational responsibilities, while the protocol uses a unified margin and clearing engine to handle execution and risk control boundaries; thus, "listing new assets" transforms from a platform process into a callable standard interface.
In simple terms: builders can list a perpetual contract market based on the HyperCore engine, set their own prices, and adjust market parameters.
Responsibilities of Builders
In HIP-3, builders undertake two types of work for a perp market:
Market Definition:
The official summary includes oracle definition + contract specifications. On an operational level, it includes at least:
Oracle Definition:
This includes the initial oraclePx and the definition of price sources. Builders should clearly define an asset or data source that is clear, difficult to manipulate, and has economic substance when defining the market; an initial oraclePx must be provided when registering the asset.
Contract Specifications:
Clearly define market parameters such as "asset symbol/minimum order unit/maximum leverage" in the API interface (coin, szDecimals, maxLeverage, etc.).
DEX Selection:
Builders first deploy a perp DEX (each DEX has independent margin, order book, and deployer settings) and can choose any quoted asset as collateral for that DEX (e.g., USDC). Each perp market corresponds to a DEX.
Market Operation:
The official list includes setting oracle prices / leverage limits / settling the market if needed, specifically:
Updating Prices:
Continuously feed prices to the market's Oracle Price through the setOracle interface.
Leverage Limits:
Constrain maximum leverage by configuring a corresponding margin table for the asset—the leverage limit is set in tiers based on position size, thus keeping available leverage within preset ranges.
Settlement if Necessary:
Builders can use the haltTrading interface to suspend the market, triggering settlement—cancelling all orders and settling positions at the current mark price; the same action can also be used to resume trading.
Currently, HIP-3 markets only support isolated positions; full positions may be supported in the future.
Full Process for Market Launch
- Stake
The mainnet requires builders to maintain a stake of 500k HYPE; even if they suspend all markets on their DEX, the staking requirement must be maintained for 30 days.
- Build
After meeting the staking threshold, builders can deploy a perp DEX. Each perp DEX is a separate trading domain: independent margin, order book, and deployer settings.
- Set Collateral
The collateral for the DEX can choose any quote asset, but if that quote asset loses its permissionless status (as determined by validator votes), the perp DEX using it as collateral will be disabled.
- Add Markets
The first three markets can be deployed directly;
To add more markets, a "new slot" must be obtained through a Dutch auction.
- Operate Markets
Once the market is live, the builder's job becomes "stabilizing the market," i.e., market operation.
- Unstake
Only after all markets on the DEX have been settled can the staked 500k HYPE be unlocked. After initiating an unstake, it will enter a 7-day unstaking queue, during which the stake may still be forfeited.
Dutch Auction: The current cycle lasts 31 hours, with each starting price being 2 times the final price (transaction price/minimum price) from the last auction.
SetOracle: Three Types of Price Inputs
In HyperCore, the oracle price is primarily used to anchor and calculate funding fees, while the mark price serves as the marked price for risk control scenarios such as margin and settlement (also used to trigger TP/SL, etc.).
In the native market, the mark price is not a direct result of a single price feed but is calculated as the median of three price results:
oraclePx + EMA(midPx - oraclePx)
median(best bid, best ask, last trade) (local order book prices)
weighted median of perp mid prices from multiple CEXs
In HIP-3, the roles of oracle price and mark price remain unchanged, but the calculation mechanism has changed:
setOracle Inputs
a. oraclePx (mandatory)
The core definition is consistent with HyperCore.
b. markPx (optional)
Can submit 0-2 sets of external mark prices as candidates for the actual mark price calculation.
c. externalPerpPx (mandatory)
An input reference for a mark price, used to prevent sudden deviations of the mark price.
Builders often deploy relayer nodes for price feeding, where oraclePx is calculated by the relayer combining external price sources; markPx is calculated by the relayer's custom algorithm; externalPerpPx comes from the weighted median of perp mid prices from multiple CEXs.
- Actual Mark Price
The mark price in HIP-3 is not directly using the price feed from setOracle:
Calculate local mark: median(best bid, best ask, last trade).
Combine local mark and markPx (0-2 sets) to take the median, resulting in the new mark price.
- setOracle Restrictions
Update Frequency: There must be at least a 2.5-second interval between two calls, and if markPx is not updated for 10 seconds, it will revert to the local mark price.
Amplitude Limit: The fluctuation of markPx each time cannot exceed ±1%; all prices will be clamped within a range of 10× the start-of-day value.
7×24H & Non-7×24H: Differences in Pricing Mechanism
In HIP-3, perpetual contract markets support the listing of any asset, which can be divided into 7×24H assets (traded around the clock) and non-7×24H assets (only available for trading during specific hours, with no trading in the spot market during non-trading hours). The trading time characteristics of these two types of assets determine the differences in their price acquisition methods.
For 7×24H assets (e.g., BTC), stable prices can be obtained from CEX/DEX or trusted oracle services:
For non-7×24H assets (e.g., stocks), liquidity-rich and relatively stable external market quotes can only be obtained during market opening hours. To maintain the normal operation of such assets in HIP-3 around the clock, a different pricing mechanism must be used during market closures.
Taking the perpetual contract market for stocks on trade.xyz as an example:
During stock market opening hours, stable price feeds provided by external oracle services like Pyth are used.
During stock market closures, price adjustments are made based on the last closing price of the stock, combined with internal buy/sell pressure. Mark prices are limited to fluctuations of 1/max_leverage around the last closing price (e.g., Tesla 10x -> 10%).
Liquidation
The HIP-3 market primarily reuses the clearing logic of HyperCore, so the liquidation trigger logic follows the platform: when the net value of a position (isolated position value) is insufficient to cover the maintenance margin requirement, it enters a liquidatable state.
Liquidation-related judgments are based on the mark price, rather than a specific transaction price.
Liquidation Price Formula:
side = 1 (long), -1 (short)
l: the maintenance margin rate
The value of MAINTENANCE_LEVERAGE comes from the margin tier corresponding to that position: first, read the maintenance margin rate mmr from that tier:
If there are tiers, the nominal value of the position corresponding to the liquidation price falls within which tier, use the mmr of that tier.
margin_available
isolated: isolatedmargin - maintenancemargin_required
Once in a liquidatable state, the system will prioritize closing positions using market orders from the order book; if it can pull the risk back into a safe range, the remaining margin still belongs to the trader.
However, in cases of insufficient depth or gaps, the actual average closing price may significantly differ from the mark price, resulting in a "liquidation gap."
Isolated position value: refers to the net value of a specific isolated position at the current mark price (after accounting for position profit and loss minus the margin tied to that position).
ADL:
At this point, the ADL (Auto-Deleveraging) mechanism can be used to provide a safety net in extreme situations:
When the isolated position value becomes negative, ADL is triggered, and positions from the counterparty are forced to reduce or close based on unrealized profit and loss and leverage ranking, sequentially at the previous mark price, using the profits from the counterparty to fill the gap, ensuring the system does not incur bad debts.
The sorting criteria are calculated based on the following standards:
previous mark price: refers to the last recorded mark price in the system before ADL is triggered.
Example:
Before triggering ADL, the system's mark price = 3,000.
Due to the constraints of setOracle, the new mark price can only be updated to a maximum of 2,970 (-1%).
However, at this time, the buy side of the order book is thin, and after the liquidation market order hits the order book, the actual average transaction price = 2,910 (which is -3% relative to 3,000).
The loss of the long position is settled at 2,910, which may push the isolated position value of that position below 0 (creating a gap), thus triggering ADL.
ADL then selects positions from the counterparty (profitable shorts) and settles forced reductions/closures at the previous mark price = 3,000, transferring the gap to "the profitable party earning less passively."
0x3 Overview of Risk Aspects:
Accountability Constraints and Key Risks
Slashing Mechanism: Accountable Authority
HIP-3 hands over the "listing and operational authority" to builders while also embedding a set of enforceable slashing rules into the protocol: builders must stake HYPE, and once deemed to be operating improperly, validators can vote to slash and burn their stake.
Staking Requirements
The mainnet requires builders to maintain a stake of 500k HYPE; even if the builder suspends all their markets, they must continue to maintain this for 30 days (responsibility does not immediately cease upon suspension).
Triggering and Voting
When malicious market operations occur, validators can initiate and execute a stake-weighted vote (voting based on staking weight) to decide whether to slash the builder's stake.
Determination Principles
The official stance is clear: slashing does not differentiate between "malicious / insufficient capability / private key theft" and other reasons; the core consideration is whether the builder's actions have resulted in an invalid state, prolonged downtime, or performance degradation.
Slashing Proportion
The proportion of slashing is determined by validator voting, with reference to the following upper limits:
Causing an invalid state or prolonged downtime: up to 100%
Brief downtime: up to 50%
Performance degradation: up to 20%
Slashed staked tokens will be burned, rather than compensated to affected users.
Parameter Configuration Risks
setOracle
Oracle prices generally come from the builder's relayer server, which carries centralization risks. If the private key is leaked or suffers a DDoS attack, the oracle price in the market may be maliciously manipulated or become unanchored for an extended period.
haltTrading
Builders can use haltTrading to cancel all orders in the market and close positions at the current mark price.
This operation should be used cautiously; for example, in the following scenario:
When detecting that the market is being maliciously manipulated by attackers, calling haltTrading to directly close positions at the mark price would directly realize the floating profits of the attackers (who might originally find it difficult to find enough counterparty orders) and could lead to bad debts.
setMarginTableIds / InsertMarginTable
InsertMarginTable: defines a new margin table, which specifies the margin requirements and maximum leverage for a certain type of asset.
setMarginTableIds: binds a market to a specified marginTableId.
For a market with low liquidity/inadequate market-making ability, setting the max leverage too high will increase the probability of triggering ADL.
Suddenly switching marginTableId is equivalent to modifying the maintenance margin ratio of user positions, which may cause a large number of accounts to shift from safe to liquidatable at the same time, triggering a chain liquidation.
setMarginModes
Currently, HIP-3 only allows isolated margin (isolated positions), and may support cross margin (full positions) in the future. A DEX may have markets with high liquidity and low liquidity, and the cross margin mode may transmit low liquidity risks to high liquidity markets. Therefore, until the official provides a mature solution, it is not recommended for builders to introduce cross margin.
Oracle Risks
For 7×24H assets, the main risk points lie in the accuracy and stability of the external oracle services relied upon, as well as the centralization risks of the aforementioned relayer servers.
For non-7×24H assets, the greater risk lies in the acquisition or calculation of oracle prices during the non-trading hours of that asset.
Taking trade.xyz as an example, during non-trading hours, the last external oracle price and internal market prices are used to calculate a composite price. During weekends, the stock perpetual market lacks liquidity (the order book thins out and market makers reduce quotes), and there are no external oracle prices for anchoring. Even if a hard cap on price fluctuations is set (1/max_leverage), this limit is still too high for low-volatility assets, and price fluctuations within this range can still lead to widespread liquidations or even ADL.
On December 14, 2025, the XYZ100-USDC (benchmarking NASDAQ100) on trade.xyz was manipulated, with attackers creating a short position of 398 XYZ100 (~10M USDC), causing a severe price dislocation, leading to the liquidation of many long positions, which in turn caused the price to continue to drop, ultimately resulting in ~13M USDC of long positions being liquidated.
https://x.com/bartdothl/status/2000292798755684839
On the other hand, the lack of continuous, anchorable stable oracle prices during non-trading hours means that the market often has to rely on a "last external price + internal order book" to form a limited internal pricing range (for example, trade.xyz restricts the maximum fluctuation to 1/max_leverage).
The risk arises at the reopening switch point: the external market will instantaneously provide a clear external price, and if it significantly gaps from the internal pricing during the closure, the system will either continue to be clamped, resulting in a severe deviation between the external price and the tradable price, or experience rapid repricing when switching back to external anchoring; both paths can trigger liquidation pressure in a short time, potentially leading to an increase in ADL events.
0x4 Risk Control Strategies
1) Stable Oracle Price
For non-24/7 trading assets like stocks, the main challenge lies in pricing during market closures: there is insufficient external anchorable stable quotes, making the market more susceptible to manipulation or drifting under thin depth.
Current common solutions in the industry mainly fall into two directions:
Directly stop updating the oracle price, pausing or restricting trading during that period (for example, the Lighter protocol only allows position reductions during market closures). Protocols like Optium also lower the maximum leverage during market closures and force liquidation of positions exceeding the limit.
Adopt an "internal pricing" mechanism similar to trade.xyz, relying on the internal market liquidity and algorithms to maintain operation in the absence of external data.
These two types of solutions intuitively reflect the trade-offs in protocol design between safety and user experience. The first solution employs stricter risk control mechanisms but at the cost of significantly sacrificing user trading experience. The second solution, while maintaining trading continuity, is prone to deviations between internal pricing and the actual value of the underlying asset due to the lack of external references.
During market closure phases, the protocol should avoid allowing pricing to completely degrade into a "purely internal price" and instead introduce referenceable external anchors to reduce the risks of dislocation and gaps. Optional references include:
Blue Ocean ATS
As a trading venue related to after-hours/night trading, it can provide a certain degree of continuous price reference during market closures (more timely than the "last closing price"), used to assist in generating market closure oracle prices or as a monitoring benchmark for price dislocation.
IG weekend CFD quotes
Weekend CFD quotes can provide alternative price signals for "weekend market expectations," suitable for use as external anchors or monitoring references during market closures, helping to identify potential "gaps at opening" in direction and magnitude.
The commonality of these two sources is that they "can provide price signals during market closures," but they do not represent the same market structure as the underlying stock, making them more suitable as anchors/references and risk warning signals rather than unconditional equivalent substitutes.
2) Price Verification
The oracle prices in HIP-3 come from the relayer servers set by builders, which may raise centralization concerns. It is recommended that builders establish a price verification mechanism that allows any user or institution to verify the authenticity and fairness of prices off-chain (similar to RedStone, packaging the price values along with their data sources and signature proofs on-chain).
- Public Data
Algorithm Specifications: Disclose detailed algorithms and process mechanisms
Data Source List: Each data source should be public and not subject to builder intervention, with detailed interfaces and parameters disclosed
Price Push Specifications: Permissions for setOracle calls, triggering frequency, and fluctuation limits
b. Price Proof
Generate a corresponding proof (Proof) for each setOracle call, including:
Inputs: The raw responses (or normalized fields) from each data source at that time point, along with the sampling timestamp.
Computation: Verifiable intermediate quantities, intermediate results of each calculation
Outputs: The oracle price recorded on-chain for that instance
Serialize the Proof to obtain proofHash, and the oracleUpdater signs the proofHash.
c. Proof On-Chain
Maintain a list that writes each ProofHash into a Merkle tree in chronological order
Publish the MerkleRoot and put it on-chain at fixed intervals (e.g., every hour/day)
d. Verification
Provide open-source tools or web pages to input the corresponding time period or a specific setOracle tx hash to retrieve all the above data
Verify signatures, timestamps, MerkleRoot, etc.
Compare the oracle price calculated through the public algorithm
3) Risk Monitoring
Price verification transforms the setOracle process into "verifiable and auditable," addressing the issue of whether the price feed is trustworthy; however, it cannot prevent the market from spiraling out of control during operation—price feed interruptions, price deviations, and depth degradation, once combined with a large open interest (OI), can easily turn localized anomalies into systemic risks of chain liquidations or even ADL. Therefore, market anomalies should be transformed into observable signals as early as possible, and actions should be triggered during the window period to bring risks back within controllable boundaries.
1. Price Side
a. Oracle Price Feed Failure
Monitoring Indicators:
- Directly use on-chain observable quantities to determine whether the price feed is blocked:
Threshold Levels:
Action:
Level 1: Conduct health checks on the relayer, switch to backup relayer nodes; issue alerts containing health reports and information on all relayer nodes.
Level 2: Call setOpenInterestCaps to lower the OI cap:
b. Price Dislocation
Monitoring Indicators:
Thresholds:
Level 1: In A, B, D, ≥ 2 exceed the threshold
Level 2: In A, B, C, D, ≥ 3 exceed the threshold and persist for X seconds
Action:
Level 1: Call setOpenInterestCaps to lower the OI limit
Level 2: Accompanied by prolonged deviations, gradually update the margin table, stepwise reducing max leverage; enable the clamp mechanism for the relayer
Level 3: Continuously issue alerts under Level 2 conditions, ultimately leaving the decision to the builder on whether to call haltTrading to stop the market
- Order Book Side
a. Depth Withdrawal
Monitoring:
depth_band(±x%): The actual order volume within the ±x% price range near mid
spread = bestAsk - bestBid: The price difference, used to measure whether the order book is "broken"
aggressiveVolume_Δt: The volume of active orders executed within Δt (taker volume, aggregated by trade side)
impactratio = aggressiveVolumeΔt / depth_band: The acceptance ratio
Judgment:
Risk increases when the following combinations occur:
- depthband decreases, accompanied by increases in spread and impactratio
Action:
Level 1: Call setOpenInterestCaps to lower the OI limit = current OI, restricting position increments
Level 2: Call setMarginTableIds to forcibly lower leverage, avoiding the generation of high-leverage positions while forcibly liquidating some high-leverage, high-risk positions
b. False Orders
Monitoring:
- depth_band rises sharply and then suddenly falls within a short time
Action:
Level 1: Trigger a warning when the upper limit is reached, setting the OI cap = current OI
Level 2: If accompanied by severe price dislocation, consider stopping the market
- Position Side
The goal of monitoring the position side is not to "predict direction," but to identify whether the market has shifted from trading-driven to position-driven speculation: when OI accumulates rapidly, positions become highly concentrated, and the majority's profits and losses approach extremes, any external disturbance to the price is more likely to be amplified into a liquidation waterfall / ADL. Therefore, actions on the position side generally have a lower priority than those on the price side and order book side.
a. Short-term OI Overweight
Monitoring:
OI_notion: Open interest size
Volume24hnotion: 24-hour trading volume
Calculate OInotion / Volume24h_notion; a rapidly rising ratio indicates a shift from short-term positions to position-driven speculation, usually signaling that the market is about to experience significant volatility.
Action:
- Level 1: Trigger a warning when the upper limit is reached
b. Majority Profits and Losses
Monitoring:
Majority Side: Within the statistical window, the side with more positions (Long or Short)
avgEntry_major: Average entry price of the majority positions
size_major: Size of the majority positions
Majority Profits and Losses:
Majority Profit and Loss Ratio:
Action:
Level 1: Trigger a warning when the upper limit is reached
Level 2: If the upper limit continues to be triggered, consider calling setOpenInterestCaps to lower the OI cap
0x5 Conclusion
The core narrative of HIP-3 is essentially: transforming the "new listing" process from one decided by a few individuals into a protocol capability that can be invoked once thresholds are met—builders can stake to launch their own perp DEX on HyperCore, initially listing a small number of markets for free, and then auctioning for more slots, thereby changing market expansion from "waiting for approval" to "expanding according to rules."
However, it is equally clear that HIP-3 does not eliminate risk; it merely rewrites the location and form of risk. What was previously underwritten by platform risk control now increasingly relies on the quality of builder inputs and operations: the pricing and frequency of setOracle, the selection and constraints of markPx, the tiered leverage of the margin table, the "internal range" for non-24/7 asset pricing during market closures, and the power of haltTrading, which can both stop losses and amplify them. Any mismanagement in any of these links can be amplified into concentrated liquidations in thin depth, further triggering gaps and ADL—the issue is no longer "can it be listed," but "once listed, can it run smoothly."
The core response at the protocol level to this "risk outsourcing" is to transform permissions into accountable permissions: staking + validator voting penalties create clear cost boundaries for builders' "operational mismanagement"; at the same time, constraints on price and leverage (clamp, update intervals, volatility limits, isolated margin) attempt to contain the most dangerous tail scenarios within controllable limits. Thus, the real proposition of HIP-3 becomes: expansion relies on openness, safety relies on constraints, and long-term viability relies on verifiability and accountability.
HIP-3 does not make new listings freer; it makes them more standardized—deployable, operable, and accountable. And for standardization to truly run smoothly, it ultimately depends on the quality of the implementation of oracle/leverage/risk control parameters and runtime monitoring.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
