Hyperliquid Builder Codes and API Rate Limits: What You Need to Know

Hyperliquid's API is purpose-built for speed, but that speed comes with rules. If you're running a market-making operation or a directional bot on the exchange, you need to understand two things before you go live: how builder codes work and exactly where the rate-limit walls sit. Getting either wrong costs you money — either in missed rebates or in a temporary ban that wipes out your fill rate during a volatile session.

What Builder Codes Actually Are

A builder code is a numeric identifier you attach to every order you submit via the API. Hyperliquid uses it to attribute trading volume to a specific builder — the entity that built the interface or infrastructure through which the trade was routed. The exchange then splits part of the taker fee with that builder.

The mechanics are simple: you register a builder address on-chain, set a fee rate (in basis points), and pass a builder field in your order payload. Every order tagged with your code credits volume to your address, and accruing fees are claimable periodically. The builder fee is paid by the taker on top of the exchange fee, so the builder captures a cut without reducing Hyperliquid's own revenue.

For anyone running a trading bot operation, builder codes are not optional bookkeeping. They are a revenue line. A bot routing several million notional per day at even 0.5 bps builder fee generates meaningful recurring income that compounds over time.

Registering and Configuring a Builder

Registration happens via a signed transaction to the Hyperliquid L1. You submit a setReferrer or builder-registration action with your address and your chosen fee rate in basis points. The maximum builder fee is capped at 10 bps — the exchange enforces this at the protocol level, not just in the UI.

A few practical points:

• Fee rate is per-order, not per-builder. You can pass different fee rates in different orders, up to your registered cap.
• The builder field is optional at the order level. If you omit it, no attribution happens and you collect nothing.
• Vault operators and sub-accounts count separately. If you run multiple vaults under one master, each vault's trades need the builder field explicitly set.

One operational trap: if you change your registered builder address, in-flight orders that reference the old address still resolve against the old record. Always drain outstanding orders before rotating addresses.

Hard Rate Limits on the API

Hyperliquid enforces rate limits at two layers: the WebSocket connection layer and the REST endpoint layer.

WebSocket order submission is the primary path for low-latency bots. The limit is 1,200 order actions per minute per IP, which works out to 20 per second sustained. Burst headroom exists but is not published — in practice, sending more than 40 orders in a single second reliably triggers backpressure.

REST endpoint limits are stricter and segmented by endpoint type:

• /exchange (order placement, cancellation): 1,200 requests/minute per IP
• /info (market data, position queries): 1,200 requests/minute per IP, but responses are cached server-side at 100ms intervals, so hammering faster than 10 req/s on static endpoints is wasted throughput
• WebSocket subscription channels for L2 data: no hard limit on subscriptions, but the server will drop clients that cannot consume the feed fast enough

Cancel operations count against the same budget as order placements. This is a meaningful constraint for market makers who are constantly repricing. A bot that places 600 orders/minute and cancels 600 orders/minute is already at the ceiling with zero headroom for fills or position queries.

Designing Around the Limits

The right architecture treats rate limit budget as a first-class resource, not an afterthought.

A few patterns that work in production:

• Batch cancels before batch places. Hyperliquid supports cancelByClid (cancel by client order ID) and bulk cancel payloads. Batching 10 cancels into one message uses 1 unit of rate-limit budget, not 10.
• Use client order IDs religiously. cloid lets you cancel without an open query to fetch the exchange order ID. Fewer info calls, more budget for order flow.
• Separate WebSocket connections for data and execution. Subscribe to L2 and trades on one connection; send orders on another. A single connection flapping due to data overload should not take down your order pipeline.
• Implement a token-bucket governor in the bot layer. Do not rely on the exchange to tell you when you're throttled — by then you've already received a 429 and potentially been rate-limited at the IP level for a cooldown window.

IP-level bans for sustained limit violations are enforced with an exponential backoff on the server side. A first offense may mean a 30-second blackout; repeated violations escalate. In a fast market, 30 seconds of blindness is catastrophic.

Fee Economics With Builder Codes in Practice

At scale, the builder fee model rewards volume consistency over spikes. Hyperliquid calculates builder fees on taker volume only — maker rebates flow back to the taker, not through the builder. This means a pure market-making book that is predominantly maker-side generates no builder fee income.

The practical implication: if your strategy takes liquidity during momentum events (e.g., a directional signal fires and you cross the spread), that taker flow is attributed and claimable. A hybrid market-making and momentum strategy naturally accumulates builder credits; a pure passive market maker does not.

For operations running at scale, builder code revenue at 1 bps on $50M monthly notional taker volume is $5,000/month — enough to matter in a P&L that is otherwise fighting for edge in sub-basis-point increments.

---

If you're building on Hyperliquid and want infrastructure that handles builder code attribution, rate-limit governance, and execution logic correctly from day one, reach out to TierZero — we've shipped this in production and can accelerate your build significantly.