Search for "private Solana RPC" and you get three unrelated products described with the same word. Teams buy one thinking they got another, then find out during a launch that the thing they were worried about was never covered.
Here is what each one actually is, and how to tell which you need.
The Three Meanings
1. Private as in dedicated hardware
A node that only you use. No other customer shares its capacity, so nobody else's traffic spike becomes your rate limit.
What it solves: noisy neighbours. Your throughput is yours.
What it does not solve: anything about who observes your transactions. A dedicated node still forwards to validators through a normal path, and your transaction is just as visible in transit as it would be on a shared endpoint.
Who needs it: high sustained request volume, usually read-heavy — indexers, analytics, anything polling hard enough to hit shared-tier limits.
2. Private as in the submission path
Your signed transaction reaches a block producer without passing through parties that would inspect it.
What it solves: front-running and sandwiching by intermediaries who would otherwise see your intent before it lands.
What it does not solve: capacity. A private path can still be rate-limited, and it does nothing for read throughput.
Who needs it: anyone whose transactions carry visible value — swaps large enough to be worth sandwiching, snipes, liquidations, arbitrage.
3. Private as in "the URL is not public"
An endpoint with a secret hostname or an API key in the URL. Nobody can use it without the key.
What it solves: unauthorised use of your quota.
What it does not solve: ★either of the above★. An unlisted URL is access control, not privacy of what flows through it.
This is the one most often mistaken for the second. An endpoint being hard to guess says nothing about who reads your transactions on the way to a validator.
If you already know it is the submission path you need, a free BoltTx key is one line.
Which One You Actually Need
Start from what you are worried about, not from the word:
| Your concern | What you need |
|---|---|
| Rate limits during traffic spikes | Dedicated capacity |
| Someone front-running my swaps | Private submission path |
| Someone else using my quota | Access control (every provider has this) |
| Transactions not landing under load | Neither — this is routing and fees |
★That last row is worth pausing on.★ "Private RPC" gets recommended for landing problems constantly, and it is usually the wrong fix. If your transactions are not landing, the cause is normally blockhash expiry, an insufficient priority fee, no retry loop, or a deprioritised submission path. A dedicated node changes none of those.
Why Dedicated Nodes Get Oversold
The pitch is intuitive: your own node, no sharing, better performance. For read workloads that reasoning holds.
For sending, it usually does not, and the reason is worth understanding.
When you submit a transaction, your node forwards it toward the validator scheduled to produce upcoming blocks. Whether that validator accepts it depends on how much stake backs the forwarding node — this is stake-weighted quality of service. A dedicated node with no meaningful stake behind it gets the same deprioritisation as a shared one during congestion.
★You paid for exclusive capacity on a hop that was never the constraint.★
The bottleneck for sending is what happens after your node, not how many customers share it.
Testing Whether "Private" Is Doing Anything
Each meaning has a different test. Run the one that matches what you bought.
For dedicated capacity — hammer it and watch for 429s:
// Fire concurrent reads well above your normal peak.
// Dedicated capacity should hold; a shared tier will start rejecting.
const results = await Promise.allSettled(
Array.from({ length: 200 }, () => connection.getSlot()),
);
const rejected = results.filter((r) => r.status === "rejected").length;
console.log(`rejected: ${rejected} / 200`);
For submission privacy — compare quoted output against realised output across many fills:
log({
pair,
sizeIn,
quotedOut,
actualOut,
slippageBps: Math.round(((quotedOut - actualOut) / quotedOut) * 10_000),
route,
});
A persistent negative gap concentrated on your most profitable-looking swaps is what sandwiching looks like. One bad fill is noise. A few hundred fills tell you whether the distribution moved after a routing change.
For landing — split by network condition, because that is where paths diverge:
const recent = await connection.getRecentPrioritizationFees();
const fees = recent.map((r) => r.prioritizationFee).sort((a, b) => a - b);
const medianFee = fees[Math.floor(fees.length / 2)] ?? 0;
metrics.record("submission", {
landed: didItLand,
bucket: medianFee > 50_000 ? "busy" : "calm",
});
If landing rate holds in the busy bucket, your path is fine and privacy was never your problem.
The Split Most Production Setups End Up With
After enough iterations, teams tend to converge on the same shape: ★one provider for reads, another for sends.★
The reason is that the two workloads want opposite things. Reads want throughput, generous rate limits, parsed responses, and historical depth. Sends want a short path to a block producer, stake behind the forwarding node, and no observation in transit.
Optimising one endpoint for both means compromising on each. The integration points are independent, so splitting costs you nothing architecturally — you change one without touching the other.
What to Ask Before Buying
"Private" in which sense? If a vendor cannot answer in one sentence, the answer is probably meaning 3.
Who sees my transaction between submission and inclusion? You want a specific list, not reassurance.
Is order flow sold or shared? One word.
Does this affect landing rate, or only rate limits? Many "private RPC" products are capacity products. That is fine, as long as you know it.
What happens under congestion? Everything performs identically on a quiet afternoon.
What Landing Looks Like
Real transactions through our delivery nodes: median confirmation 336ms — under one slot.
If a dedicated node is not moving your numbers toward something like this, the capacity was not what was holding you back.
Where BoltTx Fits
We are meaning 2, and only meaning 2.
BoltTx routes transaction submission through our own delivery nodes in four regions, with stake-weighted routing and no public mempool exposure — so a transaction is not observable in transit before it lands. We do not sell dedicated read capacity, and we do not do indexing, parsed history, or NFT metadata. Pair us with whatever read provider fits your workload.
You sign locally. We never hold funds, never sign, and never modify transaction contents. The tip travels in the transaction itself, paid on chain from your own wallet — if the transaction reverts, the tip reverts with it, because that is how Solana handles atomic transactions. You pay only on transactions that reach the chain.
Get a free API key. No monthly fee:
// Pick the region closest to where your bot runs
const connection = new Connection("https://la.bolttx.io/?api-key=YOUR_KEY");
Then run the tests above. Whichever kind of private you actually needed, you will be able to tell whether you got it.
FAQ
What is a private Solana RPC? The term covers three different things: a dedicated node nobody else shares, a submission path where intermediaries cannot observe your transaction, and an endpoint whose URL is not public. They solve different problems, and buying one does not give you the others.
Do I need a dedicated Solana node? Only if you are hitting rate limits on shared tiers, which usually means heavy read traffic. For sending transactions, a dedicated node does not change how validators prioritise your traffic, so it rarely improves landing.
Does a private RPC prevent sandwich attacks? Only if "private" means the submission path. A dedicated node or an unlisted URL does nothing about who observes your transaction on the way to a block producer. Ask which meaning applies before assuming protection.
Is a private RPC faster than a public one? For reads, usually yes, because you are not queued behind other customers. For sending, the deciding factor is what happens after your node — stake weight and routing — which dedicated capacity does not address.
What is the difference between a private RPC and a private mempool? Solana has no public mempool, so "private mempool" is imported terminology that does not map cleanly. The equivalent concern is whether your submission path exposes the transaction to intermediaries before it lands.
Will a private RPC fix my transactions not landing? Usually not. Landing failures are typically blockhash expiry, priority fee too low for current congestion, no retry loop, or a deprioritised submission path. Only the last one relates to your endpoint, and it is about stake weight rather than exclusivity.
Can I use one provider for reads and another for sending? Yes, and many production setups do exactly that. The two workloads want different things, and the integration points are independent — you can change one without touching the other.
How do I know if my current RPC is exposing my transactions? You cannot inspect it directly, so measure the outcome: track quoted versus realised output across many fills on the same pairs. A persistent negative gap on your most profitable swaps is the signature of someone acting on your intent.
Is an API key in the URL enough to make an endpoint private? It makes it private in the access-control sense — others cannot spend your quota. It says nothing about who can observe transactions flowing through it, which is the meaning most people are actually asking about.
Does a private RPC help with reads like getAccountInfo? Dedicated capacity does, because you get throughput that is not shared. Submission privacy does not, since it only concerns transactions being sent. Match the product to the workload.
Can my RPC provider see my transaction before it lands? Yes — whoever you submit through handles the signed bytes, which is exactly why the question is worth asking of any provider. What matters is how many parties are on that path and what they are contractually and technically able to do with what they see.
Do I need a private RPC for a wallet application? Rarely. Wallets are read-heavy and their transactions usually do not carry enough visible value to be worth front-running. Dedicated read capacity matters more than submission privacy.
How much does a dedicated Solana node cost? Substantially more than shared tiers, and pricing varies widely. Before paying, confirm your constraint is actually rate limits rather than landing, because the two are different problems.
Can I test whether my RPC is exposing transactions? Not directly, but you can measure the outcome. Track quoted versus realised output across many fills. A persistent negative gap concentrated on profitable swaps is the signature.
Does a private RPC help with getProgramAccounts performance? Dedicated capacity does, since heavy queries are not competing with other customers. Submission privacy does not, because it concerns sending rather than reading.