TWAP vs Iceberg Orders on Hyperliquid: Best for Large Blocks

Executing a $2m BTC-PERP position on Hyperliquid as a single market order is not a trading strategy — it's a donation to whoever is sitting passive on the other side. TWAP and iceberg orders on Hyperliquid solve the same problem — minimizing market impact — but they attack it from different angles, and choosing the wrong one at a given notional size or liquidity regime costs you more than you'd expect. Here is a ground-level look at how each algorithm actually behaves on Hyperliquid's order book, with concrete numbers from backtests we ran across Q4 2024 through Q1 2025.

Why Hyperliquid's Order Book Structure Matters

Hyperliquid runs a fully on-chain CLOB with real-time settlement and no batching delay, which gives it tighter spreads than most on-chain venues but also means the book is thinner than Binance Futures at depth. Resting liquidity in BTC-PERP at the top five levels typically covers $300k–$600k on each side during active hours; SOL-PERP runs $80k–$200k. These numbers shrink fast in off-hours and during high-volatility windows.

A naïve market order for $1m notional in BTC-PERP during off-peak hours will routinely eat through 6–12 bps of spread beyond mid, and SOL-PERP at the same notional can punch through 20–35 bps. Neither statistic is theoretical — both come from order-book snapshots we recorded across our production systems.

How TWAP Works in Practice

TWAP (time-weighted average price) splits the parent order into equal-sized child orders and spaces them uniformly across a target execution window. A $1m sell executed as TWAP over 30 minutes becomes roughly 30 child orders of $33k each, fired every 60 seconds as market or aggressive limit orders.

The logic sounds simple but the implementation details matter:

• Child order type: passive limits with a time-to-live (TTL) of 5–15 seconds reduce realized slippage by 3–8 bps versus market children at sizes under $100k per slice, but introduce fill-rate risk when the book moves away
• Interval jitter: adding ±15% random noise to each interval prevents predatory patterns from front-running the schedule; without it, adversarial MMs can time their quotes around your schedule
• Residual handling: if a child limit expires unfilled, the standard approach is to revert it to market — but at sizes above $200k per slice this produces spiky impact; a better pattern is to split the residual across the next two intervals

Our backtests on BTC-PERP show that TWAP over a 30-minute window reduces market impact by 58–72% compared to a single aggressive order at notionals between $500k and $2m. The range widens at higher notionals because book replenishment becomes more variable.

How Iceberg Orders Work in Practice

An iceberg posts a small visible quantity to the book while hiding the remaining size. On Hyperliquid, this means repeatedly refreshing a passive limit at or near the inside price, revealing only the display quantity each time, and refilling when a tranche fills.

The critical tuning parameters are:

• Display size: typically 5–15% of the parent order; too small and you're just churning fees, too large and you reveal too much intent and get faded
• Refresh logic: immediate refresh after each fill keeps you aggressive on momentum; delayed refresh (50–200ms pause) reduces being run over during a sweep
• Price aggressiveness: posting at best bid/offer captures the spread but risks sitting below a moving market; posting one tick inside sacrifices a few bps to improve fill probability

Icebergs outperform TWAP when the primary risk is information leakage rather than market timing. If a counterparty can infer your total size from order-flow patterns, an iceberg at a fixed price is harder to front-run than a predictable TWAP clock. However, icebergs carry more adverse-selection exposure — you are always posting passive, so you fill more when the market is moving against you.

Backtested Slippage Comparisons: BTC-PERP and SOL-PERP

The table below shows realized slippage (in bps vs. arrival mid) for sell orders across different notional sizes and execution methods. Data covers 480 simulated executions per cell, sampled from real order-book snapshots across October 2024 – February 2025, using our internal execution simulator.

BTC-PERP — Sell Side

Notional	Single Market Order	TWAP 30m	Iceberg (10% display)
$250k	4.2 bps	1.8 bps	2.1 bps
$1m	9.7 bps	3.4 bps	4.0 bps
$2.5m	22.1 bps	6.8 bps	9.3 bps
$5m	47.3 bps	14.2 bps	18.7 bps

SOL-PERP — Sell Side

Notional	Single Market Order	TWAP 30m	Iceberg (10% display)
$250k	11.4 bps	4.7 bps	5.2 bps
$1m	31.8 bps	9.6 bps	12.8 bps
$2.5m	74.2 bps	19.3 bps	26.1 bps
$5m	142+ bps	38.7 bps	49.4 bps

TWAP wins on slippage at every tested notional. Iceberg closes the gap slightly at the lower end ($250k), but TWAP's advantage expands dramatically above $1m. The crossover point where an iceberg would beat TWAP does not appear in our data — it would require a market where adverse selection on passive orders is dominant, which describes certain low-liquidity altcoin perps on Hyperliquid but not BTC or SOL.

When to Use Which

Use TWAP when:

• Your primary cost is market impact and you can afford a fixed time window
• You need predictable average price and can tolerate execution-price risk within the window
• The position is directional and you want to avoid sitting passive against a trending book

Use iceberg when:

• You need to maintain a price level (e.g., defending a cost basis or filling at a specific limit)
• Your execution window is open-ended and you can wait for the book to come to you
• You are working a limit that already has favorable risk/reward and fill speed is secondary to price

Hybrid approach: for positions above $2m, combining both often works well — TWAP for the first 60–70% to capture the majority of shares efficiently, then switch to an iceberg to work the residual passively at a favorable level. This is the approach built into our Hyperliquid perps execution infrastructure for clients running large block strategies.

Implementation Pitfalls

Rate limits on Hyperliquid's API impose a practical floor on how small you can set TWAP intervals — bursting too many child orders per second triggers throttling and can cause the scheduler to fall behind. In our production code we target a minimum of 8–10 seconds between child submissions for consistent execution, with a fallback burst allowance of 3 orders for residual catch-up.

Iceberg implementations must also handle the scenario where the book sweeps through your display quantity and continues — naïvely refreshing at the same price after a sweep means you are posting passive into a moving market. A stale-quote guard that pauses refresh for 200–500ms after a fast fill sequence reduces adverse selection materially, at the cost of slightly lower fill rate.

Both algorithms benefit from a live book-depth feed driving dynamic sizing: when the top-of-book depth doubles, you can safely increase child size or display quantity; when depth halves, reduce it. Hard-coding slice sizes from average liquidity leaves alpha on the table during thick-book periods and increases impact during thin ones. If you are building this kind of adaptive execution on Hyperliquid, the Hyperliquid Market-Making Bot infrastructure we build uses the same live-depth feeds and can be extended to cover large block execution alongside quoting strategies.

---

If you are running positions at the notional sizes discussed here and currently executing them manually or with a basic market order, the slippage cost likely exceeds the budget for a properly built TWAP/iceberg system within weeks. Talk to us about building production-grade large block execution for Hyperliquid perps — we scope, price and ship it fast.