What Are Builder Codes?
How Hyperliquid frontends and applications can charge per-order fees without taking custody of user funds.
Builder codes let a Hyperliquid application charge an additional fee on eligible orders that it routes. The user keeps custody of funds and approves how much that builder is allowed to charge.
This gives trading interfaces, wallets, bots, and other execution products a native revenue path without forcing them to become custodians or settle trades outside HyperCore.
Approval comes before charging
A builder cannot simply attach any fee it wants to a user's order. The user must first authorize the builder address and a maximum fee under the protocol's approval mechanism.
The approval is tied to the builder identity. The application can then attach a fee up to the user's approved maximum on eligible orders.
This separates permission from individual order submission. A user can approve once and later trade repeatedly through the application, subject to the active approval.
The fee is attached to an order
Once approval exists, an order can include the builder address and fee value. Hyperliquid handles the fee as part of execution rather than asking the application to custody trading funds and settle revenue separately.
That matters operationally. The trader's assets remain in the Hyperliquid account, the trade executes on HyperCore, and the monetization path is explicit in the order data.
The exact fee caps and eligible market behavior are protocol parameters. Builders should use the current documentation rather than hard coding values from an article into production systems.
Builder codes change frontend business models
A trading frontend can offer execution, automation, analytics, wallet integration, or strategy tooling and charge for that service through the trade itself.
The product does not need to recreate an exchange to capture revenue. It can remain an application layer around HyperCore.
This is especially relevant for specialized interfaces. A terminal aimed at professional traders, a wallet with embedded trading, or an autonomous strategy product can each charge according to the value it provides while using the same underlying market infrastructure.
Users should evaluate the all in trading cost
A builder fee sits on top of ordinary trading costs. A user should therefore consider maker or taker fees, builder fees, any HIP 3 deployer economics, and execution quality together.
A cheaper interface can still deliver worse total economics if it produces more slippage. A higher builder fee can be rational if the application materially improves routing, automation, or risk controls.
Hyperliquid Fees, Makers, and Takers covers the protocol fee layer separately.
Builder codes are not block builder infrastructure
The word builder can be confusing for users coming from Ethereum market structure. In this context, a builder is an application or product developer that routes user orders, not a consensus block builder.
The distinction matters because builder codes belong to the trading and application revenue model, not HyperBFT block production.
Operational controls for builders
A production application should expose the builder fee clearly, ensure the requested fee never exceeds the user's approval, and handle revoked or missing approvals without creating failed trading flows.
Teams should also monitor whether fee settings differ by product, market, or user segment and make sure the displayed cost matches the actual order payload.
Continue reading
Read Subaccounts and API Wallets for delegated trading authority and Building With the Hyperliquid API for the broader application architecture around signed actions.