Fastest Solana RPC: How to Measure and Choose

How to decide which Solana RPC is fastest for you

"Fastest" is not a fixed property of an endpoint. It is a measurement that depends on four things:

1. Where your app runs. A node in the same region as your servers will usually beat a node on the other side of the world.
2. Which methods you call. getLatestBlockhash and sendTransaction behave very differently from getProgramAccounts or getSignaturesForAddress over a long range.
3. Whether you need WebSocket. Streaming slotSubscribe or logsSubscribe has different latency characteristics than one-off HTTP calls.
4. Whether you share the endpoint. Shared RPC pools absorb traffic from many users; a dedicated node gives your workload its own capacity.

A quick way to decide:

Your situation	What to try first
Prototyping, low traffic, no strict latency target	Shared Solana RPC over HTTPS
Trading bot or wallet that needs fresh blockhashes fast	Shared RPC, then benchmark from your region
High request volume, heavy getProgramAccounts or log queries	Dedicated Solana node
Real-time subscriptions (slots, logs, account changes)	Endpoint with WebSocket support
Compliance or isolation requirements	Dedicated node you control

If you are not sure yet, start on a shared endpoint, measure, and only move to dedicated capacity when the numbers justify it. OnFinality offers both Solana RPC API access and dedicated nodes so you can make that transition without changing providers.

What actually makes a Solana RPC fast

Solana produces blocks roughly every 400 ms, so the network itself is not the bottleneck for most apps. The latency you feel usually comes from the path between your code and the validator or RPC node that answers your request.

Key factors:

• Geographic distance. Round-trip time is dominated by physical distance. A request from Frankfurt to a node in Tokyo adds tens of milliseconds before any processing happens.
• Node health and load. A node that is behind on the tip or saturated with requests will respond slowly regardless of distance.
• Method cost. Light methods like getBalance return quickly. Heavy methods like getProgramAccounts scan a lot of state and can take much longer.
• Connection reuse. Establishing a new TLS connection per request adds overhead. Keep-alive and connection pooling matter.
• WebSocket vs HTTP. Subscriptions push data to you, which can be faster than polling, but they require a stable connection and reconnect logic.

This is why "fastest Solana RPC" lists that only name providers are not very useful. The right question is: fastest for which methods, from which region, at what volume?

Benchmarking Solana RPC latency from your own environment

Do not trust a latency number measured from someone else's machine. Measure from where your app actually runs.

A simple HTTP timing loop using curl:

# Replace with your own endpoint (shared or dedicated)
ENDPOINT="https://solana.api.onfinality.io/public"

for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{time_total}\n" \
    -X POST "$ENDPOINT" \
    -H "Content-Type: application/json" \
    -d '{"jsonrpc":"2.0","id":1,"method":"getLatestBlockhash","params":[{"commitment":"confirmed"}]}'
done

Run this from each candidate region and compare the distribution, not just the average. Look at the median and the tail (p95, p99), because tail latency is what hurts trading bots and user-facing wallets.

For a more realistic test, benchmark the methods your app actually calls:

# Heavier method: measure separately
curl -s -o /dev/null -w "%{time_total}\n" \
  -X POST "$ENDPOINT" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getSlot","params":[{"commitment":"processed"}]}'

A JavaScript version using fetch and performance.now():

const endpoint = "https://solana.api.onfinality.io/public";

async function timeCall(method, params = []) {
  const start = performance.now();
  const res = await fetch(endpoint, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  await res.json();
  return performance.now() - start;
}

(async () => {
  const samples = [];
  for (let i = 0; i < 20; i++) {
    samples.push(await timeCall("getLatestBlockhash", [{ commitment: "confirmed" }]));
  }
  samples.sort((a, b) => a - b);
  console.log("median ms:", samples[Math.floor(samples.length / 2)].toFixed(1));
  console.log("p95 ms:", samples[Math.floor(samples.length * 0.95)].toFixed(1));
})();

Run the same script against every endpoint you are considering, from the same machine, at the same time of day. Repeat at peak and off-peak hours.

Shared RPC vs dedicated Solana nodes

Once you have numbers, the next decision is whether a shared endpoint is enough or you need dedicated capacity.

Dimension	Shared Solana RPC	Dedicated Solana node
Setup effort	Connect and go	Provisioning and configuration
Cost model	Usage-based, lower entry point	Fixed capacity, predictable for high volume
Latency under load	Varies with other tenants	Consistent for your workload
Heavy methods (getProgramAccounts, log ranges)	May be limited or slower	Sized to your needs
WebSocket subscriptions	Supported on shared endpoints	Supported, with your own connection budget
Isolation	Shared infrastructure	Isolated to your project
Best for	Prototypes, wallets, moderate traffic	Trading systems, indexers, high-throughput apps

OnFinality's RPC API service covers shared access, and dedicated nodes give you isolated capacity when shared performance is not enough. Check RPC pricing for how the two models compare for your volume.

Chain settings and connection details

For Solana mainnet, the standard connection details are:

Setting	Value
Chain name	Solana Mainnet
Native currency	SOL (9 decimals)
HTTP RPC	https://solana.api.onfinality.io/public
WebSocket RPC	wss://solana.api.onfinality.io/public-ws
Block explorer	https://explorer.solana.com

A wallet or app network config in JavaScript:

const solanaMainnet = {
  name: "Solana Mainnet",
  rpcUrl: "https://solana.api.onfinality.io/public",
  wsUrl: "wss://solana.api.onfinality.io/public-ws",
  explorer: "https://explorer.solana.com",
  nativeCurrency: { name: "SOL", symbol: "SOL", decimals: 9 },
};

If you are testing before mainnet, use Solana Devnet and request an airdrop from the devnet faucet through your Solana CLI or wallet. Devnet endpoints are separate from mainnet and should not be used for production traffic.

WebSocket subscriptions and why they matter for latency

Polling getSlot or getLatestBlockhash in a tight loop wastes requests and still leaves you behind the tip. Subscriptions push updates as they happen.

// Using the ws endpoint for slot updates
const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "slotSubscribe",
    params: [],
  }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.method === "slotNotification") {
    console.log("new slot:", data.params.result.slot);
  }
};

WebSocket connections need reconnect logic and heartbeat handling. If your app cannot tolerate dropped connections, keep an HTTP fallback for critical reads like blockhash retrieval before sendTransaction.

Common failure modes when chasing Solana RPC speed

• Stale blockhash. If your RPC is behind the tip, sendTransaction fails with an expired blockhash. Fetch a fresh one immediately before signing.
• Rate limiting on shared endpoints. Heavy polling or large getProgramAccounts calls can hit limits. Batch requests or move to dedicated capacity.
• Wrong region. A fast provider in the wrong region is slow for you. Always benchmark from your own infrastructure.
• Ignoring tail latency. A good median with a bad p99 will still cause timeouts. Track both.
• No failover. If your only endpoint has an incident, your app stops. Configure a secondary endpoint and health checks.

A minimal monitoring probe you can run on a schedule:

#!/usr/bin/env bash
ENDPOINT="https://solana.api.onfinality.io/public"
START=$(date +%s%3N)
RESP=$(curl -s -X POST "$ENDPOINT" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getHealth"}')
END=$(date +%s%3N)
echo "latency_ms=$((END-START)) response=$RESP"

Alert when latency crosses a threshold or when getHealth stops returning ok.

Key Takeaways

• "Fastest" Solana RPC is a measurement, not a label. Benchmark from your own region against the methods you actually call.
• Shared endpoints are fine for prototypes and moderate traffic; dedicated nodes give consistent latency and isolation for high-volume or heavy-method workloads.
• Use WebSocket subscriptions for real-time data, but keep HTTP fallbacks for critical writes.
• Watch tail latency (p95, p99), not just the average.
• Always configure a secondary endpoint and monitor health so a single incident does not take down your app.
• OnFinality provides Solana RPC API access and dedicated node infrastructure; see supported RPC networks and RPC pricing for details.

Frequently Asked Questions

Is there one Solana RPC endpoint that is always the fastest?
No. Latency depends on your region, the methods you call, and endpoint load. Measure from your own environment.

Do I need a dedicated Solana node?
Only if shared endpoints cannot meet your latency, volume, or isolation needs. Start shared, benchmark, then scale up.

Does OnFinality support Solana WebSocket?
Yes. The Solana mainnet endpoint supports HTTP and WebSocket transports. See the Solana network page for connection details.

How do I test Solana RPC speed quickly?
Run a short curl or fetch loop against each candidate endpoint from the same machine and compare median and p95 latency.

What about devnet?
Use Solana Devnet for testing and the mainnet endpoint for production. Do not mix them.

Where can I compare provider options?
See how to choose an RPC provider for evaluation criteria, and RPC pricing for cost models.

Related resources

• Solana RPC network
• RPC pricing
• Dedicated nodes
• How to choose an RPC provider

Originally published at OnFinality.