HIP-4 adds TWAP markets and named sports sides

Three entries appeared in Hyperliquid testnet’s HIP-4 outcomeTemplates registry on 12 August 2026, all within 16 minutes:

The live registry now contains 13 entries. Mainnet still returns an empty array, so this remains a testnet-only permissionless lane.

There are no markets using any of these three entries yet. We checked the live outcomeMeta payload after the changes landed. That absence matters because the registration actions are currently returning HTTP 422 on testnet, including for older entries that worked last week. More on that below.

binaryPrice4: an averaging window instead of one print

The earlier binaryPrice and binaryPrice2 designs ask a familiar question:

Is a named Hyperliquid perpetual above a threshold at a specified time?

Their result is determined by the mark price at that instant. binaryPrice4 keeps the same Yes/No shape and adds two inputs:

The resolution text says settlement uses the specified number of seconds of time-weighted average price ending at settlement time. A one-hour BTC example would carry seconds=3600 and could name “the Hyperliquid BTC perp mark” as its feed.

That is a different contract to trade. In a point-in-time market, the final print can decide everything. In a TWAP market, part of the result is already fixed as each second enters the average. Moving the final value generally requires moving more of the window, while predicting it becomes easier as the window fills.

The feed name is also free text supplied by the deployer. It is not automatically bound to the perpetual named in the question. A careful frontend should display that string verbatim, and traders should read it before assuming which index or mark determines settlement.

One safety consequence follows for automated deployers: an old settlement bot that samples one mark at expiry cannot settle a TWAP market correctly. The averaging data and the complete window have to be available before a venue signs the result.

Named sports sides, after one broken vote

The original sportsContestWinner design creates a two-way sports market with literal Yes and No sides. The market title names the participants, but the trade buttons do not.

Both new sports entries replace those labels with two placeholders: {shortNameA} and {shortNameB}. A football market can therefore show PSG and Spurs directly on the trade controls instead of asking a trader to remember which club maps to Yes.

The first attempt, sportsContestWinner2, cannot be filled correctly. Its side names and description reference the two placeholders, but its keyword list does not declare either of them. A deployer has no valid field through which to supply the names.

Five minutes later, sportsContestWinner3 appeared with the same resolution rules and two additional keywords:

shortNameA: shortString
shortNameB: shortString

That is the usable revision. It has 12 inputs in total and preserves the existing sports settlement behavior: side A wins at 1, side B wins at 0, and a draw, void, no contest, or unresolved deadline settles at 0.5.

Named sides look cosmetic until they reach a trading surface. They remove an avoidable mapping step at the exact point where a trader commits an order. Indexers and frontends that hard-code Yes/No will mislabel these markets when the first one appears.

Registration is currently returning HTTP 422

The first deployment attempts did not produce a market. On testnet, registerStandaloneOutcomeFromTemplate and registerQuestionFromTemplate both returned:

Failed to deserialize the JSON body into the target type

The failure was reproduced with binaryPrice4, the older binaryPrice2, the object-shaped example in Hyperliquid’s deployer documentation, and the ordered pairs shape that worked from this codebase on 5 and 6 August. More than 30 payload variants produced the same response.

Controls narrowed the fault: a normal cancel returned HTTP 200, and settleOutcome under the same signed spotDeploy.outcome envelope parsed and returned a semantic “Invalid outcome” response. The two registration variants are the part currently failing to deserialize.

That evidence supports two possibilities: registration is temporarily broken, or its accepted JSON shape changed without the public example changing. It does not establish which one. We will not call a market live until it appears in outcomeMeta and has a working Purrdict route.

Read the registry yourself

The registry is unauthenticated:

curl -s -X POST https://api.hyperliquid-testnet.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type":"outcomeTemplates"}'

At publication time, the relevant live differences are:

binaryPrice4
  + priceDescription:string
  + seconds:uInt

sportsContestWinner3
  side names: {shortNameA}, {shortNameB}
  + shortNameA:shortString
  + shortNameB:shortString

We are watching both the registry and the first successful deployment. The next useful proof is not another schema diff. It is a live TWAP or named-side market that traders can open, inspect, and trade.

Purrdict monitors HIP-4 market metadata and builds prediction-market tooling on Hyperliquid.