Why is it inevitable that Hyperliquid's HIP-3 will hit a wall?

Author: Jsquare Investment Team

Hyperliquid’s HIP-3 upgrade introduces perpetual contract markets deployed by developers, aiming to theoretically support almost any asset for perpetual trading. This means that assets ranging from cryptocurrencies, commodities, to prediction markets can all be built as perpetual contracts.

However, the design of the HIP-3 oracle introduces a critical limitation: each time the oracle price updates, the change relative to the previous price can be at most ±1%. This “1% cap” mechanism was likely intended as a security measure to ensure smooth price movements and prevent malicious or abnormal oracle data updates.

In practice, this mechanism severely limits support for high-speed or non-continuous pricing markets—where real prices can experience large jumps or “leaps” within a very short period, rather than smooth curves.

HIP-3 Oracle Mechanism and 1% Update Rule

Under the HIP-3 mechanism, each perpetual market deployed by developers relies on an oracle data source provided by the deployer. The oracle needs to be updated at high frequency (roughly every 3 seconds, with a minimum interval of 2.5 seconds). The key point is: each update can only change the mark price by at most 1% relative to the previous update. If no oracle update occurs within 10 seconds, the system will fallback to using the latest bid/ask median price as the mark price. In other words, HIP-3 enforces a strict rate limit on price changes: regardless of how much the underlying asset’s real value changes in the real world, the on-chain perpetual contract price can only deviate by 1% per oracle update cycle.

This design improves system stability to some extent and can prevent sharp price swings caused by erroneous data or oracle anomalies. It ensures a smooth and continuous price path, reducing the risk of chain reactions triggered by large jumps, and provides validators with reaction time when suspicious oracle updates are detected. Additionally, HIP-3 introduces other security mechanisms to maintain market integrity, such as a price cap mechanism limiting prices to within 10 times the opening price of the day; and a position growth limit to prevent market size from expanding uncontrollably in a short period.

However, the 1% deviation limit is a double-edged sword. For mainstream crypto assets, which typically do not experience dramatic fluctuations within seconds, this mechanism effectively reduces oracle risk; but for markets that require large or instantaneous price adjustments, this restriction becomes a serious performance bottleneck.

Why Do Niche HIP-3 Markets Fail?

The “non-mainstream niche markets” refer to markets where the underlying value can change dramatically within a very short time or exhibit leap-like jumps. The oracle system in HIP-3 is fundamentally designed for relatively smooth and publicly verifiable market data, such as high-liquidity crypto assets, and thus struggles with these markets. Below, we examine 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. Most of the time, their prices fluctuate slowly, but when the event outcome is determined, the real price should jump immediately to 0 or 1. Odds in sports or elections often change in a stepwise manner rather than smoothly—for example, a touchdown in a football game can instantly change the probability by several percentage points. Under the HIP-3 1% oracle update limit, on-chain prices cannot realize such jumps. For instance, when the result is known, to move the price from 0.50 to 1.00, it would require a series of small 1% incremental updates. During this delay, the on-chain perpetual market price will significantly deviate from the true value, and traders who know the outcome can easily exploit this discrepancy for riskless arbitrage—buying the “Yes” option at a low price and profiting as the price gradually rises. This approach is neither practical nor safe, as it undermines the core function of prediction markets. Rapid settlement is needed, but HIP-3’s continuous oracle update speed cannot guarantee fairness or efficiency.

2. Interest Rate and Yield Markets

Interest rates can sometimes fluctuate sharply within short periods, especially around monetary policy announcements or economic data releases. For example, an unexpected decision by the Federal Reserve could cause the 2-year Treasury yield to move by dozens of basis points almost instantly. Perpetual contracts linked to interest rate indices may also experience similar sudden swings. Under the HIP-3 oracle update cycle limit, even if the underlying yield jumps rapidly, the on-chain price can only adjust gradually, failing to reflect the new market conditions promptly. This not only creates arbitrage opportunities but may also lead to inaccurate margin calculations (since traders’ positions are based on outdated prices). Therefore, without adjustments, HIP-3 cannot effectively support interest rate markets or any indicators that may undergo non-continuous re-pricing.

3. Assets with Low Liquidity or Infrequent Pricing

Some HIP-3 deployers wish to list private equity or other low-liquidity assets as perpetual contracts. These assets do not trade continuously on public markets, so their valuation is typically updated only during funding rounds or when new information is released, often involving large jumps. For example, a startup valued at $100 million in one funding round might be valued at $150 million in the next. If someone attempts to maintain a fair value oracle for such assets, they face the problem that when new valuations or events occur, prices may need to jump by dozens of percentage points at once. In HIP-3 markets, such changes would be forced to be broken into multiple small oracle updates. During this period, the perpetual market cannot reflect the new valuation accurately, defeating the purpose of trading.

Why 1% Cap Is Still Not Fast Enough

The core issue is that the 1% incremental limit effectively imposes a rate limit on the movement of on-chain perpetual prices. If the real price of an asset needs to rise by 10% suddenly, HIP-3’s oracle would need multiple updates to reach that level. If the required change is 50% (as in the binary example), it might take dozens of updates, causing delays of several minutes. For competitive traders, even a few seconds of price lag can be exploited, making a delay of minutes disastrous for market integrity.

It’s important to note that this is not just about oracle latency (data fetching speed), but about deliberately limiting the rate of price change. Even if an off-chain oracle source—such as a Web2 API or Pyth feed—reports a large price move instantly, Hyperliquid’s chain will still absorb this change gradually. The initial intent is to prevent sharp price shocks, but it inevitably causes discrepancies between on-chain and real-world prices during rapid movements. Traders observing external prices can trade on Hyperliquid at lagged prices until the oracle catches up. This creates riskless arbitrage opportunities, and the risk is borne by slower or inattentive participants. Such arbitrage can harm less-informed traders and may be exploited by actors who slow down oracle updates to extract value from liquidity providers or insurance funds, draining system resources.

From a risk management perspective, the 1% limit was designed to maintain market stability, but in these scenarios, it unintentionally sacrifices price accuracy for safety. The value of perpetual markets lies in their prices closely reflecting the underlying asset’s true value. If prices lag significantly, the market cannot fulfill its fundamental function. Therefore, under the current 1% deviation cap, some perpetual markets are theoretically feasible but practically unworkable.

Potential Mitigation Measures and Future Improvements

Addressing high-speed markets requires protocol-level adjustments. Several strategies have been proposed to enable HIP-3 or its future versions to support rapid price movements without sacrificing security. Key mitigation measures and directions for improvement include:

1. Increasing the Price Change Limit for Oracle Updates

A straightforward solution is to relax the strict 1% limit for markets that need faster responses. A proposed revision to HIP-3, co-authored with Pyth, allows the maximum price deviation per market to be configurable. Deployers can set higher limits based on asset characteristics (e.g., up to 5% per update), rather than hard-coding 1%. This flexibility enables high-volatility markets to adjust prices more quickly. The principle is to prevent lag during extreme events or rapid fluctuations while still limiting the magnitude of changes to reduce manipulation risk. For prediction markets or interest rate perpetuals, higher thresholds can be chosen to allow prices to converge more rapidly to the true value.

2. One-Time Large Price Jumps for Special Events

Another potential mitigation is to permit special oracle updates during event conclusion or when an abnormal jump is needed. For example, in binary markets, once the outcome is known, the oracle could publish the final price (0 or 1) in a single update, bypassing the 1% incremental rule. This could be conditioned on specific criteria, such as the event ending or multi-party signatures verifying the result. Essentially, the oracle would operate in two modes: normal incremental updates during trading, and a non-continuous mode allowing a large jump at settlement.

3. Removing Continuous Oracle Updates

A more radical but elegant solution is to redesign certain markets to not rely on continuous oracle price updates at all. This is precisely what HIP-4 proposes for prediction market perpetuals: removing continuous oracle and funding fee mechanisms, letting market prices be determined solely by trader demand until the event concludes. In this model, event-based perpetuals open via a fair value auction, then trade freely. The oracle is only used once at settlement to publish the final result (0 or 1) for payout. This approach eliminates the need for frequent updates, allowing markets to adjust instantly as new information arrives. The trade-off is that sufficient liquidity and active trading are required to ensure price accuracy, but it cleverly sidesteps oracle rate limits and funding fee complexities.

Conclusion

HIP-3 introduced permissionless, developer-deployed perpetual markets—a major innovation that, in theory, can support any asset. However, the built-in oracle constraint—limiting each update to a maximum 1% change—currently hampers HIP-3’s support for certain fast-moving markets. The requirement for continuous, incremental price updates means markets with sudden large swings cannot be accurately reflected. In such cases, on-chain prices lag far behind real prices, creating arbitrage opportunities and undermining market integrity. As it stands, HIP-3 is best suited for assets with relatively continuous and moderate volatility (e.g., major crypto trading pairs, stocks, commodities), and performs poorly for markets that do not follow this pattern.

The good news is that the Hyperliquid community recognizes these limitations and is actively seeking solutions. The HIP-4 event perpetual proposal offers a path forward by removing reliance on continuous oracle updates for prediction markets, and the proposed HIP-3.1 revision could make the oracle system more flexible. If these solutions are implemented, Hyperliquid may support fast-moving markets without being constrained by current severe limitations.

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 advancing large-scale blockchain adoption and empowering future Alpha opportunities in Web3. Currently, Jsquare manages over $200 million in assets and operates a dedicated $50 million LP fund. Jsquare places high importance on post-investment services, leveraging Web2 and Web3 resources to empower its portfolio.