The problem: leaders drop transactions under load
When a Solana leader is producing a block, it exposes a single QUIC ingress - the TPU - and every client on the network is trying to push transactions into it at once. That ingress has finite capacity. During a mint, a liquidation cascade, or any popular event, far more packets arrive than the leader can possibly accept, and the excess has to go somewhere. That somewhere is the floor.
This is the failure mode behind most "my transaction vanished" stories. The transaction was valid, the blockhash was fresh, the fee was reasonable - and it still never landed, because the leader's ingest was saturated and the packet was dropped before it was ever considered. We break down the full set of drop causes in Why Solana Transactions Fail (and How to Land Them); this post zooms in on the one that dominates exactly when landing matters most.
The cruelest part of congestion is that it hits hardest in the moments you most need to land. The network is busy because something is happening, and that is precisely when your packets are most likely to be dropped at the door.
What SWQoS actually is
Historically, that QUIC ingress was a shared free-for-all. Under congestion the leader dropped packets more or less indiscriminately, and a well-funded trading firm and a hobbyist endpoint competed on equal footing for a lane that could not fit either of them. Whether you landed was close to luck.
Stake-weighted QoS (SWQoS) replaces that lottery with an allocation rule. Instead of one undifferentiated lane, the leader carves its ingest capacity into reserved slices and hands them out in proportion to the stake behind each connection. A connection that originates from - or is sponsored by - a staked validator is entitled to a share of the leader's QUIC capacity sized to that validator's stake. The more stake behind your connection, the larger the slice of the leader's attention you hold when everyone is shouting at once.
The key word is reserved. A stake-weighted slice is not "you go slightly faster." It is capacity that is set aside for you and cannot be flooded away by the unstaked crowd. When the shared lane collapses, your slice is still there.
How it works: stake to proportional QUIC capacity
Concretely, the path looks like this. Your transaction leaves a connection that carries a stake identity. When that connection opens a QUIC stream to the current leader's TPU, the leader looks up the stake associated with it and admits packets up to the share that stake entitles you to. Unstaked or lightly-staked connections share whatever capacity is left over after the staked reservations are honored, and that leftover lane is the first thing to saturate and drop under load.
leader TPU (QUIC ingress, finite capacity)
├─ staked connection (large stake) → large reserved slice → admitted
├─ staked connection (small stake) → small reserved slice → admitted
└─ unstaked / public lane (shared) → leftover, oversubscribed → throttled / dropped firstYou do not have to run a validator to sit on the admitted side of that diagram. You get there by sending through a connection that is backed by stake - which is exactly what a staked or dedicated RPC path provides. The provider's stake sizes the reserved slice, and you inherit it without operating a validator, managing delegations, or staying in the leader rotation yourself.
What it means for you
The practical effect is sharp and easy to observe. During the calm slots, SWQoS barely matters - there is spare capacity, so the shared lane admits nearly everyone. During the congested slots, the difference is the whole game. A stake-weighted path sails through on its reserved slice while public endpoints get throttled or dropped, and your landing rate stays flat exactly where an unstaked setup's landing rate falls off a cliff.
If you have ever watched your fills evaporate the moment the network gets busy, then come back the instant it quiets down, you have seen SWQoS from the outside. The endpoint that was "fine" in testing was simply never tested in the slots that count. A staked path is what keeps the line flat through the spike.
Land in the slots that actually matter.
rpc edge gives you a stake-weighted, co-located path to the cluster - so your transactions are admitted when public endpoints get throttled under load.
SWQoS, priority fees, and direct delivery together
SWQoS is one of three levers, and they are not interchangeable - each solves a different stage of getting a transaction into a block. The mistake is treating any one of them as "the" landing trick. They compound, and a serious setup pulls all three.
| Lever | What it controls | When it acts |
|---|---|---|
| Stake-weighted QoS | Whether the leader admits your packets at all under congestion | At ingest, before the transaction is even considered |
| Direct leader delivery | Whether your bytes reach the current and upcoming leaders' TPUs in time | In transit, deciding which leader sees it and how fast |
| Priority fee | Where you sit in the leader's ordering once admitted | At block-build, after ingest and delivery succeed |
Read top to bottom, that is the actual lifecycle of a landing transaction: it must be delivered to the right leader, admitted through ingest, then ordered into the block. SWQoS owns the admission step, direct delivery owns transit, and the fee owns ordering. rpc edge's transaction sender runs all three on one path - delivering straight to the leaders' TPUs over stake-weighted connections with a dynamic fee - which is why we walk through the leader-schedule and delivery half of the picture in Landing Transactions on Solana: Leader Paths and the Jito Block Engine.
Limits and misconceptions
SWQoS is powerful, but it is narrow, and it is worth being precise about what it does not do.
It does not order your transaction. Once your packets are admitted, they sit in the same prioritization as everyone else's admitted transactions, sorted by compute-unit price. Stake gets you in the room; the fee decides where you stand in it.
It does not guarantee inclusion. Admission is necessary, not sufficient. A transaction with a stale blockhash is still rejected. A transaction with a fee too low for current conditions is still deprioritized behind better-paying ones. SWQoS removes one of the biggest drop causes - it does not absolve the rest of the delivery path.
And it is not something you bolt onto a public endpoint after the fact. The stake has to be behind the connection your packets travel on. That is why SWQoS is a property of a staked or dedicated RPC path, not a flag you flip on shared infrastructure. If your traffic shares a lane with thousands of other users, you are on the leftover side of the ingest diagram no matter what your client config says.
The takeaway
Most Solana landing failures are not on-chain failures - they are packets dropped at a saturated leader, and stake-weighted QoS is the mechanism that decides who gets dropped. SWQoS reserves ingest capacity in proportion to stake, so a staked connection is admitted in exactly the congested slots where the public lane collapses. Treat it as the admission layer of a three-part stack: stake to be accepted, direct delivery to arrive, a dynamic fee to be ordered. rpc edge runs that whole stack co-located beside Solana stake clusters - a stake-weighted transaction sender and RPC next to the leaders - because admission, like every part of landing, is a delivery race, and delivery races are won by proximity and stake.