The Ingress Fix — QUIC & Stake-Weighted QoS

The previous three pages diagnosed the disease. No Fee Market, and How Spam Amplifies showed why the door was wide open — near-zero fees made flooding almost free. Forwarding Storms & Resource Exhaustion showed how the flood turned into a self-sustaining storm, and The Outage Timeline showed what that looked like on the wire, on real dates. This page and the next are the cure. They split cleanly: this one fixes ingress — the front door of the leader — and the next one, Pricing the Load, fixes pricing — what it costs to come through that door.

The insight behind this page is blunt. Every failure in this part traced back to the same architectural fact: the leader accepted transactions over raw, unauthenticated UDP, so it had no way to tell a real user from a spammer, and no way to say “no.” You cannot ration a resource you cannot meter, and you cannot meter a firehose with no valves. So Solana rebuilt the front door twice: first to give it valves (QUIC), then to make those valves open wider for participants with more skin in the game (stake-weighted quality of service).

Where this fits in the pipeline

Ingress is the very first stage of the leader’s assembly line — the fetch stage of the TPU. Everything on this page happens before signature verification, before banking, before a transaction touches a single account. That placement is the whole point: the cheapest packet to reject is the one you reject before you have spent any work on it.

   the leader's front door — where this page operates
   ───────────────────────────────────────────────────

   [ network ] ─►  FETCH  ─►  sig-verify ─►  banking ─►  broadcast
                    ▲
                    │  QUIC + stake-weighted QoS live HERE
                    │  admit / rate-limit / drop BEFORE any real work

The old front door: raw UDP

To see what changed, look hard at what UDP gave an attacker. A UDP packet is fire-and-forget: the sender writes a datagram addressed to the leader’s IP and port, and the network delivers it (or doesn’t). There is no handshake, no session, no acknowledgement. That is exactly why Solana chose it originally — it is the lowest-overhead way to move a transaction, and low overhead was the entire bet of the chain.

But look at what is missing, because the missing pieces are the vulnerability:

   what raw UDP does NOT give the leader
   ──────────────────────────────────────
   ✗ no connection    — every packet is a stranger; no notion of "this sender again"
   ✗ no identity      — the source IP can be spoofed; no proof of who sent it
   ✗ no flow control  — the sender decides the rate; the leader just absorbs it
   ✗ no per-source cap — one sender and ten thousand senders look identical
   ✗ no backpressure  — the leader cannot say "slow down"; it can only drop

Read that list as an attacker would. Because there is no connection, the leader cannot count “how many packets has this sender sent me this second?” — there is no this sender. Because the source address can be spoofed, even IP-based rate limiting is defeated: the attacker rotates addresses and every packet looks brand new. Because there is no flow control, the sender sets the pace and the leader is a passive sink. The result is the failure mode of the whole part: an anonymous flood the leader must fully receive before it can even begin to decide what to drop — and by then the damage (the forwarding storm) is already done upstream.

The problem is not that UDP is “insecure.” The problem is that UDP is anonymous and rateless, and you cannot build admission control on top of an anonymous, rateless channel. So the first fix is to stop using one.

The first fix: QUIC gives the door a lock and a meter

QUIC is a transport protocol built on top of UDP — it is the same transport that carries HTTP/3. It keeps UDP’s speed (it is UDP packets underneath) but adds back the two things raw UDP threw away: a connection and flow control. Solana adopted QUIC for the transaction-ingest path as part of the 2022 client work, precisely to fix the ingress problem this part has been building toward.

Here is what QUIC restores, mapped directly onto the gaps in the UDP list above:

   raw UDP                         QUIC (over UDP)
   ─────────────────────────       ────────────────────────────────────
   fire-and-forget packet     ►    handshake first → a CONNECTION exists
   no notion of "a sender"    ►    the connection IS the sender's identity
   sender sets the rate       ►    FLOW CONTROL: leader caps in-flight data
   one sender = ten thousand  ►    PER-CONNECTION limits + a max connection count
   leader can only drop       ►    BACKPRESSURE: leader can refuse to open more

Three mechanisms matter for reliability:

A connection is a handle to rate-limit against

Before a client can send transactions, it completes a QUIC handshake, which establishes a connection the leader tracks. Now “this sender again” exists. The leader can count packets and bytes per connection, so a single source that tries to flood is throttled at its own connection — it can no longer hide in an anonymous crowd of packets. The leader also caps the total number of concurrent connections it will hold, which bounds the memory and bookkeeping any set of clients can force it to spend. Spoofing does not help the attacker here: QUIC’s handshake means you cannot get a usable connection with a forged address, because the reply goes to the address you claimed, not the one you’re at.

Flow control lets the leader set the pace

Raw UDP let the sender decide how fast to push. QUIC inverts that: the receiver advertises how much data it is willing to have in flight, and the sender must stay within that window. The leader is no longer a passive sink that must absorb whatever arrives — it grants bandwidth. This is the “valve” the old firehose lacked. A sender that ignores the window doesn’t get faster service; it gets its excess dropped at the connection.

Backpressure replaces “drop and pray”

Under UDP, the only tool the leader had when overwhelmed was to drop packets after receiving them — work already wasted. With connections, the leader has an earlier, cheaper lever: it can refuse to open a new connection, or tear down an abusive one, so the cost of being turned away lands on the sender, not on the leader. Admission control moves from “receive everything, then decide” to “decide whether to receive at all.”

QUIC alone, though, only gets you fairness by connection — every connection gets metered equally. That is a huge improvement, but it is not enough. An attacker can still open many legitimate-looking connections and, within each, stay under the limit, collectively still crowding the leader. Equal treatment of all connections quietly assumes all senders are equally entitled to the leader’s scarce budget. They are not. That is the gap the second fix closes.

The second fix: stake-weighted quality of service

Solana already has a built-in, hard-to-fake measure of “who has skin in the game”: stake. A validator’s stake is capital locked into securing the chain; it is exactly the quantity the consensus mechanism already uses to weight votes and the leader schedule. The insight of stake-weighted quality of service (SWQoS) is to reuse that same signal at ingress: allocate the leader’s scarce connection and bandwidth budget in proportion to stake.

Concretely, transactions reach the leader mostly forwarded by other validators (that is what Gulf Stream does). SWQoS reserves a share of the leader’s ingress capacity for connections from staked validators, sized to each validator’s stake. A validator with 2% of stake is entitled to roughly 2% of the reserved connection capacity; a validator with 0.01% gets roughly 0.01%. Anonymous, unstaked senders share whatever capacity is left over.

   leader's ingress capacity, divided by SWQoS
   ─────────────────────────────────────────────

   ┌───────────────────────────────────────────────┐
   │ reserved for staked validators (by stake %)    │
   │  ┌──────────────┐ ┌────┐ ┌─┐                   │
   │  │ big validator│ │mid │ │s│  ...              │
   │  └──────────────┘ └────┘ └─┘                   │
   ├───────────────────────────────────────────────┤
   │ shared, best-effort pool for unstaked senders  │  ◄── spam competes HERE only
   └───────────────────────────────────────────────┘

Now re-run the attack. A spammer with little or no stake is confined to the small best-effort pool and gets a tiny, capped slice of the leader’s attention. Real user traffic, forwarded through well-staked validators, draws on the large reserved share and is not competing against the flood for the same bytes. The flood can saturate the best-effort pool completely and still not touch the reserved capacity. Spam can no longer crowd out real traffic, because the two are no longer drawing from the same bucket.

The deep property is this: stake is expensive to acquire, so it is a Sybil-resistant admission key. Under raw UDP the attacker’s cost per packet was near zero and unbounded parallelism was free. SWQoS puts a price on priority that is denominated in the one resource an attacker cannot cheaply fake — locked capital already securing the chain. It doesn’t stop spam; it demotes it beneath everything that has stake behind it.

Under the hood — QoS is triage, not a firewall

It is worth being precise about what SWQoS is and isn’t. It is not a filter that decides “valid vs invalid” — that is sig-verify’s job, the next stage. SWQoS is a scheduler for scarce ingress capacity: when demand exceeds what the leader can accept, it decides whose packets to accept first and whose to drop. Under light load, when there is capacity to spare, even unstaked senders get served fine — the weighting only bites under contention, which is exactly when it must.

Think of it as an emergency room. Everyone is admitted when the waiting room is empty. When it overflows, triage orders patients by severity — here, by stake — so the most-entitled traffic is seen first and the least-entitled waits or is turned away. The system degrades gracefully under load instead of catastrophically: the last traffic to be dropped is the traffic with the most at stake, and the first to be dropped is the anonymous flood.

   old behavior (UDP firehose)          new behavior (QUIC + SWQoS)
   ──────────────────────────────       ───────────────────────────────────
   load rises → leader absorbs all      load rises → leader admits by stake
   → everything competes equally        → unstaked flood confined to a pool
   → real txs drop alongside spam       → staked/real txs keep their reserve
   → forwarding storm, then halt        → graceful degradation, no storm

Together: admission control the firehose never had

Read as a pair, QUIC and SWQoS give the leader the two capabilities the old ingress path structurally could not have. QUIC provides backpressure — the ability to say “not right now” at the door rather than absorbing everything and dropping late. SWQoS provides prioritized admission — the ability to say “you before them” when the door is crowded, using a signal an attacker cannot cheaply forge.

That combination is precisely the antidote to the failure mode this part diagnosed. The forwarding storm depended on the leader being a passive, anonymous sink that had to fully receive a flood before reacting. Give the leader a connection to meter, a window to throttle, and a stake-ranked queue to triage, and the flood no longer converts into a storm: it is capped at the connection, confined to the best-effort pool, and shed early — before it can consume the execution budget that the no-fee-market spam amplification was designed to exhaust.

But note carefully what this fix does and does not do. It fixes who gets in and how fast — admission and rate. It does not price the transactions that do get in. Two legitimate users both fairly admitted still have no way to signal which of them is more urgent, and no way to bid for priority inside a contended block. That is a different problem — pricing, not admission — and it is the subject of the next page, Pricing the Load — Local Fee Markets & Priority Fees. QUIC and SWQoS get you to the door in the right order; priority fees decide what happens at the counter.

The honest trade-offs

None of this is free, and a first-principles reader should hold the costs next to the benefits.

It privileges the well-connected. SWQoS bakes existing stake distribution into ingress priority. A high-stake validator’s forwarded traffic is favored over an anonymous newcomer’s by design. That is the point — it is what makes stake a Sybil-resistant key — but it means the ingress path is no longer stake-neutral, and small or new participants sending directly (without a well-staked forwarder) live in the contended best-effort pool. It nudges users toward routing through well-staked infrastructure, a mild centralizing pressure.
QUIC has real overhead. A handshake and per-connection state cost more CPU and memory than fire-and-forget UDP. The connection setup adds latency to a sender’s first transaction, and maintaining thousands of connections is itself a resource the leader must budget — one that a clever attacker will probe (connection-exhaustion attacks become the new frontier, which is why the max-connection cap and per-IP limits matter). Solana traded a cheap, defenseless door for a more expensive, defensible one.
It is more moving parts. UDP ingest was a handful of lines conceptually. QUIC plus SWQoS is connection management, flow-control tuning, a stake-weighted scheduler, and the parameters that size the reserved-vs-best-effort split — all of which must be tuned and can themselves misbehave under novel load. Complexity is a reliability cost, and this fix spends it deliberately to buy a defensible front door.
It mitigates, it does not eliminate. SWQoS demotes spam; it does not make spam free to ignore. A flood can still saturate the best-effort pool and degrade service for unstaked direct senders. The goal was never “no spam” — it was “spam can’t take down the network,” and that is a bar this clears while pricing (next page) handles the rest.

The architect’s lens

Why does it exist? Because the original ingress path — raw, unauthenticated UDP — was anonymous and rateless, so the leader could neither identify a flooder nor refuse a flood. Every outage in this part traced back to that one fact. QUIC and SWQoS exist to give the leader’s front door a lock (identity), a meter (flow control), and a priority queue (stake) so it can practice admission control at all.
What problem does it solve? Spam crowding out real traffic. QUIC turns anonymous packets into metered connections the leader can throttle per source; SWQoS then reserves ingress capacity in proportion to stake, so a cheap, low-stake flood is confined to a small best-effort pool and cannot starve legitimate, well-staked traffic — directly defusing the forwarding storm failure mode.
What are the trade-offs? It privileges high-stake, well-connected participants by design and nudges users to route through staked infrastructure. QUIC adds handshake latency, per-connection CPU/memory, and a new connection-exhaustion attack surface. And it is more moving parts to tune than fire-and-forget UDP. It mitigates spam rather than eliminating it.
When should I avoid it? On a chain that has a working fee market and a shared mempool, pricing already rations access, so heavy stake-weighted ingress control buys less. And a low-throughput chain whose leader is never the network’s bottleneck gains little from elaborate admission control — this is a fix specifically for a firehose-style, mempool-less, near-zero-fee ingress path like Solana’s.
What breaks if I remove it? Drop back to raw UDP and the leader loses backpressure and per-source metering entirely — an anonymous, spoofable flood can once again saturate ingress and reignite the forwarding storm. Keep QUIC but remove SWQoS and every connection is treated equally, so an attacker opening many under-the-limit connections can still collectively crowd out real users: fairness-by-connection is not the same as fairness-by-stake, and only the latter makes spam pay in a resource it cannot fake.

Check your understanding

Raw UDP was described as “anonymous and rateless.” Name the two capabilities that phrase is missing, and explain why both must be missing for the leader to be defenseless against a flood.
QUIC is built on top of UDP and keeps its speed. What two things does QUIC add back that raw UDP threw away, and how does each one help the leader ration ingress?
Explain stake-weighted QoS in one sentence, then say precisely what resource an attacker would have to acquire to buy priority under it — and why that makes it Sybil-resistant.
SWQoS is described as “triage, not a firewall.” Under light load, does an unstaked sender get served? When does the stake weighting actually bite, and what does “graceful degradation” mean here?
This page fixes ingress but explicitly leaves one problem for the next page. What is that problem, and why can’t QUIC + SWQoS solve it?

Show answers

Missing: a connection/identity (so the leader can tell “this sender again” and rate-limit per source) and flow control/backpressure (so the leader, not the sender, sets the pace and can refuse to receive). Both must be missing to be defenseless: with identity but no flow control the leader knows who is flooding but still must absorb it; with flow control but no identity it can throttle in aggregate but an attacker spoofing source addresses makes every packet look new. You need both to meter and refuse a per-source flood.
QUIC adds a connection (established by a handshake, giving the leader a per-sender identity to count packets and bytes against, plus a cap on total concurrent connections) and flow control (the receiver advertises how much data it will accept in flight, so the leader grants bandwidth instead of passively absorbing whatever arrives). Together they let the leader throttle a single source and refuse new connections under load — backpressure the firehose lacked.
SWQoS allocates the leader’s scarce ingress capacity in proportion to validator stake, so higher-stake forwarders’ traffic is prioritized over anonymous senders. To buy priority an attacker must acquire stake — capital locked into securing the chain — which is expensive and cannot be faked by spinning up more identities, making it a Sybil-resistant admission key.
Yes — under light load there is spare capacity and even unstaked senders are served. The weighting only bites under contention, when demand exceeds what the leader can accept; then it admits by stake, so the reserved staked capacity is protected and the anonymous flood is confined to the best-effort pool. “Graceful degradation” means the last traffic dropped is the highest-stake traffic and the first dropped is the anonymous flood, instead of everything competing equally and failing together.
It leaves pricing — how to rank two legitimately admitted transactions by urgency and let users bid for priority inside a contended block. QUIC + SWQoS only control admission and rate (who gets in, how fast), not value: two fairly-admitted users still have no way to signal who is more urgent. That is what local fee markets and priority fees solve.