Clones and snapshots
Keep a state you worked to reach, and try things against it without losing it.
Which one to use
| What it does | Use it for | |
|---|---|---|
| Snapshot | Saves this testnet's state under a name. Restoring puts the testnet back exactly as it was | Undo: before an upgrade, a liquidation, a migration you might want to run again |
| Clone | Copies this testnet into a new one with its own RPC URL. The two are independent from then on | Working in parallel: a copy per test worker, or a risky experiment beside a state others rely on |
evm_snapshot | The Anvil and Hardhat call. Kept in memory and used up by one revert | Tests that already use it — it works as they expect |
Snapshots
On the testnet's Settings page, name a snapshot and save it. Everything is kept — balances, storage, deployed contracts, mined blocks, receipts and traces — until you delete it. A testnet keeps up to 20.
- Restoring replaces everything since the snapshot, and anything connected sees it at once — the block number goes back too.
- A snapshot is not used up: restore it as many times as you like.
- The RPC URL, chain id, alerts and shared links are not part of a snapshot and do not change.
Clones
Clone, on the same page, makes a new testnet in the same project. It starts with the same state, blocks and traces, and the same chain id and fork point. It gets its own RPC URL; alerts and shared links stay with the original.
A clone counts towards your testnets. It shares the chain's cache with the original, so it costs nothing until it reads state neither has read before.
From an agent
The same through MCP:
ask your agent
Snapshot my "base-dev" testnet as "before upgrade", run the upgrade script,
and if the invariant check fails, restore the snapshot.The tools are clone_testnet, snapshot_testnet, list_snapshots, restore_snapshot and delete_snapshot.