Solana arbitrage bot setup: a practical guide

Written by:

Maksym Bogdan

9

min read

Date:

March 12, 2026

Updated on:

June 30, 2026

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 (Q2 2026): 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:

Step What happens
1. State monitoring Bot maintains a live copy of DEX pool accounts locally. Subscribes via Geyser gRPC (Yellowstone)—account state arrives directly from validator memory, not RPC polling.
2. Route discovery Path-finding logic scans for price gaps across target DEX pools exceeding a configured profit threshold after fees and slippage.
3. Tx construction When a gap is found, both swap instructions (buy on DEX A, sell on DEX B) are bundled into a single atomic transaction.
4. Submission Sent via Jito bundle with a SOL tip, guaranteeing execution order within the block. Standard RPC used as fallback.
5. Settlement Bundle lands (profit captured) or reverts. If reverted, only the compute budget fee is lost—not the principal.
Visual representation of the 5-stage arbitrage bot pipeline with latency budget per stage.

Setup guide

Step 1: Choose your stack

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

Rust TypeScript
Latency Lower—compiled, no GC pauses Higher—runtime overhead
Dev speed Slower Faster to start
Key libraries solana-sdk, anchor-client, jito-searcher-client @solana/web3.js, jito-ts, @jito-foundation/mev-sdk
Best for HFT, sub-50ms latency targets Prototyping, mid-frequency strategies

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.

Skip the public-RPC trap.

RPC Fast gives Solana arbitrage bots production infrastructure on a SaaS plan—Yellowstone gRPC, Jito bundle routing, and sub-50ms slot lag. Plug in the endpoint URL and start landing trades.

→ Try RPC Fast

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:

Metric What to look for
Route detection latency Time from state update to opportunity identified—target under 50ms
Tx construction time Should be sub-10ms for competitive strategies
Bundle acceptance rate Track per block engine; low rate = tip too low or late arrival
Revert rate Above 30% signals latency issue, slippage misconfiguration, or route discovery bug

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.

Metric Public RPC Generic provider RPC Fast
Route detection latency 380 ms 110 ms 38 ms
Bundle landing rate ~24% ~71% ~96%
Revert rate 64% 41% 18%
Profitable attempts ratio 8% 32% 64%
Geyser gRPC streaming not available limited included
Multi-region BAM submission no partial yes
Suitable for production arb no marginal yes

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.

Got a bot that should be landing more?

Drop into the Dysnix Telegram chat—our team will look at your current setup and tell you exactly where the latency is leaking.

→ Talk to the Dysnix team on Telegram
Table of Content

The fastest Solana RPC for MEV, HFT, and AI agents

Private nodes with gRPC, raw streams, and sub-ms latency.

Test for free
More articles

Guide

All

Written by:

Maksym Bogdan

Date:

10 Jul 26

12

min read

Guide

All

Written by:

Olha Diachuk

Date:

07 Jul 26

8

min read

We use cookies to personalize your experience