Does Hardhat Network's evm_revert restore block metadata when automine is disabled?

Direct answer

Yes. Under standard Hardhat Network behavior, evm_revert restores the blockchain state—including block header metadata such as block.number, block.timestamp, block.difficulty, and block.coinbase—to the values captured at the evm_snapshot point. This applies whether automine is enabled or disabled.

What happens when automine is disabled

With automine off, the network does not create a new block for each transaction. The chain head stays at the last mined block until you explicitly call evm_mine (or an equivalent mining method). Because the head is frozen, a snapshot taken while transactions are pending records that frozen header state. When you later call evm_revert, the provider rolls the chain back to that exact header configuration and also restores or removes pending mempool transactions to match the snapshot moment.

The key distinction is that block metadata does not continue advancing independently of the EVM state during a revert. If you mine blocks after taking a snapshot and then revert, the block number and timestamp return to the snapshot values rather than remaining at the higher, post-mine height.

Confirmed behavior vs. version-dependent details

The rollback of header fields and mempool contents is the documented and expected behavior of Hardhat Network’s snapshot mechanism. However, the exact set of restored fields and the interaction with custom provider wrappers can vary by Hardhat version. If your tests rely on precise header values after a revert, pin the Hardhat version and avoid provider-level plugins that mutate block height outside the core network.

How to verify in your project

You can confirm the behavior with these JSON-RPC calls against a local Hardhat node:

// 1. Disable automine in hardhat.config.js
//    networks: { hardhat: { mining: { auto: false } } }

// 2. Take a snapshot and record the current block number
await provider.send('evm_snapshot');
const before = await provider.send('eth_blockNumber');

// 3. Queue a transaction (it stays pending) and mine a block
await provider.send('eth_sendTransaction', [tx]);
await provider.send('evm_mine');
const afterMine = await provider.send('eth_blockNumber');

// 4. Revert and compare
await provider.send('evm_revert', [snapshotId]);
const afterRevert = await provider.send('eth_blockNumber');
// afterRevert should equal before, not afterMine

Also inspect txpool status (if exposed by your provider) before and after the revert to confirm pending transactions are restored or dropped according to the snapshot.

When to seek more detail

If you observe metadata that does not return to the snapshot values, the next diagnostic detail that changes the recommendation is the exact Hardhat version and whether any custom network provider or middleware is intercepting evm_revert. Core Hardhat Network should restore headers automatically; divergence usually points to an external layer.