Solana RPC for Trading Bots: What You Need

Trading bots have the most demanding RPC requirements on Solana. Every millisecond of latency, every dropped transaction, and every missed update directly impacts profitability. This guide covers what matters and how to optimize.

Critical requirements

1. Staked connections

Stake-Weighted Quality of Service (SWQoS) gives staked validators priority when forwarding transactions. Without staked connections, your transactions compete for only 20% of a leader’s incoming bandwidth. This is the single most important factor for transaction landing rate.

What to check: Ask your provider whether your sendTransaction calls go through a staked connection. Not all plans include this — some providers reserve staked forwarding for premium tiers.

2. Low latency to validators

Transaction sending latency is measured from your RPC node to the current slot leader. The leader changes every 4 slots (~1.6 seconds), and your transaction must arrive before the leader rotates.

What to check: Where is the RPC node physically located? Nodes in US East (Virginia, New York) are closest to the majority of Solana validators. For an optimized setup, consider providers like Supanode that specialize in low-latency infrastructure.

3. Real-time data streaming

Polling for updates wastes time and requests. For trading, you need:

gRPC (Yellowstone): Subscribe to account changes, transactions, and blocks in real time. Latency is typically 50-200ms from slot confirmation.
WebSocket subscriptions: accountSubscribe, programSubscribe for real-time notifications. Higher latency than gRPC but simpler to implement.

4. No rate limits on critical paths

A rate limit hit during a time-sensitive trade means a missed opportunity. Ensure your plan allows burst traffic on sendTransaction and your data streaming endpoints.

Architecture for trading bots

┌─────────────────────────────────────────────┐
│                 Trading Bot                  │
├─────────────┬─────────────┬─────────────────┤
│  Data Feed  │   Compute   │  TX Sender      │
│  (gRPC)     │   (local)   │  (RPC)          │
└──────┬──────┴─────────────┴────────┬────────┘
       │                             │
       ▼                             ▼
  gRPC endpoint              sendTransaction
  (account updates,          (staked connection,
   block notifications)       multiple endpoints)

Separate read and write paths

Use different endpoints (or providers) for:

Reading data: gRPC stream or WebSocket for real-time, HTTP RPC for historical queries
Sending transactions: Dedicated endpoint with staked connections

This prevents read traffic from competing with transaction sending.

Send to multiple endpoints

Fan out sendTransaction to 2-3 providers simultaneously. Each provider has different network paths to validators, increasing the probability that at least one reaches the leader in time.

async function sendToMultiple(signedTx: string, endpoints: string[]) {
  const results = await Promise.allSettled(
    endpoints.map(async (url) => {
      const rpc = createSolanaRpc(url);
      return rpc.sendTransaction(signedTx, {
        encoding: "base64",
        skipPreflight: true,
        maxRetries: 0n,
      }).send();
    })
  );
  return results.find((r) => r.status === "fulfilled")?.value;
}

Optimization checklist

Area	Action
Preflight	Set `skipPreflight: true` — saves one RPC round-trip
Retries	Set `maxRetries: 0` on RPC, manage retries yourself
Priority fees	Dynamic fees from `getRecentPrioritizationFees` per account
Compute units	Simulate and set exact CU limit + small margin
Blockhash	Pre-fetch blockhash, refresh every 20-30 seconds
Jito bundles	Use Jito for MEV-sensitive transactions
Connection reuse	Keep HTTP connections alive, reuse WebSocket connections

Common mistakes

Using a shared RPC for trading. Shared nodes have unpredictable latency spikes from other users’ traffic.
Not using staked connections. The difference between staked and unstaked transaction forwarding is dramatic during congestion.
Polling instead of streaming. A getAccountInfo loop at 100ms interval is always slower than a gRPC subscription that pushes updates as they happen.
Single point of failure. One provider going down should not stop your bot. Always have fallback endpoints.

FAQ

Do I need a dedicated node for a trading bot? Not always. A premium shared plan with staked connections works for many bots. Dedicated nodes ($500-3,000/month) make sense when you need guaranteed throughput, custom configuration, or are running multiple bots.

How do I test transaction landing rate? Send 100 identical low-value transactions (e.g., memo program) during different congestion levels. Measure the percentage that confirm within 30 seconds. Compare across providers.

Should I use Jito for all transactions? Jito bundles are valuable when transaction ordering matters (MEV, arbitrage) or when you need atomic execution of multiple transactions. For simple trades with no ordering concerns, standard sendTransaction with priority fees is simpler and sufficient.

What latency should I target? For competitive arbitrage: under 50ms end-to-end. For swap bots: under 200ms. For DCA or scheduled trades: latency is not critical.

Sources

Updated: 2026-10-19