# SWQoS

**RPC Fast** offer own sender service – **Beam**, which routes signed transactions through partner delivery paths such as SWQoS-backed validators, Jito Block Engine submission, and other provider-specific low-latency infrastructure. [Read more](https://docs.rpcfast.com/rpc-fast-saas-solana/sending-transactions/rpc-fast-beam-beta).

## Overview

**Stake-Weighted Quality of Service (SWQoS)** is a networking mechanism in Solana that prioritizes transaction delivery based on validator stake.

Because Solana runs on Proof of Stake, validators with more delegated SOL are allocated proportionally more bandwidth when forwarding transactions to the current leader. SWQoS uses this stake weighting to determine **how much transaction traffic** a node is allowed to push through **to a leader’s TPU** (Transaction Processing Unit).

In simple terms:

> Stake = network bandwidth priority.

During congestion, stake-backed traffic receives preferential access to the leader, while unstaked traffic is significantly rate-limited.

* RPC nodes themselves *cannot stake*, but they can form trusted, peered connections with a **staked validator**. The validator then forwards transactions on the RPC’s behalf – effectively giving the RPC *virtual stake access* to that priority lane.

SWQoS ensures that transactions sent through staked connections are much more likely to be admitted quickly into the leader’s pipeline – before on-chain priority fees and ordering – reducing packet loss and delays under load.

***

### How SWQoS Works

<table><thead><tr><th width="274.19281005859375">Concept</th><th>Impact</th></tr></thead><tbody><tr><td><strong>SWQoS Priority Lanes</strong></td><td>Higher chance that transactions make it to the leader, especially under congestion.</td></tr><tr><td><strong>Staked Validator Peering</strong></td><td>RPCs gain priority by proxying through validator stake.</td></tr><tr><td><strong>Pre-Priority Fee Optimization</strong></td><td>SWQoS improves <em>access</em>, while priority fees affect <em>inclusion ordering</em>.</td></tr><tr><td><strong>Critical for HFT/DeFi</strong></td><td>Ensures timing reliability, landing rates, and lower variance.</td></tr></tbody></table>

1. **Staked Validator Priority:**\
   Validators with significant delegated stake are allowed to send more packets / receive proportionally more quota to establish QUIC/TPU connections to leaders, acting like a *priority lane* relative to non-stake traffic.
2. **Peered RPCs Gain Priority via Validators:**\
   Since RPCs are unstaked, they must be paired with a staked validator. That validator configures stake maps/peering so your RPC traffic inherits a portion of their access, boosting your transaction throughput. \
   **Staked connection:** Your RPC → Trusted staked validator → Current leader
3. **Bandwidth Allocation:**\
   SWQoS does *not* eliminate fee competition; it improves *access*. Once on the leader’s pipeline via SWQoS lanes, transactions still compete based on priority fees.

#### SWQoS ≠ Priority Fees

It’s important to separate the two:

<table><thead><tr><th width="276.80145263671875">Layer</th><th>What It Controls</th></tr></thead><tbody><tr><td><strong>SWQoS</strong></td><td>Whether your transaction reaches the leader under congestion</td></tr><tr><td><strong>Priority Fees</strong></td><td>Ordering of transactions once inside the leader queue</td></tr></tbody></table>

You can pay high priority fees – but if your packets never reach the leader because your connection is rate-limited, the fee doesn’t matter.

For high-performance systems, **delivery probability comes first.**

***

### Why SWQoS Matters for High-Performance Use Cases

Here’s where SWQoS becomes **crucial** for latency- and reliability-sensitive applications:

#### HFT & Trading Bots

* **Consistent landing rates:** Bots competing for arbitrage or liquidation opportunities must consistently land transactions in the same slot as targets. SWQoS increases the likelihood that a transaction *reaches the leader’s TPU queue early*, reducing misses during momentary congestion.
* **Reduced uncertainty:** Without SWQoS, even high priority fees may fail to deliver a transaction if the network refuses the connection itself under load. SWQoS helps ensure the connection isn’t the bottleneck.

#### DeFi Infrastructure

* **Reliability under load:** Time-critical DeFi ops like liquidations or automated market making thrive on guaranteed delivery. Public or unstaked RPC endpoints can easily fail during peak mints/NFT launches – SWQoS routes around this.
* **Scalability:** As demand scales, staked connections deliver higher *effective throughput* and can be further bolstered with stake-backed allocation models (e.g., TPS quotas tied to liquid stake holdings).

#### General RPC Performance

* **Fewer dropped packets:** By bypassing the limited non-staked queue, you avoid dropped or delayed transaction packets, which boosts user experience for wallets, games, and other dApps during traffic spikes.
* **Improved Sybil resistance:** Stake weighting makes the network harder to spam, lowering risk of malicious congestion.

***

### Why Combining SWQoS + ShredStream Matters&#x20;

Latency-sensitive systems operate in a tight feedback loop:&#x20;

> Detect opportunity –> Construct transaction –> Deliver to leader –> Observe inclusion/result

ShredStream improves information latency; SWQoS improves delivery probability. **Together, they reduce both information lag and execution uncertainty.**

**You likely need both** SWQoS and ShredStream if:

* You compete in same-slot MEV races.
* Your strategy depends on reacting within sub-slot windows.
* Your PnL is sensitive to packet drops.
* You operate during high network contention periods.

For casual dApps, neither is required. For adversarial systems, both become infrastructure basics.