Why your RPC provider decides your edge
For most teams, the RPC provider is a checkbox. You sign up, paste an endpoint, and move on. For an HFT desk on Solana, it is the single piece of infrastructure that sits between your strategy and the network on every read and every write. If it is slow, you are slow, and no amount of clever code recovers the milliseconds you lost at the wire.
The mistake most buyers make is treating latency as a software problem. It is mostly a location problem. When you call a node, the dominant cost is usually not how fast the node thinks. It is how far the request and response have to travel, and how many hops sit between the leader producing data and you receiving it. A beefier server cannot out-run distance.
A faster machine a region away still loses to equal hardware next to the cluster. Proximity is the cheapest latency you'll ever buy.
This reframes the whole buying decision. You are not shopping for the biggest box or the longest feature list. You are shopping for the shortest physical and logical path between the Solana cluster and your strategy, delivered reliably, at a price that does not surprise you. Everything below is in service of that.
The criteria that actually matter
Cut through the marketing and the decision comes down to six things. Here is what each one means and what good looks like.
| Criterion | What to look for | Why it matters |
|---|---|---|
| Latency & co-location | Nodes racked beside stake clusters and the Jito Block Engine, with a stated region and methodology | Distance is most of your latency. Co-location is the only real fix |
| Reliability & uptime | Redundant nodes, failover, transparent status, no single points of failure | A fast endpoint that drops mid-trade costs more than a slightly slower one that never does |
| Data access | JSON-RPC, Yellowstone gRPC, and decoded shreds from one vendor | Different jobs need different read models. You don't want to stitch three vendors together |
| Transaction landing | Direct leader submission plus Jito, stake-weighted QoS (SWQoS) | Reading early is half the game. Landing the trade is the other half |
| Pricing model | Throughput or capacity pricing, not opaque per-request credits | Credit counting punishes the high-volume reads HFT depends on |
| Support & onboarding | Engineers who run Solana infra, not a ticket queue | When latency regresses at 3am, you need someone who understands shreds, not a script |
A few of these deserve more than a table row.
Latency and co-location. This is the one that decides the others. Ask where the nodes physically sit relative to Solana's stake and to the Jito Block Engine. A provider that co-locates and aggregates from multiple upstreams will hand you whichever copy of the data arrives first. A provider that runs in a generic cloud region a hop or two away cannot match that, no matter what their dashboard says. We go deep on why in Why RPC Polling Can't Keep Up.
Data access. A standard JSON-RPC endpoint is necessary but not sufficient. For real-time state at scale you want Yellowstone gRPC, a push stream that sends you account and transaction updates as the validator processes them instead of you polling for them. For first-seen signal you want decoded shreds, read from the propagation layer before a block is even assembled. The difference between gRPC and polling is structural, not incremental, and we break it down in Yellowstone gRPC vs Standard RPC. The point for a buyer: get all three from one co-located vendor so they share the same short path to the cluster.
Transaction landing. Seeing an opportunity early is useless if your transaction lands late or not at all. Look for a transaction sender that submits directly to the current and upcoming leaders, routes through Jito when it helps, and uses stake-weighted QoS so your transactions get better-than-default priority during congestion. Landing rate under load is a real number you should ask about.
Co-located RPC, gRPC, and shreds from one vendor.
rpc edge runs the whole stack next to the cluster - the earliest view, the fewest hops, predictable pricing.
Shared vs dedicated nodes
Most providers sell a shared tier and a dedicated tier. The difference is not cosmetic.
A shared node serves many customers from the same machine. It is cheaper, it spins up instantly,
and it is genuinely fine for development, low-volume reads, and bursty traffic where the occasional
throttle or a few extra milliseconds will not cost you a trade. The catch is the noisy neighbor:
when someone else on the box runs a heavy getProgramAccounts scan, your latency moves, and you have
no control over when.
A dedicated node is yours. No contention, no shared rate limits, predictable latency, and full throughput. For any strategy whose edge depends on consistent response times, this is not a luxury, it is the baseline. The question is not whether dedicated is better. It is whether your strategy can tolerate the variance of shared, and for serious HFT the answer is usually no.
Red flags
The Solana RPC market has its share of marketing that does not survive contact with a methodology. Watch for these.
- Unverifiable speed claims. A provider that advertises "sub-5ms" with no statement of from where, to where, which percentile, and under what load is selling a number, not a result. Latency is meaningless without a path and a distribution. Ask for the methodology. A serious provider has one.
- Credit-counting surprise bills. Per-request credit pricing looks cheap until your read-heavy strategy hits production and the invoice arrives weighted by method. If you cannot predict next month's bill from this month's traffic, the pricing model is working against you. Prefer throughput or capacity pricing.
- No co-location. If a provider cannot tell you where their nodes sit relative to Solana stake and the Jito Block Engine, the honest answer is "in a generic region," which means you are paying distance you did not have to. Vagueness here is the tell.
- Reselling. Some "providers" are a thin billing layer over someone else's nodes. You inherit their latency, their outages, and an extra hop, with no one who can actually fix the infrastructure when it breaks. Ask who runs the metal. If they cannot answer plainly, they don't.
A short checklist
Bring this to any sales conversation.
- Where do your nodes physically sit relative to Solana stake and the Jito Block Engine?
- What is your latency methodology, including percentile and load?
- Do you offer JSON-RPC, Yellowstone gRPC, and decoded shreds from the same co-located infrastructure?
- How do transactions land: direct to leader, Jito, stake-weighted QoS?
- Is pricing throughput-based or per-credit, and can I predict my bill?
- Shared or dedicated, and what is the variance on the shared tier?
- Who runs the actual nodes, you or an upstream you resell?
- When latency regresses, who picks up, an engineer or a ticket queue?
If a provider answers all eight plainly, they are running real infrastructure. If they get vague on location, methodology, or who owns the metal, you have your answer.
The takeaway
Choosing a Solana RPC provider is not a feature comparison. It is a physics decision wearing a pricing page. The dominant cost in your reads and writes is distance, so the provider that puts the shortest, most reliable path between the cluster and your strategy wins, and the one with the longest feature list a region away does not.
Judge providers on co-location, reliability, full data access, transaction landing, honest pricing, and real support. Be skeptical of unverifiable numbers, surprise bills, and resellers. rpc edge runs RPC, gRPC, decoded shreds, and a transaction sender co-located with the cluster, on dedicated nodes, priced on throughput. Physics over promises.