How transaction landing priority works on Solana

Every Solana trade that matters is a race. Two transactions targeting the same pool can be signed in the same millisecond, but only one gets the fill. The difference is rarely the strategy that built the transaction — it is Solana transaction landing: which transaction reaches the block producer first, over a connection the block producer actually prioritizes.

This post walks through the mechanics: how slots and leaders work, why latency decides races, what stake-weighted QoS changes about who gets in, and where a staked relay like FastRelay fits.

Slots, leaders, and where transactions actually go

Solana produces blocks in slots of roughly 400 milliseconds. For each slot, exactly one validator — the leader — has the right to produce the block, and the leader schedule is computed ahead of time for the whole epoch. Everyone on the network knows which validator will be leading hundreds of slots from now.

That determinism shapes everything about transaction delivery. Solana does not use a global mempool where transactions wait to be picked up. Instead, transactions are pushed directly to the leader — to its Transaction Processing Unit (TPU) over the QUIC protocol. Your RPC node, or whatever sits between you and the network, forwards your transaction to the current leader and the next few leaders in the schedule.

The consequence: landing a transaction is a delivery problem. You need your bytes to arrive at one specific machine, somewhere in the world, inside a window measured in milliseconds — and you need that machine to accept your connection when they arrive.

Why latency loses races

A slot lasts about 400 milliseconds. If your transaction misses the current leader's window, the best case is the next slot; under congestion it can be several slots later, or never. For launch snipes, liquidations, and arbitrage, a one-slot delay is usually the whole outcome: the opportunity was taken by whoever landed in the slot before you.

Latency accumulates from three places:

• Geography. Leaders rotate across validators all over the world. If your transaction originates far from the current leader, physics alone can cost you the slot.
• Hops. A typical path — wallet to RPC provider to forwarding layer to leader — adds queuing and processing at every step.
• Admission. Even after your packet arrives, the leader has to accept it. Under load, that is where most transactions actually die.

Priority fees are often misunderstood here. A priority fee influences how a transaction is ordered inside a block the leader is building. It does nothing for a transaction that arrived too late, or that the leader's ingress dropped. Arrival comes first; ordering is second.

Stake-weighted QoS: the leader's door policy

The admission step is governed by stake-weighted quality of service (SWQoS). When demand exceeds what a leader can ingest, it does not treat all connections equally: the bulk of a leader's inbound QUIC connection capacity is reserved for connections backed by staked validators, allocated in proportion to their stake. Unstaked connections — which is what most public RPC traffic ultimately rides on — share a small remaining pool, and that pool is the first thing throttled or dropped when the network is busy.

In other words, the network's answer to "who gets in when everyone wants in" is staked SOL. A transaction entering through a high-stake connection travels in a reserved lane. A transaction entering through an unstaked connection is standing in the general-admission queue, precisely at the moments when the queue is longest.

We cover the SWQoS mechanics in more depth in Why staked SOL decides who lands first on Solana.

How relays with staked connections land first

Running meaningful stake is capital-intensive, which is why most traders cannot solve this on their own. A staked relay solves it structurally:

• It maintains stake-backed connections to leaders, so its transactions enter through the reserved SWQoS lanes rather than the public pool.
• It keeps persistent, pre-warmed QUIC connections to the current leader and the upcoming leaders in the schedule, eliminating connection setup from the critical path.
• It delivers 0-hop: your transaction goes from the relay straight to the leader, instead of through a chain of forwarding services.

The relay pools priority that no single user could afford to run, and everyone who submits through it inherits the delivery path.

Where FastRelay fits

FastRelay is this kind of infrastructure, built for latency-sensitive Solana flow:

• Four regions — Frankfurt (primary), Amsterdam, New York, and Tokyo — so there is always an ingress point close to you, wherever the current leader is.
• QUIC ingestion at ~0.1ms dispatch for the fastest path (HTTPS and WebSocket transports are also available for simpler integrations).
• A 5-channel broadcast pipeline — stake-weighted QUIC, QUIC TPU, UDP TPU, RPC fan-out, and Jito relayers — with QUIC TPU coverage of the next 48 leaders, so the transaction is racing down multiple paths at once.
• 0-slot execution: transactions land in the same slot they are sent, with a 99.8% same-slot landing rate.
• MEV protection via private routing — transactions are never broadcast to the public mempool before they land.

Access works two ways. Anyone can submit with a tip of at least 0.001 SOL per transaction — or pay the tip in $RELAY at a discount. And staking $RELAY gives your transactions landing priority over unstaked users on the relay itself, scaled to how much you stake.

The takeaway

Solana transaction landing is not magic and it is not luck. It is a pipeline: know the leader, be close to the leader, arrive over a connection the leader prioritizes. Stake-weighted QoS made the last step the decisive one — and made staked infrastructure the practical way for individual traders to compete.

If you want the full picture of how the relay, the token, and staking fit together, the litepaper covers it end to end.