Volatile state during Hardhat Network node restart

Question

Local State Persistence
The Hardhat Network simulates an Ethereum environment for development and testing. A core behavior of the local node is that the blockchain state, including deployed contract addresses and modified account balances, is held in memory.
When the node process is terminated and restarted, the environment returns to its initial state. This creates a challenge when attempting to maintain a consistent set of deployed contracts across multiple development sessions without re-running the entire deployment pipeline.
Is there a documented configuration to persist the local blockchain state to disk automatically? If not, what is the recommended mechanism for restoring a specific state snapshot after a node restart?

Tasadduq Burney · Answer

State Persistence in Hardhat
The Hardhat Network does not have a native configuration to automatically persist the blockchain state to disk. Because the node operates entirely in-memory, all deployed contracts, account balances, and state changes are wiped when the process is terminated.

Likely Explanation of Behavior
Hardhat is designed as a development and testing tool rather than a persistent node. By maintaining state in RAM, it ensures high performance and allows developers to quickly reset the environment to a clean slate. While JSON-RPC methods like evm_snapshot and evm_revert exist, these are volatile and only function within the lifespan of a single active process; they cannot be used to restore state after a restart.

Recommended Restoration Mechanisms
Since automatic disk persistence is unavailable, the industry standard is to use deterministic deployment scripts to recreate the state upon restart.

Use a Deployment Plugin: Tools such as hardhat-deploy are recommended. These plugins track deployments by saving the contract addresses and ABIs to local JSON files.
  Idempotent Scripts: Write deployment scripts that check if a contract is already deployed or simply redeploy the entire suite as part of the node startup sequence.
  Consistent Account Funding: Since Hardhat provides a set of default accounts with 10,000 ETH, ensure your scripts use these consistent indices to maintain predictable sender addresses.

Verification Steps
To verify the volatility of the state and the effectiveness of a script-based approach, run the following sequence:

Start the node: npx hardhat node
  Deploy a contract and record the address.
  Restart the node (Ctrl+C and run npx hardhat node again).
  Attempt to call the previously recorded address; it will return a 404 or fail, confirming state loss.
  Run your deployment script to restore the environment.

Diagnostic Detail: Are you requiring the exact same contract addresses across restarts for external integration (e.g., a frontend config), or is any valid deployment sufficient?

Volatile state during Hardhat Network node restart

Local State Persistence

1 answer

State Persistence in Hardhat

Likely Explanation of Behavior

Recommended Restoration Mechanisms

Verification Steps

Your perspective belongs here.

0 question comments