What is inside a Solana shred?

3 regions in one packet

A shred has three logical regions even when a decoder represents it as one byte array. The common header comes first. A type-specific header follows. The remaining bytes hold ledger data, parity data, padding, and authentication material according to the selected variant.

The distinction is operational. The common header tells a receiver where the packet belongs. The second header tells the receiver how to interpret it. The tail supplies either source bytes or recovery bytes. Parsing those regions out of sequence can produce plausible integers from incorrect offsets. Silent misclassification is often worse than an immediate parse failure.

Current Solana serialization places 83 shared header bytes first. Five more bring a data prefix to 88 bytes, whereas six more bring a coding prefix to 89. These are current layout sizes. Production decoders should still dispatch on variant and bind layout constants to the implementation version they support.

Shared prefix: 83 bytes

Bytes zero through 63 contain the signature. The other 19 encode variant in one byte, slot in eight, index in four, shred version in two, and the FEC anchor in four. Integer decoding must follow the protocol's serialized representation rather than decimal text or assumed network order.

Each field answers a different admission question. The variant selects the parser. The slot selects the leader schedule and the assembly bucket. The index supplies position within the type's sequence. The version separates packets belonging to the intended cluster. The FEC set index groups shards that can participate in the same Reed-Solomon recovery operation.

Signature checking also requires that slot's scheduled leader and a variant-appropriate message. Legacy authentication covers the serialized packet region after the signature. For a Merkle variant, the message is a root computed from leaf material plus its proof.

The 5-byte data header

A data shred devotes five bytes to its second header: two for parent distance, one for flags, and two for size. Parent distance links backward from the current slot. Flags combine completion signals with a reference-tick value. Size limits the meaningful serialized region.

These fields serve block reconstruction, not merely display. Parent distance one links the proposal to its prior slot; a greater distance can cross skipped coordinates. The data-complete bit ends a serialized entry batch. The last-in-slot bit closes the slot, and completion follows from that terminal signal.

The size field matters because packet buffers and erasure shards include bytes that are not application data. Zero padding can follow meaningful bytes. Merkle proof or chaining material can occupy space near the tail. A decoder that passes the entire UDP datagram into an entry deserializer will eventually treat padding or proof bytes as ledger bytes.

The 6-byte coding header

A coding shred uses six bytes for three unsigned integers. Two integers declare the source-member and parity-member counts; the third gives this member's parity position. Combined with the shared recovery anchor, those values define an erasure set.

The count pair determines the Reed-Solomon matrix dimensions. For example, 32 sources paired with 32 parity members create 64 possible positions. Recovery needs 32 valid independent members to reconstruct all source shards. Coding position distinguishes each parity row.

No coding header includes parent distance, completion flags, or data size. Its payload is parity rather than a separately serialized transaction stream. Encoding operates over normalized, equal-length source representations. Legacy and Merkle packets expose different authenticated and encoded byte ranges, so receivers should obtain erasure shards through a variant-aware accessor rather than intuitive slicing.

Variant selects the layout

One byte near the front controls much of the rest of the packet. Legacy data and legacy coding variants have dedicated discriminator values. Merkle variants use bit patterns that also encode proof length and whether chaining or retransmitter resigning applies.

The variant is therefore not a cosmetic type tag. It changes which bytes are signed, which bytes form an erasure shard, how much data capacity remains, and how the trailing bytes must be interpreted. Treating every data shred as the legacy layout can expose a credible slot and index while silently corrupting the payload boundary.

A sound parser performs minimum-length checks before reading fields, decodes the variant, selects a supported layout, and then validates variant-specific constraints. Unknown variants should be counted and rejected. Falling back to a nearby known layout turns an explicit compatibility event into silent ledger corruption.

Payload is not a transaction boundary

Data payloads are slices from serialized entry vectors. Packet capacity, not transaction framing, determines each cut. A transaction may begin in one packet and finish in another; a single payload may also join the tail of one entry to the next entry's beginning.

Completion flags bound serialized entry batches, not individual entries or transactions. Receivers concatenate meaningful ranges in data-index order. Deserialization begins only after that range reaches its completion signal.

This distinction affects latency. A parser can inspect headers as soon as each datagram arrives. It cannot safely decode an entry whose bytes have not arrived yet. Speculative streaming decoders can retain partial state, but they still need framing data and must discard the state if an earlier missing shred is later recovered with bytes that change the parse.

Padding has a protocol purpose

Equal-length shards are required by the erasure coding operation. The last data shred in a group often contains fewer meaningful ledger bytes than its capacity. The remaining region is zero padded for encoding.

Padding is not evidence of an empty transaction or an end marker. Meaningful bytes are selected by the size value together with layout rules. A zero byte cannot serve as a terminator because entries, hashes, signatures, and transactions may contain zeros legitimately.

Coding shreds emerge at the erasure shard length by construction. They need no semantic size marker because Reed-Solomon recovery consumes their content, not the entry deserializer. After recovery, reconstructed data shards must be rebuilt into valid data shreds and sanitized before their size and flags are trusted.

Authentication occupies two shapes

Legacy authentication is packet-local. Its Ed25519 message comprises the serialized region after the signature, including relevant padding. Changing an authenticated header or payload byte then breaks verification.

Merkle authentication applies to a set. The leader hashes authenticated leaf material for every member, builds the set's canonical tree, and signs its root. Each packet supplies the sibling hashes required to recompute that root, so one signature may recur across the group.

The two schemes provide leader authentication through different byte paths. A decoder must not verify a Merkle signature over the packet tail or verify a legacy signature over a computed root. Both operations can be expressed behind one interface, but the interface must dispatch on variant before selecting the message.

Identity needs slot, type, and index

Storage and deduplication identify a packet with three coordinates: slot, shred type, and index. Indexes for data and coding live in separate namespaces, which makes a two-coordinate slot/index key ambiguous. The FEC value groups recovery members and does not replace packet index.

Duplicate packets are normal on a fanout path. Copies whose identity and authenticated bytes match can collapse into one record. Conflicting bytes under one claimed identity require explicit duplicate handling rather than last-write-wins replacement. Signature and Merkle consistency checks determine whether either copy is attributable to the scheduled leader.

Assembly tables often need a second key for FEC work: slot plus FEC set index. Keep the identity key and recovery key separate. Mixing them tends to produce bugs when coding positions and data indexes are mapped into one shard array.

Sanitization is a staged operation

Packet length comes first. No field should be read until its complete byte range exists. Variant validity comes next, followed by header invariants such as index bounds, parent offset validity, flag combinations, proof length, coding counts, and coding position.

Cluster version and slot horizon checks reject traffic that cannot belong to the receiver's intended ledger view. Signature or Merkle verification establishes leader attribution. FEC consistency checks ensure all admitted members agree on set shape and root. Entry decoding occurs only after ordered data is available.

The order saves work under load. Ed25519 verification is more expensive than comparing a two-byte version or rejecting an impossible coding position. It also prevents malformed packets from allocating enormous buffers based on unchecked counts. Fast rejection is a correctness property when untrusted UDP can arrive at line rate.

Anatomy under raw UDP delivery

Raw UDP preserves the shred bytes but supplies no message order, retransmission, connection state, or backpressure. An average datagram size observed on any feed is an observation about traffic, not a universal serialized length.

The receiver must use the UDP datagram length as an outer bound and the shred layout as the inner interpretation. A larger receive buffer avoids truncating packets. Each packet has a service-contract ceiling of 1,228 bytes. Consumer buffers should accommodate it instead of an observed average.

Packets can arrive twice, late, or after a slot was already declared complete. They can also arrive in coding-first order. The header provides enough information to place each valid packet without relying on arrival sequence. That is why correct anatomy parsing sits before every higher-level optimization.

What the packet can prove

Successful validation can attribute specific data or an FEC-set root to the expected slot leader. The packet also reports a claimed slot, position, version, recovery group, and completion state, and it may contribute bytes toward serialized-entry reconstruction.

A shred cannot prove that its slot will remain on the rooted chain. It cannot prove that a transaction inside will execute successfully. A coding shred alone does not reveal application content without sufficient peers from its set. LAST_IN_SLOT states the leader's view of production completion, not a consensus commitment.

Infrastructure should preserve those boundaries in its types. Use terms such as authenticated, reconstructed, executed, confirmed, and rooted for different states. Calling every parsed packet confirmed collapses five distinct events and makes downstream risk controls impossible to state.

Byte ownership affects decoder latency

One received datagram often crosses several queues: socket batch, header parser, cryptographic verifier, FEC set, ordered slot assembly, and entry decoder. Copying 1.2 kilobytes at every boundary consumes memory bandwidth and makes ownership hard to audit.

A bounded packet pool can keep the raw bytes stable while stages pass compact handles. Parsed headers should store values, not borrowed pointers into buffers that may be recycled. Meaningful data ranges can reference an admitted packet until assembly copies one completed entry batch into a contiguous decoding buffer.

Zero-copy design is not an absolute goal. Entry deserializers often benefit from one contiguous range, and holding hundreds of fragmented packet buffers can cost more than one planned copy. Measure copies by stage. Preserve actual datagram length and variant-derived offsets beside every handle so a later consumer cannot read unused capacity.