timestamp dependence

Timestamp dependence is relying on block.timestamp for randomness or fine-grained logic that the block producer can nudge to their advantage. The timestamp written into a block is chosen by whoever produces it, within protocol-allowed bounds, not read from a trusted global clock. Treating it as an unpredictable or perfectly precise value invites manipulation: a producer who stands to gain can shift the timestamp by a few seconds, and that small freedom is enough to swing any decision that turns on the exact moment.

The boundaries differ by era but the lesson is the same. Under proof-of-work, a miner could set the timestamp anywhere greater than the parent block and within a modest tolerance (commonly around fifteen seconds) of real time. Under proof-of-stake, slots are a fixed twelve seconds, which tightens things, but the proposer still has discretion within the rules and can sometimes choose whether to propose at all. So using block.timestamp modulo N to pick a lottery winner, or gating an action on a sub-minute deadline, hands the outcome to whoever builds the block.

The practical rule: block.timestamp is fine for coarse, day-scale logic where a few seconds are irrelevant, such as vesting schedules, multi-hour deadlines, or interest accrual. It must never be the source of randomness, nor decide anything a producer profits from nudging. For on-chain randomness, use a verifiable random function or a beacon like RANDAO rather than the clock; for fairness-critical timing, design so that a few seconds of producer freedom cannot be exploited.