0x42-TIMESTAMP

Opcode Summary

Property	Value
Opcode	0x42
Mnemonic	TIMESTAMP
Gas	2
Stack Input	(none)
Stack Output	`block.timestamp` (uint256, seconds since Unix epoch)
Behavior	Pushes the timestamp of the current block as a Unix epoch value (seconds since 1970-01-01T00:00:00Z). On Ethereum PoS, timestamps are deterministic: `genesis_time + slot_number × 12`. On pre-Merge PoW and many L2s, the block producer has discretion over the timestamp within protocol-enforced bounds. Solidity exposes this as `block.timestamp` (the `now` alias was removed in Solidity 0.7.0).

Threat Surface

TIMESTAMP is the EVM’s sole time primitive and one of its most deceptively dangerous opcodes. Every smart contract that asks “what time is it?” ultimately executes TIMESTAMP, yet the answer is not an objective fact — it is a value chosen (or constrained) by the block producer. This single trust assumption underpins an enormous attack surface.

The threat surface centers on three properties:

Block producers influence the timestamp. On pre-Merge PoW Ethereum, miners could set block.timestamp to any value within roughly ±15 seconds of real time (constrained by the protocol rule that a child’s timestamp must exceed its parent’s, and by clients rejecting blocks with timestamps too far in the future). On PoS Ethereum, timestamps are fixed to genesis_time + slot × 12, eliminating direct manipulation — but on L2s (Arbitrum, Optimism, etc.), sequencers retain varying degrees of timestamp discretion, reintroducing the threat.
TIMESTAMP is used for security-critical decisions it was never designed to support. Contracts use block.timestamp for time-locks, vesting schedules, auction deadlines, oracle staleness checks, randomness seeds, and governance voting windows. Each use case assumes the timestamp is accurate and tamper-proof. Neither assumption holds universally. Even on PoS where the value is deterministic, it is predictable, which undermines randomness use cases. And on L2s, sequencer-controlled timestamps can deviate by minutes to hours from real time.
Off-by-one and boundary semantics cause logic errors. The difference between < and <= in a time comparison, or between “the timestamp of the block containing my transaction” and “the time I submitted my transaction,” creates subtle vulnerabilities. Contracts that use block.timestamp == deadline are fragile because the exact second may never appear as a block timestamp. Contracts using >= where > was intended create one-block windows for exploitation.

Smart Contract Threats

T1: Timestamp Manipulation by Block Producers — Time-Dependent Logic Bypass (Critical)

Block producers can influence block.timestamp to trigger or bypass time-dependent contract logic. The degree of influence depends on the consensus layer:

PoW (pre-Merge Ethereum, ETC, L1 forks). Miners could set timestamps within ~15 seconds of real time. A miner who is also a contract participant can advance or retard the timestamp to trigger a time-lock release, end an auction early, or claim a time-gated reward. The protocol only enforced block.timestamp > parent.timestamp and that the timestamp is not more than ~15 seconds in the future relative to a node’s local clock.
PoS Ethereum (post-Merge). Timestamps are deterministic (genesis_time + slot × 12), so direct manipulation is no longer possible. However, a validator-proposer can choose not to propose (missing a slot), which shifts subsequent transactions to a later slot with a later timestamp. This is a weaker form of manipulation but still relevant for MEV strategies.
L2 sequencers. On Arbitrum, the sequencer can set block.timestamp up to 24 hours in the past or 1 hour in the future relative to the L1 origin timestamp. On Optimism, timestamps are L1-anchored but lag real time by the confirmation depth. These windows reintroduce PoW-era manipulation risks on L2.

Why it matters: Any contract deployed on a chain where the block producer has timestamp discretion is vulnerable. Time-locks protecting multi-million-dollar vesting schedules, governance timelocks, and withdrawal delays all depend on block.timestamp being honest.

T2: Using TIMESTAMP as a Randomness Source (Critical)

Using block.timestamp (alone or combined with other block-level values) as a source of randomness is fundamentally broken:

On PoW: Miners know the timestamp before including transactions and can choose a timestamp that produces a favorable “random” outcome. If the contract computes uint(keccak256(abi.encodePacked(block.timestamp))) % N, the miner can try multiple timestamps within the valid range and select one that wins.
On PoS: Timestamps are deterministic and publicly known 12 seconds in advance (one slot). Any “randomness” derived from block.timestamp is fully predictable to all participants before the block is produced.
Combined with other predictable values: Patterns like keccak256(abi.encodePacked(block.timestamp, block.difficulty, msg.sender)) are no more random — all inputs are known or predictable. Post-Merge, block.difficulty was replaced by PREVRANDAO which provides better randomness, but mixing it with a predictable timestamp does not improve the entropy.

Why it matters: Lottery contracts, NFT mint randomness, and game mechanics using timestamp-derived randomness are systematically exploitable. Fomo3D-style games demonstrated this at scale, with attackers pre-calculating outcomes and reverting unfavorable transactions.

T3: Timestamp Dependence in DeFi — Auction Sniping and Oracle Staleness (High)

DeFi protocols use block.timestamp for multiple time-sensitive operations, each with distinct attack vectors:

Auction end-time manipulation. If an auction ends when block.timestamp >= endTime, a miner/validator can include their own winning bid in the block that crosses the deadline while excluding competing bids. On L2s with sequencer discretion, the sequencer can advance the timestamp to end auctions prematurely.
Oracle staleness checks. Protocols check block.timestamp - oracle.lastUpdateTime < maxStaleness to reject stale prices. A sequencer that can backdate block.timestamp can make stale oracle data appear fresh, enabling trades at incorrect prices. Conversely, a timestamp far ahead of the oracle update can force the staleness check to fail, blocking liquidations.
Interest accrual and yield calculations. Lending protocols compute interest as rate × (block.timestamp - lastAccrual). Timestamp skew on L2s directly translates to incorrect interest amounts — over-accrual benefits lenders, under-accrual benefits borrowers.
TWAP oracle manipulation. Time-Weighted Average Price calculations using block.timestamp for the time component can be skewed if timestamps are non-uniform. On PoS Ethereum, the fixed 12-second interval makes TWAPs more predictable and potentially gameable by MEV actors who know the exact timestamp windows.

Why it matters: DeFi protocols handling billions in TVL use block.timestamp for deadline enforcement, price freshness, and interest calculation. Even small timestamp deviations can create profitable arbitrage or cause liquidation failures.

T4: Off-by-One and Boundary Errors in Time Comparisons (Medium)

The distinction between strict and non-strict inequality in timestamp comparisons creates a class of subtle bugs:

< vs <= in time-locks. require(block.timestamp >= unlockTime) allows execution in the same second as the unlock. require(block.timestamp > unlockTime) requires at least one second past the unlock. On PoS with 12-second slots, the difference is up to 12 seconds, which may or may not match the developer’s intent.
Equality checks are fragile. require(block.timestamp == deadline) almost never triggers because block.timestamp only takes values at 12-second intervals (PoS) or at miner-chosen intervals (PoW). A deadline at timestamp T may never appear as a block timestamp.
“Same block” assumptions. On PoS Ethereum, every block in an epoch has timestamp genesis_time + slot × 12. There is exactly one timestamp per slot. But on L2s like Arbitrum, multiple transactions can share the same block.timestamp value within a single batch, creating unexpected “simultaneous” execution.
Timezone and epoch confusion. Developers sometimes confuse UTC timestamps with local time, or use day-boundary calculations (timestamp / 86400) that don’t align with the expected timezone. The EVM provides raw Unix seconds with no timezone support.

Why it matters: Off-by-one errors in time comparisons have caused governance proposals to be executable one block early, vesting schedules to release tokens prematurely, and auction windows to close unexpectedly.

T5: Block Timestamp Ordering Assumptions (Medium)

Developers often assume properties about timestamp ordering that do not hold universally:

Non-monotonicity across chains. While Ethereum L1 guarantees block[N].timestamp > block[N-1].timestamp (PoW) or block[N].timestamp = block[N-1].timestamp + 12 (PoS with no missed slots), L2s and sidechains may not enforce strict monotonicity. Arbitrum’s batching can produce blocks with identical timestamps.
Missed slots on PoS. When a validator misses a slot, the next block’s timestamp jumps by 24 seconds (or more) instead of the usual 12. Contracts that compute time deltas as (block.timestamp - lastTimestamp) / 12 to count “blocks elapsed” will overcount.
Cross-chain timestamp divergence. Bridges and cross-chain protocols that compare timestamps from different chains face fundamental inconsistency — L1 and L2 timestamps can differ by minutes, and two L2s may have entirely different timestamp semantics.

Why it matters: Contracts ported from L1 to L2 (or deployed across multiple chains) inherit timestamp assumptions that may not hold. Vesting contracts, streaming payment protocols, and rate limiters are particularly sensitive to timestamp ordering anomalies.

Protocol-Level Threats

P1: PoS Deterministic Timestamps — Reduced but Not Eliminated Risk (Low)

Ethereum’s Merge (September 2022) replaced miner-controlled timestamps with deterministic slot-based timestamps: genesis_time + slot_number × 12. Validators cannot modify the timestamp of their proposed block. This eliminates the ±15 second manipulation window that existed under PoW.

However, validators retain two indirect levers: (1) they can choose not to propose a block (missing a slot), which shifts transactions to a later timestamp, and (2) they choose which transactions to include in their block, enabling MEV strategies that exploit the known-in-advance timestamp. Neither is a direct timestamp manipulation, but both can affect timestamp-dependent contract logic.

P2: L2 Timestamp Semantics Create a Fragmented Trust Model (High)

Each L2 defines its own timestamp rules, creating a fragmented security landscape:

Arbitrum: The sequencer sets block.timestamp with a tolerance of up to 24 hours behind or 1 hour ahead of the L1 block’s timestamp. This enormous window reintroduces manipulation risks that PoS Ethereum eliminated.
Optimism: Timestamps are derived from L1 origins, providing stronger guarantees but introducing a lag (approximately equal to the L1 confirmation depth). The sequencer cannot backdate timestamps below the L1 origin timestamp.
zkSync, StarkNet, and others: Each has unique timestamp semantics, often set by the sequencer with varying constraints.

Contracts deployed across multiple L2s face the worst-case timestamp deviation of any chain they operate on. A time-lock that is secure on L1 (deterministic 12-second slots) may be bypassable on an L2 with sequencer-controlled timestamps.

P3: SUUM Attacks on PoW Chains (Medium)

The Staircase-Unrestricted Uncle Maker (SUUM) attack, documented in 2025 research, demonstrates that mining pools on PoW chains (Ethereum Classic, Ethereum PoW forks) actively manipulate timestamps to: (1) create uncle blocks that earn rewards, (2) suppress difficulty increases, and (3) destabilize honest miners’ reward share. Empirical analysis identified four major mining pools conducting SUUM attacks. While this does not affect PoS Ethereum, it is relevant for contracts deployed on PoW-based chains and for understanding the historical threat model.

P4: MEV and Timestamp Predictability (Medium)

On PoS Ethereum, the block timestamp for the next slot is publicly known 12 seconds in advance. MEV searchers and block builders can pre-compute exactly how timestamp-dependent contract logic will behave in the upcoming block. This enables:

Targeting liquidations that become eligible at a specific timestamp
Front-running oracle updates whose staleness expires at a known second
Sniping auctions at the exact block where block.timestamp >= endTime

The predictability transforms timestamp-dependent logic from “approximately known” (PoW) to “exactly known” (PoS), which paradoxically increases certain MEV attack surfaces despite eliminating manipulation.

Edge Cases

Edge Case	Behavior	Security Implication
Same timestamp as parent block	PoW: Protocol requires `child.timestamp > parent.timestamp`, so impossible. PoS: Impossible; each slot is exactly 12 seconds apart. L2: Can occur on Arbitrum where multiple L2 blocks share a timestamp	Contracts using `block.timestamp - previousTimestamp` for rate calculations may divide by zero or compute zero elapsed time
Missed slot on PoS	Timestamp jumps by 24+ seconds instead of 12	Time-delta calculations assuming 12-second intervals overcount elapsed “blocks”; interest accrual spikes for one period
Timestamp far in the future	PoW: Clients reject blocks >15 seconds ahead of local clock. PoS: Impossible (deterministic). L2: Arbitrum allows up to 1 hour ahead	Contracts with `require(block.timestamp <= deadline)` may accept transactions that should be rejected if the timestamp is inflated
`block.timestamp == 0`	Only possible for the genesis block (Unix epoch 0 = Jan 1, 1970). In practice, Ethereum’s genesis timestamp is 1438269973 (July 30, 2015)	Contracts using `timestamp == 0` as a sentinel for “not yet initialized” are safe on Ethereum but the assumption is chain-specific
TIMESTAMP in DELEGATECALL	Returns the same block timestamp as the calling context (TIMESTAMP reads from the block header, not the call frame)	No security implication beyond the general TIMESTAMP threat; DELEGATECALL does not affect timestamp semantics
TIMESTAMP in STATICCALL	Identical behavior; TIMESTAMP is a pure read from the block header	Safe to use in view functions, though the value is still only as trustworthy as the block producer
TIMESTAMP after SELFDESTRUCT (same tx)	TIMESTAMP continues to return the current block’s timestamp; SELFDESTRUCT does not affect block-level data	No special behavior
Very large timestamp (year 2106+)	`block.timestamp` is a uint256, so no overflow. However, uint32 representations overflow at 2^32 - 1 = Feb 7, 2106	Contracts casting `block.timestamp` to uint32 or uint40 for storage packing may overflow in the distant future; Solidity’s `SafeCast` does not prevent this unless explicitly used
Identical timestamps across L2 batches	On Arbitrum, an entire batch of L2 blocks can share the same `block.timestamp`	Protocols that assume unique timestamps per block (e.g., using timestamp as a nonce or ordering key) will malfunction

Real-World Exploits

Exploit 1: GovernMental Ponzi Scheme — Timestamp-Gated Jackpot Theft (2016)

Root cause: Critical contract logic — the jackpot payout condition — depended entirely on block.timestamp, which miners could manipulate within the PoW tolerance window.

Details: GovernMental was a deliberate Ponzi scheme deployed on Ethereum at address 0xF45717552f12Ef7cb65e95476F217Ea008167Ae3. The contract’s rules stated that if no new deposit arrived within 12 hours, the last depositor would receive the entire jackpot. The 12-hour timeout was checked using block.timestamp.

Under PoW rules, a miner who was also the last depositor could manipulate their block’s timestamp forward (within the ~15 second tolerance) to trigger the timeout condition slightly earlier. More critically, a miner could strategically exclude other participants’ deposit transactions from their block while including a timestamp that advanced the clock toward the deadline. Over multiple blocks, this combination of transaction censorship and timestamp nudging could prematurely trigger the jackpot payout.

TIMESTAMP’s role: The entire payout trigger was block.timestamp - lastDepositTime >= 12 hours. The miner’s ability to set block.timestamp within the protocol tolerance, combined with transaction ordering control, made the outcome manipulable.

Impact: The contract collected over 1,100 ETH. The jackpot mechanism was demonstrated to be gameable by miners, serving as one of the earliest and most cited examples of timestamp dependence vulnerabilities.

References:

Exploit 2: Fomo3D — Timestamp-Derived Randomness Exploitation ($3M+ Airdrop Drain, 2018)

Root cause: The Fomo3D game used block.timestamp as a component of its pseudo-random number generation for airdrop prizes, allowing attackers to predict and selectively win airdrops.

Details: Fomo3D was a lottery-style game where players bought “keys” and the last buyer before a countdown timer expired won the pot. The game also featured an airdrop mechanism that awarded bonus ETH to random buyers. The airdrop randomness was computed using a combination of block.timestamp, block.difficulty, the sender’s address, and a seed counter:

uint256 seed = uint256(keccak256(abi.encodePacked(
    (block.timestamp).add(block.difficulty).add(
        uint256(keccak256(abi.encodePacked(block.coinbase)))
    ).add(airdropTracker_)
)));

Attackers deployed contracts that replicated this randomness calculation. Before committing a key purchase, the attacker’s contract computed the airdrop outcome locally. If the outcome was not a win, the transaction reverted (costing only gas). If it was a win, the transaction proceeded. This gave the attacker a near-100% win rate on airdrops.

TIMESTAMP’s role: block.timestamp was one of the “entropy” sources, but it was known to all participants within the same block. The attacker’s contract executed in the same block and thus had the identical block.timestamp value, making the randomness fully deterministic from the attacker’s perspective.

Impact: Attackers drained significant ETH from the airdrop pool. PeckShield documented systematic exploitation using iterative contract creation to harvest airdrop prizes. The game’s later rounds saw dramatically reduced participation (pools declining from thousands of ETH to ~100 ETH).

References:

Exploit 3: F2Pool Uncle Maker Attack — Systematic Timestamp Manipulation for Mining Rewards (2022)

Root cause: F2Pool, the second-largest Ethereum mining pool (pre-Merge), systematically manipulated block timestamps to orphan competing blocks (“uncle” them) and increase its own reward share.

Details: Researchers discovered that F2Pool was backdating block timestamps to make its blocks appear earlier than they actually were, exploiting Ethereum’s GHOST fork-choice rule. When two blocks competed for the same slot, the one with the earlier timestamp had an advantage. By setting timestamps earlier (but still later than the parent, satisfying the protocol minimum), F2Pool’s blocks would be preferred over competitors’ blocks, turning the competitors’ blocks into uncles.

The uncle blocks still earned partial rewards (uncle reward = 7/8 of block reward), but F2Pool captured the full block reward plus uncle inclusion rewards. Over hundreds of blocks, this amounted to significant stolen value from other mining pools.

This technique was later generalized as the SUUM (Staircase-Unrestricted Uncle Maker) attack, with 2025 research documenting four major mining pools actively exploiting it on Ethereum Classic and Ethereum PoW forks.

TIMESTAMP’s role: The entire attack was predicated on the miner’s ability to choose block.timestamp. The protocol’s permissive timestamp validation (only requiring child.timestamp > parent.timestamp and a loose future-time bound) gave miners enough latitude to game the fork-choice rule.

Impact: Estimated millions of dollars in stolen mining revenue across the Ethereum PoW era. The attack demonstrates that timestamp manipulation is not just a smart contract concern but a consensus-level economic attack vector.

References:

Exploit 4: Vyper Vested Claims — Timestamp-Based Vesting Bypass (2025 Audit Finding)

Root cause: A vesting contract built with Vyper relied on block.timestamp to determine claimable token amounts, and the vesting curve calculation was vulnerable to timestamp manipulation on chains where the block producer has discretion.

Details: A 2025 Cyfrin CodeHawks audit of a Vyper-based vesting contract identified that the claimable amount was computed as a linear function of block.timestamp - vestingStart. On L1 PoS Ethereum, this is safe because timestamps are deterministic. However, on Arbitrum (where the contract was also deployed), the sequencer’s ability to set timestamps up to 24 hours behind actual time meant that vesting calculations could produce distorted results — either accelerating or delaying token releases depending on the timestamp skew direction.

The audit specifically flagged that block.timestamp on Arbitrum “can be off by as much as 24 hours, which can result in a distorted amount of tokens that the recipient can withdraw.”

TIMESTAMP’s role: The vesting formula’s direct dependence on block.timestamp made it sensitive to any timestamp deviation. The contract had no mechanism to validate or bound the timestamp it received.

Impact: Classified as a high-severity finding in the audit. The vulnerability could cause premature token release (benefiting vestees) or delayed release (harming vestees), depending on the sequencer’s timestamp behavior.

References:

Attack Scenarios

Scenario A: Miner Manipulates Timestamp to Win Lottery

// Vulnerable: timestamp-based "randomness" for lottery
contract TimestampLottery {
    uint256 public pot;
    uint256 public constant TICKET_PRICE = 0.1 ether;
 
    function buyTicket() external payable {
        require(msg.value == TICKET_PRICE);
        pot += msg.value;
 
        // "Random" winner check using block.timestamp
        if (block.timestamp % 7 == 0) {
            // VULNERABLE: miner can choose a timestamp where this is true
            payable(msg.sender).transfer(pot);
            pot = 0;
        }
    }
}
 
// On PoW: Miner includes their buyTicket() tx only in blocks where
// they set block.timestamp to a multiple of 7.
// On PoS: block.timestamp is predictable 12 seconds ahead. Attacker
// submits tx only in slots where genesis_time + slot*12 is divisible by 7.
// On L2: Sequencer directly controls the timestamp.

Scenario B: Auction Sniping via Timestamp Manipulation

contract VulnerableAuction {
    address public highestBidder;
    uint256 public highestBid;
    uint256 public auctionEndTime;
 
    constructor(uint256 _duration) {
        auctionEndTime = block.timestamp + _duration;
    }
 
    function bid() external payable {
        // VULNERABLE: miner can advance timestamp past auctionEndTime
        // while including their own bid in the same block
        require(block.timestamp < auctionEndTime, "auction ended");
        require(msg.value > highestBid, "bid too low");
 
        if (highestBidder != address(0)) {
            payable(highestBidder).transfer(highestBid);
        }
        highestBidder = msg.sender;
        highestBid = msg.value;
    }
 
    function endAuction() external {
        require(block.timestamp >= auctionEndTime, "auction not ended");
        // Transfer item to highestBidder...
    }
}
 
// Attack (PoW or L2 with sequencer discretion):
// 1. Miner is the highest bidder
// 2. Miner receives competing bids in the mempool
// 3. Miner produces a block with timestamp >= auctionEndTime,
//    EXCLUDING the competing bids and INCLUDING their endAuction() call
// 4. Miner wins auction at their bid price, censoring higher bids

Scenario C: Time-Lock Bypass on L2

contract TimeLock {
    struct PendingAction {
        address target;
        bytes data;
        uint256 executeAfter;
    }
    mapping(uint256 => PendingAction) public actions;
    uint256 public constant DELAY = 2 days;
 
    function queue(address target, bytes calldata data) external returns (uint256 id) {
        id = uint256(keccak256(abi.encode(target, data, block.timestamp)));
        actions[id] = PendingAction(target, data, block.timestamp + DELAY);
    }
 
    function execute(uint256 id) external {
        PendingAction storage action = actions[id];
        // VULNERABLE on L2: sequencer can set block.timestamp 24h+ ahead
        require(block.timestamp >= action.executeAfter, "too early");
        (bool ok,) = action.target.call(action.data);
        require(ok);
        delete actions[id];
    }
}
 
// On Arbitrum: sequencer sets block.timestamp 24 hours ahead of real time.
// A 2-day timelock can be bypassed after only ~1 day of real time.
// On L1 PoS: safe (deterministic timestamps, no manipulation).

Scenario D: Oracle Staleness Check Bypass

interface IPriceFeed {
    function latestRoundData() external view returns (
        uint80 roundId, int256 price, uint256 startedAt,
        uint256 updatedAt, uint80 answeredInRound
    );
}
 
contract VulnerableLending {
    IPriceFeed public priceFeed;
    uint256 public constant MAX_STALENESS = 1 hours;
 
    function getPrice() public view returns (uint256) {
        (, int256 price,, uint256 updatedAt,) = priceFeed.latestRoundData();
        // VULNERABLE on L2: if sequencer backdates block.timestamp,
        // stale prices appear fresh
        require(
            block.timestamp - updatedAt < MAX_STALENESS,
            "stale price"
        );
        return uint256(price);
    }
 
    function liquidate(address user) external {
        uint256 price = getPrice();
        // Uses potentially stale price for liquidation decision...
    }
}
 
// On Arbitrum: sequencer sets block.timestamp 30 minutes behind real time.
// An oracle price updated 90 minutes ago has updatedAt = T-90min.
// block.timestamp = T-30min. Delta = 60 min < 1 hour. Check passes.
// In reality, the price is 90 minutes stale.

Mitigations

Threat	Mitigation	Implementation
T1: Timestamp manipulation by block producers	Add safety margins to time-dependent logic	Use `block.timestamp >= deadline + BUFFER` where BUFFER exceeds the maximum manipulation window (15s PoW, chain-specific for L2)
T1: L2 sequencer timestamp manipulation	Validate against L1 timestamp where possible	Optimism L2OutputOracle provides L1-anchored timestamps; cross-reference L1 timestamps via bridge for critical operations
T2: Timestamp as randomness	Use a dedicated randomness oracle	Chainlink VRF for verifiable randomness; EIP-4399 PREVRANDAO for weak randomness (not suitable for high-value outcomes)
T2: Predictable randomness on PoS	Use commit-reveal schemes	Two-phase commit: users commit hashed secrets, then reveal. Combined entropy is unpredictable if at least one participant is honest
T3: Auction sniping	Add a time buffer after the last bid	English auction pattern: extend deadline by N minutes whenever a new bid arrives near the end (like eBay)
T3: Oracle staleness bypass	Use Chainlink’s sequencer uptime feed on L2	`require(!sequencerDown && timeSinceUp > GRACE_PERIOD)` before trusting oracle data
T3: Interest accrual skew	Cap single-period accrual	`min(block.timestamp - lastAccrual, MAX_PERIOD)` prevents timestamp jumps from causing outsized interest
T4: Off-by-one in time comparisons	Use `>=` consistently for deadlines; avoid `==`	Never check `block.timestamp == X`; use range checks. Document whether boundary inclusion is intentional
T5: Cross-chain timestamp divergence	Use block.number for relative ordering	For cross-chain protocols, use L1 block numbers (available on L2s) rather than L2 timestamps for sequencing
General	Reduce timestamp dependence	Use `block.number` for relative time (with awareness of variable block times); use external time oracles for absolute time

Compiler/EIP-Based Protections

EIP-4399 / PREVRANDAO (Paris, 2022): Replaced DIFFICULTY with PREVRANDAO, providing beacon-chain-derived randomness. While not cryptographically secure for high-value outcomes, it is vastly superior to TIMESTAMP for randomness. Contracts needing randomness should use PREVRANDAO or Chainlink VRF, never TIMESTAMP.
EIP-1153 (Transient Storage, Dencun): Not directly related to TIMESTAMP, but enables gas-efficient cross-contract locks that can protect time-dependent state transitions from reentrancy-based timing attacks.
Solidity 0.7.0: Removed the now alias for block.timestamp, reducing confusion and making timestamp usage more explicit in code.
Chainlink Sequencer Uptime Feed: For L2 deployments, Chainlink provides a feed that reports whether the L2 sequencer is operational. Protocols should check this before trusting L2 timestamps for time-sensitive operations.

Severity Summary

Threat ID	Category	Severity	Likelihood	Real-World Precedent
T1	Smart Contract	Critical	Medium (L1 PoS: Low; L2/PoW: High)	GovernMental jackpot theft, F2Pool uncle maker
T2	Smart Contract	Critical	High	Fomo3D airdrop drain ($3M+), numerous lottery exploits
T3	Smart Contract	High	High	Auction sniping, Sablier/Vyper vesting miscalculation on Arbitrum
T4	Smart Contract	Medium	Medium	Governance proposals executable one block early; vesting off-by-one bugs
T5	Smart Contract	Medium	Medium	Cross-chain vesting divergence, L2 batch timestamp collisions
P1	Protocol	Low	Low	PoS deterministic timestamps largely resolved PoW-era manipulation
P2	Protocol	High	High	Arbitrum 24-hour sequencer window, Optimism timestamp lag
P3	Protocol	Medium	Medium	SUUM attacks on ETC/EthPoW (4 mining pools documented, 2025)
P4	Protocol	Medium	Medium	MEV strategies exploiting predictable PoS timestamps

Opcode	Relationship
BLOCKHASH (0x40)	Returns hash of a recent block (up to 256 blocks back). Sometimes combined with TIMESTAMP for pseudo-randomness — both are predictable and neither provides cryptographic entropy.
NUMBER (0x43)	Returns the current block number. Often used as an alternative to TIMESTAMP for relative time measurement (`block.number × avgBlockTime ≈ elapsed seconds`). More manipulation-resistant on PoS but less precise.
PREVRANDAO (0x44)	Returns the beacon chain’s RANDAO mix (post-Merge, replaced DIFFICULTY). Provides significantly better randomness than TIMESTAMP. Contracts should migrate from TIMESTAMP-based randomness to PREVRANDAO or Chainlink VRF.
COINBASE (0x41)	Returns the block producer’s address. Like TIMESTAMP, this is a block-level value controlled by the block producer. Sometimes combined with TIMESTAMP in flawed randomness schemes.

EVM Threat Models

Explorer

Opcode Summary

Threat Surface

Smart Contract Threats

T1: Timestamp Manipulation by Block Producers — Time-Dependent Logic Bypass (Critical)

T2: Using TIMESTAMP as a Randomness Source (Critical)

T3: Timestamp Dependence in DeFi — Auction Sniping and Oracle Staleness (High)

T4: Off-by-One and Boundary Errors in Time Comparisons (Medium)

T5: Block Timestamp Ordering Assumptions (Medium)

Protocol-Level Threats

P1: PoS Deterministic Timestamps — Reduced but Not Eliminated Risk (Low)

P2: L2 Timestamp Semantics Create a Fragmented Trust Model (High)

P3: SUUM Attacks on PoW Chains (Medium)

P4: MEV and Timestamp Predictability (Medium)

Edge Cases

Real-World Exploits

Exploit 1: GovernMental Ponzi Scheme — Timestamp-Gated Jackpot Theft (2016)

Exploit 2: Fomo3D — Timestamp-Derived Randomness Exploitation ($3M+ Airdrop Drain, 2018)

Exploit 3: F2Pool Uncle Maker Attack — Systematic Timestamp Manipulation for Mining Rewards (2022)

Exploit 4: Vyper Vested Claims — Timestamp-Based Vesting Bypass (2025 Audit Finding)

Attack Scenarios

Scenario A: Miner Manipulates Timestamp to Win Lottery

Scenario B: Auction Sniping via Timestamp Manipulation

Scenario C: Time-Lock Bypass on L2

Scenario D: Oracle Staleness Check Bypass

Mitigations

Compiler/EIP-Based Protections

Severity Summary

Graph View

Latest updates

Opcodes Reference & Notes

EVM Threat Models

Backlinks

EVM Threat Models

Explorer

0x42-TIMESTAMP

Opcode Summary

Threat Surface

Smart Contract Threats

T1: Timestamp Manipulation by Block Producers — Time-Dependent Logic Bypass (Critical)

T2: Using TIMESTAMP as a Randomness Source (Critical)

T3: Timestamp Dependence in DeFi — Auction Sniping and Oracle Staleness (High)

T4: Off-by-One and Boundary Errors in Time Comparisons (Medium)

T5: Block Timestamp Ordering Assumptions (Medium)

Protocol-Level Threats

P1: PoS Deterministic Timestamps — Reduced but Not Eliminated Risk (Low)

P2: L2 Timestamp Semantics Create a Fragmented Trust Model (High)

P3: SUUM Attacks on PoW Chains (Medium)

P4: MEV and Timestamp Predictability (Medium)

Edge Cases

Real-World Exploits

Exploit 1: GovernMental Ponzi Scheme — Timestamp-Gated Jackpot Theft (2016)

Exploit 2: Fomo3D — Timestamp-Derived Randomness Exploitation ($3M+ Airdrop Drain, 2018)

Exploit 3: F2Pool Uncle Maker Attack — Systematic Timestamp Manipulation for Mining Rewards (2022)

Exploit 4: Vyper Vested Claims — Timestamp-Based Vesting Bypass (2025 Audit Finding)

Attack Scenarios

Scenario A: Miner Manipulates Timestamp to Win Lottery

Scenario B: Auction Sniping via Timestamp Manipulation

Scenario C: Time-Lock Bypass on L2

Scenario D: Oracle Staleness Check Bypass

Mitigations

Compiler/EIP-Based Protections

Severity Summary

Related Opcodes

Graph View

Latest updates

Opcodes Reference & Notes

EVM Threat Models

Backlinks