Why the unconventional HIP-3 market doesn't work.

Author: Jsquare Investment Team

Hyperliquid's HIP-3 upgrade introduced 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 built into perpetual contracts.

However, the HIP-3 oracle design introduces a key limitation: each oracle price update can only vary by a maximum of ±1% relative to the previous price. This "1% cap" mechanism was likely intended as a security measure to ensure smooth price movements and prevent malicious or anomalous oracle data updates.

But in practice, this mechanism severely limits support for high-speed or discontinuous pricing markets—in which real prices often experience sharp jumps within a very short period, even exhibiting "jump" changes rather than a smooth curve.

HIP-3 Oracle Mechanism and 1% Update Rule

Under the HIP-3 mechanism, every 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). Crucially, each update, relative to the previous mark price, can only change by a maximum of 1%. If no oracle update occurs within 10 seconds, the system will revert to using the latest bid/ask median price in the market as the mark price. In other words, HIP-3 imposes a strict rate limit 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 a maximum of 1% in each oracle update cycle.

This design enhances system stability to some extent and protects against drastic price fluctuations caused by erroneous data or oracle anomalies. It ensures a smooth and continuous price path, reducing the risk of cascading liquidations triggered by a single large price jump, and also giving validators time to react when suspicious oracle updates are detected. Furthermore, HIP-3 introduces other security mechanisms to maintain market integrity, such as a price cap that limits prices to within 10 times the opening price of the day, and an open position growth cap to prevent uncontrolled market expansion in a short period. However, the 1% price deviation cap is a double-edged sword. For mainstream crypto assets, which typically do not experience drastic price fluctuations within seconds, this mechanism effectively reduces oracle risk; but for markets that require significant or instantaneous price adjustments, this restriction can become a serious performance bottleneck. Why Unconventional HIP-3 Markets Fail

The "unconventional market" referred to here is one where the value of the underlying asset can change drastically or dramatically within a very short period. HIP-3 oracle systems are essentially designed for relatively smooth price movements and publicly verifiable market data, such as highly liquid crypto asset prices, and therefore struggle with these types of markets. Below, we will examine several typical markets and explain why the 1% oracle update cycle limit makes HIP-3 unsuitable for them:

1. Prediction Markets

Perhaps the most typical example is a prediction market similar to binary options. Most of the time, its price may fluctuate slowly, but when the outcome of an event is determined, the true price should immediately jump to 0 or 1.

Odds in sporting events or elections typically change in a stepwise, rather than smooth, curve manner. For example, a touchdown in a football match can instantly alter the odds of winning by several percentage points. Under HIP-3's 1% oracle update cycle limit, on-chain prices cannot achieve such jumps. For instance, once the outcome is determined, jumping the price from 0.50 to 1.00 requires a series of small 1% increments. During this delay, the on-chain perpetual contract market price will deviate significantly from its true value. Any trader who knows the outcome can easily exploit this difference for risk-free arbitrage, buying the "yes" option at a low price and profiting as the price slowly rises. This approach is neither realistic nor safe because it undermines the core function of prediction markets. Results need to be settled quickly, and HIP-3's continuous oracle update speed is insufficient to guarantee fairness or efficiency. 2. Interest Rate and Yield Markets Interest rates can sometimes fluctuate significantly in a short period, especially during monetary policy announcements or economic data releases. For example, an unexpected decision by the Federal Reserve could cause the two-year Treasury yield to change by tens of basis points almost instantaneously. Perpetual contracts linked to interest rate indices can also experience similar sudden fluctuations. Due to the limitations of HIP-3's oracle update cycle, even if the base yield jumps rapidly, the on-chain price can only adjust gradually, failing to reflect new market conditions in a timely manner. This not only creates arbitrage opportunities but can also lead to inaccurate margin calculations (because traders' positions are based on outdated prices for extended periods). Therefore, without adjustments, HIP-3 models cannot effectively support interest rate markets or any indicators that may experience discontinuous repricing. 3. Assets with Low Liquidity or Infrequent Pricing Some HIP-3 deployers wish to list private equity or other low-liquidity investment targets as perpetual contracts. These assets are not continuously traded on the public market, so their valuations are typically only updated during funding rounds or when new information is released, often resulting in significant fluctuations. For example, a startup might be valued at $100 million in one funding round, and then rise to $150 million in the next. If someone were to attempt to maintain a fair value for such assets through oracles, they would face the problem that when a new valuation or event occurs, the price might need to adjust by tens of percentage points all at once. In the HIP-3 market, this change is 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 purpose of the transaction. The core issue is that the 1% increment cap effectively sets a rate limit on the speed at which on-chain perpetual contract prices move. If the true price of an asset suddenly needs to rise by 10%, a HIP-3 oracle would need multiple updates to reach that level. If the required price change reaches 50% (as in the example of a binary event), it might require dozens of updates, resulting in delays of several minutes. For competitive traders, even a price lag of a few seconds is enough to be exploited, so a lag of several minutes is disastrous for market integrity. It's important to note that this isn't just a matter of oracle latency (i.e., data acquisition speed), but a deliberate slowing down of price changes. Even if an off-chain oracle source, such as a Web2 API or Pyth price feed, instantly reports a large price change, the Hyperliquid chain will still absorb this change bit by bit. The intention is to avoid drastic price shocks, but this inevitably creates a discrepancy between the on-chain price and the true price when the real price moves rapidly. Traders observing external prices can trade on Hyperliquid at the lagging price until the oracle gradually updates to catch up with the true price. This creates risk-free arbitrage opportunities, with the risk borne by slow participants or those who don't notice the price changes. This arbitrage not only harms uninformed traders but can also be exploited by those who extract value from liquidity providers or insurance funds through slow oracle updates, thus consuming system funds. From a risk management perspective, the 1% limit was intended to maintain market stability, but in some situations, it has inadvertently led to some HIP-3 markets sacrificing price accuracy for security. The value of perpetual contracts lies in their prices closely reflecting the true value of the underlying asset. If prices lag significantly, the market cannot fulfill its essential function. Therefore, under the current 1% price deviation cap, some perpetual contracts are nominally feasible, but practically difficult to operate. Potential Mitigation Measures and Future Improvements To address the limitations of high-speed markets, adjustments are needed at the protocol level. Several strategies have been proposed to allow HIP-3 or its successors to support rapid price changes without sacrificing security. The following are some key mitigation measures and improvement directions that promise to enable perpetual contracts to cover these highly challenging markets: 1. Increase the upper limit on oracle update magnitudes. One direct solution is to relax the strict 1% limit for markets requiring faster response. The HIP-3 revision proposal, co-authored by Pyth, makes the maximum price deviation configurable for each market. Deployers can set higher upper limits based on the characteristics of the asset (a maximum of 5% per update is suggested), instead of hardcoding it to 1%. This flexibility allows prices to adjust more quickly in highly volatile markets. The principle is to prevent price lag during extreme events or rapid fluctuations while still limiting the magnitude of changes to reduce the risk of manipulation. Thus, for prediction markets or interest rate perpetual contracts, higher thresholds can be chosen, allowing prices to converge to true value more quickly. 2. One-time Updates for Large Price Jumps Another potential mitigation is to allow special oracle updates when an event ends or when an unusual jump is needed. For example, in binary event markets, once the outcome is determined, the protocol could allow oracles to publish the final price (0 or 1) in a single update, bypassing the 1% incremental update rule. This could be accompanied by specific conditions, such as the final settlement price only being allowed to be published at a preset event end time or when the result is verified by multiple signatures. Essentially, the oracle would operate in two modes: small incremental updates in normal trading mode, and bypassing the 1% bias limit in discontinuous pricing mode. 3. Eliminating Continuous Oracles A more radical but elegant solution is to redesign the operation of certain markets so that they are completely independent of continuous oracle price updates. This is precisely the solution HIP-4 proposed for perpetual contracts in prediction markets: removing continuous oracles and funding fees, allowing market prices to be entirely determined by trader demand until the event ends. In this model, event-based perpetual contracts open through a fair value price discovery auction and are then freely traded. Oracles are used only once at settlement to announce the final result (0 or 1) to pay out rewards. In this way, the problem of needing to update odds every few seconds disappears, and the market can self-adjust instantly 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 introduced permissionless, builder-deployed perpetual contract markets, a significant innovation that theoretically allows for the launch of 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-volatile markets.

The requirement for continuous, incremental price updates means that markets with sudden, large price fluctuations cannot be accurately reflected. In this case, 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), but performs poorly for markets that do not follow this pattern. The good news is that the Hyperliquid community is aware of these limitations and is actively seeking solutions. The HIP-4 event-driven perpetual contract proposal demonstrates 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 solutions are implemented, Hyperliquid is expected to support rapidly fluctuating markets in the future without the current severe limitations.