Hyperliquid Builder Codes: What That 'Approve Builder Fee' Popup Means

Onboarding onto any third-party Hyperliquid app involves two signatures. The first, approveAgent, delegates order signing — we covered it in the agent wallets guide. The second is approveBuilderFee, and it is the one that makes people hesitate, because it visibly involves money: you are approving a fee.

The hesitation is healthy. Signing things you don't understand is how DeFi losses happen, and 'approve fee' pattern-matches to unpleasant surprises. But this particular approval is one of the better-designed payment mechanisms in crypto: a hard-capped, per-fill, protocol-enforced fee that pays the app you are using — visible on-chain, and revocable at any time.

Short version: you are not subscribing to anything, you are not granting access to your balance, and you are not signing a blank check. You are setting a ceiling on what one specific builder may add to your fills. Here is exactly how it works.

Builder codes are Hyperliquid's native mechanism for letting third-party applications earn revenue from the order flow they create. The mechanics:

• When an app routes your order, it attaches its builder code — an identifier tied to the builder's address — plus the fee it charges on that order.

• The protocol enforces hard ceilings: builder fees can be at most 0.1% (10 basis points) on perps and 1% on spot. No approval you sign can exceed them.

• The fee is charged only when an order actually fills, collected by the venue as part of trade settlement, and credited to the builder. No invoices, no token, no middleman holding funds.

• Your approval sets a per-builder maximum. The app specifies its fee per order, which must sit at or under your approved cap or the order is rejected.

• Housekeeping bounds: an account can hold up to 10 active builder approvals, and a builder must maintain at least 100 USDC in its perps account to be eligible at all.

The design detail worth appreciating: the fee travels with the order, on-chain. What an app charges is not buried in a pricing page — it is in the approval you sign and in the settlement record afterwards. This mechanism has funded a genuine ecosystem: third-party terminals, bots, and specialized frontends now account for a large share of Hyperliquid's flow, earning tens of millions in aggregate builder revenue — without any of them ever holding user funds.

Read the approval precisely, because its limits are the point:

• It is a ceiling, not a charge. Approving a 0.1% max fee moves nothing. Money changes hands only when a trade fills, in proportion to that fill's notional.

• It is scoped to one builder. The approval names a specific builder address. It grants nothing to any other app, and other apps cannot ride on it.

• It cannot touch your balance. A builder fee is deducted at fill time as part of the trade, like venue fees. The approval grants no withdrawal rights, no transfer rights, no access to resting funds.

• It must be signed by your master wallet. The protocol requires approveBuilderFee to come from the account owner — an agent wallet cannot sign it. That means the app trading on your behalf cannot quietly raise its own pay: the two approvals grant different powers, and the money-touching one always needs you.

• It is revocable at any time. Withdraw the approval and the builder's fee attachment stops working. Nothing about it is locked in.

The honest fine print: the fee applies per fill, so high-frequency strategies pay it often — 10 bps on notional is negligible for a swing trade and material for a strategy that churns hundreds of times a day. Know which kind of trader you are, and read the number in the popup rather than assuming every app charges the same.

Every trading interface has to be paid for somehow, and the funding model shapes the product's incentives. The realistic alternatives:

• Subscriptions charge you while you don't trade, and push the product toward retention theater — features that justify the monthly bill rather than improve execution.

• Spread markups and internalized routing hide the cost inside your fill price. You cannot audit what you paid, and the app is incentivized to route where it earns most, not where you fill best.

• Payment for order flow sells your orders to the counterparty. The conflict of interest is structural.

• Token emissions pay for the app by diluting a token you are encouraged to hold. The incentive is narrative management, not execution quality.

Builder codes are the clean version: usage-based (you pay when you trade, nothing when you don't), protocol-capped (0.1% perps / 1% spot, enforced by the chain rather than promised by the app), transparent (the number is in the approval and the settlement), scoped and revocable. The app's revenue scales with executed volume — which aligns it with being genuinely useful for trading, the one thing you actually want from it.

It is also why the model survived contact with a competitive market: users can read the fee, compare apps, and revoke — so fees converge toward what the value justifies rather than what opacity allows.

Hyperhelm charges 10 basis points (0.1%) on perps notional via its builder code — the protocol's cap for perps — and a 25 bps partner fee on CoW spot executions. Both numbers are shown in the deploy ticket before you sign anything, every time.

What sits behind the fee is the part that differs from a typical terminal: the trade you execute has passed through the full governed pipeline — structure read, playbook matched, and the risk gate's verdict on size, leverage, and levels — with exits placed as native brackets at entry. The fee bills the execution of a governed decision, not access to a screen.

And the looking is genuinely free: the verdict, the structure map, the firing playbooks, and the public governed-vs-ungoverned benchmark are all visible without connecting a wallet, approving anything, or handing over an email. The two approvals — agent and builder fee — appear only at the moment you decide to execute. If you never trade, you never pay; if you do, you pay per fill, capped by a signature you can revoke.

That asymmetry is deliberate. A risk product you have to pay to evaluate is asking for trust it hasn't earned; a fee that only exists when a governed trade executes has to keep earning it.

Thirty seconds of diligence, for any app — including ours:

• Read the number. The approval shows the maximum fee. Perps approvals above 0.1% are impossible by protocol; anything at the cap should come with a reason you find convincing.

• Know the two signatures apart. approveAgent delegates trading; approveBuilderFee caps a payment. An app that needs both should be able to explain both. One never implies the other.

• Check who you're approving. The approval names the builder's address. A legitimate app documents its builder identity; an app that obscures it is telling you something.

• Confirm the master-wallet rule. If anything other than your master wallet is being asked to sign a builder-fee approval, stop — the protocol does not accept agent-signed fee approvals, so whatever is asking is not doing what it claims.

• Audit your approvals occasionally. Up to 10 can be active; apps you stopped using six months ago do not need a standing fee approval. Revoke what you don't use — it costs nothing and shrinks your surface.

• Treat opacity as the answer. An app that makes the fee hard to find has answered your question about the fee.

Builder codes are a good deal for everyone when they are legible: the venue gets an ecosystem, builders get sustainable revenue without custody, and you get specialized tools that bill only when they deliver a fill. Legibility is your half of the bargain — read what you sign.