Validators control what goes into a block, including its timestamp. A contract that uses block.timestamp for randomness, lotteries, or tight time-lock logic can be exploited by the validator who proposes the block — they just shift the timestamp until they win.
Every block on Ethereum has a timestamp field set by the validator (or miner, on PoW chains) who proposes it. The network enforces only loose constraints: the timestamp must be greater than the parent block's timestamp, and not too far in the future. Within those bounds, the validator has discretion.
That flexibility is enough to exploit contracts that use block.timestamp for randomness (e.g. block.timestamp % 2 == 0 determines winner) or for conditions where a shift of a few seconds changes the outcome.
Dozens of early lottery contracts on Ethereum used block.timestamp % N as the winning condition. Miners on PoW Ethereum routinely held blocks until the timestamp produced a favorable result, then submitted it. Losses ranged from a few ETH to hundreds.
Multiple "provably fair" dice and gambling games were shown to be exploitable by the miner who proposed the settling block. The miner simply discarded any block where they lost and re-mined until the timestamp gave them a win.
Timestamp manipulation refers to exploiting the fact that `block.timestamp` in Solidity can be slightly influenced by the validator/miner who produces the block. Ethereum validators can set block.timestamp anywhere within ~15 seconds of the actual time, which can be enough to influence time-dependent contract logic.
On Ethereum post-Merge, validators can set block.timestamp within about 12 seconds (one slot) of the actual time. On older PoW chains, miners had ~15 seconds of flexibility. This small window is enough to influence lottery outcomes, lock expiry checks, or randomness seeds that use block.timestamp — but not enough to manipulate 30-minute TWAP windows or daily time locks.
block.timestamp is safe for time granularity above ~15 minutes. Daily/weekly vesting schedules, lock periods measured in hours, and deadline checks for off-chain signed orders are all fine. It's unsafe for anything requiring precision under 15 seconds — especially as a source of randomness, lottery timing, or as the sole factor in an economic decision.
Several lottery and gambling contracts have been exploited via timestamp manipulation — attackers front-ran draws by controlling block.timestamp. GovernMental (2016) and multiple on-chain lottery contracts lost funds. Any contract using `block.timestamp % N` for randomness is exploitable.
For randomness, use Chainlink VRF (Verifiable Random Function) — it provides provably fair, manipulation-resistant random numbers. For time-based conditions requiring precision, consider off-chain oracles. SmartContractAuditor.ai flags contracts using block.timestamp as a randomness source and identifies timing precision risks in vesting and lock logic.