Solana arbitrage bot setup: a practical guide

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:

RPC_ENDPOINT=https://your-dedicated-rpc-endpoint
RPC_WEBSOCKET=wss://your-dedicated-rpc-endpoint
GEYSER_RPC=grpc://your-geyser-endpoint:10000
JITO_BLOCK_ENGINE=ny.mainnet.block-engine.jito.wtf
COMMITMENT=processed

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:

const subscribeRequest = {
  accounts: {
    raydium_sol_usdc: {
      account: ['POOL_ACCOUNT_ADDRESS'],
      filters: []
    }
  },
  commitment: CommitmentLevel.PROCESSED
};

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.

JITO_MODE=true
JITO_FEE=0.0003           # base tip in SOL
FEE_LEVEL=5               # priority fee multiplier
MAX_JITO_TIP_LAMPORTS=5000000

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

SLIPPAGE=10              # max slippage in basis points (0.1%)
PROFIT_LEVEL=10          # minimum profit threshold in BPS
MIN_PROFIT_ONCHAIN=5     # on-chain profit check—reverts if below
MAX_ACCOUNTS=25          # Solana tx limit = 60 accounts; 25 per side + slack

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.

Step 6: Test before mainnet

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

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.