EIPs

Introduces new opcodes

Modifies pre-existing opcodes

Introduces new precompiles

Modifies pre-existing precompiles logic or gas-accounting

Introduces new system contract, stateful or not

Modifies pre-existing system contracts

New EVM gas accounting rules

Changes *where inside an opcode's execution* state is accessed, or where gas is charged relative to that access. Because a state access is recorded in the block-level access list only if execution had enough gas to reach it, this ordering is consensus-critical: moving it changes the BAL at every gas boundary of every affected opcode.

New Blob gas accounting rules which potentially affect pre-existing tests

New state gas accounting rules. State gas is the cost of *writing* state, as opposed to accessing or executing it: `StateGasCosts`, `COST_PER_STATE_BYTE`, the block-level state gas budget, and the spill path into execution gas.

New gas-refund mechanism

Introduces a new transaction type

Creates new or modifies pre-existing transaction types' validation mechanisms

Introduces new block or block header fields

Introduces encoding changes at the transaction/block/interfaces level

Modifies block RLP validation mechanisms that require test client syncing.

Modifies state, internal variables, or similar, at the fork activation block

Introduces new fields to the Engine API directives

Engine API encoding changes (the revision-1 template defines no anchor text for this row).

Modifies or adds new fields to the transition tool interface.

Implements a new validation mechanism or rule that translates in reworking pre-existing tests

Tests that are **not about this EIP** must nonetheless assert something this EIP produces. Their logic does not change; they gain a new thing to check.

Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists.

Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.

Introduces or modifies mechanisms and requires performance validation.

Feature contains edge/boundary conditions.

Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography

Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.

The EIP text does not determine the answer for cases a test can construct. Clients must agree on a previously unspecified detail before tests can be baselined. The cost here is coordination and re-baselining, not test writing.