Every Hyperliquid Trade Pays a Frontend: Builder Codes Explained

When you trade on Hyperliquid through a third-party wallet or trading terminal, the app you are using earns a cut. Every single fill. Automatically, on-chain, in USDC. That is a builder code at work.

The mechanic is deceptively simple: any application that routes orders through Hyperliquid can attach a small fee to each trade, and the protocol pays that fee directly to the builder's address. No token launch. No subscription model. No partnership negotiation. Just fees flowing from fills to the app that facilitated them. In aggregate, Hyperliquid's builder ecosystem has generated over $90 million in revenue across 1,411 registered builders, making it one of the most quietly productive monetization systems in DeFi.

This guide breaks down exactly how builder codes work, who profits from them, and what it takes to integrate one into your own application.

The Mechanics: How Builder Codes Actually Work

Builder codes are an on-chain fee attribution mechanism baked into Hyperliquid's matching engine. The word "builder" here refers to DeFi builders who create applications on Hyperliquid, and the "code" is the fee parameter attached to each order they route.

The process has three steps:

1. User approval. Before a builder can earn fees from a trader, that trader must sign an ApproveBuilderFee action from their main wallet (agent and API wallets cannot do this). The approval sets a maximum fee the builder is allowed to charge. Users can revoke this permission at any time, and each wallet can hold a maximum of 10 active builder-code approvals.
2. Fee attachment. The builder includes an optional parameter on each order: {"b": builder_address, "f": fee_in_tenths_of_bps}. The fee is set per-order for maximum flexibility, meaning a builder can charge different rates on different trades if they choose to.
3. On-chain settlement. When the trade fills, Hyperliquid's fee logic deducts the builder fee from the fill and credits it to the builder's account in USDC. The fee is additional to the protocol's standard maker/taker fees.

Fee Caps and the f Parameter

The fee parameter f is measured in tenths of a basis point. A value of f: 10 equals 1 basis point (0.01%), while f: 100 equals 10 basis points (0.10%), which is the maximum for perpetual futures. Spot markets allow up to 100 basis points (1%).

On a $10,000 perpetual futures fill at the maximum 10 bps, the builder earns $10. At a more typical 5 bps, that same fill generates $5. Builder codes only apply to fees collected in the quote or collateral asset (USDC), which means they do not apply to the buying side of spot markets.

Who Earns the Most: The Builder Leaderboard

Figures as of July 2026, from HyperTracker's builder leaderboard.

The top of the leaderboard reveals a clear pattern: the highest-earning builders are wallets and trading terminals that sit in the user's daily workflow. Phantom leads with $23.6 million in all-time builder fee revenue, generated from 153,128 users and $44.8 billion in routed volume. Crypto Briefing reported that Phantom earned $20 million in builder code fees since launching its Hyperliquid integration in July 2025, processing $37 billion in trading volume. Our data shows the figure has since grown past $23 million.

Based ranks second at $15.2 million in revenue on $44.9 billion in volume, a volume figure that actually exceeds Phantom's despite lower revenue, because it routes through fewer but higher-volume traders (42,967 users compared to Phantom's 153,128). MetaMask and PVP each sit near the $8 million mark, with MetaMask having joined more recently (August 2025) and already pulling in 52,534 users.

Further down the rankings, Insilico has earned $3.7 million from just 3,339 users, an outlier that reflects a small base of extremely active algorithmic traders routing massive volume ($36.3 billion) through its infrastructure. That is a revenue-per-user figure that dwarfs every other builder in the top 15.

Revenue Per User: The Hidden Metric

Raw revenue totals only tell part of the story. The more interesting metric for builders evaluating this opportunity is revenue per user, because it reveals whether a builder's economics depend on user count or user intensity.

| Builder | Revenue | Users | Rev/User | Vol/User | | --- | --- | --- | --- | --- | | Insilico | $3.7M | 3,339 | $1,113 | $10.9M | | Mass | $1.5M | 1,054 | $1,395 | $2.4M | | TreadFi | $2.2M | 4,835 | $463 | $2.3M | | PVP | $8.0M | 28,223 | $284 | $607K | | Phantom | $23.6M | 153,128 | $154 | $293K |

Insilico earns over $1,100 per user, while Phantom earns $154. Both are successful, but they represent fundamentally different strategies. Phantom wins on distribution (bring every Solana wallet user to Hyperliquid perps with a single tap). Insilico wins on intensity (serve a small cohort of power traders who generate enormous volume). The builder code system rewards both approaches equally.

Builder Codes vs Referral Codes

Hyperliquid has two separate fee-sharing mechanisms, and confusing them is one of the most common mistakes new builders make.

Builder codes are per-order, app-specific, and additive. They add a fee on top of the protocol's standard trading fees. They only apply when the user trades through the builder's app, and they require explicit user consent via a signed approval.

Referral codes are per-user, permanent, and subtractive. They reduce the protocol's fees and share a portion with the referrer. They apply to all of a user's trades regardless of which frontend they use, and they expire after the referred user hits $1 billion in cumulative volume.

When both are present on the same order, the builder code overrides the referral code for that specific fill. This means a builder's revenue is never diluted by referral codes on trades routed through their app.

Integrating a Builder Code: The Technical Steps

Getting started requires a Hyperliquid perps account with at least 100 USDC and an application that submits orders through the Hyperliquid API. There is no application form and no approval committee.

Step 1: Register Your Builder Address

Your builder address is simply the wallet that will collect fees. Ensure it holds at least 100 USDC in perps account value and uses the standard account abstraction mode.

Step 2: Prompt Users to Approve Your Fee

Before you can earn, each user needs to sign an ApproveBuilderFee action. This must come from the user's main wallet. The action sets the maximum fee you are allowed to charge that user. Best practice: surface the approval clearly in your UI with the builder address, maximum fee, an example cost, a note that the fee is additional to protocol fees, and instructions for revoking.

Step 3: Attach the Fee to Orders

Add the builder parameter to each order you submit:

{
  "b": "0xYourBuilderAddress",
  "f": 50
}

In this example, f: 50 charges 5 basis points (0.05%) per fill. You can vary this per order, which means you could charge less on high-volume assets to stay competitive, or charge more on less liquid pairs where your analytics or routing add clear value.

Step 4: Claim Revenue

Builder fees accumulate in your builder address and can be claimed through the referral reward system. All builder code activity is logged on-chain and published daily in LZ4-compressed format for full transparency.

What Builders Are Actually Building

The builder code system has spawned a diverse ecosystem. Wallets like Phantom and MetaMask integrate Hyperliquid perps as a native feature, so their users can trade without ever visiting app.hyperliquid.xyz. Trading terminals like PVP and Insilico build specialized interfaces for social trading, copy trading, and algorithmic execution. Aggregators like Axiom ($2.4 million in revenue, 34,093 users) and Infinex ($2.8 million, 9,283 users) route cross-chain trades through Hyperliquid's liquidity.

The common thread is that none of these builders launched a token to monetize. They built a product, attached a builder code, and started earning on day one. That stands in sharp contrast to the traditional DeFi playbook of bootstrapping a protocol, launching a governance token, and hoping the token accrues value.

Tracking Builder Performance with Our Data

Understanding builder code economics at scale requires more than the raw on-chain logs. Our builder analytics endpoint surfaces the full leaderboard: revenue, volume, user count, and join date for every registered builder on Hyperliquid.

Builders can use this data to benchmark their own performance against the ecosystem. Funds can use it to evaluate which frontends are gaining or losing share. And the raw numbers reveal dynamics that surface-level metrics miss, like how Insilico's 3,339 users generate more volume than MetaMask's 52,534, or how Based routes nearly the same volume as Phantom with a third of the users.

Our cohort analytics add another layer. By cross-referencing builder code data with our 16 behavioral cohorts (8 by account size, 8 by all-time PnL), you can see which types of traders are concentrated on which frontends. A builder that attracts mostly Smart Money cohort users will have very different economics than one that serves Exit Liquidity traders, even at the same volume.

Explore Builder Analytics on HyperTracker

Track builder revenue, volume, and user growth across the full Hyperliquid ecosystem. Free tier available.

View the Builder Leaderboard

The Bigger Picture

Builder codes solve a problem that plagued DeFi frontends for years: how does an application that routes trades to a decentralized protocol actually make money? Before builder codes, the answer was usually "launch a token" or "charge a subscription." Both introduce friction. Tokens require governance overhead and regulatory risk. Subscriptions filter out casual users before they ever try the product.

Hyperliquid's approach aligns incentives more directly. Builders earn proportionally to the value they create, measured in trading volume they route. Users consent to the fee explicitly, see exactly what they are paying, and can revoke at any time. The protocol benefits because each builder is effectively a distribution channel, bringing new traders into the Hyperliquid ecosystem who might never have visited the native frontend.

With $90.7 million in cumulative builder revenue and 1,411 registered builders, the system has already proven the model at meaningful scale. The next frontier is not whether builder codes work. It is what gets built on top of them.