HIP-4 and the Permissionless Era of Outcome Markets

Hyperliquid's HIP-4 brings outcome markets into HyperCore and opens a new market-creation layer for builders. With permissionless deployment, deployers can create markets from validator-approved templates, specify settlement parameters within those templates, and build specialized trading experiences around them.

Prediction markets are often understood through their frontends. HIP-4 starts one layer lower. It introduces outcome contracts: fully collateralized instruments that settle within a fixed range and can represent a future event, a bounded payoff, or a binary question.

Prediction markets are one application of the primitive. The broader opportunity is a standardized way to turn defined events, thresholds, and decisions into tradable markets inside Hyperliquid's execution environment.

What Is an Outcome Market?

An outcome market pays according to what happens at settlement. In the simplest version, the market has two sides: Yes and No.

A trader who buys Yes is taking exposure to the event occurring. If the market settles Yes, the position receives the full settlement amount. If it settles No, it receives zero. The same logic works in reverse for No. The protocol represents these sides with separate tokens and settles them using a settleFraction between 0 and 1.

Prices provide a compact way to express the market's view. If Yes trades at 0.65, participants commonly read that price as an implied probability of roughly 65%, subject to liquidity, spreads, fees, and market structure.

For example, buying 100 Yes tokens at 0.65 costs 65 units of the quote token. If the event occurs, those tokens settle for 100 units. If it does not, they settle for zero. The payoff is straightforward. The important design work sits in defining the event, identifying the relevant data, and resolving the market correctly.

HIP-4 also supports questions with several possible outcomes. A question can contain named outcomes such as "Candidate A," "Candidate B," and "Other." Exactly one named outcome settles to Yes while the others settle to No. A protocol-created fallback captures outcomes that were not listed individually.

Native Market Infrastructure

Outcome markets run within HyperCore's trading environment, giving deployers access to protocol-level trading and settlement infrastructure. The trading API follows the same general model as spot trading, while outcome books have mechanics specific to complementary sides.

The Yes and No books for one outcome share liquidity. Buying Yes at price p is equivalent to selling No at 1-p. The protocol can therefore treat complementary orders as one merged book while presenting traders with the side they selected.

This gives builders a common foundation for market data, orderbooks, account state, and settlement. Frontends, analytics products, automated strategies, and market-making systems can build around those objects instead of recreating an entire venue stack.

What Permissionless Deployment Changes

Permissionless does not mean unstructured. Every deployer-created market must come from a validator-approved template.

A template fixes the shape of the market's name and description, the available sides, and the typed keywords that a deployer may fill in. A template might define a market around an underlying asset, a threshold, and an expiry time. The deployer supplies those values to create a specific market instance.

Templates also contain semantic restrictions. These restrictions define the intended meaning of the market. An instance that contradicts its template can be treated as malformed, and validators can slash the stake posted by the deployer that created it.
. Validators therefore provide a reusable quality-control layer while deployers determine which valid market instances to create.

The result is a clear division of responsibilities:

• Validators approve reusable market formats and enforce protocol rules.

• Deployers choose which instances to create, when to list them, how to operate them, and how to settle them.

• Traders and builders interact with the resulting markets through Hyperliquid's trading and data interfaces.

Market creation becomes modular. A venue can specialize in a category, a calendar, a community, or a particular trading experience while remaining inside a common protocol framework.

Accountability Is Part of the Design

The deployer model comes with obligations. Active deployers must maintain the required stake. Deactivation requires that the minimum staking duration has elapsed and that the deployer has no active outcomes; the current documentation specifies a minimum duration of 183 days. Deactivation is permanent, and the deployer's venue name remains reserved.

Capacity is also bounded by per-deployer limits. Settling outcomes frees capacity for new markets, creating a rolling model for market inventory.

These constraints reflect the importance of precise specifications and timely settlement. A deployer is accountable for the markets it introduces, and validators have an enforcement mechanism when those markets are malformed or settled incorrectly.

Supporting the Deployer Layer

Outcome markets need more than a matching engine. They also need reliable data inputs, clear settlement criteria, and infrastructure that can support market creation at scale.

Pyth is working with HIP-4 deployers to provide market-data and infrastructure support as this new market layer develops. For markets whose settlement criteria depend on an observable price, Pyth feeds could serve as a potential oracle input, subject to the deployer's written specification and technical integration.

Pyth provides real-time, first-party market data across a range of assets. Its oracle program combines data from multiple publishers into an aggregate price and confidence interval. Where deployers need configurable delivery, Pyth Pro offers customizable, enterprise-grade price data through standard APIs. Those characteristics give deployers market-data inputs they can evaluate when designing settlement logic, including the relevant price, time window, confidence, and staleness requirements.

As deployers explore categories beyond crypto, potential use cases include sports markets and an inference-token index. Pyth is evaluating how additional coverage and infrastructure could support those demands as HIP-4 develops.

The same principle applies across categories: price-based markets may require a market-data feed, while sports, politics, policy, and other real-world events require clearly defined authoritative sources. Pyth can support the data and infrastructure layer without imposing one resolution model on every market.

This builder-first approach builds on Pyth's work supporting market creators across Hyperliquid's market infrastructure, including HIP-3. The objective is practical: help deployers launch reliable markets, integrate the data they need, and create products that can operate beyond the first wave of crypto-native use cases.

Why This Matters for Builders

HIP-4 turns event markets into a building block.

A team can create a market-discovery interface. A market maker can quote probability instruments alongside spot and perpetual markets. An analytics provider can track how expectations change as new information arrives. A developer can combine outcome positions with other Hyperliquid primitives in a broader trading workflow.

The opportunity is wider than prediction-market frontends. Outcome contracts can represent price thresholds, scheduled decisions, event milestones, or bounded payoffs. Their common feature is a defined resolution condition and a finite settlement range.

The standardized format also makes the ecosystem easier to inspect. Hyperliquid exposes outcome metadata, templates, deployer information, and market state through read APIs, giving builders a programmatic way to discover markets and understand how they are intended to resolve.

For data providers, this creates a new surface for supporting specialized market categories. For deployers, it creates access to infrastructure partners that can help translate a market idea into a well-defined, observable, and tradable product.

What to Watch Next

The release opens the market-creation layer. The harder question is whether it can produce durable markets.

First, liquidity will matter more than the number of markets listed. A large catalog with wide spreads and shallow books is mostly a directory.

Second, resolution quality will determine trust. Market language needs to be precise about the event, the data source, the relevant timestamp, and the treatment of edge cases.

Third, deployers will need repeatable distribution and settlement operations. The stake and lockup create accountability, while the template system creates consistency. Neither one creates traders automatically.

Fourth, data coverage will influence which categories can scale. Sports, inference-related assets, and other event markets require inputs that match their settlement rules. The strongest deployer ecosystems will connect market design, data availability, liquidity, and user experience from the beginning.

Finally, the ecosystem will reveal whether multiple venues improve specialization or fragment liquidity. That balance will shape the user experience as more deployers enter the system.

The Takeaway

HIP-4 makes outcome markets a native Hyperliquid primitive. Permissionless deployment widens who can create those markets while templates, staking requirements, semantic restrictions, and capacity limits keep the system bounded.

The release is about more than adding prediction markets. It creates an open framework for turning real-world questions, price conditions, and bounded outcomes into tradable products.

Pyth's role in that expansion is intentionally practical: support deployers with the data and infrastructure they need as new market categories emerge. If HIP-4 becomes a durable market layer, the opportunity will extend to the teams that can make those markets clear, liquid, and reliably resolvable.