Solana shred format reference

Wire unit

One UDP datagram contains one raw Solana shred. shredstream.sh permits datagrams up to 1,228 bytes and measured a 1,216-byte mean on 2026-08-31. The mean is not a fixed packet size. Parse using the received datagram length and the selected shred variant.

All multibyte integer fields in the headers below are little-endian. Byte ranges use a start-inclusive, end-exclusive convention.

Common header

The current common header is 83 bytes.

The minimal safe read for the common header is 83 bytes. Reject a shorter datagram before accessing any common field.

Data header

The current data header follows the common header and ends at byte 88.

Data flags

The value 0x40 marks data complete. The value 0xC0 marks last in slot and therefore also data complete. A parser should use the bit definitions from its pinned client release rather than accept unknown combinations.

The size field is not the UDP datagram length. Bytes can remain after the declared ledger data for padding, chained-root material, Merkle proof nodes, or a retransmitter signature.

Coding header

The current coding header follows the common header and ends at byte 89.

The coding shred’s erasure-shard position is k plus position. Its global coding index is not that local array position. The first coding index can be derived as coding index minus position.

The common current target is 32 data and 32 coding shreds in an FEC set. A final set can be shorter. Allocate from sanitized k and m rather than treating 32 plus 32 as an eternal packet rule.

Variant families

The variant byte is a dispatch value, not a field to decode with a guessed mask. Current Merkle forms encode proof-entry count in the low four bits and use other bits for role and flags. Exact valid discriminants and flag combinations belong to the matching Agave release.

Merkle-dependent regions

There is no one valid proof offset for all packets. Data or coding role, proof depth, chain presence, retransmitter signature presence, and payload capacity all affect the boundary. Use typed accessors from the pinned implementation.

Identity and ordering keys

Data and coding indices occupy separate spaces. Deduplicating on slot and index alone can discard a valid member of the other type.

FEC consistency checks

Every member admitted to one recovery set must agree on slot, cluster shred version, FEC-set index, data count, coding count, protected shard size, variant compatibility, and authenticated Merkle context where present. Coding members must imply the same first coding index. A recovered data shred must pass the same structural and authentication checks as a received data shred.

Do not append coding payload to ledger bytes. Coding shreds exist to reconstruct missing data members.

Signed material

The expected public key comes from the scheduled leader for the slot. A matching source IP, plausible slot, or correct cluster shred version does not prove authenticity.

Deshredding boundary

Only sanitized data bytes are concatenated, in data-index order, across the applicable completed range. The parser’s data accessor must exclude headers, padding, proof nodes, chained roots, and retransmitter signatures.

Completion flags describe boundaries. They do not make an incomplete earlier range appear. A last-in-slot flag without all required data or successful FEC recovery still leaves a gap.

Fail-closed parser order

1. Check the received datagram length against the 1,228-byte product maximum.
2. Check enough bytes exist for the common header.
3. Read and dispatch the variant.
4. Read common fields with checked slices.
5. Compare the cluster shred version.
6. Parse the data or coding header.
7. Validate sizes, indices, counts, flags, and proof layout.
8. Resolve the scheduled leader.
9. Verify legacy signed data or the Merkle root.
10. Admit the packet to duplicate, ordering, and FEC state.

Unknown variants and impossible lengths are explicit rejections. Falling back to a legacy layout can turn proof bytes into plausible application data.