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 header carries a 16-bit shred version. Its value separates cluster lineages using their trusted genesis plus hard-fork context; it is not a chronological format number.

The variant discriminator selects packet role, either data or coding, then legacy or Merkle family and flags for proof size, chaining, and retransmitter-signature presence. Formats evolve through supported variants and cluster feature activation, not a universal shred-format sequence numbered 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 shreds established the original operating model across both roles: each signed packet belongs to a slot, occupies its role-specific index, joins an FEC set, and carries ledger data or parity. A data header exposes its parent offset, completion flags, and size; coding headers expose k, m, and 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 a tail signature. Origin authentication of shred content still belongs to the leader signature, while the addition supplies separate retransmission evidence under active implementation 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

Select the parser through packet slot, trusted cluster feature state, and variant discriminator. Retain overlapping legacy and current parsers around activation because UDP reordering and repair can deliver older-slot data later.

Reject unknown variants before reading dependent fields. Keep unsupported_variant distinct from wrong_shred_version: the former identifies missing decoder compatibility, while the latter directs investigation toward cluster context, routing, replay, or configuration.

Why exact dates are absent

One wall-clock date cannot describe format adoption across mainnet plus test and private networks, client deployments, feature activation, rollback, and late repair. 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 the target cluster's authoritative feature state, and store that provenance beside packet fixtures.

Questions

Does the 16-bit header value name a format?: No. It is a compact cluster-lineage filter computed from trusted genesis plus 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 receiver settings.
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.
How should receivers handle format transitions?: 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.