Hyperliquid Builder Codes: Monetizing a Trading Frontend

Every order your frontend routes to Hyperliquid can pay you a fee, up to 0.1% of notional on perps, if you attach a builder code to it. That's the entire pitch: no rebate agreement to negotiate, no revenue-share contract with the exchange, no minimum volume. You register an address on-chain once, get user approval for a max fee, and stamp that address onto orders you send on their behalf. Hyperliquid splits the taker fee and routes your cut to your builder address automatically.

If you're building any kind of trading UI on top of Hyperliquid — a copy-trading dashboard, a perps terminal, a bot that manages positions for other people — this is the difference between running a cost center and running a business.

What a builder code actually is

A builder code is just an Ethereum address that you control, plus a per-order fee you request. When a user signs an order through your app, the order payload carries a builder field: your address and a fee expressed in tenths of a basis point. Hyperliquid validates that the user has approved your address for at least that fee, deducts it on top of the normal exchange fee, and credits it to you.

Two numbers to keep straight:

• Perps cap builder fees at 0.1% (10 bps) of notional.
• Spot caps them at 1%, though realistically you'll charge far less if you want fills.

The fee is charged on the taker side and is added to what the user pays — it does not come out of Hyperliquid's cut. So a maker-heavy strategy earns you nothing from builder codes on its passive fills, which matters a lot for how you model revenue on a market-making frontend.

Registering and getting approval

There are two on-chain steps, and people conflate them.

First, your builder address needs a small amount of USDC in its perps account — the address has to be "activated" before it can receive fees. A few dollars is enough. This trips up almost everyone on their first integration: you attach the code, orders fill, and no fees show up because the receiving address was never funded.

Second, the user approves your builder address up to a maximum fee via an approveBuilderFee action. This is a one-time signature per user. Your app can't silently raise the fee later beyond what they approved; if you signed them up at 1 bp and try to charge 5, the order rejects.

Here's the approval and an order with a builder code attached, using the Python SDK:

from hyperliquid.exchange import Exchange
from hyperliquid.utils import constants

exchange = Exchange(wallet, constants.MAINNET_API_URL)

# One-time per user: approve up to 0.1% for our builder address
exchange.approve_builder_fee(
    builder="0xYourBuilderAddress",
    max_fee_rate="0.001",          # 0.1% ceiling the user consents to
)

# Every order thereafter carries the builder code
exchange.order(
    name="ETH",
    is_buy=True,
    sz=2.0,
    limit_px=3450.0,
    order_type={"limit": {"tif": "Ioc"}},
    builder={"b": "0xYourBuilderAddress", "f": 5},  # f = 5 -> 0.5 bp
)

The f field is the gotcha. It's in tenths of a basis point, so f: 5 is 0.5 bp, f: 10 is 1 bp, and f: 100 is 10 bp — the perps maximum. Set it to 1000 expecting 1 bp and you'll either overcharge your users by 100x or get every order rejected against their approval. If you're wiring this up in Rust instead, the field layout is identical; the Python and Rust API guide covers the signing differences that actually bite.

Modeling the revenue

The math is refreshingly simple, which makes it easy to sanity-check whether an app is worth building.

daily_builder_revenue = taker_notional * builder_fee_rate

Say your users push $8M/day in taker volume — a mid-size copy-trading app or an active bot fleet. At a 1 bp builder fee:

$8,000,000 * 0.0001 = $800 / day  ≈ $24,000 / month

Bump the fee to 2 bp and you're at ~$48k/month, but now you're competing on cost with every other frontend, and sophisticated users will notice. The realistic ceiling most apps settle at is 1–2 bp for retail-facing perps UIs. Charge more and your power users route around you.

Three things wreck the naive model:

• Maker fills earn nothing. If half your flow rests on the book, halve your revenue estimate. A funding-rate arbitrage strategy that quotes passively will generate far less builder revenue than a momentum bot that crosses the spread.
• Volume is Pareto. A handful of whales usually drive most notional, and whales are the most fee-sensitive users you have. Losing three of them can halve your top line.
• Taker volume ≠ signups. Ten thousand users who each trade $50/day is $500k notional — $50/day at 1 bp. One serious desk doing $5M/day is worth ten thousand tourists.

For a worked comparison of where the actual edge sits on Hyperliquid, the breakdown of funding-rate arbitrage against CEX venues and the HLP vault strategy explainer are both useful reality checks — builder fees are a tax on flow, not a source of alpha, and users only tolerate them if your app is genuinely earning them money.

Gotchas worth the paragraph

A few things I've watched teams get wrong:

Attribution is per-order, not per-account. There's no "set it and forget it" account-level builder tag. If a code path in your app sends an order without the builder field — a liquidation-avoidance market close, a stop that fires through a different module — that fill is free for the user and earns you zero. Audit every order-sending path. This is a common leak in liquidation-protection bots where the emergency-close code was written before builder codes were added.

Approval ceilings are sticky. Users approve a max once. If you launch at 0.5 bp and later want 1.5, you have to re-prompt every existing user for a new signature, and many won't return. Set your ceiling generously at approval time (say 0.1%) and charge below it — you can always lower the actual f per order without a new signature, but never raise it past the approved max.

Fund the builder address first. Restating this because it's the number one reason a correct integration shows $0: activate the receiving perps account with a few USDC before you expect a cent.

Test on testnet with real approval flow. The approval signature and fee accounting behave differently enough that eyeballing mainnet is a bad idea. Run a dashboard against testnet and confirm fees land in your builder address before you point real users at it.

Builder codes turn "we built a nice Hyperliquid UI" into "we built a nice Hyperliquid UI that pays for itself." The integration is a day of work; the revenue model is a spreadsheet. The hard part is building a perps trading app good enough that users are happy to pay the extra basis point to use it.