Hyperliquid Builder Codes: How Developers Are Earning Millions on the Fastest DEX

Phantom wallet earns $100,000 per day from Hyperliquid trades executed through its interface. PVP.trade has generated $7.2 million in lifetime revenue. Neither launched a token. Neither charges subscription fees.

Builder codes make this possible. They let application developers earn up to 0.1% on every trade routed through their interface. No token economics, no complex revenue sharing agreements, no barriers for users. Over $40 million in builder code revenue has flowed to developers since launch, with 40% of Hyperliquid's daily active users now trading through third-party frontends.

What Are Hyperliquid Builder Codes?

Builder codes are an on-chain revenue attribution mechanism that lets application developers earn fees on trades executed through their interfaces. When a user trades through your application, you attach a builder code to the order and earn a percentage of the trade value. This works for wallets, trading bots, social trading platforms, and mobile apps.

The key distinction: "builder" in this context refers to DeFi application developers, not consensus-layer block builders. You're building applications that route user trades through Hyperliquid's order book, and builder codes let you capture value from that trading activity.

How Builder Codes Work

The technical flow involves five steps:

1. User authorization: Users approve a maximum builder fee via the ApproveBuilderFee action from their main wallet, setting an upper bound on what any builder can charge them.

2. Order attribution: When placing orders on behalf of users, builders include a parameter specifying their address and fee rate: {"b": "builder_address", "f": fee_value}.

3. On-chain processing: Builder codes are processed on-chain with one-block finality, matching regular Hyperliquid trade speed.

4. Fee collection: Fees accumulate in the builder's account and can be claimed through Hyperliquid's referral reward system.

5. Trade tracking: All trades with builder codes are logged and published daily in LZ4 compressed format for transparency and analytics.

Fee Limits and Requirements

Builder code fees have protocol-enforced caps:

Becoming a builder requires a minimum of 100 USDC in your Hyperliquid perpetuals account. This low barrier means anyone building on Hyperliquid can start earning from day one.

The fee parameter (f) is specified in tenths of basis points. A value of f: 10 equals 1 basis point (0.01%), while f: 100 equals 10 basis points (0.1%), the maximum for perpetuals.

Revenue Potential: Real Numbers from Real Builders

Top Performing Builders

Market Dynamics

• $40M+ total builder code revenue generated across the ecosystem
• ~40% of Hyperliquid daily active users trade via third-party frontends
• 187 active builders currently earning fees
• One-third of Hyperliquid's total trading flow comes from third-party builders

Applications that previously struggled to monetize, particularly wallets and portfolio trackers, now have a direct path to sustainable revenue.

Revenue Calculation Example

Consider a trading interface with $10M daily volume:

Daily volume: $10,000,000
Builder fee: 0.05% (5 basis points)
Daily revenue: $10,000,000 x 0.0005 = $5,000

Monthly revenue: ~$150,000
Annual revenue: ~$1,800,000

Even at conservative volumes and fee rates, builder codes generate meaningful revenue. Applications with viral mechanics (copy trading, social features, gamification) can achieve multiples of these figures.

Use Cases: Where Builder Codes Create Value

1. Wallet Integrations

Phantom integrated Hyperliquid trading directly into its wallet interface. Users trade without leaving Phantom, and the wallet earns builder fees on every transaction. This model generates $100K+ daily, demonstrating that wallet-native trading is a significant opportunity.

2. Trading Bots and Automation

Automated trading systems attach builder codes to every order they execute, from simple rebalancing bots to sophisticated copy trading platforms. The Hyperliquid copy trading bot guide demonstrates how to build these systems with proper risk controls.

3. Social and Copy Trading Platforms

Platforms that let users follow and automatically copy successful traders charge builder fees on mirrored trades. PVP.trade's $7.2M in lifetime revenue demonstrates the potential here. The social trading model creates viral growth: successful traders attract followers, generating more volume and more builder code revenue.

4. Regional Frontends and Mobile Apps

Teams building localized trading interfaces for specific languages, regulatory environments, or mobile-first experiences can monetize through builder codes. This enables building Hyperliquid frontends for underserved markets without negotiating revenue sharing deals.

5. Consumer Trading Apps

Robinhood-style interfaces that abstract away DeFi complexity can target mainstream users while earning builder fees. The 1% cap on spot trades makes this particularly attractive for consumer-focused applications where users are less fee-sensitive.

Technical Implementation

Builder code integration requires adding parameters to Hyperliquid's order placement API. The implementation involves user fee approval and order attribution.

Prerequisites

1. Fund a Hyperliquid account with at least 100 USDC in the perpetuals subaccount
2. Generate API credentials for your builder address
3. Ensure users have approved your builder fee via ApproveBuilderFee

Order Placement with Builder Code

from hyperliquid.api import API
from hyperliquid.utils import sign_l1_action
import json

# Initialize with your credentials
api = API(base_url="https://api.hyperliquid.xyz")

# Builder code parameters
builder_address = "0xYOUR_BUILDER_ADDRESS"
builder_fee = 50  # 5 basis points (0.05%) in tenths of bps

# Order with builder code attribution
order_params = {
    "coin": "ETH",
    "is_buy": True,
    "sz": 0.1,  # Size in base asset
    "limit_px": 2500.0,
    "order_type": {"limit": {"tif": "Gtc"}},
    "reduce_only": False,
    # Builder code attribution
    "builder": {
        "b": builder_address,
        "f": builder_fee
    }
}

# Sign and submit the order
signed_action = sign_l1_action(
    wallet=your_wallet,
    action={"type": "order", "orders": [order_params]},
    timestamp=get_timestamp()
)

response = api.post("/exchange", signed_action)

User Fee Approval Flow

Users must approve your builder fee before you can charge it. This is a one-time action per builder that sets the maximum fee rate you can charge that user:

# User approves builder fee (called from user's wallet)
approval_action = {
    "type": "approveBuilderFee",
    "builder": "0xYOUR_BUILDER_ADDRESS",
    "maxFeeRate": 100  # Max 10 bps (0.1%) in tenths of bps
}

# User signs and submits this approval
signed_approval = sign_l1_action(
    wallet=user_wallet,
    action=approval_action,
    timestamp=get_timestamp()
)

response = api.post("/exchange", signed_approval)

Tracking Builder Revenue

# Check builder rewards
rewards_response = api.post("/info", {
    "type": "referral",
    "user": builder_address
})

accumulated_fees = rewards_response.get("unclaimedRewards", 0)
print(f"Unclaimed builder fees: ${accumulated_fees}")

Error Handling

Common issues when implementing builder codes:

def place_order_with_builder(order_params, builder_address, fee_bps):
    """Place order with builder code and proper error handling."""

    # Validate fee is within limits
    if order_params["coin"] in PERP_MARKETS:
        max_fee = 100  # 10 bps max for perps
    else:
        max_fee = 1000  # 100 bps max for spot

    if fee_bps > max_fee:
        raise ValueError(f"Fee {fee_bps} exceeds max {max_fee} for market type")

    order_params["builder"] = {
        "b": builder_address,
        "f": fee_bps
    }

    try:
        response = submit_order(order_params)

        if response.get("status") == "err":
            error = response.get("response", {})

            # Handle common errors
            if "builder fee not approved" in str(error).lower():
                raise BuilderFeeNotApproved(
                    "User has not approved builder fee. "
                    "Prompt user to call ApproveBuilderFee action."
                )
            elif "insufficient builder balance" in str(error).lower():
                raise InsufficientBuilderBalance(
                    "Builder account needs minimum 100 USDC in perps."
                )
            else:
                raise OrderError(f"Order failed: {error}")

        return response

    except Exception as e:
        logger.error(f"Builder order failed: {e}")
        raise

Infrastructure Requirements for Builder Applications

Production builder applications require infrastructure for real-time market data, fast order execution, and high availability. The difference between capturing revenue and missing trades often comes down to milliseconds.

The Public Endpoint Problem

Hyperliquid's public endpoints limit you to 100 requests per minute, far too restrictive for production trading applications. Public WebSocket feeds provide only ~20 levels of order book depth, while production market making and arbitrage strategies need 100+ levels to operate effectively.

For applications processing thousands of trades daily, these limitations translate directly into lost revenue. Missed trades due to rate limiting or stale market data mean builder fees you don't collect.

What Production Builder Applications Need

Infrastructure Options

For production builder applications, three infrastructure tiers exist:

Managed RPC endpoints provide higher rate limits and better latency than public infrastructure. This is sufficient for many trading bots and moderate-volume applications.

Dedicated nodes offer unlimited capacity and full protocol access. For high-frequency applications or those requiring gRPC streaming, dedicated infrastructure is essential. The Hyperliquid RPC providers comparison breaks down the options.

Co-located execution environments place your trading logic in the same data center as your node infrastructure. For latency-sensitive strategies like liquidation bots or arbitrage, this proximity can mean the difference between profitable and unprofitable trades.

Dwellir provides managed Hyperliquid infrastructure including HyperEVM RPC, orderbook WebSocket feeds, and Hypercore gRPC streaming. The gRPC endpoint delivers every fill on Hyperliquid with sub-second latency, enabling real-time trade attribution and copy trading functionality. See the Hyperliquid documentation for endpoint details.

For teams building copy trading platforms or social trading applications, the real-time liquidation tracker guide demonstrates gRPC streaming patterns that apply directly to builder code implementations.

HIP-3 and the Future of Builder Economics

Builder codes exist within Hyperliquid's broader economic model, which includes HIP-3, the protocol's mechanism for distributing fees to builders and other ecosystem participants.

How HIP-3 Complements Builder Codes

HIP-3 creates additional incentives beyond direct builder fees:

• Volume-based rewards: Builders generating significant volume may qualify for additional HIP-3 distributions
• Ecosystem alignment: The fee structure encourages builders to grow total Hyperliquid volume, not just extract from existing users
• Sustainable economics: Combined with builder codes, HIP-3 creates a flywheel where successful applications drive platform growth

ERC-8021: Builder Codes Coming to Ethereum

The success of Hyperliquid's builder code model has inspired ERC-8021, a proposal to bring similar functionality to Ethereum L1 and L2s. If adopted, applications built on Hyperliquid today could expand to Ethereum-based DEXs using the same monetization model.

Competition and Market Dynamics

The builder code model faces competition. Protocols like Paradex and Lighter have launched with zero-fee trading models, attempting to attract volume away from fee-generating platforms. However, Hyperliquid's liquidity depth and execution quality continue to attract builders despite fees.

For builders, this competitive dynamic means:

• Fee sensitivity matters: Applications charging the maximum 0.1% may lose users to lower-fee alternatives
• Value-add is essential: Successful builder applications justify fees through superior UX, analytics, or automation
• Liquidity wins: Hyperliquid's deep order books and fast execution remain compelling for traders

Conclusion

Hyperliquid builder codes represent a fundamental shift in how DeFi applications generate revenue. Instead of token launches, subscription fees, or complex revenue sharing agreements, developers earn directly from trading volume, aligned with user activity and platform growth.

The opportunity is substantial: $40M+ in total builder revenue, individual applications earning millions, and 40% of Hyperliquid users already trading through third-party interfaces. For developers building trading applications, wallets, or automation tools, builder codes offer a clear path to sustainable revenue.

The technical implementation is straightforward with a few additional parameters on order placement. The harder challenges are building applications that users want to trade through and scaling infrastructure to handle production volumes reliably.

Ready to build on Hyperliquid? For gRPC streaming access and dedicated infrastructure, contact the Dwellir team. For HyperEVM RPC access, sign up at the Dwellir dashboard. Explore the Hyperliquid documentation for implementation guides and API references.

This guide is for educational and informational purposes only. Building financial applications involves regulatory considerations that vary by jurisdiction. Always consult appropriate legal and compliance advisors before launching trading applications.