CEX-DEX Arbitrage Latency: Beating Solana MEV Searchers

The gap between a Binance trade print and a filled Raydium swap on the same asset is where this entire business lives. On a good day that window is 40 to 120 milliseconds wide, and there are maybe six teams on Solana who can consistently be first through it. Everyone else is providing exit liquidity to those six. If you're building a CEX-DEX arb bot and you're thinking about it as a trading problem, you've already lost — it's a latency-engineering problem with a trading strategy bolted on at the end.

Here's the actual race. A large market order hits BTC/USDT on a centralized venue and moves the price. SOL-margined or wrapped versions of correlated assets on Solana DEXs haven't repriced yet because their price discovery lags the CEX. Your bot sees the CEX print, computes that Raydium's constant-product pool or a Jupiter route is now mispriced against the new fair value, and fires a swap to capture the difference before the pool's own arbitrageurs or an MEV searcher watching the same signal beats you to it.

Where the milliseconds actually go

People obsess over their swap-building code and ignore the two legs that dominate the budget: getting the CEX signal and getting the Solana transaction landed. Rough decomposition of a well-tuned stack, one-way:

• CEX WebSocket delivery to your box: 1–15 ms depending on colocation
• Signal computation and route decision: 0.2–2 ms if you're not doing anything stupid
• Transaction build, sign, and serialize: 0.3–1 ms
• Submission to a Jito block engine and inclusion: 400 ms floor (one slot), realistically 1–2 slots

That last number should reorganize your priorities. Solana slots are ~400 ms. No matter how fast your signal path is, your transaction lands on a slot boundary. Shaving 5 ms off signal processing is worthless if you then wait a full slot for inclusion. The game isn't being fast in the abstract — it's being fast enough to make the current leader's block with a competitive Jito tip, and doing that consistently.

The CEX feed leg

Colocate. If your signal is coming from Binance, you want a machine in the same AWS region (Tokyo, ap-northeast-1) their matching engine writes to, with a direct WebSocket to the depth stream, not the aggregated ticker. The aggregated ticker is throttled and smoothed; the raw depth@100ms or the trade stream gives you the print the instant it happens. Parse the frame yourself — don't route it through a heavyweight client library that allocates on every message. A hand-rolled simd-json parse of the relevant fields keeps you in single-digit microseconds.

One gotcha that burns people: exchange WebSocket feeds silently reorder and batch under load. During the exact volatility spikes you're trying to trade, your feed latency variance blows out. Measure p99, not mean. A feed that's 3 ms average but 80 ms at p99 will get you picked off precisely when the edge is largest.

The Solana side: seeing and landing

Reading Solana state fast is its own discipline. Public RPC is a non-starter — you need a dedicated node with a Geyser plugin so you get account updates pushed to you instead of polling. If you want the mechanics of streaming pool state and pending transactions with minimal jitter, the Yellowstone gRPC Geyser setup for Solana mempool streaming covers the plumbing we lean on — subscribing to specific Raydium and Meteora accounts and getting deltas at slot speed rather than reconstructing state from block scans.

Landing the transaction is where searchers earn their edge. You submit a Jito bundle — an atomic, ordered set of transactions — to a block engine with a tip that competes for placement in the leader's block. A few things that matter more than they should:

• Tip sizing is an auction, not a constant. Under contention your tip has to beat the other searcher targeting the same pool. Pull the tip floor from Jito's tip stream and price dynamically off your expected edge. A fixed 10,000-lamport tip loses every contested race.
• Send to the block engine closest to the upcoming leader. Jito runs regional engines. If you blindly hit one endpoint, you eat cross-region latency into the block-building deadline. Track the leader schedule and route accordingly.
• Bundle atomicity is your friend. Put the swap and any revert-guard in one bundle so a partial fill can't strand you with unhedged inventory.

There's an even lower-latency path than mempool-watching for the fastest teams: consuming the shred stream directly to see transactions before they're fully confirmed. We wrote up how the Jito ShredStream latency edge changes what's possible for a searcher who's willing to run the infrastructure. For CEX-DEX specifically it matters less than for on-chain-only strategies, because your alpha originates off-chain, but it helps you detect competing arb transactions early and adjust your tip.

The part nobody wants to build: inventory hedging

This is where amateur bots quietly bleed out. When you buy the underpriced asset on Raydium, you're now long inventory that you need to flatten, usually by selling the correlated position back on the CEX. The DEX leg fills atomically on-chain; the CEX hedge fills whenever your order reaches their matching engine — a different latency domain entirely. Between those two events you carry directional risk.

A worked example. Say the CEX moved SOL up 0.4% and you buy 500 SOL of exposure on Raydium at the stale price for a 12 bps gross edge. Your hedge is a 500-SOL short on the CEX perp. If your hedge lands 200 ms later and SOL keeps moving 0.3% against you in that window, you've eaten more than your entire edge in slippage on the hedge leg. So:

# Gate the arb on hedgeable edge, not gross edge
gross_edge_bps = (fair_value - dex_exec_price) / fair_value * 1e4
hedge_slippage_bps = est_hedge_slip(size, cex_book_depth, feed_latency_p99)
jito_tip_bps      = tip_lamports * sol_price / notional * 1e4

net_edge = gross_edge_bps - hedge_slippage_bps - jito_tip_bps - dex_fee_bps
if net_edge > MIN_EDGE_BPS:   # we set this at 3–4 bps, not 0
    fire_bundle()

The discipline is refusing trades where the gross edge looks fat but the hedge is unreliable. Pre-position inventory on both venues so you can lean either direction without a round trip, and size against your worst-case hedge slippage, not your average. The teams that survive treat the CEX perp desk as part of the bot, not an afterthought — the same principle applies whether you're arbing into Jupiter or running EVM arbitrage across DEX pools, where the hedge domain differs but the inventory-risk math is identical.

Where the well-funded searcher actually wins

Not on clever code. Three places: colocation you can't match on a hobbyist budget, a dedicated Geyser node instead of shared RPC, and dynamic Jito tip pricing tuned against real contention data. The strategy logic is maybe 15% of the edge. The other 85% is infrastructure discipline — measured p99 latency at every hop, leader-aware bundle routing, and hedging that respects the two-latency-domain problem. If you want to compare this signal-driven approach against pool-native strategies like JIT liquidity on Meteora DLMM, the tradeoff is that CEX-DEX gives you a cleaner alpha source at the cost of a much harder hedging problem.

Getting the colocated feed and low-jitter data infrastructure right is the unglamorous half that decides whether you're one of the six teams or their counterparty. If you're serious about building a searcher that competes in this window, our Solana MEV and arbitrage bot work is where we start.