If you've started building on Solana and run into the term "RPC" — and have only a vague idea what it actually does — this post is for you. We're going to walk through what a Solana RPC server is, how it relates to a validator, what "private RPC" means, what RPC node providers actually do, and how to pick the one that fits your workload.
We'll keep it practical. By the end you should know enough to read provider marketing pages with a sceptical eye and pick what's right for what you're building.
What Is an RPC Server?
RPC stands for Remote Procedure Call. In a blockchain context, an RPC server is the API layer that lets your application talk to the network — read data, submit transactions, query state, watch events.
You don't talk to "Solana" directly. You talk to a node, and that node either is a validator (participating in consensus) or is downstream of validators (an RPC-only node). Either way, the interface you hit is the RPC server.
Concretely, when you write:
const connection = new Connection("https://api.mainnet-beta.solana.com");
const balance = await connection.getBalance(publicKey);
The https://api.mainnet-beta.solana.com is an RPC server. Your getBalance call is an RPC method. The server interprets the request, queries its local copy of the chain state, and returns the answer.
Same goes for sendTransaction — you hand the RPC a signed transaction, and the RPC's job is to get it to the validator that's about to produce a block.
Already know what an RPC does and just need a send endpoint? Free key here — one line to swap in. The rest of this explains what you are actually choosing between.
Solana RPC vs a Validator
These often get conflated. They're related but distinct:
- A validator participates in consensus. It produces and votes on blocks. Validators are stake-weighted and economically responsible.
- A Solana RPC node runs the same client software but is configured to serve API traffic rather than vote. It mirrors chain state and submits transactions into the network (transaction sending) or answers state queries (read-only).
In practice, "Solana RPC node providers" run RPC-only fleets that push transactions into the network through SWQoS-style mechanisms to reach the current block-producing nodes quickly. When you sign up with a provider, you're getting a place to send reads and submit transactions; the validator network is the actual chain.
What "Private RPC" Means
You'll see "private RPC" used a few different ways. Let's separate them:
-
Dedicated private RPC — your own RPC instance, not shared with other customers. Removes noisy-neighbour problems and gives you predictable latency. Some providers sell this as a premium tier.
-
Private RPC routing — what providers like BoltTx do. Even if the underlying infrastructure is shared, transactions you submit don't pass through the public observation surface bots use to scrape pending transactions. The privacy is at the routing layer, not the hardware layer.
-
Self-hosted private RPC — you run your own node. Full privacy but full operational responsibility (see the enterprise post for why most teams shouldn't).
For trading workloads, what you usually want is option 2 — private routing — because that's what protects you from sandwich attacks. For latency-sensitive enterprise workloads, dedicated private instances may also make sense.
What Solana RPC Node Providers Actually Do
A serious RPC node provider does more than "let you call methods." Here's the actual stack:
- Run their own RPC fleets in geographic locations optimised for network latency
- Health-check and load-balance across the fleet
- Filter abusive traffic so one bad customer doesn't degrade the whole pool
- Submit transactions intelligently — route through SWQoS paths for priority landing, set tips appropriately, retry on the right conditions
- Mirror state so reads don't have to round-trip on-chain
- Provide observability so you can see what's happening with your traffic
The differences between providers come down to how well each of these is done. Two providers can both hand you an HTTPS endpoint and have wildly different P95 latency profiles. One might lean on shared public mempools and leak your transactions to MEV bots; another might route privately. The endpoint URL looks the same; the behaviour doesn't.
Blockchain RPC Providers: How Solana Compares
The general "blockchain RPC providers" category splits three ways: EVM-first vendors that added Solana later, Solana-native vendors, and multi-chain platforms that cover many networks at once.
For Solana specifically, the dynamics are different:
- No public mempool. Transactions go directly to the next-scheduled validator. So "private mempool" isn't quite the right framing — it's about whether the path through the RPC layer exposes your transaction before it lands.
- SWQoS (Stake-Weighted Quality of Service). The network prioritises RPC nodes with SWQoS support. Providers without SWQoS support fall further behind during congestion.
- MEV is validator-side, not mempool-side. The protections that matter look different from Ethereum.
- Sub-second confirmation is achievable on Solana, which changes what "fast enough" means as a baseline.
A multi-chain provider that's good at Ethereum may not be good at Solana — the optimisations that win on Ethereum don't all carry over.
How to Choose an RPC Node Provider
The decision tree for most builders:
If you're sending transactions (trading, DEX, mints, bots, AI agents)
You want:
- Sub-second confirmation as a documented behaviour
- SWQoS support
- Native Anti-MEV (sandwich protection at the routing layer)
- Telemetry per signature so you can debug delivery
- Pricing that aligns with landed transactions, not attempts
This is BoltTx territory. Try the free tier and benchmark.
If you're indexing or analysing data
You want:
- Parsed transaction APIs (so you don't have to decode raw JSON)
- streaming subscriptions
- Webhooks
- NFT metadata if relevant
- Generous read pricing
A general-purpose vendor with a broad API surface is the usual fit here — parsed endpoints and indexing save real work on read-heavy loads.
If you're a generalist team that hasn't specialised yet
You want:
- A solid all-in-one platform
- Reasonable pricing across read and write
- Good documentation
- A clear migration path if you specialise later
Most general-purpose vendors fit. Pick based on team familiarity and pricing.
If you're an enterprise team with strict requirements
You want:
- Documented SLA
- Per-customer isolation
- Second-level latency telemetry
- A real account manager
See our enterprise guide for the full checklist.
Common Solana RPC Misconceptions
A few patterns we see come up:
"Public RPCs are fine for production." They're rate-limited, have no SLA, and frequently lag. Fine for development; never for production.
"All RPC providers have the same latency." P50 might be similar across providers. P95 and tail behaviour during congestion are where serious differences show up. Always benchmark.
"I need to run my own node for serious workloads." The opposite is usually true. Self-hosting Solana validators/RPCs is operationally expensive and most teams trying it walk it back within a year. A managed provider with the right architecture beats self-host for most use cases.
"RPC providers are interchangeable." For reads, mostly yes. For sends, no — sandwich exposure, landing rate during congestion, and fee profiles vary substantially.
"The cheapest provider is fine if you're starting out." The cheapest provider that gets your transactions sandwiched is silently the most expensive provider. Account for delivered value, not just sticker price.
Try BoltTx as Your Solana RPC
If you want to skip provider research and start with something purpose-built for transaction sending:
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
Free tier signup — pay only when transactions land. If your workload is read-heavy and you need parsed APIs, pair BoltTx with a general-purpose read vendor — a common setup.
FAQ
What's a Solana RPC server in one sentence? A server that exposes the Solana JSON-RPC interface, letting your application read chain state and submit transactions.
Is Solana RPC the same as a validator? No. A validator participates in consensus. An RPC node serves API traffic. Same software, different role.
What's a private RPC for Solana? Either a dedicated RPC instance just for you, or a routing layer that doesn't expose your transactions to public observation. BoltTx provides the latter as the default.
How do I pick a Solana RPC provider? For transaction sending, prioritise sub-second confirmation, SWQoS, and Anti-MEV. For reads, prioritise parsed APIs and pricing. For enterprise, prioritise SLA, isolation, and observability.
Can I use multiple RPC providers? Yes — a common pattern is BoltTx for sends and a general-purpose vendor for reads and indexing. The integration points are independent.
What's the difference between mainnet-beta RPC and devnet? Mainnet-beta is real Solana with real value. Devnet is a separate cluster for testing. Don't deploy to mainnet what you haven't tested on devnet first.
Why do I need a paid Solana RPC if public endpoints exist? Public endpoints are rate-limited and not built for production sending. They work for development and one-off queries. Once you are submitting transactions where timing has money attached, the limits and the shared submission path both become the constraint.
What is the difference between a Solana RPC and a Solana node? A node participates in the network and holds chain state. An RPC endpoint is the interface you talk to. Providers run nodes and expose RPC endpoints in front of them; you can run your own, but the operational cost is significant.
How many RPC calls does a trading bot make per second? It varies enormously by strategy. A polling bot watching several pools can generate hundreds of reads per second, while a sniper might sit idle then burst. Measure your own over a week including peaks rather than guessing from a tier description.
Can I use one Solana RPC for both reading and sending? You can, but most production setups split them. Reads want throughput and history; sends want a short path to a block producer with stake behind it. Optimising one endpoint for both means compromising on each.
What does it mean when an RPC returns 429? You exceeded the rate limit for your tier. It is a capacity signal, not a transaction problem. If it happens during normal operation rather than at peaks, you have outgrown the tier.
Why is my Solana RPC slow? Separate the two cases. Slow reads usually mean shared capacity or geographic distance. Slow or failing sends usually mean the path after your node, which no amount of read capacity fixes.
Do I need a Solana RPC to send transactions? Yes. You sign locally, but something has to carry the signed bytes toward a block producer. That is what the endpoint does. Which endpoint you pick determines how likely the transaction is to be accepted under load.
What is the best Solana RPC for a trading bot? The one with the shortest path to a block producer for your region and meaningful stake behind it. Read features barely matter for a bot that mostly sends. Test with your own traffic during a congested period rather than trusting benchmarks.
How much does a Solana RPC cost? Models differ. Some charge per credit or by monthly tier for capacity; others charge per landed transaction. Which is cheaper depends entirely on whether your workload is read-heavy or send-heavy.
Is a free Solana RPC tier enough for production? For reads on a small application, often yes. For a trading bot where landing matters, the constraint is usually not the free tier's request count but the submission path underneath it.