Funding Arbitrage Across Hyperliquid and Drift Perps

Funding on the same asset rarely agrees across venues. On a random Tuesday I've seen ETH perp funding print +0.011% per hour on Hyperliquid while Drift's ETH-PERP sat at -0.003% for the same 60-minute window. That 0.014% gap, annualized, is roughly 123% — and it's collectable if you're short the expensive side and long the cheap side at matched notional. The catch is that Hyperliquid lives on its own L1 and Drift lives on Solana, so the arb is real but the plumbing is where it either works or quietly bleeds you out.

This is a different animal from the usual Hyperliquid-versus-Binance or HL-versus-Bybit funding trade. Both legs here are on-chain, both settle in different mechanics, and neither venue lets you net margin against the other. You're running two independent margin accounts on two chains and pretending they're one position.

Why the divergence exists at all

Funding is a venue-local number. Each exchange computes it from its own mark-versus-index premium and its own open-interest skew, so two order books for the same underlying drift apart based on who's leaning where.

• Hyperliquid uses a premium component plus a clamped interest term, sampled frequently and paid hourly. Its funding reacts fast to the perp trading rich or cheap against the oracle.
• Drift runs funding off its AMM-plus-orderbook (DLOB) mark against a Pyth-derived oracle, also settling continuously but with different caps and a different OI base.

Because the two venues have different trader populations — Hyperliquid skews toward aggressive perp-native flow, Drift toward Solana-native accounts and vaults — the OI imbalance on any given asset is frequently opposite. That's the structural reason the sign of funding flips between them often enough to trade. When Hyperliquid longs are paying to hold and Drift is flat or paying shorts, you collect on both legs at once.

If you've read our writeup on Jupiter trigger and recurring orders as a strategy engine, the mental model is similar: you're not predicting price, you're harvesting a mechanical, recurring payment and hedging the thing you don't want exposure to.

The position, concretely

Say the divergence favors shorting Hyperliquid and going long Drift on SOL-PERP. You want net delta near zero, so notionals match, not contract counts.

target_notional = 40_000  # USD per leg
sol_index = 168.40

# HL short leg
hl_size = target_notional / sol_index      # ~237.5 SOL short

# Drift long leg — Drift sizes in base units too, but check tick/lot
drift_size = target_notional / sol_index   # ~237.5 SOL long

# Net delta ≈ 0 as long as both fills land near sol_index.
# Slippage on one leg leaves residual delta you must trim.

The moment both legs are on, your PnL is: (funding you receive on the HL short) + (funding you receive on the Drift long) − fees − borrow/margin cost − any delta drift. If the combined funding is +0.010%/hr net, that $80,000 of gross exposure earns about $8/hr, ~$5,760/yr, on maybe $12–16k of posted margin if you run 3–5x. The leverage is what makes a 10-bps-per-hour edge worth the operational pain.

Getting both legs on without eating the edge

Legging in is the first place people lose money. If you fill the Hyperliquid short and then the Drift long moves against you by 20 bps while you're bridging or confirming, you've spent two hours of funding before you've collected a minute. Fill both legs as close to simultaneously as your infra allows. In practice that means pre-funding margin on both chains ahead of time — you do not want to be bridging USDC across to Solana at trade-open. Keep a standing balance on each side and only rebalance capital between them on a slow cadence.

Hyperliquid's API is a straightforward signed-order REST/WebSocket interface. Drift you'll hit through the TypeScript or Python SDK against its on-chain program, which means you're building and sending Solana transactions, dealing with priority fees, and occasionally eating a dropped tx during congestion. Budget for retries and idempotency — a double-filled leg is a real delta bug, not a hypothetical.

The risks that actually kill this trade

Independent liquidation. This is the big one. Each leg can be liquidated on its own venue. A sharp SOL move up hurts your Hyperliquid short's margin while your Drift long is fine — but Drift's collateral can't rescue the HL account. You have to margin each side to survive a move that the other side is profiting from. Run each leg's liquidation price at least 30–40% away from mark, and monitor both continuously. A dashboard that shows both margin ratios on one screen is not optional; this is exactly the kind of thing we build in our trading dashboard work.

Funding flips. The divergence is not a law of physics. When the sign converges — or worse, inverts — you're now paying on the side you were collecting. Set a rule: if net funding drops below a threshold (say +0.003%/hr) for N consecutive hours, unwind. Don't hold a delta-neutral position out of inertia when the reason you opened it is gone.

Oracle and mark differences. Drift marks against Pyth; Hyperliquid against its own oracle. During a fast move the two can disagree for seconds to minutes, which shows up as phantom PnL swings and can trip a liquidation on one side even when your true delta is flat. Size margin for the worst intraday oracle gap you've observed, not the average.

Execution and settlement asymmetry. Solana congestion can delay your Drift adjustments exactly when you most need to trim delta. Hyperliquid won't wait for you. This asymmetry means you should keep the Drift leg slightly under-levered relative to Hyperliquid, so the slower-to-adjust venue has more buffer.

The auto-rebalancing discipline here rhymes with what we covered in the Meteora DLMM fee-farming rebalance bot and the JIT liquidity strategy on Solana: the yield is real, but it only survives if a bot is watching the thing that can wipe it out faster than you can react by hand.

What a working bot looks like

Minimum viable loop:

1. Poll funding on both venues (WebSocket where available, REST fallback).
2. Compute net funding for each candidate asset, rank, filter for liquidity depth on both books.
3. On a qualifying divergence, size matched notional, fill both legs near-simultaneously, record entry basis.
4. Every cycle: check net delta, trim the residual; check both margin ratios, top up or de-lever; check net funding against the exit threshold.
5. Unwind both legs together when the edge decays or a margin alarm fires.

The unglamorous parts — retry logic on Solana tx drops, delta reconciliation after partial fills, alerting when one venue's WebSocket goes stale — are 80% of the code and 100% of the reason it survives a bad week. Before any capital touches mainnet, it's worth having the liquidation and reconciliation paths independently reviewed, because those are the bugs that don't show up in backtests.

If you're weighing whether this divergence is deep and stable enough to run at your size, that's a conversation worth having before you write the executor — a strategy consultation will tell you fast whether the edge clears your costs.