From Beginner to Risk Control: A Practical Guide to HIP-3 Security for Builders

HIP-3 (Hyperliquid Improvement Proposal 3) has been online on the mainnet for about three months. Since its launch, the cumulative transaction volume of third-party custom marketplaces has exceeded US$13 billion. This means that "listing new products" is transforming from an internal process of exchanges into an infrastructure capability that can be directly called by external developers.

In centralized exchanges, "listing new products" is inherently a platform power: which products can be traded, when they will be listed, and how their parameters will be set are all basically determined by the operations and risk control processes. Even on-chain, perpetual contracts, a category that is heavily reliant on infrastructure, are often constrained by the deployment and governance pace of a few teams.

HIP-3's innovation lies in shifting the process from "platform approval" to "open interfaces": As long as the conditions are met, third parties can deploy new perpetual contract markets on the same trading and clearing platform, systematically outsourcing the centralized power to list new contracts to the ecosystem. This improvement not only lowers the barrier to innovation but also enhances market scalability. However, the potential security risks brought about by open interfaces cannot be ignored. Ensuring the compliant operation of these markets and the absence of malicious behavior remains a critical issue that needs rigorous scrutiny in the design of HIP-3.

0x1 Hyperliquid: The base of HIP-3

Hyperliquid is a perpetual trading infrastructure running on its own blockchain. The most crucial point for HIP-3 is that matching, clearing, and settlement are provided uniformly by the protocol foundation, allowing market capabilities to be reused, rather than building a trading system from scratch.

Hyperliquid employs a two-tier architecture:

HyperCore: A customized L1 blockchain optimized for contract trading, capable of processing 200,000 orders per second with deterministic finality.

HyperEVM: The application layer that runs smart contracts and is compatible with EVM.

Hyperliquid's native perp marketplace (validator-operated perps) still resembles the traditional centralized exchange (CEX) process for listing: the official platform lists perpetual contracts based on the community's wishes, while delisting is decided by validator nodes through voting.

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

The Hyperliquid protocol will support perpetual contracts deployed by builders (HIP-3), a key milestone in achieving a fully decentralized perpetual contract listing process.

0x2 HIP-3: Marketplace for Developer Deployment

HIP-3's concept is simple: without altering the Hyperliquid trading and clearing platform, it opens up the ability to "add perpetual markets" to qualified builders. Builders are responsible for defining the key parameters of the market and price feed/operational responsibilities, while the protocol uses a unified margin and clearing engine to handle execution and risk control boundaries; thus, "adding a new market" transforms from a platform process into a callable standard interface.

In short: the builder can list a perpetual contract market based on the HyperCore engine, and feed prices and adjust market parameters by themselves.

Boundaries of Builder's Responsibilities

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

Market definition:

The official documentation summarizes this as Oracle definition + contract specifications. At an operational level, it includes at least:

Oracle definition:

This includes defining the initial oraclePx and the price source. When defining the market, the builder should clearly define a target asset or data source that is well-defined, difficult to manipulate, and has economic substance; an initial oraclePx needs to be provided when registering the asset.

Contract Specifications:

Explicitly define market parameters such as "asset symbol/minimum order unit/maximum leverage" (coin, szDecimals, maxLeverage, etc.) in the API interface.

DEX selection:

The Builder first deploys a perp DEX (each DEX has independent margin, order book, and deployer settings), and can choose any quoted asset as collateral for the DEX (such as USDC). Each perp market will correspond to a DEX.

Market operation:

The official list includes setting oracle prices, leverage limits, and setting the market if needed. In detail:

Update price feed:

The Oracle Price in the market is continuously fed through the setOracle interface.

Leverage limit:

Maximum leverage is constrained by allocating corresponding margin tables to assets—the leverage limit is set in tiers according to position size, thereby limiting the available leverage to a preset range.

Settlement will be made if necessary.

The Builder can use the haltTrading interface to halt the market and trigger settlement—canceling all orders and settling positions at the current mark price; the same action can also be used to resume trading.

Currently, the HIP-3 market only supports isolated positions, but cross positions may be supported in the future.

Market Launch Process

Stake

The mainnet requires builders to maintain a 500k HYPE stake; and even if they shut down their markets on their DEXs, the staking requirement must still be maintained for 30 days.

Build

Once the staking threshold is met, the builder can deploy a perp DEX. Each perp DEX is an independent trading domain: independent margin, order book, and deployer settings.

Set collateral

The collateral of this DEX can be any quote asset, but if the quote asset loses its permissionless quote asset status (determined by validator voting), the perp DEX that uses it as collateral will be disabled.

Add markets

The first three markets can be deployed directly;

When adding new markets, it is necessary to obtain "new quotas" through Dutch auctions.

5. Operate markets

Once the market is launched, the builder's job becomes "to stabilize the market," which is market operation.

6. Unstake

Once all markets on the DEX have settled, the staked 500k HYPE will be unlocked. After initiating an unstake, it will enter a 7-day unstaking queue, during which time the staked HYPE may still be subject to staking penalties.

Dutch auction: The current cycle is 31 hours per round, and the starting price for each bid is 2 times the previous final price (sold price/lowest price).

SetOracle: Three Types of Price Inputs

In HyperCore, the oracle price is mainly used to anchor and calculate funding fees, while the mark price serves as the mark price for risk control scenarios such as margin calls and liquidation (and is 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 rather the median of three calculated prices:

oraclePx + EMA(midPx - oraclePx)

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

Weighted median of perp mid prices from multiple CEXs

In HIP-3, the functions of Oracle price and mark price remained unchanged, but the calculation mechanism changed:

setOracle input

a. OraclePx (required)

The core definition is consistent with HyperCore.

b. markPx (optional)

You can submit 0 to 2 sets of external mark prices as the actual mark prices to calculate candidate values.

c. externalPerpPx (required)

This serves as a reference value input for the mark price, preventing sudden deviations in the mark price.

Builders often deploy layer nodes for price feeding, OraclePx

The relayer combines external price sources for comprehensive calculation; markPx is calculated using a custom algorithm by the relayer; externalPerpPx is the weighted median of perp mid prices from multiple CEXs.

2. Actual mark price

The mark price in HIP-3 does not directly use the price feed from setOracle:

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

Combine the local mark and markPx (groups 0–2), take the median, and obtain the new mark price.

3. Set Oracle restrictions

Update frequency: There should be at least a 2.5-second interval between two calls. If markPx is not updated within 10 seconds, it will revert to the local mark price.

Range limit: markPx fluctuations will not exceed ±1% each time; all prices will be clamped to within 10 times the start-of-day value.

7x24H & Non-7x24H: Differences in Pricing Mechanisms

In HIP-3, the perpetual contract market supports the listing of any asset, which can be divided into 7x24H assets (traded around the clock) and non-7x24H assets (traded only during specific trading hours; the spot market cannot trade during non-trading hours). The trading time characteristics of these two types of assets determine the difference in their price acquisition methods.

For 24/7 assets (such as BTC), a stable price can be obtained from a combination of CEX/DEX or trusted oracles:

For non-24/7 assets (such as stocks), sufficient liquidity and relatively stable external market quotes are only available during trading hours. To maintain the normal operation of such assets around the clock in HIP-3, a different pricing mechanism needs to be used during market closures.

Taking the stock perpetual contract market on trade.xyz as an example:

During stock market trading hours, stable price feeds are provided by external oracle services such as Pyth.

During stock market closures, price adjustments are made based on the stock's previous closing price, taking into account internal buying and selling pressure. Mark prices are limited to 1/max_leverage of the previous closing price fluctuation (e.g., Tesla 10x -> 10%).

liquidation

The HIP-3 market mainly reuses HyperCore's liquidation logic, so the liquidation trigger logic follows the platform: when the isolated position value is insufficient to cover the maintenance margin requirements, it enters a liquidation state.

The judgment regarding liquidation is based on the mark price, not the price of a particular transaction.

Liquidation price formula:

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

l: That is, the maintenance margin rate

The value of MAINTENANCE_LEVERAGE comes from the margin tier corresponding to this position: first, the maintenance margin rate (mmr) is read from this tier.

If there are tiers, the MMR of the position corresponding to the liquidation price is used based on which tier the notional value of the position falls into.

margin_available

isolated: isolated_margin - maintenance_margin_required

Once the system enters a liquidation state, it will prioritize closing positions using market orders through the order book. If the risk can be brought back to a safe range, the remaining margin will still belong to the trader.

However, when there is insufficient depth or a gap, the actual average closing price may be significantly lower than the mark price, thus forming a "liquidation gap".

Isolated position value: refers to the net value of an isolated position at the current mark price (the profit or loss of the position minus the margin tied to the position).

ADL:

In this case, the ADL (Auto-Deleveraging) mechanism can be used as a fallback in extreme situations:

When the isolated position value becomes negative, the ADL (Advanced Position Limitation) is triggered. The opposing positions are sorted by unrealized profit/loss and leverage, and the positions are forcibly reduced/closed at the previous mark price. The profits from the opposing positions are used to fill the gap, ensuring that the system does not incur bad debts.

The sorting criteria are calculated according to the following standards:

Previous mark price: refers to the previous mark price recorded by the system before the ADL was triggered.

example:

Before triggering ADL, the system's mark price was 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 orders in the order book were very thin. After the market orders were placed, the actual average transaction price was 2,910 (which is -3% compared to 3,000).

Losses on long positions are settled at 2,910, which may drive the isolated position value of the position below 0 (creating a gap), thus triggering the Adaptive Limit (ADL).

ADL then selects positions from the opposing side (profitable short positions), and settles them by forcibly reducing/closing the positions at the previous mark price of 3,000, thus transferring the gap to "the profitable side passively earning less".

0x3 Risk Overview: Accountability Constraints and Key Risks

Slashing: Authorized means to hold perpetrators accountable

While HIP-3 delegates the "right to add and operate" to the builder, it also enshrines responsibility in the protocol through a set of enforceable staking rules: the builder must stake HYPE, and if it is deemed to be improperly operated, the validators can vote to stake and burn its stake.

Pledge Requirements

The mainnet requires the builder to maintain 500k HYPE stake, and even if the builder suspends all of its market activity, it must continue to maintain this stake for 30 days (the liability will not be immediately relieved due to the suspension of trading).

Triggering and Voting

In the event of malicious market manipulation, validators can initiate and execute a stake-weighted vote to determine whether to slash the builder's stake.

Judgment principles

The official statement clarifies that fines and confiscations will not differentiate between reasons such as "malicious intent/insufficient capability/stolen private key," but will focus on whether the builder's actions have resulted in invalid states, prolonged downtime, or performance degradation.

Fines and confiscation range

The penalty percentage is determined by a vote of validators, with a reference upper limit:

Causes invalid state or prolonged downtime: up to 100%

Brief downtime: up to 50%

Performance degradation: up to 20%

Forfeited staked tokens will be destroyed, rather than being compensated to affected users.

Parameter configuration risks

setOracle

Oracle prices typically originate from the builder's relayer server, which carries a risk of centralization. If the private key is leaked or a DDoS attack occurs, the oracle price in the market may be maliciously manipulated or remain unanchored for an extended period.

haltTrading

The Builder can cancel all orders in the market and close them at the current mark price via haltTrading.

This operation should be used with caution, for example in the following scenarios:

When it is detected that the market is being maliciously manipulated by an attacker, haltTrading is invoked to close the position directly at the mark price, which will directly realize the attacker's unrealized profit (the attacker might have had difficulty finding enough counterparty orders originally), and may result in bad debts.

setMarginTableIds/InsertMarginTable

InsertMarginTable: Defines a new margin table that specifies the margin requirements and maximum leverage for a particular asset class.

setMarginTableIds: Binds a market to a specified marginTableId.

In a market with low liquidity or insufficient market-making capabilities, setting the maximum leverage too high will increase the probability of ADL triggering.

Suddenly switching marginTableId is equivalent to modifying the maintenance margin ratio of a user's position, which may cause a large number of accounts to change from safe to liquidated at the same time, triggering a chain of liquidations.

setMarginModes

Currently, HIP-3 only allows isolated margins, but cross margins may be supported in the future. A single DEX may contain both high-liquidity and low-liquidity markets, and cross margins could potentially transmit low-liquidity risk to high-liquidity markets. Therefore, until a mature official solution is provided, it is not recommended that builders introduce cross margins.

Oracle risks

For assets operating 24/7, the main risks lie in the accuracy and stability of the external Oracle service they rely on, as well as the centralized risks associated with the relayer server mentioned earlier.

For assets that are not traded 24/7, the greater risk lies in obtaining or calculating the oracle price during the asset's non-trading hours.

Taking trade.xyz as an example, during non-trading hours, the price is calculated using a combination of the last external oracle price and the internal market price. On weekends, the perpetual stock market lacks liquidity (order books are thinner and market makers reduce quotes), and there is no external oracle price to anchor it. Even with a hard cap on price fluctuations (1/max_leverage), this limit is still too high for low-volatility assets; price fluctuations within this range could still lead to widespread liquidations or even accounts receivable (ADL).

On December 14, 2025, the XYZ100-USDC (pegged to NASDAQ100) on trade.xyz was manipulated by the attackers. The attackers created a short position of 398 XYZ100 (~10M USDC), which caused the price to decouple severely. A large number of long positions were liquidated, and the liquidation caused the price to continue to fall, eventually resulting in the liquidation of ~13M USDC of long positions.

On the other hand, during non-trading hours, there is a lack of continuous and anchorable stable oracle prices, and the market often has to rely on the "last external price + internal order book" to form a limited internal pricing range (for example, trade.xyz limits the maximum fluctuation range to 1/max_leverage).

The risk arises at the re-opening switch point: the external market will instantly provide a clear external price. If there is a significant gap between it and the internal pricing during the market closure, the system will either continue to be clamped, resulting in a severe deviation between the external price and the tradable price, or a rapid repricing will occur when switching back to the external anchor. Both paths may trigger concentrated liquidation pressure in a short period of time, leading to an increase in ADL events in extreme cases.

0x4 Risk Control Strategy

1) Stable Oracle Price

For non-24/7 tradable assets like stocks, the main challenge lies in pricing during market closures: there is a lack of stable external quotes, making the market more susceptible to manipulation or drifting on its own with limited depth.

Currently, common solutions in the industry mainly fall into two categories:

This can directly stop updating the oracle price, suspend or restrict trading during that period (for example, the Lighter protocol only allows position reduction during market closures). Protocols like Optium may also lower the maximum leverage during market closures and force liquidation of positions exceeding the limit.

It adopts an "internal pricing" mechanism similar to trade.xyz, relying on the market liquidity and algorithm within the protocol to maintain operation when external data is lacking.

These two approaches clearly reflect the trade-offs made in protocol design regarding security and user experience. The first approach employs a stricter risk control mechanism, but at the cost of significantly sacrificing the user's trading experience. While the second approach maintains trading continuity, the lack of external references can easily lead to a deviation between internal pricing and the actual value of the underlying asset.

During market closures, it's crucial to avoid allowing negotiated pricing to completely degenerate into a "pure internal price." Instead, a referable external anchor should be introduced to mitigate the risks of decoupling and price gaps. Possible 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 the market closure period (more timely than the "last closing price"), which can be used to assist in generating the market closure oracle price or as a monitoring benchmark for price decoupling.

IG weekend CFD quotes

Weekend CFD quotes can provide alternative price signals for "weekend market expectations," making them suitable as an external anchor or monitoring reference during market closures, helping to identify the direction and magnitude of "potential opening gaps" in advance.

Both of these sources share the characteristic of "providing price signals during market closures," but they do not have the same market structure as the underlying stock spot price. They are more suitable as anchors/comparisons and risk warning signals than as unconditional equivalent substitutes.

2) Price Verification

HIP-3's oracle prices originate from the relayer server set up by the builder, which may be subject to centralized disputes. Therefore, it is recommended that the builder construct a price verification mechanism that allows any user or institution to verify the authenticity and fairness of the price off-chain (similar to RedStone, which packages the price value along with its data source and signature proof onto the blockchain).

Public data

Algorithm Specification: Disclose detailed algorithms and process mechanisms

Data source list: Each data source should be public and not subject to builder intervention, and should expose detailed interfaces and parameters.

Price push specifications: Oracle call permissions, trigger frequency, and fluctuation limits.

b. Proof of Price

For each `setOracle` call, generate a corresponding proof, which includes:

Inputs: The raw response (or normalized field) of each data source at this point in time, and the sampling timestamp.

Computation: Computable intermediate quantities, intermediate results of each calculation step.

Outputs: The oracle price recorded on the blockchain this time.

The Proof is serialized to obtain the proofHash, and oracleUpdater signs the proofHash.

c. Proof on the chain

Maintain a list and write each ProofHash into a Merkle tree in chronological order.

MerkleRoot is published and uploaded to the blockchain at fixed intervals (e.g., hourly/daily).

d. Verification

Provide an open-source tool or webpage that allows you to retrieve all the above data by inputting the corresponding time period or the tx hash of a specific SETOracle operation.

Verify signature, timestamp, MerkleRoot, etc.

Compare Oracle prices calculated using publicly available algorithms.

3) Risk monitoring

Price verification makes the setOracle process "recalculated and auditable," addressing the reliability of price feeds; however, it cannot prevent the market from spiraling out of control—price feed interruptions, price deviations, and depth degradation, when combined with a large open interest (OI), can easily escalate local anomalies into systemic risks such as chain liquidations or even ADL (Alternate Limits). Therefore, market anomalies should be made observable signals as early as possible and triggered during the window of opportunity to bring risks back to a controllable level.

1. Price side

a. Oracle price feed failure

Monitoring indicators:

Determine whether the price feed is blocked directly using on-chain observables:

Threshold grading:

Action:

Level 1: Perform a health check on the layer, switch to a backup layer node; issue an alert containing a health report and information on all layer nodes.

Level 2: Call setOpenInterestCaps to lower the OI cap:

b. Price de-anchoring

Monitoring indicators:

Threshold:

Level 1: Among A, B, and D, at least two exceed the threshold.

Level 2: Among A, B, C, and D, at least 3 exceed the threshold and persist for X seconds.

Action:

Level 1: Use setOpenInterestCaps to lower the OI cap.

Level 2: With prolonged deviations, the margin table is updated gradually, and maximum leverage is reduced progressively by tier; the Relayer enables the clamp mechanism.

Level 3: Continues to issue warnings in Level 2 mode, with the builder ultimately deciding whether to call haltTrading to stop the market.

2. Betting odds side

a. Deep detachment

monitor:

depth_band(±x%): The actual order volume within the price range of ±x% around mid.

spread = bestAsk - bestBid: price difference, used to measure whether the order book is "broken".

aggressiveVolume_Δt: Taker volume within Δt (aggregated by trade side).

impact_ratio = aggressiveVolume_Δt / depth_band: bearing ratio

Judgment: The risk increases when the following combination patterns appear:

The depth_band decreases, accompanied by an increase in spread and impact_ratio.

Action:

Level 1: Call `setOpenInterestCaps` to lower the OI cap by the current OI, limiting the increase in position size.

Level 2: Calling `setMarginTableIds` forcibly reduces leverage, preventing high-leverage positions from being created and forcibly closing some high-leverage, high-risk positions.

b. Fake orders

monitor:

depth_band rises briefly and then drops suddenly.

Action:

Level 1: Call setOpenInterestCaps to lower the OI cap = current OI

Level 2: If accompanied by a severe price decoupling, consider suspending the market.

3. Position side

The goal of position-side monitoring is not to "predict the direction," but to identify whether the market is shifting from trading-driven to position-based speculation: when open interest (OI) accumulates rapidly, positions are highly concentrated, and the majority's profit or loss is approaching extreme values, any exogenous price disturbance is more likely to be amplified into a liquidation waterfall/ADL (Advanced Liquidation Drought). Therefore, position-side actions generally have a lower priority than price-side and order book-side actions.

a. Overemphasis on short-term OI (Online Identification)

monitor:

OI_notional: Open Interest

Volume_24h_notional: 24-hour transaction volume

Calculate OI_notional / Volume_24h_notional. A rapid increase in the ratio indicates that the market is shifting from short-term holding to long-term speculation, which usually foreshadows sharp market fluctuations.

Action:

Level 1: Trigger an alert when the upper limit is reached.

b. Majority profit and loss

monitor:

Majority Side: Within the statistical window, the side with more holders (Long or Short).

avgEntry_major: Average opening price of most positions

size_major: Size of the majority position

Majority profit and loss:

Majority profit/loss ratio:

Action:

Level 1: Trigger an alert when the upper limit is reached.

Level 2: If the cap is continuously triggered, consider calling `setOpenInterestCaps` to lower the OI cap.

0x5 Conclusion

The core narrative of HIP-3 is to change the process of "updating new products" from a process where a few people make the decisions to a protocol capability that can be accessed as long as a threshold is met. By staking, builders can launch their own perp DEX on HyperCore, launch a small number of markets for free first, and then compete for more slots through auctions, thereby changing market expansion from "waiting for approval" to "expanding according to the rules".

However, it's equally clear that HIP-3 didn't eliminate risk; it merely rewrote its location and form. What was previously covered by platform risk control now rests more on the builder's input and operational quality: the price feed and frequency of `setOracle`, the selection and constraints of `markPx`, the tiered leverage of the margin table, the "internal range" for pricing of non-24/7 asset market closures, and the power of `haltTrading`—which can both stop losses and amplify them. Any mishandling in any of these areas can be magnified into concentrated liquidation within a thin market depth, further triggering gaps and ADLs—the question is no longer "can it be done?", but "can it run stably after it's done?"

The core of addressing this "risk outsourcing" at the protocol level is to transform authority into accountable authority: staking plus validator voting penalties give builder "operational misconduct" a clear cost boundary; at the same time, price and leverage constraints (clamp, update interval, volatility cap, isolated margin) attempt to bring the most dangerous tail scenarios within a controllable range. Thus, the real proposition of HIP-3 becomes: expansion relies on openness, security relies on constraints, and long-term sustainability relies on verifiability and accountability.

HIP-3 doesn't make new deployments more flexible, but rather more standardized—enabling deployment, operation, and accountability. However, for standardization to truly run smoothly, it ultimately depends on the quality of the implementation of Oracle/leverage/risk control parameters and runtime monitoring. If you are designing market access, parameter templates, alerting, and emergency response processes based on HIP-3, or require auditing and ongoing security support, please contact BlockSec.