HIP-4 Markets That Settle Early

Every HIP-4 price market ever deployed asks its question about a single moment. Will BTC be above 66,000 at 16:00 on the 21st. The price spends the whole week doing whatever it likes, and none of it counts. Only the last reading does.

A template called priceTouch appeared in the Hyperliquid testnet registry this morning, and it is the first one that watches the whole path.

The template

Straight from {"type":"outcomeTemplates"}:

{
  "id": "priceTouch",
  "role": { "standaloneOutcome": { "sideNames": ["Yes", "No"] } },
  "name": "{perp} touches {target} by {time}",
  "keywords": [
    ["perp", "hlPerp"],
    ["priceDescription", "string"],
    ["seconds", "uInt"],
    ["target", "uDecimal"],
    ["time", "dateTime"]
  ]
}

Five keywords, four of them familiar from binaryPrice4. The interesting one is the rename: threshold became target. Same type, same role, different word, and every parser in the ecosystem that matches on threshold: reads a priceTouch description and finds nothing.

The resolution prose is where the change actually lives:

The market resolves to Yes once the {perp} price touches {target}, and resolves to No at {time} if the price has not touched {target} by then. The price counts as touched once the {seconds}-second TWAP of {priceDescription} price equals or crosses {target} at any time after this market is deployed and before {time}.

Three phrases in that paragraph carry consequences.

”At any time after this market is deployed”

The observation window opens at deployment. Not at some later start keyword, because there is no start keyword. The clock begins when the outcome exists.

That makes the target only meaningful relative to the price at the moment of deployment. Deploy a market whose target the price has already passed and it is Yes before anyone can quote it. Deploy one seconds after a spike and you have sold a lottery ticket that already won. In finance this is a barrier option, and the barrier being live from inception is exactly what makes an American barrier different from the European contracts HIP-4 has been minting until now.

A touch binary is worth strictly more than a terminal one

This is the part that changes how these markets should be priced.

Take two markets on the same underlying, same strike, same expiry. One asks “above 66,000 at expiry”. The other asks “touches 66,000 before expiry”. Every path that wins the first market also wins the second, because a price that finishes above the strike had to cross it on the way. But paths that spike to 66,001 on Tuesday and sag back to 61,000 by Friday win the touch market and lose the terminal one.

So the touch market’s Yes leg dominates. Its price should never trade below the corresponding terminal binary, and for a volatile underlying with a week to run, it should trade meaningfully above it. For a symmetric random walk with no drift, the classic reflection-principle result puts the touch probability at roughly twice the terminal probability for an out-of-the-money barrier. Real markets have drift, fees, and a TWAP smoothing the barrier, so do not take the factor of two literally. Take the inequality literally.

If both markets are live at once and the touch is quoting below the terminal, that is not a view. That is an arbitrage.

It can settle before it expires

Read the description again: “resolves to Yes once”. Not at {time}. Once.

Every downstream system that has ever handled a HIP-4 price market assumes the market’s time: keyword is when it resolves. Our rotator settles at expiry off the 1m candle close. Our launchpad sorts and prefills by expiry. A parlay leg’s deadline is its expiry. All of that quietly assumes resolution and expiry are the same event, and for priceTouch they are not: the Yes case resolves early, and only the No case waits for the clock.

The practical failures this creates, in order of how much they cost:

• A settled market that still looks pending. If nothing is watching the TWAP, a market that touched its target on Tuesday sits unresolved until someone notices. During that window the Yes token is worth exactly one dollar and is still quotable at less. Whoever is watching gets paid by whoever is not.
• Combos that are already decided. A parlay whose touch leg has been determined for two days still renders as live. Nothing is unsafe about it, because settlement is evaluated at settle time, but every deadline heuristic derived from the time: keyword is now wrong.
• Settlement is manual. Nothing in the template or in the deployer-actions documentation settles a touch market automatically. The deployer posts settleOutcome, same as every other template outcome. Which means a touch market is an obligation to watch a price feed, not a fire-and-forget deploy. That is a real operational difference from a market you can settle once, at a known minute, from a candle.

The tie-break flipped

A small detail, and the kind that costs somebody a payout eventually.

priceTouch says the price counts as touched once the TWAP “equals or crosses” the target. An exact touch resolves Yes.

The existing binaryPrice family asks whether the price is above the threshold, so an exact touch of the threshold resolves No. Strictly-above wins Yes; equality loses.

Two live templates, sitting in the same registry, with opposite conventions on the identical edge case. Neither is wrong. Both are one word of prose deep.

The other one: scalars escape the price feed

priceTouch did not land alone. sportsScalarMarket arrived in the same batch, and it is the shortest template on the registry:

{
  "id": "sportsScalarMarket",
  "role": { "standaloneOutcome": { "sideNames": ["Over", "Under"] } },
  "name": "{measure} from {low} to {high}",
  "keywords": [
    ["high", "uDecimal"],
    ["low", "uDecimal"],
    ["measure", "string"]
  ]
}

The payout arithmetic is identical to scalePrice, the scalar template that landed hours earlier: Over pays a dollar at or above high, nothing at or below low, and a linear ramp in between, with Under paying one minus Over. What is different is everything around it.

There is no perp. There is no time. There is no seconds, no priceDescription, no officialSource. Three keywords, and one of them, measure, is unvalidated free text that carries the entire subject of the market, its units, and its implied resolution source at once. “Total goals in Arsenal v Manchester City, FA Community Shield 2026” is a valid measure. So is anything else a deployer can type into a hundred characters.

Two consequences fall straight out of that.

Nothing on-chain says when this market ends. Every other template carries a time or a resolutionDeadline. This one carries neither, so no consumer can compute an expiry, sort by it, or alert on it. Settlement happens when the deployer says the official final value is in.

Nothing on-chain says who is official. The prose promises “the official final value of {measure}” and no keyword names the authority. sportsContestWinner has an officialSource keyword precisely because this matters. Here the entire trust assumption lives in whatever the deployer wrote in a free-text field.

That is not necessarily a flaw. It is the most expressive template on the registry by a distance, and it makes any measurable quantity into a market with no protocol change at all. It just means the deployer, not the protocol, is the thing you are trusting.

What scalars still do to combos

Same warning as this morning, now with a second template attached to it.

Most HIP-4 parlay implementations map a settlement fraction to three outcomes: at or above 0.99 is a win, at or below 0.01 is a loss, and anything between voids and refunds. That rule was written for sports draws, and applied to a scalar it is safe. Nobody drains an escrow.

But a scalar settles strictly inside its range in every case except the two extremes, so a scalar leg voids the combo almost always. It is a refund machine wearing the costume of a bet. The honest fix is to keep scalar templates out of leg selection entirely, and to key that exclusion off the side names, Over/ Under and Long/Short, rather than a list of template ids. There will be a third scalar.

Deploying one

The action is registerStandaloneOutcomeFromTemplate, keyword values as ordered pairs in the registry’s own order, which is alphabetical: perp, priceDescription, seconds, target, time.

If you are wiring this up today, the thing that will waste your afternoon is not the new template. Template instances have required a deployerFeeScale field, a decimal string in [0, 10], since the 13th. Omit it and you get this:

WITH    deployerFeeScale -> 200 {"status":"err","response":"Unable to recover signer."}
WITHOUT deployerFeeScale -> 422 Failed to deserialize the JSON body into the target type

That is a real differential probe against testnet with a deliberately bogus signature. The 422 fires at JSON deserialization, before signature recovery, so the request never reaches the part of the exchange that could tell you which field is missing. It looks like a transport failure. It is a missing string.

We deployed the first touch market on testnet the morning the template landed:

perp:BTC|priceDescription:Hyperliquid BTC-USD perp mark
seconds:300|target:66000|time:20260821-1600

BTC mark was 62,840, so the target sits about 5% above spot with a seven-day window, and the 300-second TWAP means a single wick cannot trigger it. On-chain the outcome stores only those keyword values, pipe-joined in keyword order, under the marker name template:priceTouch, with sides template:Yes and template:No.

Where this is going

Three payoff shapes landed on HIP-4 in one day: a linear ramp on price, a linear ramp on an arbitrary measured quantity, and a path-dependent barrier. None of them required a change to the minting engine, the order book, or the settlement path. The invariant that the two sides sum to one dollar absorbs all of it.

The template system is turning out to be a derivatives-expression language that happens to be governed by validator vote. What it can express has stopped being the interesting question.

What is interesting now is that the interfaces on top were built when a HIP-4 market meant one number, read once, at a known minute. Every one of those assumptions broke this week. Ours included.