HIP-4 gets macro: the policyRateDecision template explained
A three-way central-bank rate template is live in HIP-4's permissionless testnet lane. Learn its outcomes, resolution rules, and pricing asymmetry.
On 4 August 2026, between 09:39 and 10:41 UTC, four new entries appeared in Hyperliquid testnet’s HIP-4 template registry. Together they add a market shape the protocol did not have the day before: a central-bank rate decision.
You can see them yourself:
curl -s -X POST https://api.hyperliquid-testnet.xyz/info \
-H 'Content-Type: application/json' \
-d '{"type":"outcomeTemplates"}'This post is the raw read: what the template says, how it resolves, and the one asymmetry in its rules that changes how you should price it.
Background: what a HIP-4 template is
HIP-4 markets are normally created by Hyperliquid itself. The permissionless lane — live on testnet — lets anyone with an activated deployer venue create a market, but only from a template that validators have voted in. A template is a parameterised market: a name string, a resolution description, and a list of typed keywords you fill in at deploy time.
Before today there were five: two crypto price binaries (binaryPrice, binaryPrice2) and three sports entries (sportsContestWinner, plus the three-way sportsContestResult question and its named outcomes). Everything on the lane was either a coin price or a game.
The new template
policyRateDecision is a question template — a group of named outcomes where exactly one pays $1 and the rest pay $0. Its title renders as:
{institution} {decisionLabel} rate decision
So a September FOMC market reads “Federal Reserve September rate decision”. Six keywords parameterise it:
| Keyword | Type | What it is |
|---|---|---|
institution | string | The central bank making the decision |
decisionLabel | string | Which meeting, e.g. “September” |
policyMeasure | string | The exact measure, e.g. the target range for the federal funds rate |
officialSource | string | Who publishes the number — the primary resolution source |
scheduledDecision | dateTime | When the decision is scheduled, UTC |
decisionDeadline | dateTime | The hard cutoff for a published value |
Three named outcomes hang off it: No change, Decrease, Increase. Two of the three — policyRateIncrease and policyRateNoChange — were voted in alongside the parent. They declare no keywords of their own; each is a one-line pointer back to the parent’s rules.
How it resolves
The template defines two numbers and compares them:
- Decision Value — the numeric value of the policy measure announced by the official source at the scheduled decision.
- Prior Value — the value of that same measure in effect immediately before.
Then: equal → No change. Lower → Decrease. Higher → Increase. Exactly one resolves Yes; the other two, and the protocol-created fallback outcome, resolve No.
A few details that matter more than they look:
- Only the scheduled decision counts. Inter-meeting or emergency moves are ignored — except that they do reset the Prior Value. A bank that cuts between meetings and then holds resolves No change.
- First print wins. “Resolution uses the initially published decision; later revisions do not change the resolution.” No revision risk.
- Rescheduling is tolerated, up to a point. If the meeting moves, the rescheduled decision applies — but only if it is published by the
decisionDeadline. - Successor measures are handled. If the bank retires the measure, the closest official successor named by the source is used.
The asymmetry: No change wins when nothing happens
Here is the line worth reading twice:
If the Decision is canceled or postponed without a replacement decision, or no official Decision Value is published by {decisionDeadline} UTC, No change resolves to Yes.
Every failure mode — cancellation, indefinite postponement, a source that simply never publishes — routes to No change. It is not a void, not a refund, and notably not a 0.5 split.
That is a deliberate departure from the sports template that landed a day earlier. sportsContestWinner, the two-way shape, settles at 0.5 on a draw, a no-contest, or an unresolved deadline: your stake comes back halved either way. policyRateDecision has no such escape hatch. Somebody has to be paid $1, and by construction that somebody is No change.
For a trader, the practical consequence is that No change carries the tail risk of the entire market, on top of being the most likely outcome most of the time. It should trade at a premium to your pure “will they hold” estimate — by exactly the probability that the meeting doesn’t happen at all.
One leg landed an hour late
At 09:41 UTC, when we first captured the registry, policyRateDecrease — the third named outcome — was not there. The parent question names three results; only Increase and No change had templates, so the family was not deployable as written: a question needs all of its named outcomes.
At 10:41 UTC the missing leg appeared:
{"id":"policyRateDecrease",
"role":{"questionOutcome":{"parent":"policyRateDecision"}},
"name":"Decrease","keywords":[],
"description":"This outcome resolves to Yes if the Decision Value is lower than the Prior Value under the parent question's rules."}No keywords, and the same one-line form as its two siblings — the substance all lives in the parent question. The registry now returns ten templates, and the policy-rate family is complete and deployable by any activated venue.
Two practical notes if you are building against this. First, the legs of a question can arrive minutes or an hour apart, so read the registry rather than assuming a family is whole. Second, as of this writing no policyRateDecision market exists on-chain yet — outcomeMeta has zero of them. The template is live; the first market is not.
Why this one matters more than the last one
The interesting thing is not the Fed. It is the sequence.
binaryPrice → binaryPrice2 → sportsContestWinner → sportsContestResult → policyRateDecision, each within days of the last. Hyperliquid is adding one vertical at a time, and each new vertical arrives question-shaped: a parameterised group with named outcomes and a long, carefully lawyered resolution description.
Crypto prices were the proof of concept. Sports was the first real category. Macro is the first category that isn’t a scoreboard — the first where the resolution source is an institution publishing a number, and the rules have to survive rescheduling, cancellation and revision. The template handles all three explicitly. That is a protocol being built for the general case, not for a demo.
It also tells you where the on-chain category taxonomy is going. This template’s metadata block carries category:economics — a value that had not appeared on HIP-4 before today. If you index HIP-4 data, that string is new on your wire today.
Reading the registry yourself
The template registry is a single unauthenticated call, on both testnet and mainnet:
curl -s -X POST https://api.hyperliquid-testnet.xyz/info \
-H 'Content-Type: application/json' \
-d '{"type":"outcomeTemplates"}' | jq '.[].id'Mainnet currently returns an empty array — the permissionless template lane is testnet-only for now. When it opens, this is the endpoint that will tell you first.
We monitor this registry continuously and write up every change. Purrdict is a HIP-4 prediction-market front end and data pipeline built on Hyperliquid.
Ready to trade?
Explore curated HIP-4 outcome markets on Hyperliquid mainnet through the Purrdict trading interface.