Hardhat v2.12 persistSnapshots Flag Alters Snapshot Restoration Behavior

Answer first

No. Enabling a persistSnapshots flag does not guarantee identical contract storage and balances after evm_revert across a node restart, and there is no confirmed public plan to add transaction history or mempool state to Hardhat snapshots. On forked networks the safe practice is to treat snapshots as in-memory only, recreate them after every restart and fork reset, and pin the fork block.

Confirmed facts

• Hardhat Network’s documented snapshot APIs are evm_snapshot and evm_revert. They capture in-memory EVM state: account balances, contract storage, code and nonces.
• Pending mempool transactions and transaction history are not part of a snapshot. Revert cannot restore mempool-dependent behavior.
• I cannot confirm that a persistSnapshots configuration flag exists in Hardhat v2.12 or any established Hardhat release. The well-documented network config does not list such an option.
• On a forked network evm_revert restores local EVM state to the snapshot point. It does not refetch or rewind the remote forked chain. Divergence between local state and the upstream chain after the fork block is a known source of inconsistency.
• No confirmed public roadmap item establishes that Hardhat will add transaction history or mempool contents to snapshots. Any claim about upcoming releases is unverified.

Likely explanation for the premise

If a flag that persists only storage, code and balances to disk existed, it would not by itself guarantee post-revert equivalence after a restart. Snapshot IDs and the in-memory snapshot graph are lost on restart. Persisted storage alone cannot be reattached to a valid snapshot ID unless Hardhat explicitly reloads and reconciles the persisted data on startup, which is not documented behavior.

Persisting storage/code/balances without logs and pending transactions also leaves transaction-dependent state unrecoverable. Mempool-dependent tests will still diverge after revert.

Steps needed for this case

1. Verify the flag exists. Check the official Hardhat docs and the v2.12 changelog/release notes for a persistSnapshots option in hardhat.config.js network config, and inspect packages/hardhat-core source for the flag name.
2. Assume in-memory semantics. Take a fresh evm_snapshot after node startup and after any hardhat_reset / fork change. Do not rely on a snapshot taken before a restart.
3. Pin fork reproducibility. Set a fixed forking.blockNumber and avoid relying on live chain progression between snapshots.
4. Validate state manually. After revert, compare eth_getBalance and eth_getStorageAt for key accounts/contracts against the expected snapshot point.

One missing diagnostic detail that changes the recommendation: can you confirm the exact config key name and where it is set, and whether Hardhat actually loads persisted data on startup? Without that confirmation the flag should be treated as unconfirmed and not relied on for cross-restart correctness.