Congestion and the transaction processing path

Solana originally accepted transactions over raw UDP. UDP has no connection state and no congestion control, which makes it fast but also makes it impossible for a validator to tell who is sending what or to limit how much any one source can push. Under load, that meant a validator could be overwhelmed by traffic it had no way to throttle, and legitimate transactions could be crowded out by whatever was sending fastest.

The network moved to QUIC, a connection-oriented transport built on UDP. QUIC gives a validator something UDP never did: a connection it can identify, a stream it can count, and a way to apply limits per connection and per source. Each transaction is sent as its own unidirectional stream, so the unit the validator throttles is the stream rather than the packet.

The limits stack. There is a cap on the total number of concurrent connections a validator will accept, a cap on how many connections a single IP address may hold, and a cap on the rate of streams a connection may open. The stream rate is the one that most often affects a client sending at volume, because exceeding it causes the validator to signal that the stream is blocked and then stop reading, leaving the client's transactions queued locally until they time out.

The stream allowance is weighted by stake. A connection associated with staked identity receives a larger share of the available stream capacity than an unstaked one, and the split is proportional to the stake behind the connection. The purpose is to give the network a way to prioritise traffic from participants with something at stake when it is under stress, and it is the reason a client submitting directly from an unstaked address may find its throughput capped well below what the network could otherwise accept.

A validator that is not the leader for the current slot does not simply discard what it receives. It forwards transactions to the validators scheduled to lead upcoming slots, using the leader schedule described on the validators and leader schedule page. The forwarding stage typically looks a few leaders ahead rather than only at the immediate next one, so a transaction still reaches a block producer if the next leader is slow or offline.

Forwarding is rate-limited. A validator will only forward at a bounded rate, because otherwise it could be used to amplify a denial-of-service attack: an attacker could send a small amount of traffic to one validator and have it multiplied into a large amount aimed at a leader. The rate limit is a defensive measure, and it means that under heavy load a validator may drop transactions it would otherwise have forwarded.

The forwarding path is also where the network's ability to degrade gracefully comes from. Because a validator knows the leader schedule, it can forward transactions ahead of time and discard ones that have already become invalid, and a leader can take the stake of the forwarding validator into account when deciding what to include. That gives the network a way to shed load in a controlled way rather than failing outright.

Putting the stages together, there are several distinct reasons a transaction can fail to land, and they call for different responses. A transaction can be refused at the transport because the connection or stream limit was exceeded. It can be dropped in forwarding because the forwarding rate limit was reached. It can be discarded because its blockhash expired before it reached a leader. It can reach the scheduler and lose to a higher-priority transaction competing for the same account. Or it can be included and fail during execution, in which case it pays its fee and is recorded as failed.

Only the last two of those are fee decisions. Raising the prioritisation fee helps a transaction that reached the scheduler and lost, and it does nothing for a transaction that was refused at the transport or dropped in forwarding. That distinction is the single most useful thing to understand about congestion on Solana: the fee market decides ordering among transactions that were admitted, and the transport decides admission. A client whose transactions are being dropped before admission will not fix the problem by paying more.

The practical responses follow from the diagnosis. A client that is being throttled at the transport can reduce the number of streams it opens by batching more work into fewer, denser transactions, spread its submissions across distinct source addresses so each gets its own connection budget, or submit through a relay that holds stake and therefore has a larger stream allowance. A client whose transactions are reaching the scheduler but losing can raise its fee. A client whose transactions are expiring can refresh the blockhash and resubmit.

Solana has experienced periods of sustained congestion, and the public discussion of those periods is the best available record of how the pipeline behaves under stress. The recurring theme in that discussion is that the bottleneck has not been raw execution capacity. It has been the ingest path: validators receiving far more transactions than they could admit, with the excess consuming resources before it could be filtered.

That is the problem the QUIC migration and the stake-weighted stream limits were aimed at, and it is the problem the write-lock fee proposal discussed on the local fee markets page is also aimed at, from a different direction. One approach filters at the transport; the other prices at the account. Neither is a complete answer on its own, and the project's own discussion of the proposals is candid about that.

This page does not assert specific incident dates, outage durations or transaction-failure rates, because those figures require a primary source that this page does not have. What it describes is the mechanism — the stages, the limits and the failure modes — which is documented and stable. A reader who wants the incident record should go to the network's own status reporting rather than to a summary here.