Every Solana RPC provider now sells some version of “staked connections”: your transactions ride a validator’s stake to the leader’s door, so they get in when unstaked traffic does not. The pitch is right. The mechanism is a formula in the validator’s QUIC server, and reading it tells you three things the pitch does not — how much a connection actually gets, where extra stake stops helping, and why a sender on the other side of the planet is given more room than one next door.
The door: connections and streams
A leader accepts transactions over QUIC. Each sender holds a connection, and sends each transaction on a stream inside it. The leader limits both.
Connections are split into two pools, each 2,000 deep by default: one for senders whose identity holds stake, one for everyone else. A staked identity may hold up to 16 connections, an unstaked one up to 8, and each IP address may open 8 new connections per minute by default — the validator binary raises that to 32 to tolerate container hosts.
Staked senders are keyed by public key, not IP: the 16-connection cap and any ban follow the identity across every address it connects from. All connections under one identity share a single stream counter, so opening more connections buys no more streams.
The stream allowance, exactly
How many streams a connection may have in flight at once is the number that decides whether your transactions are admitted under load. For a staked sender:
streams = clamp( stake_ratio × (100,000 − 128) + 128, 128, 512 )
where stake_ratio is the sender’s stake divided by total stake. Then every sender, staked or not, has the result scaled by round-trip time:
streams × clamp(rtt_ms, 50, 350) ÷ 50
An unstaked sender gets a flat 128 before the RTT scaling.
Three things fall out of the arithmetic.
- The ceiling is low. The formula reaches 512 when stake_ratio × 99,872 + 128 = 512, which is a stake ratio of about 0.38%. A sender holding more than roughly 0.38% of all stake — on the order of 1.5 million SOL at today’s totals — gets exactly the same 512 streams as one holding 0.38%. Beyond that point, stake buys zero concurrency.
- Distance is rewarded. The RTT factor runs from 1× at 50 ms to 7× at 350 ms. A peer 350 ms away gets seven times the in-flight streams of one 50 ms away. That is bandwidth-delay-product scaling — the far peer needs more in flight to keep the same throughput — but it means a sender who measures a long RTT to a leader is granted more room, not less.
- There is a trapdoor at the bottom. A staked identity whose stake ratio is below 1/50,000 — about 8,000 SOL at a 400-million-SOL total — is reclassified as unstaked. Small stake is not a small lane; it is no lane.
Throttling: when the budget is actually enforced
The allowance above is a cap on concurrency. A second mechanism caps rate: the leader admits at most 500 new streams per millisecond across all senders, and it meters per 100 ms window.
The unstaked pool is throttled always: each unstaked connection gets 20 streams per 100 ms, derived from a 200-transactions-per-second budget per connection.
The staked pool is throttled only under load. The server tracks an exponential moving average of stream load, and until that average reaches 95% of capacity, a staked sender may use the whole staked budget — 40,000 streams per 100 ms. Past 95%, each staked sender’s share becomes its stake ratio times 40,000, with a floor of 21.
So the system is bimodal. In a quiet block, a staked connection with any stake at all is effectively unlimited. In a hot block, it gets its proportional share, and the share of a small validator is small.
How stake is bought: the override
The stake the server consults is not only the validator’s real delegation. A validator can grant virtual stake to any peer identity through its admin interface, and the server refreshes its view of staked nodes every 5 seconds. That is the mechanism under every “staked connections” product: the provider’s sending identity is given stake it does not hold, by validators it has an arrangement with, and the leader treats it accordingly.
Two properties of the override matter to a buyer. It takes effect, or is revoked, within five seconds. And it only counts at validators that have granted it — a lane sold by one validator is a lane at that validator’s slots, which are a fraction of the schedule.
Stake is also revalidated on a randomised one-to-two-hour cycle, and a stale cache can over-grant by at most a factor of two. Increases never evict an existing connection; a newcomer with more stake evicts a lower-staked connection only by winning a two-sample lottery, and if it loses it is silently demoted to the unstaked pool.
What this means for a transaction you send through an RPC
Your wallet never holds a connection to a leader; your RPC provider’s sending node does. The node’s identity, its granted stake, and its RTT to the current leader decide its stream allowance, and under load that allowance is what your transaction competes for.
If the provider’s node is unstaked, your transaction is in the 128-stream pool with every other unstaked sender’s, throttled to 20 streams per 100 ms per connection, always. If it holds a sliver of stake above the 1/50,000 floor, it is in the staked pool, unthrottled until the leader is 95% loaded, and then proportional. If it holds 0.38% or more, it has the maximum, and more stake than that is marketing.
Stake-Weighted QoS: Questions People Actually Ask
What is stake-weighted QoS on Solana?
A rule in the leader’s QUIC server that allocates connection slots and in-flight streams by the sender’s share of stake. Staked senders get between 128 and 512 concurrent streams, scaled by round-trip time; unstaked senders get 128 and are rate-limited always.
How much stake does an RPC need for the maximum lane?
About 0.38% of total stake. At that ratio the formula reaches its 512-stream cap, and additional stake buys no more concurrency.
Can a validator sell its stake-weighted lane?
Yes. A validator can grant virtual stake to a peer identity through its admin interface; the server refreshes the grant within five seconds. The lane applies only at that validator’s own slots.
Why does a far-away sender get more streams?
The allowance is multiplied by round-trip time, clamped between 50 and 350 ms and divided by 50, so a 350 ms peer gets seven times the in-flight streams of a 50 ms peer. It is bandwidth-delay scaling, not a reward.
The three numbers to ask a provider for
Their sending identity’s stake ratio — real or granted — against the 1/50,000 floor and the 0.38% ceiling.
Which validators have granted it, because the lane only exists at those validators’ slots.
Their RTT to leaders, because the server multiplies the allowance by it.
Nothing else in the pitch changes the formula.
This is door three of the seven places a transaction disappears, and it decides who is heard before the fee ranking is ever consulted. Stake buys a seat in consensus too — the 2,000-seat cap.
Constants read from the Agave validator source at commit beee69b958: streamer/src/nonblocking/swqos.rs, streamer/src/quic.rs and core/src/staked_nodes_updater_service.rs.