Learn
Everything we know about Solana shreds
Written because the answers did not exist anywhere else in one place. No signup and no gate. Everything here is what we learned building the feed we sell, which is the same feed you would be buying.
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 feedCalculate Solana shred-feed bandwidth, packet-processing load, and storage from current packet-rate and packet-size observations.
- 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.
Comparisons
Shreds against the alternatives, and how to measure any of them without fooling yourself.
- Benchmark Your Shred Provider YourselfEvery published Solana shred latency benchmark was run by the company that won it. Here is an open-source harness for measuring providers on your own machine, and how to read what it tells you.
- Jito ShredStream Alternatives, Compared HonestlyJito ShredStream shut down on 5 September 2026. A provider-by-provider comparison of the replacements - DoubleZero, Helius, Triton, OrbitFlare, ERPC and others - with prices, regions and the cases where each one wins.
- Jito ShredStream Shuts Down September 5. Here's the 48-Hour Cutover.Jito ShredStream stops delivering shreds on September 5, 2026. What breaks, the replacement paths, and a parallel-run cutover you can finish in two days.
- Receiving shreds without a provider: what it actually takesWhat it takes to receive shreds straight from Turbine yourself: the node you must run, the position problem stake creates, and the honest arithmetic against paying for a feed.
- Your Bot Is Dropping Shreds: UDP Buffers, Backpressure and Silent LossGaps in your Solana shred stream are usually your own host, not your provider. How to find which of the four layers is dropping packets, and how to fix each one.
- What Solana Shreds Actually Cost in 2026: Every Provider, Every NumberA dated, sourced price comparison of Solana shred providers, including delivery regions, bandwidth metering, output format, and the terms buyers should verify.
- Why Shred Streams Cost $500 a Month, and What You're Actually Paying ForA unit-economics explanation of Solana shred delivery: coding overhead, validator position, peering, operations, and the difference between marginal bandwidth and total service cost.
Using them
Latency budgets, what the data is good for, and what it cannot tell you.
- Detecting a token launch in shreds, before the block existsHow to spot a PumpFun create or Raydium pool initialization inside deshredded transactions, before the block exists. Discriminators, the lookup-table catch, and what you cannot know pre-execution.
- Trading on data that might not surviveShreds show you transactions that may never execute. How often slots die, what seen-in-shreds actually guarantees, and the reconciliation patterns trading systems use.
- Where the milliseconds go: the full budget of a shred-driven tradeFrom leader emit to your transaction landing: every hop in a shred-driven trade, roughly costed in milliseconds, and why the wire is usually not where you are losing.