The previous lecture said "the leader schedule is public and known in advance." This lecture goes into what that schedule actually looks like, how it's computed, and what happens to your transaction once it arrives at a leader's queue. The schedule matters for users because it determines which validator can include your transaction in any given slot, which in turn shapes priority fees, transaction routing, and the entire MEV landscape on Solana. By the end you should understand why a stake-weighted, 4-slot, 2-days-in-advance schedule is what the network actually runs.

At any moment, exactly one validator on the network is the leader. The leader's job is simple to state: take incoming transactions, run them through PoH, weave them into the chain, and produce a block. While they're leading, no other validator produces blocks. Their slot is theirs alone.

This is different from how most chains pick a block producer. Bitcoin runs a global race: every miner tries to find a valid block, and whoever finds one first wins the right to extend the chain. Ethereum after the Merge has random validator selection: at the start of each slot, a deterministic shuffle picks one validator to propose, and that validator has the slot for themselves.

Solana takes the random-selection idea and extends it. Instead of picking one validator per slot at the start of each slot, the entire schedule for an epoch is computed up front and published. Every node, including users, RPC nodes, validators, and observers, can look up exactly who the leader is for any slot in the next ~2 days. There is no "we'll find out at the start of the slot." The schedule is already written.

The schedule is generated by a deterministic algorithm using two inputs: the on-chain stake distribution at the start of the previous epoch, and a hash from the previous epoch used as a random seed.

The algorithm allocates slot windows to validators with probability proportional to their stake. A validator holding 1% of the total stake gets approximately 1% of the slot windows in the epoch. A validator holding 5% gets approximately 5%. A validator with no stake gets zero. Validators don't sign up for specific slots. They get assigned them based on stake.

The deterministic part is important. Given the same inputs, every node computes the same schedule. There's no negotiation, no broadcast of "here is the schedule," no need to agree on it. The schedule is implied by data that already lives on chain. Anyone who has the chain state can derive the schedule independently and reach the same answer.

The "previous epoch" timing matters. The schedule for epoch N is computed using stake data from epoch N-1. This gives the network the entire previous epoch to converge on the stake snapshot, validate it, and prepare. By the time epoch N starts, every node has the same schedule for it. Stake changes during epoch N affect epoch N+1 rather than the current one.

An epoch on Solana mainnet is 432,000 slots, which at 400ms per slot is about 2 days. So the leader schedule has a horizon of roughly 2 days at any time. Right now, you can look up who the leader will be 432,000 slots from now, and as long as the current epoch is in progress, that answer won't change.

The diagram shows the next piece: the schedule doesn't assign individual slots to individual validators. It assigns 4-slot windows.

A leader window is 4 consecutive slots. The validator chosen for that window is the leader for all four. After their window ends, the next validator takes the next four. Then the next, and so on, for the entire 432,000-slot epoch.

Why 4 slots and not 1? Two practical reasons.

First, vote propagation latency. When a validator produces a block, other validators need time to receive it, verify it, and broadcast their vote. That round trip takes some milliseconds, and if leadership were changing every 400ms, the new leader's first block would have to start before the previous leader's last block had finished gathering votes. Bundling slots into 4-slot windows means a validator can build on their own previous block from the same window without waiting for external confirmations. The pipelining works.

Second, propagation amortization. When a validator becomes leader, the other validators have to start sending transactions to them via Gulf Stream, and the new leader has to set up their pipeline. There's a small startup cost. Spreading that cost across one slot rather than four would amplify it by 4x.

The trade-off is censorship: a malicious leader who wants to block a specific transaction has 1.6 seconds of guaranteed leadership to drop it, compared to 400ms if every slot had a fresh leader. In practice this isn't a major concern because Gulf Stream sends to multiple upcoming leaders simultaneously, but the trade-off is real.

Once a validator's window starts at slot N, here's what happens for the next 1.6 seconds.

The validator has already been receiving transactions via Gulf Stream from RPC nodes that knew this window was coming. By the time slot N opens, there's a queue of pending transactions ready to process. The validator picks transactions from the queue, executes them in parallel based on their declared accounts, and weaves them into the PoH stream. Each PoH step that includes a transaction is called an entry. Entries accumulate, and at the end of slot N, the accumulated entries form the block for slot N.

The leader doesn't stop at one block. Slot N+1 starts immediately, and the leader picks up where slot N left off, with a fresh batch of entries forming the next block. Same for N+2 and N+3. All four blocks share the same validator as producer.

While producing, the leader is also broadcasting. Each entry, as it's finalized, gets shredded by Turbine and sent out to the validator tree. The other validators are receiving and replaying in parallel with the leader's production. By the time the leader finishes a block, most of the network already has most of it.

This pipelining is what makes 400ms slots viable. The leader isn't doing one slot end-to-end and then handing off. They're doing four overlapping pieces of work simultaneously: receiving transactions, executing them, generating PoH, shredding, broadcasting, and starting the next slot. The network is doing the same work, but for replay rather than production.

At the end of the 4th slot, the leader's window ends. The next validator's window begins. The new leader has been receiving transactions for the upcoming window all along via Gulf Stream, so they don't start cold. The handoff is invisible from the outside.

A slot can fail to produce a block for several reasons. The leader might be offline. Their hardware might be too slow. Their network might be congested. They might be running buggy software. Whatever the cause, the result is the same: the slot just doesn't have a block.

The PoH chain keeps advancing. Validators still record that slot N existed, and that no block was produced for it. The schedule doesn't shift to accommodate the missing block. Validator B's window is still slots 104 to 107 even if B is offline for all four slots. The next validator's window starts at slot 108 as scheduled, regardless.

A small percentage of slots get skipped on mainnet under normal conditions, usually a few percent. The exact number varies based on validator health, network conditions, and software versions. During congestion events or after major software updates, the skip rate can jump for a few hours. Tools like Solana Explorer let you look up any validator's recent skip rate as a measure of operator reliability.

For your transaction, a skipped slot means the leader didn't include it in the block it would have made, so the transaction is still pending. The next leader will see it via Gulf Stream and might include it in their slot, or might not. Wallets and SDKs typically handle this by retrying the transaction submission with a fresh blockhash until it lands or the blockhash expires.

Now the part that connects directly to programmer-visible mechanics. The leader chooses which transactions to include in their block and in what order. The protocol gives them flexibility on this: they're not required to take transactions in any particular order. The default ordering implementation in the standard validator client ranks transactions by priority fee per compute unit, but a leader running custom software could pick differently.

This is why priority fees work the way they do. When you attach a high priority fee to your transaction, you're paying the leader to prioritize your transaction over others. The leader's incentive is to maximize the fees they earn during their window, so transactions with higher per-CU bids get included first.

The 4-slot window also explains why priority fees vary on second-to-second timescales. When a transaction-fee-rich validator is the leader for their window, the going rate for inclusion in those four slots is what they're willing to accept. When a different validator takes over, the going rate can shift. Sophisticated transaction submitters track the leader schedule and adjust their bids based on who's about to lead.

Beyond priority fees, leaders can earn additional revenue from MEV, or maximal extractable value. Because they have full control over transaction ordering within their slots, they can sandwich, arbitrage, or otherwise extract value from the transactions in their queue. Specialized validator software like Jito's client lets leaders accept private order-flow bundles with explicit tips, paid by searchers in exchange for guaranteed ordering. A significant chunk of validator revenue on Solana today comes from this kind of MEV tipping rather than from priority fees alone.

The combined leader revenue picture is:

• The base fee on each signature, which is 5,000 lamports, half burned and half retained as a reward.
• Priority fees attached to transactions, scaled by CU price and CU limit.
• MEV tips from bundle submitters, if the leader runs MEV-aware software.
• A small protocol-level block reward that scales with inflation.

For users submitting transactions, the practical takeaway is: priority fees go to whoever is leading at the time your transaction lands. The leader has full discretion on inclusion, and their incentives are aligned with picking high-bidding transactions first. Bidding too low risks getting skipped over for higher bids. Bidding more than necessary just leaves money on the table.

The last piece of practical value. RPC nodes, the infrastructure that connects user wallets to the validator network, use the leader schedule actively.

When a wallet submits a transaction, the RPC node doesn't broadcast it to a mempool, since there is no mempool, and doesn't send it randomly to peers. The node looks up the upcoming leaders, typically the next 2 to 4 slot windows, and forwards the transaction directly to those validators. The transaction lands in their incoming queue before their slot starts.

This is why some RPC providers consistently get transactions confirmed faster than others. Faster forwarding paths to upcoming leaders means transactions arrive in the queue earlier, with more time to be considered for inclusion. Premium RPC services often colocate their forwarding infrastructure near major validator clusters specifically to reduce this latency.

The schedule's 2-day horizon means RPC routing decisions can be planned well in advance. RPC services know who their next 100+ leaders will be and can maintain warm connections, latency-tuned routes, and inclusion-pricing oracles for each one. None of this would be possible if leader assignment happened at the start of each slot, the way most chains do it.

This is the network as it actually runs from a programmer's perspective. The deterministic schedule, the 4-slot windows, the skipped slots, and the leader-controlled ordering are the mechanics underneath every priority fee you set and every "transaction confirmed" notification your users see.