How do Solana slots, blocks, entries, and shreds relate?

4 nouns describe different layers

Slot, block, entry, and shred are often used as though they name different sizes of the same object. They do not.

A slot is a leader-schedule coordinate and production opportunity. An entry records Proof of History progress through its hash count and hash, followed by a transaction vector that can be empty. Shreds are packet-sized transport and recovery units. A block is the assembled and interpreted ledger product associated with a produced slot in a given fork context.

The distinctions explain most low-latency behavior. Packet delivery overlaps the leader's entry production. A complete block view appears later. Consensus commitment arrives later again.

A slot is an opportunity

The leader schedule assigns a validator to each slot. The coordinate advances whether or not a usable block is ultimately produced.

A leader may fail to produce, packets may not propagate sufficiently, or the resulting proposal may lose its fork. The canonical ledger can therefore omit that slot, and its coordinate alone never guarantees a block.

Slot is also not a precise timestamp. Target durations guide the protocol, but actual production and observation vary. Use slot for ledger placement and a local monotonic clock for receive latency.

A leader produces a ledger proposal

During its slot, the leader processes transactions against its parent state and records Proof of History entries. The proposal has a parent relationship carried through data-shred metadata and broader ledger context.

Production is incremental. The leader does not need to finish the entire block before the first data leaves. It can serialize entry batches and shred them as work proceeds.

That property creates the direct-feed timing advantage. Early transactions in a slot can be observable from completed entry batches while later transactions have not yet been recorded.

Entries order transactions and time

Each entry records hash-chain progress and a transaction vector. Tick entries can have zero transactions. Transaction-bearing entries can contain several.

Entry order expresses the leader's recorded PoH sequence. Transaction order inside each vector adds another coordinate. Runtime execution can exploit parallelism among non-conflicting transactions, but the ledger still has a deterministic recorded structure.

Entries do not include settled RPC execution metadata. The transaction messages are proposed inputs. Replay produces success or failure, logs, balances, and other outcomes.

Serialization turns entries into bytes

The leader serializes entries in vector batches. Each batch becomes a byte stream containing framing, entry fields, transaction objects, signatures, and messages.

Network packet boundaries do not align with that stream. A transaction may cross them, and a single packet can contain fragments from multiple entries. DATA_COMPLETE ends a serialized vector and tells the receiver when a consecutive byte range is decodable.

Several entry vectors can appear within one slot. LAST_IN_SLOT terminates the final vector.

Data shreds carry the source stream

Data shreds hold slices of serialized entry bytes plus headers, padding, and authentication material selected by variant. Their indexes define concatenation order within the slot.

The receiver validates each packet, extracts its meaningful data range, fills gaps through FEC or repair, and concatenates consecutive indexes. It then deserializes completed entry vectors.

Data shreds are the earliest packet representation of proposed ledger content. They are not small independent transactions and should not be searched without respecting serialization boundaries.

Coding shreds protect the source

Coding packets provide Reed-Solomon parity for bounded FEC groups. They add no transaction objects; their job is rebuilding lost source data without a retransmission round trip.

A recovery group declaring k source members needs k independent and mutually consistent shards. Those may be any valid mixture of source and parity. Coding positions select parity rows, while the FEC anchor locates the source range.

Feed byte volume therefore exceeds serialized ledger volume. Parity is deliberate redundancy. Counting coding payload as block content inflates block-size estimates and produces meaningless transaction-density calculations.

Turbine distributes shreds in parallel

Turbine propagates shreds through a tree-like fanout rather than requiring the leader to send the entire proposal independently to every validator. Different packets take different paths, so their arrival sequence can diverge from protocol order.

The distribution unit is a shred. Bounded packet size avoids dependence on large-message transfer and gives FEC a granular loss model. Receivers use indexes and set metadata rather than arrival sequence.

A raw delivery service observes and forwards these packet units over UDP. Forwarding begins before RPC block construction. The consumer receives the same basic early representation and accepts responsibility for decoding and uncertainty.

Slot data completion closes the proposal bytes

An authenticated packet carrying LAST_IN_SLOT claims a terminal data index. The receiver has local source completeness only after it possesses or recovers every data position from zero through that index.

Earlier DATA_COMPLETE markers allow entry batches to decode before that moment. FEC-set completion covers smaller recovery ranges. Neither should be confused with full slot data completion.

A skipped slot may produce no terminal packet. UDP silence cannot establish a skip immediately. Later cluster state resolves whether no canonical block exists.

A block is more than packet concatenation

Ordered shreds recover serialized entries. Validator replay then verifies ledger rules and executes transactions against parent state. The resulting block-facing data includes outcomes and context not present in raw packet bytes.

RPC block representations can include transaction metadata, block time estimates, rewards, and commitment context. Those are assembled or derived at later layers. They are not hidden fields inside coding shreds.

For a raw consumer, block_proposal_decoded and executed_block should be separate objects linked by slot, fork identity, and transaction signatures.

Parent links create a fork, not a list

Parent distance in each data header links a proposal to an earlier slot, including across skipped coordinates. Several recent proposals can form competing branches.

Numeric slot order does not decide which branch becomes canonical. Votes and fork choice do. A higher complete slot can depend on a parent that the receiver has not replayed.

Store parent relationships and block views explicitly. Concatenating all numerically increasing slots into one chain will merge forks and misstate state transitions.

One slot can have no block

Leader failure, insufficient propagation, protocol rejection, or fork outcome can leave a slot without a canonical block. Applications often call this a skipped slot.

A raw receiver might have seen partial or even complete authenticated proposal data for a slot that RPC later reports as skipped or absent on the selected fork. That is not necessarily a decoder contradiction. The two sources answer different temporal and consensus questions.

Retain an orphaned or dropped outcome during reconciliation. Deleting early observations makes strategy audits and latency comparisons impossible.

One transaction can appear in several proposals

A signed transaction may reach multiple leaders or be replayed after a fork change while its recent blockhash remains usable. Its signature may consequently recur across different slot proposals.

Global first-seen deduplication helps some strategy decisions but cannot identify a ledger event by itself. Add cluster and slot, the particular proposal view, plus entry and transaction positions.

Later executed state tells which occurrence landed, whether it succeeded, or whether none reached the canonical chain. Raw observation alone does not.

Counts have no fixed ratio

There is no universal number of transactions per entry, entries per shred, shreds per slot, or slots with blocks. Workload and serialization sizes vary.

A large transaction can span packets. Many small transactions can share an entry and packet range. Merkle proof size changes data capacity. FEC ratios add coding traffic without adding transactions. Skipped slots carry no canonical block content.

Capacity models should use measured distributions and parsed boundaries. Invented fixed ratios fail under exactly the high-load conditions trading systems care about.

Latency accumulates by layer

First shred arrival, first completed entry batch, last-in-slot arrival, local source completion, replay completion, confirmation, and rooting are distinct timestamps.

A direct parser competes near the first two. RPC consumers usually observe after replay and service publication. Consensus-sensitive applications wait longer by design.

Measure the stage relevant to the claim. Comparing first transaction decoded from shreds with finalized RPC response mixes both transport and commitment choices. The comparison can be useful, but its components should remain visible.

A precise mental model

The schedule grants a slot. The leader builds a proposal from entries. Serialization turns entries into bytes. Data shreds carry those bytes. Coding shreds protect groups of data. Turbine propagates both. Receivers authenticate, recover, order, and deserialize. Replay executes. Consensus selects and roots.

Every arrow can add latency or fail. Each output has a different confidence level.

The model is longer than saying a shred is part of a block, but it supports correct systems. It shows exactly where raw UDP helps and exactly what the consumer must still do.

The model also determines storage boundaries. Packet capture stores datagrams and transport times. Shred storage uses slot/type/index identity. FEC state uses slot, anchor, and authenticated view. Entry storage adds an ordinal within the slot. Transaction events add their own ordinal and signature. Executed block storage adds fork and commitment context.

Moving data between these stores should strengthen or preserve claims. A packet becomes an authenticated shred after verification. A source range becomes entries after complete deserialization. A transaction becomes executed after replay metadata matches it. No later object should erase the provenance needed to explain that transition.

This discipline helps when sources disagree. Raw shreds can show a transaction that an RPC endpoint never reports because its fork lost. RPC can show a canonical block that one raw receiver could not complete because packets were lost. Both observations can be correct within their layer.

For latency comparisons, choose aligned events. First authenticated transaction message from shreds can be compared with first proposed-transaction event from another feed. Local slot-data completion can be compared with another source's full proposal. Confirmed RPC time should be compared only when the added commitment wait is part of the question.

Capacity planning follows the same separation. Packets per second size the receiver. Data bytes and completion boundaries size the entry decoder. Transactions and instructions size application dispatch. Account writes and runtime work size replay. One blocks-per-second figure cannot predict all four resource profiles.

A senior system treats the layers as a pipeline with typed evidence, not a vocabulary preference. The distinctions make early data useful without asking downstream code to forget uncertainty.

Operational alerts should also name the layer. shred_receive_gap points to delivery or local queueing. fec_unrecoverable points to concentrated member loss. entry_decode_failure points to byte boundaries or compatibility. replay_failure points to ledger validation or parent state. commitment_timeout points to consensus observation.

One block missing alert collapses these causes and sends operators toward the wrong subsystem. Layered counters preserve the same mental model during incidents that engineers use during design. They also allow service-level objectives to state whether they promise packet delivery, local proposal reconstruction, decoded transaction events, or later confirmed reconciliation.