BotTx

Trading Bot RPC Requirements — Why Latency Matters and What to Look For

What RPC properties actually decide trading bot profitability. Latency, tail behaviour, MEV protection, and the operational realities that don't show up on marketing pages.

BoltTx Team··8 min read
solanatrading-botrpclow-latencyhftinfrastructure

If you're running or building a trading bot on Solana, the RPC layer is doing more to determine your P&L than you probably think. Most bot operators pick an RPC the way they pick a coffee shop — based on convenience, brand recognition, or what their friend uses. Then they spend months optimising their trading logic without realising the execution stack is the actual constraint.

This piece walks through what trading bot RPC requirements actually look like, why the obvious metrics aren't the right ones, and what to evaluate when you're deciding what to run on.

The Obvious Metric and the Real Metric

The metric most people quote when comparing RPCs is average latency. As in: "this RPC has 200ms average confirm time." For trading bots, this is roughly the wrong metric to focus on.

The metric that actually matters is tail latency under load. Specifically:

Why? Because the moments your bot most needs to execute well are the moments the network is most congested. Memecoin launches happen during congestion. Arbitrage opportunities cluster during congestion. Sandwich victims swap during congestion. If your RPC's average is great but its P95 collapses during the exact moments that matter, you have an RPC that looks good in benchmarks and bad in production.

A bot operator we talked to once described it: "Our RPC was 200ms average. We were losing money. Then we measured P95 during the hours we were actually trading and it was 4 seconds. The 200ms average was averaging in 100ms during dead hours."

What Actually Matters

The properties that decide bot P&L, in rough order of importance:

Sub-second confirmation as a design floor, not an average. "Sub-second on average" means half your transactions are slower than that. You want sub-second as the floor — the worst-case behaviour, not the typical case.

SWQoS (stake-weighted QoS) routing. The Solana network prioritises RPCs that route through SWQoS paths. An RPC without SWQoS support degrades dramatically under congestion. This is invisible if you've never looked but decisive when load matters.

Native Anti-MEV routing. Every directional bot is a sandwich target. Without RPC-level protection, you're paying 5-30 bps per swap to MEV operators, compounding across every trade. This single property often makes the difference between profitable and unprofitable.

Per-customer isolation. Your traffic should not be at the mercy of another customer's bad day. Multi-tenant RPCs without isolation share latency profiles across customers, meaning you can degrade because someone else's volume spiked.

Per-signature delivery telemetry. For any specific transaction you submitted, when was it received, when was it relayed, when did it land (or why didn't it). Without this, you can't debug failures.

Predictable behaviour during congestion. Some RPCs handle 10x normal load gracefully. Others fall over. The only way to know is to test against your actual peak traffic profile.

Stable connection handling. HTTP keepalive, fast TLS handshake, predictable reconnect behaviour. Sounds basic; many RPCs do it badly. Bots that reconnect on every transaction are paying connection setup latency on every transaction.

The properties that don't matter as much as people think:

How to Actually Evaluate an RPC

Don't trust marketing numbers. The only valid evaluation is: run your own workload, measure the metrics you care about, compare.

A practical evaluation protocol:

  1. Set up parallel tracking. Configure your bot to submit duplicate transactions to two RPCs simultaneously (or alternating). This means you can compare landing time on the same trades.
  2. Measure during the hours that matter. Don't run benchmarks during off-peak when everything looks fine. Measure during peak congestion.
  3. Track P50, P95, P99. Not just average. The whole distribution.
  4. Compare effective fills. Not just latency — the actual prices you got. This catches sandwich exposure that pure latency metrics miss.
  5. Run for a week. Single-day measurements have too much noise; you need a sample size.
  6. Compare cost per landed transaction. Some RPCs are cheap per request but expensive per landed transaction (because of failures and retries).

A free tier should be enough to run this evaluation for a week without spending real money. If a provider's free tier isn't generous enough to evaluate, that's a signal about how they think about customer relationships.

RPC Requirements by Bot Strategy

Different strategies put different demands on the RPC:

Arbitrage bots: Latency-sensitive on the submission. SWQoS critical. Anti-MEV non-negotiable. Failed-transaction cost matters because of failed-attempt fee burn.

Sniper bots: Sub-second confirmation as a hard requirement. Detection latency more important than for most strategies (often need streaming data alongside the RPC). SWQoS critical.

Market makers: Cancel-replace cycles need predictable latency. P95 matters more than average. Anti-MEV important; ratio of failed cancels to successful matters.

Volume bots: Throughput more important than latency. Anti-MEV critical (every swap is a sandwich target). Failed-transaction cost important.

DCA bots: Latency low priority. Anti-MEV important. Reliability matters because the bot is unattended.

Copy trading bots: Submission latency directly determines arrival distance. Detection latency equally important.

The common requirement across all categories: Anti-MEV + per-signature telemetry. The first because every directional bot is a sandwich target; the second because debugging without it is impossible.

What to Do This Week

If you have a bot in production:

  1. Measure your tail latency during peak hours. Not average. P95 specifically. Compare against off-peak. If the gap is wide, your RPC is the bottleneck.
  2. Compare actual fills to AMM-math expected fills. The systematic gap is your sandwich tax. Quantify it.
  3. Audit your retry logic. More than two retries usually means you're expiring blockhashes silently. Most bots set this wrong.
  4. Test an alternative RPC in parallel. Free tiers exist; use them. Run for a week with parallel submission and compare.
  5. Talk to support. Send a real support ticket and time the response. Production RPC operators who don't have humans who answer in hours-not-days are not production-grade.
  6. Stop optimising trading logic until execution is right. The execution stack determines your floor. Optimising strategy on a bad floor is wasted effort.

What BoltTx Does for Trading Bots

BoltTx is built for the workload above. Specifically:

Drop-in is one URL change in existing Solana code:

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,
});

Free tier signup. Run real bot traffic against it for a week and compare. The economics of trading bots are determined by the execution stack; if BoltTx's profile is better for your workload, the data will tell you.

FAQ

What's the most important RPC property for trading bots? P95 confirmation latency during congestion, plus Anti-MEV routing. These two together determine the floor of what you can extract from any strategy.

How do I measure RPC quality? Run parallel submission to two RPCs on the same trades for a week. Compare P95 latency, effective fills, and landing rate. Don't trust marketing-page numbers.

Is "best RPC" the same as "most expensive RPC"? No. Pricing models vary; some "premium" RPCs aren't actually better for trading workloads, just more expensive. Evaluate on landing rate and effective fills, not price.

Should I use multiple RPCs for redundancy? Yes for read traffic. For sends, parallel submission to multiple RPCs duplicates transactions and creates settlement complications — not usually worth it. Pick the best one for sends.

Should trading bots use streaming subscriptions? For market-data ingestion, streaming subscriptions are useful. For transaction sending, you want HTTP RPC with the right routing properties. Different problems, different tools.

Further Reading

← Back to all posts