Reference

Solana shred version history

Trace the public progression from legacy shreds to Merkle, chained, and retransmitter-signed forms without inventing global format numbers or dates.

Two kinds of versioning

Solana uses the word version for two different concerns.

The common shred header contains a 16-bit shred version. That value separates cluster lineages derived from genesis and hard-fork context. It is not a chronological format number.

The variant discriminator selects the packet format: data or coding, legacy or Merkle, and Merkle flags such as proof size, chaining, and retransmitter-signature presence. Format evolution happens through supported variants and cluster feature activation, not through a universal sequence called shred format version 1, 2, or 3.

Changelog

Historical order	Format family	Change	Authentication model	Receiver impact	Global date or numeric format version
Earlier	Legacy data shreds	Carry serialized ledger bytes with the legacy data header and completion flags	Leader signature uses the legacy signed-data rule	Parse fixed common and data headers, validate size, verify leader, order data bytes	No global semantic number or date is stated here
Earlier	Legacy coding shreds	Carry Reed-Solomon parity with data count, coding count, and position	Leader signature uses the legacy signed-data rule	Group compatible members and recover missing data under the legacy layout	No global semantic number or date is stated here
Later	Merkle data shreds	Add Merkle proof material around protected data-shard content	Leader signs the reconstructed Merkle root	Variant-aware capacity, leaf hashing, proof walking, and root verification become required	Activated by cluster feature state, not one universal date
Later	Merkle coding shreds	Add Merkle proof material for coding members	Leader signs the reconstructed Merkle root	Proof position uses the erasure-shard position k plus coding position	Activated by cluster feature state, not one universal date
Later extension	Chained Merkle data shreds	Commit an FEC set to the preceding set’s root	Leader-authenticated root includes the variant-defined chain relation	Receiver validates continuity as well as membership	No invented activation date
Later extension	Chained Merkle coding shreds	Carry chain commitment with parity membership	Same leader-root model with chained context	Recovery state must retain the compatible preceding-root relationship	No invented activation date
Later extension	Retransmitter-signed Merkle data shreds	Add separate retransmitter evidence at the variant-defined tail	Extra signature does not replace the leader signature	Parser reserves tail capacity and validates each signature under its own role	No invented activation date
Later extension	Retransmitter-signed Merkle coding shreds	Add separate retransmitter evidence to coding members	Extra signature does not replace the leader signature	Coding capacity, proof offsets, and validation follow the selected variant	No invented activation date

The ordering above describes protocol-family progression. It does not assert that every cluster activated each family at the same wall-clock time or that every client release supported each form on the same date.

Legacy era

Legacy data and coding shreds established the common operating model: one signed packet belongs to a slot, occupies a type-specific index, joins an FEC set, and carries either ledger data or parity. Data shreds expose parent offset, flags, and size. Coding shreds expose k, m, and coding position.

A legacy receiver cannot safely parse a Merkle packet as legacy. Proof and chain bytes change capacity and authentication boundaries even when the common header still looks plausible.

Merkle era

Merkle variants authenticate each data or coding shard through a leaf and proof that reconstruct a root signed by the slot leader. The proof size is encoded by the variant, and the erasure-shard position selects the proof path.

This change moved authentication away from an assumption that one fixed payload slice is always the signed message. A current receiver asks the typed parser for the root or signed data required by that variant.

Chained Merkle forms

Chained forms add a commitment to the preceding FEC set root. The chain lets a receiver validate a defined continuity relationship between adjacent sets. It also consumes wire capacity and changes offsets, so a non-chained capacity calculation is not valid for a chained packet.

Chain validation requires state beyond one isolated datagram. A packet can have a valid membership proof while its expected chain context is unavailable or inconsistent.

Retransmitter-signed forms

Retransmitter-signed Merkle forms add another signature at the tail. The leader signature remains the origin authentication for the shred content. The added signature supplies separate retransmission evidence under the active implementation’s rules.

Do not overwrite the leader field with the retransmitter key, and do not include the trailing signature in ledger bytes or Reed-Solomon input unless the matching typed implementation defines it there.

Cluster shred version

Property	Meaning
Width	16 bits
Header offset	Bytes 77 through 78
Byte order	Little-endian
Purpose	Reject packets from an incompatible cluster lineage early
Derived from	Trusted genesis and hard-fork context through validator-compatible code
Not equivalent to	Agave release, feature-set identifier, RPC version, packet variant, or commitment
Security property	Cheap context filter, not authentication
Collision property	Only 65,536 values exist, so unrelated lineages can collide

Software can upgrade without changing the cluster shred version. A new packet variant can activate while the same cluster-lineage value remains in the common header. Conversely, similar software on unrelated clusters can carry different shred versions.

Operational transition rule

Use the packet slot, trusted cluster feature context, and variant discriminator to select a parser. Keep overlapping old and new parser support around an activation because UDP can reorder packets and repair can return older-slot data later.

Reject an unknown variant before reading format-dependent fields. Count unsupported_variant separately from wrong_shred_version. The first means decoder compatibility is missing. The second points to cluster context, routing, replay, or configuration.

Why exact dates are absent

No single wall-clock date correctly describes a format family across mainnet, test networks, private clusters, client deployments, feature activation, rollback, and late repair traffic. A precise operational history needs a named cluster, feature identifier, activation slot, client commit, and source.

This reference does not invent those values. Pin the decoder to an Agave release, obtain authoritative feature state for the target cluster, and store that provenance beside packet fixtures.

Questions

Is the 16-bit shred version a format version?: No. It is a compact cluster-lineage filter derived from genesis and hard-fork context. The variant discriminator and active feature state select the packet layout. An Agave release, a Merkle variant, a feature-set identifier, and the 16-bit header value are separate pieces of receiver configuration.
Why does this history omit activation dates?: Format support and activation are cluster, feature, client, and slot specific. One wall-clock date would misstate private clusters, test networks, staged deployments, rollback, and late repair traffic. A defensible date requires a named cluster, feature identifier, activation slot, client commit, and authoritative source, none of which should be guessed.
What should a receiver do during a format transition?: Deploy support before activation, select parsing by trusted slot context and the packet discriminator, retain the older path for reordered and repaired packets, and reject unknown variants visibly. Test data, coding, recovery, proof failure, duplicate conflict, and partial final FEC sets on both sides of the transition.