Builder codes for developers

How a front end, wallet or bot earns a fee on the orders it sends, and the rules the protocol enforces.

Updated Fact-checked November 4, 2026 7 sources
Short answer

A builder code lets your app add its own fee to orders it sends for a user. The user first signs approveBuilderFee with their main wallet, setting a maximum. Your app then adds "builder":{"b":"0xYourAddress","f":10} to each order, where f is in tenths of a basis point, so 10 means 0.01%. The caps are 0.1% on perps and 1% on spot sells, and each user can have up to 10 active approvals. Your builder address needs at least 100 USDC of perps account value.

Hyperliquid doesn’t charge apps to use its order books, and it doesn’t pay them either. Instead, any front end, wallet, bot or Telegram app that sends orders for a user can attach a builder code: its own address plus a fee, set per order and enforced onchain. This is how MetaMask, Phantom, fomo and others earn from Hyperliquid trading. For what that costs a trader, and what popular apps charge, see builder codes, explained. This page is the developer side.

The rules

From Hyperliquid’s builder codes docs and the exchange endpoint:

RuleValue
Maximum fee, perps0.1% of notional, on both sides
Maximum fee, spot1%, only on the sell side (fees collected in the quote asset)
Outcome markets (HIP-4)Work like spot: builder fees on sell orders (HIP-4)
Who approvesThe user, with their main wallet, never an API wallet
Active approvals per user10
Builder address requirementsAt least 100 USDC in perps account value, and standard account abstraction mode
RevocableYes, by the user, at any time
Sub-buildersUp to 5 addresses can share one order’s builder fee

Units: the part everyone gets wrong

Two different units are in play.

  • Approval (maxFeeRate) is a percent string: "0.01%", "0.1%".
  • Per-order fee (f) is an integer in tenths of a basis point. 1 bp = 0.01%, so f: 10 is 0.01%.
You want to chargemaxFeeRate to approvef on the orderFee on a $10,000 trade
0.001% (0.1 bp)"0.001%"1$0.10
0.01% (1 bp)"0.01%"10$1.00
0.05% (5 bps)"0.05%"50$5.00
0.1% (10 bps), perps maximum"0.1%"100$10.00
1% (100 bps), spot-sell maximum"1%"1000$100.00

Step 1: get the user’s approval

The user signs an approveBuilderFee action with their main wallet. It is a user-signed (EIP-712) action, like a withdrawal, so in a web app the user’s own wallet signs it. The raw action is:

{ "type": "approveBuilderFee",
  "hyperliquidChain": "Mainnet",
  "signatureChainId": "0xa4b1",
  "maxFeeRate": "0.01%",
  "builder": "0xyourbuilderaddress…",
  "nonce": 1793825061957 }

signatureChainId is the chain ID the wallet signs with, in hex (0xa4b1 is Arbitrum, the docs’ example). Use "Testnet" for hyperliquidChain on testnet. Lowercase every address before signing: mixed case is a common cause of bad signatures (signing).

Before asking the user to sign, check what they’ve already approved. This is a free read:

curl -s https://api.hyperliquid.xyz/info \
  -H 'Content-Type: application/json' \
  -d '{"type":"maxBuilderFee","user":"0xuser…","builder":"0xbuilder…"}'

It returns one integer in the same tenths-of-a-bp unit, e.g. 10. An address with no approval returned 0 when we tested on 4 November 2026. {"type":"approvedBuilders","user":"0x…"} lists every builder the user has approved (it returned [] for the same address).

Only ask for the approval when the stored maximum is lower than the f you plan to send. Users can hold only 10 approvals, so asking again and again uses up a scarce slot and trust.

Step 2: add the builder field to orders

Every order action takes an optional builder object:

{ "type": "order",
  "orders": [{ "a": 0, "b": true, "p": "80000", "s": "0.001",
               "r": false, "t": { "limit": { "tif": "Gtc" } } }],
  "grouping": "na",
  "builder": { "b": "0xyourbuilderaddress…", "f": 10 } }

b is your builder address and f is the fee for this order. You can change f per order, up to what the user approved. To split the fee, add "s": [{"b": "0xpartner…", "s": 50000}]. Each share is in units of 0.001%, so 50000 is half of the builder fee. You can list up to 5 sub-builders, each must be an existing user, the shares must add up to at most 100%, and the main builder keeps the remainder (exchange endpoint).

The order itself can be signed by the user’s main wallet or by an API wallet the user approved for your app. Only the builder-fee approval needs the main wallet.

Illustrative only, not run by us. This is the shape of the official SDK's example, on testnet, with the key read from the environment. In a real front end the user's wallet signs the approval. Never ask users for a private key.

# ILLUSTRATIVE ONLY: testnet. Based on examples/basic_builder_fee.py
import os
import eth_account
from hyperliquid.exchange import Exchange
from hyperliquid.utils import constants

user = eth_account.Account.from_key(os.environ["HL_TEST_USER_KEY"])
ex = Exchange(user, constants.TESTNET_API_URL)
BUILDER = "0xyourbuilderaddress"  # lowercase

print(ex.approve_builder_fee(BUILDER, "0.01%"))   # main wallet only
print(ex.market_open("ETH", True, 0.05, None, 0.01,
                     builder={"b": BUILDER, "f": 10}))  # 1 bp

Step 3: track and claim what you earn

  • Per fill. A fill’s fee is the total the user paid, including the builder fee. The builderFee field shows your part, and is left out when it’s 0 (info endpoint).
  • Running total. {"type":"referral","user":"<builder address>"} includes builderRewards. For one large front end’s builder address on 4 November 2026 it read "builderRewards": "3996642.528857…".
  • Daily archive. Every fill that used your code is published per day at https://stats-data.hyperliquid.xyz/Mainnet/builder_fills/{builder}/{YYYYMMDD}.csv.lz4. The address must be all lowercase, or you get an error instead of the file (builder codes). The 2 November 2026 file for one builder downloaded fine (608 KB compressed). The 3 November file wasn’t there yet that evening, so expect a lag.
  • Claiming. Builder fees are claimed “through the usual referral reward claim process”, the same flow as referral rewards.

Our fees dataset tracks 30-day builder revenue by app, if you want to see what the market charges.

Things to know before you ship

  • Builder codes override referral codes on that order. Hyperliquid’s referrals docs say this outright (staking referral proposal). A user with a referral discount loses it on orders that carry your code.
  • Disclose your fee. The protocol caps it, but users compare. The official app charges no builder fee, and published app rates on 4 November 2026 ran from about 1 bp to 10 bps (what apps charge).
  • Standard mode. If your builder address switches to unified or portfolio-margin mode, it stops accruing builder fees (account abstraction modes).
  • Regulation is yours to handle. Hyperliquid’s terms restrict users in the United States, Ontario and other places. Building a front end doesn’t change who may trade, and you may have obligations of your own where you operate.
  • Leverage. Most volume through builder codes is leveraged perps, where users can lose their whole margin. Don’t build flows that hide that.

Questions people ask

What is the maximum builder fee on Hyperliquid?

0.1% of notional on perps, charged on both buys and sells, and 1% on spot, charged only on the sell side because builder fees are collected in the quote asset. In the order's f field that is 100 for perps and 1,000 for spot.

Can an API wallet approve a builder fee?

No. Hyperliquid's docs say ApproveBuilderFee must be signed by the user's main wallet, not an agent or API wallet. Once approved, orders signed by the user's API wallet can carry the builder field.

How do builders get paid?

Builder fees accrue onchain with each fill and are claimed through the same process as referral rewards. The running total appears as builderRewards in the info request {"type":"referral","user":""}.

Do builder codes stack with referral codes?

Not on the same order. Hyperliquid's referrals docs say builder codes override referral codes for that order. A user's referral discount still applies to orders they place without a builder code.

Sources

  1. Hyperliquid Docs — Builder codes
  2. Hyperliquid Docs — Exchange endpoint (order builder field, approveBuilderFee)
  3. Hyperliquid Docs — Info endpoint (maxBuilderFee, approvedBuilders, referral, fills)
  4. Hyperliquid Docs — Account abstraction modes (builders must be in standard mode)
  5. Hyperliquid Docs — Staking referral program proposal (builder codes override referral codes)
  6. Hyperliquid Docs — HIP-4 outcome markets (builder fees on outcome sells)
  7. hyperliquid-python-sdk — examples/basic_builder_fee.py