NullRabbit
cohort.v1
← All symptoms
Symptom · search entry

Solana transaction dropped before reaching the leader: QUIC stake-weighted throttling explained

Solana has no mempool, so a transaction that is dropped before the leader is not queued anywhere and will simply expire when its blockhash ages out. Under load, leaders apply stake-weighted quality of service at QUIC ingress: connections backed by stake receive transaction capacity in proportion to that stake, and traffic arriving from unstaked nodes, which includes most RPC servers, is the first to be shed. The drop is silent; the only client-visible evidence is the later expiry.

Common causes

  • Your transaction was forwarded by an unstaked RPC node during congestion, and the leader's ingress throttled that connection's share to near zero.
  • The compute unit price was too low for the leader's scheduler to prioritise the transaction within its block budget, so it was discarded rather than carried forward.
  • The send path forwarded to the wrong leaders, because the forwarding node's view of the leader schedule or the cluster clock was slightly off.
  • The leader itself was saturated, shedding even staked traffic while it cleared its backlog.

System-level mechanism

Gulf Stream replaces the mempool with directed forwarding: senders push transactions at the next expected leaders, and each leader admits what its ingress policy allows. Stake weighting exists because ingress capacity is finite and an open admission policy invites being flooded; tying capacity to stake makes large-scale flooding expensive. The structural consequence is that write access to the chain under load is mediated by who forwards for you and how much stake stands behind that connection. This is an admission-control decision at the transport layer, settled before the transaction is ever examined as a transaction, which is why no fee or simulation result on your side can fully override it.

What this indicates

Repeated silent drops during congestion indicate a send-path topology problem: the node forwarding your transactions has no stake-backed ingress relationship with leaders. The remedies are structural rather than parametric: a staked connection path, a forwarding service that holds one, or both, alongside a realistic priority fee.

Related issues

Transactions expiring with "Blockhash not found" or "block height exceeded"; confirmation slowing cluster-wide under load; reads working normally while writes fail, since only the write path crosses leader ingress.

Deep references

Related symptoms
Evidence