Hyperliquid: The frontend wars – Blockworks

This is a segment from the 0xResearch newsletter. To read full editions, subscribe.

One of Hyperliquid’s core innovations is builder codes. These codes function as a protocol-level parameter in transaction payloads, allowing interfaces to append a builder address for automated, onchain fee capture. Builders can attach a surcharge of up to 100 basis points (1%) on spot and 10 basis points (0.1%) on perps.

This decoupling of execution from settlement enables frontends to monetize proprietary flow without the technical complexities of maintaining an orderbook or the capital inefficiency of bootstrapping liquidity. As shown below, third-party frontends integrate Hyperliquid perps and add their own variable fee tiers on top, effectively creating a differentiated pricing landscape for the same underlying execution.

As such, builder codes have unlocked a powerful distribution flywheel. Nearly 40% of daily active users now trade through third-party frontends rather than the native UI, a share that briefly crossed 50% in late October. The top three builders alone, Based, Phantom, and pvp.trade, have collectively captured more than $31 million in fees.

From a market structure perspective, this pushes Hyperliquid away from the fully-integrated crypto exchange model and closer to the layered intermediation of traditional equities. In a centralized exchange like Binance, one entity controls the full stack across onboarding, routing, matching and custody.

Hyperliquid’s design mimics the US equity market, where retail brokers (Robinhood, Schwab) own the client relationship and monetize distribution, while routing orders to wholesalers (Citadel Securities, Virtu) that handle execution and settlement. In effect, the stack becomes two-tiered:

• A broker-like distribution layer, where builders compete for order flow and differentiate on product and fee pass-through.
• A central execution venue, where Hyperliquid concentrates liquidity and handles matching and margining.

While new to crypto perps, this decoupling mechanism has already played out on Solana. Trading terminals like Photon and Axiom controlled the user flow by focusing on the consumer layer. Photon grew first by being the fastest Solana memecoin sniper, while Axiom eventually challenged it with a broader product suite and more aggressive points and rebate designs. These terminals effectively functioned as builders: They sat on top of DEXs, bolted on their own fee markups, and maintained accounting manually. Hyperliquid’s builder codes essentially turn that pattern into a native protocol primitive.

However, the Solana example also highlights the risk. Trading terminals captured 77% of Solana’s DEX revenue over the past year, $633 million vs. $188 million for DEXs, a 3.4x multiple that highlights that owning the frontend is often more valuable than owning the backend. Specifically, is the frontend too valuable for Hyperliquid to give away?

The relationship between frontends and backends is rarely purely symbiotic. Frontends like Jupiter aggregate various backends (Meteora, Raydium, Orca) and return the best route given size, fees and slippage constraints. 

Source: Jupiter Frontend Aggregation Example

This forces DEX backends into severe margin compression. With zero moat, they must be the cheapest route to win flow. Since they don’t own the user, backends are also at risk of replacement. We see this when pump.fun replaced Raydium as its liquidity backend with its own in-house AMM, significantly impacting Raydium’s volume share. 

Right now, Hyperliquid does not face this problem. By pioneering builder codes on perps, it is effectively a singular-builder code environment. However, if builders evolve from a UI on top of HL into true routers that can send flow to competing backends, they start to resemble a smart-order router in traditional finance. In this scenario, builders can:

• Optimize all-in cost: Calculate spread/slippage + taker/maker fees + builder surcharge − rebates + expected funding.
• Bargain with venues: Demand higher builder shares or rebates with the threat of routing flow elsewhere.
• Capture the user relationship: While venues are forced to compete purely to be the cheapest, best-execution wholesale liquidity provider.

Similarly, in traditional finance, wholesalers compete with broker-dealers for volume. Robinhood routes to Citadel Securities, Virtu, and Jane Street based on which provides the best execution and payment for order flow.

Source

While rival DEXs like Drift and Ostium have integrated builder codes, none have emerged as genuine competitors to date. However, a significant structural risk remains: If a venue like Lighter were to pair builder rebates with its zero-fee model, it could theoretically allow wallets like Phantom and Rabby to bypass Hyperliquid’s 4.5 bps fee. This would enable frontends to capture the entire fee stack, effectively doubling their revenue per trade compared to the current Hyperliquid model. 

LiquidTrading serves as a leading indicator of this future. The Paradigm-backed terminal, which raised $7.6 million in its seed round, has facilitated $5.6 billion in volume on Hyperliquid. But crucially, it also allows users to trade on Ostium and Lighter via the same interface. If larger builders follow this path and begin actively routing flow based on venue rebates rather than loyalty, Hyperliquid builder frontends could evolve into a commoditized perp aggregator, directly threatening the protocol’s ability to capture value.

Still, there is a fundamental difference. Spot is easy to aggregate because each swap is atomic and the asset is fungible across venues. One transaction equals one fill, and a router can seamlessly split a trade across multiple pools. However, with perps, positions are persistent and venue-specific. A BTC-PERP position on Venue A is not fungible with a BTC-PERP position on Venue B due to differences in index composition, funding rates, liquidation engines and risk limits.

To route perps across venues meaningfully, the market needs one of two difficult solutions:

• User fragmentation: Users must keep collateral on multiple venues, which is capital inefficient and results in poor UX.
• Prime brokerage layers: The router must act like a clearing layer, solving the hard problems of credit extension, cross-margining and liquidation coordination.

While non-fungibility offers a short-term defense, the harsh reality is that frontends are rational economic actors; they will migrate if a competitor offers superior margins. Yet, the data suggests this threat is currently contained. Despite the high user counts on third-party interfaces, the vast majority of volume, over 90%, still originates from Hyperliquid’s native frontend. 

Furthermore, the HYPE token adds a retention layer. Builders can hold HYPE to access fee discounts, allowing them to stack revenue streams: referrals, builder fees, and volume-based discounts. With this, the cost of switching for incrementally better fees may not be worth it for existing frontends. Finally, the flow coming from builders appears to be additive rather than cannibalistic. These are new users entering the ecosystem via wallets and terminals, not users switching interfaces. 

Therefore, while builder codes offer an effective expansion vector, expecting Hyperliquid to maintain total dominance over its distribution layer is unrealistic. As the sector matures, Hyperliquid will face a tougher grind to defend its lead against aggregators and low fee competitors. However, building a performant onchain orderbook remains an immense technical moat, and with frontend margins remaining healthy, the incentives for builders to switch are low. Still, in a rapidly expanding market, this is not a battle to retain volume, but rather a more competitive race for growth where Hyperliquid remains the heavyweight to beat.

Get the news in your inbox. Explore Blockworks newsletters: