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 is a Proof of History record containing a hash count, hash, and zero or more transactions. A shred is a packet-sized transport and recovery unit. 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. Shreds arrive while a leader is producing entries. 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. Such a slot can be skipped or absent from the canonical ledger. Therefore slot number does not guarantee 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 vectors of entries. Each vector becomes a byte stream with framing, entry fields, transaction objects, signatures, and messages.

This stream has no reason to align with network packet boundaries. A transaction can cross a shred. One shred can contain bytes from several entries. DATA_COMPLETE marks the end of one serialized vector so a receiver knows when a consecutive range is decodable.

Several entry vectors can appear within one slot. The final vector ends with the last-in-slot data shred.

Data shreds carry the source stream

Data shreds hold slices of serialized entry bytes plus headers, padding, and variant-specific authentication material. Their data 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 shreds carry Reed-Solomon parity for bounded FEC sets. They add no new transaction objects. Their purpose is to reconstruct missing source data without a retransmission round trip.

A set with k data shreds becomes recoverable from any k distinct, valid, consistent data and coding members. Coding positions identify parity rows. FEC anchors map 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 and can arrive out of 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. It does not wait for 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

A valid LAST_IN_SLOT data shred establishes the claimed terminal data index. Local slot data is complete when every index from zero through that terminal position is present or recovered.

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 prove skip in real time. 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

Data headers carry a parent offset, allowing a proposed slot to link to an earlier parent across skipped coordinates. Several recent slot 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 can be forwarded to multiple leaders or replayed after a fork change while its recent blockhash remains usable. The same transaction signature may therefore appear in more than one proposed slot view.

Global first-seen deduplication is useful for some strategy decisions but insufficient as ledger event identity. Contextualize by cluster, slot, block view, entry ordinal, and transaction ordinal.

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 keys by slot, type, and index. FEC state keys by slot, anchor, and authenticated view. Entry storage uses slot and entry ordinal. Transaction events add transaction 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.