Building a Solana Arbitrage Bot — RPC, Latency, and the Parts That Actually Matter | BoltTx Blog

Most arbitrage bots on Solana don't lose money to bad logic. They lose to the gap between "I detected the opportunity" and "my transaction landed." That gap is almost always RPC and validator-side mechanics, not the trading code. If you're building a bot — or you've built one and the numbers aren't lining up — this is the part of the stack that's usually doing the most damage to your P&L.

This piece walks through what actually makes a Solana arbitrage bot profitable, how the RPC layer affects you, and what to look at when you're debugging a bot that should be working but isn't.

What Solana Arbitrage Actually Looks Like

The textbook definition is: same asset, different price across two markets, take the spread. On Solana that usually means token X has different prices on Raydium and Orca, or across a Jupiter route and a direct AMM swap. The bot detects the divergence and submits a swap path that captures the difference.

The implementation reality is messier. By the time you've detected the opportunity, computed the path, and submitted the transaction, the price has often already moved. Solana's block time is fast enough that the half-life of an arbitrage opportunity is sometimes a single slot. That's why latency matters so much more here than in something like a buy-and-hold bot.

The Three Parts of a Solana Arbitrage Bot

If you strip the architecture down, every working bot has three components:

1. Market data ingestion. You need real-time pool state — reserves, fees, tick liquidity for concentrated AMMs. Most teams either consume RPC streaming subscriptions or poll RPC accounts. Polling is simpler; streaming is faster but more work to set up correctly.

2. Path computation. Given current state, where is the opportunity? Two-hop is the easiest case. Multi-hop through Jupiter routes is where the harder math is, but also where the harder competition is.

3. Transaction submission. This is where most bots quietly bleed. You computed a profitable path; getting that transaction landed before the opportunity disappears is a different problem.

People who are new to this overweight (1) and (2). People who have actually run bots in production overweight (3).

Why the RPC Layer Decides Your P&L

Once you've identified an opportunity, your transaction is racing. Other bots saw the same signal. The first to land captures most of the spread; everyone else either loses money on fees or eats slippage on a price that's already moved.

The properties that matter at this stage:

End-to-end submission latency. From "I called sendTransaction" to "the validator producing the next block has my transaction." Every additional millisecond is a slot you're more likely to lose.
SWQoS (stake-weighted QoS) routing. The network prioritises RPCs that route through SWQoS paths. An RPC without SWQoS support loses badly under congestion — exactly when arbitrage opportunities cluster.
Anti-MEV / private routing. If your transaction passes through any path that's observable to bots, you'll get sandwiched on profitable swaps.
Predictable tail behaviour. Average latency is irrelevant. You care about P95 and P99, because the worst-case cases are the ones you're trying to hit.

A "fast" RPC that has good averages but degrades at the 95th percentile during congestion is, for an arbitrage bot, indistinguishable from a slow RPC. The opportunities you're chasing are exactly the ones happening during congestion.

Common Failure Modes

Things we've seen actually kill bot P&L, in rough order of frequency:

Transaction not landing in time. You submitted; by the time a slot included it, the path was no longer profitable. Symptom: a lot of "successful" transactions with negative or near-zero profit.

Sandwiched. A bot front-ran your swap, you executed at the inflated price, they back-ran. Symptom: profitable in dry-run, breakeven or worse in production.

Stale state. You detected the opportunity using state that was already a slot or two old. By the time you submitted, the AMM had already been rebalanced. Symptom: a lot of failed transactions due to slippage limits.

Compute unit exhaustion. Multi-hop routes through concentrated AMMs eat compute. The classic offenders are Raydium AMM v4 (sometimes searched as just "raydium v4"), Raydium CLMM, and Orca Whirlpool. If you under-budget CUs, the swap fails partway. Symptom: ~200k CU transactions failing where ~300k would have succeeded. Also factor in raydium fees (and the equivalent on whatever DEX you're routing through) when sizing position economics.

Blockhash expiry under retry. You retried too many times with the same blockhash; by the third retry it was expired. Symptom: transactions silently dropping after retries.

The first two — landing time and sandwiching — are RPC-layer problems. The rest are bot-side, but they amplify the RPC problems.

Priority Fee and Jito Tip Strategy: Higher Isn't Always Better

The two levers that get your transaction prioritised on Solana are the on-chain priority fee and the optional Jito tip. The naive strategy is "always max it out." This doesn't work for arbitrage bots because:

The expected value of paying max on every attempt rarely beats paying it only when the opportunity justifies it.
Bidding aggressively on every attempt makes your P&L noisier — you eat the priority fee on losing attempts too.
There's a ceiling effect. Once you've outbid the second-place bot, additional fee is wasted.

A better strategy: adjust the priority fee dynamically based on expected profit. If the spread is large, bid aggressively. If it's marginal, bid just above the floor and let the trade fail if it doesn't land cheaply. This requires knowing where the floor is — which means you need real-time priority fee telemetry.

What to Do This Week If You're Bot Building

A short, practical sequence for someone who has the trading logic working and is debugging the execution stack:

Measure your end-to-end submission latency. From sendTransaction to "transaction landed in slot N." If you don't have per-signature telemetry, you can't fix this.
Audit your tail behaviour. What does P95 look like during peak hours? If it's worse than during off hours, you have an RPC capacity problem.
Check for sandwich exposure. Compare your AMM-math expected output against actual fills. The gap is your sandwich tax.
Profile compute unit usage. Multi-hop swaps frequently under-budget CU. Test with realistic worst-case routes.
Don't tune retries up. Past two retries you're usually expiring blockhashes. Retries are a band-aid for a slow submission path; fix the path.

If you've done all five and your bot is still bleeding on execution, the question is whether your RPC layer is actually built for this workload. Most general-purpose Solana RPCs are not.

What BoltTx Does for Arbitrage Bots

BoltTx is built for transaction-sending workloads where the difference between landing in slot N and slot N+1 is real money. Specifically:

Sub-second confirmation as the design floor, with documented P95 behaviour
Native Anti-MEV routing — your swaps don't pass through observation surfaces bots scrape
SWQoS-aware delivery so transactions land during the exact moments arbitrage opportunities cluster
Per-signature telemetry — for any specific transaction you submitted, when it was received, when it was relayed, whether it landed
Tip-based pricing — you only pay on landed transactions, not on every attempt

Drop-in integration is one URL change:

import { Connection } from "@solana/web3.js";

const connection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

const signature = await connection.sendTransaction(tx, signers, {
  skipPreflight: true,
  maxRetries: 0,
});

Run a week of real bot traffic against the free tier and compare your landing rate, your sandwich exposure, and your P95 confirmation latency against your current setup. The data is the answer.

FAQ

What's the minimum spread an arbitrage bot needs to be profitable? Depends on your fee structure, your priority fee strategy, and how often the path is contested. Marginal bots target 30-50 basis points; serious ones target much wider spreads on less-watched pairs. The execution stack determines what spread you can actually capture.

Should I run my own validator for arbitrage? For most teams, no. The operational cost is high and the validator-side income is uncorrelated with arbitrage P&L. A managed RPC with strong SWQoS support gets you most of the benefit without the ops burden. See our enterprise guide for the full reasoning.

How does BoltTx compare to running my own RPC node? Self-hosting a Solana RPC node for arbitrage is operationally expensive — bare metal, NVMe, multi-gig uplinks, 24/7 ops. Most teams that try it walk it back within a year. A managed RPC with the right architecture is dramatically more cost-effective per landed transaction.

Does Anti-MEV protection slow down my transactions? On the path BoltTx uses, no. The protection is at the routing layer, not an extra confirmation step. Your transactions go through a non-observable path; speed is unchanged.

What about multi-hop arbitrage routes? Same principles, more compute units, and more places for the path to break under price movement. Budget your CU realistically (test with worst-case prices) and keep your blockhash fresh.