Why UDP Forwarding Beats WebSocket and gRPC for Shred Delivery

When it comes to receiving Solana shreds in real time, the transport protocol you choose has a direct impact on latency. Many infrastructure providers offer shred data over WebSocket or gRPC streams, which seem convenient but introduce significant overhead. Both protocols run on top of TCP, which means they inherit connection setup costs, congestion control delays, and — most critically — head-of-line blocking. A single dropped packet stalls the entire stream until retransmission completes. For a continuous stream of time-sensitive data like shreds, this behavior is devastating to performance.

To understand why head-of-line blocking is so problematic, consider what happens during a burst of shred delivery. The leader produces dozens of shreds per slot, and they arrive at your infrastructure in rapid succession. With TCP-based protocols like WebSocket or gRPC, these packets are delivered in a strict sequence. If packet number 47 in the stream is lost due to network jitter, packets 48 through 100 must wait in a buffer until packet 47 is retransmitted and received. Your application sees nothing during this pause — even though packets 48-100 have already arrived at your network interface. The entire stream freezes for one round trip of retransmission, typically 1-10ms depending on network conditions.

UDP eliminates all of this. There is no connection handshake, no acknowledgment loop, and no ordering guarantee that could cause stalls. Each shred arrives as an independent datagram. If one packet is lost, the rest continue flowing without interruption. This matches how Solana's Turbine protocol actually disseminates shreds across the validator network — as independent UDP packets using erasure coding for redundancy. By forwarding shreds over UDP, we preserve the same delivery semantics that Solana itself uses, without adding any artificial bottlenecks.

The erasure coding built into Solana's shred format provides a natural solution for packet loss. Each block's shreds include both data shreds and coding (parity) shreds. Even if some UDP packets are lost, the Reed-Solomon erasure coding allows full block reconstruction from a subset of the total shreds. This means UDP's lack of guaranteed delivery is not a practical concern — the application layer already handles redundancy. TCP's retransmission mechanism is redundant and actively harmful in this context, adding latency without improving reliability.

WebSocket and gRPC also add serialization and framing overhead that UDP avoids. A WebSocket frame includes a header with opcode, masking key, and length fields. gRPC adds HTTP/2 framing, header compression state, and Protocol Buffer serialization. These layers add processing time on both the sender and receiver side. With raw UDP, the shred data is the payload — there is no wrapping, no serialization, no framing. Your application reads the packet and immediately has the shred bytes ready for processing.

GetShreds forwards shreds over raw UDP in Jito-compatible format, which means your validator or custom pipeline can consume them natively without any deserialization layer. Our benchmarks consistently show 5-15ms of additional latency when using WebSocket or gRPC compared to direct UDP delivery. For MEV strategies where every millisecond counts, that gap is the difference between capturing an opportunity and missing it. We measured this by running identical shred processing pipelines side by side — one consuming from a WebSocket stream and one consuming from our UDP feed — on the same hardware in the same data center.

Connection management is another practical advantage of UDP. WebSocket and gRPC connections can drop due to idle timeouts, server restarts, load balancer reconfigurations, or network path changes. When a connection drops, your client must detect the failure, reconnect, and potentially re-authenticate before data flows again. This reconnection window can last seconds, during which you miss shreds entirely. UDP has no connection to drop — packets simply arrive at your port. If our edge node restarts, your application experiences a brief gap in data but resumes receiving immediately when packets resume, with zero reconnection logic required.

We operate bare-metal edge nodes in Frankfurt and Amsterdam, each tapping Turbine directly and forwarding shreds over UDP with sub-millisecond processing time. No KYC, no credit cards — just pay in SOL and start receiving shreds within minutes. Our infrastructure is purpose-built for shred forwarding, with kernel-level optimizations for packet processing and direct network paths to major Solana validator clusters.