Stake-Weighted QoS and Staked Connections

Stake-Weighted Quality of Service (SWQoS) is Solana’s mechanism for allocating transaction forwarding capacity based on stake weight. It gives staked validators (and RPC nodes with staked connections) priority access to the leader’s Transaction Processing Unit (TPU).

How SWQoS works

When you send a transaction to the Solana network, it must reach the current slot leader’s TPU. The leader accepts incoming transactions over QUIC, Solana’s transport protocol. SWQoS determines how much bandwidth each sender gets:

1. 80% of QUIC capacity is reserved for connections from staked nodes, allocated proportionally to their stake weight.
2. 20% of QUIC capacity is shared among all unstaked connections (standard RPC nodes, direct client connections).

During normal load, the 20% unstaked pool is sufficient. During congestion — NFT mints, token launches, liquidation cascades — the unstaked pool fills up and transactions are dropped. Staked connections bypass this bottleneck entirely.

Why this matters for transaction landing

A transaction sent from an unstaked RPC node during congestion competes with every other unstaked sender for 20% of the leader’s capacity. Common symptoms:

• Transactions silently dropped (never confirmed, never errored).
• High retry rates with eventual BlockheightExceeded errors.
• Inconsistent landing rates — fine during off-peak, poor during peak.

A staked connection gets dedicated bandwidth proportional to stake. Even a small amount of stake (100+ SOL) provides a meaningful allocation above the unstaked floor.

How staked connections work

Your App → RPC Node (with staked identity) → QUIC → Leader TPU (SWQoS)
                                                      ├─ 80% staked pool ← your tx lands here
                                                      └─ 20% unstaked pool

The RPC node must:

1. Run a validator identity keypair with delegated stake.
2. Establish a QUIC connection to the leader using that identity.
3. The leader verifies the identity against the stake registry.
4. Transactions forwarded through this connection get staked-tier bandwidth.

You do not need to run a validator yourself. RPC providers offer staked connections as a service — the provider holds the staked identity and forwards your transactions through it.

Staked vs. unstaked: performance comparison

These numbers vary by network conditions and are based on community benchmarks as of 2026-10-21.

When you need staked connections

Essential for:

• Trading bots (arbitrage, liquidation, sniping) where landing speed is profit.
• High-frequency applications sending many transactions per second.
• Any application where transaction drop rates directly impact user experience or revenue.

Nice to have for:

• General dApps with moderate transaction volume.
• Applications that can tolerate occasional delays.

Not needed for:

• Read-only applications (no transactions to send).
• Devnet/testnet development.
• Low-frequency operations (once per minute or less).

Choosing a staked RPC provider

When evaluating providers, ask:

1. How much stake? More stake = more bandwidth. Look for providers with significant stake delegations.
2. What is the forwarding path? Direct QUIC to the leader is ideal. Some providers proxy through intermediate nodes, adding latency.
3. Do they support sendTransaction enhancements? Features like automatic retry, skip-preflight, and leader-aware routing complement staked connections.
4. Geographic proximity to validators. Lower latency between the RPC node and the leader means faster forwarding.

Combining with other landing strategies

Staked connections work best as part of a multi-layered approach:

1. Staked connection — ensures your transaction reaches the leader’s staked pool.
2. Priority fees — positions your transaction higher in the leader’s execution queue.
3. Jito bundles — for atomic execution and ordering guarantees during Jito validator slots.
4. Multiple leader forwarding — sending to the current and next leader for redundancy.

Each layer addresses a different bottleneck: SWQoS handles the network ingress layer, priority fees handle the block scheduling layer, and Jito handles the ordering layer.

FAQ

Can I stake my own RPC node? Yes. You need a validator identity keypair and SOL delegated to it. Even without producing blocks (running as a “non-voting” node), the staked identity gives you SWQoS bandwidth proportional to the delegated stake.

How much stake do I need? There is no hard minimum. The bandwidth allocation scales linearly with stake. Even 100 SOL of stake provides a noticeable improvement over unstaked during congestion. For competitive trading, providers typically stake thousands of SOL.

Does SWQoS affect RPC read requests? No. SWQoS only governs the TPU connection for forwarding transactions to the leader. Read operations (getAccountInfo, getBalance, etc.) are handled by the RPC node’s local state and are not affected by stake weight.

Is SWQoS the same as “priority sending”? No. SWQoS controls network-level access to the leader (can your transaction reach the TPU?). Priority fees control execution ordering within the leader’s block (when does your transaction execute?). They are complementary.

Updated: 2026-10-21