How to Test Ethereum Glamsterdam Devnet Fixtures

Ethereum's Glamsterdam upgrade is now far enough along that developers can test its execution behavior against dedicated devnet fixtures instead of waiting for a public mainnet fork. The current test stream has reached Glamsterdam Devnet 8, while Ethereum developers are also preparing the Sepolia Glamsterdam fork for September 28, 2026. This guide shows how to work with the execution-spec test fixtures, run them locally, and interpret failures without confusing an unfinished devnet specification with a production Ethereum bug.

Understand what the Glamsterdam tests are testing

Glamsterdam is an upcoming Ethereum protocol upgrade whose execution-layer work changes how transactions and blocks behave. The execution layer is the part of an Ethereum node responsible for processing transactions, maintaining account and contract state, and producing the execution payload consumed by the consensus layer. Ethereum's official execution-spec testing project publishes machine-readable fixtures so different execution clients can check the same protocol rules against the same inputs.

The current Glamsterdam development stream has already gone through multiple devnets. The Devnet 8 test release, version 8.1.0, included updated tests for the Glamsterdam gas changes and additional coverage for Block Access Lists. That matters because a fixture from an earlier devnet can describe behavior that has since changed, so copying an old test bundle and treating it as the current specification can produce misleading failures.

Install the tools before downloading fixtures

The execution-spec testing framework uses Python tooling and provides separate commands for generating test vectors, consuming existing fixtures, and executing tests against a live JSON-RPC endpoint. JSON-RPC is the interface Ethereum clients expose for applications and test tools to send requests such as reading blocks, accounts, and transaction results. For a first Glamsterdam test, you normally want the consume path because the official project distributes already-generated fixtures for this purpose.

Install a current Python environment and the uv package manager, then verify both are available from your terminal. The exact Python version should follow the testing project's current requirements rather than an arbitrary system installation. Keeping this environment separate from your normal blockchain development setup makes it easier to reproduce a failed test later.

python --version
uv --version

If both commands return valid versions, the basic tooling is ready. Do not mix an old virtual environment with a newer checkout of the test framework because dependency changes can otherwise look like protocol failures.

Get the Glamsterdam test release you actually intend to run

Use a specific Glamsterdam fixture release instead of an unspecified development branch. The official tracker for tests-glamsterdam-devnet@v8.1.0 records the release as a follow-up test release for Glamsterdam Devnet 8, with its changes merged into the corresponding development branch. This gives your test run a fixed target that can be named in bug reports and compared with later fixture revisions.

The release process is deliberately separate from the normal mainnet test releases. Ethereum's execution-spec project has used versioned tags such as tests-glamsterdam-devnet@v7.2.1 and tests-glamsterdam-devnet@v8.1.0 so developers can distinguish experimental fork fixtures from the ordinary execution-test stream. Record the exact fixture version before running anything; otherwise, two developers can test the same client against different protocol snapshots and reach different conclusions.

Run the fixtures with the consume command

The consume command is designed to execute existing Ethereum test fixtures rather than generate new ones. The framework documentation identifies fill for generating test vectors, consume for running existing vectors, and execute for live JSON-RPC testing. For Glamsterdam compatibility work, that distinction is useful because a fixture failure can first be reproduced independently of a running network.

uv run --with git+https://github.com/ethereum/execution-spec-tests.git consume --help

Start with the help output before choosing a fixture path or filter. The available options can change as the testing framework evolves, and using the command's own current interface is safer than copying arguments from an older devnet guide. Once the fixture bundle is available locally, use the consumer's fork and test-selection options to run only the Glamsterdam cases you want to investigate.

Use a client test when you need real execution-client evidence

A specification fixture tells you what the expected result should be, but developers ultimately need to know whether an execution client produces that result. Ethereum clients such as Geth, Nethermind, Besu, and others implement the execution rules independently, which is why the same fixture suite is valuable across multiple implementations. A failure in one client is therefore not automatically evidence that the Glamsterdam specification is wrong.

For live-client testing, run the target execution client with its Glamsterdam-compatible development configuration and expose its JSON-RPC endpoint only to your local test environment. Then use the testing framework's live execution mode against that endpoint. This separates two useful questions: whether the official fixture itself behaves as expected, and whether a particular client correctly implements that behavior.

Check the failure before changing your client

A failed Glamsterdam test needs classification before anyone starts modifying code. First check that the fixture version matches the client branch being tested, because the fork specification is still evolving. Next check whether the failure is caused by a changed gas rule, a fixture update, a client implementation issue, or an infrastructure problem such as an unavailable dependency.

This is particularly important for Glamsterdam because the execution specification has already changed between devnet releases. Devnet 8.1.0, for example, revised EIP-2780-related gas parameters and added test coverage around those changes. A client that correctly passes Devnet 7 fixtures can therefore fail a newer fixture for a legitimate reason if its implementation has not caught up with the latest rules.

Compare multiple clients before calling it a protocol problem

Cross-client comparison is one of the strongest checks available to a developer working on a pre-mainnet Ethereum fork. If several independent execution clients fail the same new fixture in the same way, the fixture or specification deserves closer inspection. If one client fails while others pass, the implementation becomes the more obvious place to investigate.

This approach also prevents a common testing mistake: treating the first error message as the root cause. Ethereum clients have different internal architectures, so the same protocol mismatch may surface as a gas-calculation error in one implementation and a state-transition error in another. Compare the expected fixture result, the client's actual result, and the exact fork configuration before drawing a conclusion.

Test the Sepolia transition separately from local fixtures

Local fixture testing is not a replacement for testing an actual network fork. Ethereum developers have scheduled the Sepolia Glamsterdam fork for September 28, 2026, with the relevant client and application releases expected to be confirmed before activation. Sepolia is a public Ethereum test network, so it provides a useful second stage after local fixture testing because wallets, explorers, applications, validators, and other infrastructure can expose compatibility problems that isolated execution tests cannot.

Do not send production funds or point production infrastructure at experimental fork configurations. Treat the local devnet and Sepolia as progressively broader compatibility tests: first prove that the execution rules work, then prove that the client implementation works, and finally check that the surrounding Ethereum tooling continues to behave correctly during the fork transition.

Keep a reproducible Glamsterdam test record

For every failure, record the client name and version, consensus-client version when relevant, Glamsterdam fixture version, operating system, test command, failing fixture and complete error output. This turns a vague report such as “Glamsterdam is broken” into a reproducible engineering problem. It also makes later comparisons meaningful when a new devnet fixture or client release changes the result.

Glamsterdam is still a development target rather than a finished mainnet specification, so the correct goal is not to prove that every test must pass today. The useful result is a clear record of what the current fixture expects, what each client actually does, and which changes are still moving. As the September 28 Sepolia fork approaches, developers who have already tested against versioned fixtures will have a much better baseline for deciding whether their applications and node infrastructure are ready for the next transition.