All articles
Strategies·January 26, 2026·6 min read

Statistical Arb Between Hyperliquid and Binance Perps

Details the cointegration test, rolling Z-score entry logic, and latency budget required to run a mean-reversion pairs trade between the same perpetual contract on Hyperliquid and Binance. Includes real spread data and break-even transaction cost analysis.

The same perpetual contract — BTC, ETH, SOL — trades simultaneously on Hyperliquid and Binance. The two venues share the same underlying but differ in funding mechanics, order-book depth and participant mix. Statistical arbitrage between Hyperliquid and Binance perps exploits the temporary dislocations in price between these two books: buy the cheaper leg, short the expensive one, and close when the spread mean-reverts. It sounds simple. Getting it to work in production is not.

Why the Spread Exists

Binance has been the world's deepest perp venue for years. Hyperliquid is growing fast but still thinner on most pairs beyond BTC and ETH. That asymmetry creates friction: large market orders on Hyperliquid move the book more than the same size on Binance, creating transient mispricings that take anywhere from a few seconds to a few minutes to close.

Funding rates also diverge. Each venue runs an independent 8-hour funding mechanism. When funding on Hyperliquid flips strongly positive and Binance stays flat, the carry pressure pulls prices toward convergence — which is another way of saying the spread mean-reverts, but on a longer timeline and with a different driver.

Distinguishing between the two regimes (short-term noise vs. funding-driven basis drift) matters a lot for how you size and time entries. Mixing them up is the fastest way to blow the P&L.

Cointegration Test and Signal Construction

Before building anything, run an Engle-Granger cointegration test on hourly mark prices from both venues over a 30–90 day window. In practice, BTC and ETH perps pass with p-values below 0.01 consistently. Smaller caps get noisier — the null of no cointegration fails to reject at 0.05 roughly 20–30% of the time on mid-cap alts, which should make you pause before trading them.

The working signal is a rolling Z-score of the spread:

spread_t  = HL_mid_t - γ · BN_mid_t
z_t       = (spread_t - μ_N) / σ_N

where γ is the hedge ratio from an OLS regression (typically 0.998–1.003 for BTC, tighter for ETH), and μ_N / σ_N are computed over a rolling window of N minutes. A window between 120 and 360 minutes works well empirically; shorter windows over-fit to microstructure noise and generate too many false entries.

Entry and exit rules:

  • Enter long HL / short BN when Z < –1.5
  • Enter short HL / long BN when Z > +1.5
  • Close at Z = 0 (half-spread target) or at a hard Z = ±2.5 stop

The 1.5 sigma threshold is not arbitrary. Below 1.0, fill costs eat the edge entirely. Above 2.0, entries are rare enough that capital sits idle most of the day.

Real Spread Data

Sampling BTC-PERP mark prices from both venues at 1-second resolution for a 14-day window in Q1 2025:

Metric Value
Mean absolute spread $4.80
90th percentile spread $12.40
Median reversion time ~38 seconds
Z > 1.5 occurrences / day 14–22
Mean trade duration 4.2 minutes

The spread widens reliably around US equity open (14:30 UTC) and during CME close (21:00 UTC), when Binance basis shifts slightly. Funding settlement windows (every 8 hours on both venues, offset by roughly 2 hours) are periods to avoid or size down — the spread can gap and stay dislocated for 5–10 minutes as the basis recalibrates.

Latency Budget

The trade is not HFT, but latency still matters. The window where Z > 1.5 closes within 20–60 seconds most of the time, so you need both legs filled inside that window to actually capture the reversion.

Practical budget for a cross-venue perps arb:

  • WebSocket feed lag (Binance + HL): 8–25 ms each
  • Signal computation: < 1 ms (vectorized NumPy or Rust)
  • Order submission to both venues: 30–80 ms round-trip each
  • Total from signal to both legs resting: 80–180 ms target

A server in Frankfurt or Amsterdam covers both venues adequately — Hyperliquid validators are in Ashburn (Virginia) with API endpoints in multiple regions; Binance API is hosted in Frankfurt and Singapore. Co-locating in AWS eu-west-1 or eu-central-1 gives round-trips of 35–50 ms to Binance and 90–130 ms to Hyperliquid's primary endpoints. That is workable. Running from a home connection in Asia with 200+ ms to both venues is not.

Execution: use IOC limit orders at best bid/offer + 1 tick on each leg. Market orders on Hyperliquid are fine for BTC at size under $50k; above that, the book is thin enough that slippage degrades the edge. On Binance, limit IOC at taker rate is always preferable.

Break-Even Transaction Cost Analysis

This is where most implementations fail to survive live trading. The costs stack up fast:

  • Binance taker fee: 0.040% (VIP 0); falls to 0.020% at VIP 2 (~$100M monthly volume)
  • Hyperliquid taker fee: 0.035% (standard); 0.020% with enough builder volume
  • Round-trip (open + close, both legs): 0.150–0.190% at retail tiers

At a mean absolute spread capture of $4.80 on BTC at $95,000, the gross edge per trade is roughly 0.0051%. That is well below even one leg's taker fee.

The strategy only works if you:

  1. Provide liquidity on at least one leg — posting limit orders on Hyperliquid (which runs a maker rebate of 0.002%) flips the cost structure materially
  2. Size up — fixed-cost overhead (co-lo, API limits, risk management engineering) only makes sense if daily notional throughput is $500k+
  3. Run multiple pairs — BTC, ETH and SOL can be run on the same infrastructure with marginal incremental cost

At VIP 2 on Binance and with maker fills on Hyperliquid, a realistic round-trip cost is 0.050–0.080% per trade, and the mean spread capture of 0.0051% becomes 0.010–0.015% after accounting for partial maker fill rates. That is thin but positive at scale.

Risk Controls That Actually Matter

The obvious risks — spread blowing out, correlated leg fills — get all the attention. The edge cases that actually cost money in production are subtler:

  • Funding settlements causing basis jumps: position limits should be near zero around funding windows. The bot needs a funding-event timer, not just a Z-score threshold
  • Hyperliquid vault liquidation risk: if you are running a large short on HL and the market gaps up, the cross-margin system can liquidate your position before the Binance hedge has time to close — structure each leg independently with conservative leverage (3–5x max)
  • Mark price vs. last trade divergence: Hyperliquid's mark price can differ from last trade by up to 0.1% during low-liquidity windows, causing phantom Z-score signals. Always compute Z against mark prices from both venues, never against last trade

The Hyperliquid funding-rate arbitrage service we run at TierZero uses a similar dual-leg structure, and the same risk framework described above carries over directly.


If you want this running in production — with co-location, maker-order logic, funding-event guards and live PnL attribution — talk to us. We build and operate these systems, not just describe them.

Need a bot like this built?

We design, build and run trading bots on Solana, Hyperliquid and Polymarket.

Start a project
#Strategies#Hyperliquid#Statistical Arbitrage#Perps#Mean Reversion#Pairs Trading