Retrospective LLM-Based Complexity Evaluations

EIP complexity assessment

EIP-8148: Custom sweep threshold for validators

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, consensus
LLM Completescore 27
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. Assessment of the sealed Draft EIP-8148 snapshot, limited to its execution-layer surface: the new EIP-7685 request type, stateful request predeploy, transaction-call paths, fee and queue processing, mandatory post-block system call, request encoding, and execution-block validity effects. Consensus-layer threshold storage, deposit interpretation, validator validation, and withdrawal processing are boundary context only and are not scored.

27HighHigh
Evaluator
LLMChecklist v2
Confidence
Medium
Under-specified at assessment cutoff
Yes — 1 criterion affected
Plausible range
26–27 (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. Encoding changes (RLP/SSZ)3
  2. New fork activation mechanism3
  3. Patterns affecting pre-existing tests3
  4. Security risks3

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: The predeploy address and its synthetic deployment transaction, sender, and resulting address remain TBD. This is one localized deployment/activation gap: it blocks exact test baselines but is not counted again as added-contract, fork-activation, or security complexity.

Plausible total

26–27
recorded score 27 · plausible tiers High

Unresolved questions at the cutoff (2)
  • What exact value replaces SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS?
  • What exact signed synthetic deployment transaction, sender, and address establish the required code and inhibitor storage before FORK_BLOCK?
Notable ambiguities noted by the assessor (2)
  • The request prose says threshold is returned little-endian, while add-call input is big-endian and the pseudocode stores and slices the packed value without an explicit byte-to-uint conversion; the supplied bytecode appears intended to perform the output byte reversal, but the pseudocode notation is not independently explicit.
  • SYSTEM_TRANSACTION_GAS is named in the system-call text but not listed in the EIP-8148 constants table; its numeric value of 30,000,000 is nevertheless explicit.

Criterion breakdown

EIP-8148 Hegotá: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
Encoding changes (RLP/SSZ)3A new SSZ-encoded request payload is introduced at the block/interface request layer, meeting the rubric's binary score-3 condition.
  • eip.md · Specification > Execution layer > Set sweep threshold request A new fixed-field request containing Bytes20, Bytes48, and uint64 is introduced, with the threshold returned little-endian.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call The system call returns concatenated SSZ-serialized requests which become EIP-7685 block request data in exact dequeue order.
Confidence: High
Uncertainty: The outer EIP-7685 envelope is unchanged, but the new type's payload encoding is consensus-visible block/interface data.
New fork activation mechanism3The activation block performs a new mandatory state transition in the predeploy, satisfying the rubric's binary score-3 condition.
  • eip.md · Specification > Execution layer > Definitions FORK_BLOCK is the first block after activation.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call Starting at FORK_BLOCK, the mandatory call updates queue state, converts the EXCESS_INHIBITOR path to ordinary excess state, and resets the per-block count.
Confidence: High
Uncertainty: The exact predeploy address and deployment transaction are TBD, but the fork-block state-changing call is explicit.
Patterns affecting pre-existing tests3Existing post-fork block/state-transition cases across transaction, gas-boundary, invalid-block, and synchronization categories must incorporate the mandatory call, predeploy state, and request output, so a diverse major subset is reworked.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call Every execution block from FORK_BLOCK performs an additional stateful system call after all transactions, and missing code or call failure invalidates the block.
  • eip.md · Backwards Compatibility The proposal states that it makes backwards-incompatible changes to block structure and block validation rules.
Confidence: Medium
Uncertainty: The package contains no test inventory, so the exact fraction of pre-existing vectors is uncertain even though the every-block transition is explicit.
Security risks3The mechanism spans transaction execution, persistent queue/fee state, mandatory privileged execution, block validity, and EIP-7685 request commitments. Failure can affect chain liveness and cross-layer integrity, so multiple critical components need extensive review and fuzzing.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call Transaction-populated state feeds a mandatory gas-exempt system call; missing code, out-of-gas, or any call error makes the entire block invalid, and emitted bytes are committed as ordered cross-layer requests.
  • eip.md · Security Considerations Fee-overpayment, system-call-failure, and empty-code risks are delegated to the analogous EIP-7002 analysis.
  • supporting/eip-7002.md · Security Considerations > System Call failure An offending transaction can cause repeated invalid-block attempts through a failed system call, requiring producer or mempool mitigation.
Confidence: High
Uncertainty: Consensus-layer authorization and threshold effects are excluded; score 3 is supported by execution-layer block-validity and liveness exposure alone.
Edge/boundary conditions3Multiple independent boundary-prone mechanisms combine: calldata length and value, dynamic fee/inhibitor arithmetic, queue head-tail arithmetic and reset, the 16-request cap, endian packing, fork-first-call behavior, and fatal system-call outcomes. The cross-product requires an elevated case count.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract The contract distinguishes exactly 56-byte input, zero-byte fee reads, and the system caller; it checks fee sufficiency and special call-value conditions.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call Queue processing spans empty, partially drained, and fully drained states, caps dequeue at 16, updates excess around a target of 2, handles the inhibitor, resets counts, and invalidates blocks on missing code or failure.
Confidence: High
Uncertainty: Exact deployment artifacts are TBD, but the specified boundary set already meets score 3.
Cross-EIP interactions3EIP-8148 strongly depends on 7251 for compounding-validator semantics and on 7685 for transport and commitment. It coexists with the 7002 and 7251 request predeploys and has explicit gas-semantic exceptions for 1559 and 7825. These five interactions span request ordering/hash, end-of-block execution, gas rules, and validator-request semantics, requiring coordinated cross-EIP tests. Five interacting EIPs do not reach the rubric's first +1 threshold, which starts at six.
  • eip.md · Front matter > requires The proposal normatively requires EIP-7251 and EIP-7685.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call The new call is explicitly exempted from EIP-7825 and EIP-1559 behavior and aligns with EIP-7002 system-call behavior.
  • supporting/eip-7685.md · Specification > Execution Layer > Block Header Requests from all types share ordered request hashing, requiring mixed type 0x01, 0x02, and 0x03 cases.
Confidence: High
Uncertainty: EIP-7002 is partly a design analogue, but mixed request ordering and shared system-call processing make its interaction test-relevant.
Interacting EIPs: EIP-1559, EIP-7002, EIP-7251, EIP-7685, EIP-7825
Added system contracts2Exactly one new system contract is introduced, and it is both stateful and triggers a new execution-to-consensus request action.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract A new predeploy stores queue entries, queue pointers, per-block count, and excess, and emits dequeued requests for consensus-layer processing through a system call.
Confidence: High
Uncertainty: The address and deployment transaction are TBD, but the contract's stateful role is unambiguous.
New invariant on pre-existing tests2A broad set of post-fork request-aware vectors gains mechanical expected-output and commitment checks for type 0x03. The stable empty-request hash prevents this from forcing a new non-empty assertion in every test or re-deriving pre-fork vectors.
  • eip.md · Specification > Execution layer > Set sweep threshold request Dequeued requests must be emitted as type 0x03 request data, with threshold encoded little-endian.
  • supporting/eip-7685.md · Specification > Execution Layer > Block Header All non-empty request objects are ordered by request type and committed through requests_hash, while empty request data is excluded.
Confidence: Medium
Uncertainty: The sealed package does not describe the test harness, so whether all broad request assertions are already generic is not established.
Performance risks2Contract paths can be benchmarked individually, but block-wide cost includes mandatory execution, state-dependent fee work, request serialization, and interaction with transaction-populated queue state. The dequeue cap bounds the expected impact, making it limited rather than substantial.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call Every block executes a new gas-exempt system call with a dedicated 30,000,000 gas limit and invalidates the block if it fails.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Fee calculation Fee computation uses a state-dependent fake-exponential loop, while dequeue processing is capped at 16 requests per block.
Confidence: Medium
Uncertainty: The package supplies no benchmark or bound on fake_exponential iterations under reachable excess values.
Unspecified behavior requiring cross-client consensusUnder-specified2Clients cannot baseline activation, call-target, empty-code, or deployment-state tests until the exact predeploy and deployment artifacts are agreed. The gap is material but localized, and it does not expose a previously unobservable legacy behavior.
  • eip.md · Specification > Constants > Execution layer SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS is explicitly TBD.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Deployment The deployment transaction JSON, sender, and resulting address are all TBD.
Confidence: High
Uncertainty: The behavioral contract is otherwise detailed; remaining agreement is concentrated in deployment and activation identity.
EVM Gas rule changes1EIP-8148 extends an existing special system-call gas-accounting pattern to one new mandatory call. This updates the set of calls using the existing mechanism rather than creating a distinct gas-accounting mechanism.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call The new system call has a dedicated 30,000,000 gas limit; its gas is excluded from block gas accounting and block gas-limit checks, it transfers no value under EIP-1559 semantics, and it is exempt from the EIP-7825 transaction cap.
  • supporting/eip-7002.md · Specification > Execution layer > Withdrawal Request Contract > System Call The sealed baseline already defines the same dedicated, block-excluded gas treatment for an existing request-predeploy system call.
Confidence: Medium
Uncertainty: The gas exclusions are explicit, but the rubric does not state whether another instance of an existing system-call pattern should be treated as a mechanism update or a new mechanism.
Show 17 zero-score criteria
Zero-score criteria (Checklist revision 2)
CriterionScoreWhy this scoreEvidence / uncertainty
Added opcodes0EIP-8148 adds contract code, not an opcode.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Bytecode The supplied contract bytecode is composed of existing EVM instructions and assigns no new opcode.
Uncertainty: No opcode addition is specified.
Modified opcodes0No pre-existing opcode behavior is modified or deprecated.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Bytecode The proposal uses CALLER, SLOAD, SSTORE, calldata, memory, and control-flow operations without redefining their results.
Uncertainty: System-call gas treatment is scored under gas rules and does not change an opcode result.
Added precompiles0No precompile is introduced.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Deployment The new component is explicitly deployed like a smart contract, not defined as a precompile.
Uncertainty: The deployment details are incomplete but the component type is explicit.
Modified precompiles0No precompile logic or gas schedule is modified.
  • eip.md · Specification > Execution layer The specified execution changes concern a new smart contract and system call and identify no existing precompile.
Uncertainty: No precompile interaction is specified in the package.
Modified system contracts0Adding an independent request producer does not directly or indirectly modify an existing system contract's behavior.
  • eip.md · Specification > Constants > Execution layer The proposal allocates a distinct new predeploy and distinct storage slots for its request mechanism; it does not alter the code or state layout of an existing predeploy.
  • supporting/eip-7685.md · Specification > Execution Layer > Requests Different request types coexist as separate opaque request objects in the existing bus.
Uncertainty: Cross-type request ordering changes the aggregate request list, but not the behavior of the pre-existing contracts themselves.
State-access ordering within opcode execution0Contract-level SLOAD and SSTORE sequencing is new program behavior, not a change to the consensus semantics or internal state-access ordering of any opcode.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Bytecode The proposal supplies bytecode for a new contract using existing EVM operations; it specifies no change to state access or gas-charge ordering inside an opcode.
Uncertainty: No package evidence indicates an opcode-internal ordering change.
Blob gas accounting changes0The execution-layer proposal does not alter blob gas accounting.
  • eip.md · Specification > Constants > Execution layer The constants define request-queue, fee, and system-contract parameters and no blob gas parameter or blob gas rule.
Uncertainty: No blob mechanism appears in any specified EIP-8148 execution path.
State gas accounting changes0Persistent contract storage is introduced, but no state-gas accounting rule is changed.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract The contract performs ordinary EVM storage reads and writes for its queue, count, and excess value; it defines no StateGasCosts, state-byte rate, state budget, or spill path.
Uncertainty: No rubric-defined state-gas mechanism is specified in the package.
New EVM gas refund0The request fee is value paid to a contract, not an EVM gas-refund mechanism.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Add Set Sweep Threshold Request The call only requires msg.value to cover the dynamic request fee and specifies no EVM gas refund or modification to refund accounting.
Uncertainty: No refund behavior is introduced by the execution-layer specification.
New transaction types0The request type is an EIP-7685 request type, not a new transaction type.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > Add Set Sweep Threshold Request Users submit requests by calling the predeploy with calldata and value; no transaction envelope or type byte is defined.
Uncertainty: No transaction-format change is specified.
New or modified transaction validity mechanisms0Contract-call success rules and system-call validity do not modify transaction validity or intrinsic gas calculation.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract Invalid calldata or insufficient value causes contract execution to revert; no existing transaction's protocol validity or intrinsic gas is changed.
  • eip.md · Specification > Execution layer > Set sweep threshold request contract > System Call The EIP-7825 exemption applies to the protocol system call, not to user transactions.
Uncertainty: No txpool or transaction-envelope validation change appears in EIP-8148.
New block / header fields0No new execution-layer block/header field is introduced by this EIP.
  • supporting/eip-7685.md · Specification > Execution Layer > Block Header The existing EIP-7685 framework already supplies requests_hash for request objects.
  • eip.md · Specification > Execution layer > Set sweep threshold request EIP-8148 adds a type within that request list and specifies no new execution block or header field.
Uncertainty: Consensus-layer container changes are outside the required execution-layer scoring scope.
Block syncing changes0The proposal changes block validity through request processing, but not the rubric-specific block RLP validation mechanism.
  • supporting/eip-7685.md · Motivation The general request framework is designed so adding request types does not update the execution block structure.
  • eip.md · Specification > Execution layer > Set sweep threshold request EIP-8148 uses the existing request object and specifies no new block RLP validation mechanism.
Uncertainty: No RLP change is present in the sealed EIP-8148 execution specification.
Engine API changes0No new Engine API field, endpoint, or communication mechanism is specified.
  • supporting/eip-7685.md · Specification > Execution Layer > Requests The existing interface-level object carries a request-type byte plus opaque request data.
  • eip.md · Specification > Execution layer > Set sweep threshold request The proposal defines type 0x03 within that existing object and adds no Engine API endpoint or field.
Uncertainty: Engine API mechanics are not discussed in EIP-8148, so the zero rests on the sealed generic EIP-7685 carrier.
Transition-tool interface changes0The existing EIP-7685 request mechanism can carry type 0x03 without a specified tool-interface change.
  • supporting/eip-7685.md · Abstract The existing general-purpose request bus abstracts request details so new request types do not require an execution block-structure update.
  • eip.md · Specification > Execution layer > Set sweep threshold request EIP-8148 adds one request type and opaque request data but specifies no transition-tool field.
Uncertainty: The EIP does not describe transition-tool integration explicitly.
New test-framework primitives0Existing request-contract and state-transition test primitives are sufficient for the analogous new type.
  • eip.md · Rationale > Overview The message format, queue, and rate limiting deliberately follow the existing EIP-7002 request mechanism.
  • supporting/eip-7002.md · Specification > Execution layer > Withdrawal Request Contract The sealed supporting EIP already supplies the analogous add, fee-getter, queue, and system-process testing shape.
Uncertainty: The package does not enumerate available framework helpers, but it specifies no novel expectation type or modifier.
Cryptography0No new or modified cryptographic mechanism is part of EIP-8148's execution-layer behavior.
  • eip.md · Specification > Execution layer The execution surface consists of fixed-width request fields, a stateful EVM contract, SSZ serialization, and a system call; it introduces no cryptographic primitive.
Uncertainty: EIP-7685 hashing is an existing framework behavior, not introduced by EIP-8148.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@ac450a4ab2 EIPS/eip-8148.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z
Current master · File history · blob 5de8327f93 · sha256 5c362a259138
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-8148.yaml · sha256 0ef82fc7342b
Supporting documents in the sealed package
supporting/eip-1559.md, supporting/eip-7002.md, supporting/eip-7251.md, supporting/eip-7685.md, supporting/eip-7825.md
Compare EIP-8148 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.