Severity depends on reachable impact and deployment context. Listed tools are review aids; their applicability depends on language, version and configuration.
Using block.timestamp is not automatically a vulnerability. It is the normal EVM clock for deadlines, vesting, auctions, and governance delays. Risk appears when correctness depends on precision or control that the target chain does not guarantee, or when a timestamp is used as secret entropy.
The common claim that an Ethereum block proposer can choose any timestamp within a fixed 13- or 15-second margin is outdated and was never a universal smart-contract rule. On post-Merge Ethereum, the consensus specification requires an execution payload's timestamp to equal the time computed for its proof-of-stake slot. A proposer can choose whether to publish and can order or censor transactions, but cannot freely select another valid timestamp for that slot.
Solidity documents that a block's timestamp must be greater than its parent's. That does not guarantee regular intervals or prompt transaction inclusion. L2s and other EVM chains may derive timestamps from sequencers or parent-chain rules, with different drift, batching, and outage behavior. A contract intended for several networks must review each one.
Timestamp dependence matters when a one-block difference changes who receives value, when very short windows can be missed through congestion or sequencer downtime, or when code assumes regular block production. Exact equality such as block.timestamp == deadline is usually a liveness bug because no transaction is guaranteed inclusion at that second.
Timestamps are also unsuitable as randomness. Callers can calculate public block data during execution, while proposers or sequencers may influence inclusion and ordering. That case belongs with weak randomness, even if block.timestamp is the visible source.
Map every timestamp to its consequence. Separate coarse eligibility checks from price calculation, winner selection, liquidation, and same-block ordering. Review <, <=, >, and >= boundaries in pairs and define whether the endpoint is inclusive.
Tests should cover one second before, exactly at, and one second after each boundary; skipped slots; long gaps; two actions in the same block; delayed automation; and the target L2's maximum documented timestamp behavior. For accrual formulas, fuzz elapsed time across large gaps and confirm caps, rounding, and stale-state handling.
Firepan can inspect timestamp-dependent branches and downstream state changes in a submitted repository and commit. It does not predict inclusion, model every sequencer policy, or continuously monitor deployed contracts.
block.number; block production is not a stable wall-clock rate and L2 block numbers can have chain-specific meaning.No single safe window fits every chain or application. The right tolerance follows from the chain's rules, automation model, and value at risk.
Firepan
Run a free scan — results in minutes, no credit card required.
Run Free Scan →Understand the ERC-20 allowance overwrite race, its transaction-ordering conditions, and safer approval and spending designs.
Understand how Ether can reach a contract without its receive logic and how to review exact-balance assumptions safely.
Learn how adversarial gas consumption can block progress, waste sponsored gas, or break calls, plus practical review, testing, and mitigation guidance.