What should you look for in a Solana RPC provider?

Solana's JSON-RPC API is the gateway between your application and the cluster. A Solana RPC provider operates the nodes that field those requests, so your choice affects latency, reliability, and how much infrastructure your team has to manage. The public endpoints listed in the Solana docs are fine for experiments, but production apps typically need a provider with committed throughput, WebSocket support, and a clear fair-use policy.

This article is a practical evaluation guide for teams comparing Solana RPC providers. You will find a decision checklist, the criteria that matter most, an example endpoint request, and a look at the failure modes worth planning for.

Solana RPC provider decision checklist

Use this checklist before you buy anything:

• Define the read/write mix. Are you mainly sending transactions or reading accounts, blocks, and signatures?
• Confirm the provider covers mainnet-beta, devnet, and testnet with consistent method support.
• Test commitment behavior: processed, confirmed, and finalized must map to the state your app expects.
• Choose an access model: a shared endpoint for early stage, a dedicated node for predictable workloads.
• Verify WebSocket subscriptions and reconnect behavior before building a real-time UI on top of them.
• Check archive depth: how far back can the provider return transactions, blocks, and account history?
• Review rate limits, 429 handling, and whether the limit is raised by request volume or node rental.
• Plan for failover: can you route traffic across multiple endpoints, regions, or providers?

The rest of this article explains each point in context.

What a Solana RPC provider does

Every Solana application depends on RPC nodes. When a wallet asks for a token balance, a DEX fetches a quote, or a bot submits a trade, it makes an HTTP JSON-RPC call to a node. Some calls are simple reads like getBalance or getLatestBlockhash. Others simulate and submit transactions. WebSocket methods push live updates for account changes, logs, and slot transitions.

Solana exposes several public clusters: mainnet-beta, devnet, and testnet. The official endpoints are convenient for one-off checks but are shared infrastructure. Solana's own docs warn that public endpoints are not intended for production applications and can return 429 when you exceed rate limits or 403 when traffic is blocked. A commercial Solana RPC provider operates a managed fleet of nodes, adds load balancing, and often provides extra services such as Geyser streaming or transaction delivery helpers.

A basic request to a provider looks like this:

curl "YOUR_SOLANA_RPC_URL" \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getLatestBlockhash","params":[{"commitment":"confirmed"}]}'

The response returns a blockhash and the last valid block height, which your app then uses to build and submit transactions.

Shared vs dedicated Solana RPC access

Most providers offer two ways to connect: a shared endpoint or a dedicated node.

A shared endpoint is a load-balanced URL that fans out requests across many customers. It is cheap and easy to start with, but you share capacity with other teams. Latency can spike when another customer sends a burst of requests, and rate limits are usually enforced per API key.

A dedicated Solana RPC node gives your team exclusive access to the node's resources. This matters for high-frequency trading, NFT drops, data indexing, and any workload that needs predictable throughput. You still get the provider's maintenance, monitoring, and failover, but you do not have to run Solana software yourself.

OnFinality provides Solana in both models. The shared RPC API service works for standard dApp traffic, while dedicated nodes isolate capacity for demanding applications. The Solana network page describes the available access types and the full list of supported networks shows which other chains you can reach from the same platform.

How to evaluate a Solana RPC provider

The table below summarizes the criteria that separate a useful Solana RPC provider from one that causes production incidents.

Throughput and slot lag

Slot lag is the difference between the current leader slot and the slot your RPC node has processed. If a node lags, reads return stale state and transaction submission may fail because the blockhash expires. Providers monitor slot lag, but the threshold they use is not always documented. Ask for the provider's stale-node policy and test the getSlot response against an independent source.

Commitment is a Solana-specific trap

Solana has three commitment levels: processed, confirmed, and finalized. A transaction that is processed can still be rolled back if the cluster does not confirm it. Many providers default to confirmed to reduce UI flicker, but read-heavy apps sometimes use processed to see the newest state. Whatever you choose, the provider must return the same state consistently for the same commitment.

Method coverage and archive access

A production Solana app often relies on getSignaturesForAddress, getTransaction, and getProgramAccounts. These methods are expensive for RPC nodes. getProgramAccounts can read every account owned by a program, which is useful for DEX balances but can time out on a busy network. Check whether the provider enforces a maximum response size, whether archive nodes are available, and whether Geyser or gRPC streaming is offered for high-volume data.

Solana RPC endpoint configuration and WebSockets

Solana's RPC is split into an HTTP API for request-response calls and a WebSocket API for subscriptions. When you evaluate a provider, test both surfaces.

A WebSocket subscription for slot updates looks like this:

const WebSocket = require('ws');

const ws = new WebSocket('wss://YOUR_SOLANA_RPC_URL');

ws.on('open', function open() {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'slotSubscribe'
  }));
});

ws.on('message', function incoming(data) {
  console.log(data.toString());
});

Real-world apps also subscribe to account changes, program logs, and signatures. Confirm the provider supports the subscription methods you need, not just the common wallet RPCs. If you are building an indexer, look for Geyser plugins or gRPC streams instead of polling getProgramAccounts in a loop.

Common failure modes with Solana RPC providers

Knowing what can go wrong helps you ask better questions during a provider trial.

• 429 Too Many Requests. Shared endpoints enforce rate limits. Check whether the provider returns the Retry-After header and what the client should do when the quota is exhausted.
• 403 Forbidden. Some providers block traffic from certain regions or require an allowlist. If your users are global, this can break access.
• Stale slot responses. A node that lags behind the cluster returns stale values for getSlot, getBalance, and other reads. Your app needs a way to detect that and fail over.
• BlockhashNotFound. The blockhash you used to sign a transaction has expired or was never observed by the receiving node. Retry with a fresh getLatestBlockhash.
• Transaction simulation failure. Your transaction may reference an account that has changed since reading state. Simulate again with current data before submitting.
• WebSocket disconnects. Subscriptions drop without warning. The client must reconnect, resubscribe, and fill missed data from HTTP calls.
• Large responses timing out. getProgramAccounts and getSignaturesForAddress can return many records. Providers may cap response sizes or stream results.

A good provider should document these behaviors and offer retries, load-balanced endpoints, and monitoring. Avoid providers that describe every failure as client error without publishing the operational details.

Build vs buy: running your own Solana RPC node

Running Solana's validator software with an RPC port is not trivial. A mainnet RPC node needs a modern CPU, a large amount of RAM, fast NVMe storage, and a multi-day ledger sync before it is useful. After sync, you need to monitor slot lag, apply updates, keep snapshots fresh, and manage failover. That is a full operational role, separate from whatever application you are building.

Managed infrastructure shifts that work to the provider. OnFinality supports Solana on both the shared RPC API and dedicated node products, with transparent RPC pricing that separates request volume from node rental. Teams that already operate infrastructure for several chains should also read the general RPC provider selection guide for a cross-chain comparison framework. For staging and integration tests, take a look at Solana devnet endpoints as well.

Key Takeaways

• A Solana RPC provider is the gateway between your app and the cluster. Public endpoints are not a production target.
• Test commitment, method coverage, WebSocket reliability, and archive depth before committing.
• Shared endpoints are fine for early stages; dedicated nodes give you isolated capacity and predictable performance.
• Provider failover, retry behavior, and stale-node detection affect user experience as much as raw latency does.
• Make sure the provider covers the clusters your team uses, including devnet for staging and testnet for validation-focused experiments.

FAQ

What is a Solana RPC provider?

A service that operates Solana RPC nodes and exposes them as managed HTTP and WebSocket endpoints. It lets you read on-chain state and submit transactions to the cluster without running Solana infrastructure yourself.

Are public Solana RPC endpoints good enough for production?

No. Public endpoints like api.mainnet.solana.com are designed for development and testing. They are shared infrastructure and can rate-limit or block traffic. Production apps should use a provider with defined limits, redundancy, and support.

What is slot lag and why does it matter?

Slot lag is the difference between the current leader slot and the slot your RPC node has processed. If your node is behind, reads return stale state and transaction submission can fail because blockhash availability is tied to the node's view of the cluster.

Should we use a shared or dedicated Solana RPC endpoint?

Shared endpoints are cheaper and simpler, and they are a good starting point. Dedicated nodes provide isolated resources and are better for high-throughput workloads, data indexing, or applications that need predictable latency.