Skip to main content
HIP-4 outcome markets use side identifiers and probability-priced fields. mark_price and mid_price represent implied probability in [0, 1], not USD. Stored HIP-4 market-data coverage for native order books, trades, open interest, and L4 begins May 2, 2026 across current symbol rows. Outcome discovery and settlement metadata are separate route contracts: the outcomes response exposes is_settled. The candles route provides a probability-history series without a per-schema floor in the current coverage response. Use the selected outcome side’s coverage metadata for the exact window rather than inferring a venue-wide history.

HIP-4 REST

Outcome-market route family.

Response schemas

Shared field rules and envelope behavior.

Route Scope

The current contract keeps outcome-market routes under /v1/hyperliquid/hip4/*: There is no HIP-4 funding or liquidation route. A listed route does not establish non-empty coverage for every outcome; use coverage and freshness for the selected identifier before relying on its window.

Implementation Pattern

For probability-history analysis, an outcome-liquidity monitor, or an outcome-market dashboard, start by discovering the question or outcome side, then pull one small order-book, trade, or candle request. If the output feeds a model, alert, or backtest, check data-quality routes and label price fields as probabilities. Preserve the # identifier or URL-encoded form in requests and storage.

Next Step

Open HIP-4 REST, then pair it with Schemas and Reliability and gaps.

Workload Boundary

Use this family when the application needs outcome-market state rather than a normal perp or Spot market. The relevant workloads are probability-history analysis, outcome-liquidity monitoring, and outcome-market dashboards. Keep HIP-4 output separate from dollar-priced series in storage and analytics, and add data-quality checks before a model or alert acts on the result.
Last modified on August 28, 2026