The RPC Layer
That Cut the Cord

01 — The Validator Pretense

A Solana RPC node is not a separate piece of software. It is a validator running with the --full-rpc-api flag set, declining to vote, but otherwise replaying every slot, holding the full account state in memory, and gossiping with the network. When you call getBalance, you are querying a process that thinks of itself as a consensus participant. The read path inherited every constraint of the write path — heavy memory, expensive disk, contention with replay, and a tight coupling to the leader's tick rate.

This was fine when Solana was small. It is not fine now. Public RPCs throttle, dedicated nodes cost thousands per month, and the bandwidth to serve a high-volume dashboard or indexer is wildly out of proportion with the bandwidth to actually run consensus. Three providers — Helius, Triton One, and FluxRPC — answer the resulting demand differently. The first two layer products on top of the existing model. The third tears the model up.

02 — Helius: RPC as Developer Platform

Helius is the closest thing Solana has to a default RPC provider. Internally every Helius endpoint sits on a validator running RPC-mode, but the value you pay for is the layer wrapped around it: webhooks, DAS (Digital Asset Standard) for unified token / NFT / compressed-NFT queries, Enhanced Transactions that return parsed human-readable history, getTransactionsForAddress (a paginated address-history endpoint that doesn't exist in vanilla RPC), Sender for transaction landing during congestion, and LaserStream — a drop-in Yellowstone gRPC with multi-region failover, historical replay, and auto-reconnect.

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

What is actually unique to Helius — and not just a wrapper around vanilla RPC — is the DAS API (one query returns ownership and metadata for SPL tokens, regular NFTs, and ZK-compressed NFTs in a single shape), the webhook system (push, not poll, with parsed payloads), Enhanced Transactions, and the LaserStream stack covered in section 04. Everyone else either matches these by integrating Helius, builds them from scratch, or ignores them. Use Helius when the binding constraint on your team is engineering time, not microseconds.

03 — Devnet vs Mainnet, Three Stances

Helius is the only one of the three that treats devnet 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. The implication for builders is concrete: prototype an NFT marketplace, indexer, or DeFi UI against the devnet endpoint, exercise the same webhook payloads and DAS queries you will use in production, and pay nothing until traffic moves you up a tier.

On mainnet 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 transaction landing under contention.

Triton on devnet. Triton lists devnet in their network coverage and the Yellowstone gRPC interface works against it, which is useful when you are testing a gRPC client integration before pointing it at a mainnet stream that is metering you. But the products that justify Triton's price floor — Professional Trading Centers, dedicated co-located nodes, Cascade SWQoS bandwidth, Old Faithful historical archive — are mainnet-only by design. There is no MEV competition on devnet to race against, no liquidity to make markets in, and nothing to backtest from a historical archive that does not exist. The pragmatic Triton devnet workflow is "wire up the client, hit shared RPC, then move to mainnet with the dedicated node on 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 mainnet-shaped. FluxRPC's whole value proposition — caching hot mainnet account state next to your application — does not have a meaningful devnet analogue because devnet accounts are throwaway and rarely hot. The realistic FluxRPC adoption path is to prototype against Helius free-tier devnet, validate the integration, then migrate the production read path to FluxRPC mainnet on launch day. Lantern + 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 diverges in ways worth rehearsing on devnet before they bite you on mainnet. requestAirdrop works on devnet (and is rate-limited by the faucet) and is a no-op on mainnet. getRecentPrioritizationFees returns near-zero on devnet and returns the real, contested distribution on mainnet — your priority-fee logic ships untested if you only ever read devnet values. sendTransaction lands trivially on devnet with the default settings; 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 essentially never an issue on devnet because there is no leader contention; on mainnet it is the central problem FluxRPC's HEAD-slot reads and LaserStream replay both target. Devnet teaches you that your client decodes correctly. Mainnet teaches you that landing a transaction is its own business.

04 — 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 of code." Three SDKs ship today — JavaScript/TypeScript, Rust, and Go. All three present an interface byte-compatible with Yellowstone gRPC: swap the endpoint and the auth token in an existing Yellowstone client and the rest of the application is untouched. Everything else — connection, retry, slot tracking, decompression, regional failover — happens inside the library.

The JavaScript SDK is the architecturally interesting one. The streaming engine, gRPC connection management, protobuf serialization, and slot tracking are all written in Rust; only the application logic runs in JavaScript. NAPI bindings move data across the boundary zero-copy. The published throughput is 1.3 GB/s sustained versus roughly 30 MB/s for a pure-JS Yellowstone client — about 40×. The win is mechanical: the JavaScript event loop is no longer in the hot path, so the moment your consumer needs to keep up with mainnet block velocity, the SDK lets it do that without burning CPU on JSON deserialization. For Go and Rust users the headline matters less — they were already fast — but the parity of features across all three languages is the bigger deal.

Slot-based replay is the headline reliability feature. The SDK tracks the last slot it acknowledged; on disconnect it asks the upstream to resume from exactly that point. The advertised recovery window is up to 24 hours, which means a multi-hour incident no longer means a missed-events postmortem — the consumer catches up and continues. 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 cost cut.

The named adopter is DFlow, which uses LaserStream to power real-time order flow and execution monitoring — a workload where a missed account update is a missed trade. The broader strategic point is that LaserStream SDKs collapse a category of work. A serious gRPC consumer used to require 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 gating constraint shifts from "do we have the engineers to maintain a gRPC client" to "do we have the engineers to write the strategy that consumes it."

05 — Triton One: Validator-Adjacent Infrastructure

Triton One is the older operator and the more technically uncompromising one. Triton authored 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 model telegraphs their audience: 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 and gRPC.

06 — Project Yellowstone, Component by Component

"Project Yellowstone" is the umbrella name for Triton's stack. The components map cleanly to use cases and are worth naming individually because each is a deliberate piece of infrastructure, not 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 next to the validator. You don't reach for that on devnet. Devnet on Triton exists but is not the focus — devnet's value proposition is iteration speed, and Triton sells you the opposite. Use Triton when you have to win a transaction race against another team that is also reaching for Triton.

07 — 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 ingest chain state through their own pipeline, hold it in a purpose-built store, and serve it without paying the consensus tax. The user-visible consequence is three things.

First, the pricing model is bandwidth, not requests. $0.06 per gigabyte, 10 GB free, top-up in crypto or fiat. A getBalance call moves about 0.5KB, so roughly 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) this is genuinely cheaper than either competitor.

Second, the data is HEAD slot. FluxRPC returns the latest confirmed state directly rather than serving a snapshot that may lag the leader. Combined with their own ingestion pipeline, this removes the "is my read fresh" question that creeps into multi-RPC deployments.

Third, FluxRPC ships a local cache — Lantern. This is the design choice that separates the architecture 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.

08 — Lantern: The Cache You Run Yourself

Lantern is a sidecar process. You hand it your FluxRPC API key once, declare which programs and accounts you care about, and it maintains 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 is not currently advertised the way it is on Helius. Cache freshness depends on how Lantern is configured and how aggressively FluxRPC pushes updates — for fast-moving accounts (an active CLOB market, an oracle price feed) you still want the upstream HEAD-slot read for 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.

09 — Calling It: What the Wire Actually Looks Like

The providers differentiate on features in their marketing. On a latency dashboard the differentiator is the wire format. 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" — executed four ways, with the cost of each made explicit.

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 cold TLS), one HTTP request, one JSON parse on each side. The response carries the full account state — lamports, 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 is no streaming; if the account changes a second later you have to ask again.

2. WebSocket subscription. Same JSON envelope, persistent connection, server pushes 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 is faster than 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-your-poll-interval. The remaining cost is JSON parse per message plus WebSocket framing overhead — which is precisely 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 declaring 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); }

Why this is the fastest network call available. (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, hands decoded objects in via zero-copy NAPI. Pure-JS Yellowstone clients saturate 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 host, 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("..."));

Why this is the fastest call, full stop. You are reading from a hash map in RAM rather than 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 — 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.

10 — What Each Call Actually Retrieves

The wire cost is only half the cost. The other half is the payload — what 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 uses bandwidth continuously. The matrix below is the back-of-envelope every Solana team builds at some point.

getProgramAccounts is the famously punishing call — the vanilla implementation scans every account owned by the program and serializes it. This is 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 collapses the moment your indexer issues even one of these per minute. The cost on the spreadsheet isn't $/credit — it is $/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 determines which regime you are in.

11 — 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. Without understanding what those primitives are, the gRPC stream is opaque bytes and the JSON-RPC response is unreadable nesting. This is the "mental model" section. The Triton docs for Dragon's Mouth subscriptions 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 assigned to that slot tries to produce a block; if it succeeds, the slot has a block, if it skips, the slot is empty. A block contains a sequence of entries — sub-block batches that exist primarily so validators can execute non-conflicting transactions in parallel. Each entry contains a list of transactions, the atomic unit of state change. A transaction in turn contains one or more instructions, each targeting a specific program. The thing most developers underestimate: roughly 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, optionally the transactions array and optionally the updated-accounts array. The fields that actually matter for chain logic are slot (for ordering and fork resolution), parent_slot (to verify chain continuity), 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 appear in your stream as a single event. It transitions through stages, and Dragon's Mouth surfaces each one as a SlotUpdate: SLOT_FIRST_SHRED_RECEIVED (first piece of block data hit your validator), SLOT_CREATED_BANK (a fresh execution bank for the slot was instantiated), SLOT_COMPLETED (all shreds in, bank fully populated), then eventually SLOT_DEAD (the fork containing this slot was abandoned) or finalized (32+ confirmation lockouts deep, will never be reverted). The reason 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 listens for slot status before treating an account update as "real."

4. Commitment: same slot, three timings. Every subscription takes a commitment level — processed (live, can be reverted), confirmed (supermajority of stake voted for it), finalized (~31 slot lockout, never reverted). The Yellowstone server buffers updates per slot at confirmed/finalized and releases them in slot order when the threshold is reached. The Triton-recommended optimization: subscribe at processed and buffer client-side, then release on your own slot notifications. You get the lowest latency and you keep control of the fork-handling logic. Reading from confirmed-only is what most teams ship initially and what they usually regret.

5. The seven Dragon's Mouth subscriptions. A single Subscribe call carries a request with multiple filter maps, each scoped to a stream type. The same connection can carry accounts + transactions + slots + blocks + block_meta + entries + deshred simultaneously. Each map key is a label of your choosing (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 the surface concrete.

The closing point. A "fast" provider is not faster than physics — every provider is constrained by leader propagation. What providers actually differ on is how soon a particular slot's data appears 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 changing an endpoint and an auth token. The data model is the same data model.

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

Section 11 covered what a block looks like to a consumer of consensus state. There is 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 is not transmitted as a single object. It is 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 complete. Read the shreds and you read the network in flight.

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

2. Turbine: the propagation tree. The leader does not broadcast shreds to every validator. It picks a fanout of K direct neighbors (currently around 200), each of whom forwards to the next layer. The result is a tree of depth O(log N) where every validator receives every shred in 2–3 hops. The validator's position in that tree determines how soon it sees a shred — neighbors at depth 1 see shreds milliseconds before validators at depth 3. This is the entire physics of the "fast" story. Co-located dedicated nodes (Triton Professional Trading Centers) are paying to sit near the top of the tree. ShredStream operators are paying 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) in advance. 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 will be leader at any future slot. Sniper bots and MEV searchers exploit this directly: they send their transactions to the next 4 leaders simultaneously through TPU forwards, bypassing the public mempool entirely.

4. The handoff just got faster (today). The agave validator client merged PR #12428 — "send shred to next leader" on 2026-05-20, modifying turbine/src/broadcast_stage.rs so the validator scheduled to be the next leader is unconditionally included in the shred broadcast targets, regardless of turbine tree topology. The mechanical effect: the next leader receives 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 a 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 post-12428 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 is that no single provider answers all three of those problems, and the answers live at architecturally different layers of the validator network.

13 — Cross-Comparison Matrix

The three providers are not competing on a single axis. Helius sells developer time. Triton sells physical edge. FluxRPC sells a different architectural assumption. The matrix below makes the feature surface comparable.

14 — Use Case Mapping

The matrix is dense. The decision tree underneath is short — pick the provider that aligns with what your binding constraint actually is.

15 — 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 specifically they do with it — makes the picture sharper.

The pattern that falls out of this roster is not "one provider wins." It is 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 may 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 is "which combination, in what order, for which code path."

16 — Where This Goes

Helius, Triton, and FluxRPC are not competing for the same dollar. Helius is selling developer time — pay $49 to $999 a month and skip a quarter of backend work. Triton is selling physical edge — pay $2,900+ and get the same network position a validator has. FluxRPC is selling an architectural bet: an RPC layer that doesn't pretend to be a validator can be cheaper, faster on cached reads, and more horizontally scalable than either alternative. The Colosseum prize was a recognition that the assumption "RPC = a special-mode validator" had been 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 is also reaching for Triton. The interesting question is not which provider is best. It is which assumption about the RPC layer is right — and whether validator-coupled RPC will look obvious or quaint five years from now.