Retrospective LLM-Based Complexity Evaluations

EIP complexity assessment

EIP-8298: SETCODEFROM Code Reuse Instruction

Assessed in Hegotá. The score describes the EIP text available at the snapshot, not the EIP as it stands today.

ProspectiveHegotáSnapshot 2026-08-25PFI at snapshotLayers: execution
LLM Completescore 22
Human Pending· No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.

LLM assessment

Evaluated on: · Spec revision: 2026-08-25 · ac450a4ab2 · Inclusion status at snapshot: PFI

Scope at the cutoff. Execution-layer assessment of the sealed Draft of EIP-8298: one runtime-only EVM instruction that adopts a live source account's code hash, charges a fixed base plus active warm/cold account-access gas, mutates the current execution-environment account with revert semantics, and makes the new code visible to later execution while the current frame continues its already-loaded code.

22MediumMedium
Evaluator
LLMChecklist v2
Confidence
Medium
Under-specified at assessment cutoff
Yes — 6 criteria affected
Plausible range
21–23 (Medium–High)
Snapshot
2026-08-25 · EIP revision ac450a4ab2 (2026-08-25)
Score bands · Checklist revision 2
  • Low <12
  • Medium 12–22
  • High ≥23

28 criteria scored 0–3 (4 in exceptional cases; cross-EIP interactions is uncapped); nominal maximum 84.

Complexity profile

Each segment is one criterion's contribution to the LLM total. Hover or focus a segment for its score and rationale.

Top complexity drivers

  1. Cross-EIP interactions4
  2. EVM Gas rule changes3
  3. Security risks3
  4. Edge/boundary conditions3

Under-specified at assessment cutoff: Yes

The EIP text available at the assessment cutoff left material behavior unresolved. The affected criteria and the plausible total range record that uncertainty.

Why: Material under-specification remains in the opcode assignment, the exact source-access/gas/check ordering, and the exhaustive definition of valid regular deployed source code. These are recorded once here; their direct scoring consequences are confined to the listed criteria.

Plausible total

21–23
recorded score 22 · plausible tiers Medium, High

Unresolved questions at the cutoff (4)
  • What numeric value is SETCODEFROM_OPCODE?
  • In what exact order are stack/context checks, base-gas charging, source access and warming, source-code reads, validity checks, and the current-account write performed, especially at out-of-gas boundaries and in static or initcode execution?
  • What is the exhaustive active-fork predicate for valid regular deployed source code beyond the stated 0xEF example?
  • Are later EXTCODE* observations of the current account required to change immediately while CODESIZE and CODECOPY remain bound to the current frame's already-loaded code?
Notable ambiguities noted by the assessor (3)
  • The access-ordering test space is multiplicative: cold/warm, static/non-static, initcode/deployed, delegated/direct, valid/invalid source, sufficient/insufficient gas, success/revert, and later direct/re-entrant observation can change the expected result or recorded access.
  • The 3000 base charge is justified by analogy to a warm nonzero-to-nonzero SSTORE, but it is a fixed SETCODEFROM rule rather than reuse of SSTORE net-metering or refund semantics.
  • The draft says regular code adoption disables ECDSA transaction origination permanently at protocol level, while application-level signature recovery remains possible unless the separately specified companion behavior is also adopted.

Criterion breakdown

EIP-8298 Hegotá: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
Cross-EIP interactionsUnder-specifiedExceptional4The coordinated set is 2200, 2929, 3541, 3607, 7702, 7928, 8037, and 8151. Gas/warmth, deployed-code validity, authority-account selection, sender and authorization validity, block-level access recording, state-growth pricing, and ecRecover behavior each need targeted combined cases. With eight interactions, the rubric gives base score 3 plus one increment for at least three additional interactions beyond the first three.

Exceptional score: The score of 4 is the rubric's mechanical uncapped result: eight identified interacting EIPs produce score 3 plus one increment for the first group of three additional interactions beyond the initial three.

  • eip.md · Front matter > requires; Specification > Gas Costs; Specification > ECDSA Transaction Origination The EIP requires 2200, 2929, 3607, and 7702 for gas comparison, warm/cold access, sender-code validity, delegated execution, and authorization-code restrictions.
  • eip.md · Specification > SETCODEFROM; Motivation Source-code validity uses the 0xEF reservation associated with 3541/7702, and the deployment-economics use case explicitly targets state-creation pricing under 8037.
  • eip.md · Security Considerations The proposal identifies coordinated behavior with 7702 delegation, contrasts 6913 without depending on it, and identifies 8151 as a companion for account-code-restricted ecRecover.
  • rubric.md · Testing Anchors > State-access ordering within opcode execution A new state access must be coordinated with block-level access-list observability at gas boundaries.
  • supporting/eip-8037.md · Specification > Pre-state and post-state gas validation; Rationale > Account-creation charging and EIP-7928 The package identifies 7928 as the block-level access-list proposal that constrains recordable state-access timing.
Confidence: Medium
Uncertainty: 6913 is only a withdrawn comparison and 20 only an application example, so neither is counted. Additional active-fork code-validity rules are not exhaustively identified by the draft.
Interacting EIPs: EIP-2200, EIP-2929, EIP-3541, EIP-3607, EIP-7702, EIP-7928, EIP-8037, EIP-8151
EVM Gas rule changesUnder-specified3This is a new dynamic opcode-gas rule, and executing it participates in the existing transaction-wide warmth mechanism, so it can change gas charged by later existing account-access operations. That reaches score 3 rather than a self-contained constant schedule.
  • eip.md · Specification > Parameters; Specification > Gas Costs SETCODEFROM introduces a 3000-gas base charge plus a source-dependent warm/cold account-access charge, yielding 3100 or 5600 under the stated EIP-2929 constants.
  • supporting/eip-2929.md · Specification > Storage read changes The existing transaction-wide accessed-address mechanism charges cold or warm costs and changes the cost of later account operations after an address is warmed.
Confidence: Medium
Uncertainty: The score assumes participation in accessed_addresses follows the cited active warm/cold mechanism; EIP-8298 does not fully order the base charge, account access, warming, and exceptional-context checks.
Security risks3The mechanism crosses critical account authority, code identity, delegated execution, storage compatibility, transaction origination, re-entrancy, and revert boundaries. Incorrect implementation or exposure can transfer control or strand an account, warranting extensive review and fuzzing.
  • eip.md · Security Considerations The instruction can permanently change account behavior, changes code-identity and inspection semantics, permits delegated execution to update the authority account, disables protocol-level ECDSA origination, and creates re-entrant visibility of new code.
  • supporting/eip-7702.md · Specification > Delegation indicator; Security Considerations > Storage management Delegated execution separates authority from loaded code, and changing account code is security-critical because storage and authority assumptions can collide across implementations.
Confidence: High
Uncertainty: The package is explicit about the risk classes, but the TODO tests and open source-validity predicate leave their final test matrix incomplete.
Edge/boundary conditionsUnder-specified3Several independent boundaries exist, and temporal visibility plus re-entrancy requires an elevated cross-product of context, source validity, warmth, gas boundary, success/revert, and delegated/direct cases.
  • eip.md · Specification > SETCODEFROM; Specification > Deployed Code Execution Cases include low-160-bit address truncation, precompile/empty/invalid/valid sources, initcode and static exceptional halts, success versus zero return, frame or transaction revert, delegated versus direct execution, current-frame old code, and later/re-entrant execution of new code.
  • eip.md · Security Considerations Implementations must separate currently executing code from later-visible account code, and re-entrant calls after success observe the update.
Confidence: High
Uncertainty: The source-validity predicate is illustrative rather than exhaustive, so the final boundary set may be larger.
Unspecified behavior requiring cross-client consensusUnder-specified3Several constructible outcomes cannot yet be baselined, including bytecode selection, access-list/gas-boundary effects, and the complete source-validity predicate. Those gaps concern a newly observable code-identity transition and can require vectors to be re-derived as the draft is amended.
  • eip.md · Specification > Parameters; Specification > SETCODEFROM; Test Cases The opcode value is TBD, regular deployed-code validity is described with a non-exhaustive 'e.g.' rule, detailed state-access/check ordering is absent, and the test section is TODO.
  • eip.md · Specification > Deployed Code Execution; Security Considerations The new, previously unavailable same-transaction code replacement makes current-frame versus later-call and code-inspection visibility consensus-observable.
Confidence: Medium
Uncertainty: The sealed package provides Draft status but no permitted evidence about implementations, devnets, or discussion resolution; the score rests only on the visible normative gaps.
Added opcodes2This is one complex opcode because its cost is dynamic and it performs state access and conditional state mutation.
  • eip.md · Specification > Parameters; Specification > SETCODEFROM; Specification > Gas Costs One new opcode is defined with one input and one output, live account access, conditional account-state mutation, and dynamic warm/cold gas; its numeric value is TBD.
Confidence: High
Uncertainty: The missing numeric assignment blocks final bytecode vectors but does not change the count or complex character of the opcode.
State-access ordering within opcode executionUnder-specified2A new state-accessing operation is introduced, and the position of its source access and warmth update relative to gas charging and exceptional-context checks must be settled. This matches the score-2 anchor for one new state-accessing operation.
  • eip.md · Specification > SETCODEFROM; Specification > Gas Costs The instruction reads live source.codeHash, validates source code, charges warm/cold source access, exceptionally halts in initcode or static context, and conditionally writes the current account's codeHash.
  • supporting/eip-2929.md · Specification > Parameters; Specification > Storage read changes Account access both charges gas and updates the transaction-scoped accessed_addresses set at opcode execution time, with scope-reversion behavior defined for the set.
Confidence: High
Uncertainty: The draft does not say whether static/initcode failure, insufficient gas, or a failed source-validity check occurs before or after the source is recordably accessed and warmed.
Patterns affecting pre-existing testsUnder-specified1The affected pre-existing category is narrow: invalid/unassigned-opcode behavior at the eventual opcode byte and any deployed bytecode containing it. This is a minor subset rather than a broad rework.
  • eip.md · Specification > Parameters; Backwards Compatibility The opcode value is TBD, and the hard-fork assignment changes the behavior of already deployed bytecode using the newly assigned instruction.
Confidence: Medium
Uncertainty: Because the opcode byte remains TBD, the exact existing-test subset cannot yet be identified.
Performance risks1The new read/write path needs isolated benchmarking, especially for cold versus warm access and journaling, but it is bounded and does not add bytecode copying or a size-dependent workload.
  • eip.md · Specification > Gas Costs; Rationale Each attempt performs one live source-account read and one conditional current-account codeHash update; no source bytecode is stored, and the fixed charge is independent of source code size.
Confidence: Medium
Uncertainty: The package contains no benchmarks or performance-validation plan, so cache, journaling, and repeated-update costs are not quantified.
Show 19 zero-score criteria
Zero-score criteria (Checklist revision 2)
CriterionScoreWhy this scoreEvidence / uncertainty
Modified opcodes0Existing operations can observe state changed by SETCODEFROM, but their own behavior is not modified by the proposal.
  • eip.md · Specification > Deployed Code Execution The current frame continues its already-loaded code and later code-executing operations use the updated account state; no existing opcode definition is rewritten.
Uncertainty: Code-inspection cases need tests, but the package frames their changed results as consequences of the new state mutation rather than modified opcode semantics.
Added precompiles0No precompile is added.
  • eip.md · Specification > SETCODEFROM Precompile addresses are explicitly invalid source accounts; no new precompile address or function is defined.
Uncertainty: The source exclusion is an opcode validation branch, not a precompile addition.
Modified precompiles0EIP-8298 does not alter precompile logic or gas accounting.
  • eip.md · Specification > SETCODEFROM; Security Considerations The instruction rejects precompile sources and merely mentions an optional companion ecRecover change in a separate EIP.
  • supporting/eip-8151.md · Abstract; Specification > Modified ecRecover Behavior The ecRecover behavior change is specified by EIP-8151, not EIP-8298.
Uncertainty: Co-activation with the companion proposal is handled as a cross-EIP interaction, not attributed as an EIP-8298 precompile modification.
Added system contracts0No system contract is introduced.
  • eip.md · Abstract; Specification > SETCODEFROM The proposal introduces an instruction usable by executing account code and does not deploy a protocol-owned contract.
Uncertainty: The factory and wallet templates are application examples, not added system contracts.
Modified system contracts0There is no direct or package-evidenced indirect modification to a pre-existing system contract.
  • eip.md · Specification; Rationale SETCODEFROM is self-only for the current execution-environment account, and no existing system contract code, state, or invocation is named for modification.
Uncertainty: Generic accounts could choose to execute the opcode, but the sealed package identifies no system-contract consumer.
Blob gas accounting changes0No blob-gas counter, price, limit, or charging rule is introduced or modified.
  • eip.md · Specification > Parameters; Specification > Gas Costs The only specified charges are EVM base gas and warm/cold source-account access gas.
Uncertainty: No blob-related behavior appears in the sealed proposal.
State gas accounting changes0SETCODEFROM reuses already-stored bytecode and introduces no state-gas rate, budget change, reservoir rule, or state-gas charging site. Its specified charge is execution gas.
  • eip.md · Specification > Gas Costs The proposal assigns zero cost to storing source bytecode because it already exists and defines the operation's charge entirely as a 3000 base plus source-account access.
  • supporting/eip-8037.md · Specification > Multidimensional metering for state creation costs State gas is separately charged for state-creation operations, while other operations are charged to execution gas.
Uncertainty: The proposal does not explicitly use the state-gas vocabulary for its codeHash write, but its no-new-bytecode rationale and complete SETCODEFROM_GAS formula provide no package evidence for a state-gas change.
New EVM gas refund0No new gas-refund mechanism is introduced. Reverting the code update is ordinary state reversion, not a gas refund.
  • eip.md · Specification > Gas Costs; Specification > SETCODEFROM Every attempt is charged the defined gas and failure returns zero or exceptionally halts; no refund counter operation is specified.
Uncertainty: No refund behavior is stated anywhere in the sealed EIP.
New transaction types0No new transaction type is introduced.
  • eip.md · Abstract; Specification > SETCODEFROM The feature is a runtime-only instruction and adds no transaction envelope.
Uncertainty: The instruction can execute within existing transaction execution, subject to its initcode prohibition.
New or modified transaction validity mechanisms0SETCODEFROM creates account state to which existing validity rules apply; it does not create or modify the validity mechanism or intrinsic gas calculation of a transaction type.
  • eip.md · Specification > ECDSA Transaction Origination After adoption, ECDSA origination and redelegation fail by application of the already-existing EIP-3607 and EIP-7702 code checks.
  • supporting/eip-3607.md · Specification EIP-3607 already rejects a transaction whose sender has non-empty code.
  • supporting/eip-7702.md · Specification > Set code transaction > Behavior; Specification > Transaction origination EIP-7702 already limits authorization processing and transaction origination according to empty, delegated, or regular account code.
Uncertainty: The consequence is security-critical and requires cross-EIP tests, but it is not itself a transaction-validity rule change under this anchor.
New block / header fields0No new block or block-header field is introduced.
  • eip.md · Specification The normative state consists of opcode parameters and account execution behavior; no block or header field is defined.
Uncertainty: No header surface appears in the sealed proposal.
Encoding changes (RLP/SSZ)0No RLP, SSZ, transaction, block, or interface encoding changes are introduced.
  • eip.md · Specification > SETCODEFROM The new input is an EVM stack item interpreted as a low-160-bit address, and no transaction, block, or interface encoding is defined.
Uncertainty: Assigning an opcode byte is EVM bytecode semantics, not an encoding change at the levels named by this anchor.
Block syncing changes0No block RLP validation mechanism requiring syncing tests is introduced.
  • eip.md · Specification; Backwards Compatibility The proposal adds an EVM instruction and describes account-state execution effects, with no block RLP validation rule.
Uncertainty: No block-serialization surface appears in the package.
New fork activation mechanism0No account state, pre-existing internal variable, or similar value is modified specifically at the activation block.
  • eip.md · Backwards Compatibility Activation is described as a hard fork that makes the new instruction available, without an activation-block state transition.
Uncertainty: Normal opcode-table activation is not an irregular fork-activation mechanism under this anchor.
Engine API changes0No Engine API field, endpoint, or communication mechanism is added or modified.
  • eip.md · Abstract; Specification All normative changes are within EVM instruction execution and account state.
Uncertainty: No Engine API surface is described.
Transition-tool interface changes0No transition-tool input or output field and no new interface mechanism is specified.
  • eip.md · Specification > SETCODEFROM; Backwards Compatibility The change is expressed as opcode execution over existing stack, account, codeHash, and gas state and requires a normal hard-fork activation.
Uncertainty: Implementations need opcode support, but that is not evidence of an interface-field change under this anchor.
New invariant on pre-existing tests0Tests unrelated to SETCODEFROM do not gain a mechanically required new assertion merely because the fork activates.
  • eip.md · Abstract; Backwards Compatibility The new result and codeHash mutation occur only when the new instruction executes; the compatibility impact is limited to bytecode using that instruction.
Uncertainty: The Test Cases section is TODO, but no package text defines a fork-wide output or invariant for every pre-existing test.
New test-framework primitives0The package does not establish a need for a new expectation type, modifier, or framework-level helper beyond composing opcode, call, state, and revert tests.
  • eip.md · Specification > SETCODEFROM; Specification > Deployed Code Execution; Test Cases The observable behaviors are stack success, account code changes, calls, exceptional halts, and reverts; the Test Cases section contains only TODO and requests no new testing abstraction.
Uncertainty: The absent test design limits confidence that existing helpers cover same-transaction code replacement ergonomically, but no required primitive is evidenced.
Cryptography0No cryptographic mechanism is introduced or modified. Existing hash and ECDSA consequences are state-identity interactions, not new cryptography in this EIP.
  • eip.md · Motivation; Specification > SETCODEFROM Post-quantum migration is a use case, but the instruction itself takes an address and copies an existing live account codeHash without defining a cryptographic operation.
Uncertainty: The proposal's PQ motivation does not change the execution-layer mechanism scored here.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@ac450a4ab2 EIPS/eip-8298.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z
Current master · File history · blob aa6440a0cc · sha256 177a51851156
Rubric
Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator
gpt-5.6-sol at xhigh reasoning effort · isolation bubblewrap_one_eip_capsule_v1
Source record
Frozen research record research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8298.yaml · sha256 1b7eed2ca59d
Supporting documents in the sealed package
supporting/eip-20.md, supporting/eip-2200.md, supporting/eip-2929.md, supporting/eip-3541.md, supporting/eip-3607.md, supporting/eip-6913.md, supporting/eip-7702.md, supporting/eip-8037.md, supporting/eip-8151.md
Compare EIP-8298 with other assessmentsAll Hegotá assessments
Criterion legend and glossary

Every stacked bar, comparison matrix, and criterion table on this site uses the same criterion colours, abbreviations, and order. Colour marks the criterion group; the abbreviation and name identify the criterion. Scores are 0–3 per criterion (4 is exceptional; cross-EIP interactions is uncapped).

EVM surface

Opcodes, precompiles, and system contracts that are added or modified.

  • Added opcodes
    Introduces new opcodes
    Score anchors
    0
    No new opcodes are introduced.
    1
    A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
    2
    Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
    3
    Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
    • Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
  • Modified opcodes
    Modifies pre-existing opcodes
    Score anchors
    0
    No pre-existing opcode modifications are introduced.
    3
    At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
  • Added precompiles
    Introduces new precompiles
    Score anchors
    0
    No new precompiles are introduced.
    1
    A new simple precompile is introduced (constant input length, constant gas cost).
    2
    Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
    3
    Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
    • Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
  • Modified precompiles
    Modifies pre-existing precompiles logic or gas-accounting
    Score anchors
    0
    No pre-existing precompiles are modified.
    1
    At least one pre-existing precompile has its gas schedule modified.
    2
    Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
    3
    The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
  • Added system contracts
    Introduces new system contract, stateful or not
    Score anchors
    0
    No new system contracts are introduced.
    1
    A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
    2
    Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
    3
    Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
  • Modified system contracts
    Modifies pre-existing system contracts
    Score anchors
    0
    No modifications to pre-existing system contracts are introduced, directly or indirectly.
    1
    Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
    2
    Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
    3
    At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.

Gas and accounting

Execution, blob, and state gas rules, refunds, and where charges happen inside opcodes.

  • EVM Gas rule changes
    New EVM gas accounting rules
    Score anchors
    0
    No gas accounting changes.
    1
    Existing gas accounting mechanism is updated.
    2
    A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
    3
    A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
  • State-access ordering within opcode execution · Checklist revision 2 only
    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.
    Score anchors
    0
    No change to where state is accessed, or to where gas is charged relative to a state access, within any opcode.
    1
    A single opcode's state-access or gas-charge ordering changes.
    2
    Multiple opcodes' ordering changes, or a new state-accessing operation is introduced whose position in the order must be settled.
    3
    The ordering rule changes for a whole class of state-accessing opcodes at once, or what counts as a recordable state access is redefined — requiring existing BAL vectors to be re-derived across opcodes and forks.
    • Distinct from "Modified opcodes", which asks whether an opcode's **result** changed. This row asks about the **path to the result**, which is observable even when the result is identical. An EIP can be 0 on that row and 3 on this one.
    • Score changes **to** the ordering. Do not score the fact that state accesses are observable — they always are.
    • Each boundary must be re-tested against every other dimension that can change the answer (cold/warm, static/non-static, delegated/direct, revert/success), so the case count grows multiplicatively rather than additively. Note this explicitly under Special Considerations.
  • Blob gas accounting changes
    New Blob gas accounting rules which potentially affect pre-existing tests
    Score anchors
    0
    No blob gas accounting changes.
    1
    Existing blob gas accounting mechanism is updated.
    2
    A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
    3
    A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
  • State gas accounting changes · Checklist revision 2 only
    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.
    Score anchors
    0
    No state gas accounting changes.
    1
    An existing state gas cost or `STATE_BYTES_PER_*` rate is adjusted.
    2
    A new state-gas-charging site is introduced, or the block-level state gas budget or reservoir allocation is modified.
    3
    A new state gas charging mechanism is introduced, or the spill interaction between state gas and execution gas is modified, affecting existing gas tests.
    • Harder to test than blob gas: the spill path means state gas cannot be metered independently of execution gas, and some costs (e.g. `NEW_ACCOUNT`) are state-dependent.
  • New EVM gas refund
    New gas-refund mechanism
    Score anchors
    0
    No new gas-refund mechanisms are introduced.
    1
    A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
    2
    A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
    3
    A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.

Blocks, transactions, and encoding

Transaction types and validity, block and header fields, encodings, syncing, and activation-time changes.

  • New transaction types
    Introduces a new transaction type
    Score anchors
    0
    No new transaction types are introduced.
    3
    A new transaction type is introduced.
  • New or modified transaction validity mechanisms
    Creates new or modifies pre-existing transaction types' validation mechanisms
    Score anchors
    0
    No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
    1
    Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
    2
    Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
    3
    Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
  • New block / header fields
    Introduces new block or block header fields
    Score anchors
    0
    No new block or header fields are introduced.
    3
    A new block or header field is introduced.
  • Encoding changes (RLP/SSZ)
    Introduces encoding changes at the transaction/block/interfaces level
    Score anchors
    0
    No encoding changes are introduced at the transaction, block, or interfaces levels.
    3
    An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
    • "Interfaces level" includes the Engine API. Score an Engine API encoding change (e.g. JSON -> SSZ) here.
  • Block syncing changes
    Modifies block RLP validation mechanisms that require test client syncing.
    Score anchors
    0
    No new RLP validation mechanism is introduced.
    1
    A single simple RLP validation mechanism is introduced.
    2
    Multiple simple RLP validation mechanisms are introduced or a single complex one.
    3
    Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
  • New fork activation mechanism
    Modifies state, internal variables, or similar, at the fork activation block
    Score anchors
    0
    No state modifications, internal variables or similar are modified at the fork activation block.
    3
    Either a state modification or internal variables are modified at the fork activation block.
    • Initialization of new internal variable is not considered a modification.

Client interfaces

Engine API and transition-tool interface changes.

  • Engine API changes
    Introduces new fields to the Engine API directives
    Score anchors
    0
    No new fields or communication mechanisms are introduced to the Engine API.
    1
    A single new field is introduced in one of the Engine API endpoints.
    2
    Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
    3
    Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
  • Engine API encoding changes · Checklist revision 1 only
    Engine API encoding changes (the revision-1 template defines no anchor text for this row).
  • Transition-tool interface changes
    Modifies or adds new fields to the transition tool interface.
    Score anchors
    0
    No modifications to the transition tool interface are required.
    1
    A single new field needs to be introduced to the transition tool interface.
    2
    Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
    3
    Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
    • Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.

Testing impact

Rework, new invariants, and new primitives required in the test framework.

  • Patterns affecting pre-existing tests
    Implements a new validation mechanism or rule that translates in reworking pre-existing tests
    Score anchors
    0
    No pre-existing tests are affected by this change.
    1
    Minor subset of existing tests are affected by this change.
    2
    Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
    3
    Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
  • New invariant on pre-existing tests · Checklist revision 2 only
    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.
    Score anchors
    0
    Pre-existing tests assert nothing new.
    1
    A narrow, contrived category of pre-existing tests gains a new assertion.
    2
    A broad category gains a new assertion, applied mechanically.
    3
    Every test in the fork gains the assertion regardless of what it tests, and pre-fork vectors must be re-derived to satisfy it.
    • Paired with the row above, and easy to confuse with it. "Patterns affecting pre-existing tests" asks whether existing tests must be **reworked**; this row asks whether they must **additionally assert something new**. Score both — an EIP can be low on one and high on the other.
  • New test-framework primitives · Checklist revision 2 only
    Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists.
    Score anchors
    0
    Existing test primitives suffice.
    1
    Existing primitives need minor extension.
    2
    New expectation or modifier primitives are required, reusable within this EIP's own test suite.
    3
    New framework-level primitives are required that become a permanent part of the framework and are used by other EIPs' tests.

Risk and validation

Security, performance, boundary conditions, and cryptography that need validation.

  • Security risks
    Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
    Score anchors
    0
    No new mechanisms are introduced that could pose a security risk.
    1
    The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
    2
    The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
    3
    The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
  • Performance risks
    Introduces or modifies mechanisms and requires performance validation.
    Score anchors
    0
    No new mechanisms are introduced that require performance validation.
    1
    The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
    2
    The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
    3
    The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
  • Edge/boundary conditions
    Feature contains edge/boundary conditions.
    Score anchors
    0
    No discernible edge cases or boundary conditions are introduced.
    1
    A single edge-case or boundary-condition prone mechanism is introduced.
    2
    Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
    3
    Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
  • Cryptography
    Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
    Score anchors
    0
    No cryptography mechanisms are introduced.
    1
    A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
    2
    Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
    3
    Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.

Coordination

Cross-EIP interactions and behavior that clients must agree on before tests exist.

  • Cross-EIP interactions
    Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
    Score anchors
    0
    Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
    1
    The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
    2
    The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
    3
    The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
    • +1 for every 3 additional interacting EIPs beyond the first 3, each of which requires its own coordinated test cases. List the EIPs in the rationale.
    • This row is intentionally uncapped, unlike every other anchor: each interacting EIP is another axis of the test matrix, so a ceiling would make a 12-EIP product indistinguishable from a 3-EIP one.
  • Unspecified behavior requiring cross-client consensus · Checklist revision 2 only
    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.
    Score anchors
    0
    The EIP text determines the answer for every case a test could construct.
    1
    A few details are unspecified but have an obvious intended reading.
    2
    Details require client agreement before tests can be written, but they are localized.
    3
    A previously unspecified *and previously unobservable* behavior becomes consensus-critical; expect tests to be re-baselined on each round of EIP amendment.
    • Score this from the EIP's state at assessment time: whether it has client implementations, whether it has been through a devnet, and how many open questions remain on its discussion thread.