Why the Non-Mainstream HIP-3 Market Doesn't Work

Original Author: Jsquare Investment Team

Hyperliquid's HIP-3 upgrade introduced developer-deployed perpetual contract markets, aiming to theoretically support perpetual contract trading for almost any asset. This means that various assets, from crypto assets and commodities to prediction markets, can be structured as perpetual contracts.

However, HIP-3's oracle design introduces a critical limitation: each oracle price update can only deviate by a maximum of ±1% from the previous price. The likely intention behind this "1% cap" mechanism is to act as a safety measure, ensuring smooth price changes and preventing malicious or abnormal oracle data updates.

But in practice, this mechanism severely limits support for fast-moving or non-continuously priced markets—where real prices often experience significant jumps within extremely short timeframes, even exhibiting "jump" changes rather than smooth curves.

HIP-3's Oracle Mechanism and the 1% Update Rule

Under the HIP-3 mechanism, each developer-deployed perpetual contract market relies on an oracle data source provided by the deployer. This oracle needs to be updated frequently (approximately every 3 seconds, with a minimum update interval of 2.5 seconds). The key point is: each update can only deviate by a maximum of 1% from the previous mark price. If no oracle update occurs within 10 seconds, the system will fall back to using the latest mid-price of the market's best bid/ask as the mark price. In other words, HIP-3 imposes a strict rate limit on price changes: regardless of how much the underlying asset's real-world value changes, the on-chain perpetual contract price can only deviate by a maximum of 1% per oracle update cycle.

This design enhances system stability to some extent and can guard against sharp price fluctuations caused by erroneous data or oracle anomalies. It ensures a smooth and continuous price path, thereby reducing the risk of cascading liquidations triggered by a single large price jump, while also giving validators reaction time upon detecting suspicious oracle updates. Furthermore, HIP-3 introduces other safety mechanisms to maintain market integrity, such as a price cap mechanism limiting prices to within 10 times the day's opening price, and an open interest growth cap mechanism preventing uncontrolled market expansion in short periods.

However, the 1% price deviation cap is a double-edged sword. For markets like mainstream crypto assets, which typically do not experience violent fluctuations within seconds, this mechanism can effectively reduce oracle risk. But for markets that genuinely require large or instantaneous price adjustments, this limitation becomes a severe performance bottleneck.

Why Non-Mainstream HIP-3 Markets Fail

The "non-mainstream niche markets" referred to here are those whose underlying value may change drastically within extremely short timeframes or in a jump-like manner. HIP-3's oracle system is essentially designed for relatively smooth, publicly verifiable market data, such as highly liquid crypto asset prices, making it ill-suited for these types of markets. Below, we examine several typical market types and explain why the 1% oracle update cycle limit makes HIP-3 unsuitable for them:

1. Prediction Markets

Perhaps the most typical example is prediction markets similar to binary options. For most of the time, their prices may fluctuate slowly, but when an event outcome is determined, the real price should immediately jump to 0 or 1. Odds for sports events or elections often change in a stepwise fashion rather than a smooth curve; for instance, a touchdown in a football game can instantly change the win probability by several percentage points. Under HIP-3's 1% oracle update cycle limit, on-chain prices cannot achieve such jumps. For example, after an outcome is determined, moving the price from 0.50 to 1.00 would require a series of small 1% increments. During this delay, the on-chain perpetual contract market price would severely deviate from the true value, allowing any trader who knows the result to easily exploit this price difference for risk-free arbitrage by buying the "yes" option cheaply and profiting as the price slowly rises. This approach is neither realistic nor safe, as it undermines the core function of prediction markets. Outcomes need to be settled quickly, and HIP-3's continuous oracle update speed is insufficient to ensure fairness or efficiency.

2. Interest Rate and Yield Markets

Interest rates can sometimes fluctuate significantly within short periods, especially during monetary policy announcements or economic data releases. For example, an unexpected decision by the Federal Reserve could almost instantly move the 2-year Treasury yield by dozens of basis points. Perpetual contracts linked to interest rate indices could experience similar sudden volatility. Under HIP-3's oracle update cycle limit, even if the underlying yield jumps quickly, the on-chain price can only adjust gradually, failing to reflect the new market situation promptly. This not only creates arbitrage opportunities but may also lead to inaccurate margin calculations (as traders' positions are based on stale prices for an extended period). Therefore, without adjustments, HIP-3's model cannot effectively support interest rate markets or any indicators prone to discontinuous repricing.

3. Low-Liquidity or Infrequently Priced Assets

Some HIP-3 deployers may wish to list private equity or other low-liquidity investment targets as perpetual contracts. These assets are not continuously traded on public markets, so their valuations are typically only updated during funding rounds or upon new information releases, often involving significant jumps. For instance, a startup valued at $100 million in one funding round might rise to $150 million in the next. Anyone attempting to maintain a fair-value oracle for such an asset would face this problem: when a new valuation or event occurs, the price may need a one-time adjustment of tens of percentage points. In a HIP-3 market, this change would be forced to spread across multiple small oracle update cycles. During this period, the perpetual contract market cannot reflect the new valuation, failing to achieve the intended purpose of trading.

Why the 1% Cap Is Still Not Fast Enough

The core issue is that the 1% incremental cap essentially imposes a speed limit on the movement of on-chain perpetual contract prices. If an asset's real price suddenly needs to rise by 10%, HIP-3's oracle would require multiple updates to reach that level. If the required price change is 50% (as in the binary event example), it might take dozens of updates, causing a delay of several minutes. For competitive traders, even a few seconds of price lag is exploitable, so minutes of lag would be catastrophic for market integrity.

It's important to note that this is not just an issue of oracle latency (i.e., data retrieval speed), but a deliberate speed limit on price changes. Even if an off-chain oracle source, such as a Web2 API or a Pyth feed, instantly reports a large price movement, the Hyperliquid chain would still absorb this change bit by bit. The original intention is to avoid sharp price shocks, but it inevitably creates a discrepancy between on-chain and real prices when the latter changes rapidly. Traders observing external prices can trade on Hyperliquid at the lagging price until the oracle gradually catches up. This creates risk-free arbitrage opportunities, with the risk borne by slower or unaware participants. Such arbitrage not only harms less-informed traders but could also be exploited to extract value from liquidity providers or insurance funds through slow oracle updates, thereby draining system capital.

From a risk management perspective, the 1% limit was set to maintain market stability, but in these scenarios, it inadvertently causes some HIP-3 markets to sacrifice price accuracy for safety. The value of a perpetual contract market lies in its price closely reflecting the true value of the underlying asset. If the price lags severely, the market cannot fulfill its essential function. Therefore, under the current 1% price deviation cap, certain perpetual contracts are nominally feasible but practically difficult to operate.

Potential Mitigations and Future Improvements

Addressing the limitations for fast-moving markets requires protocol-level adjustments. Various strategies have been proposed to enable HIP-3 or its successors to support rapid price changes without sacrificing security. Below are some key mitigation measures and improvement directions that could potentially allow perpetual contracts to cover these challenging markets:

1. Increase the Oracle Update Cap

A straightforward solution is to relax the strict 1% limit for markets requiring faster responses. A HIP-3 revision proposal co-authored by Pyth suggests making the maximum price deviation configurable per market. Deployers could set a higher cap (suggested up to 5% per update) based on the asset's characteristics, rather than a hardcoded 1%. This flexibility would allow high-volatility markets to adjust prices more quickly. The principle is to prevent mark price lag during extreme events or rapid volatility while still limiting the change magnitude to reduce manipulation risk. Thus, for prediction markets or interest rate perpetuals, a higher threshold could be chosen to allow prices to converge to true value faster.

2. One-Time Updates for Large Price Jumps

Another potential mitigation is to allow special oracle updates when an event concludes or an anomalous jump is needed. For example, in a binary event market, once the outcome is determined, the protocol could permit the oracle to publish the final price (0 or 1) in a single update, bypassing the 1% incremental rule. This could be conditional, such as allowing the final settlement price only at a preset event end time or upon multi-signature verification of the result. Essentially, the oracle would operate in two modes: normal trading mode with small incremental updates, and discontinuous pricing mode bypassing the 1% deviation limit.

3. Eliminate Continuous Oracles

A more radical yet elegant solution is to redesign how certain markets operate, eliminating reliance on continuous oracle price updates altogether. This is precisely what HIP-4 proposes for prediction market perpetual contracts: remove continuous oracles and funding rate mechanisms, letting market prices be determined entirely by trader demand until the event concludes. In this model, event-based perpetual contracts open via a fair-value price discovery auction and then trade freely. The oracle is used only once at settlement to announce the final result (0 or 1) for payout. This way, the problem of needing to update odds every few seconds disappears, and the market can adjust instantly as information arrives. The trade-off is requiring sufficient liquidity and active trading to ensure price accuracy, but it cleverly circumvents oracle limitations and funding rate complexity.

Conclusion

HIP-3 introduced permissionless, builder-deployed perpetual contract markets, a significant innovation that theoretically enables perpetual contracts on any asset. However, the built-in oracle constraint—a maximum price change of only 1% per update—currently hinders HIP-3's support for certain fast-moving markets. The requirement for continuous, incremental price updates means markets where prices jump significantly and suddenly cannot be accurately reflected. In such cases, on-chain prices lag far behind real prices, creating arbitrage opportunities and undermining market integrity. In its current form, HIP-3 is best suited for assets with relatively continuous, moderate volatility (such as major cryptocurrency pairs, stocks, or commodities) and performs poorly for markets that do not follow this pattern.

The good news is that the Hyperliquid community is aware of these limitations and actively seeking solutions. The HIP-4 event futures proposal shows a path forward by eliminating reliance on continuous oracles for prediction markets, while the proposed HIP-3.1 amendment could make the oracle system more flexible. If these proposals are implemented, Hyperliquid could potentially support fast-moving markets in the future without the current severe constraints.

Source: HIP 4 - Event Futures | bedlam

HIP-3.1 Amendment

Hyperliquid Docs

bitget.com

About Jsquare

Jsquare is a research and technology-driven investment firm focused on driving the mass adoption of blockchain and empowering future Alpha opportunities in the Web3 space. Currently, we manage assets exceeding $200 million and operate a dedicated $50 million LP fund. We place high importance on post-investment services, fully leveraging Web2 and Web3 resources to empower our portfolio.