A xone --dev chain started with --dev.seed can stop and start again on the same datadir. The same seed gives the same validator, the chain loads its head from the store, and a copy of a stopped datadir works as a saved fixture. A start with other settings is refused before anything is written. This came in PR #995 (merged 2026-11-15, closes #670); the v0.1.0 release has no --dev at all.

For what --dev is and how to send a first transaction, see the one-validator dev chain.

Why does a dev chain need a seed to resume?

Without --dev.seed the validator key is random and lives in memory only. After a stop no process can sign for that validator again, so the chain cannot continue. With a seed, the same seed gives the same validator address and the same genesis on every run (flags.md, --dev.seed row). The flag text adds: "a test key: anyone with the seed has it".

How do I resume a chain?

Start the first run with a seed and a datadir, stop it, then start it again with the same options:

xone --dev --dev.seed my-fixture --datadir ./devchain
# stop it, then:
xone --dev --dev.seed my-fixture --datadir ./devchain

The second start loads the head from the store, and the safety record in the datadir continues (PR #995).

How do I save and reload a fixture?

Copy a stopped datadir. The copy is the fixture. To reload it, start --dev on the copy with the seed and the other settings it was made with:

cp -a ./devchain ./fixture-a
xone --dev --dev.seed my-fixture --datadir ./fixture-a

The settings that must match are the seed, --dev.period, --dev.accounts, --dev.balance and --dev.alloc (flags.md).

What gets refused?

The node compares the genesis and the fork table it would build with the files stored in the datadir. If any differ, the start stops before any change. The errors are (dev.rs):

REFERENCE TABLEScroll to explore all columns →
Start Result
--dev with no seed on a datadir that is not empty --dev needs an empty datadir: <dir> is not empty (set --dev.seed to resume a dev chain made with that seed; without a seed its validator key lived in memory only)
--dev with another seed or other fixture settings --dev: <dir> holds another dev fixture (<file> differs); use the --dev.seed, --dev.period, --dev.accounts, --dev.balance and --dev.alloc it was made with, or an empty datadir
--dev with an option it makes itself --dev makes its own chain and key; it does not take --<flag>
--dev.seed or --dev.alloc without --dev refused at configuration check

PR #995 records that the test leaves the datadir byte-identical after each refused start.

How is the resume tested?

bin/xone/tests/dev_resume.rs runs the real binary: it mines blocks, kills the process with kill -9, and restarts on the same datadir. The head, the block hash and the funded balance are equal after the restart. Another seed and an unseeded start are refused (PR #995).

What is not covered?

PR #995 lists two limits:

  • A resume after the V2 switch (block 2700 on the dev chain) was not run.
  • A contract-state fixture goes through the same tables, but the test checks a balance, not a deployed contract.

The collected competitor articles state nothing about resuming a dev chain, so this post has no comparison table.

Frequently asked questions

Can I restart a --dev chain that I started without a seed?

No. Its validator key lived in memory only. A start on that datadir is refused with the "needs an empty datadir" error. Start a new chain, this time with --dev.seed.

Is a copied datadir a safe way to share a fixture?

It is the documented way to save a fixture. The seed is a test key: anyone with the seed can sign for that validator. Do not use a dev seed for anything of value.

What if I change --dev.period on a saved fixture?

The start is refused: the stored genesis and fork table differ, and the error names the differing file. Nothing is written.

Does --dev work with the v0.1.0 release?

No. --dev came after v0.1.0, and resume came in PR #995. Build xone from main.

Sources