Jsquare Research Report "Why the Non-Mainstream HIP-3 Market Doesn't Work"

Author: Jsquare Investment Team

The HIP-3 upgrade of Hyperliquid introduces a perpetual contract market deployed by developers, 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 constructed as perpetual contracts.

However, the oracle design of HIP-3 brings a critical limitation: each oracle price update can only vary by a maximum of ±1% relative to the last price. This "1% cap" mechanism is likely intended as a safety measure to ensure smooth price changes and prevent malicious or anomalous oracle data updates.

In practice, this mechanism severely limits support for fast or discontinuous pricing markets—where real prices often experience significant jumps in a very short time, rather than smooth curves.

Oracle Mechanism and 1% Update Rule of HIP-3

Under the HIP-3 mechanism, each perpetual contract market deployed by developers 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 that each update can only vary by a maximum of 1% relative to the previous mark price. If there is no oracle update within 10 seconds, the system will revert to using the latest bid/ask midpoint as the mark price. In other words, HIP-3 imposes strict rate limits on price changes: regardless of how much the real-world value of the underlying asset changes, the on-chain perpetual contract price can deviate by at most 1% during each oracle update cycle.

This design enhances system stability to some extent and can prevent severe price fluctuations caused by erroneous data or oracle anomalies. It ensures the smoothness and continuity of price paths, thereby reducing the risk of triggering chain liquidations due to a single large price jump, while also giving validators time to react when suspicious oracle updates are detected. Additionally, HIP-3 introduces other safety mechanisms to maintain market integrity, such as a price cap mechanism that limits prices to within 10 times the opening price of the day; and an open position growth cap mechanism to prevent market scale from uncontrollably expanding in a short time.

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

Why Non-Mainstream HIP-3 Markets Fail

The "non-mainstream niche markets" referred to here are those where the underlying value may change dramatically in a very short time or fluctuate significantly. The HIP-3 oracle system is essentially designed for price movements that are relatively smooth and publicly verifiable, such as high liquidity crypto asset prices, making it inadequate for these types of markets. Below, we will examine several typical markets and explain why the 1% oracle update cycle limitation 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 the outcome of an event is determined, the real price should jump immediately to 0 or 1. Odds for sports events or election outcomes typically change in a stepwise manner rather than a smooth curve; for example, a touchdown in a football game can instantly change the win probability by several percentage points. Under HIP-3's 1% oracle update cycle limitation, the on-chain price cannot achieve such a jump. For instance, when the 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 significantly deviate from the real value, allowing any trader who knows the outcome to easily exploit this price difference for risk-free arbitrage by buying the "yes" option at a low price 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 in a short time, especially during monetary policy announcements or economic data releases. For example, an unexpected decision by the Federal Reserve could almost instantly change the yield on two-year Treasury bonds by several basis points. Perpetual contracts linked to interest rate indices may also experience similar sudden fluctuations. Under HIP-3's oracle update cycle limitation, even if the underlying yield rapidly jumps, the on-chain price can only adjust gradually, failing to reflect the new market conditions in a timely manner. This not only creates arbitrage opportunities but may also lead to inaccurate margin calculations (as traders' positions are based on outdated prices for an extended period). Therefore, without adjustments, HIP-3's model cannot effectively support interest rate markets or any indicators that may experience discontinuous repricing.

3. Low Liquidity or Infrequently Priced Assets

Some HIP-3 deployers aim to list perpetual contracts for private equity or other low liquidity investment targets. These assets do not trade continuously in public markets, so their valuations are typically updated only during funding rounds or when new information is released, often resulting in significant jumps. For example, a startup may be valued at $100 million in one funding round, while the next round could raise it to $150 million. If someone attempts to maintain a fair value oracle for such assets, they will face the issue that when new valuations or events occur, the price may need to adjust by several percentage points all at once. In the HIP-3 market, this change would be forced to be spread over multiple small oracle update cycles. During this period, the perpetual contract market cannot reflect the new valuation, thus failing to achieve the intended trading purpose.

Why the 1% Cap is Still Not Fast Enough

The crux of the issue is that the 1% incremental cap effectively sets a rate limit on the speed of movement for on-chain perpetual contract prices. If the real price of an asset suddenly needs to rise by 10%, HIP-3's oracle would need to go through multiple updates to reach that level. If the required price change reaches 50% (as in the binary event example), it could take dozens of updates and result in several minutes of delay. For competitive traders, even a few seconds of price lag is sufficient to be exploited, making several minutes of lag disastrous for market integrity.

It is important to note that this is not just an issue of oracle delay (i.e., data acquisition speed), but rather an intentional throttling of price changes. Even if an off-chain oracle source, such as a Web2 API or Pyth price feed, instantaneously reports a significant price change, the Hyperliquid chain will absorb this change gradually. The intention behind this is to avoid severe price shocks, but it inevitably creates a discrepancy between on-chain prices and real prices during rapid real price movements. Traders observing external prices can trade on Hyperliquid at lagged prices until the oracle gradually updates to catch up with real prices. This creates risk-free arbitrage opportunities, with the risk borne by those participants who are slow or unaware of the price changes. Such arbitrage not only harms traders with insufficient information but may also allow exploiters to extract value from liquidity providers or insurance funds through slow oracle updates, thereby depleting system funds.

From a risk management perspective, the 1% limit was intended to maintain market stability, but in these situations, it inadvertently leads some HIP-3 markets to sacrifice price accuracy for safety. The value of perpetual contract markets lies in their ability to closely reflect the real value of the underlying assets. If price lags are severe, the market cannot fulfill its essential function. Therefore, under the current 1% price deviation cap, some perpetual contracts may be nominally feasible but are practically difficult to operate.

Potential Mitigation Measures and Future Improvements

To address the limitations of fast markets, adjustments at the protocol level are needed. Various strategies have been proposed to enable HIP-3 or its subsequent versions to support rapid price changes without sacrificing safety. Below are some key mitigation measures and improvement directions that could allow perpetual contracts to cover these high-challenge markets:

1. Increase the Oracle Update Deviation Cap

A direct solution is to relax the strict 1% limit for markets that require faster responses. The HIP-3 revision proposal co-authored by Pyth allows for configurable maximum price deviations for each market. Deployers can set higher limits based on the characteristics of the asset (suggested up to 5% per update) instead of hardcoding it to 1%. This flexibility would allow high-volatility markets to adjust prices more quickly. The principle is to prevent mark price lags during extreme events or rapid fluctuations while still limiting the magnitude of changes to reduce manipulation risks. Thus, for prediction markets or interest rate perpetual contracts, a higher threshold can be chosen to allow prices to converge more quickly to real values.

2. One-Time Updates for Significant Price Jumps

Another potential mitigation solution is to allow special oracle updates in cases of event conclusions or when significant jumps are needed. For instance, in binary event markets, once the outcome is determined, the protocol could allow the oracle to publish the final price (0 or 1) in a single update, bypassing the 1% incremental update rule. This could include specific conditions, such as allowing the final settlement price to be published only at a preset event conclusion time or upon multi-signature verification of the result. Essentially, the oracle would operate in two modes: performing small incremental updates in normal trading mode and bypassing the 1% deviation limit in discontinuous pricing mode.

3. Eliminate Continuous Oracles

A more radical but elegant solution is to redesign the operation of certain markets so that they do not rely on continuous oracle price updates at all. This is precisely the proposal for prediction market perpetual contracts in HIP-4: removing continuous oracles and funding fee mechanisms, allowing market prices to be entirely determined by trader demand until the event concludes. In this model, event-based perpetual contracts open through fair value price discovery auctions and then trade freely. The oracle is only used once at settlement to announce the final result (0 or 1) for payout. This way, the issue of needing to update odds every few seconds disappears, and the market can instantaneously adjust itself as information arrives. The trade-off is the need for sufficient liquidity and active trading to ensure price accuracy, but it cleverly circumvents oracle limitations and funding fee complexities.

Conclusion

HIP-3 introduces permissionless, builder-deployed perpetual contract markets, which is a significant innovation that theoretically allows perpetual contracts to be launched on any asset. However, the built-in oracle constraint—limiting each update to a maximum price change of 1%—currently hinders HIP-3's support for certain fast-moving markets. The requirement for continuous, incremental price updates means that markets where prices can suddenly fluctuate significantly 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 prices and moderate volatility (such as major cryptocurrency trading pairs, stocks, or commodities), while it performs poorly for markets that do not follow this pattern.

The good news is that the Hyperliquid community has recognized these limitations and is actively seeking solutions. The HIP-4 event perpetual contract proposal showcases a path forward by removing 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 is expected to support fast-moving markets without the severe limitations currently in place.

Source: HIP 4 - Event Futures | bedlam

HIP-3.1 Amendment

Hyperliquid Docs

bitget.com

About Jsquare

Jsquare is an investment company driven by research and technology, focused on promoting the large-scale application of blockchain and empowering future Alpha opportunities in the Web3 space. Currently, we manage over $200 million in assets and operate a dedicated $50 million LP fund. We place a high value on post-investment services, leveraging resources from both Web2 and Web3 to empower our portfolio.