How Hyperliquid HIP-4 Outcome Markets Work: Yes/No Tokens, Settlement and Order Books

Most prediction markets look simple from the outside.

A trader buys YES or NO.

The event resolves.

One side pays out… but underneath, market structure matters a lot.

Liquidity, settlement mechanics, matching engines, and order book design all shape how efficient a market becomes once real volume arrives.

That’s where Hyperliquid’s HIP-4 upgrade gets interesting. Instead of building outcome trading as a separate application layer, Hyperliquid designed outcome contracts directly inside HyperCore… the same infrastructure powering its spot and perpetual markets.

That decision changes how these markets trade, settle, and share liquidity. Here’s a closer look at how Hyperliquid outcome markets actually work under the hood.

The Core Architecture of Decentralized Prediction Markets

Outcome Contracts Are Binary Instruments

At the center of HIP-4 are outcome contracts. Each contract represents a binary event:

• YES
• NO

If the event happens, YES settles to 1 and NO settles to 0.

If the event does not happen, the settlement flips. The structure is intentionally simple. Suppose there’s a market asking:

“Will BTC close above $120,000 tomorrow?”

A YES token trading at 0.72 means the market currently implies roughly a 72% probability that the event will happen.

If the event resolves positively:

• the token settles at 1
• the trader earns 0.28 profit per contract

If the event resolves negatively:

• the token settles at 0
• the trader loses the original 0.72 paid

Unlike perpetual futures, there’s no leverage multiplier involved. The payout range is always fixed between 0 and 1.

Hyperliquid Uses Fully Collateralized Markets

One of HIP-4’s core mechanics is full collateralization.

Every position is funded upfront… that means traders never borrow capital and never enter leveraged exposure. The system does not rely on liquidation engines, maintenance margin thresholds, or forced position closures.

This creates a very different risk model from traditional crypto derivatives. In leveraged perpetual markets, liquidation systems constantly monitor collateral ratios.

During sharp volatility, positions can unwind rapidly and trigger cascading liquidations across the market. Outcome contracts avoid that structure entirely. Maximum downside is known immediately at trade entry because the entire risk amount is prepaid.

For event-based markets, that simplicity matters. Traders focus on probability pricing rather than liquidation management.

Order Book Mechanics & Liquidity Aggregation

The YES and NO Books Share Liquidity

One of the more technically interesting parts of HIP-4 is how Hyperliquid handles order books.

At first glance, YES and NO appear to be separate assets… but economically, they are mirror images of the same probability.

Buying YES at price P is mathematically equivalent to selling NO at price 1 - P. For example:

• Buy YES at 0.65
• Equivalent to selling NO at 0.35

Instead of splitting liquidity into two disconnected books, Hyperliquid merges them. This creates a shared liquidity model where both sides contribute to the same effective order book depth. Why does that matter? Because fragmented liquidity is one of the biggest problems in prediction markets. When liquidity splits between separate YES and NO markets, spreads widen and execution becomes less efficient. Merged liquidity improves:

• capital efficiency
• price discovery
• spread tightness
• execution quality

Underneath the surface, Hyperliquid generalizes traditional price-time priority into what it calls:

price-side-time priority

At the same merged price level, resting sell orders are prioritized before dual-side buy orders. Most users never notice this directly. But structurally, it helps the market behave more efficiently during active trading.

Outcome Markets Still Behave Like Real Exchanges

Despite the new mechanics, HIP-4 outcome markets still trade using familiar exchange infrastructure.

Markets operate through central limit order books (CLOBs), similar to spot and perpetual trading. Traders can place:

• limit orders
• market orders
• resting liquidity
• aggressive taker orders

The experience looks much closer to a traditional trading venue than an AMM-style prediction market.

That matters for market makers and algorithmic traders. Because HIP-4 runs inside HyperCore, firms already connected to Hyperliquid infrastructure can extend existing systems into outcome markets without building entirely new execution environments. The same low-latency infrastructure used for perp trading now supports event-based markets.

Market Lifecycle, Auctions, and Protocols

Comparison: Traditional vs. Hyperliquid Market Structure

To understand how these protocol mechanics differ from standard decentralized applications, consider the following structural comparison:

Markets Open With an Auction Phase

Before continuous trading begins, Hyperliquid outcome markets go through an opening auction. This phase typically lasts around 15 minutes. During the auction:

• traders submit orders
• no trades execute immediately
• the engine collects all order flow

Once the auction closes, Hyperliquid calculates a single clearing price designed to maximize matched volume.

Every matched participant fills at the same price. Any unfilled orders then move into the live order book once continuous trading begins.

This mechanism helps stabilize early market pricing and reduces chaotic opening volatility. It also creates cleaner initial price discovery for new outcome markets.

Settlement Depends on Oracle Resolution

Outcome markets only work if settlement is reliable. Once an event reaches its resolution time, the authorized oracle posts the final result:

• 1 if the event occurred
• 0 if it did not

After that:

• trading halts
• open orders are canceled
• positions settle automatically

Settlement payouts happen directly inside Hyperliquid’s infrastructure. Some markets may also include challenge windows… these allow disputes before settlement becomes final if oracle results are contested. Because outcome markets depend heavily on accurate event resolution, oracle design becomes one of the most important pieces of the system.

Questions and Multi-Outcome Structures

HIP-4 also introduces the concept of “questions.” A question groups multiple related outcomes together where only one outcome can resolve positively. For example:

• Candidate A wins
• Candidate B wins
• Candidate C wins

Only one outcome settles to YES while all others settle to NO. Each outcome maintains its own order book, but the contracts remain linked through merge and negate operations. This creates more advanced market structures beyond simple binary contracts. Multi-outcome markets are expected to expand further as HIP-4 evolves.

Technical Ecosystem & Infrastructure Impact

Why Market Structure Matters for Prediction Markets

Prediction markets are often discussed at the application layer:

• politics
• sports
• macro events
• crypto price targets

But infrastructure design shapes whether those markets scale effectively. Execution quality matters.

Liquidity efficiency matters.

Settlement reliability matters.

HIP-4 focuses heavily on those underlying mechanics. By integrating outcome contracts directly into HyperCore, Hyperliquid is effectively treating event markets as another native asset class rather than a separate category of application. That approach could become increasingly important as prediction markets continue growing across crypto and traditional finance.

Outcome Markets Also Create New Data Challenges

Event markets generate fast-moving datasets:

• price changes
• implied probabilities
• order book shifts
• trade activity
• settlement updates

As more markets launch, developers need infrastructure capable of handling both real-time and historical prediction market data. This includes:

• tracking probability movement over time
• monitoring liquidity changes
• analyzing event-driven volatility
• aggregating market activity across platforms

FinFeedAPI’s Prediction Markets API provides access to normalized market data across platforms including:

• Polymarket
• Kalshi
• Myriad
• Manifold
• Hyperliquid HIP-4

Developers can work with:

• trades
• quotes
• OHLCV candles
• order books
• market activity feeds
• historical datasets

As outcome trading infrastructure expands, standardized market data becomes increasingly important for analytics, trading systems, and research platforms.

Hyperliquid Is Expanding What Can Trade On-Chain

HIP-4 is not just another prediction market product. It represents another step in Hyperliquid’s broader strategy:

bringing more market types into a single execution environment.

Spot markets, perpetual futures, tokenized assets, and now outcome contracts all share the same infrastructure layer.

That creates a trading ecosystem where different financial instruments no longer operate in isolation... and for prediction markets specifically, HIP-4 introduces a more exchange-native approach to how event contracts can trade, settle, and share liquidity at scale.

Build Prediction Trading Engines with FinFeedAPI

Building an analytics strategy across the decentralized prediction ecosystem requires more than just understanding a single platform's order book. With the arrival of Hyperliquid HIP-4 alongside established networks like Polymarket, Kalshi, and Manifold, market data has become heavily fragmented across distinct execution layers, separate AMM formats, and native CLOB infrastructures.

Tracking probabilities, pricing shifts, and historical settlement trends across all major venues simultaneously is where data pipelines typically break down.

With FinFeedAPI’s Prediction Markets API, development teams can:

• Normalize Cross-Platform Data: Access unified trades, order books, and quotes across Hyperliquid Outcome Markets, Polymarket, Kalshi, Manifold, and more through a standardized schema.
• Track Implied Volatility: Monitor fast-moving event probabilities and chart historical movements using precise OHLCV candle streams.
• Audit Historical Outcomes: Utilize historical datasets to backtest event-driven trading algorithms, populate front-end dashboards, or build comprehensive analytics platforms.

Instead of deploying isolated data aggregators for every new improvement proposal or platform upgrade, keep your data infrastructure clean, structured, and scalable.

👉 Explore our APIs and build products that rely on consistent data from FinFeedAPI.com

FAQs

What makes Hyperliquid's outcome markets different from Polymarket or Kalshi?

Polymarket primarily relies on AMM (Automated Market Maker) models and isolated application layers, while Kalshi is a traditional, siloed financial exchange. Hyperliquid integrates outcome contracts directly into HyperCore.

This allows event contracts to share a unified central limit order book, use native developer APIs, and reside within the exact same trading account as standard crypto assets, spot pairs, and perpetual futures.

How does the 1M $HYPE stake requirement protect the protocol?

To deploy an outcome market DEX slot on Hyperliquid, builders are required to stake 1 million $HYPE tokens. This substantial capital commitment acts as a security bond. If a market creator attempts to maliciously manipulate an oracle feed or trigger faulty state transitions, their stake can be partially or fully slashed and burned by the network’s validators, ensuring strict operational alignment.

Can traders hedge open perpetual positions with HIP-4 outcome contracts?

Yes. Because outcome contracts share the same account architecture as perpetuals and spot assets, traders can engage in cross-market hedging without transferring capital across multiple platforms. For instance, a trader holding an aggressive long perpetual contract can buy a macro-event "NO" outcome contract within the same account to offset downside risk against sudden economic policy shifts or regulatory changes.

How does price-side-time priority break ties on a merged book?

In a shared order book where buying YES at $P$ matches selling NO at $1-P$, orders can sit at the exact same merged price level. Hyperliquid handles this by prioritizing resting sell orders over dual buy orders when they arrive at the same structural priority tier. This unique sorting logic guarantees predictable matching mechanics even when high-frequency traders execute complex dual-sided arbitrage strategies.

What are "negate and merge" operations in multi-outcome questions?

When an event features multiple choices (e.g., three different election candidates), it is structured as a single "Question" built out of multiple separate outcome books. Exactly one choice settles to 1 (YES) and all others settle to 0 (NO). If a trader accumulates NO tokens across every single outcome inside that question, the system recognizes that the basket represents a mathematically guaranteed win. The trader can trigger a "negate and merge" function to redeem those balanced positions for quote tokens (USDH) instantly before the final settlement date.

How are trading and settlement fees calculated for HIP-4 markets?

Following the latest structural update on the network, Hyperliquid implements an optimized six-scenario fee model specifically built for outcome tokens. To lower entry friction for casual users, the protocol charges zero fees on entry or minting. Instead, fees are captured on exit—primarily on position-closing trades or during the final token settlement process, where costs are distributed proportionally based on the final settlement fraction. Additionally, market builders can append an operational fee share of up to 50% to incentivize high-quality venue deployments.