What is HIP-4? Hyperliquid Outcome Contracts Explained
What is HIP-4? Hyperliquid Outcome Contracts Explained
Learn how HIP-4 and outcome contracts work, explore composability with the rest of Hyperliquid stack, and how developers can build on this.
Hyperliquid 노드를 운영 중이신가요?Hyperliquid 피어링을 통해 블록 및 전체 멥풀에 대한 직접 경로를 활성화합니다.
자세히 알아보기What is HIP-4? Hyperliquid Outcome Contracts Explained
Learn how HIP-4 and outcome contracts work, explore composability with the rest of Hyperliquid stack, and how developers can build on this.
SOC 2 Type II 인증 · ISO 27001
March 13, 2026 — 11 min read
Hyperliquid has spent two years building toward a single thesis:
Every financial market: crypto, equities, commodities, events should run on the same execution engine, with shared liquidity and composable margin.
Each proposal and action in terms of HIPs (Hyperliquid Improvement Proposals) is continually expanding the surface area of what's tradable on HyperCore.
First, HIP-1 gave the chain native tokens.
Then, HIP-2 bootstrapped liquidity.
Last year (2025), HIP-3 opened perpetual futures to permissionless deployment.
Just days ago, HIP-4 went live on Hyperliquid testnet, and it expands Hyperliquid into a new design space and market mechanics with outcome contracts.
What is it? Is it simply “prediction markets on Hyperliquid”? How does it work?
Let’s answer each question with a breakdown of the primitives HIP-4 introduces and how they fit within the overall Hyperliquid infrastructure.
Outcome contracts are binary financial instruments on Hyperliquid tied to whether a specific event occurs. They trade between 0 and 1, where the price represents the market’s implied probability of that event occurring.
If the event happens, the contract settles at 1.
If it doesn't, it settles at 0.
Because the settlement values are fixed, the payoff structure is straightforward.
Assume a trader buys a YES contract at price P, the payoff at settlement is:
Profit if event occurs: 1−P
Loss if event does not occur: P
Example:
If a contract trades at 0.60, the market is implying a 60% probability that the event will occur. And here’s the scenario if a trader buys YES at 0.60:
Math, money, and payoffs aside, understanding how outcome contracts behave and what becomes possible because of it requires a little more depth.
Outcome contracts run directly inside HyperCore, the core execution layer responsible for spot and perpetual markets on Hyperliquid. Meaning, they use the same onchain orderbook infrastructure, matching engine, and trading environment that existing markets use.
Order book: Every outcome market gets its own central limit order book (CLOB), operating the same as spot and perp markets operate on HyperCore.
Account system: Outcome contract positions live inside the same Hyperliquid trading account that a trader uses for Hyperliquid DEX.
Outcome contracts being native to HyperCore also makes life easier for builders and developers looking to innovate within the Hyperliquid ecosystem.
Because outcome contracts inherit the same infrastructure as any other HyperCore market in terms of:
transaction throughput,
latency profile,
validator set handling finality, and more.
This way, builders querying outcome market state, order book depth, or settlement events can use the same infrastructure they'd use for Hyperliquid DEX.
The next step is understanding how these markets actually operate once they are deployed.
Once deployed inside HyperCore, outcome contracts follow a simple lifecycle: creation > auction > continuous trading > settlement.
While the process seems self-explanatory, there’s a nuance to each step that helps Hyperliquid maximize this market offering:
The builder (deployer) must stake 1M $HYPE tokens to deploy their outcome market.
The stake is slashable if a builder attempts to manipulate the oracle or to trigger invalid state transitions. Any partial or fully slashed $HYPE will be burned.
During deployment, the builder defines the event schema:
Event title
Resolution time
Resolution source
Authorized oracle updater
Optional addition: Challenge window for optimistic early resolution + disputes
Also, deployers can set an additional fee share of up to 50% on top of Hyperliquid's base fees.
Markets are deployed into slots within a builder’s event DEX.
Once resolved, the slot can be recycled with a new event, meaning a single 1M $HYPE commitment can support a rolling series of markets.
After deployment, a ~15-minute single-price clearing auction runs, during which users submit orders (“buy YES up to price P”).
Remember, nothing executes in this phase.
When it closes, the engine picks the clearing price that maximizes matched volume, and every matched order fills at that single price.
Unfilled orders carry into continuous trading at their original limits.
The actual math behind determining the opening price. Source
After the auction, the market transitions to continuous orderbook trading.
Orders follow price-time priority. Traders can submit limit and market orders just like in other Hyperliquid markets.
The contract price reflects the market’s implied probability of the event occurring and remains bounded between 0.001 and 0.999 until the event resolves.
When the event resolves, the authorized oracle posts the final outcome:
1 if the event occurs
0 if it does not
Trading halts, open orders are canceled, and all positions settle automatically to their final PnL in USDH.
Markets may optionally include a challenge window, allowing oracle outputs to be disputed before settlement becomes final.
Now, we know how the outcome markets work, the math, and the process. Let’s pivot to understanding why this matters for Hyperliquid as an ecosystem and for all participants within it.
Hyperliquid’s roadmap has been consistent from the start: expand the surface area for trading within a single execution engine.
The idea is simple.
It's building a single execution layer where every market type — spot, perpetuals, and now outcome contracts — runs on the same infrastructure, settles through the same engine, and sits inside the same trading account. More importantly, every new market type deepens the same liquidity pool rather than fragmenting it.
That last part is what composability actually means here.
Consider a concrete example: a trader holds a long ETH perpetual. They believe ETH rallies if the Fed cuts rates, but want protection if it doesn't.
Anywhere else, the trader would need to take two separate positions on two separate platforms, each with its own collateral pool.
On Hyperliquid, the perp and the outcome contract sit in the same account.
Alternatively, this composability carries advantages for builders and developers alike:
A market maker active in spot can extend their infrastructure to outcome markets without a new integration.
Builders looking at Hyperliquid get unlimited design space which used to require multiple institution-grade infrastructure before and a lot of coordination in between to make it work.
Well, this isn’t a new experiment that Hyperliquid did. They have been at the same goal all along.
Hyperliquid has been very explicit regarding their long-term vision.
The Blockchain To House All Finance: A single blockchain capable of hosting every financial market on one execution layer.
Now, composability is only as useful as the builders innovating on it. Let’s think more practically about builders and operators on Hyperliquid.
HIP-4 doesn't affect everyone on Hyperliquid equally. Let's zoom out and think of implications for the major 2-3 roles onchain.
For builders, HIP-4 turns event markets into deployable infrastructure rather than standalone applications. This opens room for new types of products:
Cross-market arbitrage bots
Event trading interfaces
Layered structured products
Market analytics and probability data products
Prediction market frontends
Since the infrastructure is purpose-built and reliable, builders can build a wide range of interfaces and market-discovery layers on top of outcome contracts.
For liquidity providers and market makers, outcome markets currently offer limited functionalities. Bounded payoff is a turnoff for any LP looking to maximize gains.
Also, outcome markets as probability instruments are more passive compared to perp markets for LPs where exposure is continuous and funding rates drive position decisions, increasing the profit ceiling.
Maybe, over time, this could lead to an entirely new liquidity category on Hyperliquid: event-probability market-making.
LPs and market makers don’t gain a direct win-win from HIP-4.
The 1M $HYPE stake is the barrier. At current prices, that's a significant capital commitment, but slot recycling changes the unit economics meaningfully.
A single stake supporting a rolling series of markets amortizes that cost over time.
This enables deployers to operate rolling event markets around recurring events such as:
macroeconomic releases
earnings announcements
elections or governance votes
major product launches
So, market creators have to think about slot utilization, sequencing market rollouts, and market timing far more than whether to stake a million $HYPE.
What next? Builders need good tooling and data access to genuinely leverage the new design space of outcome markets.
Outcome markets are event-driven.
A simple statement but this architectural distinction has direct implications that don't exist in continuous markets like spot or perpetuals.
> In a perpetual market, a missed update means a slightly stale price.
> In an outcome market, a missed event means a broken interface, a failed hedge, or a position that didn't settle correctly.
The cost of infrastructure failure is asymmetric.
For builders and traders interacting with these markets, that behavior raises the importance of reliable infrastructure. Applications need consistent access to:
real-time orderbook data
market state and event metadata
account balances and position updates
transaction submission for orders and cancellations
Because outcome markets trade on HyperCore’s orderbook, these interactions happen through RPC endpoints and APIs that expose market data and execution interfaces.
In practice, builders developing event trading interfaces, analytics dashboards, or automated strategies need infrastructure that can reliably handle spikes in activity when new information hits the market.
This is where infrastructure providers such as Quicknode become useful.
By offering managed Hyperliquid RPC endpoints, data access, and developer tooling, Quicknode allows teams to focus strictly on building products and solutions.
Quicknode's HyperCore integration, which is currently in public beta, promises to carry infra superpowers like:
💡View current pricing: https://www.quicknode.com/api-credits/hyperliquid
More Quicknode resources for Hyperliquid builders:
SDKs & Tools
Hyperliquid Python SDK — also on PyPI
Hyperliquid API Examples — clone-and-run examples in Python, TypeScript, Rust & Go
Hyperliquid SDK Examples — advanced SDK usage patterns
HyperCore CLI — stream & backfill HyperCore data from the terminal
hyperliquidapi.com — zero-custody Hyperliquid trading API
Stay tuned for more insights—subscribe to our blog for the latest in blockchain infrastructure.
For teams building on top of HIP-4, the infrastructure layer is the difference between a product that works when it matters and one that doesn't.
The tradable surface area on HyperCore just expanded with HIP-4 going live on testnet. With outcome contracts, Hyperliquid is now pricing events.
That shift expands the design space for builders and market participants.
Developers can deploy recurring event markets, liquidity providers can quote probability instruments alongside traditional markets, and traders can express views not just on prices but on outcomes.
What next is deployment of markets, maturity of tools and developer resources, and of course Hyperliquid's evergreen pursuit of widening the range of markets that can live inside the same trading infrastructure.
Not exactly. Prediction markets are one application of outcome contracts.
Outcome contracts are the underlying financial primitive i.e. binary instruments that settle to 0 or 1 based on an event outcome. Prediction markets simply use that primitive to price the probability of future events.
On Hyperliquid, outcome contracts can support many kinds of event-based markets beyond traditional prediction use cases.
As of March 2026, HIP-4 outcome trading is live on Hyperliquid testnet. Mainnet launch will follow a two-phase approach: curated canonical markets first, permissionless builder deployment second. No mainnet date has been confirmed.
Quicknode offers the most comprehensive solution with full HyperCore and HyperEVM support, gRPC streaming, and the broadest protocol coverage. The best provider ultimately depends on your specific needs—high-frequency trading, cost optimization, or multi-chain infrastructure.
Yes, switching providers is straightforward since most use standard JSON-RPC and WebSocket interfaces. You typically only need to update your endpoint URL.
However, if you've built features around provider-specific tools like Quicknode's analytics dashboard or custom APIs, you may need to adjust those integrations. The core blockchain interactions remain compatible across providers.
2017년에 설립된 Quicknode 개발자와 기업을 위해 기관급 블록체인 인프라를 Quicknode . 99.99%의 가동률과 80개 이상의 체인을 지원함으로써, 팀들은 타협 없이 온체인 애플리케이션을 구축하고 확장할 수 있습니다.
최신 엔지니어링 인사이트, 제품 업데이트, 웹3 뉴스를 여러분의 이메일로 바로 받아보세요.