xone evm statetest <fixture.json> runs one GeneralStateTests or EEST state_test fixture on the xOneRS executor and prints geth's result line. It arrived in PR #991, merged on 2026-11-15. It is a first version: legacy transactions on the Frontier to ConstantinopleFix forks only. The v0.1.0 release does not have it; build from main.

This post covers what the runner does, what it skips, and how its one committed fixture is checked. The replay gate that compares whole blocks is a different test; see the replay gate and the replay gate in numbers.

What does the statetest runner do?

For each test in the file, each post fork that the build supports and each post entry, the runner builds the transaction from the entry's indexes, signs it with the fixture's secretKey, runs it on the pre state, and compares the state root and the logs hash with the fixture's hash and logs (statetest.rs).

It uses the same executor path as xone evm t8n (evm.rs).

How do I run it?

Build xone from main, then pass one fixture file:

cargo build --locked --release -p xone
./target/release/xone evm statetest conformance/vectors/statetest/transfer.json

The only option is --state.chainid <n> (default 1). The source says one chain id is used for every fork: protected from EIP-158 on, unprotected before it (flags.rs, statetest subcommand).

What does the output look like?

The runner prints geth's format on one line: a JSON array of {"name", "pass", "fork", "stateRoot"} objects. It exits with 1 if any case fails or if no case ran (PR #991).

Which cases does it skip?

A skipped case goes to stderr with its reason. It is never counted as a pass. The source lists three reasons (statetest.rs):

REFERENCE TABLEScroll to explore all columns →
Skip reason When
unsupported fork a post fork outside Frontier to ConstantinopleFix, the range that t8n runs
expectException a post entry that expects the transaction to fail
not a legacy transaction an accessList or fee-market fields

The source calls these the documented XDC skip list of issue #26, and says the list grows with issue #230. Both issues are open.

How is the runner itself checked?

The repository commits one fixture, conformance/vectors/statetest/transfer.json. PR #991 says it is made from the recorded transfer t8n vector: the post root and the logs hash of the pinned geth-XDC. The fixture has post entries for two forks, ConstantinopleFix and Cancun; the second is outside the supported range, so the runner skips it.

The test statetest_passes_the_pinned_root_skips_unsupported_forks_and_fails_a_wrong_one in bin/xone/src/cmd/evm.rs checks three things: the fixture passes, the unsupported fork is skipped, and a wrong root fails.

What is not covered yet?

PR #991 leaves these for issues #26 and #230:

  • a run of a pinned EEST release with the documented XDC skip list (it needs the release files, and an Istanbul-and-later Ethereum-rules mode or --state.xdc),
  • typed and access-list transactions,
  • a block-test runner,
  • a nightly differential job.

Until then, the runner proves the fixture format and the executor path, not coverage of the Ethereum test suite.

How do other projects describe this?

REFERENCE TABLEScroll to explore all columns →
Project What its article states xOne
ethrex EF spec tests and Hive run in CI, as stated in ethrex completes its first external security audit, 2026-06-18 One state-test fixture runs in a unit test; an EEST release run is open (#26, #230)

XDC rules differ from Ethereum rules in places, so a raw Ethereum suite needs a skip list. The xOne replay gate compares whole recorded XDC blocks instead.

Frequently asked questions

Does the v0.1.0 release have xone evm statetest?

No. The runner was merged on 2026-11-15 in PR #991, after v0.1.0. Build xone from main to use it.

Which forks does the runner support?

Frontier to ConstantinopleFix, the same range as xone evm t8n. A post entry for a later fork is skipped with the reason unsupported fork.

Does a skipped case count as a pass?

No. Each skip goes to stderr with its reason and is never counted as a pass. The command exits with 1 if a case fails or if no case ran.

Can I run the full Ethereum test suite with it today?

Not yet. Typed transactions, later forks and a pinned EEST release run are open work in issues #26 and #230.

Sources