HIP-4 Gets Scalar Markets

Every HIP-4 prediction market until today paid out the same way. You held a token, the market settled, and the token was worth either one dollar or nothing. Sports contests could settle at 0.5 when a match was a draw or never happened, but that was a refund rule, not a payout curve. The question was always binary: did the thing happen or not.

On 14 August 2026 a new template appeared in the Hyperliquid testnet outcomeTemplates registry called scalePrice, and it breaks that assumption. Its tokens can settle at any fraction of a dollar. This is the first scalar market on HIP-4.

What the template says

Query the registry and you get the entry verbatim:

{
  "id": "scalePrice",
  "role": { "standaloneOutcome": { "sideNames": ["Long", "Short"] } },
  "name": "{perp} from {low} to {high} at {time}",
  "keywords": [
    ["high", "uDecimal"],
    ["low", "uDecimal"],
    ["perp", "hlPerp"],
    ["priceDescription", "string"],
    ["seconds", "uInt"],
    ["time", "dateTime"]
  ]
}

Two things jump out before you even read the description.

The side names are Long and Short. Every previous standalone template fixed its sides as Yes and No. A template is allowed to name its own sides, and this is the first one to use that freedom for something other than a yes/no question.

The keywords carry both a low and a high, where the price templates before it carried a single threshold. That pair is the payout range.

The payout formula

The template’s description spells out the arithmetic:

If the {perp} price at time of settlement is at or above {high} at {time}, Long tokens pay out $1 each. If the price is at or below {low}, Long tokens pay out $0 each. Otherwise, Long tokens pay out $1 times (price - {low}) / ({high} - {low}) each. In each case, Short tokens pay out $1 minus the Long payout each.

So the Long token is a clamped linear ramp between two prices:

Long and Short always sum to exactly $1, which is what keeps the existing HIP-4 minting machinery intact. The engine still mints one Long and one Short for every dollar collected. Only the redemption split changes.

Settlement uses the same TWAP mechanism that binaryPrice4 introduced: the seconds-second time-weighted average of the feed named in priceDescription, ending at time. A single-block wick cannot decide the payout, which matters far more for a scalar market than a binary one, because on a ramp every dollar of price is money rather than just the dollars near the strike.

Note that priceDescription is unvalidated free text chosen by whoever deploys the market. It is not bound to the perp keyword. For a market you did not deploy yourself, treat the named feed as a claim and read it literally.

A price of 0.48 is not a 48% chance

This is the part that will quietly break things.

On every HIP-4 market so far, a token trading at 0.48 meant the market thought there was a 48% chance of the event. Price was probability. Nearly every prediction-market interface in existence, ours included, is built on that identity.

On a scalar market it is no longer true. A Long token at 0.48 means the market’s expected payout is 48 cents. That expectation blends the probability of finishing above the range, the probability of finishing below it, and the whole distribution of outcomes in between. There is no single event that has a 48% chance of happening.

Two markets can both print 0.48 and mean completely different things. One might be a coin flip between the two extremes. The other might be near-certain to land mid-range. A percentage label on that number is not a rounding error, it is a category error.

The practical consequences:

• Any interface rendering “48% chance” on a scalar market is stating something false. It should show the expected payout, or better, the implied settlement price, which you can invert directly: price = low + long_token_price * (high - low). A Long at 0.48 on a 60,000 to 66,000 range implies a settlement around $62,880.
• Combo and parlay products that multiply leg probabilities together are doing arithmetic on a number that is not a probability. A scalar leg does not belong in a product of independent binary events.

What it does to parlays

Worth being precise here, because the failure is not the one you would guess.

Most HIP-4 parlay implementations, ours included, map a settlement fraction to a ternary result: at or above 0.99 is a win, at or below 0.01 is a loss, and anything in between is a void that refunds the stake. That rule was written for sports draws.

Applied to a scalar market it holds up safely. A Long that settles at 0.63 falls in the middle band and voids, refunding rather than paying out. Nobody drains an escrow. But it also means a scalar leg voids the combo in almost every case, since landing exactly outside the range is the only way it does not. A scalar market is a bad parlay leg, and the honest fix is to exclude it from leg selection rather than let people build combos that mostly refund.

Deploying one

The action is registerStandaloneOutcomeFromTemplate, with the keyword values supplied as ordered pairs in exactly the order the registry lists them, which is alphabetical: high, low, perp, priceDescription, seconds, time.

One detail that will cost you an afternoon if you miss it. Template instantiations now require a deployerFeeScale field, a decimal string from 0 to 10. Omit it and the exchange does not give you a useful protocol error, it returns a bare HTTP 422 with the body Failed to deserialize the JSON body into the target type. That message says nothing about which field is missing.

We deployed the first one on testnet the morning the template landed:

high:66000|low:60000|perp:BTC
priceDescription:Hyperliquid BTC-USD perp mark
seconds:3600|time:20260821-1600

BTC was trading around 62,850 at the time, so Long opened near the middle of the range. On-chain the outcome stores only the keyword values pipe-joined and sorted by keyword, under the reserved marker name template:scalePrice, and the side names come back prefixed as template:Long and template:Short.

Settlement is manual. The deployer computes the interpolated fraction and posts it via settleOutcome, which accepts any decimal in [0, 1] for a standalone outcome. The deployer-actions documentation now explicitly cites "0.66" as an example of a scalar payout, which is a good sign the two changes shipped together deliberately.

Why this matters more than a template

HIP-4 launched as binary infrastructure. scalePrice shows the template system can express payoff shapes the original design did not contemplate, without any change to the minting engine, the order book, or the settlement path. The constraint that Long plus Short equals one dollar is doing all the work.

Follow that thread and range markets, capped futures, and tranche-style payoffs all become expressible as templates rather than as protocol upgrades. The interesting question is no longer what HIP-4 can settle. It is whether the interfaces built on top of it are still assuming price means probability.

Ours is, and we are unwinding that assumption now.