HIP-4 Outcome Market Data: The Price Is a Probability

HIP-4 outcome markets are Hyperliquid's binary prediction markets, live since May 2026. Each market asks one yes-or-no question with a fixed expiry, and the order-book price is an implied probability between 0 and 1, not a dollar figure. A Yes side trading at 0.67 means the market is pricing the event at a 67% chance. At expiry the outcome settles to 1 or 0. 0xArchive carries HIP-4 records back to launch, including order books, trades, outcome-side open interest, candles, L4 orders, and per-outcome settlements across more than 500 outcome series. Join the price history to the settlement to evaluate calibration and realized outcomes.

Why the price is a probability

A HIP-4 outcome market is a binary contract. It poses a single question with a hard deadline. "BTC above 78,213 on May 3 at 06:00 UTC?" Every market has two sides: a Yes side and a No side. Each contract resolves to exactly one of two values when the question is answered. Yes pays 1 if the event happens and 0 if it does not. No is the mirror.

That settlement rule is what forces the price into a probability. If a Yes contract pays 1 on success and 0 on failure, a risk-neutral price for it is just the probability of success. Buy Yes at 0.67 and you pay 0.67 to win 1.00 if the event lands. The market is telling you it thinks the event is 67% likely. Buy at 0.05 and the market is pricing a long shot at 5%.

The two sides are linked. Yes and No should price close to complementary, so Yes plus No sits near 1.00. Test any deviation against the order book and settlement data rather than treating it as either a signal or noise.

Here is the trap that quietly breaks analysis. HIP-4 reuses the same field names as every perp and spot market: mark_price, mid_price. On a perp, those are USD. On an outcome market, they are probabilities in [0, 1]. If your pipeline treats a HIP-4 mark_price of 0.6674 as "$0.67" and runs it through dollar-denominated PnL, returns, or volatility math, every number downstream is wrong, and nothing errors out. The values are small, positive, and plausible. The bug is silent. The fix is one rule: branch on market type before you touch the price. HIP-4 prices are probabilities. Treat them as such, then convert to odds, log-odds, or expected value, never to dollars.

What HIP-4 data 0xArchive carries

HIP-4 is a Hyperliquid-scoped market family. It is not a separate venue and not a third venue API. It sits under the Hyperliquid namespace alongside core perps, Spot, and HIP-3, at routes beginning /v1/hyperliquid/hip4/. HIP-4 coverage begins in May 2026, when HIP-4 went live. Outcome-side open-interest records begin May 2, 2026. Do not map HIP-4 to 2023; that date belongs to Hyperliquid core perps, not outcome markets.

Because these are settle-to-binary instruments, there is no funding and there are no liquidations on HIP-4 by design. A fully collateralized binary has no funding rate to pay and no liquidation to trigger. HIP-4 provides order books, trades, outcome-side open interest, candles, L4 order records, and per-outcome settlements.

The settlement record is the part that makes outcome data worth studying. A trade tape on its own tells you what people paid. The settlement tells you whether they were right. Pair the price history with the resolved outcome and you can score the market against reality. Without the settlement, you have prices with no answer key. 0xArchive stores both, for more than 500 outcome series.

Each outcome has an integer outcome_id. Each side has its own tradable coin, encoded as 10 * outcome_id + side. Outcome 0 Yes is coin 0, outcome 0 No is coin 1, outcome 1 Yes is coin 10, and outcome 1 No is coin 11. The bare numeric form is canonical. The older #0 and %230 forms still work in routes, so you will see both in the wild.

What you can do with it

Outcome data is a different shape from perp data, so the questions are different too. Four lines of work cover most of it.

Probability calibration

Calibration asks the core question of any forecaster: when the market says 70%, does the event happen about 70% of the time? You answer it by bucketing. Take the market-implied probability at some reference point, say the price one hour before expiry, group every outcome into probability bins (0.0 to 0.1, 0.1 to 0.2, and so on), then compare each bin's average price to the share of those outcomes that actually settled to 1. Plot the realized frequency against the implied probability. A perfectly calibrated market sits on the 45-degree line. Above the diagonal, Yes occurred more often than forecast. Below it, Yes occurred less often. The Brier score, the mean squared error between price and the 0/1 outcome, gives you a single number for the same idea.

Settlement and resolution studies

With the settlement record you can study the endgame. How fast does price converge to 1 or 0 as expiry approaches? How much does it move in the final hour? Do certain question types (a BTC price threshold versus a macro print) resolve more cleanly than others? These are settlement studies, and they need exactly two things: the full price path and the resolved value. You have both.

Mispricing and two-sided arbitrage

Because Yes and No should sum to near 1.00, the pair is a built-in consistency check. When best-ask Yes plus best-ask No drops below 1.00, both sides are cheap relative to the certain payout, and the gap is a spread to capture. Buying both sides costs the sum of their executable asks. To assess selling both sides, use executable bids. Compare the relevant total at matched size and time with the pair payout after fees. Pull the L2 or L4 book for both coins of an outcome, sum the top of book, and you have a clean mispricing series across the markets and timestamps you query.

Backtests and event modeling

The recurring daily BTC-threshold markets are a ready-made backtest set. You can build a strategy that reads the implied probability, compares it to your own model's probability for the same event, and takes the side where your edge is largest. Then you score it against the real settlements. Because the markets repeat daily, you get a dense, like-for-like sample instead of a handful of one-off events.

A short worked example

Say you pull a set of settled BTC daily outcomes and, for each one, record the Yes mid-price 60 minutes before expiry and whether it settled to 1. You bin by implied probability and count:

Read the implied probability alongside the settled outcome. The middle bin is close to calibrated: an average implied probability near 0.50 against a realized 0.545. Both tail frequencies fall inside their quoted bands. To assess calibration, compare each bin's realized frequency with the mean forecast in that bin and report uncertainty. The counts here are illustrative; run the analysis on the archive to get the full curve.

Test calibration with settled events, not selected screenshots

A probability-looking price is not a calibration result. Join pre-expiry observations to confirmed settlement outcomes and keep one defined observation per event and horizon. Paired Yes and No sides are not two independent events.

Population. Enumerate outcomes due to expire by the registered cutoff, then classify each as settled binary, unresolved, void or disputed where evidenced, or missing. Score the Yes instrument against its per-side settlement_value. Preserve settlement_at. Register the cutoff and publication snapshot hash before scoring. Do not select by liquidity, winning side or availability of a favorable chart. Report resolved, void, disputed, missing-settlement and otherwise ineligible events separately.

Selection and time. Horizons: 24h, 6h and 1h before the event's contractual expiry. At each horizon take the last eligible pre-horizon quote within five minutes, provided that a Yes bid and a Yes ask are both present at or before the horizon and before resolution was known. The five-minute tolerance is a proposed research rule, not a product cadence guarantee. Never use a quote after the horizon or a settlement update as a pre-expiry feature. Keep actual UTC quote, expiry and settlement times.

Price policy. Primary predictor: the Yes-side midpoint from the Yes book. HIP-4 prices are probabilities and binary settlement_value is 0.0 or 1.0. No Yes bid or no Yes ask means missing. Do not normalize Yes and No to sum to one unless the study separately reports that transformation and the underlying spread. Treat one event as one observation at each horizon; uncertainty clusters by event or series.

Scores. With binary outcome y and probability p, Brier score is (p-y)**2. Log loss is -(y*log(p)+(1-y)*log(1-p)); report the clipping epsilon 1e-6 as a numerical research convention, not as the raw price, and show unclipped boundary counts. Compare an explicit baseline such as p=0.5, with confidence intervals clustered by event series. Fix calibration bins before seeing outcomes.

Missingness. Report all eligible events, events with settlement joins, events quoted at each horizon and scored events. Do not turn thin or absent books into zero probability. Preserve void and ambiguous outcomes without forcing a binary label.

Scores, calibration curves and other materially transformed outputs fall under the Data License; raw records are not redistributed.

How to pull it

Discover outcomes first. You need the outcome_id and the per-side coin before you can ask for a book or a trade tape. Every route authenticates with an X-API-Key header.

List outcomes, filtering to settled ones for a calibration study:

curl "https://api.0xarchive.io/v1/hyperliquid/hip4/outcomes?is_settled=true&limit=100" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

A record looks like this. Note target_price, expiry, is_settled, and the two side_specs with their coin values:

{
  "outcome_id": 0,
  "class": "priceBinary",
  "underlying": "BTC",
  "target_price": 78213,
  "expiry": "2026-05-03T06:00:00Z",
  "is_settled": true,
  "status": "settled",
  "side_specs": [
    { "side": 0, "name": "Yes", "coin": "#0",  "slug": "btc-above-78213-yes-may-03-0600" },
    { "side": 1, "name": "No",  "coin": "#1",  "slug": "btc-above-78213-no-may-03-0600" }
  ]
}

For each settled Yes-side instrument, choose a fixed observation time before expiry. Read its historical probability and compare it with the per-side instrument metadata’s settlement_value. is_settled and status describe finality, not the winning side; a current summary is not a historical pre-expiry observation.

curl "https://api.0xarchive.io/v1/hyperliquid/hip4/summary/0" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

# legacy side form, still accepted:
curl "https://api.0xarchive.io/v1/hyperliquid/hip4/summary/%230" \
  -H "X-API-Key: $OXARCHIVE_API_KEY"

The response carries the probability-priced fields:

{ "coin": "#0", "mark_price": "0.6674", "mid_price": "0.6674", "open_interest": "873237" }

The rule to keep in the code, in a comment if nowhere else: mark_price here is a probability. Convert to odds with p / (1 - p) or to log-odds, never to dollars.

HIP-4 vs cross-platform prediction-market data

HIP-4 puts binary outcome-market books, wallet-attributed fills and per-side settlement values on the same venue. Join historical probabilities to settlement_value to study calibration without reconciling a separate settlement dataset.

FAQ

Is HIP-4 a separate venue from Hyperliquid?

No. HIP-4 is a Hyperliquid market family, alongside core perps, Spot, and HIP-3. Its routes live under /v1/hyperliquid/hip4/. There are two venue APIs at 0xArchive: Hyperliquid and Lighter. HIP-4 is part of Hyperliquid.

Why is the price between 0 and 1 instead of in dollars?

Because the contract settles to 1 or 0. A price between those bounds is the market's implied probability of the event. The mark_price and mid_price fields are probabilities in [0, 1], not USD. Same field names as a perp, different meaning.

How far back does HIP-4 data go?

To May 2026, when HIP-4 launched. Published route coverage for order books, trades, outcome-side open interest, L4, and per-outcome settlements begins that month. Outcome-side open interest begins May 2, 2026; check current route metadata for other exact starts. HIP-4 history does not extend to 2023; that range applies to Hyperliquid core perps.

Is there funding or liquidation data on HIP-4?

No, by design. HIP-4 outcomes are fully collateralized binary contracts, so there is no funding rate and no liquidation engine. If you need funding or liquidations, those live on the perp routes, not on HIP-4.

How do I find the right Yes and No coin for a market?

Call /outcomes first. Each outcome has an integer outcome_id, and each side has a coin equal to 10 * outcome_id + side. Outcome 0 Yes is 0, outcome 0 No is 1, outcome 1 Yes is 10. The bare numeric form is canonical; #0 and %230 still work.

How do I tell whether a market was right?

Join the price history to the settlement record. Settlements give you the resolved value per outcome. Compare the implied probability over the market's life to the 0/1 result to score calibration, accuracy, or a strategy.

What can I build with the settlement record specifically?

Calibration curves, Brier scores, convergence-to-settlement studies, and backtests that grade a model against real resolutions. The settlement is the answer key. Prices alone cannot tell you who was right.

Next step

Read the HIP-4 outcome market data guide for the coverage map, or go straight to the HIP-4 REST reference for route and field details. When you are ready to run a calibration study across the archive, every HIP-4 route, schema, and served depth is available on every plan; Free covers the most recent rolling 30 days with a maximum 30-day span per request, and Build and above keep the full retained archive. See pricing for limits.