The RPC Layer That Cut the Cord

The Validator Pretense

Here is the thing most people miss. A Solana RPC node — the server your app actually talks to when it reads the chain — isn't a separate piece of software. It's a validator (the program that runs Solana's consensus) started with the --full-rpc-api flag and told not to vote. Otherwise it does all the same work: replaying every slot, holding the full account state in memory, gossiping with the network. So when you call getBalance, you're really talking to a process that still thinks of itself as a consensus participant. The read path got stuck with every constraint of the write path — heavy memory, expensive disk, fighting for resources with replay, and a tight coupling to the leader's tick rate (how fast the network produces blocks).

That was fine when Solana was small. It isn't fine now. Public RPCs throttle you, dedicated nodes cost thousands a month, and the bandwidth you need to serve a busy dashboard or indexer (a service that scans the chain and builds a searchable copy) is wildly out of proportion with the bandwidth you need to actually run consensus. Three providers — Helius, Triton One, and FluxRPC — answer that demand in different ways. The first two build products on top of the existing model. The third tears the model up.

Helius: RPC as Developer Platform

Helius is the closest thing Solana has to a default RPC provider. Under the hood, every Helius endpoint still sits on a validator running in RPC mode. But what you're actually paying for is the layer wrapped around it: webhooks (the server pings you when something happens, so you don't have to keep asking), DAS (the Digital Asset Standard, a single API for token / NFT / compressed-NFT queries), Enhanced Transactions that hand you parsed, human-readable history, getTransactionsForAddress (a paginated address-history endpoint that plain RPC just doesn't have), Sender for getting your transactions to land during congestion, and LaserStream — a drop-in Yellowstone gRPC (the binary streaming protocol Solana uses for live data) with multi-region failover, historical replay, and auto-reconnect.

There are four pricing tiers: Free ($0), Developer ($49), Business ($499), Professional ($999). The April 2026 unlock pushed LaserStream gRPC down from Pro-only to Business (10 concurrent connections), and put Enhanced WebSockets with transactionSubscribe on Developer (up to 100 subscriptions per connection). Streaming traffic is metered at 20 credits per 1MB — $100/TB after the 33% cut earlier in 2026.

What's genuinely unique to Helius — not just a nicer wrapper around plain RPC — is the DAS API (one query gives you ownership and metadata for SPL tokens, regular NFTs, and ZK-compressed NFTs in a single shape), the webhook system (it pushes events to you instead of making you poll, with the payloads already parsed), Enhanced Transactions, and the LaserStream stack covered in section 04. Everyone else either matches these by integrating Helius, builds them from scratch, or just skips them. Reach for Helius when the thing slowing your team down is engineering time, not microseconds.

Devnet vs Mainnet, Three Stances

Helius is the only one of the three that treats devnet — Solana's free test network — as a first-class environment. Devnet on the $0 plan gives you 1M credits/month, the full DAS API, webhooks, and Enhanced Transactions. From April 2026 the Developer tier added LaserStream on devnet too. For builders that means something concrete. You can prototype an NFT marketplace, indexer, or DeFi UI against the devnet endpoint, exercise the exact same webhook payloads and DAS queries you'll use in production, and pay nothing until traffic bumps you up a tier.

On mainnet — the real network, with real money — the four tiers gate three things: requests per second, sendTransaction throughput, and access to the streaming stack. Business ($499) is now the practical floor for serious indexers and DeFi apps: 200 RPC req/s, LaserStream gRPC, the full webhook fleet, and the bandwidth to actually serve a frontend at retail volume. Professional ($999) adds higher RPS, multi-region routing, and Sender for landing transactions under contention.

Triton on devnet. Triton lists devnet in their network coverage, and the Yellowstone gRPC interface works against it — handy when you're testing a gRPC client before you point it at a mainnet stream that meters you. But the products that justify Triton's price floor — Professional Trading Centers, dedicated co-located nodes, Cascade SWQoS bandwidth, the Old Faithful historical archive — are mainnet-only by design. On devnet there's no MEV (the profit you can extract by ordering transactions) to race for, no liquidity to make markets in, and no historical archive to backtest against, because it doesn't exist. So the sensible Triton devnet workflow is simple: wire up the client, hit shared RPC, then move to mainnet with the dedicated node the day you go live.

FluxRPC on devnet. Not currently advertised in 2026. The public endpoints, the Lantern sidecar binary, the bandwidth-priced billing, and the EU/US regional routing are all built for mainnet. FluxRPC's whole pitch — caching hot mainnet account state right next to your application — has no real devnet equivalent, because devnet accounts are throwaway and rarely hot. So the realistic path is to prototype against Helius free-tier devnet, get the integration working, then move the production read path to FluxRPC mainnet on launch day. Lantern plus a FluxRPC mainnet key is a deployment-day change, not a development-time one.

What actually differs at the RPC-call level. The JSON-RPC method names are identical — getAccountInfo, getProgramAccounts, sendTransaction, getRecentPrioritizationFees — but the behavior drifts in ways worth rehearsing on devnet before they bite you on mainnet. requestAirdrop works on devnet (the faucet rate-limits it) and does nothing on mainnet. getRecentPrioritizationFees returns near-zero on devnet and the real, contested distribution on mainnet — so if you only ever read devnet values, your priority-fee logic ships untested. sendTransaction lands easily on devnet with the defaults; on mainnet under congestion it fails silently unless you bundle through Jito, route through Helius Sender, or buy Triton Cascade bandwidth. Account-state freshness is basically never a problem on devnet, because nothing is competing for the leader; on mainnet it's the central problem that FluxRPC's HEAD-slot reads and LaserStream replay both go after. Devnet teaches you that your client decodes correctly. Mainnet teaches you that landing a transaction is a whole separate job.

LaserStream SDKs: 40× Throughput Behind a Drop-In

If LaserStream is Helius's answer to "build me a reliable Yellowstone consumer," the LaserStream SDKs released in 2026 are the answer to "do it in one line." Three ship today: JavaScript/TypeScript, Rust, and Go. All three expose an interface that's byte-compatible with Yellowstone gRPC, so you swap the endpoint and the auth token in an existing Yellowstone client and touch nothing else. Everything that's usually painful — connecting, retrying, slot tracking, decompression, regional failover — happens inside the library.

The JavaScript SDK is the clever one. The streaming engine, gRPC connection management, protobuf serialization (the binary message format), and slot tracking are all written in Rust; only your application logic runs in JavaScript. NAPI bindings (Node's native-addon interface) move data across the boundary without copying it. Published throughput is 1.3 GB/s sustained versus 30 MB/s for a pure-JS Yellowstone client — 40×. The reason is mechanical. The JavaScript event loop is no longer in the hot path, so the moment your consumer has to keep pace with mainnet block velocity, the SDK lets it do that without burning CPU on JSON parsing. For Go and Rust users the headline matters less — they were already fast — but the real win is that all three languages get the same features.

Slot-based replay is the standout reliability feature. The SDK remembers the last slot it acknowledged; if it disconnects, it asks the upstream to pick up from exactly that point. The advertised recovery window is up to 24 hours, which means a multi-hour incident no longer turns into a missed-events postmortem — the consumer just catches up and keeps going. Dedicated nodes that don't support replay simply opt out with replay: false. Auto-reconnect uses exponential backoff, and multi-region failover routes around regional outages. Zstd compression on the wire delivers a stated 70–80% bandwidth reduction — which matters because LaserStream traffic is metered at 20 credits per 1MB, so the compression is also a direct cut to your bill.

The named adopter is DFlow, which uses LaserStream to power real-time order flow and execution monitoring — a job where a missed account update is a missed trade. The bigger point: the LaserStream SDKs make a whole category of work disappear. A serious gRPC consumer used to need a small infrastructure team to build retry, resume, decompression, and language-specific protobuf handling on top of raw Yellowstone. With the SDKs, that work becomes "import the library." The question shifts from "do we have the engineers to maintain a gRPC client" to "do we have the engineers to write the strategy that uses it."

Triton One: Validator-Adjacent Infrastructure

Triton One is the older operator, and the more technically uncompromising one. Triton wrote the open-source Yellowstone gRPC plugin that the rest of the ecosystem — including Helius's LaserStream — is either a drop-in for or a fork of. Their pricing tells you who they're for: pay-as-you-go on shared RPC, $2,900/month and up for dedicated nodes, no tier-gated throttling or overage premiums. The customer is a market maker, a validator operator, or a trading firm that already knows it needs co-location (servers physically near the validators) and gRPC.

Project Yellowstone, Component by Component

"Project Yellowstone" is the umbrella name for Triton's stack. The pieces map cleanly to use cases, and they're worth naming one by one, because each is a deliberate piece of infrastructure rather than a marketing bundle.

The Triton extreme is the Professional Trading Center: a co-located, optimized package with local Jupiter, direct validator paths, gRPC streams, and custom indexes deployed right next to the validator. You don't reach for that on devnet. Devnet on Triton exists, but it isn't the focus — devnet is about iteration speed, and Triton sells you the opposite. Use Triton when you have to win a transaction race against another team that's also reaching for Triton.

FluxRPC: The Validator Layer, Removed

FluxRPC is the architecturally interesting one, and the reason it took the Infrastructure Track ($25,000 USDC) at the Solana Breakout Hackathon in May 2025. Both Helius and Triton ultimately serve data from RPC-mode validators. Even when they wrap a beautiful product layer on top, the bottom of the stack is still a validator process. FluxRPC's claim is that the RPC layer doesn't need to be a validator at all. They pull chain state in through their own pipeline, hold it in a purpose-built store, and serve it without paying the consensus tax. That buys you three things you can actually feel.

First, you pay for bandwidth, not requests. $0.06 per gigabyte, 10 GB free, top-up in crypto or fiat. A getBalance call moves 0.5KB, so 2 million calls cost $0.06. There are no per-second rate limits in the Helius sense and no tier-gating in the Triton sense — you pay for what comes down the wire. For bursty, read-heavy workloads (dashboards, indexers, leaderboards) that's genuinely cheaper than either competitor.

Second, the data is HEAD slot — the very latest confirmed state. FluxRPC returns that directly, rather than serving a snapshot that may lag the leader. Combined with their own ingestion pipeline, this kills the "is my read fresh?" question that creeps into deployments juggling several RPCs.

Third, FluxRPC ships a local cache called Lantern. This is the choice that sets the architecture apart from a standard hosted RPC. A standard RPC sells you a URL; FluxRPC sells you a URL and a binary you run next to your application, fed by selective streams from the upstream. Account reads hit your local process, not the wire.

Lantern: The Cache You Run Yourself

Lantern is a sidecar process — a small helper program that runs alongside yours. You hand it your FluxRPC API key once, tell it which programs and accounts you care about, and it keeps a live, edge-cached copy of that subset in RAM or on disk. Your application then points Connection at http://localhost and reads from the local process. Latency on getAccountInfo and getMultipleAccounts drops to 0.1–0.25ms, throughput climbs past 10k requests per second, and the upstream API key never leaves the ops box.

The trade-offs are real and worth stating. Lantern is mainnet-focused; devnet support isn't currently advertised the way it is on Helius. Cache freshness depends on how Lantern is configured and how aggressively FluxRPC pushes updates — so for fast-moving accounts (an active CLOB market, an oracle price feed) you still want the upstream HEAD-slot read on the critical write path. And Lantern is read-side only: you still submit transactions through the standard channel, with the same landing problem every other Solana developer has.

The interesting move isn't making RPC faster. It's noticing that the RPC node never needed to be a validator in the first place.

Calling It: What the Wire Actually Looks Like

In marketing, the providers differentiate on features. On a latency dashboard, the thing that actually separates them is the wire format — how the request and response are encoded as they travel. A JSON-RPC call is text over HTTP/1; a gRPC stream is binary protobuf over HTTP/2; a Lantern read never leaves your process. Same data on the screen, three orders of magnitude apart on the chart. What follows is the same read — "tell me the state of this account" — done four ways, with the cost of each spelled out.

1. HTTP JSON-RPC. Every Solana endpoint — Helius, Triton, FluxRPC, public RPC — accepts the same protocol: POST a JSON envelope, parse a JSON envelope back. id is yours to echo, method is the call name, params is a positional array.

curl https://mainnet.helius-rpc.com/?api-key=<KEY> -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc":"2.0","id":1,"method":"getAccountInfo",
    "params":["So11111111111111111111111111111111111111112",
              {"encoding":"base64","commitment":"confirmed"}]
  }'

What the wire costs: one TCP round-trip (three for a cold TLS handshake), one HTTP request, one JSON parse on each side. The response carries the full account state — lamports (Solana's smallest unit of currency), owner, executable flag, and the raw account data base64-encoded. Roughly 200–500 bytes for a small account, KBs for an SPL mint, larger for an AMM pool. There's no streaming — if the account changes a second later, you have to ask again.

2. WebSocket subscription. Same JSON envelope, but the connection stays open and the server pushes to you when the account changes. The first response is a subscription handle (an integer); after that, every change ships a notification through the same socket.

const ws = new WebSocket("wss://mainnet.helius-rpc.com/?api-key=<KEY>");
ws.onopen = () => ws.send(JSON.stringify({
  jsonrpc: "2.0", id: 1, method: "accountSubscribe",
  params: ["7XSQ...", {encoding: "jsonParsed", commitment: "confirmed"}]
}));
ws.onmessage = e => handle(JSON.parse(e.data));

Why this beats polling: zero per-update round trips, no rate-limit budget burned re-asking the same question, and latency drops to leader-to-you propagation (400ms at confirmed) instead of leader-to-you plus however long your poll interval is. What's left to pay is a JSON parse per message plus WebSocket framing overhead — and that's exactly what gRPC removes.

3. gRPC stream (Yellowstone / LaserStream / Dragon's Mouth). All three providers' streaming products wrap the same Geyser.Subscribe service. You send a SubscribeRequest saying which accounts, programs, and transactions you care about; the server returns a SubscribeUpdate stream of binary protobuf messages.

import { LaserstreamClient } from "@helius/laserstream";
const client = new LaserstreamClient({ endpoint: "...", apiKey: "..." });
const stream = client.subscribe({
  accounts: { mine: {
    owner: ["TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"],
    filters: []
  }}
});
for await (const update of stream) { handle(update); }

This is the fastest network call available, for three reasons. (a) Binary protobuf, not JSON. A SubscribeUpdate for a 165-byte token account is 200 bytes on the wire; the same payload over JSON-RPC is 600 bytes after base64-encoding data plus the envelope overhead. Zstd compression on LaserStream cuts another 70–80%. (b) HTTP/2 multiplexing. Many subscriptions share one TCP/TLS connection — WSS gets you this too, raw HTTP JSON-RPC does not. (c) No event-loop tax (the LaserStream JS SDK move): the Rust core decodes protobuf and tracks slots off the JS thread, then hands decoded objects in via zero-copy NAPI. Pure-JS Yellowstone clients top out at 30 MB/s; the LaserStream JS SDK sustains 1.3 GB/s.

4. Lantern local cache. The architectural outlier. The call goes to http://localhost — your application talks to a sidecar process on the same machine, which holds the account state in RAM, fed by an upstream FluxRPC push stream. No network round-trip, no TLS, no JSON over the wire at all.

const conn = new Connection("http://localhost:8080"); // not a remote URL
const info = await conn.getAccountInfo(new PublicKey("..."));

This is the fastest call, full stop. You're reading from a hash map in RAM, not from a remote validator. Latency drops to 0.1–0.25ms, throughput climbs past 10k req/s. The trade-off: freshness depends on how aggressively the upstream pushes — so for fast-moving accounts (active CLOB markets, oracle feeds) you still want an upstream HEAD-slot read on the critical write path, with Lantern serving everything else.

What Each Call Actually Retrieves

The wire cost is only half the bill. The other half is the payload — how many bytes the call actually has to move. getAccountInfo on a token mint is two orders of magnitude cheaper than getProgramAccounts on the same program. A streaming subscription is cheaper per update than the equivalent polling pattern, but it uses bandwidth continuously. The matrix below is the back-of-envelope math every Solana team works out at some point.

getProgramAccounts is the famously punishing call — the vanilla implementation scans every account owned by the program and serializes it. That's why Triton sells Steamboat (a maintained side-index), why Helius offers getTransactionsForAddress as the operation people actually wanted instead, and why the "cheap RPC" question falls apart the moment your indexer fires even one of these a minute. The number on the spreadsheet isn't $/credit — it's $/credit × bytes-per-call × calls-per-second. A polling-heavy frontend hitting getAccountInfo a thousand times a minute, and a streaming indexer that subscribes once and listens forever, live in completely different price regimes on the same provider. The wire format decides which one you're in.

How a Block Actually Works (and What Dragon's Mouth Hands You)

Every subscription type in the previous sections filters or returns one of the same five primitives: a slot, a block, an entry, a transaction, or an account update. If you don't know what those primitives are, the gRPC stream is just opaque bytes and the JSON-RPC response is unreadable nesting. So this is the mental-model section. The Dragon's Mouth subscription docs are the canonical reference; what follows is the working developer's digest.

1. Slot, block, entry, transaction — the hierarchy. A slot is a 400ms time bucket. The leader (the validator whose turn it is to produce blocks) assigned to that slot tries to produce a block; if it succeeds, the slot has a block, and if it skips, the slot is empty. A block holds a sequence of entries — sub-block batches that exist mainly so validators can run non-conflicting transactions in parallel. Each entry holds a list of transactions, the atomic unit of state change. A transaction in turn holds one or more instructions, each aimed at a specific program. The thing most developers underestimate: 85–90% of mainnet transactions are vote transactions — validators voting on consensus, not user activity. Filter them out (vote: false) or your stream is mostly noise.

2. The block as a struct. A Dragon's Mouth SubscribeUpdate for blocks hands you, in order: slot, blockhash, parent_slot, parent_blockhash, block_height, block_time (Unix seconds), executed_transaction_count, and optionally the transactions array and the updated-accounts array. The fields that actually matter for chain logic are slot (for ordering and fork resolution), parent_slot (to verify the chain is continuous), and blockhash (the unique identifier you reference when signing a transaction, so it can't be replayed on a different fork).

3. The slot lifecycle (why fork-aware code matters). A slot doesn't show up in your stream as a single event. It moves through stages, and Dragon's Mouth surfaces each one as a SlotUpdate: SLOT_FIRST_SHRED_RECEIVED (the first piece of block data hit your validator), SLOT_CREATED_BANK (a fresh execution bank for the slot was spun up), SLOT_COMPLETED (all shreds in, bank fully populated), then eventually SLOT_DEAD (the fork containing this slot was abandoned) or finalized (32 slots (31 confirmations) deep, never to be reverted). Why this matters: if you act on a transaction at processed commitment and the slot later goes DEAD, that transaction is gone — never happened, never charged, never landed. Fork-aware code waits for slot status before treating an account update as "real."

4. Commitment: same slot, three timings. Every subscription takes a commitment level — how sure you want to be before you trust the data. processed is live and can still be reverted; confirmed means a supermajority of stake voted for it; finalized (32 slots (31 confirmations)) means it will never be reverted. The Yellowstone server buffers updates per slot at confirmed/finalized and releases them in slot order once the threshold is hit. The Triton-recommended trick: subscribe at processed and buffer on your side, then release on your own slot notifications. You get the lowest latency and you keep control of the fork-handling logic. Reading confirmed-only is what most teams ship first — and usually regret.

5. The seven Dragon's Mouth subscriptions. A single Subscribe call carries a request with several filter maps, each scoped to a stream type. The same connection can carry accounts + transactions + slots + blocks + block_meta + entries + deshred all at once. Each map key is a label you pick (you get it back in the update, so you know which filter matched).

// One Subscribe call, multiple streams, one connection.
const request = {
  slots:        { all: {} },                                  // every slot status change
  accounts:     { wsol_usdc: {
                    account: ["8BnEgHoWFysVcuFFX7QztDmzuH8r5ZFvyP3sYwn1XTh6"]
                }},                                           // one specific account
  transactions: { non_vote: { vote: false, failed: false } }, // user activity only
  blocks:       {},                                           // off
  blocksMeta:   { headers: {} },                              // light block headers
  entries:      {},                                           // off
  commitment:   CommitmentLevel.PROCESSED                    // live, buffer client-side
};
for await (const update of stream) {
  if (update.slot)        handleSlot(update.slot);
  if (update.account)     handleAccount(update.account);
  if (update.transaction) handleTx(update.transaction);
  if (update.blockMeta)   handleBlockMeta(update.blockMeta);
}

Each of those seven streams hands back a differently shaped payload. The table makes it concrete.

The closing point. A "fast" provider isn't faster than physics — every provider is bounded by leader propagation, how long it takes a block to spread across the network. What they actually differ on is how soon a given slot's data shows up in your stream after the leader produces it (gRPC + co-location wins), how cheaply you can replay if you disconnect (LaserStream's slot replay), and how much of the parsing they do for you (Helius Enhanced Transactions, Triton Vixen). The Triton Dragon's Mouth interface is the original gRPC surface; LaserStream is byte-compatible with it. Once you understand the primitives above, switching providers is just changing an endpoint and an auth token. The data model is the same data model.

Below the Block: Shreds, Turbine, and Pre-Block Reads

Section 11 covered what a block looks like to a consumer of consensus state. There's a layer below that, and most of the "fastest" stories in this article — Jito ShredStream, Triton co-location, the 50–100ms pump.fun cancel window — live there. A block isn't sent as a single object. It's broken into shreds — 1,228-byte fragments of the slot's data — and gossiped across the validator network the instant the leader can serialize them, before the block is even finished. Read the shreds and you read the network in flight.

1. What a shred actually is. There are two kinds. Data shreds carry serialized entries — the transactions themselves. Coding shreds are Reed-Solomon parity fragments (redundant pieces) that let downstream validators rebuild missing data shreds without re-requesting them. Together they form an FEC (forward error correction) set. A block of 1,000 transactions might serialize to, for example, 150 data shreds plus 50 coding shreds; lose any 50 of the 200 and the block is still rebuildable.

2. Turbine: the propagation tree. The leader doesn't broadcast shreds to every validator. It picks a fanout of K direct neighbors (currently 200), each of whom forwards to the next layer. The result is a tree of depth O(log N), where every validator gets every shred in 2–3 hops. A validator's position in that tree decides how soon it sees a shred — neighbors at depth 1 see shreds milliseconds before validators at depth 3. This is the whole physics of the "fast" story. Co-located dedicated nodes (Triton Professional Trading Centers) pay to sit near the top of the tree. ShredStream operators pay to receive shreds at the same depth as a validator without being one.

3. The leader schedule. Leaders are deterministic and announced one full epoch (432,000 slots ≈ 2 days) ahead of time. Each leader gets a 4-slot window (1.6s of block production), then hands off to the next scheduled leader. You can query getLeaderSchedule and know exactly who'll be leader at any future slot. Sniper bots and MEV searchers exploit this directly: they fire their transactions at the next 4 leaders at once through TPU forwards (sending straight to the leader's transaction-intake port), skipping the public mempool entirely.

4. The handoff just got faster (today). The agave validator client merged a "send shred to next leader" patch in May 2026, changing turbine/src/broadcast_stage.rs so the validator scheduled to be the next leader is always included in the shred broadcast targets, no matter the turbine tree topology. The mechanical effect: the next leader gets the previous leader's last shreds at depth-1 instead of waiting for turbine to walk them down the tree, which trims the leader-to-leader handoff window — the gap where one slot is "done" but the next slot's block production hasn't started yet. The strategic implication: the floor on "how soon you can act on incoming flow" is itself moving. Every cancel-race analysis from 2025 needs to be re-benched against the post-patch mainnet.

5. Why this maps back to the three providers.

The mental model that closes this section: block-level streams read settled state, shred-level streams read in-flight state, SWQoS writes into the propagation graph at the top. Different problems, different races, different products. The reason serious teams compose providers (from the roster section) isn't taste — it's that no single provider answers all three of those problems, and the answers live at architecturally different layers of the validator network.

Cross-Comparison Matrix

The three providers aren't competing on a single axis. Helius sells developer time. Triton sells physical edge. FluxRPC sells a different architectural assumption. The matrix below lines up the features so you can compare them.

Use Case Mapping

The matrix is dense. The decision tree underneath is short — pick the provider that matches whatever your real bottleneck is.

Who Actually Uses This: The Roster

The abstract decision tree above is fine. The concrete version — who actually runs which provider behind which product, and what they do with it — makes the picture sharper.

The pattern that falls out of this roster isn't "one provider wins." It's that serious teams mix providers per workload. A pump.fun sniper runs Helius webhooks for new-token signal, Jito ShredStream for the cancel window, and might keep a FluxRPC + Lantern path for the analytics dashboard the trader watches alongside. A Magic Eden runs Helius DAS for the catalog and Triton for any latency-sensitive trade path. The interesting strategic question is no longer "which RPC" — it's "which combination, in what order, for which code path."

Where This Goes

Helius, Triton, and FluxRPC aren't competing for the same dollar. Helius sells developer time — pay $49 to $999 a month and skip a quarter of your backend work. Triton sells physical edge — pay $2,900+ and get the same network position a validator has. FluxRPC sells an architectural bet: an RPC layer that doesn't pretend to be a validator can be cheaper, faster on cached reads, and easier to scale out than either alternative. The Colosseum prize was a recognition that the assumption "RPC = a special-mode validator" had gone unexamined for too long.

The honest starter playbook in 2026: Helius for devnet and most of mainnet shipping; swap individual hot paths to FluxRPC the day bandwidth pricing starts to win on a spreadsheet; reach for Triton the day your business requires winning a transaction race against another team that's also reaching for Triton. The interesting question isn't which provider is best. It's which assumption about the RPC layer is right — and whether validator-coupled RPC will look obvious or quaint five years from now.