All articles
Solana·October 28, 2025·4 min read

Solana DEX Arbitrage Bots: Routing Across Raydium and Orca

How multi-hop route discovery and atomic same-block execution turn Solana AMM price gaps into consistent edge for a solana arbitrage bot.

Solana's throughput advantage means price discrepancies across AMMs are measured in milliseconds, not seconds. A solana arbitrage bot that can discover a profitable route, simulate it, and land it atomically inside the same block is a fundamentally different beast from the MEV bots that crawled Ethereum mempools two years ago. This guide walks through the core mechanics: route discovery, atomic execution, and the latency infrastructure that makes it viable.

Route Discovery Across Raydium and Orca

The first challenge is not finding a price difference — it is finding the best one fast enough to act on. Raydium operates a hybrid model: a CLOB order book anchored to OpenBook markets, combined with its own concentrated liquidity pools (CLMM). Orca runs Whirlpools, a Uniswap v3-style CLMM with configurable tick spacing. These differing price-curve shapes mean that for the same token pair, quoted prices can diverge meaningfully at any given slot.

A production solana arbitrage bot builds a directed graph where nodes are tokens and edges are pool accounts — Raydium CLMM, Raydium AMM v4, Orca Whirlpools, Meteora DLMM, and any others with sufficient liquidity. At each tick, the bot re-prices every edge using on-chain state fetched via a Geyser plugin stream rather than polling RPC. Geyser account notifications arrive in tens of milliseconds after commitment, which is the only realistic way to keep the graph current at Solana's slot cadence (approximately 400 ms per slot).

Multi-hop routes — say, SOL → USDC on Raydium, then USDC → mSOL on Orca, then mSOL → SOL on Meteora — can produce positive expected value even when simple two-pool arbitrage does not, because each leg's slippage profile differs. The bot runs Bellman-Ford or a modified Dijkstra pass over the graph after every relevant account update, searching for negative-weight cycles that represent gross profit above a dynamic threshold.

Simulation, Priority Fees, and Atomic Execution

Route discovery is cheap; the expensive question is whether the transaction will actually land profitably. Before sending anything on-chain, every candidate route goes through a local simulation against a snapshot of pool state. This catches:

  • Stale state risk — pool state changed between graph update and simulation.
  • Slippage blowout — thin liquidity on one leg wipes the projected profit.
  • Anti-rug checks — token mint authority or freeze authority flags that signal a honeypot.

Profitable simulations get packaged into a Jito bundle. Jito's block engine lets you submit an ordered, atomic set of transactions with a tip paid directly to the validator. If any transaction in the bundle fails, the whole bundle is dropped — no partial fills, no leaked losses. This atomicity guarantee is what makes same-block execution reliable rather than a gamble.

Priority fees sit on top: the bot computes a compute-unit price by back-testing recent landed-transaction fees against slot congestion data. Paying too little means the transaction misses the block; paying too much erodes margin. The fee model runs as a separate subprocess that updates every few seconds based on real-time mempool pressure observed through Jito's tip percentile feed.

See the Solana arb bot case study for a concrete example of how this stack performed across a live deployment on mainnet.

Kill-Switches, Inventory, and Operational Discipline

Even a well-calibrated bot needs guardrails. Inventory skew accumulates when one leg of a multi-hop route consistently fills better than another, leaving the bot long or short a non-USDC token. Hard position limits per token, combined with a soft rebalance trigger that widens the bot's acceptable route set to include unwinding trades, keep exposure bounded.

Kill-switches fire on three conditions: cumulative loss exceeding a session threshold, RPC or Geyser latency spiking above a configured ceiling, and on-chain program upgrades detected on any pool the bot touches. An upgrade authority change on a pool contract is an immediate halt signal — the risk of a rug or a parameter change that breaks simulation assumptions is too high to ignore.

Our trading-bot services cover the full stack from Geyser infrastructure through route-graph construction to bundle submission, so you are not building each layer from scratch. Latency between account update and bundle submission in a well-tuned setup sits under 50 ms end-to-end — the difference between catching a three-slot arb window and missing it entirely.


If you are building or scaling a solana arbitrage bot and want a team that has already navigated the Geyser integration, Jito bundle mechanics, and multi-AMM graph engineering, start a project with TierZero. We scope, build, and deploy — you keep the edge.

Need a bot like this built?

We design, build and run trading bots on Solana, Hyperliquid and Polymarket.

Start a project
#arbitrage#dex#solana