How Hyperliquid Builder Codes Share Fees on Routed HyperCore Fills

Hyperliquid builder codes are a per-order attribution field on HyperCore fills an application routes for you. Official collection caps sit at 0.1 percent on perpetual contracts and 1 percent on spot. A fill with no builder attribution pays none of that additional cut. The code decides who gets paid on a fill that already has a venue. Matching stays on the same HyperCore book. HIP-3 listings are a separate product.

Suppose you rest the same HyperCore BTC size two ways. One application attaches an approved builder fee that pays the team that sent the order. The other rest carries no builder address and pays no application. Both orders compete on the same onchain book. The same committed book can produce two invoices. Only the additional line is optional.

What Hyperliquid builder codes are

A builder code is fee-share attribution on a HyperCore fill the application sent. The additional builder fee sits on top of the protocol maker or taker rate. Tagged rests and raw rests still compete on the same price-time book.

Official collection caps sit on that extra line. "Builder fees charged can be at most 0.1% on perps and 1% on spot". Codes are set per order. The user approves a maximum builder fee for each builder and can revoke at any time. The fee is processed entirely onchain as part of the fee logic. "This action must be signed by the user's main wallet, not an agent/API wallet". A builder needs at least 100 USDC in perps account value and must use standard as the account abstraction mode. Collection applies only in the quote or collateral asset. That rule skips the buying side of spot trades and applies to both sides of perpetual trades. Each user can have a maximum of 10 active builder-code approvals at a time. Builders claim through the usual referral-reward claim process. f is the builder fee to charge in tenths of basis points, so a value of 10 means 1 basis point (source: Hyperliquid Docs, builder codes). The optional order field is {"b": address, "f": number}, with b as the builder address. Builder here means a DeFi application team that routes flow, not a consensus block builder.

An independent explainer states the surcharge as an app-level add-on on top of Hyperliquid's own trading fees (source: Hyperliquid Guide, builder fees). Live application revenue and frontend rosters on that kind of page are operator figures.

Protocol fees are a different invoice, and the docs split them on purpose. There are separate fee schedules for perps versus spot (source: Hyperliquid Docs, fees). Tier 0 perpetual taker on that table is 0.045 percent. Suppose you size 10,000 USDC of perpetual notional on a tagged fill. The published 0.1 percent perpetual cap on that size is 10 USDC of builder fee, which is those two official inputs multiplied, not a live quote from any named application. A raw order still owes the protocol taker or maker line and owes 0 extra to a builder.

Who collects the extra line depends on the path.

The generic picture of a hosted book versus an onchain book is still in DEX and CEX trading. The builder-code fact is smaller: the additional line is attribution on a fill that already had a venue. You can prefer a terminal and still refuse the attribution, because a resting order is valid with no builder address.

How builder-fee approval and revoke work

A builder cannot charge you until you sign ApproveBuilderFee from your main wallet, naming that builder and a maximum rate you can later revoke. An agent or API wallet cannot stand in for that signature. A later order that asks above your ceiling fails as a tagged fill.

That signature is account state. It stays until you revoke it or replace the maximum for that same builder. The ten-approval cap is a hard count of active builders, so an eleventh application waits for a free slot. The 100 USDC perps-account floor and the standard account-abstraction mode sit on the builder side. They are a minimum so a throwaway address cannot collect fees.

Independent decoder documentation records the same ceiling. The decoded approveBuilderFee payload stores the maximum fee rate a user authorizes a builder to charge on routed trades (source: Dwellir, ApproveBuilderFee). Read the maximum on the prompt. That number is the most the builder may attach later. You can authorize 0.05 percent even though the protocol cap is 0.1 percent on perpetual contracts. The order's f value still has to sit at or under whichever limit is tighter. f of 10 is 1 basis point, which is 0.01 percent, so f of 100 is the 0.1 percent perpetual cap if your authorization allows it.

The public Python example refuses an agent signer with an exception that only the main wallet has permission to approve a builder fee (source: Hyperliquid Python SDK, basic_builder_fee.py). That check documents the same main-wallet rule. After the authorization the example sends a market open with a builder dict, which is how the optional field actually rides on the order.

Referral plumbing is easy to mix with this attribution parameter, because the programs share a claim flow and nothing else. Using a referral code gives you a 4 percent discount on your fees for your first $25 million in volume (source: Hyperliquid Docs, referrals). That discount reduces protocol fees under the referral program. A builder code is a separate, approved extra that pays the application. Independent disclosure copy draws the same line: a referral code may discount protocol fees, while a builder code adds a separate, user-approved fee that pays the app routing your order (source: HypeBasis, builder codes and fees). Claiming accrued builder fees uses the referral-reward claim flow, which is how coins get withdrawn. Shared claim plumbing still leaves two programs.

Authorization is the on-switch, the per-order tag is the bill, and revoke is how you turn the switch off.

Builder fee caps on perps and spot

Builder fees are capped at 0.1 percent on perpetual contracts and 1 percent on spot, collected only in the quote or collateral asset, and they skip the buying side of spot while applying to both sides of a perpetual. Those three rules travel together. A page that shows only the perpetual cap has stopped one clause early.

On a perpetual, a tagged buy and a tagged sell can both carry the additional line, because both sides collect in the quote. On spot, a tagged purchase skips the builder cut under the current rule, and a tagged sale can still pay it. If you buy spot through an application and later sell through the same application, the sell is the fill that can pay the builder.

Quote-asset collection also means the additional fee comes out of the same quote or collateral the protocol fee uses, which is why a builder code is fee logic on the fill. A tagged BTC perpetual still clears in the quote. A tagged spot sale still clears in the quote or collateral of that pair. The skip is about which side of the pair can carry the field. The book itself still moved.

The 1 percent spot cap is ten times the perpetual cap in percent terms, and it is still a ceiling. Posted rates sit at or under it. An honest application shows the rate it will attach, next to the protocol line, so you can see who collected the additional surcharge. Cap math on 10,000 USDC of notional is 10 USDC at the perpetual ceiling and 100 USDC at the spot ceiling, which is the published percent times that size.

The mechanical skip is perpetual both sides, spot sell side, quote or collateral only, and no more than the published cap.

Builder codes vs HIP-3 listing fees

Builder codes share a fee on routed flow. HIP-3 builder-deployed perps are permissionless listings that inherit HyperCore's book and post a slashable deployer stake. The shared word builder is the mix-up. Authorizing a fee-share application leaves deployer stake untouched. A 500,000 HYPE deployer posting leaves b and f off your next rest.

HIP-3 builder-deployed perps cover the listing requirement, the 183-day floor, and slashing. The remaining job here is the fee split. A HIP-3 deployer can also set an extra fee share on that dex's markets as a listing setting, on a scale the fees page documents separately from the per-order tag. That share is a listing setting. The b/f field is the per-order tag you authorized for an application. You can see a builder-code fee on a validator-operated BTC book with no HIP-3 dex in the path. You can also trade a HIP-3 market through a tagged frontend, which is two different builder bills sharing one word.

A HIP-3 fill still matches on HyperCore, while the extra listing economics live on the deployer, not on your ApproveBuilderFee list. If a UI pastes a custom ticker next to BTC without naming the dex, ask which book you are on before you size it. That question is HIP-3's. The builder-code question is only whether this order carries an application's address.

One is a fee share on routed flow, and the other is a listed perpetual dex with a bond. Authorization of a builder address is separate from reading the listing requirement. A 500,000 HYPE deployer posting is separate from reading the per-order f field.

BloFin HYPE fills vs HyperCore builder codes

A BloFin HYPE fill is exchange matching under BloFin custody. The fill stays on BloFin's matcher. Signing ApproveBuilderFee in a wallet leaves BloFin fills untagged, and closing the BloFin position leaves HyperCore authorizations in place.

The public swap book on August 21, 2026 still lists the JSON instrument ID HYPE-USDT at 75x, listed December 19, 2024 11:30 UTC, copied from the live response (source: BloFin instruments API, SWAP). Reader copy for that perpetual is HYPEUSDT. Autocomplete that shows HYPEUSDT is a search stub, not the market. A separate HYPERUSDT swap at 50x is Hyperlane, a different listing. If the chart header says Hyperlane, stop. The same API response still keys that second listing as HYPER-USDT.

You can hold HYPE exposure on BloFin and still open a HyperCore rest in a wallet, because those are two venues. A BloFin password and a HyperCore ApproveBuilderFee signature are separate account state. Filling HYPEUSDT SWAP leaves b and f off a later wallet rest, and a wallet rest leaves the BloFin position open. Treating a filled CEX swap as a tagged HyperCore holding mixes two venues. A deposit or withdrawal between BloFin and a HyperCore wallet moves custody of coins. Yesterday's CEX matching stays a CEX fill.

How to buy HYPE is the purchase path if you want the token on an exchange first. CEX versus DEX is the generic custody fork. Both paths still leave builder attribution off. Hyperliquid remains a competing venue, and a listing date is a listing date.

Builder pay happens only when a HyperCore order carries the optional field at send time.

Where tagged fills clear on HyperCore

A tagged order is still a HyperCore action: rest, fill, cancel, and liquidation stay on the onchain book, and the builder fee is processed as fee logic on that fill. HyperEVM gas is a different bill. A tagged bid keeps its price-time place.

What Hyperliquid is covers HyperCore and HyperEVM as two environments. Builder-code applications look like frontends because a phone or a terminal sent the order, yet they still settle as book fills. Solidity calls on chain ID 999 are a different action. Book fills leave HYPE-as-gas off the invoice.

How HyperCore works is the environment that holds those books. The trader-facing rest, fill, and same-batch cancel sit in how the Hyperliquid book works.

A generic primer on what an order book is still helps if bids and asks are new, though it will not tell you who the additional line pays. Price-time still decides who is filled at a level once the orders are actually on the book, and paying a builder leaves the timestamp unchanged. If you want to know whether your cancel sorts before a new GTC in the same batch, that is the book's job.

A CEX-looking ladder on Hyperliquid can still be a book application, and a contract that needs HYPE as gas is a different job on the same chain. If the fill is a HyperCore fill, the builder code is only an optional fee field on that fill.

Checks before you approve a builder fee

Weigh the maximum on the prompt, whether this order will actually carry a builder field, and whether the application is worth that additional line, because a raw order on the same book is still available. You need a second invoice you can actually read.

Three checks before you sign:

1. What maximum you authorized, in percent, for this exact builder address.
2. Whether this click will send a tagged order, or you are on a path that omits b and f.
3. Whether you still know how to rest the same size on a raw order if you revoke.

If any of those three is fuzzy, wait to sign. You can prefer a chart overlay and still refuse the fee, and you can pay a tagged application for a week and then revoke. Authorizations persist when you switch screens, so a later session in the same wallet can still be billed until you turn the switch off. Ten active approvals is a budget of slots.

Skip memorizing the f conversion table. The useful trio is the cap, the quote-asset rule, and the fact that a BloFin fill is a different instrument. If the prompt is an SDK screen or a become-a-builder pitch, that is a different audience than a fee-share explainer.

Builder codes let an application take a user-approved extra on the HyperCore fills it sends. The two paths share a book and split a payee. HIP-3 is a listing requirement, and BloFin is a CEX fill. Sign the maximum you mean, or send the rest with no builder field at all.

Frequently asked questions

If I revoke a builder today, do fees it already earned on my fills disappear?

No. Revoke stops that builder from attaching a fee to future orders. Coins already accrued on tagged fills that happened while the authorization was live stay accrued. Those accrued builder fees are claimed through the usual referral-reward claim process the documentation names for builder codes. If you want the billing off, you still have to revoke. If you want to know whether yesterday's tagged fill already paid the application, revoke leaves that fill in place.

Can I read the approved maximum for a builder without asking that app?

Yes. Official builder documentation exposes an info request that returns the approved maximum builder fee for a given user and builder pair, so the ceiling is public account state. You can check the same user-builder pair that signed ApproveBuilderFee without trusting the prompt you just clicked. The read leaves approvals in place. If the returned maximum does not match what you thought you signed, you still have to revoke or replace the maximum from the main wallet.

After I sign ApproveBuilderFee from my main wallet, can later API-wallet orders still carry the builder field?

Yes. The approval is a main-wallet action, and later order actions sent on your behalf may include the optional builder field once that authorization is complete. An API or agent wallet still cannot sign ApproveBuilderFee, but it can send a tagged order after you have already authorized that builder from the main wallet. The tag is still optional per order, so an API order with no builder field pays no application. Without a main-wallet signature, a tagged API order fails as a collection path.

If I buy spot on a tagged application and later sell the same coins on a raw order, does the application still collect?

Not on that close, because a raw order has no builder field, so the sell pays no application even if the purchase went through a tagged application. The tagged spot buy also skipped collection under the current quote-asset rule, which means mixed routing can leave both legs without a builder line. A later tagged sell is the spot fill that can pay the application. A zero on the way in covers the purchase only.

After a builder claims through the referral-reward flow, do those coins appear as extra margin on BloFin HYPEUSDT?

No. Claimed referral rewards are reflected in HyperCore spot balance, which is a withdrawal of accrued quote into spot on that account. That credit sits off your perps margin and off BloFin. The builder needed 100 USDC in perps account value to collect in the first place, and that floor sits on the builder's account. Closing or adding to HYPEUSDT leaves those claimed coins in HyperCore spot.

Researched and written by the BloFin Academy editorial team with AI-assisted drafting. Updated August 2026. Primary sources include the Hyperliquid documentation on builder codes, referrals, and fees, plus HypeBasis, Hyperliquid Guide, and Dwellir explainers, the public Python SDK example, and BloFin's public instrument APIs. Protocol and listing facts independently verified against cited sources current as of August 2026.

This article is educational and general in nature, not financial or investment advice. Cryptocurrencies like HYPE carry real risks, including price volatility, venue and custody risk, and the chance of losing funds. Nothing here is a recommendation to buy, sell, hold, or trade HYPE, to use Hyperliquid, to approve a builder, or to use BloFin. Do your own research, and consider speaking with a licensed professional before making financial decisions. BloFin does not provide investment advice.