Retrospective LLM-Based Complexity Evaluations

EIP complexity assessment

EIP-7002: Execution layer triggerable withdrawals

Assessed in Prague / Pectra. The score describes the EIP text available at the assessment cutoff, not the EIP as it stands today.

RetrospectivePrague / PectraAssessment cutoff 2024-01-18Included by cutoffLayers: execution, consensus
LLM Completescore 38
Human Not available· Human complexity assessments were not produced for this fork; only the LLM assessment exists.

LLM assessment

Evaluated on: · Spec revision: 2023-06-29 · 28cbb0162f

Scope at the cutoff. At the selected revision, EIP-7002 proposed a new stateful, value-accepting precompile through which an execution-layer withdrawal credential could queue a validator exit. The execution layer would maintain a persistent FIFO queue and an EIP-1559-style dynamic exit fee, append up to 16 queued exits and an exits-root commitment to each block, and update the queue and fee state after block execution. The consensus-layer portion was only a sketch: exits would be carried in the ExecutionPayload and processed with voluntary-exit-like rules whose validation failures would not invalidate the block.

38HighHigh
Evaluator
LLMChecklist v2
Confidence
Medium
Under-specified at assessment cutoff
Yes — 10 criteria affected
Plausible range
33–44 (High)
Assessment cutoff
2024-01-18 · EIP revision 28cbb0162f (2023-06-29)
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. New block / header fields3
  2. Encoding changes (RLP/SSZ)3
  3. Block syncing changes3
  4. Patterns affecting pre-existing tests3

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 consensus behavior is unresolved: core constants and gas charging are TBD; the refund-call signature and recipient are inconsistent; queue insertion and validation use contradictory layouts; malformed input, call-mode, rollback, and re-entry outcomes are not fully defined; concrete Engine API/tool interfaces are absent; and the consensus-layer rules are only a sketch. These gaps directly drive the unspecified-behavior score and lower confidence in several interface, gas, framework, precompile, and performance scores without being counted as separate primary complexity in every affected row.

Plausible total

33–44
recorded score 38 · plausible tiers High

Unresolved questions at the cutoff (6)
  • What is the precompile address, gas schedule, and exact behavior for malformed input and non-CALL call modes?
  • Which address receives excess payment, and do nested-call failure or re-entry revert every preceding queue and counter write atomically?
  • What is the canonical three-slot queue decoding algorithm, including integer bounds, cleared entries, and pointer behavior under long-lived backlog?
  • What exact consensus-layer eligibility, withdrawal-credential authorization, duplicate/already-exited handling, and state-transition rules apply?
  • Which ExecutionPayload and Engine API fields and versions carry exits, and which transition-tool inputs or outputs represent them?
  • Does the final precompile gas rule remain fixed despite state-dependent fake-exponential work, or become dynamic?
Notable ambiguities noted by the assessor (4)
  • The sealed historical EIP header calls the feature "Execution layer triggerable exits," while the package/template provenance title says "Execution layer triggerable withdrawals"; the assessment preserves the populated package title and evaluates the sealed exit mechanism.
  • The exit-fee rationale calls one parameter the maximum downward rate of the "blob gas price," although every surrounding formula and variable concerns exits.
  • The historical EIP simultaneously specifies three storage slots per queued exit during insertion and two-slot stepping with repeated slot reads during validation.
  • EIP-4788 is linked and discussed, but only as a dependency of an explicitly unselected alternative; it is therefore not listed as an interacting EIP.

Criterion breakdown

EIP-7002 Prague / Pectra: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
New block / header fields3The explicit new header field triggers the rubric's binary score-3 anchor.
  • eip.md · Block structure, lines 156-179 Beginning at the fork block, the block body gains an exits list and the header gains a new exits_root field committing to that list.
Confidence: High
Encoding changes (RLP/SSZ)3Explicit RLP changes at the block level and an SSZ interface/payload addition trigger the rubric's binary score-3 encoding anchor.
  • eip.md · Exit operation and Block structure, lines 61-73 and 156-179 The proposal defines RLP for each exit and extends the RLP block body with an exits list and the block header with its trie-root commitment.
  • eip.md · Consensus layer sketch, lines 283-292 The execution payload gains an SSZ List of ExecutionLayerExit operations.
Confidence: High
Uncertainty: The consensus-layer SSZ container details are only sketched, but the block-level RLP change independently fixes the score at 3.
Block syncing changes3The proposal adds multiple block-RLP/schema validations, including the complex state- and ordering-dependent queue equivalence rule, so the score-3 syncing anchor applies.
  • eip.md · Block structure, lines 156-179 The post-fork RLP block body is extended by an exits list and the header by an exits_root committing to that list.
  • eip.md · Block validity, lines 181-226 Sync validation must verify both the commitment and a state-dependent ordered equivalence between the body exits and the persistent queue after transactions.
Confidence: High
Uncertainty: The illustrative queue-extraction pseudocode is internally inconsistent, but the normative requirement for the complex validation is clear.
Patterns affecting pre-existing tests3Existing post-fork block, state-transition, malformed-block, and syncing tests must be reworked across diverse categories to construct or validate the new body, header, queue-derived operations, and end-of-block transition. This is the major, diverse impact described by score 3.
  • eip.md · Block structure and Block validity, lines 156-226 Every post-fork block gains an RLP body list and header commitment, and validity additionally depends on the post-transaction contents of persistent precompile state and strict FIFO ordering.
  • eip.md · Backwards Compatibility, lines 367-369 The proposal explicitly characterizes its block-structure and block-validation changes as backwards incompatible.
Confidence: High
Uncertainty: Exact test-suite breadth is not enumerated in the proposal, but the mandatory per-block schema and validity changes make the broad impact direct.
Security risksUnder-specified3The feature crosses authorization of validator funds, consensus exit processing, execution-layer value transfer, persistent queue state, block validity, and an anti-griefing fee market. These multiple critical-component interactions require extensive security review and fuzzing, meeting score 3.
  • eip.md · Rate limiting using exit fee, lines 336-344 The mechanism is explicitly designed against cheap queue-filling griefing and combines an economic fee response with cross-layer exit delivery.
  • eip.md · Security Considerations / Impact on existing custody relationships, lines 371-380 Enabling withdrawal credentials to exit changes a validator-ownership capability on which existing custody relationships or products might rely.
  • eip.md · Validator Exit precompile, lines 79-125 A call mutates persistent queue state and performs a nested value-returning CALL, making failure, re-entry, and atomicity behavior security-relevant.
Confidence: High
Uncertainty: The incomplete consensus validation and CALL/revert semantics make the precise vulnerability surface uncertain, but not the breadth of security impact.
Edge/boundary conditions3Multiple independent mechanisms have boundary-rich state spaces, and the combination of value transfer/revert behavior, persistent FIFO transitions, capped per-block output, exponential integer math, and fork ordering requires an elevated case count. This meets score 3.
  • eip.md · Validator Exit precompile, lines 77-147 Call behavior has boundaries for 48-byte input, insufficient/exact/excess fee, excess-return success, queue indices, integer arithmetic, and termination of the fake-exponential loop.
  • eip.md · Block validity and queue update, lines 195-224 and 254-279 Dequeue behavior depends on empty, below-limit, exactly-limit, and above-limit queue sizes, preserves FIFO order, conditionally resets pointers, and updates excess around the target threshold.
Confidence: High
Uncertainty: Several boundary outcomes are themselves under-specified, increasing test-design uncertainty without changing the primary score.
Unspecified behavior requiring cross-client consensusUnder-specified3Previously nonexistent stateful-precompile, queue, refund, and cross-layer exit behaviors become consensus-visible, yet several constructible cases and even the block queue-decoding algorithm lack a single answer. Cross-client agreement and repeated test re-baselining would be required, meeting score 3.
  • eip.md · Constants, Configuration, and Gas cost, lines 31-51 and 150-154 The fork timestamp, precompile address, and precompile gas cost are all TBD.
  • eip.md · trigger_exit and return_excess_payment pseudocode, lines 93-125 trigger_exit calls return_excess_payment with one argument although its definition requires fee and source address, leaving the refund recipient and precise failure/rollback semantics unresolved.
  • eip.md · Block validity queue extraction, lines 195-224 Queue insertion uses three slots per exit, while extraction advances by two and repeatedly reads the same slot in malformed pseudocode, so constructible block validity cases do not have a determinate algorithmic answer.
  • eip.md · Consensus layer sketch, lines 283-292 Consensus processing is only a sketch and says invalid exit requests can fail validation without invalidating the block, without specifying the full checks or outcomes.
Confidence: High
Uncertainty: The historical text is too incomplete to enumerate every unresolved call mode, malformed input, rollback, queue, and consensus-validation outcome.
Added system contracts2A single protocol-reserved contract-like address is both stateful and the source of a new cross-layer system action. That is exactly the score-2 single-system- contract anchor.
  • eip.md · Abstract and Stateful precompile rationale, lines 13-17 and 296-306 The proposal adds one unprecedented stateful precompile whose address holds an unbounded queue and fee state and whose output triggers consensus-layer exits.
Confidence: High
Uncertainty: The proposal calls the mechanism a precompile rather than a system contract, but it explicitly assigns protocol-owned code semantics and persistent state to one address.
EVM Gas rule changesUnder-specified2This is a new gas-charged EVM execution mechanism, but it is confined to calls to a previously unused precompile address and therefore does not, as written, alter existing gas-accounting mechanisms or their tests. That matches score 2; the actual amount and final fixed-versus-dynamic rule are not yet specified.
  • eip.md · Validator Exit precompile / Gas cost, lines 150-154 The proposal introduces metering for a new native precompile, but leaves its gas cost TBD pending an estimate of the native computation cost.
  • eip.md · Rationale / Utilizing CALL to return excess payment, lines 326-334 The selected refund path uses a 2300-gas nested CALL specifically so that the precompile can have fixed rather than dynamic gas accounting.
Confidence: Medium
Uncertainty: The precompile gas cost is explicitly TBD, so a finalized dynamic schedule or interaction with existing CALL charging could move this score.
State-access ordering within opcode executionUnder-specified2The proposal adds a new state-accessing operation behind CALL, and the positions of its state accesses, failure points, gas charging, and nested CALL must be settled and tested. It does not rewrite ordering for an existing class of opcodes, so score 2 is the applicable anchor rather than score 3.
  • eip.md · Validator Exit precompile / trigger_exit pseudocode, lines 79-125 A CALL to the new precompile performs fee validation, several state reads and writes, queue insertion, and then a nested value-returning CALL in a specified high-level sequence.
Confidence: Medium
Uncertainty: The gas charge point and revert behavior around the state writes and excess payment are not fully specified.
Transition-tool interface changesUnder-specified2Representing queue-derived block outputs plus a new end-of-block processing phase requires a new transition-tool mechanism and associated fields, matching score 2. The historical text does not define the concrete tool interface.
  • eip.md · Block structure and Block processing, lines 156-179 and 228-280 A transition must consume or produce the new exits body list and exits root and perform a new post-transaction, end-of-block queue and fee-state update.
Confidence: Medium
Uncertainty: No transition-tool API is specified, so the exact number and direction of fields depend on how the block-building and block-validation modes expose exits.
New invariant on pre-existing tests2A broad category of otherwise unrelated post-fork tests gains mechanical exits-root and queue-equivalence assertions. The text does not require pre-fork vectors to be re-derived, so score 2 fits better than the score-3 anchor.
  • eip.md · Block validity, lines 181-226 Valid post-fork blocks must commit to the body exits and must contain exactly the queue-head exits, in order, after transaction execution and before the per-block precompile update.
Confidence: High
New test-framework primitivesUnder-specified2The new queue/body equivalence expectation and end-of-block modifier are reusable primitives needed throughout this EIP's suite, beyond merely writing isolated precompile calls. The package does not establish reuse by other EIPs, so score 2 rather than score 3 is appropriate.
  • eip.md · Block validity and Per-block precompile storage calculations, lines 181-280 Tests must express queue-derived block-body expectations and observe a mandatory transition phase that occurs after transactions and validity checks.
Confidence: Medium
Uncertainty: Existing framework capabilities are not described; sufficiently generic block and storage expectations could reduce the needed extension to score 1.
Performance risksUnder-specified2Persistent backlog growth, stateful native execution, and mandatory per-block queue processing require integrated performance validation, but the emitted list and dequeue work are explicitly capped. This is a limited-impact, not fully isolated mechanism matching score 2.
  • eip.md · Stateful precompile rationale, lines 296-306 The proposal acknowledges that the in-state message queue contains an unbounded amount of state and may face client-specific engineering constraints.
  • eip.md · Exit message queue rationale, lines 316-324 Calls may arrive far faster than the maximum 16 exits dequeued per block, while the cap is intended to bound block-size and consensus-processing load.
Confidence: Medium
Uncertainty: The gas cost and behavior under very large fee/queue state are unresolved, so the actual computation and storage-growth impact could be greater.
Added precompilesUnder-specified1The defined shape is one precompile with constant input length and an intended fixed gas charge, matching score 1. Its statefulness and system action are scored separately under added system contracts.
  • eip.md · Abstract and Validator Exit precompile, lines 13-17 and 75-86 Exactly one new precompile is added, with one fixed-length 48-byte input and a call flow that queues an exit and returns excess payment.
  • eip.md · Gas cost and Utilizing CALL rationale, lines 150-154 and 326-334 The exact gas cost is TBD, while the selected 2300-gas stipend is intended to permit a fixed rather than dynamic precompile cost.
Confidence: Medium
Uncertainty: Because the gas schedule is TBD and the exponential calculation has variable work, a finalized dynamic gas cost would make this a score-2 complex precompile.
Engine API changesUnder-specified1The historical design implies one new payload field carrying the exits list across the execution/consensus interface. With no endpoint or additional API fields specified, the conservative score-1 anchor is best supported.
  • eip.md · Consensus layer sketch, lines 283-292 ExecutionLayerExit values are specified to appear in ExecutionPayload as a bounded SSZ list.
  • eip.md · Rationale / Exits inside of the block, lines 361-365 The exits must be embedded in the shared execution-payload data structure so consensus processing does not require a synchronous execution-layer call.
Confidence: Low
Uncertainty: The Engine API is not named and endpoint coverage is absent; carrying the payload field through multiple directives could raise this to score 2.
Cross-EIP interactionsUnder-specified1The selected design has a limited, non-critical interaction with EIP-1559 by adapting its fee-adjustment pattern, and can test its exit-fee state independently. EIP-4788 is an explicitly rejected alternative rather than a dependency. This supports score 1.
  • eip.md · Stateful precompile and Rate limiting rationales, lines 302-306 and 336-357 The exit fee deliberately reuses an EIP-1559-style self-correcting fee pattern, while keeping its own state inside the new precompile.
  • supporting/eip-1559.md · Abstract and Specification, lines 16-24 and 152-195 EIP-1559 defines the referenced block-to-block fee adjustment pattern based on prior usage relative to a target.
  • eip.md · Rate limiting using exit fee, lines 340-344 The alternative proof-based design would require EIP-4788, but the selected economic design explicitly avoids that dependency and its cross-layer proof complexity.
Confidence: Medium
Uncertainty: The consensus sketch also names existing voluntary-exit and deposit processing without identifying corresponding EIP numbers or defining the exact coupling.
Interacting EIPs: EIP-1559
Show 11 zero-score criteria
Zero-score criteria (Checklist revision 2)
CriterionScoreWhy this scoreEvidence / uncertainty
Added opcodes0No opcode is added by the selected proposal.
  • eip.md · Validator Exit precompile and Stateful precompile rationale, lines 75-86 and 296-304 The selected design exposes behavior at a precompile address through CALL; an opcode is mentioned only as an unselected alternative design.
Modified opcodes0Adding a precompile reachable through CALL is scored under added precompiles; it does not constitute a modification of the CALL opcode itself under this anchor.
  • eip.md · Validator Exit precompile, lines 75-86 Existing CALL dispatches to a newly allocated precompile address, but no existing opcode's general result semantics are redefined or deprecated.
Modified precompiles0No pre-existing precompile is modified.
  • eip.md · Abstract and Stateful precompile rationale, lines 13-17 and 296-304 The EIP introduces a new precompile and compares alternative placements; it does not alter any existing precompile's gas schedule or behavior.
Modified system contracts0All specified contract-like behavior belongs to the newly added precompile, so no pre-existing system contract is directly or indirectly modified.
  • eip.md · Abstract and Stateful precompile rationale, lines 13-17 and 296-304 The mechanism is introduced at a new configurable precompile address; the text does not alter the code or state of any pre-existing system contract.
Uncertainty: The address is TBD, but the proposal consistently describes the precompile as new.
Blob gas accounting changes0No blob gas accounting mechanism is introduced or changed. The isolated use of the phrase "blob gas price" in the parameter discussion does not change the formulas, variables, or surrounding specification from exit-fee accounting.
  • eip.md · Rationale / Exit fee update rule, lines 350-359 The described exponential rule computes an exit fee from excess exits; it does not modify blob-gas usage, targets, reservoirs, or charging.
Uncertainty: Line 359 says "blob gas price," but in context this appears to be an unresolved drafting error rather than a specified blob-gas change.
State gas accounting changes0Persistent writes are introduced, but the rubric scores a distinct state-gas accounting regime rather than the mere fact of writing state. None is specified.
  • eip.md · Validator Exit precompile / queue helpers, lines 108-147 The new precompile uses ordinary SLOAD/SSTORE-style state operations and a precompile gas cost, without defining a separate state-gas budget, reservoir, rate, or spill path.
Uncertainty: The ordinary EVM/precompile gas cost is TBD, but no text suggests a separate state-gas mechanism.
New EVM gas refund0Returning excess fee payment in ETH is a value transfer, not a new EVM gas-refund mechanism, so the gas-refund anchor is not triggered.
  • eip.md · Validator Exit precompile / return_excess_payment, lines 121-125 Excess ETH paid above the exit fee is sent back through a value-bearing CALL; no unused-gas refund or refund counter is created.
New transaction types0The proposal adds a call target and a block operation, not a transaction type.
  • eip.md · Validator Exit precompile, lines 75-86 Users trigger exits by sending an ordinary CALL with value and a 48-byte input; no transaction envelope or transaction type is introduced.
New or modified transaction validity mechanisms0Exit-fee validation is execution behavior inside a call, not a transaction validity rule, and no existing transaction type is otherwise modified.
  • eip.md · Validator Exit precompile / check_exit_fee, lines 79-106 Insufficient exit payment makes execution of the precompile call fail; the text does not change transaction-envelope validity or intrinsic gas calculation.
New fork activation mechanism0Recognizing a new precompile and initializing its new zero-valued variables does not meet this anchor's requirement for a special modification of state or an internal variable at activation.
  • eip.md · Definitions and Per-block precompile storage calculations, lines 53-57 and 228-280 The fork is activated by timestamp, after which the same queue and fee update is run at the end of every block; no one-time migration or pre-existing state mutation is specified for the activation block.
Uncertainty: The precompile address is TBD and collision handling is absent, but no activation migration is specified in the historical text.
Cryptography0The proposal uses existing encoding and trie commitment machinery and introduces no cryptographic mechanism to implement or test.
  • eip.md · Exit operation and Block structure, lines 61-73 and 171-179 Exit data is RLP encoded and committed with the existing indexed-data trie-root construction; the validator public key is carried as opaque bytes.
  • eip.md · Consensus layer sketch, lines 283-292 The sketch adds exit processing but specifies no new signature, proof system, hash function, or other cryptographic primitive.
Uncertainty: The consensus-layer validation rules are incomplete, but the selected text does not specify any cryptographic verification.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@28cbb0162f EIPS/eip-7002.md committed 2023-06-29 · information cutoff 2024-01-18
Current master · File history · blob d3249f6388 · sha256 acf1880b4186
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/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7002.yaml · sha256 7b9aac068cf4
Supporting documents in the sealed package
supporting/eip-1559.md, supporting/eip-4788.md
Compare EIP-7002 with other assessmentsAll Prague / Pectra 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.