Solana arbitrage bot setup: a practical guide

TL;DR

•  Arbitrage on Solana is 50%+ of DEX volume—90M+ confirmed arb txs through Jito in 2025, generating $142.8M in cumulative profits.

•  Bot logic is now commoditized. The difference between profitable and losing arb bots in 2026 is almost entirely infrastructure: data feed latency and bundle landing rate.

•  Public RPCs are 200ms behind validator-adjacent nodes. WebSocket subscriptions miss updates between polling intervals. Standard RPC submission loses to Jito bundles every time.

•  RPC Fast benchmarks: 38ms median route detection latency, 96% Jito bundle landing rate, 18% revert rate. Public RPC equivalents: 380ms / 24% / 64%.

•  This guide walks through the full setup: stack choice (Rust vs TypeScript), DEX coverage, RPC + Geyser config, Jito bundle tuning, slippage controls, and what to monitor before going live.

‍

Arbitrage on Solana is mechanical: the same token trades at different prices across Raydium, Orca, Meteora, and Phoenix at any given moment. A bot that spots the gap and closes it faster than everyone else captures the spread. The chain handles the rest—transactions are atomic, so if either leg of the trade fails, the whole thing reverts. No partial fills, no stuck positions.

In 2025, arbitrage accounted for roughly 50% of Solana's average DEX volume. Over 90 million successful arbitrage transactions were recorded through Jito's detection system—generating $142.8 million in combined profits.

Most bots don't capture any of it. Not because the strategy is wrong, but because the setup is. A bot reading prices from a public RPC is already 200ms behind the bots co-located next to validators. A bot using WebSocket subscriptions instead of Geyser gRPC misses price updates that arrive between polling intervals. A bot submitting through standard RPC instead of Jito bundles loses to bots that guarantee execution order.

The logic is secondary. Infrastructure is the entry ticket.

What a Solana arbitrage bot actually does

The core loop has five steps:

Setup guide

Step 1: Choose your stack

Most production arbitrage bots on Solana run in Rust or TypeScript. The choice has real performance implications:

For a first production bot, TypeScript is a reasonable starting point. For anything competing in the sub-slot latency tier, Rust is not optional.

Step 2: DEX coverage

Minimum viable coverage in 2026:

• Raydium (CPMM and CLMM pools)—largest DEX by volume on Solana
• Orca Whirlpool—concentrated liquidity, high volume on major pairs
• Meteora DLMM—dynamic liquidity, strong memecoin flow
• Phoenix—on-chain order book, useful for CEX-DEX arb

Jupiter as a routing layer helps with quote discovery. Their self-hosted jupiter-swap-api binary can be queried locally at millisecond latency, aggregating quotes across 30+ DEXs without hitting public endpoints.

Start with 2–3 DEX pairs on high-liquidity tokens (SOL/USDC, SOL/USDT). Prove the logic works, then expand.

Step 3: Configure your RPC and data feed

This is where most setups fail. A working .env configuration:

Key decisions:

• Use processed commitment, not confirmed or finalized—you need the freshest possible state, and arbitrage reverts safely if the slot reorganizes
• Never use a public RPC in production—rate limits kick in during congestion, and you're competing against bots with dedicated endpoints
• Geyser gRPC over WebSocket—Yellowstone streams push account updates directly from validator memory, sub-50ms latency vs 100–300ms for standard WebSocket

Subscribe to specific pool accounts, not all transactions. Filter at the server level:

Step 4: Jito bundle configuration

Standard RPC submission enters the gossip network and competes randomly for block inclusion. Jito bundles guarantee atomic execution in order—if the bundle doesn't land, none of the transactions execute.

Arbitrage bots on Solana typically pay 50–60% of expected profit in Jito tips to outbid competing searchers. Too low: bundle gets skipped. Too high: strategy turns unprofitable.

Tip calibration: start at 50% of estimated profit, monitor bundle acceptance rate, adjust from there. Send to multiple block engine endpoints in parallel—US East, EU, Tokyo—to improve inclusion across different slot leaders.

Step 5: Slippage and risk controls

Always run simulateTransaction before bundle submission on high-value opportunities. Simulation catches routes that look profitable off-chain but fail on-chain due to pool state changes between detection and execution. A failed simulation costs zero. A failed bundle with a large Jito tip does not.

On the data side, Aperture TxStream carries the same idea into the feed: it attaches a predicted execution result to each transaction while it is still in flight, before it lands, reconstructed from deshredded data and accurate to roughly 95% against actual execution, at a cost of about +791 µs to median delivery. That prediction is included on the Aperture plan; on Stream, TxStream is available for a limited time without simulation.

Step 6: Test before mainnet

Run the bot on devnet with simulated transactions. Monitor these metrics before going live:

RPC Fast benchmarks: what the numbers look like at the arbitrage workload specifically

The chart below summarizes four metrics that determine whether an arbitrage bot is profitable on Solana, measured across ~500 arb cycles per infrastructure tier on the major SOL/USDC and SOL/USDT pairs across Raydium, Orca, Meteora, and Phoenix.

In practical terms—the gap between public RPC and dedicated infrastructure on arbitrage is the difference between an unprofitable strategy and a profitable one. The same logic running on RPC Fast captures 8x more profitable attempts than the same logic on public RPC, before any strategy tuning.

The infrastructure ceiling

A working arbitrage bot can be assembled in a weekend. A profitable one is a different problem—and it is almost entirely an infrastructure problem.

The bots at the top of the stack run on bare-metal EPYC servers colocated in the same data centers as high-stake validators. They receive Geyser updates before most RPC nodes even see the slot. They submit bundles to Jito and bloXroute in parallel, with dynamic tip calibration. They have 24/7 monitoring and automated failover.

"The logic is usually fine. What kills most bots is the RPC. They're reading stale state, submitting too late, and losing to searchers who built their setup around the validator, not around a cloud endpoint. When we tune a bot's infrastructure—dedicated bare-metal, Geyser feeds, parallel relay submission—the latency profile changes completely. That's where the edge actually comes from."

— RPC Fast / Dysnix team, based on tuning 100+ Solana trading bots in production

If your bot logic is solid and you're still losing consistently, the bottleneck is almost certainly your data feed or submission path—not the strategy. RPC Fast's dedicated infrastructure for Solana arbitrage bots includes bare-metal compute, Yellowstone gRPC, native Jito and bloXroute integration, and SWQoS-enabled transaction forwarding.

Two ways to run this on RPC Fast

You do not have to start on bare metal. Shared SaaS plans start at $0 with no card, and gRPC streaming opens up from the Stream plan onward.

Dedicated nodes start at $2,200/month — server, setup and maintenance included, delivered within 72 hours. No rate limits, and gRPC streaming plus SWQoS routing come with every tier.

Prove the route logic on a shared plan first. Move to dedicated when latency and rate limits, not the strategy, are what cap your fill rate.

Current plan limits and prices sit on the pricing page.