Learn
Everything we know about Solana shreds
Written because the answers did not exist anywhere else in one place. No signup, no gate, and no requirement to buy anything. If you read all of this and decide to build your own receiver against someone else’s feed, the writing has still done its job.
What shreds are
The unit itself: what is inside one, how they are grouped, and how they become transactions.
- What is the difference between data and coding shreds?Data shreds carry serialized Solana entries, while coding shreds carry Reed-Solomon parity that reconstructs missing data without waiting for retransmission.
- What is a Solana entry?A Solana entry combines Proof of History progress, a resulting hash, and a batch of transactions inside the ordered ledger stream carried by data shreds.
- How do Solana entries become transactions?Receivers turn ordered shred bytes into entry vectors, extract versioned transactions, resolve account indexes, and later reconcile proposed messages with execution results.
- How does erasure coding work in Solana?Solana applies systematic Reed-Solomon erasure coding to bounded shred groups, allowing receivers to rebuild missing data from any sufficient valid subset.
- What is a Solana shred FEC set?A Solana FEC set groups consecutive data shreds with Reed-Solomon coding shreds so missing UDP packets can be reconstructed locally.
- How should a receiver handle malformed and spam shreds?A raw Solana shred receiver must reject malformed UDP in stages, bound every allocation, authenticate leaders, isolate conflicts, and preserve capacity for current valid slots.
- What are Merkle shreds in Solana?Merkle shreds authenticate each FEC set through one leader-signed root and a compact proof carried in every data and coding packet.
- What is inside a Solana shred?A Solana shred contains a common header, a type-specific header, authenticated payload bytes, and, for Merkle variants, a proof near the packet tail.
- Which fields are in a Solana shred header?Solana shred headers carry signatures, variants, slots, indexes, versions, FEC grouping, and type-specific data or recovery metadata.
- How do Solana shred indexes and ordering work?Solana data-shred indexes define ledger byte order, while coding indexes, coding positions, and FEC anchors serve separate identity and recovery roles.
- How are Solana shreds signed and verified?Solana leaders authenticate legacy shred bodies or Merkle FEC-set roots with Ed25519 signatures that receivers verify against the slot leader schedule.
- How large is a Solana shred, and why does MTU matter?Solana keeps shreds within a packet-sized network envelope to avoid IP fragmentation, with actual ledger capacity reduced by headers, proofs, and coding metadata.
- What is a Solana shred version?The two-byte Solana shred version separates packets from different cluster lineages and lets receivers reject cross-cluster traffic before costly verification.
- When is a Solana slot complete from shreds?A receiver has complete slot data only after it sees a valid last-in-slot marker and possesses every data shred from index zero through that terminal index.
- How do Solana slots, blocks, entries, and shreds relate?A Solana slot is a leader opportunity, entries form its ordered ledger record, and shreds transport that record before an executed block is available.
- What is a Solana shred?A shred is the smallest piece of a Solana block. Leaders split blocks into roughly 1,200 byte fragments, sign them, and broadcast them before the block is finished.
How they travel
Turbine, the leader schedule, and why where you sit on the network decides when you see data.
- What is the Solana block production timeline?Solana block production overlaps transaction intake, execution, proof-of-history recording, shred creation, Turbine propagation, replay, and voting within each slot.
- How do Solana network upgrades affect shreds?Solana upgrades can change supported shred variants, authentication, recovery layout, feature state, and client behavior while cluster shred version prevents incompatible networks from mixing packets.
- How does proof of history affect Solana timing?Proof of history gives Solana entries a verifiable sequential order and tick cadence that structures slots while block data is streamed as shreds.
- How does the Solana gossip protocol work?Solana gossip maintains a signed, eventually consistent CRDS view of validator identities, contact addresses, votes, and other cluster metadata.
- How does stake-weighted fanout work in Solana?Stake-weighted fanout biases early Turbine positions toward validators with more effective stake, then spreads each shred through bounded retransmit relationships.
- How does the Solana leader schedule work?The Solana leader schedule assigns upcoming slot-production opportunities from an epoch stake snapshot using deterministic stake-weighted selection.
- How does the Solana repair protocol work?Solana repair detects ledger gaps left after Turbine and erasure recovery, requests missing shreds or ancestry information from selected peers, and validates returned data.
- How do Turbine layers and positions work?Turbine layers convert a stake-weighted peer ordering into relay depth, neighborhood membership, and packet forwarding duties for each shred.
- How is the Solana Turbine tree constructed?Solana constructs each Turbine propagation tree from an eligible peer set, stake-weighted deterministic ordering, shred context, and a fixed fanout rule.
- What is the difference between vote and non-vote transactions on Solana?Vote transactions carry validator consensus decisions, while non-vote transactions perform general program work, though both become ordinary ordered ledger bytes inside shreds.
- What is Solana Turbine?Turbine is Solana's stake-aware block propagation protocol, which distributes shreds through a deterministic relay tree instead of making each leader send every packet to every validator.
- Why does Turbine position determine shred latency?Turbine position determines how many relay queues and network paths a shred crosses before arrival, creating latency that receiver hardware cannot recover after the fact.
Receiving them
UDP, kernel buffers, packet loss and the tuning that separates a receiver that works from one that drops.
- Bandwidth of a Solana shred feedThe measured shredstream.sh feed averages 54.3 Mbps, 5,585 packets/sec, and 1,216 bytes per packet, producing 17.6 TB over 30 days.
- Busy polling and NAPI for UDP latencyNAPI bounds Linux receive work, while socket busy polling spends CPU to find packets sooner and can reduce wakeup latency on supported drivers.
- PTP vs NTP for latency measurementPTP can synchronize hardware clocks within a controlled network, while NTP disciplines system clocks across broader paths with larger and more variable uncertainty.
- Interrupt affinity for UDP receive queuesInterrupt affinity places NIC queue notifications on selected CPUs, aligning NAPI, memory, and receiver work to reduce contention and latency variance.
- Jumbo frames for UDP market dataJumbo frames reduce packet overhead for large transfers but provide little direct benefit to fixed-size Solana shreds and require end-to-end MTU agreement.
- Linux kernel receive buffers for UDPLinux UDP receive buffering spans NIC rings, the network backlog, and per-socket memory, with distinct limits and drop counters at each layer.
- How to measure one-way UDP latencyOne-way latency requires explicit sender and receiver timestamp points, synchronized clock domains, hardware support where needed, and an uncertainty budget.
- MTU and fragmentation for UDP shred deliveryPath MTU determines whether a UDP datagram crosses the network intact, fragments under IPv4, or fails before reaching a shred receiver.
- NAT, conntrack, and UDP shred deliveryNAT and Linux conntrack create timed pseudo-state for UDP flows, affecting inbound reachability, firewall policy, table capacity, and failure detection.
- NIC tuning for high-rate UDPNIC ring depth, interrupt moderation, RSS, offloads, queue placement, and driver counters determine UDP receive loss and latency before the socket.
- Packet loss in a UDP shred receiverPacket loss can occur at the sender, path, NIC, Linux receive stack, socket, or application, and each location leaves different evidence.
- SO_REUSEPORT for high-rate UDP receiversSO_REUSEPORT lets multiple UDP sockets bind one address and port, but useful scaling depends on flow diversity and explicit queue steering.
- UDP vs gRPC vs WebSocket for Solana dataUDP, gRPC, and WebSocket feeds expose different latency, delivery, framing, and failure semantics for Solana trading infrastructure.
- UDP vs TCP for market dataUDP preserves freshness under loss while TCP preserves an ordered byte stream, a distinction that determines failure behavior for latency-sensitive market data.
- Why UDP has no backpressureUDP has no receiver window or acknowledgements, so overload becomes queue growth and packet loss instead of sender slowdown.
- XDP and kernel bypass for UDP receiversXDP and AF_XDP shorten Linux packet delivery, while DPDK takes queue ownership in user space, with substantial memory and operational trade-offs.