HIP-4 Fees & Architecture: How Prediction Markets Really Work on Hyperliquid

TLDR

• HIP-4 trades on spot rails — 7 bps taker, 4 bps maker — not on perp rails, and there is no extra HIP-4 surcharge
• Fees are denominated in outcome tokens, not USDH; you must normalize against the current share price to get the true USDH cost
• Settlement is a native HyperCore L1 action — one block, no oracle, no dispute window, no claim step
• The EVM parimutuel contracts floating around are third-party — official HIP-4 lives entirely on HyperCore

1. HIP-4 trades on spot rails, not perp rails

This is the most common misconception about HIP-4. Outcome tokens trade under the same fee schedule as regular spot pairs — not as perpetual futures.

On Hyperliquid’s testnet, base rates are:

There is no additional HIP-4 surcharge layered on top. Prediction markets get the same baseline as any other spot asset. The protocol does contain a governance hook called VoteGlobalAction::SetOutcomeFeeScale (more on that below), but it is currently neutral and has never been exercised to add an extra fee tier.

The practical implication: a $500 USDH taker position costs $0.35 in fees. On Polymarket, the same trade costs $5–10.

2. The fee trap: fees are in outcome tokens, not USDH

Here is where people get confused reading their fill history.

When you buy YES shares on a HIP-4 market, your fill record shows something like:

{
  "coin": "#90",
  "px": "0.5900",
  "sz": "950",
  "fee": "0.5600",
  "feeToken": "+90"
}

The fee is 0.56 — but 0.56 of what? It is 0.56 shares of the outcome token (+90), not 0.56 USDH.

To get the true USDH cost, multiply by the share price:

fee_usdh = fee_shares × fill_price
         = 0.56 × 0.59
         = 0.33 USDH

Then check it against the trade notional:

fee_bps = fee_usdh / (sz × px) × 10000
        = 0.33 / (950 × 0.59) × 10000
        = 0.33 / 560.50 × 10000
        = 5.6 bps

That matches userSpotCrossRate exactly — confirming HIP-4 uses spot cross-rate fees, not a different schedule. The token denomination is not a trick or a discount; it is just how the fill record is structured. You must normalize when computing P&L or true cost basis.

Important asymmetry: on the buy side, feeToken is the outcome token (+NNN). On the sell side, feeToken is USDH, because you are receiving USDH from the sale and the fee is deducted from that receipt.

3. No deployer cut

One concern with any token-based system is whether token deployers take a revenue share from trading.

On HIP-4, the answer is no. deployerTradingFeeShare is 0.0 for every outcome token on the protocol. There is no hidden fee going to whichever entity created the market.

You can verify this through the tokenDetails endpoint:

curl -X POST https://api.hyperliquid-testnet.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type": "tokenDetails", "tokenId": "0x..."}'

The deployerTradingFeeShare field will be 0 for all HIP-4 outcome tokens. What you see in the fee schedule is what you pay — nothing more.

4. The governance hook exists (but is currently neutral)

A lever does exist for adjusting prediction market fees at the protocol level. The hl-node binary contains:

VoteGlobalAction::SetOutcomeFeeScale

This is a single parameter with a cooldown between changes. It was found via binary analysis of the hl-node release by @quertyeth from @valtitudexyz, who did the fee structure deep-dive.

The key word is currently. The governance hook is present but has not been used. All markets run at the neutral scale factor. If the Hyperliquid team or community ever votes to adjust prediction market fees, this is the mechanism they would use.

For traders today: the hook is dormant. The cost structure you see now is what is active.

5. Settlement is native L1 — no oracle, no claim

Settlement on HIP-4 is not a smart contract call, not an optimistic oracle timeout, and not a manual claim. It is a VoteGlobalAction on HyperCore L1.

The sequence:

1. An authorized resolver submits the outcome via VoteGlobalAction on HyperCore
2. The matching engine receives the action in the same consensus round
3. Trading halts on the resolved market, all open orders are cancelled
4. Settlement fills are generated automatically — winners at px: "1.0", losers at px: "0.0"
5. USDH lands in the winner’s balance atomically

There is no dispute window. There is no Merkle proof to submit. There is no external oracle dependency for price-based outcomes — those resolve against Hyperliquid’s own spot/perp price feeds.

The fills appear in userFills with dir: "Settlement". The closedPnl field contains the actual profit or loss in USDH. For price-binary markets, settlement takes one block. For community/event markets, it takes one block after the resolver submits.

This is the meaningful architectural gap between HIP-4 and Polymarket. Polymarket settlement involves UMA’s optimistic oracle, a 48-hour challenge window in contested cases, and a manual claim transaction. Your capital is locked during that entire window. On HIP-4, capital is available in the next block.

6. Pair minting: YES + NO always equals 1.00

Understanding this mechanism explains why HIP-4 orderbooks work the way they do.

When you place a buy order for YES shares at price p, the engine automatically mirrors it as a NO order at price 1 - p. If your YES bid at $0.70 matches, the engine simultaneously creates a NO ask at $0.30.

The engine mints new shares to fill matched orders. The system wallet addresses (0x3000...) that hold the initial token supply never actually sell — they exist only to satisfy accounting requirements. All real trading is mint-on-demand.

The result: YES + NO always sums to exactly $1.00. Buying YES at $0.70 and buying NO at $0.30 is equivalent to depositing $1.00 USDH and receiving one YES and one NO share. Resolving YES at $1.00 simply lets the YES holder claim the full collateral.

This mirrored-orderbook architecture means you only need to watch one side to understand liquidity. The NO book is the mathematical mirror of the YES book.

7. EVM contracts are third-party — official HIP-4 is L1-only

This is worth being explicit about because confusion here is common.

There are parimutuel-style contracts deployed on HyperEVM (V1 and V2). These contracts allow users to deposit USDC or USDH and participate in outcome markets through a pooled mechanism. They have a different fee structure and different settlement mechanics than native HIP-4.

These contracts are not official HIP-4. They are third-party products built on HyperEVM.

The original reverse-engineering research on these contracts was done by @Yaugourt, who maintains liquidterminal.xyz/hip4 — a valuable documentation resource for understanding how those EVM contracts work internally.

Official HIP-4 is entirely on HyperCore L1:

• Orderbook matching on HyperCore
• Settlement via VoteGlobalAction on HyperCore
• Balances tracked in spotClearinghouseState on HyperCore
• No EVM contract involved in the standard trading flow

If you are trading on Purrdict, you are using official HIP-4 on HyperCore — not the EVM contracts. The distinction matters because fee structures, settlement timing, and capital efficiency are different between the two systems.

Also worth mentioning: the hypercore-indexer by ExoMonk provides open tooling for indexing HyperCore data, which has been a useful reference for understanding the on-chain data structure.

Summary: what this means for traders

Try it on Purrdict

Purrdict is a HIP-4 interface built on official HyperCore. Low fees, instant settlement, shared margin across perps and spot.

app.purrdict.xyz — testnet is live, free to use.

Follow updates: @hypurrdict on X. Join the community: Discord.

Research credit: @quertyeth / @valtitudexyz for hl-node binary fee analysis. @Yaugourt for EVM contract reverse-engineering and liquidterminal.xyz/hip4 documentation. ExoMonk/hypercore-indexer for open HyperCore indexing tooling.