HIP 4 - Event Perpetuals

Written by: rajiv (framework), john (kalshi), marc (felix), krane (asula)

Abstract

This HIP introduces “Event Perpetuals”: binary markets traded on Hyperliquid’s order book. Unlike traditional perps, Event Perps have no continuous oracle or funding; prices are determined entirely by trading activity. The price reflects the binary probability of an event occurring. A single resolution oracle update sets the market to 0 or 1 at event conclusion, causing trading to halt and positions to settle.

HIP-3: Builder deployed Perpetuals

HIP-3 introduced permissionless, builder-deployed perpetual markets on Hyperliquid’s Layer-1. To deploy a market, builders need to stake 1M HYPE which can be slashed in the case of byzantine behavior. More specifically, any builder with 1M HYPE can deploy a new DEX with completely new markets using the same infrastructure as Hyperliquid’s flagship DEX.

Why HIP-3 doesn’t work for Event Perpetuals

While interest in prediction markets has grown, there is currently no venue to list or trade them permissionlessly. HIP-3’s builder-deployed perpetuals might appear to be a natural fit for prediction markets, but the structure of market deployment isn’t yet fit for them.

Prediction markets don’t have corresponding spot assets and don’t rely on external oracles to ensure market integrity, thereby eliminating the need for funding rates during continuous trading. Only during market resolution, an external data source sets the resolution price r to r ∈ {0, 1} (throughout this doc, assume r is the probability of the “YES” event).

Moreover, Hyperliquid’s HIP-3 specification only allows for the mark price to change by ≤1% per tick. Making it unsuitable for the resolution of prediction markets.

Let’s discuss the practical implications of these limitations with the example of an NFL prediction market if we were to try to build out a prediction market with HIP-3:

Let’s say the market is defined by: Will the Chiefs win Super Bowl LVIII against the 49ers? The logical oracle for winning probabilities for NFL games are sportsbooks. The oracle would retrieve moneyline quotes from various vendors and calculate the implied win probability for the Chiefs. The market deployer updates the price using these probabilities every 3 seconds on the HIP-3 market. The process works as long as there are no sudden changes to the oracle price.

Sportsbooks freeze quotes ahead of high impact plays and update quotes only after a play has concluded. The sportsbook odds would then update as a step function, however the hyperliquid oracle would need to scale the price delta over several ticks because its change over one tick is limited to ≤ 1%. This leaves the perp market lagging behind. Informed traders may take advantage of the arbitrage opportunity or cause HIP-3 based prediction markets to always lag behind other “faster” markets.

The lag is amplified by basis effects. The oracle prices can increase faster from 0 -> 1 than they can decrease from 1 -> 0\ making resolution asymmetrical. It would take a whopping 50 minutes and 8 digits of oracle precision to go from 0.5 (neutral) to 0 (no).

The required instant step function update is therefore impossible, which opens up the possibility of informed traders frontrunning the change. Moreover, every prediction market will have at least one large step function change i.e. the resolution.

Due to these reasons, HIP-3 doesn’t currently work well for prediction markets and has motivated us to suggest Event Perpetuals.

Event perpetuals are binary perpetual contracts designed to trade the probability of discrete events. Unlike traditional perpetuals, they do not reference a continuous index or rely on funding payments. Instead, their fair value lies within [0,1], reflecting the market-implied probability of a “YES” outcome. At event conclusion, a single oracle update sets the resolution value r∈{0,1}. Trading halts, resting orders are cancelled, and all positions settle to r.

Key features

• Binary payoff structure: Fair value p ∈ [0, 1] reflects the market-implied probability of a “YES” outcome. Settlement occurs at resolution value r ∈ {0, 1}.
• No funding, no continuous oracle: Prices are entirely market-driven until a market resolution is reached.
• Margining: 1x isolated margin only. Mark price is derived from mid-price on the order book, subject to standard risk controls. If a user is buying q units of YES at price p they are required to deposit: q * p units of collateral. On the other hand, if a user is buying q units of NO when the price of YES is p, they are required to deposit: q * (1 - p) units of collateral.
• Opening auction: Trading begins with a single-price clearing auction that determines the opening market price before continuous trading starts.
• Permissionless deployment: Builders provide the event schema, including title, end time, resolution source, and authorized updater(s).
• Fees: Deployers can set a fee share of up to 50% custom additional fees on top of the base fee rate.

Lifecycle

1. Deployment: The Builder stakes 1M HYPE to deploy the DEX and submits an event schema and parameters, paying deployment gas via a separate Event Perpetual deployment process. Since there are far more prediction markets than asset perpetuals and most of them are less liquid than traditional markets, a separate listing/deployment process is needed. We can also design event perp DEXs to have multiple slots for markets they choose to deploy. Upon resolution, the market in any given slot can be replaced with a new market. This mirrors HIP-3’s recycling of dated contracts and avoids the need to repeatedly participate in the deployment auction for each new event.
2. Opening auction:
   1. Order Collection: For ~15 minutes, people post “I’ll buy YES up to price P” or “I’ll sell YES down to price P.” Nothing executes during this window. The book can look “crossed” (buys above sells). We only use these orders to compute the open.
   2. Pick the single opening price (p*): At the end, the engine tries all candidate prices and chooses the one where the most contracts can trade (max matched volume). If there’s a tie, pick the one with the smallest leftover imbalance; if still tied, pick the price closest to 50%.
   3. Fill everyone at that one price (uniform price):
   • Orders better than p* (e.g., buy at 0.70 when p*=0.65) get filled first.
   • Orders exactly at p* share whatever is left pro‑rata (each gets a slice proportional to its size).
   • All executions print at p* (one opening price).
   4. The clearing price maximizes matched volume given supply and demand. Unfilled orders rest in the book at their original prices. The orderbook may be crossed during the opening auction but will be uncrossed while determining the opening price.

3. Trading: Continuous order book trading with 0 funding and price bands [0.001, 0.999]. No leverage allowed in our construction due to complexities around liquidations during resolution.
4. Resolution: At or before resolutionTime, the updating oracle posts r ∈ {0, 1}. Early resolution can happen if an event occurs before resolution time for the market. A challenge window can be specified, making resolution optimistic and disputable during that period.
5. Settlement: Upon resolution, trading halts, resting orders are canceled, and positions resolve to their final PnL.

Conclusion

In this proposal, we outline Event Perpetuals, a primitive designed to facilitate prediction markets on top of Hyperliquid by extending HIP-3’s builder-deployed perpetuals. If Event Perpetuals hit any scale, they’ll be the first venue with permissionless deployment for prediction markets. Moreover, they can enable established players in the market (like Kalshi) to deploy permissionless markets with the same resolution engine as their core exchange. This approach would effectively utilize Hyperliquid builder codes to open the venues prediction markets to more liquidity.