Hardhat Network Forking: Deterministic Block Timestamp Constraint

Answer

Hardhat does not currently expose a configuration flag to fix the block.timestamp of a forked network. The fork inherits the timestamp from the latest block of the RPC endpoint, so running the fork at different times yields different values.

Confirmed facts

• Hardhat’s --fork option copies the latest block, including its block.timestamp, from the supplied RPC URL.
• No Hardhat configuration option (e.g., in hardhat.config.js) exists to override or fix that timestamp.
• The JSON‑RPC method evm_setTime (accessible via hardhat.provider.send) can set the blockchain clock for subsequent blocks.

Likely explanation

The missing flag is likely omitted because Hardhat treats the fork as a snapshot of a live chain; adding a timestamp override would diverge from that snapshot semantics. Future releases may consider such a flag, but no public roadmap or issue indicates an imminent implementation.

Recommended steps for deterministic timestamps

1. In your test file, import Hardhat’s network provider:

const { network } = require('hardhat');

2. Before each test (or in a beforeEach hook), set the desired timestamp:

beforeEach(async () => {
  // Example: set timestamp to 1 Jan 2023 00:00:00 UTC
  const targetTimestamp = 1672531200;
  await network.provider.send('evm_setTime', [targetTimestamp]);
  // Optionally mine a block to advance to the new timestamp
  await network.provider.send('evm_mine', []);
});

3. Run your tests as usual; all subsequent block.timestamp reads will reflect the fixed value.

What to verify

After applying the override, log await network.provider.send('eth_getBlockByNumber', ['latest', false]) and confirm the timestamp matches the value you set.