Streaming overview
How to choose between WebSocket PubSub, Yellowstone gRPC, and decoded shreds.
Streaming is the core rpc edge product. Polling is too slow for trading systems that need to react to state changes, transaction flow, or slot progression. The right stream depends on what stage of the Solana lifecycle you need.
Choose a stream
| Stream | Protocol | Best for | Data stage |
|---|---|---|---|
| WebSocket PubSub | WebSocket JSON-RPC | standard SDKs, browser-compatible subscriptions, moderate fanout | processed / confirmed / finalized |
| Yellowstone gRPC | gRPC | backend trading systems, account updates, transaction metadata, slots, blocks | processed / confirmed / finalized |
| Decoded Shreds | gRPC (SubscribeDeshred) | pre-execution transaction intent for latency-sensitive strategies | before processed metadata |
| Raw shreds | UDP or custom stream | teams that want to rebuild shreds themselves | roadmap |
How to think about latency
Raw shreds are earliest, but they require you to handle the lowest-level data and do your own
reconstruction. Decoded Shreds is later than raw shreds because we reconstruct and decode for you,
but it can be earlier than processed transaction metadata and is much easier to consume. Yellowstone
gRPC at processed is the right choice when you need executed account state, logs, metadata, and
normal filters.
Why bandwidth matters
Streaming plans are shaped around bandwidth because subscription breadth directly controls cost and load. A narrow program/account filter can be tiny. A broad block or all-token transaction stream can be a firehose. This is why rpc edge plans expose included bandwidth and why dashboards focus on bytes by transport, method, and subscription family.
Region roadmap
Frankfurt is first. Multi-region is on the roadmap, but we want the next regions to follow real customer demand. Tell us where your trading stack runs in Telegram.