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 time the oracle price is updated, the change relative to the last price can only be ±1%. This "1% cap" mechanism is likely intended as a safety measure to ensure smooth price movements 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, exhibiting "jump" changes rather than smooth curves.
HIP-3's Oracle Mechanism and 1% Update Rule
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 change the marked price (mark price) by a maximum of 1% relative to the previous one. If there is no oracle update within 10 seconds, the system will revert to using the latest bid/ask midpoint of the market as the marked price. In other words, HIP-3 imposes a strict rate limit on price changes: regardless of how much the real value of the underlying asset changes in the real world, 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 the market size 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 effectively reduces oracle risk; but for markets that indeed require large 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 the prices of highly liquid crypto assets, making it inadequate for dealing with such markets. Below, we will examine several typical markets and explain why the 1% oracle update cycle limitation makes HIP-3 unsuitable for them:
- #### 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 often 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, to jump the price from 0.50 to 1.00, it would need to be done through a series of small 1% increments. During this delay, the on-chain perpetual contract market price would significantly deviate from the real value, and any trader who knows the outcome could 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.
- #### 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 quickly 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.
- #### Low Liquidity or Infrequently Priced Assets
Some HIP-3 deployers wish to list private equity or other low liquidity investment targets as perpetual contracts. These assets do not trade continuously in the public market, so their valuations are typically updated only during financing rounds or when new information is released, often resulting in significant jumps. For example, a startup may be valued at $100 million in one financing round, and in the next round, it may rise 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 a HIP-3 market, this change would be forced to be spread over multiple small oracle update cycles. During this time, the perpetual contract market cannot reflect the new valuation, thus failing to achieve the intended purpose of trading.
Why the 1% Cap is Still Not Fast Enough
The crux of the problem is that the 1% incremental cap effectively sets a rate limit on the speed at which on-chain perpetual contract prices can move. 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 may take dozens of updates, resulting in several minutes of delay. For competitive traders, even a few seconds of price lag is enough to be exploited, so a few minutes of lag is catastrophic for market integrity.
It is important to note that this is not just an issue of oracle delay (i.e., data retrieval speed), but rather a deliberate 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 still absorb this change incrementally. The intention behind this is to avoid severe price shocks, but it inevitably creates a discrepancy between on-chain prices and real prices when real prices change rapidly. Traders observing external prices can trade on Hyperliquid at lagging prices until the oracle gradually updates to catch up with the real price. 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 originally intended to maintain market stability, but in these scenarios, it inadvertently leads some HIP-3 markets to sacrifice price accuracy for safety. The value of perpetual contract markets lies in their prices closely reflecting 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:
- #### 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 the maximum price deviation for each market to be configurable. Deployers can set a higher cap based on the characteristics of the asset (suggested to be up to 5% per update) instead of hardcoding it to 1%. This flexibility can allow high-volatility markets to adjust prices more quickly. The principle is to prevent marked 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 their real value.
- #### One-Time Updates for Significant Price Jumps
Another potential mitigation solution is to allow special oracle updates when an event concludes or requires an abnormal jump. For example, 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 when verified by multiple signatures. 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.
- #### 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 made by HIP-4 for perpetual contracts in prediction markets: 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 self-adjust in real-time 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 a permissionless, builder-deployed perpetual contract market, 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 in 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 demonstrates a path forward by eliminating the reliance on continuous oracles for prediction markets, while the proposed HIP-3.1 amendment aims to 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
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, Jsquare manages assets exceeding $200 million and operates a dedicated $50 million LP fund. Jsquare places a high value on post-investment services, leveraging resources from both Web2 and Web3 to empower its portfolio.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
