Atomic Arbitrage Between Drift CLOB and AMMs on Solana

Atomic arbitrage between Drift Protocol's on-chain CLOB and Orca or Raydium AMMs is one of the cleaner MEV trades on Solana — two price sources that update at different speeds, collapsible into a single transaction with no leg risk. But the mechanics are unforgiving: the window is narrow, the compute budget is tight, and the account list is long enough to trip up anyone who hasn't read the program IDL carefully. This is what running it in production actually looks like.

Why Drift vs. AMM Diverges at All

Drift's CLOB maintains resting limit orders that update only when a keeper crank turns or a taker hits them. AMM prices on Orca (Whirlpool) and Raydium (CLMM) update on every swap. When a large AMM trade moves spot price, the CLOB can lag for one or more blocks — the gap between the AMM mid and the best Drift ask (or bid) becomes the arb. The same thing happens in reverse: a big CLOB fill moves Drift's mark and the AMM hasn't caught up.

The asymmetry is predictable. AMMs are continuously repriced by volume; the CLOB reprices in discrete increments. Every block where that gap exceeds your all-in cost — fees, priority fee, Jito tip — is an opportunity. In practice you're looking for spreads above about 8–12 bps after costs on a SOL-USDC or SOL-PERP route before it's worth submitting.

Account Structure and Instruction Composition

The hard part of this arb isn't finding the price gap — it's building a transaction that doesn't fail on account validation. A Drift market order needs: the user account, the user stats account, the state account, the market account, the oracle account, and the spot market vaults for both base and quote. On top of that, the Drift program expects a specific account ordering in the remainingAccounts slice for the spot markets involved.

Orca Whirlpool adds its own list: the whirlpool account, both token vaults, the tick array accounts (you need the correct tick arrays for the current price, which change as price moves), and both associated token accounts for your signer. Raydium CLMM is structurally similar.

A working instruction composition looks like this:

• Instruction 0: ComputeBudgetProgram.setComputeUnitLimit — budget 600,000–900,000 CU depending on route complexity
• Instruction 1: ComputeBudgetProgram.setComputeUnitPrice — tuned dynamically (see below)
• Instruction 2: Orca/Raydium swap — sell the overpriced leg on the AMM
• Instruction 3: Drift place-and-fill or fill order — take the underpriced leg on the CLOB

The order matters. You want the AMM fill confirmed before the CLOB instruction executes, and you want both to land or neither to land — that's what keeps it atomic. If the CLOB fill fails (no resting liquidity at your price), the transaction reverts and the AMM swap never settles. No position, no loss.

One gotcha: Drift's placeAndTakePerpOrder requires the remainingAccounts to include all oracle accounts for any market the user is currently in. If your signer wallet has open positions in other markets, those oracles need to be in the list or the instruction panics with an account not found error.

Compute Budget and Priority Fee Tuning

Running close to the 1.4M CU block limit means you need to be precise about your budget request. Over-requesting wastes fee headroom; under-requesting causes silent truncation that fails mid-instruction. Profile the transaction with solana-test-validator and the --log flag first — you'll see the exact CU consumed per instruction.

Priority fees are the main lever for inclusion speed. The floor for competitive arb on Solana is around 500,000 microlamports per CU during normal conditions, but that number spikes 5–10x during volatile periods. Calibrate against the rolling 50th and 95th percentile of recent block fees (the getRecentPrioritizationFees RPC call gives you this per-slot data). Set your floor dynamically: if estimated profit is $40 and block fees would cost you $15 at the 95th percentile, the trade is still positive EV.

When submitting via Jito bundles, you're paying a tip rather than a priority fee. Tips are economically equivalent, but the accounting is different — the tip is a SOL transfer to a Jito tip account and is not recoverable if the bundle fails. Keep your tip calibrated to the expected profit minus a safety margin. A rule of thumb: tip at most 50–60% of expected profit on competitive routes; on routes where you have an information edge (private RPC, custom geyser subscription), you can shade it higher.

Latency Thresholds That Actually Matter

The arb closes when a competing transaction lands or when the CLOB updates. On Solana's 400ms block time, you have at most one to two blocks from when you detect the gap to when you need to be confirmed. In practice, competitive detection-to-submission latency needs to be under 50ms if you're relying on public RPC. With a private Geyser stream and a geographically colocated node, you can push that to under 10ms, which meaningfully expands the set of opportunities you can profitably chase.

The venue-specific latency profile matters too. AMM prices are readable from program account state — subscribe to the pool account via Geyser and you get the new price in the same slot as the swap. Drift's mark price updates are slightly less direct: you're watching the order book state account and the oracle, and inferring available fill prices from resting limit orders. Building a local order book replica from account updates is necessary if you want sub-slot reaction time.

A threshold to internalize: if your round-trip from Geyser update to RPC confirmation is above 200ms, you will lose most races to operators running colocated infra. That's not a reason to skip the strategy — the economics work even at lower win rates if you're selective — but it shapes which routes you target. Illiquid CLOB markets with fat spreads and slow repricing are more forgiving than SOL-USDC which has aggressive competition.

Risk Controls You Cannot Skip

Atomic construction handles leg risk, but it doesn't handle everything. The residual risks in production are:

• Stale oracle: Drift uses Pyth. If Pyth is stale (common during validator instability), your profit estimate is wrong. Check the oracle confidence interval and staleness flag before submitting.
• Slippage on the AMM: Even with a price quote, Whirlpool fills can slip if another transaction lands in the same slot before yours. Use a minimum output amount instruction argument — set it to 99.5% of your expected output, not the default zero.
• Wallet exposure: Your signer wallet needs both SOL for fees and the base/quote tokens for the trade. Running out of SOL mid-session causes silent failures that are annoying to debug at 3am.
• Compute simulation before submission: Always simulate with simulateTransaction before sending live. A failed simulation costs nothing; a failed on-chain transaction burns the priority fee.

These are not edge cases — they're the failure modes you'll hit within the first week of live trading if you haven't accounted for them.

What Makes a Route Worth Running

Not every Drift market is worth arbing against AMMs. The criteria for a viable route:

• Sufficient AMM liquidity: thin pools move too much on your arb swap, eating the spread
• Active CLOB resting orders: if there's no resting liquidity at competitive prices, the CLOB fill reverts and you wasted the priority fee
• Spread above ~8–12 bps after all costs on a consistent enough basis to justify the infrastructure overhead
• Predictable oracle latency: markets with choppy or wide Pyth confidence intervals generate more false signals than real ones

SOL-USDC and SOL-PERP on Drift with Orca SOL/USDC Whirlpool as the AMM leg are the standard starting point. The competition is high but the liquidity and spread behaviour are well-understood. BTC-USDC is viable but requires more capital. Long-tail markets have less competition but also less resting CLOB liquidity — validate fill rates before deploying capital.

---

If you want a production-grade implementation of this strategy — with Geyser account subscriptions, dynamic priority fee calibration, Jito bundle submission, and proper compute budget profiling — reach out. We build and run these systems for clients who want the infrastructure handled by engineers who have already hit every failure mode described above.