What is a Solana shred?

The short version

Solana does not finish a block and then send it. It sends the block as it is being built.

The validator whose turn it is to produce a block is called the leader. As the leader executes transactions, it packages the results into small fragments and pushes them onto the network immediately. Each fragment is a shred. By the time the block is complete, most of the network already has most of it.

This is the single most important thing to understand about Solana's data model, and it is what makes a whole category of infrastructure possible. If you wait for a finished block, you are late by construction.

Why blocks are broken up at all

Two reasons, and they are both practical.

The first is that a block has to cross the internet, and the internet moves small packets far better than large ones. A shred is sized to fit inside a standard network packet without being fragmented along the way. Anything larger risks being split by an intermediate router, and a split packet is a slow packet.

The second is that breaking the block into pieces lets the network distribute it in parallel. Rather than the leader sending the whole block to every validator, it sends different pieces to different peers, and they pass those pieces on. The work of distribution is shared out. This is the Turbine protocol, and it is the reason Solana can move a block to thousands of machines in well under a second.

What is actually inside one

A shred carries a header and a payload.

The header says which slot the shred belongs to, where it sits in the sequence, whether it is the last one in its slot, and whether it carries block data or recovery data. It also carries the leader's signature, which is what lets anyone receiving it confirm the shred genuinely came from the validator whose turn it was, rather than from someone pretending.

The payload is a slice of the serialised block. On its own it usually means nothing. A single transaction can span several shreds, and a single shred can contain fragments of several transactions. Only once you have collected the right group of shreds does the content become readable.

Data shreds and coding shreds

Not every shred carries block content. Some carry recovery information instead.

Shreds are sent over UDP, which does not guarantee delivery. Packets get dropped. Rather than asking for a retransmission, which would be slow, Solana sends extra shreds computed from the real ones. If some of the originals go missing, the extras can be used to reconstruct them mathematically.

The ones carrying block content are data shreds. The ones carrying recovery information are coding shreds. They are grouped into sets, and within a set you can lose a certain number of shreds and still rebuild everything. This is why a shred feed uses roughly twice the bandwidth you might expect from the block size alone: you are receiving the redundancy as well as the data.

How a shred becomes a transaction

Getting from raw shreds to something you can act on takes four steps, and each one can go wrong in its own way.

First, you check the signature, so you know the shred came from the real leader. Second, you group shreds into their recovery sets and rebuild anything that went missing. Third, you reassemble the payloads in index order into a continuous stream of bytes. Fourth, you decode that stream into entries, and entries into transactions.

This is the work that a raw shred feed leaves to you. It is genuinely non trivial, and it is why some providers sell a decoded feed instead. The trade is straightforward: decoding costs time, so a decoded feed is easier to consume and always slightly behind the raw one.

Where shreds sit relative to everything else

It helps to see the whole path from the leader to your code.

A leader produces a block. The block is split into shreds and broadcast. Validators receive the shreds, rebuild the block, and execute it. Once executed, the block is available through the normal RPC interfaces, and a little later it is confirmed, then finalised.

Every one of those stages costs time. An application polling RPC for new blocks sits at the far end of that chain. An application reading shreds sits at the near end, roughly at the same moment the rest of the network is learning about the transaction.

That gap is the entire reason this market exists.

What shreds do not give you

Being early is not the same as being certain, and it is worth being clear about the difference.

A shred tells you what a leader is proposing. It does not tell you that the block will be accepted. Slots get skipped. Blocks get dropped. A transaction you saw in a shred can fail on execution, or land in a block that never becomes part of the chain. Anything you build on shred data has to treat what it sees as probable rather than settled, and reconcile against confirmed state afterwards.

There is also no mempool here. On Solana, transactions go straight to the leader rather than sitting in a public waiting area, so you cannot see what is about to happen. Shreds show you what is happening, at the earliest moment it is observable. That is a meaningfully different thing, and systems designed around Ethereum's mempool need rethinking rather than porting.