How large is a Solana shred, and why does MTU matter?

1 packet is the design target

A shred is sized as a network datagram, not as an arbitrary block chunk. The target is one packet that can traverse common Internet paths without IP fragmentation.

Fragmentation turns one logical datagram into several IP fragments. Losing one fragment loses the whole UDP datagram. Middleboxes can treat fragments poorly, and reassembly adds state and latency. A block propagation protocol built from many small independent units avoids that coupling.

The practical result is roughly 1.2 kilobytes per shred. Exact packet and usable-data sizes depend on the network envelope, protocol framing, and shred variant. Receivers should parse actual datagram length and header fields rather than treat one observed average as a fixed format.

1,280 bytes is the IPv6 baseline

IPv6 requires links to support a minimum MTU of 1,280 bytes. Subtracting a 40-byte IPv6 header and an 8-byte UDP header leaves 1,232 bytes for UDP payload under that baseline envelope.

Solana networking reserves protocol space within that budget. The raw shred payload delivered by shredstream.sh is bounded at 1,228 bytes under its wire contract. The four-byte difference from the outer 1,232-byte payload budget reflects surrounding protocol framing used in Solana packet paths.

IPv4 headers can be smaller, and many Ethernet paths expose a 1,500-byte MTU. Designing around the smaller common envelope reduces dependence on path-specific assumptions and tunnels that shrink effective MTU.

1,228 is a maximum, not a mean

The service's wire contract allows UDP datagrams up to 1,228 bytes. Its measured feed average is 1,216 bytes over the stated 5.6-hour window.

Those numbers answer different capacity questions. Socket buffers must accommodate the maximum. Bandwidth forecasting can use the measured mean with its capture date. A decoder uses each received length and the variant layout.

Allocating exactly 1,216 bytes because it is the average will truncate larger packets. Allocating a 65,535-byte object per packet wastes cache and memory. Use receive APIs and buffer pools sized for the documented maximum, while retaining the actual datagram length.

Headers consume at least 88 or 89 bytes

The current common header occupies 83 bytes. Data shreds add five type-specific bytes, for an 88-byte prefix. Coding shreds add six, for an 89-byte prefix.

That overhead includes a 64-byte Ed25519 signature. It also carries variant, slot, index, version, FEC anchor, and type-specific metadata. None of those bytes are serialized transactions.

Subtracting 88 from a packet maximum still does not yield universal data capacity. Legacy signing, erasure representation, zero padding, Merkle proofs, chaining material, and optional signatures affect which tail bytes carry meaningful entry data.

Merkle proofs reduce source capacity

Each Merkle proof sibling occupies 20 bytes. A six-level branch therefore uses 120 packet bytes. Optional chaining or resigned variant data can consume more.

The variant encodes proof-size information, so payload capacity varies with tree shape and flags. Larger FEC sets can require taller proofs, although actual supported dimensions and canonical tree rules constrain the relationship.

A decoder should expose meaningful_data_length after parsing variant and size, not publish packet_length minus 88 as ledger bytes. Capacity assumptions affect entry framing, FEC grouping, bandwidth models, and estimates of shreds per slot.

Coding payload is not ledger capacity

Coding shreds use most of their post-header region for parity. Their bytes protect equal-length source representations rather than serialize more entries.

The coding header declares FEC dimensions and position. The parity length follows the variant's erasure-shard rules. A receiver should not compare coding datagram length with data size to infer how many transaction bytes were produced.

Feed bandwidth includes both source and parity traffic. When data and coding counts are similar, network bytes can approach twice the source shred traffic before considering duplicates and other packet overhead. That redundancy purchases local loss recovery.

The data size field controls meaning

Data shreds carry a two-byte size field that marks the meaningful boundary according to the selected layout. The final data packet in a serialized batch often has unused capacity.

Zero padding fills source shard length where erasure coding requires it. Padding can appear inside a full-size datagram after meaningful ledger bytes. The first zero byte is not a delimiter because valid serialized content can contain zeros.

Validate that declared size includes required headers, stays within variant capacity, and does not exceed actual datagram length. Pass only the resulting meaningful range into ordered entry assembly.

Smaller datagrams can be valid or truncated

An observed UDP datagram below the maximum is not automatically invalid. A final packet or a transport representation can be shorter according to supported variant rules.

It is also not automatically valid. Kernel receive-buffer truncation, capture snap length, tunnel issues, or malformed traffic can remove bytes. The variant, declared size, proof requirements, and minimum header length decide.

Record truncation flags from the socket API where available. A 900-byte buffer receiving a 1,228-byte datagram may report only 900 bytes, and no amount of FEC padding inference can authenticate the missing tail.

MTU problems create distinctive loss

When a path's effective MTU is below the packet envelope, large datagrams can disappear while smaller ones pass. Tunnels, VPNs, encapsulation, and cloud networking can reduce available payload.

Symptoms include a biased datagram-length distribution, repeated gaps at full-size packets, high FEC recovery despite healthy packet rate, or complete feed failure behind a misconfigured tunnel. Ordinary random UDP loss tends to be less tightly correlated with size.

Packet captures at ingress and application receive points can isolate the boundary. Path MTU discovery is less helpful for one-way UDP when ICMP is filtered. Operationally, use a network path known to carry the documented maximum without fragmentation.

Socket sizing is a separate problem

MTU determines one datagram's safe size. Socket receive buffers determine how many datagrams the kernel can queue during bursts. A 1,228-byte application buffer does not prevent kernel drops when the process falls behind.

At a measured 5,585 packets per second, 10 milliseconds of scheduling delay can place roughly 56 datagrams into queues before burst variance. Kernel accounting also exceeds payload bytes because each packet has metadata.

Use sufficiently large socket receive buffers, batch receive calls where available, pin or prioritize hot receive work, and monitor kernel drop counters. Increasing MTU assumptions does not solve queue exhaustion.

Bandwidth arithmetic needs both mean values

5,585 packets per second multiplied by 1,216 mean bytes gives about 6.79 million payload bytes per second, or roughly 54.3 megabits per second after multiplying by eight. That matches the measured product feed figures.

Network-interface counters will be higher because Ethernet, IP, UDP, and link-layer overhead sit outside the raw payload. Monthly transfer also depends on continuous duration and provider accounting units.

Use the published 17.6-terabyte monthly figure for product planning under its stated measurement. Use local counters for capacity headroom. Peak packets per second often determines CPU and queue needs more strongly than average megabits.

Fragmentation is worse than one loss

Suppose a UDP datagram is split into two IP fragments. The receiver can deliver the datagram only after both arrive. One lost fragment discards bytes from the other fragment too.

Fragments also share an identification and reassembly timeout, creating kernel state. Attackers can exploit fragment queues, and network appliances often impose strict policies. Latency varies when reassembly waits for a delayed piece.

Keeping each shred within one packet makes loss granular. One dropped packet becomes one known erasure position, which FEC can repair. Fragmentation would turn partial delivery into the same whole-shred erasure with extra network cost.

Jumbo frames do not enlarge shreds

A data center may support 9,000-byte Ethernet frames. That does not change the Solana shred wire format or allow several shreds to be concatenated into one raw datagram.

Jumbo frames can reduce overhead for internal encapsulation or batch transport that a separate service controls, but the endpoint still needs to recover exact original shred boundaries and lengths. shredstream.sh delivers raw UDP packets, one datagram at a time under its documented maximum.

Protocol compatibility is more valuable than filling every local link. A consumer that assumes jumbo-sized shreds will not interoperate with the actual network.

Receivers should retain length as data

The parser input is a byte slice plus actual datagram length, receive time, and transport metadata. Do not copy the full buffer capacity and forget how many bytes arrived.

Length participates in minimum-header checks, proof-tail calculation, data-size validation, and malformed-packet metrics. It is also useful for diagnosing path issues and validating bandwidth forecasts.

Keep packet-length histograms by variant and outcome. A sudden new mode can indicate a protocol activation, capture bug, truncation, or spam. Averages alone hide a population of short invalid packets alongside full-size valid traffic.

Receive APIs can preserve packet boundaries efficiently

One UDP receive returns one datagram boundary even when the application uses batch system calls. Interfaces such as recvmmsg on supported systems can fill several independent buffers and lengths in one kernel transition. They do not concatenate the packets into a stream.

Batching reduces syscall overhead at thousands of packets per second, but a large batch can add queueing if the process waits for it to fill. Receive immediately available packets up to a bound and pass each actual length forward. Timestamp behavior depends on the operating system and socket options, so document whether a timestamp represents kernel arrival or user-space dequeue.

Buffer pools should have enough entries for bursts, worker latency, and FEC retention. A pool entry can use the 1,228-byte raw maximum plus local metadata. It should not expose capacity bytes as received bytes. Clear metadata on reuse and overwrite any range that a later cryptographic operation might read.

Scatter-gather APIs do not remove the need for a contiguous shred payload during signature and hash work. Measure whether parsing directly from pooled buffers or copying into aligned verification batches performs better on the target CPU.

When a receive call reports truncation, count and reject the datagram. Reissuing receive cannot retrieve its missing tail because UDP delivery already consumed it. A larger buffer fixes future packets only.

Packet boundary preservation also simplifies capture comparison. One record should contain receive length, transport tuple, timestamp, and exact bytes. A byte-stream log without lengths cannot distinguish two adjacent shreds from one oversized malformed datagram during replay.

Network overhead should also remain explicit in capacity tests. A 54.3 Mbps raw payload rate is not a 54.3 Mbps interface ceiling. Add IP and UDP headers, Ethernet framing, inter-packet overhead, monitoring traffic, duplicates, and burst margin. Virtual network devices can add encapsulation bytes and CPU work even when the physical link has ample bandwidth.

Test sustained receive at the measured rate and short bursts above it. Watch packet loss, soft-interrupt CPU, socket queue occupancy, batch size, and worker handoff latency. A host can show low average utilization while dropping packets during sub-millisecond bursts.