Data Stages
The six stages between a leader's shreds and a parsed transaction, and the stage at which each constant-k product hands data over.
This page describes the stages Solana block data passes through between the leader that produces it and the code that reads it, and the stage at which each constant-k product hands it over.
The six stages
| # | Stage | What happens | What comes out |
|---|---|---|---|
| 1 | Shreds | The leader erasure-codes the block it is producing and broadcasts the fragments over UDP. They arrive out of order, and some never arrive. | Individual shred packets |
| 2 | Erasure decoding | Reed-Solomon recovery. The coding shreds of an FEC set rebuild the data shreds of that set that did not arrive. | A complete set of data shreds |
| 3 | Reassembly, also called deshredding | Shred headers are stripped, the payloads are concatenated in index order, and the Merkle proof and the leader's signature are verified. | A byte stream |
| 4 | Deserialization | Those bytes are read as Entry structures and the transactions inside them. The format is wincode since Agave 4.2, bincode before it. | Entries, and transactions carrying signatures, account keys and instructions |
| 5 | Execution | The bank runs the transactions. | Fees, logs, balance changes, compute units, success or error status |
| 6 | Parsing | Program IDs and instruction data are resolved into named fields. This is what jsonParsed does on Solana RPC. | Instructions as named fields rather than opaque data |
Each stage costs time. Data from an earlier stage arrives sooner and says less about the outcome.
Stage by product
| Product | Stages already done | What arrives | Stages left to the reader |
|---|---|---|---|
| ShredPrism | 1 to 3 | Serialized entries: the byte stream of stage 3 | 4 onwards |
| Turbo Kaldera (aRPC) | 1 to 4 | Decoded pre-execution transactions | 5 onwards |
| Kaldera | 1 to 5 | Executed transactions, accounts, slots and blocks, with execution metadata | 6 |
| Solana RPC | 1 to 5, and 6 where the request asks for the jsonParsed encoding | Executed transactions, accounts and blocks | 6 on any other encoding |
aRPC is constant-k's name for pre-execution transaction streaming. No other provider uses the term.
Filters and the deserialization stage
A server-side account filter matches on account keys, and account keys exist only after stage 4. A feed that stops at stage 3 has none to match against.
| Product | Server-side filters |
|---|---|
| ShredPrism | None. Every slot and every transaction, unfiltered. |
| Turbo Kaldera | Account filters on transactions. See Filters on Turbo. |
| Kaldera | Every Yellowstone filter type. See Filters. |
The word "decoded"
Providers attach "decoded" to different stages, so the word on its own does not identify the stage a feed delivers. The wording below was read from each provider's published documentation on 20 September 2026.
| Provider wording | The stage it names |
|---|---|
| Jito, "decoded transactions", served by the shredstream proxy after it deshreds | Output of stage 4 |
| Helius, "decoded shreds", "preprocessed transactions", "pre-execution data without running a deshredder" | Output of stage 4 |
| Shyft, "raw shreds are small binary-encoded packets, that arrive undecoded", against its own "Decoded transactions" | Everything before stage 4, against the output of stage 4 |
Shreder, "Decoded Shreds", a filtered transaction stream, published alongside a "Binary" tier of "serialized Solana VersionedTransaction bytes" | Output of stage 4, alongside the output of stage 3 |
| QuickNode, "binary-encoded Solana data", "Binary protocol with efficient serialization" | The gRPC wire format, at any stage |
Providers use "binary" as inconsistently: it is a product name at one, an adjective for shred packets before stage 4 at a second, and a description of the gRPC wire format at a third.
Terms constant-k uses
| Term | What it names |
|---|---|
| Shreds | The erasure-coded fragments of stage 1, before reassembly |
| Serialized entries | The stage 3 byte stream that ShredPrism delivers, which the reader deserializes |
| Decoded pre-execution transactions | The stage 4 output that Turbo Kaldera delivers |
| Pre-execution | Any stage before stage 5 |
| aRPC | constant-k's name for pre-execution transaction streaming |
constant-k does not use "binary" for a payload, and does not use "decoded" without the stage it names.