Best Solana RPC for Trading Bots: Reproducible Latency Benchmark

Provider names alone do not determine the fastest Solana RPC for a trading system. Region, plan, method mix, connection reuse, burst limits and the path used to submit transactions can change the result. This guide provides a reproducible way to compare endpoints from the same machine that will run your software.

Methodology note: TierZero does not publish provider rankings from unverifiable or synthetic numbers. Run the harness below against your own endpoints and save the raw output with the date, region, plan and Solana commitment level.

What to measure

For trading infrastructure, a single average latency number hides the failures that matter. Record:

• p50, p95 and p99 response time for each RPC method;
• error and HTTP 429 rates during a controlled burst;
• WebSocket disconnects and missed slot notifications;
• freshness, by comparing the returned slot with an independent reference;
• transaction acknowledgement and landing, measured separately;
• geographic location and test time, because routing and congestion change.

Do not put production private keys in a benchmark. Read methods need no signer. For transaction tests, use a dedicated low-value test wallet and a clearly defined budget.

Minimal Node.js latency harness

The following script tests read latency without sending transactions. Use Node.js 20 or newer and provide endpoints through environment variables.

```js const endpoints = Object.entries(process.env) .filter(([key]) => key.startsWith("RPC_")) .map(([name, url]) => ({ name, url }));

const samples = Number(process.env.SAMPLES || 100); const timeoutMs = Number(process.env.TIMEOUT_MS || 5000);

async function rpc(url, method, params = []) { const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), timeoutMs); const started = performance.now(); try { const response = await fetch(url, { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }), signal: controller.signal, }); const body = await response.json(); if (!response.ok || body.error) throw new Error(body.error?.message || String(response.status)); return { ms: performance.now() - started, slot: body.result?.context?.slot, ok: true }; } catch (error) { return { ms: performance.now() - started, ok: false, error: String(error) }; } finally { clearTimeout(timer); } }

function percentile(values, p) { const sorted = [...values].sort((a, b) => a - b); return sorted[Math.min(sorted.length - 1, Math.floor(sorted.length * p))]; }

for (const endpoint of endpoints) { const results = []; for (let i = 0; i < samples; i++) { results.push(await rpc(endpoint.url, "getLatestBlockhash", [{ commitment: "processed" }])); } const ok = results.filter((r) => r.ok); const times = ok.map((r) => r.ms); console.log(JSON.stringify({ endpoint: endpoint.name, samples, successRate: ok.length / results.length, p50Ms: percentile(times, 0.50), p95Ms: percentile(times, 0.95), p99Ms: percentile(times, 0.99), })); } ```

Example invocation:

```bash RPC_HELIUS="https://..." RPC_QUICKNODE="https://..." RPC_TRITON="https://..." SAMPLES=200 node rpc-benchmark.mjs ```

How to run a fair comparison

Run every endpoint from the same host, in the same process and during the same time window. Warm up connections first. Randomize provider order so the first endpoint is not always tested under different conditions. Repeat during normal traffic and during congestion, and retain the raw JSON rather than copying only the best result.

Use identical methods and commitment levels. A `processed` request cannot be compared fairly with a `confirmed` request. Separate cached reads such as `getLatestBlockhash` from expensive account scans. A provider that is fast for one method may enforce different limits for another.

Helius, QuickNode, Triton or a self-hosted node?

The correct choice depends on the workload:

Option	Evaluate closely	Often suitable for
Helius	plan limits, enhanced APIs, regional latency	Solana applications that benefit from managed data APIs
QuickNode	selected region, add-ons, burst policy	multi-chain teams wanting one managed platform
Triton One	dedicated capacity and streaming requirements	Solana-focused workloads and Yellowstone gRPC
Self-hosted Agave	hardware, operations, peering and data completeness	teams needing full control and able to operate validators

This is a selection framework, not a universal ranking. Test the exact paid plan you intend to use. Free endpoints are useful for development but usually have different limits and routing.

WebSocket and Yellowstone gRPC tests

HTTP latency does not predict streaming quality. For WebSocket, record slot-notification arrival times, reconnect count and subscription restoration. For Yellowstone gRPC, record stream lag, message gaps, filter configuration and backpressure. Our Yellowstone gRPC vs WebSocket comparison explains the architectural differences.

Transaction submission requires a separate experiment

`sendTransaction` returning quickly only proves that the RPC accepted the request. It does not prove inclusion. Track the signature until it is processed, confirmed, expired or dropped. Record priority fees, blockhash age, retries and the submission path. For bundle-based flows, evaluate the relay separately from the RPC endpoint.

Never describe a provider as profitable based on latency alone. Infrastructure can reduce avoidable delay and failure rates, but strategy quality, fees, competition and market conditions determine trading outcomes.

A practical production design

Production systems commonly use at least two independently monitored endpoints:

1. a primary endpoint for reads and subscriptions;
2. a fallback from a different provider or failure domain;
3. health scoring based on error rate, tail latency and slot freshness;
4. circuit breakers that stop sending when data is stale;
5. structured logs that connect quotes, decisions, submissions and confirmations.

TierZero builds client-owned blockchain infrastructure and indexer software, monitoring and failover logic. If you need a benchmark designed around your workload, describe the methods, region and expected request rate.