- Place each data source on the life cycle of a Solana block
- Compare the five options on timing, completeness and effort
- Pick a starting option for your bot, dashboard or pipeline
In this lesson +
“Real-time” means very different things on Solana. A dashboard that refreshes every few seconds and a bot racing other bots for the same pool both want live data, but they need different sources. This lesson lines up the five options side by side so you can pick the right one the first time.
01Where the data comes from#
Every option below taps the same stream of blocks, just at a different point in its life. A leader breaks its block into small packets called shreds and sends them across the network. Validators and RPC nodes reassemble the shreds, execute the transactions (replay), then publish the results to plugins and clients.
The rule of thumb that falls out of this picture: the earlier you tap in, the faster you see data, and the rawer it is. You buy speed with complexity.
02At a glance#
031. HTTP polling#
Call an RPC method such as getSignaturesForAddress or getAccountInfo on a timer and diff the results. It is how most people start, because it is just the RPC calls you already know in a loop.
- +Works with any endpoint and any language
- +Nothing to keep connected
- +Easy to reason about and test
- −You always find out late, by up to one poll interval
- −Burns requests asking about things that have not changed
- −Easy to hit rate limits as you add addresses
042. WebSocket subscriptions#
Open one connection and subscribe to what you care about: accountSubscribe, logsSubscribe, programSubscribe, signatureSubscribe or slotSubscribe. The node pushes a JSON notification when something changes.
- +Push instead of pull, so far fewer wasted calls
- +Standard Solana API, supported everywhere
- +Fine in browsers and small scripts
- −Notifications are thin: logs often need a follow-up getTransaction
- −Connections drop and need reconnect plus backfill logic
- −JSON encoding gets heavy at high volume
053. Yellowstone gRPC#
Yellowstone gRPC streams data straight from the validator’s Geyser plugin interface over a single long-lived gRPC connection. You send filters (accounts, owners, transactions that mention a program) and get compact protobuf messages with full transaction and account data, as early as processed commitment.
- +Full updates, so no follow-up RPC calls
- +Server-side filters cut bandwidth
- +Binary encoding handles heavy volume well
- −Needs a gRPC client library and protobuf types
- −You still decode program instructions yourself
- −Not usable directly from a browser
Go deeper with our Solana gRPC API guide, the Python walkthrough, and the head-to-head Yellowstone gRPC vs WebSockets benchmark.
064. Shredstream#
Shredstream sends you the raw shreds themselves, over UDP, as they move through the network. You see transactions before the validator has executed them, which makes it the earliest source on this list.
- +Earliest possible view of transactions
- +No per-request overhead: packets just arrive
- +Pairs with gRPC for a confirm step
- −You reassemble shreds and decode entries yourself
- −Needs a server with a public IP and open UDP port
- −Includes data that never confirms
Read the Solana Shredstream guide for the full picture. On NoLimitNodes, Shredstream is included with the Ultra plan and can also be bought on its own.
075. Decoded streams#
Raw transactions are bytes. To know that a transaction was “a 2 SOL buy on PumpFun” you have to decode the program’s instructions against its IDL, and keep those decoders working as programs upgrade. Decoded streams do that work on the server and push typed events with named fields.
- +No decoders to write or maintain
- +Events arrive with human-readable fields
- +Fastest path from idea to working dashboard
- −Limited to the programs and events the provider covers
- −One more layer between you and the raw chain
- −Less control over exactly what is included
NoLimitNodes offers two kinds: curated Enhanced Streams for common DEX and lifecycle events, and Program Streams with per-instruction topics for each supported program.
08How to choose#
Answer three questions in order:
- Do you need to act within a second? If not, polling or WebSockets are enough. Keep it simple.
- Do you want events or raw data? If you want “swap happened, here are the amounts”, start with decoded streams. If you need every byte, use Yellowstone gRPC.
- Is being first worth real engineering time? Only then add Shredstream, usually alongside gRPC to confirm what the shreds suggested.
Whichever you pick, you still need plain HTTP RPC to load starting state, fetch blockhashes and send transactions. Streams tell you what changed; RPC is how you act on it.
Q1Which source sees a transaction earliest, before the validator has executed it?
Q2You want PumpFun trades as typed JSON with no decoding code. Which option fits?
Q3What is the main reason teams move from WebSockets to Yellowstone gRPC?
Frequently asked questions#
What is the fastest way to get Solana data?
Shredstream sees transactions earliest because it delivers shreds before the validator executes the block. The catch is that you decode raw data yourself and some of what you see never confirms.
Is Yellowstone gRPC better than WebSockets?
For production streaming, usually yes: it carries fuller updates, filters server-side and uses binary encoding. WebSockets are simpler to start with and fine for low-volume monitoring.
Do I still need RPC if I use streams?
Yes. Streams push changes, but you still need HTTP RPC to load starting state, fetch blockhashes and send transactions.
What are decoded streams?
Feeds where a provider has already parsed program instructions into typed events, such as swaps or token launches, so you skip writing decoders for each program.
Put this lesson on a live endpoint.
Every example in the Academy runs against standard Solana RPC, WebSocket and gRPC endpoints. Get one in under a minute and follow along with real data.