By late 2025, 50% of all DEX trading volume on Solana came from arbitrage bots and on peak days that figure climbed to 70%. Solana's total on-chain spot volume hit $1.6 trillion in 2025, and a large share of that runs through automated systems.

A human trader looking at two DEX prices and deciding to arbitrage them is not a strategy—it's a nostalgia exercise. By the time you spot the gap, construct the transaction, and hit submit, the price has corrected, someone else's bundle has landed, and you've paid fees for nothing.

The agents running these strategies work in a completely different time frame. They detect, compute, and execute within a single Solana slot—400 milliseconds. Some operate in less than 50ms from signal to transaction broadcast. This is not a matter of being faster with a keyboard. It's a matter of architecture.

This article breaks down exactly how those agents work: the types of arbitrage they run, the execution flow from signal to settlement, the infrastructure stack they depend on, and why most attempts fail before they find a single profitable trade.

What arbitrage means on Solana

Arbitrage is the practice of exploiting price differences for the same asset across different venues. In traditional finance this happens across exchanges, over seconds or minutes. On Solana, it happens across DEX pools, within a single block.

Solana's design makes it uniquely suited to arbitrage. The network produces a block every 400ms, transaction fees are fractions of a cent, and hundreds of liquidity pools for the same token pairs exist across Raydium, Orca, Meteora, Phoenix, and dozens of smaller AMMs and prop-AMMs. Every time a large swap hits one of these pools, it moves the price. That price difference persists until another transaction corrects it—typically within one to two slots.

The agent's job is to be that correcting transaction. Detect the discrepancy, compute whether the trade is profitable after fees and tips, construct and submit the transaction before any other agent does the same thing.

Key fact: Solana processed ~70 million transactions per day and over $143B in monthly DEX volume as of October 2025 (CryptoSlate / DefiLlama). The majority of that activity involves automated systems reacting to pricing events faster than any human can.

Types of arbitrage AI agents run

Not all arbitrage is the same. The strategy type determines the latency requirement, the infrastructure needed, and the competitive landscape the agent operates in.

Atomic and cyclic arbitrage dominate Solana by volume. These strategies execute entirely within a single transaction—if the trade is unprofitable at execution time, the transaction reverts and the only cost is the compute fee. This atomic guarantee makes the strategy safe to run at high frequency: the agent fires whenever it sees an opportunity, and failed attempts cost almost nothing.

Latency arbitrage is the most competitive tier. It depends entirely on seeing the triggering trade before most other agents and submitting a response transaction in the same or next slot. This is where infrastructure becomes the primary competitive variable.

The arbitrage execution flow

Here is the full lifecycle of a competitive arbitrage trade on Solana, from signal to settlement:

Step 1: data ingestion

The agent subscribes to relevant AMM program accounts via Yellowstone gRPC. Unlike polling over JSON-RPC, gRPC streams push account state updates directly from validator memory the moment they change—latency under 50ms from state change to agent notification.

For the most competitive strategies, agents connect directly to Jito ShredStream. ShredStream delivers block data at the shred level—fragments of transactions before they assemble into a full block. This gives the agent a 50–100ms head start over gRPC alone, seeing incoming swap activity before it confirms.

Step 2: opportunity detection

The agent maintains an in-memory model of current pool states. When a new account update arrives, it recalculates the effective price across all relevant pools for the target token pair. If the price difference exceeds the minimum profitable threshold—accounting for swap fees, compute costs, and Jito tip—the agent flags an opportunity.

This computation runs in microseconds for simple two-pool routes. Triangular routes across three pools require slightly more computation but still complete well under 1ms on optimized code.

Step 3: transaction construction

The agent constructs the arbitrage transaction: the sequence of swap instructions that executes the route, a ComputeBudget instruction setting the priority fee, and a Jito tip instruction if submitting via bundle.

Priority fees matter here. The ComputeBudgetProgram.setComputeUnitPrice instruction tells the validator how much the agent will pay per compute unit. Too low and the transaction gets deprioritized under congestion. Calibration is an ongoing process—most production bots target the 75th–90th percentile of recent priority fees for the same program.

Step 4: submission via Jito bundle

Most competitive arbitrage agents submit via Jito bundles rather than standard sendTransaction. A bundle is a group of transactions that execute atomically in order—critical for strategies that need to guarantee execution sequence.

The agent sends the bundle to multiple Jito Block Engine endpoints in parallel—US East, EU, Tokyo—because different validators are geographically closer to different endpoints on any given slot. The Jito tip (typically 50–60% of expected profit) compensates the validator for including the bundle and determines priority among competing bundles.

Step 5: confirmation and logging

The agent monitors confirmation via getSignatureStatuses with processed commitment—not confirmed or finalized, which add unnecessary latency. On a successful execution, it logs the route, profit, tip paid, and slot delta. On failure, it logs the reason for use in tip calibration.

The full flow from ShredStream signal to bundle submission runs under 50ms on well-optimized setups. From there, the transaction sits in the Jito mempool waiting for the next leader slot—typically under 400ms additional wait.

Why most arbitrage AI agents fail

The mechanics are well-documented. Jito publishes its infrastructure. Yellowstone gRPC is open source. Solana's RPC methods are public. Yet the overwhelming majority of arbitrage bots produce no profit or actively lose money. Here is why.

Wrong commitment level

Using confirmed or finalized commitment instead of processed adds 400–800ms of unnecessary latency to every data update. Arbitrage windows close in one to two slots. An agent running on confirmed commitment is structurally too slow before it even evaluates the first opportunity.

Public RPC in production

Public endpoints apply rate limits during congestion events—exactly when the most lucrative opportunities appear. A token launch, a liquidation cascade, a large market order: all of them spike RPC traffic at the same time they create pricing inefficiencies. An agent that hits a rate limit during these events misses every opportunity they generate.

WebSocket instead of gRPC

WebSocket subscriptions are easier to set up but carry higher latency and lower stability than Yellowstone gRPC. Account updates arrive later, subscriptions drop during heavy load, and reconnection takes seconds. For strategies where the window is one slot, a WebSocket that takes 3 seconds to reconnect is functionally down during the most active periods.

Tip calibration failure

Arbitrage bots compete directly against each other in Jito's bundle auction. A tip that's too low results in bundle deprioritization—other agents' bundles land instead. Most new bots set tips too conservatively and wonder why their bundles never confirm. The standard starting point: 50% of estimated profit, adjusted based on observed bundle acceptance rate.

No colocation

The physical distance between the agent's server and the current Solana leader adds latency that no software optimization can eliminate. An agent running in a cloud region 200ms from the nearest validator loses that 200ms on every submission—enough to miss a one-slot window entirely.

Latency = profit: the numbers

Every millisecond of latency removed from the execution pipeline has a direct effect on opportunity capture rate. Here is how the components stack up:

The cumulative difference between a public shared endpoint and a dedicated colocated node with ShredStream can exceed 300–400ms on the full pipeline. For strategies with a one-slot window, that difference is binary: the agent either competes or it doesn't.

Data layer: what AI agents need

An arbitrage agent's data requirements are more specific than a general RPC consumer. Here's what the data layer must provide:

• Real-time AMM pool states: reserve balances, fee parameters, tick data for concentrated liquidity pools. These change with every swap and must arrive within one slot to be useful.
• Leader schedule: the agent needs to know which validator produces the next block so it can route transactions to the correct TPU address. getLeaderSchedule should run at epoch start and refresh every few hundred slots.
• Recent blockhash: every transaction requires a fresh blockhash. Stale blockhashes cause immediate transaction rejection. The agent polls getLatestBlockhash on a tight loop—typically every 2–3 seconds.
• Priority fee oracle: recent priority fees for the target programs, used to calibrate ComputeUnitPrice. getRecentPrioritizationFees provides this directly.
• Bundle confirmation feedback: Jito provides bundle status APIs. The agent uses this to monitor tip effectiveness and adjust calibration in real time.

All of this requires a data connection that stays alive, delivers updates within one slot, and doesn't rate-limit during the exact conditions—high network activity—when the data is most critical.

Infrastructure stack for arbitrage agents

Here is the full infrastructure stack that production arbitrage agents on Solana run in 2026:

Why RPC Fast fits this stack

The infrastructure layer in that table—dedicated bare-metal nodes, Jito ShredStream, Yellowstone gRPC, SWQoS paths, automated failover—describes exactly what RPC Fast provides for production arbitrage agents on Solana.

RPC Fast nodes run on bare metal colocated with Solana validators. ShredStream comes enabled by default on dedicated plans, not as an add-on. Yellowstone gRPC delivers structured account streams with filtered subscriptions so the agent only processes the pool accounts it actually monitors. SWQoS transaction paths give bundles priority routing to the leader under congestion. Failover completes in under 50ms automatically—no manual intervention, no dropped windows.

On dedicated nodes, getLatestBlockhash returns in under 4ms. Transaction propagation runs under 100ms. There are no RPS limits—the agent submits as frequently as the strategy requires, without hitting a ceiling during the high-traffic events that generate the most opportunities.

SaaS tiers provide the same ShredStream and gRPC access at lower scale, with a direct upgrade path to dedicated nodes when the strategy proves out and volume justifies the investment.