The expensive mistake is the wrong class

"Just use gRPC" is the new "just poll faster." Both can be right. Both are wrong as defaults.

If you are building a portfolio page, a shred firehose is theater. If you are competing for the same liquidation as ten other bots, a 500ms poll loop is a gift to your competitors. The fix is a decision matrix you can put in a design doc before you open a pricing page.

We already covered pieces of this ladder in Why RPC Polling Can't Keep Up, Yellowstone gRPC vs Standard RPC, What Are Solana Shreds, and Deshred vs Processed. This post is the chooser: one table, three workloads, explicit anti-patterns.

A stream is a contract about when you learn, what commitment that means, and who owns the gaps.

Step 1: name the workload

Workload"Good" meansWrong default
Interactive appUsers see balances and history that match reality; boring opsFull shred stack for a settings page
Complete indexerNo silent holes; resume after crash; reproducible orderEarliest signal without a completeness plan
Latency traderFirst usable signal + a send path that can actFeature-rich API a region away from stake

You can run all three in one company. You almost never run them on one connection design.

Step 2: the Solana stream ladder

Rows are classes, not brand SKUs. Lag numbers are order-of-magnitude teaching aids, not a bench of any single vendor.

ClassHow you learnLag classReconnect / gapsOpsUse whenWrong when
1. Polling JSON-RPCClient asks on a timerPoll interval + RTT (often hundreds of ms of structural staleness)Re-query; no stream cursorLowOne-shot reads, low-frequency jobsContested trading, dense live state
2. WebhooksProvider HTTP callback after an eventAfter process/confirm class eventsProvider retry variesLow-medAlerts, async side effectsSub-second loops
3. Standard WebSocketaccountSubscribe / logs-style pushBetter than poll; commitment-boundYou own retry + resyncMedFew accounts, simple live UIThousands of accounts
4. Enhanced / hardened WSS classPush with better filters/resilienceSame commitment family as the nodeBetter than bare WSSMedProduct live UI without self-running GeyserTrading-scale multi-filter fan-out
5. Geyser-class gRPC (Yellowstone-shaped)Plugin pushes accounts/txs/slotsAs-processed (or higher if you request it)Client reconnect unless the product persistsHigh if self-host; med if managedBots, live indexers, filtered firehosesSingle balance once a minute
6. Shred / deshred-classPropagation-layer fragments (and early reassembly)Earliest network view; not confirmed truthComplex; bad decode = wrong worldHighestHFT / RFQ / liquidationsWallet truth, compliance replay alone

How to run the matrix in five minutes

  1. Circle the workload in step 1.
  2. Circle the minimum class in step 2 that still hits "good."
  3. Write: I accept lag class X. I own reconnect story Y. Signal is / is not user-visible truth.
  4. Only then pick a provider and a SKU.

That order saves more money than any annual discount.

Step 3: commitment is part of the stream contract

Streams deliver updates at a commitment, or before commitment in the shred case.

LevelOperator reading
ProcessedRuntime/leader view; can fork away
ConfirmedSupermajority voted; still not "paint the bank balance" for every product
FinalizedDeep confirmation; slowest safe class for many user-truth UIs

Rules we use with customers:

  • User-facing balances and receipts → confirmed or finalized on the read-after-write path
  • Strategy "something is moving" → processed or shred-class as signal
  • Indexer durability → define whether confirmed is enough and how you catch up to finality

Mixing shred-class first-seen into a row labeled finalized is how you ship ghost state. See Solana Commitment Levels Explained.

Step 4: anti-patterns that burn a quarter

Anti-patternFailure modeFix
Serverless long-lived gRPCCold starts and idle killsAlways-on workers; persistence if you need gap fill
One stream for all ICPsOptimize the wrong tailSplit by workload
Poll harderRate limits + half-interval stalenessClimb the ladder
gRPC for everythingOps tax without benefitStay on poll/WSS until live requirements appear
Earliest signal as ledger truthBad UI, bad fillsDual path: signal + settlement read
Great stream, weak sendYou see the opportunity and lose the landPair with landing path (why txs fail, sender paths)

Step 5: where rpc edge sits on the ladder

We build for the latency trader and latency-sensitive bot row: co-location with stake and Jito, decoded shreds, Yellowstone gRPC where you need filtered live state, and a transaction sender that can act when the signal is real.

That is not a claim that we are the best dashboard API or the best multi-chain indexer. Those jobs often want a different class on the ladder. The matrix exists so you can say that out loud.

If your circled row is 6 or hard 5 with a serious send path, start with pricing and the Solana RPC product. If your row is 1-3, keep life simple: JSON-RPC and light push are fine, and you should not pay for a trading topology you will not use.

Building on the latency end of the ladder?

rpc edge is for first-seen signal and landing under contention. If that is your row, we should talk. If it is not, the matrix above still saves you a bad contract.

View plans & pricing →

One week reliability (before you buy three SKUs)

Pick one workload and one class.

Done means:

  • Process stayed up without babysitting
  • Gaps were zero or detected
  • Reconnect is explainable in two sentences
  • You did not upgrade classes mid-week out of FOMO

That is the same discipline as any production loop: a trigger, a capable path, and verification. Here verification is gap detection plus a commitment policy, not a unit test.

Bottom line

Streaming is a ladder of contracts. Name the workload, pick the minimum class, write the reconnect story, and never confuse first-seen signal with finalized truth. The teams that win are not the ones with the most streams. They are the ones who bought the right row and measured it honestly.

Frequently asked questions

What is the best Solana streaming method?
There isn't one. Interactive apps, complete indexers, and latency traders need different lag and completeness contracts. Pick the minimum stream class that matches the job: poll or webhooks for simple alerts, WSS for light live UI, Geyser-class gRPC for multi-filter live state, shred-class signal for first-seen trading.
Is Yellowstone gRPC always faster than WebSockets?
gRPC is usually the right push model when you need server-side filters and high fan-in. It still delivers at a commitment you choose (often processed). It is not automatically earlier than shred-class signal, and it is overkill for a single balance poll once a minute.
When should I use shreds instead of gRPC?
When first-seen signal is the product: contested arb, liquidations, RFQ, sniping. Shred-class reads sit at the propagation layer, before a finished block is assembled. Treat that as signal, not finalized ledger truth, and keep a confirmed/finalized path for settlement-grade decisions.
Can one stream serve my wallet UI and my trading bot?
You can share a provider. You should not share one connection design. UI wants stable, user-true balances; the bot wants earliest usable signal and a separate landing path. Split by workload or you will optimize the wrong tail.
How does rpc edge fit this matrix?
rpc edge is built for the latency end of the ladder: co-located reads, first-seen decoded shreds, and a send path tuned for landing under contention. For pure developer indexing APIs or multi-chain dashboards, a general-purpose platform may fit better. Match architecture to the row you circled in the matrix.