TWAP Execution on Hyperliquid: Minimizing Slippage for Large Orders

Hyperliquid's order book is deep by perp DEX standards, but deep is relative. Drop a $1M BTC-PERP market order at 2 AM UTC and you will move the price against yourself by more than the taker fee warrants. TWAP — time-weighted average price — is the standard institutional response: split the order across time, absorb liquidity as it refreshes, and land near the prevailing mid rather than the post-impact mid. Here is what that actually looks like in production on Hyperliquid in 2025.

Why Slippage Gets Painful Above $500k Notional

Hyperliquid publishes its order book on-chain via its consensus layer, which means you can inspect depth programmatically before you send anything. For BTC-PERP during active hours, top-of-book depth within 0.1% of mid routinely sits between $800k–$2M. For ETH-PERP it is thinner. For mid-cap perps like WIF or HYPE itself, assume $100k–$400k before meaningful price impact.

The practical rule: once your order exceeds roughly 30–40% of visible depth within 0.2% of mid, the expected slippage on a single market order starts compounding nonlinearly. At $500k on a thinner perp, you are already there. At $1M on BTC-PERP during low-volume windows, you are there too. TWAP does not eliminate that impact — it amortizes it across book-refresh cycles, which on Hyperliquid run at sub-second latency.

Hyperliquid's Native TWAP: Mechanics and Limits

Hyperliquid ships a native TWAP order type that most traders overlook. You specify a total size and a duration (in minutes), and the exchange engine slices it into equal sub-orders executed at regular intervals. No keeper bot, no gas estimation, no off-chain scheduler.

The native implementation executes as limit orders at the current best ask (for buys) or best bid (for sells) with a built-in fill-or-skip logic: if the sub-order cannot fill within a price tolerance, it skips that interval rather than crossing the spread aggressively. This protects you from execution during sudden spreads caused by liquidation cascades.

Practical limits of the native TWAP:

• Minimum duration is 5 minutes; maximum is 24 hours.
• Sub-order sizing is fixed and equal — no volume-weighted or volatility-adjusted scheduling.
• You cannot inject custom participation rates (e.g., trade more when book depth increases).
• There is no event-based pause — it keeps firing even if a large print moves the market 2% in your direction.

For a straightforward $500k–$2M execution over 30–60 minutes where market conditions are stable, the native TWAP is often good enough and operationally simpler. But for anything more nuanced, you build your own.

Custom Bot TWAP: What You Actually Control

A custom execution bot built on Hyperliquid's API layer gives you full control over the scheduling logic. The core loop is not complicated — what matters is what you layer on top of a naive equal-interval split.

Participation rate adjustment. Before each sub-order, query the L2 snapshot. If depth within 0.15% of mid is above a threshold (say, 2× your sub-order size), execute at full slice size. If depth is thin, cut the slice by 50% or skip the interval. This alone reduces adverse-selection cost measurably on thinner books.

Volatility gating. Compute a rolling 5-minute realized volatility estimate from the mark price stream. If vol spikes above a threshold — typically 2× the session baseline — pause execution. This prevents you from continuing to buy into a momentum move.

Dynamic limit pricing. Rather than pegging to best ask, set your limit at mid + (spread * 0.4). You cross less of the spread, you post more passively, and on Hyperliquid's maker rebate structure you often flip the fee sign on a meaningful fraction of fills.

Completion targeting. Build in a catch-up mechanism: if you are 20% behind schedule at the halfway mark, widen your limit aggressively or briefly allow market fills. Incomplete executions that leave residual risk are worse than slightly elevated slippage on the close-out.

Measured Slippage: Native vs. Custom, Real Conditions

Running both approaches against the same execution targets across 90 days of internal testing on BTC-PERP and ETH-PERP (orders in the $500k–$3M range):

Approach	Avg. Slippage vs. TWAP Benchmark	Worst-Case Interval
Single market order	18–42 bps	N/A
Native TWAP (30 min)	4–9 bps	22 bps
Custom bot TWAP (30 min, vol-gated)	2–5 bps	11 bps

The custom bot roughly halves slippage versus native TWAP on volatile days — the sessions where it matters most. On quiet, high-liquidity sessions the gap narrows to near zero. That asymmetry is the argument for building your own: you pay for the engineering once and capture the savings on the tail events that would otherwise hurt you.

Infrastructure Considerations

Hyperliquid's InfoAPI websocket feeds L2 snapshots at 20ms intervals in practice. Your execution loop should be reading from the websocket, not polling REST — the latency difference matters when you are making participation decisions. Keep your execution process co-located or as close to the endpoint as latency allows; the exchange runs validators in Tokyo and Frankfurt, so edge location matters for the final-leg round trip.

Use signed WebSocket sessions for order placement, not REST per-order — the throughput ceiling is higher and you avoid per-request auth overhead on tight loops. Rate limits on Hyperliquid's API are generous by CEX standards, but sub-order bursts on a 5-second cadence can brush against them if you are running multiple symbols concurrently.

One non-obvious issue: Hyperliquid's cancel-on-disconnect behavior. If your bot drops connection with open sub-orders in flight, those orders remain live. Build dead-man logic — a heartbeat that cancels all open execution orders if the main process does not check in within N seconds.

---

If you are executing at scale on Hyperliquid and want a production-hardened TWAP bot rather than building from scratch, talk to us — this is exactly the kind of system we design, deploy, and operate.