HIP-4 Deployer Fee Scale, Explained

Hyperliquid updated its HIP-4 deployer-actions documentation on 12 August 2026 with the first published answer to a question anyone deploying a prediction market has to ask: how does the deployer get paid?

The answer is a field called deployerFeeScale. It is a decimal string between 0 and 10, set when a market is created, and it multiplies what traders pay.

The arithmetic

Every HIP-4 outcome market has a base trading fee rate. The scale sits on top of it. Per the documentation, users trading the outcome’s markets pay:

base rate x (scale + max(scale, 1))

The deployer receives the scale component. The protocol receives the rest, which is max(scale, 1). So the protocol always takes at least 1x base, no matter what the deployer chooses.

Written out as multiples of the base rate:

The kink at 1

Read that table again and the interesting part is not the top or the bottom, it is the bend in the middle.

Below a scale of 1, the protocol’s max(scale, 1) floor is binding. The protocol takes its 1x regardless, so everything the deployer adds is pure addition to the trader’s cost, and a small addition at that. A deployer taking 0.25 raises the cost of trading by a quarter and earns a quarter of base on every trade.

At or above 1, the floor stops binding and the split becomes exactly even: the deployer and the protocol each take scale. A deployer who sets 3 is charging traders six times the base rate and keeping half of it.

That makes the sub-1 range the efficient one. Going from 0.25 to 1 quadruples the deployer’s revenue per trade but takes the trader’s cost from 1.25x to 2x, and prediction-market traders are famously fee-sensitive because the spread they are crossing is often only a couple of cents wide. A market at scale 10 is charging 20x base on an instrument whose entire price range is $0 to $1.

Maker rebates: there are none

The same paragraph settles something that had only ever been an observation:

Maker rebates are never paid on outcome markets.

On Hyperliquid spot, a maker earns a rebate. On HIP-4 outcome markets, a maker does not, and now that is documented rather than inferred. If you are modelling market-making on prediction markets, your revenue is the spread, full stop.

Where the scale attaches

The field goes on the template instance, and only certain ones:

• On registerStandaloneOutcomeFromTemplate, for a single YES/NO market.
• On the questionTemplateInstance of registerQuestionFromTemplate, for a multi-outcome question.

Named outcome instances carry no scale of their own. A question’s scale applies uniformly to its fallback and to every named outcome underneath it, including ones added after the question is already live. One question, one fee scale, no per-outcome variation inside it.

Per-outcome scales are returned by the outcomeMeta info request, so a trader or an indexer can read what a market charges before touching it. At the time of writing, no live outcome on either testnet or mainnet returns a scale field yet: the documentation is ahead of the deployed build. Testnet is running 305 outcomes and mainnet 8, and a search for the field across both payloads finds nothing.

The other change: questions are no longer sealed

The same update quietly retired a limitation. The previous text said the named outcome set of a question was fixed at creation, with support for adding outcomes promised as a future upgrade. That future arrived in the same edit, as a fifth deployer action:

registerAndAssociateNamedOutcomeFromTemplate

It adds one named outcome to a question that is already live. The question must have come from a template, the outcome’s template must declare that question’s template as its parent, and the new outcome counts against the deployer’s active-outcome and daily caps like any other. It inherits the question’s fee scale.

The clever part is what happens to existing positions. Holders of the question’s fallback YES token, the “other” bucket, receive an equal balance of the new outcome’s YES token. If you bought “other” on a four-name market because you thought the winner was somebody unlisted, and the deployer then lists that somebody, you are not diluted. Your “other” position keeps meaning what it meant when you took it.

That changes how a multi-outcome market can be launched. Until now, a “who wins X” market had to enumerate its entire field on day one, because anything you left out was stuck in the fallback forever. Now a market can open with the four names people actually care about and add the fifth when it becomes relevant. The cap is 100 named outcomes per question, and that number did not change.

What did not change

Worth stating plainly, because a docs republish makes everything look new. The staking requirement, the 183-day minimum deployer duration, the Standard account abstraction requirement, the keyword hint types, the way descriptions are derived as keyword:value|keyword:value, settleOutcome, settleQuestion2 and the testnet limits of 10 active outcomes and 50 deploys per day are all unchanged, word for word.

No new templates landed either. Testnet still exposes the same 13.

What it means if you trade

Two habits are worth forming before the field goes live.

Check the scale before you size a position. A market with a scale of 3 costs six times what an identical market at zero costs to enter and exit, and on a prediction market that difference can exceed the edge you think you have. The number is in outcomeMeta, and it will be on our market pages the moment it starts appearing on chain.

And note that the deployer setting the fee is the same party that settles the market. That has always been true on HIP-4, but a deployer with fee revenue has a reason to keep a market liquid and running, which is on balance a good incentive. It is still worth knowing who deployed the market you are trading.

Purrdict trades HIP-4 markets on Hyperliquid at app.purrdict.xyz.