Hyperliquid Builder Codes Explained: How Apps Earn On-Chain Fees

Builder codes are how applications make money on Hyperliquid — transparently, on-chain, and without ever touching your funds. When you trade through a third-party app rather than Hyperliquid's own front-end, that app can attach a builder code to your order and earn a small fee on the fill. It is the mechanism that lets an entire ecosystem of trading tools, bots and interfaces build on Hyperliquid and sustain themselves, and unlike a centralized broker's hidden spread markup, every cent of it is visible and capped on-chain.

This guide explains exactly how builder codes work: the three-step flow, the fee caps and safeguards that protect you, how they differ from HIP-3 (the two are constantly confused), and why this model is better for traders than the alternatives. No hype, the sharp edges stated plainly.

Published June 14, 2026. Last updated June 14, 2026.

What a builder code is

A builder code is an on-chain revenue-attribution tag. When an app routes an order to Hyperliquid on your behalf, it includes its own builder address and a fee rate on the order; Hyperliquid's fee logic then pays that builder a cut of the trade, processed entirely on-chain as part of normal settlement. There is no invoice, no off-chain billing, and no custody — the app never holds your money, it just earns an attributed fee on flow it brought to the exchange.

This is the on-chain answer to a question every app faces: how do you monetize a tool built on a non-custodial exchange without marking up prices or taking custody? Builder codes make the revenue explicit and auditable rather than hidden in a spread.

How it works: the three-step flow

First, approval. Before an app can earn anything from you, you sign an ApproveBuilderFee action that sets a maximum fee for that specific builder address. Critically, this must be signed by your main wallet — not an agent or API key — so granting fee permission is always a deliberate act you control, separate from the scoped keys that place your orders.

Second, attribution. When the app places an order for you, it attaches its identifier and the per-order fee as a small parameter on the order (in the API, an object like {"b": builder_address, "f": fee}). Third, collection: Hyperliquid settles the fee on-chain as part of the fill. The per-order fee the app charges can be anything up to — but never above — the ceiling you approved.

The caps and safeguards

Builder codes are bounded by design, which is what makes them safe to approve. The maximum fee is hard-capped by the protocol: 0.10% (10 basis points) for perpetuals and 1.00% (100 basis points) for spot. An app cannot charge more than that even if it wanted to, and it cannot charge more than the ceiling you personally approved, whichever is lower. You can revoke any builder's permission at any time, and you can hold at most ten active builder-code approvals at once — so the list of who can earn from your trades stays short and under your control.

There are requirements on the builder's side too: a builder must hold at least 100 USDC in perps account value and use the standard account mode to receive fees at all. None of this touches custody — approving a builder fee never gives an app the ability to move or withdraw your funds; it only authorizes a capped fee on fills you initiate.

Builder codes vs HIP-3

These are the two most-confused mechanisms on Hyperliquid, so state the difference plainly. HIP-3 is about creating a market: staking 500,000 HYPE to deploy and run a perp market, and earning a 50/50 split of that market's fees (see our HIP-3 guide). Builder codes are about routing an order: any app can attach its code to orders it sends into any existing market and earn a capped fee on those fills, with no staking and no market to operate.

A single trade can carry both — you might trade a trade.xyz HIP-3 equity market through an app that attaches its builder code. The deployer earns from the market; the app earns from the routing. Different roles, different revenue, often mentioned in the same breath but mechanically separate.

Why this model is better for traders

Compare it to the alternatives. A centralized broker typically monetizes through a spread markup or payment for order flow you can't see and can't quantify. A custodial bot platform often charges a subscription plus holds an API key with trade permissions. Builder codes replace all of that with a single, capped, revocable, on-chain fee on top of Hyperliquid's normal trading fees — and because the app never takes custody, the worst case is a small fee, never a lost balance.

The practical upside for you: tools built on builder codes can be free to use, because the builder earns from flow rather than from a subscription, and you can see and cap exactly what you're paying. Transparent, aligned incentives are the whole point.

Where Signalview fits

Builder codes are exactly how Signalview sustains itself, and we'd rather say so than hide it. Signalview is free to run — you pay Hyperliquid's normal trading fees plus a transparent, capped builder fee on the trades our agents execute, and nothing else. There's no subscription and no custody: agents run on scoped keys that can place orders but never withdraw, and the builder-fee approval is a separate, revocable permission you grant with your main wallet.

It also powers the marketplace: signal authors earn builder fees when other traders deploy their signals, which is what makes publishing a good, backtested strategy worthwhile. The incentive points the right way — Signalview earns when traders actually use strategies that work, not when they pay a flat fee regardless of outcome.

Risk note: perpetual futures are leveraged, high-risk instruments — a transparent fee structure doesn't change that you can lose your entire margin. Nothing here is investment advice.