The latency problem with standard RPC
Most applications read Solana through JSON-RPC: you poll an endpoint, or subscribe to a WebSocket, and the node answers with confirmed data. That model is perfectly fine for wallets, explorers, and dashboards. It is not fine when you are competing for an arbitrage opportunity that exists for a few hundred milliseconds.
The issue is when the data becomes available. By the time a transaction is visible through a typical confirmed-commitment RPC response, the network has already done the work of receiving it, replaying it, voting on it, and rolling it into a block your node considers settled. Every one of those steps is latency you inherited but never chose.
For high-frequency strategies, the winning move is to read state as far upstream as physically possible - at the moment data is propagating, not after it has settled. That upstream point is the shred.
So what exactly is a shred?
When a Solana validator is the leader, it packs transactions into entries and produces a block. Rather than broadcasting that block whole, the leader splits it into small pieces called shreds - each a network-sized packet of block data. Shreds are erasure-coded (so a receiver can reconstruct missing pieces) and propagated across the cluster through Solana's Turbine tree, validator to validator.
There are two flavours worth knowing: data shreds, which carry the actual serialized entries, and coding shreds, the erasure-recovery parity. Stitch enough data shreds for a slot back together - "de-shredding" - and you can reconstruct the entries, and from the entries, the individual transactions.
Shreds are how a block travels. Read them and you're seeing transactions in flight - not after they've landed.
This is the key insight: shreds exist and move before any single validator has finished assembling the full block and certainly before your RPC node would surface it at a confirmed commitment. Tap into that stream and you collapse the gap between "the network knows" and "you know."
Shreds vs RPC vs Geyser gRPC
There are three common ways to read Solana, each sitting at a different point on the latency curve. They are complementary, not mutually exclusive - most serious pipelines use more than one.
| Method | Earliest view | Best for |
|---|---|---|
| JSON-RPC | Confirmed | Wallets, explorers, history |
| Yellowstone gRPC | Processed | Real-time account & tx streams |
| Decoded shreds | In-flight | HFT, MEV, first-seen detection |
Geyser-based gRPC (the Yellowstone plugin) is a big step up from polling - it pushes account, slot, and transaction updates to you as the validator processes them. Shred streaming sits one notch further upstream still: you're decoding from the propagation layer itself.
Decoding transactions from shreds
Raw shreds aren't directly useful to a strategy - you want decoded transactions: instructions, accounts, programs. The pipeline looks roughly like this: ingest shreds for a slot, reassemble entries, deserialize transactions, then decode against the relevant program layouts. rpc edge does this for you and hands the result over a gRPC stream:
// stream decoded transactions, straight from shreds
const stream = await rpcedge.subscribe({
endpoint: "grpc://iad1.rpcedge.com:443",
source: "shreds",
decode: true,
filter: { programs: [ RAYDIUM, PUMP_FUN ] },
});
for await (const tx of stream) {
// tx is fully decoded, first-seen, pre-confirmation
strategy.onTransaction(tx);
}The result is a transaction object you can act on immediately, arriving at the earliest moment the network made it observable. For a searcher, that head start is the entire game.
Want decoded shreds on your strategy?
rpc edge streams them co-located with the cluster - the earliest view, fewest hops.
Location is half the latency
Decoding from shreds only helps if the shreds reach you quickly. Every network hop between the leader and your decoder is time your competition might not be paying. This is why rpc edge racks its infrastructure beside Solana stake clusters and the Jito Block Engine, and aggregates shreds from multiple sources so you always get whichever copy arrives first.
When to use shred streams - and when not to
Reach for decoded shreds when:
- You're running latency-sensitive strategies - arbitrage, sniping, MEV.
- "First-seen" matters more than "fully settled."
- You can handle pre-confirmation data and reconcile against finality yourself.
Stick with RPC or gRPC when:
- You need guaranteed, confirmed/finalized state (accounting, settlement).
- You're building user-facing reads where correctness beats milliseconds.
In practice the strongest pipelines layer all three: shreds for first-seen signal, gRPC for live account state, RPC for confirmed truth. rpc edge offers each as a first-class product so you can compose the stack your strategy actually needs.
The takeaway
If you remember one thing: the fastest place to read Solana is the propagation layer, not the confirmation layer. Shreds are that layer. Decode them close to the cluster and you've given your strategy the earliest possible view of the network - the head start that decides who lands first.