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 exact length. This product caps UDP payload at 1,228 bytes. Other lengths are not invalid automatically because test vectors and protocol variants need context, but the tool marks each 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 that variant's Ed25519 rule to its original signed byte range:

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 combines slot identity with the packet's recovery-set index. Coding metadata describes group and symbol position under the known layout. The visual output sends those 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, showing that these signed bytes match that key. Canonical slot status, transaction success, and correct key scheduling remain unproven. The caller establishes the key-to-slot relationship through 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

A lone shred usually cannot yield a transaction. Transactions may cross fragment boundaries, while one fragment can carry bytes belonging to several transactions. Group data shreds, restore their index order, and reassemble them; missing content may require coding-shred recovery.

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, but cannot establish scheduled leadership, fork choice, transaction execution, or commitment.

The component supports named protocol layouts and reports unknown versions. New Solana upgrades may add shred variants. An unknown result can mean the tool needs an update rather than indicate a malicious packet.

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.