When a Builder Code Pays for Itself (and When It Doesn't)

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

Hyperliquid's builder code program has paid out over $90 million to 1,411 builders since launch. Phantom alone has pulled in $23.6 million. Headlines like these make integration feel like an obvious decision for any wallet or trading app with even a small user base.

But look past the top five, and the picture changes. The average builder earns roughly $64,000 in lifetime revenue. The median is almost certainly lower, because a handful of massive integrators pull that average up dramatically. For a wallet team weighing whether to invest engineering time in an integration, the real question isn't "how much does Phantom make?" It's "how much will we make, given our users, our volume, and our fee tolerance?"

This article walks through the decision framework: the three variables that determine builder code profitability, the breakeven math, and the scenarios where integration makes sense versus where it doesn't.

Three Variables That Determine Everything

Builder code revenue boils down to a simple formula:

Monthly Revenue = Daily Volume Through Your App x Fee Rate x 30

Three inputs. Each one matters, and they interact with each other in ways that catch teams off guard. The fee rate you choose affects whether power users stick around, which in turn affects volume, which determines whether the whole thing was worth building.

1. Volume: The Variable You Can't Fake

Volume through your app depends on how many users trade via your interface and how actively they trade. Phantom routes over $44.8 billion in all-time perp volume because 153,128 users trade through it, and many of those are high-frequency perp traders who chose Phantom for convenience. Insilico, by contrast, has only 3,339 users but still generated $36.3 billion in volume because its users are institutional-grade algo operators who generate massive fills per account.

The takeaway: raw user count is a weak predictor. What matters is trading volume per user, and that's a function of who your users are and what your product encourages them to do. A wallet with 100,000 casual spot swappers will generate less perp volume than a terminal with 2,000 active futures traders.

2. Fee Rate: The Knob You Control

Hyperliquid lets builders charge up to 10 basis points (0.10%) on perps and 100 basis points (1.00%) on spot. You keep 100% of what you charge. The protocol takes its own fee separately.

Where you set your fee creates a tradeoff. MetaMask charges close to the maximum at roughly 8.9 basis points (calculated from $8.1 million in revenue on $9 billion in volume). That aggressive fee works because MetaMask's 52,534 users are primarily convenience-motivated: they want to trade perps without leaving MetaMask, and they're willing to pay a few extra basis points for that. Insilico, on the other hand, charges roughly 1 basis point. Its users are quant teams who would notice a 10 bps surcharge instantly and route around it.

The lesson from the leaderboard is that there's no universally right fee. Your rate depends on your users' fee sensitivity, which tracks closely with their sophistication and available alternatives.

3. User Economics: Revenue Per User as a Sanity Check

Revenue per user is the metric that cuts through the noise. It tells you how much each user is actually worth over their lifetime with your product, and it reveals how different builder strategies play out in practice.

Mass earns over $1,395 per user with just 1,054 accounts. Phantom earns $154 per user across 153,128 accounts. Both are successful, but they represent completely different business models. Mass serves a small group of heavy traders. Phantom serves a large group of moderate traders. If your product looks more like Mass than Phantom, you need fewer users to make builder codes profitable, but you also need those users to trade aggressively.

The Breakeven Calculation

Integration isn't free. A Hyperliquid builder code integration typically costs a few dev-weeks of engineering time for a team that already has a wallet or trading interface. The builder address itself requires only 100 USDC in its perps account, so the capital requirement is negligible. The real cost is engineering time and ongoing maintenance.

Here's a scenario matrix showing monthly revenue at different volume and fee combinations:

Reading this table: if your app routes $2 million per day in perp volume at 5 basis points, you're looking at roughly $30,000 per month. At $10 million per day and the same fee, that jumps to $150,000. These are illustrative calculations based on the builder code formula, where revenue equals daily volume multiplied by the fee rate (expressed as a decimal) over 30 days.

The numbers above are based on the formula alone. They don't account for volume fluctuations, user churn, or the reality that crypto trading volume is cyclical and can swing by multiples between bull and bear markets.

When Integration Makes Sense

Based on the leaderboard data, builder codes tend to pay off in a few clear scenarios:

You already have users who trade perps

This is the strongest case. If your wallet or app already handles Hyperliquid trades and you're routing that volume without a builder code, you're leaving money on the table. Phantom's integration works because millions of people already used Phantom. Adding perps with a builder code was incremental engineering on top of an existing distribution advantage.

Your users are fee-insensitive

Convenience-oriented users, the kind who trade through a wallet's built-in swap interface rather than navigating to a dedicated exchange, tend to tolerate small fees. If your product attracts this type of user, you can set a higher fee rate (closer to the 10 bps cap) without worrying about volume loss. MetaMask's effective rate near 9 bps works precisely because its users prioritize convenience over fee optimization.

You serve a niche with high volume per user

Small user bases can still generate meaningful revenue if each user trades heavily. Insilico's 3,339 users generated $3.7 million in builder revenue because the average user traded over $10.8 million in volume across their lifetime. If you're building tooling for quant teams, fund managers, or professional market makers, you don't need tens of thousands of users. You need a few hundred who trade aggressively.

When It Probably Doesn't

The leaderboard also reveals patterns where builder codes underdeliver.

Your users are primarily spot traders

Hyperliquid's perp volume dwarfs its spot volume. Builder codes work on both, but the revenue math is dramatically different. Spot users tend to trade smaller sizes and less frequently. Unless you're routing serious spot flow (and charging closer to the 100 bps spot cap), the revenue from casual spot swappers will likely be negligible.

Your user base is fee-sensitive and has alternatives

If you're building a trading terminal that competes with other terminals, your users are the type to comparison-shop fees. Charging 5 bps when a competitor charges 1 bps creates a real retention risk, especially among power users who generate the bulk of your volume. In this scenario, you're forced to the lower end of the fee range, and you need massive volume to make the math work.

You don't already have Hyperliquid users

Builder codes don't generate demand. They monetize existing demand. If your wallet's users aren't already trading on Hyperliquid (or aren't interested in perps), integrating a builder code won't change their behavior. The integration cost might be moderate, but the revenue projection should assume zero organic adoption unless you have a clear plan to drive users to Hyperliquid through your interface.

How the Top Builders Set Their Fees

Looking at the top 10 by revenue, fee strategies cluster into two camps:

| Strategy | Fee Range | User Type | Examples | | --- | --- | --- | --- | | High-fee, convenience-first | 5-10 bps | Retail, wallet-native | Phantom, MetaMask, Rabby | | Low-fee, volume-first | 1-3 bps | Algorithmic, institutional | Insilico, Axiom, Based |

Neither is inherently better. Phantom and Based both rank in the top three by total revenue, but they got there through opposite strategies. Phantom charged higher fees to a massive user base. Based charged lower fees on similarly massive volume. The right strategy depends entirely on who your users are and what alternative they'd use if you charged too much.

One pattern worth noting: the top two builders by revenue per user (Mass and Insilico) both serve small, concentrated user bases of heavy traders. If your product naturally attracts this profile, you might not need Phantom's scale to make builder codes profitable.

Monitoring Builder Code Performance

Once you've integrated, you need visibility into how your builder code is performing. The critical metrics are daily volume routed through your code, effective fee rate, revenue per user, and user retention (are the same wallets trading consistently, or is volume driven by one-time users?).

Our builder analytics API tracks all of this programmatically. The /builders/list endpoint returns volume, revenue, and user counts for any builder code, broken down by timeframe (daily, weekly, monthly, all-time). You can monitor your own code's performance and benchmark against the broader ecosystem without manual calculation.

Tracking what matters: HyperTracker's builder analytics endpoint gives you revenue, volume, and user counts for any builder code. Query /builders/list to benchmark your performance against the broader ecosystem and spot trends before they hit your bottom line.

The Decision Framework

Before committing engineering resources, run through this checklist:

1. Do your users already trade on Hyperliquid? If yes, you're monetizing existing behavior. If no, you're betting on adoption.
2. How much daily volume can you realistically route? Use your current user metrics to estimate. If you can't project at least $1 million per day in perp volume, the revenue may not justify the engineering cost.
3. What fee rate will your users tolerate? Survey your user base's fee sensitivity. Wallet users tend to tolerate higher fees. Trading terminal users tend to leave.
4. What's your integration cost? A few dev-weeks for a team with existing Hyperliquid infrastructure. Longer if you're building wallet signing flows, agent keys, and deposit orchestration from scratch.
5. Can you sustain the volume through market cycles? Bull market volume can be multiples of bear market volume. Build your projection on a conservative base, because your integration needs to survive a downturn.

If the answers suggest you can route $2 million or more per day at a fee rate your users will accept, the integration almost certainly pays for itself within the first quarter. Below that threshold, the decision gets harder and depends on how much you value optionality: if volume grows, the builder code is already in place to capture it.

Track Builder Code Revenue in Real Time

HyperTracker's builder analytics API lets you monitor volume, revenue, and user counts for any builder code on Hyperliquid. Query the leaderboard, benchmark your performance, and spot trends before they show up in your spreadsheet.

Explore the API

The builder codes that generate headlines are the ones backed by massive distribution. Phantom had 153,128 users when it integrated. MetaMask brought 52,534. But distribution isn't everything. Mass proved that 1,054 users can generate $1.47 million if they're the right 1,054. The question was never "should wallets integrate builder codes?" It was always "does your wallet have the users, the volume, and the fee tolerance to make it work?" Now you have the numbers to answer it.