Hyperliquid builder codes: earn fees on routed order flow

If you route someone’s order to Hyperliquid, you can get paid for it. That is the whole idea behind Hyperliquid builder codes: a front end tags each order it submits with the builder’s address, and the protocol skims a small extra fee on that fill and credits it to the builder. No token, no revenue-share contract, no off-chain invoicing. The fee is part of the order action and it settles on-chain like everything else on the exchange. This post covers how the code is set, how you attach it, the HIP-4 outcome-market specifics, the real economics, and the parts that bite you in production.

What a hyperliquid builder code is and how the fee is capped

A builder code is not a string you register in a table. It is your builder address plus a per-order fee value you put in the order action. The fee is denominated in tenths of a basis point. So a value of 10 means 10 tenths of a bp, which is 1 bp, which is 0.01%. A value of 5 is 0.05 bp… read the field carefully, because the unit trips people up constantly.

The fee is capped, and the cap is enforced two ways. There is a protocol maximum the builder cannot exceed, and there is a per-user approved maximum. Before any order carrying your code fills for a given user, that user must have approved a maximum builder fee for your address. If your order asks for more than the user approved, the order is rejected. This is the single most important mechanic: the fee is opt-in per user, capped by the user, and you can never silently raise it above what they signed off on.

Perps and spot have different ceilings, so if you route both, budget for two different approved maxes.

Registering a code and attaching it to orders

There is no separate “register” step for the code itself. What exists is the approval. The user signs an approveBuilderFee action naming your builder address and the max fee they accept, in tenths of a bp. That signature is what unlocks routing for that user.

Once approved, you attach the code to an order via the builder field on the order action. The order action carries the usual asset, is_buy, price, size, reduce_only, and order type, plus:

{
  "builder": {
    "b": "0xYOUR_BUILDER_ADDRESS",
    "f": 5
  }
}

b is the builder address (lowercase), f is the fee in tenths of a bp. That f must be less than or equal to what the user approved, and less than or equal to the protocol cap. Submit the order the normal way. On fill, the builder fee is deducted from the taker and credited to your address. Maker fills and taker fills behave differently, so do not assume every fill pays you.

HIP-4 outcome-market order-flow specifics

HIP-4 outcome markets run on the same exchange plumbing, which is why builder codes carry over cleanly. An outcome market is still an asset with an orderbook, prices bounded roughly between 0 and 1, and orders that place, cancel, and fill through the same action shapes. The builder field attaches the same way.

The catch is the read side. Before you can route an outcome order you need to resolve the asset index, current book, and resolution state, and those live on specific endpoints. We walked through exactly which calls return live HIP-4 state in HIP-4 read paths. Get the index wrong and you will happily route a builder-tagged order into the wrong market.

Settlement is the other difference. A perp position you close whenever. An outcome market resolves to 0 or 1 at expiry, and fills near resolution or right at settlement behave in ways that make fee accrual harder to reason about. Do not model outcome-market builder revenue as if it were a continuous perp book.

The economics: 0.05% on routed volume

Concretely, Verdict routes at a 0.05% builder fee on outcome-market orders. On a taker fill that means 5 bp of notional flows to the builder address. The math is simple: revenue scales linearly with routed volume, not with users, not with page views. A hundred users who each place one small order are worth less than one user who trades size.

That linearity is the whole business case and also the trap. Your revenue is a small slice of volume you did not create, so the front end has to be worth routing through: better market discovery, faster book, cleaner order ticket, signals the raw exchange does not give you. If the UX is worse than trading direct, nobody approves your fee and nobody routes. The fee is real money but it is a rounding error per order, so you need either volume or a reason to exist beyond skimming.

Approvals are also friction you pay for once per user. A first-time trader has to sign approveBuilderFee before their first routed order, which is an extra wallet prompt on top of the order signature. Batch it, explain it, or you lose people at the exact moment they were about to trade.

Building a routing front: the Verdict case

Verdict is our terminal for every Hyperliquid HIP-4 outcome market. The architecture is deliberately thin: a React front end sitting on a read-only data plane for prices, books, and resolution state, and the builder code attached at the order layer. We do not custody, we do not match, we do not hold an orderbook. Hyperliquid does all of that. Verdict adds discovery across every outcome market, a usable ticket, and the 0.05% builder code on routed orders. That is the entire monetization surface: no subscription, no token.

If you want the signals side of the same stack, that lives separately in PredMCP, which exposes cross-venue Polymarket and Hyperliquid data as MCP tools. Verdict is the place you click buy; PredMCP is the place a model reads the market first.

Pitfalls

The approval flow is where most integrations break. Check the user’s approved max before submitting, not after, or you eat rejected orders and confused users who think the app is broken.

Respect the cap. Requesting f above the protocol max or above the user’s approval rejects the whole order. Read the max as tenths of a bp every single time; the unit confusion between bp and tenths of a bp causes more bugs here than anything else.

Watch settlement edge cases on HIP-4. Orders resting into resolution, partial fills at expiry, and markets that resolve while an order is live all need explicit handling, because fee accrual around settlement does not look like a normal fill. Reconcile builder credits against actual fills rather than against submitted orders. What you asked for and what filled are not the same number, and only the fills pay.