Decode a Solana shred

1 fragment becomes a labeled byte map

The shred decoder accepts hex, base64, or an uploaded datagram and displays the fields that can be read from that shred's variant. It shows byte ranges, interpreted values, signed material, payload range, and FEC grouping context. It does not label arbitrary payload bytes as a complete transaction.

A shred is a versioned protocol object. Data and coding variants carry different fields. Merkle variants add proof material. Layouts can change across network upgrades. The component therefore selects a known layout from the variant and version instead of assuming every packet shares one fixed header.

Method

Input normalization removes permitted whitespace, decodes the chosen representation, and reports the exact byte length. The product feed has a maximum UDP payload of 1,228 bytes and a measured mean of 1,216 bytes. A different length is not automatically invalid because test vectors and protocol variants need context, but the tool marks the difference.

Parsing proceeds in four passes:

1. Read the common signed header and variant discriminator under the selected Solana shred format.
2. Parse data-specific or coding-specific fields with explicit byte ranges and byte order.
3. Divide header, block payload, and any Merkle proof or chained material according to that variant.
4. Validate relationships such as index bounds, FEC set membership, declared sizes, and completion flags.

Optional signature verification applies the protocol's Ed25519 rule to the exact signed message for that variant:

valid = Ed25519Verify(leader_public_key, signed_message_bytes, signature)

The tool never reconstructs the signed message by reserializing parsed fields. It uses the original byte slice because a byte-level signature must be checked against the bytes that were signed.

FEC grouping uses the slot and FEC set index. Coding metadata describes the recovery group and symbol position under the known layout. The visual output links these values to the FEC set visualiser.

Worked example

Assume a user pastes a base64 datagram whose decoded length is 1,228 bytes. The discriminator maps to a supported data-shred variant. The parser reads a slot value of 410,200,300, shred index 144, FEC set index 128, and flags that do not mark the final data shred.

The byte map labels the signature region, common fields, data header, serialized block payload, and any variant-specific trailing material. The tool reports that index 144 belongs to a set beginning at 128 under the parsed metadata. It does not infer how many data symbols are required unless that information is present or supplied by companion shreds.

The user supplies the scheduled leader's public key for slot 410,200,300. Signature verification returns valid. That result means the signed bytes match that public key. It does not mean the slot becomes canonical, the payload contains successful transactions, or the supplied key is the correct scheduled leader. The caller must establish the key-to-slot relationship from an authoritative schedule source.

If the input ends halfway through a declared proof, the byte map highlights the missing range and stops before semantic payload parsing. It does not pad absent bytes or guess a variant.

From payload to entries

One shred usually cannot be decoded into a transaction on its own. A transaction can cross shreds, and one shred can contain fragments from several transactions. Data shreds must be grouped, ordered by index, and reassembled. Missing data may need recovery from coding shreds.

The reconstructed byte stream then becomes entries, and entries contain transactions. Entry boundaries and serialized lengths must be valid before transaction parsing. The component can export parsed header metadata to a FEC workspace, but the single-shred view stops at the boundary it can defend.

This limit is deliberate. A decoder that displays a plausible transaction from an incomplete byte range can be more misleading than one that says incomplete.

Use the byte map for debugging

The most useful workflow is comparison. Paste one accepted packet and one rejected packet. Compare variant, length, slot, index, FEC set, flags, signature result, and payload boundaries. A format change often becomes visible before a high-level parser has a helpful error.

Export includes input encoding, decoded byte length, parser version, selected layout, every interpreted field, validation results, and a checksum of original bytes. It excludes private keys. The output can accompany a bug report without rewriting field values by hand.

Malformed inputs are bounded. Declared lengths are checked before allocation. Unknown variants remain raw. Extra bytes are reported. No input causes the component to fetch accounts, leaders, or blocks unless the user explicitly supplies a key through the supported field.

Limitations

The decoder is not a validator. Optional signature verification authenticates bytes against a supplied public key. It does not prove that key was the scheduled leader, apply fork choice, execute transactions, or establish commitment.

The component supports named protocol layouts and reports unknown versions. Solana can introduce new shred variants. An unknown result can mean the tool needs an update rather than the packet is malicious.

One packet cannot establish loss, FEC recoverability, slot completion, or transaction order beyond its own header. Those properties require companion shreds. A pasted datagram also lacks trustworthy network arrival provenance unless the capture preserved it.

Hex and base64 transcription can change bytes. The tool reports a checksum so the user can compare it with the capture. Uploaded production traffic may contain public transaction data, but operators should still follow their data-handling policy.

The method earns trust by showing byte ranges and verification inputs. It refuses the stronger claims that the available bytes cannot support.