Solana leaders discard below-floor transactions before verifying their signatures

The floor has hysteresis. It publishes at 99,000 buffered transactions and does not lift until the buffer is back to 95,000, so a leader sheds 4,000 transactions before low-priority packets are admitted again ^[1]. During that stretch the discard happens inside the signature-verification stage, before the signature is checked, so no fee is charged and no log exists to read ^[3][23]. Vote transactions are exempt from the floor ^[5].

Priority is the fee divided by the block space the transaction requested ^[6]. A transaction that ships with the default 1.4 million compute unit limit therefore sits far below where its fee alone would put it. The post calls right-sizing that limit the cheapest way past this stage ^[6][7].

Deduplication is a bloom filter of 63,999,979 bits, and the same bytes arriving twice inside two seconds lose the second copy ^[8]. The filter resets when it ages past two seconds or when its false-positive rate reaches 0.1% ^[9]. An RPC node's retry pool rebroadcasts every two seconds to the next two leaders ^[16]. Those two intervals are the same length, so a rebroadcast that lands slightly early is dropped as a duplicate instead of forwarded ^[4].

Stake sets the width of the QUIC lane. Below one fifty-thousandth of total stake, a validator counts as unstaked ^[12]. Unstaked means 128 concurrent streams, against a ceiling of 512 for a sender with a large share ^[11]. Wallets do not open connections to leaders; the RPC provider does. According to the post, nothing surfaces to the sender when the provider's lane is full, and the retry loop keeps aiming at the same lane ^[13].

The timing numbers reduce to one slot length. The write-up puts the fetch stage's window for forwarded packets at 20 slots, about 8 seconds, which works out to 400 ms a slot ^[15][2]. A leader's four-slot turn is 1.6 seconds ^[20]. A direct-to-leader sender whose QUIC handshake does not complete waits 2 seconds, sleeps another 1.6, and knocks again 3.6 seconds in, two seconds after the window it wanted had closed ^[20][3]. An RPC node refreshes its view of the leader schedule every 1,000 ms, two and a half slots. Fast rotation, the post says, can leave it aiming at the previous leader for a quarter of every window ^[19].

Help from other nodes is narrow. A non-leader forwards a packet only if it came from a staked node, and never if the packet was itself forwarded. The targets are the leaders 2, 6 and 10 slots ahead, at no more than 12 MB per second per node ^[14]. A transaction that landed and failed is dropped from the RPC pool at once and never retried; one that landed without being rooted is kept, so it can go out again if its fork dies ^[17].

Seven points is the write-up's count, and every figure in it is a default ^[22]. The post leaves the client release unnamed. The five-minute refresh of the validator address list is attributed to the widely used client, where a validator that restarts on new ports is unreachable to almost every sender for up to five minutes ^[21]. For these numbers to describe your traffic, your RPC provider has to be running that client near stock and staked above the unstaked threshold. Your own maxRetries has to be something other than 0. Zero means exactly one broadcast and no retries ^[18][12].