.jpeg)
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:

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=processedKey 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=5000000Arbitrage 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 + slackAlways 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:
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.

.jpg)
