Choosing an RPC Provider

An RPC provider gives your application an HTTP endpoint for requests and, usually, a WebSocket endpoint for subscriptions. The public Solana endpoints are useful for development, but production applications should use private RPC access with capacity and support that match their traffic.

Use the Solana RPC infrastructure directory to find current free, shared, and dedicated services. The directory changes as providers and their offerings change; this guide explains how to compare them.

Start with your workload

Measure or estimate the workload before comparing plans:

• clusters you need: Mainnet, Devnet, or Testnet
• peak requests per second, not only the daily average
• HTTP methods, WebSocket subscriptions, and concurrent connections
• response size and bandwidth, especially for account and block queries
• how far back you need transaction, signature, and block history
• where your users and backend services run
• whether you submit transactions, read data, or do both

A wallet balance view, an indexer, and a transaction service have different bottlenecks. Test with representative requests and response sizes instead of a single lightweight method.

Compare provider capabilities

Provider-specific APIs can be valuable, but keep the standard RPC boundary clear. That makes it easier to add a fallback or change providers later.

Check history and method support

Run the exact methods your application needs against a trial endpoint. These standard calls provide a useful first check:

RPC_URL="https://your-provider.example"

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"getVersion"}'

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"getHealth"}'

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"minimumLedgerSlot"}'

curl "$RPC_URL" \
  -H "content-type: application/json" \
  --data '{"jsonrpc":"2.0","id":1,"method":"getFirstAvailableBlock"}'

minimumLedgerSlot reports the lowest slot retained in the node's ledger, while getFirstAvailableBlock reports the lowest confirmed block slot that has not been purged. Neither alone guarantees that every historical method or transaction is available, so test a known old signature or block from your required range.

Also test error responses. Confirm how the service reports rate limiting, method restrictions, oversized responses, timeouts, and invalid API keys.

Measure latency and freshness

Latency includes network distance, provider routing, queueing, and the time needed to execute a method. Measure at least:

• median and tail latency, such as p95 and p99
• error and timeout rates at normal and peak load
• returned slot compared with another healthy endpoint
• time from sending a transaction to observing its signature status
• WebSocket reconnect time and missed-notification recovery

Run measurements from the same regions as the application. A fast response from a lagging node can still give users stale state.

Plan for failures

For production traffic, decide what happens when an endpoint becomes slow, rate-limited, stale, or unavailable.

1. Configure timeouts, bounded retries, and backoff with jitter.
2. Maintain at least one separately operated fallback for critical paths.
3. Health-check both availability and slot freshness before routing traffic.
4. Keep related blockhash, simulation, send, and confirmation operations on a healthy endpoint when possible; lag between endpoints can produce confusing results.
5. Re-establish WebSocket connections and subscriptions after disconnects. Subscription notifications are not a durable event log, so reconcile state with HTTP after reconnecting.

Do not retry every request blindly. Reads are generally safe to retry, but a timed-out transaction submission may already have reached the cluster. While its recent blockhash remains valid, reuse the same signed transaction and track its signature instead of creating a new payment or state change. After the blockhash expires, search transaction history for the original signature or verify the intended change against reliable application or onchain state. A null result from the recent signature-status cache is inconclusive. Only rebuild with a fresh blockhash after establishing that the original did not land. A rebuilt transaction has a new signature, so preserve application-level idempotency before sending it.

Protect access credentials

Treat paid RPC URLs and API keys as credentials. Keep unrestricted keys out of source control, logs, analytics, and public client bundles. If a browser or mobile client must call RPC directly, use a restricted public key or a backend proxy and enforce origin, method, and rate limits where the provider supports them.

An RPC endpoint never needs a wallet's private key or seed phrase. Transactions sent through sendTransaction are already signed.

Selection checklist

Before committing to a provider or architecture, confirm:

• required clusters, methods, commitments, and historical range work
• sustained and burst traffic fit documented limits
• latency, freshness, and error rates meet targets from every required region
• WebSocket reconnect and reconciliation behavior is tested
• keys can be scoped, rotated, and monitored
• pricing has been modeled with representative heavy methods and responses
• alerts, support, status information, and escalation paths are documented
• a fallback has been tested instead of only configured

Re-run the evaluation as traffic and RPC usage change. The best provider fit is an operational decision, not a permanent property of an application.