Forem: OrbitFlare RPC

Top Solana RPC Providers in 2026 - A Comprehensive Guide

OrbitFlare RPC — Fri, 01 May 2026 18:46:34 +0000

For a long time, picking a Solana RPC provider was a one-line decision: pick the cheapest endpoint that didn't fall over. The interesting question was whether you could afford a dedicated node or had to live on shared infrastructure. That world is mostly gone.

In 2026, "Solana RPC" usually means a stack of five things that used to be distinct products. Plain JSON-RPC is the floor. On top of it sit WebSocket subscriptions, Yellowstone-style gRPC streams, shred-level feeds tapped before validators finish execution, and staked transaction submission with SWQoS routing. Most of the providers below offer some subset. A few offer all of them. At least two of the names you keep seeing on these lists don't really play the same game anymore.

What to Actually Benchmark

Reading a provider's website is not benchmarking. Five things worth putting on a real test rig from your own infrastructure before signing anything:

p99 latency on the methods your app actually calls. Average latency is marketing. The slowest 1% of requests is what breaks production. Pick the three or four methods that dominate your traffic (getAccountInfo, sendTransaction, simulateTransaction, getSignaturesForAddress are typical) and measure p99 from your own server for at least an hour during real chain activity. The gap between providers shows up in the long tail, not the median.
Transaction land rate during congestion. Pick a known busy window (a vote epoch transition, a major mint, a memecoin event) and submit a few hundred test transactions through each provider you're evaluating. Track what percentage land on the first try. Staked submission and SWQoS routing typically push this into the high 90s; unprioritized submission can fall into the 60s. Land rate at p50 congestion is the number every provider quotes; land rate at p99 is the one that matters.
Reconnect behavior under partial failure. Most providers' SDKs survive a clean disconnect. The interesting case is a flaky upstream: connection technically alive, packets dropping, slot lag silently growing. Simulate it (tc qdisc add dev eth0 netem loss 5% on Linux is one easy approach) and watch whether the client recovers, retries, or just keeps yielding stale data. Whoever hides the failure longest hurts you the most.
The pricing curve at 10x your current load. Free tiers and starter plans are decoys. The real number is what the bill becomes at the volume you'd hit if your product worked. Build a quick spreadsheet: project your request mix to 10x scale, run it through each provider's pricing page, see which ones double, which ones quadruple, and which ones quietly switch you to a custom-quote tier.
The shape of what's above plain JSON-RPC. Raw RPC is a commodity. The actual differentiators are the surfaces above it: parsed transactions, token and NFT metadata APIs, shred-level feeds, regional pops, archival depth, observability dashboards. Match your real needs against what each provider has shipped, not what they list on a coming-soon page. If a feature isn't documented, it doesn't exist for buying purposes.

1. OrbitFlare

OrbitFlare runs the full transport stack for Solana: RPC, WebSocket, Yellowstone-compatible gRPC, and two shred-layer products. Jetstream delivers decoded shreds over gRPC (the server parses the transaction for you), while Shredstream forwards raw shreds over UDP straight from top-of-Turbine validators in 9 regions. Coverage spans 11 regional pops on three continents: four in the US (Ashburn, New York, Los Angeles, Salt Lake City), five in Europe (Amsterdam, Frankfurt, London, Dublin, Siauliai), and two in Asia (Tokyo, Singapore). A single SDK talks to all four transports through one builder pattern, which kills the per-transport plumbing tax any non-trivial Solana app eventually accumulates.

The Jetstream path sits closer to the leader than any Geyser-based feed by definition. Geyser fires after the validator commits the transaction. Shred decoding produces a parsed transaction before that. For anyone timing entries on swap rumors, copy-trading an active wallet, or detecting pool creations before they're in a block, that window matters.

What OrbitFlare doesn't ship: NFT-heavy parsing APIs and cross-chain coverage. If those are the problem, Helius and QuickNode are the right calls.

2. Triton One

Triton built Yellowstone. That alone earns them a top spot on any honest list, because the standard everyone else implements is the standard they wrote. Their public products read like an institutional menu: Dragon's Mouth for live gRPC, Steamboat for archival queries, Old Faithful for historical block data, Cascade Marketplace for SWQoS routing.

They run dedicated nodes by default. Observed latency sits around 100ms, which is competitive with anyone. They have the longest credible track record powering large protocols. Openbook, Pyth, and Wormhole have all leaned on Triton at various points, and that kind of operational reputation isn't bought, it accumulates.

The catch is the price tag. Dedicated nodes start in the high four figures per month, with Cascade pricing on top if staked submission is needed. Triton is institutional infrastructure and prices itself that way. For something that genuinely needs the guarantees they offer (large DeFi, exchange backends, capital-heavy MEV operations), they're worth the spend. For a side project a few months in, the pricing page is the bouncer.

3. Helius

Helius is the Solana-native incumbent, and usually the right answer when the requirement is "I need a lot of Solana-specific tooling and I want it now." Their RPC runs through staked validator nodes for SWQoS priority on transaction submission. Beyond plain RPC, they ship an Enhanced Transactions API, the Digital Asset Standard (DAS) read API, parsed webhooks, and LaserStream for low-latency gRPC.

If your app is heavy on token metadata, NFT data, or anything that would otherwise require a custom indexer to enrich raw RPC output, Helius has done that work and exposes it under one account. Their free tier at 1M credits per month is one of the more generous on this list, which makes the on-ramp for hobby projects almost frictionless. They also operate a top-staked validator, which gives them more leverage on transaction landing than most.

The tradeoff worth flagging: the Enhanced APIs are useful but sticky. Once your code is wired to "give me a parsed transaction with token transfers labeled," moving to another provider means writing the parser yourself. That's not a knock on their engineering. It's a portability choice worth making consciously.

4. GetBlock

GetBlock benchmarks #1 on raw latency in Asia, EU, and Africa, which is credible for users outside North America. Their dedicated nodes ship with Yellowstone gRPC included rather than as an add-on, unusual at their price point, and they offer a LandFirst transaction submission product that competes with paid SWQoS tiers elsewhere.

Their shared tier is fine for hobby projects but they're at their best as a regional dedicated provider. They also offer free engineering help for custom configurations, worth mentioning not as praise but as a signal of where they sit. You're getting hands-on attention you wouldn't get from QuickNode or Alchemy at the same spend.

5. RPC Fast

RPC Fast is the most opinionated provider on this list. They run bare-metal dedicated nodes only, ship Jito ShredStream on by default, and price everything custom. There is no self-serve tier ladder. The pitch is straightforward: HFT-grade infrastructure for teams that can write a procurement email.

Their automated failover claim of sub-50ms recovery is aggressive enough that it's worth pressure-testing in a real benchmark before signing anything, but the underlying setup (bare-metal nodes, geographic redundancy) is the right shape for it. Yellowstone gRPC is supported but not their primary streaming pitch. ShredStream is.

The catch is the pricing model. Custom-only is fine when the budget exists; it's a wall when the goal is to spin up a node over the weekend. Skip this one if "request a quote" isn't a workflow you can run.

6. Alchemy

Alchemy supports 37+ chains and has the deepest developer tooling in crypto, the kind of metering, logging, replay, and trace infrastructure you'd expect from a much older industry. For teams already using them on EVM, adding Solana is two clicks and a billing change.

What you get: solid latency (40-60ms observed in North America and Asia), a generous free tier (30M compute units a month), and the most polished docs on this list. What you don't get: Solana-specific depth. There's no equivalent of Helius's parsed APIs, no Jetstream-style shred feed, and the highest shared plan caps at 300 RPS.

Alchemy is the right answer when Solana is one of several chains being supported and managing two relationships isn't appealing. It's not the right answer when Solana is the hot path.

7. QuickNode

QuickNode is the EC2 of crypto RPC. They support 75+ chains across 120+ networks, have the most polished dashboard in the space, and offer a long shelf of add-ons to compose per-project. MEV protection, transaction speed boosters, NFT and token APIs, Yellowstone gRPC on port 10000, and so on.

For multi-chain teams, especially ones that want a single vendor for both EVM and Solana, QuickNode is the pragmatic answer. Their ops are mature, their SLAs are real, and their support is responsive in ways most of this list isn't.

Where they're not the obvious pick: pure Solana work where every dial needs to be turned up. Standard tiers cap shared throughput around 400 RPS, which sounds like plenty until a sniper is fanning blockhash refreshes through a launch. The Solana-specific depth, parsed APIs, shred-level feeds, fine-grained staked submission, is shallower than what Helius, Triton, or OrbitFlare offer.

8. Ankr

Ankr runs a decentralized RPC network across 80+ chains, with throughput up to ~1,500 RPS on premium tiers. Pricing is pay-as-you-go from around $6 per 1M requests, which is the most cost-effective option on this list for low-volume reads.

Two things to know. Their network model means there's no single dedicated machine, traffic is load-balanced across operators. That's fine for read-heavy workloads, less ideal when predictable latency for transaction submission is a requirement. SWQoS access is gated behind their premium tier.

Pick Ankr when cost per read matters more than tail latency. Skip it for any hot path.

9. Chainstack

Chainstack quietly turned on Jito ShredStream by default on their Solana nodes in early 2026, shipped a Trader Node product with priority routing, and run real SOC 2 Type II compliance, which matters more than people admit when the goal is to onboard institutional customers.

Their Unlimited Node tier at $149/mo is the best flat-rate offer in the market. Full RPC, WebSocket, and gRPC access without the per-request metering that turns other providers' pricing pages into spreadsheet exercises. That directly undercuts OrbitFlare's Growth tier on raw monthly cost. Chainstack sits below the providers above in this ranking because their Solana product is one of many things they offer rather than their entire business. For teams already on Chainstack for EVM work, extending to Solana is a one-tab decision.

10. Syndica

Syndica is Solana-only and has leaned hard into observability. ChainStream gives a query layer over historical Solana data. Their dashboards show what RPC traffic actually looks like, with request mix, p99 latency by method, and error rates broken down in a way most providers don't bother with.

The core RPC is solid but isn't differentiated on raw speed. The reason to pick Syndica is the diagnostics. When a team is trying to figure out why a particular method is slow, or which addresses are eating most of their getAccountInfo budget, having that data already collected beats writing a metrics pipeline from scratch.

Best fit for teams with their hands full of Solana-specific debugging and a real need to understand their own usage in production.

Dedicated vs Shared

A quick note, because people still ask this every week.

Shared nodes get you started faster and cost less, but they come with noisy-neighbor effects. When another tenant runs a heavy getProgramAccounts query on the same instance, p99 latency spikes. On the better providers this is minor. On cheaper ones it can be severe.

Dedicated nodes remove the noise but introduce configuration and capacity questions that used to be the provider's problem. You pick the region. You pick the hardware tier. You pay whether your traffic is full or empty.

The right answer depends more on predictability requirements than on scale. A small trading operation that needs consistent latency belongs on dedicated before a much larger read-heavy app that can tolerate occasional spikes. Every major provider on this list offers both shapes. Pick the one that matches what you need to be certain about.

By Use Case

The honest mapping, since "no universal winner" sounds wise but doesn't help anyone make a decision:

Trading, MEV, sniping. OrbitFlare, Triton One, or RPC Fast. All three give shred-level or sub-block feeds and serious latency. OrbitFlare for teams that want one SDK across the whole transport surface. Triton if the team is already built around Yellowstone and the institutional reputation is part of the buying decision. RPC Fast if the budget is open and procurement is an option.
Solana-native dApps with NFT or token surfaces. Helius. The Enhanced Transactions API and DAS will save weeks of indexer work. Plan for the portability cost when moving.
Multi-chain teams. QuickNode for breadth and ops maturity, Alchemy for developer tooling depth, Chainstack for the flat-rate pricing. The right answer depends on existing relationships more than the technology.
Institutional workloads with compliance requirements. Chainstack (SOC 2 Type II) or Triton One. Helius is also SOC 2 certified but fewer of their enterprise customers talk about it publicly.
Cost-sensitive read workloads. Ankr. Pay-as-you-go pricing is the cheapest cost-per-request on this list.
Solana with regional concentration outside North America. GetBlock for Africa benchmarks. OrbitFlare for any of the 11 regions across the US, Europe (including Eastern Europe via Siauliai), and Asia (Tokyo and Singapore).
Production debugging on Solana. Syndica's observability layer earns its rank.

At a Glance

The Floor

There is no universal best. There is a worst, though, and that's running anything you care about on a public RPC endpoint and being surprised when it stops responding the moment a launch hits. Pick something on this list. The cheapest paid tier of any of them beats free.

To compare specifics against OrbitFlare, or to get help sizing the right tier for a workload, get in touch.

The OrbitFlare SDK: One Rust Crate for Every Solana Transport

OrbitFlare RPC — Sun, 26 Apr 2026 15:38:00 +0000

Building a Solana app in Rust tends to mean you collect SDKs. One for JSON-RPC because you need get_balance and get_transaction for the obvious one-shot reads. One for WebSocket because polling for account changes gets tired fast. One for gRPC because Yellowstone is the only realistic way to keep up once your volume passes a certain threshold. And often a fourth for whatever specialized feed you've signed up for on top of it, because the first three stop being enough the moment latency starts mattering to your app.

Each one arrives with its own types, its own error model, its own opinions about how to reconnect when the socket drops, and its own way of threading auth into a URL. You end up writing the same wrapper code in four slightly different places - retry the request, fall back to a secondary endpoint, redact the api key out of log lines, time out when the connection has gone silent - and none of it is the reason you started the project. It's the least interesting code in any Solana app, and somehow it ends up being the most fragile too.

The OrbitFlare Rust SDK

OrbitFlare sits at the other end of that problem. We run Solana RPC, WebSocket, and gRPC endpoints, plus our own Jetstream feed for the cases where Geyser-based streams can't keep up.

Our new Rust SDK is what you use to talk to any of it, and it's shaped around a single builder pattern and a single error type across every transport, so the code you write to call get_balance over HTTP reads almost identically to the code you write to open a binary gRPC firehose.

What that buys you, beyond a shorter Cargo.toml, is that all the plumbing you would otherwise be writing per-client lives once, in one place, and gets better over time instead of drifting in four directions at once.

The Transports

The crate exposes four transport modules, each behind its own feature flag.

rpc is the typed JSON-RPC client you'll reach for whenever you need a one-shot read, a transaction submission, or a historical lookup.
```
let rpc = RpcClientBuilder::new()
    .url("http://ams.rpc.orbitflare.com")
    .build()?;
```
ws gives you the pub/sub surface for the things you want to watch as they happen on-chain: slots, accounts, signatures, and log filters.
```
let ws = WsClientBuilder::new()
    .url("ws://ams.rpc.orbitflare.com")
    .build()
    .await?;
```
grpc is the Yellowstone-compatible firehose, where you open one long-lived subscription, hand the server a set of filters, and let it stream every matching event straight from the validator's Geyser plugin.
```
let geyser = GeyserClientBuilder::new()
    .url("http://ams.rpc.orbitflare.com:10000")
    .build()?;
```
jetstream has the same API shape as the gRPC client, but the data comes out of our own shred-decoded pipeline rather than Geyser, which is a meaningful win when "earlier" matters to what you're building.
```
let jetstream = JetstreamClientBuilder::new()
    .url("http://ams.jetstream.orbitflare.com")
    .build()?;
```

Installation

cargo add orbitflare-sdk --features <features>

The available features are rpc, ws, grpc, and jetstream. Pick whichever combination your app actually needs and your dependency tree stays lean.

What You Don't Have to Write

The boring infrastructure around any transport client - reconnect, fallback, liveness, api key handling - is where most of the bugs in any Solana app quietly live, and it's fundamentally the same work regardless of which protocol you're speaking.

The SDK handles it once, on your behalf, and runs the same implementation across every client. When a socket drops, the subscriptions you had on it get re-registered against the new connection. When a primary endpoint starts misbehaving, the client backs off and cycles through whatever fallback URLs you chained onto the builder, bringing the primary back into rotation once it recovers.

And anywhere a URL might end up in an error log, the api key gets redacted out of it first and you start grepping your tracing output.

In a Real Project

Most apps built on the SDK end up with roughly the same shape. You construct the clients you need up front, hand them off to whichever parts of the app are going to use them, and let the SDK manage the underlying connections for the lifetime of the process.

use orbitflare_sdk::{
    GeyserClientBuilder, Result, RpcClientBuilder, WsClientBuilder,
};

#[tokio::main]
async fn main() -> Result<()> {
    let rpc = RpcClientBuilder::new()
        .url("http://ams.rpc.orbitflare.com")
        .build()?;

    let ws = WsClientBuilder::new()
        .urls(&[
            "ws://ams.rpc.orbitflare.com",
            "ws://lon.rpc.orbitflare.com",
        ])
        .build()
        .await?;

    let geyser = GeyserClientBuilder::new()
        .url("http://ams.rpc.orbitflare.com:10000")
        .build()?;

    // ... use rpc, ws, geyser
    Ok(())
}

The demo we're going to build over the rest of this post is a small wallet ticker. You pass in a pubkey at the command line, and the program prints a live view of that wallet's SOL balance along with every token account it owns, updating the display in place as the balances change. Around 120 lines of code end to end.

It uses the same pattern the code sketch above hinted at. The RPC client handles the bootstrap - one get_balance for the SOL side, one get_token_accounts_by_owner for the SPL tokens, and a handful of small lookups to decorate each account with its mint's decimals so the output reads as token amounts rather than raw integers.

From there the WebSocket client takes over: we open an account_subscribe for the wallet itself and one for each token account we found, merge the updates into a single stream inside the app, and redraw the dashboard whenever any of them tick. The RPC client gets you the starting state; the WebSocket client keeps it honest from there.

Setting Up the Project

Create a new Cargo project and pull in the dependencies you'll need:

[package]
name = "wallet-ticker"
version = "0.1.0"
edition = "2024"
rust-version = "1.85"

[dependencies]
orbitflare-sdk = { version = "0.2.0", features = ["rpc", "ws"] }
tokio = { version = "1.52.1", features = ["full"] }
serde_json = "1.0.149"
base64 = "0.22.1"

orbitflare-sdk with the rpc and ws features gives you exactly the two transports this project uses and nothing else.

Tokio's full feature is convenient for a tutorial; in a production app you'd bare that down to the runtime pieces you actually rely on.

base64 and serde_json show up because WebSocket account updates arrive as base64-encoded bytes wrapped in a JSON envelope, and you'll be reaching into both.

Building the Clients

RpcClient::build is synchronous; WsClient::build is async because it actually opens the socket. The Arc wrap on ws is there because each subscription will live in its own tokio::spawn and they all need to reach the same underlying connection:

let rpc = RpcClientBuilder::new()
    .url("http://ams.rpc.orbitflare.com")
    .commitment("confirmed")
    .build()?;

let ws = Arc::new(
    WsClientBuilder::new()
        .url("ws://ams.rpc.orbitflare.com")
        .build()
        .await?,
);

The Bootstrap

Pulling the wallet's current state is two RPC calls:

let mut sol_lamports = rpc.get_balance(&wallet).await?;
let raw_tokens: Vec<Value> = rpc
    .get_token_accounts_by_owner(&wallet, None, None)
    .await?;

get_token_accounts_by_owner returns each entry in jsonParsed encoding, so the mint address, token amount, and decimals are already structured fields you can lift straight into a HashMap<pubkey, Holding>. The pubkey you key by is the token account's own address - that's the id you'll subscribe to in the next step, not the mint.

Subscribing Concurrently

Once you have the list of accounts, you need one subscription for the wallet itself and one per token account. The shape that works is a tokio::spawn per subscription sharing an Arc<WsClient>, with all of them pushing updates into a single mpsc channel the main loop drains:

let ws = Arc::new(ws);
let (tx, mut rx) = mpsc::channel::<Update>(1024);

for pubkey in holdings.keys().cloned().collect::<Vec<_>>() {
    let ws = Arc::clone(&ws);
    let tx = tx.clone();
    tokio::spawn(async move {
        let Ok(mut sub) = ws.account_subscribe(&pubkey, "confirmed").await else {
            return;
        };
        while let Some(v) = sub.next().await {
            // decode v["data"][0] as an SPL token account,
            // then send an Update down tx
        }
    });
}

The tokio::spawn is what makes this scale. A naive for pubkey in ... { ws.account_subscribe(...).await? } loop works too, but it serializes one subscribe per round-trip. That's fine for a dozen accounts, painful for a few hundred, and flat-out unusable on wallets with thousands of token accounts. Spawning lets every subscription open in parallel, and the first updates start landing in the channel before the last subscribe ack even comes back.

The Render Loop

Everything comes together in a short loop that reads the next update, mutates local state, and redraws:

while let Some(update) = rx.recv().await {
    match update {
        Update::Sol(lamports) => sol_lamports = lamports,
        Update::Token { account, amount } => {
            if let Some(h) = holdings.get_mut(&account) {
                h.amount = amount;
            }
        }
    }
    render(&wallet, sol_lamports, &holdings);
}

Run it against any Solana address:

ORBITFLARE_LICENSE_KEY=ORBIT-KKKKKK-EEEEEE-YYYYYY cargo run --release -- <pubkey>

You'll see the dashboard populate within a few hundred milliseconds as the RPC bootstrap lands, then each line ticks in place the moment something touches the wallet on-chain:

wallet: CKs1E69a2e9TmH4mKKLrXFF8kD3ZnwKjoEuXa6sz9WqX

  SOL     0.040420950
  EPjF...Dt1v      42.500000
  So11...1112       0.005000

Ctrl+C to quit. The full source - about 140 lines of Rust end to end, including the render function, the state types, and the bootstrap parse loop - is linked at the bottom of the post.

That's about it for the SDK in broad strokes - a builder per transport, a shared error and retry story, and the reconnect and fallback work kept inside the crate where you don't have to think about it.

The ticker above is the smallest app that meaningfully exercises more than one of the clients at a time, but the shape scales up from there: the same pattern works just as well when you're stitching together a copy trader, a liquidation monitor, or anything else that needs to move between one-shot reads and live streams in the same loop.

With the SDK in place, the plumbing is off your plate and what's left is the part of the project that's actually yours to build. Which, for most of us, is the only reason we started one in the first place.

Resources

If you build something with the crate, or run into a rough edge that should be smoother, we'd love to hear about it and help you out!