Skip to main content

SWQOS

TL;DR
  • What — Priority Solana transaction routing via two distinct submission paths: HTTP RPC and QUIC.
  • Best for — Trading bots and settlement systems whose transactions aren't landing during congestion.
  • Skip if — You need leader-slot-specific bundle submission — use the TPU-direct half of Relayer/TPU for that.
  • Edge — Stake-weighted priority backed by Everstake's validator. No API key on either flow.

Stake-weighted priority lane into the validator's TPU. Submit transactions through SWQOS endpoints and they get prioritized in block-building because they ride on Everstake's stake weight — the lane unstaked RPCs queue behind. Pubkey-scoped (QUIC) or open with tip (HTTP).

Use this if…​

  • Your Solana transactions aren't landing during congestion.
  • You're running a trading or settlement system where landing rate, not raw send rate, is the bottleneck.
  • You want to pay per-transaction tips for inclusion priority instead of running an authenticated subscription.

How it works​

When a Solana validator builds a block, it processes transactions in stake-weighted order. SWQOS routes your transactions through Everstake's validator, with a tip-paying instruction inside each transaction that bumps its priority within that ordering. The result is a higher landing rate during congestion than public RPCs achieve.

This is a probability shift, not a guarantee. SWQOS doesn't bypass slot leaders or skip the standard transaction lifecycle — it just gets you closer to the front of the line at our validator, and at every other validator that subscribes to the same stake-weighted scheduler.

Two submission flows​

SWQOS exposes two distinct paths. They have different authentication models and trade-offs.

HTTP / RPC endpoint​

  • No API key, no allowlist — public endpoint
  • Tip-instruction required — each transaction must include a SystemProgram::transfer paying ≥1,000,000 lamports to a designated Everstake tip account
  • Standard sendTransaction JSON-RPC — but no preflight, and only the submission method is exposed (you fetch blockhash from elsewhere)
  • HTTP/1.1 and HTTP/2 with persistent connections; for lowest latency use h2c (HTTP/2 prior knowledge)
  • Default rate limit: 10 TPS per client

QUIC endpoint​

  • Pubkey allowlist — you provide a Solana pubkey at subscribe time; only QUIC connections authenticated with that keypair are accepted
  • Tip-instruction still required — same 1,000,000-lamport tip-transfer rule applies inside the transaction
  • Raw serialized transactions over QUIC stream — not Solana SDK compatible; you build your own QUIC client
  • 10s keep-alive, 8 connections / minute per authorized client
  • Lower latency than the HTTP path

You typically pick one based on infrastructure: HTTP if you want to use a standard SDK and accept fetching blockhash separately; QUIC if you can build a custom client and need lowest latency.

Tiers​

Both flows are billed under the same plan. The differences in tier are about regional access and concurrent allowlist size for QUIC.

TierConnectionRegionsQUIC pubkeysBest for
Pay-As-You-GoRPCFRA, AMS, NY, TYO, LON, SGP, Main—Low-volume or testing
BaseQUICFRA10Single-region desks
ProQUICFRA, AMS, NY, TYO100Multi-region trading systems
CustomQUICFRA, AMS, NY, TYOCustomHigh-frequency, enterprise

Extra regions — London (LON), Dublin (DUB), and Singapore (SGP) are available on the QUIC tiers as purchasable per-region add-ons; add them in the dashboard. With these, SWQOS is live in all 7 regions.

Live pricing is in the dashboard.

Next​