EIP complexity assessment

EIP-7976: Increase Calldata Floor Cost

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

RetrospectiveAmsterdam / GlamsterdamAssessment cutoff 2025-09-03Included by cutoffLayers: execution

LLM Completescore 10

Human Completescore 5 · Checklist revision 1· merged checklist

LLM · Checklist revision 22026-08-25 · Primary study score · 10 LLM · Checklist revision 12026-08-25 · Re-run for the human comparison · 12 Human · Checklist revision 1Complete · 5 CompareHuman vs LLM · same checklist revision

Evaluated on: 2026-08-25 · Spec revision: 2025-09-03 · c582d21e50

Scope at the cutoff. At the information cutoff, EIP-7976 was a draft execution-layer proposal to raise EIP-7623's existing calldata floor from 10/40 to 15/60 gas per zero/non-zero byte for data-heavy transactions. It retained the existing max-based transaction gas-used formula, including EIP-3860's initcode term, and raised the corresponding minimum gas-limit validity threshold while leaving EVM-heavy transactions on standard calldata pricing.

10LowLow

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: Yes — 1 criterion affected
Plausible range: 9–10 (Low)
Assessment cutoff: 2025-09-03 · EIP revision c582d21e50 (2025-09-03)

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

New or modified transaction validity mechanisms2
Performance risks2
Cross-EIP interactions2
EVM Gas rule changes1

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 specification's equation and test guidance require final transaction gasUsed to meet the calldata floor, but the adjacent prose says valid cases can have gasUsed below the floor. The likely intended distinction is between pre-floor execution consumption and final charged gas, but that distinction is not stated explicitly.

Plausible total

9–10
recorded score 10 · plausible tiers Low

Affected criteria (1)

Unspecified behavior requiring cross-client consensus (1)

Unresolved questions at the cutoff (1)

Does final tx.gasUsed always include the floor as the equation and test case state, with only pre-floor execution consumption allowed below it, or is the floor intended solely as a gas-limit reservation in some valid cases?

Notable ambiguities noted by the assessor (1)

Specification line 58 uses gasUsed in a way that conflicts with the preceding max-based tx.gasUsed equation; the primary score follows the equation and test guidance while recording the ambiguity as under-specification.

Criterion breakdown

EIP-7976 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
New or modified transaction validity mechanisms	2	The existing validity threshold is materially raised and existing boundary vectors must change, but updates are localized and need no test-framework redesign, matching score 2.	eip.md · Specification, lines 43-58 A transaction is invalid when its gas limit is below the greater of the raised calldata-floor requirement and its intrinsic gas cost. eip.md · Test Cases, lines 84-92 The requested coverage includes the new equality boundary and rejection of transactions whose gas limit is insufficient under the raised floor. Confidence: High
Performance risks	2	Validating the claimed block-level payload and variance effect cannot be fully reduced to a transaction microbenchmark, but it has limited scope in existing performance behavior because it targets data-heavy transactions; this matches score 2.	eip.md · Motivation and Rationale, lines 18-26 and 62-70 The repricing is intended to reduce the maximum data-heavy payload by about one third and reduce block-size variance while permitting gas-limit headroom. Confidence: Medium Uncertainty: The package quantifies the payload-size bound but supplies no benchmark plan for propagation, processing, or mixed block workloads.
Cross-EIP interactions	2	The proposal directly modifies EIP-7623 and must preserve EIP-3860 creation accounting in coordinated boundary tests, but these interactions are explicit and limited in scope, matching score 2.	eip.md · Front matter and Specification, lines 1-12 and 41-58 EIP-7976 formally requires EIP-7623, changes its floor formula, and uses EIP-3860's INITCODE_WORD_COST in the contract-creation branch. supporting/eip-3860.md · Specification, lines 42-60 EIP-3860 defines the value and intrinsic-cost treatment of the initcode term incorporated by the EIP-7976 creation-transaction calculation. supporting/eip-7623.md · Specification, lines 26-67 EIP-7623 defines the pre-existing floor mechanism and its validity rule, including the EIP-3860 creation-cost term, with the earlier value of 10. Confidence: High Interacting EIPs: EIP-3860, EIP-7623
EVM Gas rule changes	1	This is an update to an existing transaction gas-accounting mechanism, not a new accounting mechanism, matching score 1.	eip.md · Specification, lines 30-58 The proposal changes TOTAL_COST_FLOOR_PER_TOKEN to 15 and applies it in the existing EIP-7623 max-based transaction gas-used and gas-limit rules. Confidence: High
Patterns affecting pre-existing tests	1	Existing tests around the EIP-7623 calldata floor need localized expected value and boundary updates, a minor subset matching score 1.	eip.md · Test Cases, lines 84-92 Tests must cover data-heavy and EVM-heavy transactions, the floor boundary, gas estimation, and rejection below the raised threshold. supporting/eip-7623.md · Specification, lines 52-67 EIP-7623 already defines the same formula and validity rule with a floor value of 10, whose threshold expectations EIP-7976 changes. Confidence: Medium Uncertainty: The sealed package does not enumerate the pre-existing test corpus, so the exact number of affected vectors is not stated.
Edge/boundary conditions	1	The adjusted max-based floor is one boundary-prone mechanism, including its validity threshold, matching score 1.	eip.md · Specification and Test Cases, lines 43-58 and 84-92 The max selects between ordinary computation-inclusive cost and the calldata floor, and the EIP explicitly calls for equality-boundary and insufficient-gas-limit cases. Confidence: High
Unspecified behavior requiring cross-client consensusUnder-specified	1	The inconsistent use of gasUsed leaves a localized wording ambiguity, but the equation and test guidance make the intended floor-charging behavior obvious enough to match score 1 rather than requiring broad coordination.	eip.md · Specification, lines 43-58 The equation floors tx.gasUsed through max, while the following validity paragraph says there are valid cases where gasUsed is below that floor. eip.md · Test Cases, lines 84-92 The test guidance says data-heavy transactions pay the floor and asks for boundary and insufficient-limit coverage, supporting the equation's apparent intended reading. Confidence: Medium Uncertainty: The text does not explicitly distinguish raw execution consumption from final transaction gasUsed when describing cases below the reserved floor.

Show 21 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No new opcode is introduced, so the score is 0.	eip.md · Specification, lines 28-58 The proposal defines no opcode and changes only transaction-level gas accounting and validity.
Modified opcodes	No opcode result or behavior is modified; transaction gas repricing alone does not trigger this anchor, so the score is 0.	eip.md · Specification, lines 35-58 The formula treats EVM execution gas as an input but specifies no change to any existing opcode's non-gas behavior.
Added precompiles	No precompile is introduced, so the score is 0.	eip.md · Specification, lines 28-58 The specified transaction formula introduces no precompile address or callable function.
Modified precompiles	No precompile behavior or gas schedule is modified, so the score is 0.	eip.md · Specification, lines 28-58 No existing precompile or precompile gas schedule appears in the proposed calldata floor change.
Added system contracts	No system contract is introduced, so the score is 0.	eip.md · Specification, lines 28-58 The complete specified mechanism is transaction gas arithmetic and does not introduce a contract address, code, state, or system action.
Modified system contracts	The proposal has no direct or identified indirect effect on a pre-existing system contract, so the score is 0.	eip.md · Specification, lines 28-58 No existing system contract code, state, or behavior is named or changed by the transaction-level calldata floor adjustment.
State-access ordering within opcode execution	The proposal does not move state access or gas charging relative to state access within any opcode, so the score is 0.	eip.md · Specification, lines 35-58 All specified changes concern transaction calldata accounting and a transaction gas-limit validity threshold; no opcode state access appears.
Blob gas accounting changes	An economic incentive to use blobs is not a change to blob gas accounting; the anchor therefore scores 0.	eip.md · Rationale, lines 62-70 The proposal describes migration toward blobs only as an incentive resulting from higher calldata cost and specifies no blob-gas rule.
State gas accounting changes	No state-gas cost, charging site, budget, reservoir, or spill rule changes, so the score is 0.	eip.md · Specification, lines 30-58 The formula adjusts calldata-related execution gas usage and transaction validity without defining any charge for writing state or a state budget.
New EVM gas refund	Referring to the already-subtracted refund in an input does not introduce a new gas-refund mechanism, so the score is 0.	eip.md · Specification, lines 35-55 The formula consumes execution_gas_used after an existing refund has been subtracted but introduces no refund trigger, amount, or mechanism.
New transaction types	No transaction type is introduced, so the score is 0.	eip.md · Specification, lines 35-58 The rules apply a revised calculation to transactions generally and do not define a new typed transaction or envelope.
New block / header fields	No new block or header field is introduced, so the score is 0.	eip.md · Specification, lines 28-58 The specification changes transaction gas calculations and adds no block body or header field.
Encoding changes (RLP/SSZ)	Repricing encoded data is not an encoding-format change, so the score is 0.	eip.md · Specification, lines 28-58 Existing calldata bytes are counted for gas purposes without changing transaction, block, or interface serialization.
Block syncing changes	No RLP validation mechanism requiring sync testing is introduced, so the score is 0.	eip.md · Specification, lines 28-58 The change is a transaction gas formula and validity threshold; it adds no block field, RLP element, or block-RLP validation rule.
New fork activation mechanism	Fork scheduling alone is not the activation mechanism scored by this anchor, so the score is 0.	eip.md · Backwards Compatibility, lines 72-80 The repricing requires a scheduled network upgrade, but the text defines no activation-block state mutation or internal-variable modification.
Engine API changes	JSON-RPC gas estimation is not an Engine API schema change, so the score is 0.	eip.md · Backwards Compatibility, lines 72-82 The proposal calls for eth_estimateGas updates but specifies no Engine API endpoint, field, or communication mechanism.
Transition-tool interface changes	No transition-tool interface field or mechanism is specified, so the score is 0.	eip.md · Backwards Compatibility, lines 72-82 The only named interface handling change is to wallet and node gas estimation through eth_estimateGas; no transition-tool field is added.
New invariant on pre-existing tests	The proposal changes expected results in relevant tests but does not require tests unrelated to this EIP to assert a new output, so the score is 0.	eip.md · Test Cases, lines 84-92 The requested assertions are confined to tests of the calldata floor, its branch boundary, estimation, and insufficient-gas rejection.
New test-framework primitives	The listed cases can be expressed with existing transaction and gas assertions; no framework primitive is required, so the score is 0.	eip.md · Test Cases, lines 84-92 The prescribed cases are ordinary transaction gas-use, boundary, estimation, and invalidity checks, with no new expectation abstraction.
Security risks	The constant increase does not add a security-sensitive mechanism or alter an identified security invariant, so the score is 0.	eip.md · Security Considerations, lines 94-104 The EIP states that the lower maximum block size adds no concern beyond EIP-7623, bundling does not defeat the objective, and no new attack vector is introduced.
Cryptography	No cryptography is added or modified, so the score is 0.	eip.md · Specification, lines 28-58 The specification consists of byte counting and integer gas arithmetic and introduces no cryptographic operation or construction.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@c582d21e50 EIPS/eip-7976.md committed 2025-09-03 · information cutoff 2025-09-03T20:52:20Z
Current master · File history · blob 4d5904c246 · sha256 0785ed008ee2
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/amsterdam/eip-7976.yaml · sha256 0b6bcc06f544
Supporting documents in the sealed package: supporting/eip-3860.md, supporting/eip-7623.md

Evaluated on: 2026-08-25 · Spec revision: 2025-09-03 · c582d21e50

Scope at the cutoff. At the sealed historical cutoff, Draft EIP-7976 raises EIP-7623's calldata floor from 10/40 to 15/60 gas per zero/non-zero byte by changing `TOTAL_COST_FLOOR_PER_TOKEN` from 10 to 15. It retains the existing max-based transaction gas-used mechanism, updates the minimum gas-limit validity threshold, and targets lower worst-case execution-payload size while leaving EVM-heavy transactions on standard calldata pricing.

12MediumMedium

Evaluator: LLMChecklist v1
Confidence: Medium
Under-specified at assessment cutoff: Yes — 4 criteria affected
Plausible range: 9–14 (Low–Medium)
Assessment cutoff: 2025-09-03 · EIP revision c582d21e50 (2025-09-03)

Score bands · Checklist revision 1

Low <10
Medium 10–19
High ≥20

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

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

New or modified transaction validity mechanisms2
Security risks2
Performance risks2
Edge/boundary conditions2

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 core constant and formulas are clear, but the draft provides categories rather than concrete numeric vectors, does not quantify the pre-existing test set or enumerate transaction-type/creation-path coverage, and gives approximate performance outcomes without a benchmark method. The Rationale also contains the apparent malformed literal `45s_000_000/40`. These omissions principally limit confidence in test breadth, boundary coverage, and performance validation rather than the basic gas-rule classification.

Plausible total

9–14
recorded score 12 · plausible tiers Low, Medium

Affected criteria (4)

New or modified transaction validity mechanisms (2)
Patterns affecting pre-existing tests (1)
Performance risks (2)
Edge/boundary conditions (2)

Unresolved questions at the cutoff (3)

What exact before/after vectors cover zero-byte, non-zero-byte, mixed-calldata, refund-adjusted, and branch-equality cases?
Which existing transaction types and EIP-7623 tests change validity or expected gas use at the 10-to-15 floor repricing?
What workload and measurement method substantiate the projected block-size and variance effects?

Notable ambiguities noted by the assessor (3)

The historical checklist includes Engine API encoding changes but supplies no dedicated definition; that row is conservatively scored from its label with low confidence.
The EIP gives test categories but no concrete expected-value vectors or inventory of pre-existing tests, leaving the exact regression breadth uncertain.
The Rationale's `45s_000_000/40` literal appears malformed; the surrounding prose indicates an approximate payload-size calculation, but the sealed evidence does not correct it.

Criterion breakdown

EIP-7976 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
New or modified transaction validity mechanismsUnder-specified	2	Raising the floor changes the validity threshold for existing transactions and therefore changes floor-sensitive validity tests, but the sealed evidence indicates limited expected-value and boundary updates rather than test-infrastructure redesign. This matches score 2. Exceptional score: Not applicable; the score is not 4.	eip.md · Specification — paragraph beginning `Any transaction with a gas limit below` Declares transactions invalid when their gas limit is below the updated floor or intrinsic gas, using the maximum of the two. eip.md · Test Cases — Invalid transactions Requires rejection tests for insufficient gas limits under the updated floor. Confidence: Medium Uncertainty: Concrete before/after validity vectors and transaction-type coverage are not provided, limiting certainty about test volume.
Security risks	2	The repricing is narrow, but it changes existing gas-used and transaction-validity assumptions and touches execution validation and gas estimation. That supports targeted review and boundary fuzzing across a limited component set, matching score 2; the proposal does not support broad critical-component interactions for score 3. Exceptional score: Not applicable; the score is not 4.	eip.md · Specification — gas-used formula and transaction invalidity rule Changes consensus-relevant gas accounting and the minimum gas limit accepted for a transaction. eip.md · Security Considerations Claims no additional security concern beyond EIP-7623 and identifies transaction bundling as an existing, practically limited consideration. Confidence: Medium Uncertainty: The security section is qualitative and supplies no explicit threat model or negative test vectors for inconsistent implementation.
Performance risksUnder-specified	2	The arithmetic can be isolated, but its intended block-size/variance and estimation effects require system-level validation. The impact is confined mainly to floor-bound data-heavy transactions while EVM-heavy behavior is retained, fitting score 2 rather than the substantial or complex-interaction anchor. Exceptional score: Not applicable; the score is not 4.	eip.md · Motivation and Rationale Targets lower maximum block size and variance, estimates a roughly 33% reduction for data-heavy payloads, and preserves pricing for EVM-heavy transactions. eip.md · Backwards Compatibility — gas estimation handling Requires wallet and node gas estimators to incorporate the changed floor. Confidence: Medium Uncertainty: The proposal gives approximate maxima but no benchmark methodology, workload set, or performance acceptance criteria.
Edge/boundary conditionsUnder-specified	2	Two related but distinct boundary-prone mechanisms require coverage: selection between gas-used branches and transaction validity against competing minimums. Neither is shown to need an elevated number of cases, matching score 2. Exceptional score: Not applicable; the score is not 4.	eip.md · Specification — `max(...)` gas-used formula and minimum gas-limit validity rule Creates floor-sensitive boundaries at equality between the standard and floor branches and at the maximum of intrinsic cost and the reserved floor. eip.md · Test Cases — items 2, 3, and 5 Explicitly requests EVM-heavy exemption, equality/crossover, and insufficient-gas-limit cases. Confidence: Medium Uncertainty: No numeric boundary vectors are supplied, and coverage across zero/non-zero calldata and contract creation is not enumerated.
Cross-EIP interactions	2	The proposal directly depends on and modifies EIP-7623 and composes with EIP-3860 for creation transactions. Coordinated boundary and creation testing is required, but the interactions are narrow arithmetic composition rather than complex multi-EIP redesign, matching score 2. Exceptional score: Not applicable; the score is not 4.	eip.md · Front matter `requires: 7623` and Specification Explicitly requires and modifies EIP-7623's floor mechanism while incorporating EIP-3860's initcode word cost for creation transactions. supporting/eip-7623.md · Specification Provides the floor mechanism and validity rule whose parameter EIP-7976 changes. supporting/eip-3860.md · Specification — Parameters and Rules Defines `INITCODE_WORD_COST = 2` and creation-transaction intrinsic cost used by the combined formula. Confidence: High Uncertainty: The proposal does not provide combined numeric vectors for the EIP-7623/EIP-3860 creation path.
EVM Gas rule changes	1	The proposal updates an existing EVM transaction gas-accounting mechanism by repricing its floor parameter; it does not introduce a different accounting mechanism. This matches score 1. Exceptional score: Not applicable; the score is not 4.	eip.md · Specification — parameter table and `tx.gasUsed` formula Sets `TOTAL_COST_FLOOR_PER_TOKEN` to 15 and applies it through the existing maximum of standard execution cost and calldata floor cost. supporting/eip-7623.md · Specification — parameter table and changed `tx.gasUsed` formula Defines the pre-existing floor mechanism with the same formula and a floor parameter of 10. Confidence: High Uncertainty: The arithmetic change is explicit; concrete client/spec pseudocode beyond the formula is not included.
Patterns affecting pre-existing testsUnder-specified	1	The parameter change affects a focused subset of pre-existing tests whose expected gas use or validity is floor-sensitive. The sealed evidence supports a minor, localized subset rather than a considerable or diverse test rewrite, matching score 1. Exceptional score: Not applicable; the score is not 4.	eip.md · Test Cases — items 1–5 Calls for coverage of data-heavy and EVM-heavy transactions, the branch boundary, gas estimation, and insufficient-gas rejection under the new floor. supporting/eip-7623.md · Specification — `TOTAL_COST_FLOOR_PER_TOKEN` and validity threshold Shows that the affected behavior already exists with a floor parameter of 10, so prior floor-sensitive expectations must be repriced. Confidence: Medium Uncertainty: No pre-existing test inventory or concrete vectors are supplied, so the exact number of affected tests cannot be established.

Show 17 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No opcode is introduced; score 0 applies.	eip.md · Specification Changes transaction-level gas arithmetic without defining an opcode. Uncertainty: None material within the sealed proposal.
Modified opcodes	No pre-existing opcode behavior is modified or deprecated, and the row explicitly excludes gas-only changes; score 0 applies.	eip.md · Specification The floor applies to transaction gas used and gas-limit validity; no pre-existing opcode behavior is changed. Uncertainty: Contract-creation cost is an input to the transaction formula, not an opcode behavior change in this proposal.
Added precompiles	No precompile is introduced; score 0 applies.	eip.md · Specification Defines no precompile address, input, output, behavior, or gas schedule. Uncertainty: None material within the sealed proposal.
Modified precompiles	No pre-existing precompile is modified; score 0 applies.	eip.md · Specification Only the transaction calldata floor parameter and related formulas are changed; no precompile logic or gas schedule is mentioned. Uncertainty: None material within the sealed proposal.
Added system contracts	No system contract is introduced; score 0 applies.	eip.md · Specification Defines constants and transaction gas formulas only; it does not deploy or invoke a new system contract. Uncertainty: None material within the sealed proposal.
Modified system contracts	No direct or discernible indirect modification of a pre-existing system contract is specified; score 0 applies.	eip.md · Specification The normative change is confined to transaction calldata floor accounting and validity, with no system-contract code, state, or action identified. Uncertainty: Generic transactions involving system contracts are not identified as a distinct interaction.
Blob gas accounting changes	No blob gas accounting mechanism is added or modified, so the row scores 0.	eip.md · Specification and Rationale — calldata floor formula and Better blob incentivization The normative change prices transaction calldata; blobs appear only as an incentive rationale, with no blob-gas rule specified. Uncertainty: The proposal may indirectly encourage blob use, but an economic incentive is not a blob gas accounting change.
New EVM gas refund	Referencing refund-adjusted execution gas does not introduce a gas-refund mechanism; score 0 applies.	eip.md · Specification — definition of `execution_gas_used` and `tx.gasUsed` formula Uses execution gas after subtracting an existing refund in the floor calculation but specifies no new refund rule. Uncertainty: Refund behavior at the floor crossover is not illustrated with vectors, but no new refund is specified.
New transaction types	No new transaction type is introduced; score 0 applies.	eip.md · Specification — transaction gas-used and gas-limit rules Applies rules to transactions generically and defines no new transaction envelope or type. Uncertainty: The proposal does not enumerate existing typed-transaction coverage, but it does not define a new type.
New block / header fields	No new block or block-header field is introduced; score 0 applies.	eip.md · Specification Defines transaction-local gas calculations and no block or header field. Uncertainty: The stated payload-size reduction changes possible contents, not header structure.
Encoding changes (RLP/SSZ)	No RLP, SSZ, transaction, block, or interface encoding change is introduced; score 0 applies.	eip.md · Specification Reprices calldata through gas arithmetic while leaving transaction, block, and interface encodings unspecified and unchanged. Uncertainty: Payload-size effects do not themselves alter payload encoding.
Block syncing changes	No new block RLP validation mechanism requiring sync testing is introduced; score 0 applies.	eip.md · Specification Changes transaction gas accounting and gas-limit validity without specifying block RLP validation. Uncertainty: The proposal discusses maximum payload size but not block encoding or sync-validation rules.
New fork activation mechanism	A scheduled ruleset change is required, but the row scores activation-block state or internal-variable modifications; none is specified, so the score is 0.	eip.md · Backwards Compatibility States that the repricing requires a scheduled network upgrade but specifies no activation-block state or internal-variable modification. Uncertainty: The draft does not name an activation point or describe transition handling, but it also defines no new activation mechanism.
Engine API changes	An execution RPC estimation update is not an Engine API field change under the row definition; score 0 applies.	eip.md · Backwards Compatibility — Wallets and Node Software Requires `eth_estimateGas` handling updates but introduces no Engine API endpoint, directive field, or communication mechanism. Uncertainty: No Engine API consequences are described in the sealed sources.
Engine API encoding changes	Because the historical checklist supplies no definition for this row, it is scored conservatively from the label alone. No Engine API encoding change is visible, so the score is 0.	eip.md · Specification and Backwards Compatibility Specifies arithmetic gas-rule and `eth_estimateGas` updates, with no Engine API encoding described. Uncertainty: The source template has no dedicated definition for Engine API encoding changes; no substitute definition was imported.
Transition-tool interface changes	The proposal requires a ruleset update but specifies no transition-tool interface field or new interface mechanism; score 0 applies.	eip.md · Specification and Backwards Compatibility Defines a fork-scheduled gas repricing and calls for wallet/node gas-estimation updates without adding transition-tool input or output fields. Uncertainty: The proposal does not describe a transition-tool mapping, so the conclusion rests on the absence of any specified interface change.
Cryptography	No cryptographic mechanism or cryptographic functionality is introduced or modified; score 0 applies.	eip.md · Specification — calldata token counting and gas-used formula The complete normative mechanism consists of byte counting, integer constants, and gas arithmetic, with no cryptographic operation. Uncertainty: None material within the sealed proposal.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@c582d21e50 EIPS/eip-7976.md committed 2025-09-03 · information cutoff 2025-09-03T20:52:20Z
Current master · File history · blob 4d5904c246 · sha256 0785ed008ee2
Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: gpt-5.6-sol at xhigh reasoning effort · isolation bubblewrap_one_eip_capsule_v1
Source record: Frozen research record research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7976.yaml · sha256 3451bf7d1c3c
Supporting documents in the sealed package: supporting/eip-3860.md, supporting/eip-7623.md

Evaluated on: Not recorded · Spec revision: 2025-11-04 · 173fe4aade

5LowLow

Evaluator: HumanChecklist v1
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2025-11-06 · EIP at 173fe4aade
Source: merged ethspecs/pm checklist

Score bands · Checklist revision 1

Low <10
Medium 10–19
High ≥20

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

Complexity profile

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

Top complexity drivers

New or modified transaction validity mechanisms2
Patterns affecting pre-existing tests2
EVM Gas rule changes1

Criterion breakdown

EIP-7976 Amsterdam / Glamsterdam: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
New or modified transaction validity mechanisms	2	Mechanism affects validity, but we only have to pay attention to the fork transition when the values change, as the rest of the scenarios will be automatically updated by updating a few constants.	—
Patterns affecting pre-existing tests	2	Pattern affects many tests but the test framework is already well prepared for this change due work already done in EIP-7623 testing. However, static tests might break after these change because these have to be manually updated.	—
EVM Gas rule changes	1	Affects an existing mechanism for which tests are already prepared to be automatically updated.	—

Show 21 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Notes
Added opcodes	No rationale recorded.	—
Modified opcodes	No rationale recorded.	—
Added precompiles	No rationale recorded.	—
Modified precompiles	No rationale recorded.	—
Added system contracts	No rationale recorded.	—
Modified system contracts	No rationale recorded.	—
Blob gas accounting changes	No rationale recorded.	—
New EVM gas refund	No rationale recorded.	—
New transaction types	No rationale recorded.	—
New block / header fields	No rationale recorded.	—
Encoding changes (RLP/SSZ)	No rationale recorded.	—
Block syncing changes	No rationale recorded.	—
New fork activation mechanism	No rationale recorded.	—
Engine API changes	No rationale recorded.	—
Engine API encoding changes	No rationale recorded.	—
Transition-tool interface changes	No rationale recorded.	—
Security risks	No rationale recorded.	—
Performance risks	No rationale recorded.	—
Edge/boundary conditions	Contains edge-cases but automatic test generators for these conditions already exist as part of tests for EIP-7623.	—
Cryptography	No rationale recorded.	—
Cross-EIP interactions	No rationale recorded.	—

Assessment provenance

Assessed EIP revision: ethereum/EIPs@173fe4aade EIPS/eip-7976.md committed 2025-11-04
EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.
Current master · File history · blob 7310f62b56 · sha256 34c48660c11f
Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Merged checklist ethspecs/pm@ce4d90eda1 complexity_assessments/EIPs/EIP-7976.md · committed 2025-11-06
blob d3e6776fa9 · sha256 221b4016db2b
Research record: research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7976.yaml · sha256 a2808654dc90

Both assessments applied Checklist revision 1 (24 criteria) to EIP-7976 in Amsterdam / Glamsterdam. Δ is LLM minus Human.

LLM12Medium

Human5Low

Δ total+7Tiers differ: Medium vs Low

Criteria19/24agree exactly · 1 differ by 1 · 4 differ by 2+

Confounded comparison. The human checklist evaluated the EIP as it stood when the checklist was written; the LLM evaluated the sealed historical revision. Input alignment: no substantive drift; human hindsight exposure: high exposure. The study's primary LLM score under checklist revision 2 is 10; it uses a different criterion inventory and thresholds and is not directly comparable to either total here.

Exposure evidence

The assessment says generators were already prepared and refers to work completed during EIP-7623 testing and existing static tests.

Every intervening EIP revision is classified non-substantive by Task 01.

Complexity profiles side by side

LLM

Human

Largest disagreements: Edge/boundary conditions (+2), Performance risks (+2), Security risks (+2), Cross-EIP interactions (+2), Patterns affecting pre-existing tests (−1)

Show differences only (5 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
Security risks	2	0	+2	Differ by 2+	Show rationale LLM The repricing is narrow, but it changes existing gas-used and transaction-validity assumptions and touches execution validation and gas estimation. That supports targeted review and boundary fuzzing across a limited component set, matching score 2; the proposal does not support broad critical-component interactions for score 3. Human No rationale recorded.
Performance risks	2	0	+2	Differ by 2+	Show rationale LLM The arithmetic can be isolated, but its intended block-size/variance and estimation effects require system-level validation. The impact is confined mainly to floor-bound data-heavy transactions while EVM-heavy behavior is retained, fitting score 2 rather than the substantial or complex-interaction anchor. Human No rationale recorded.
Edge/boundary conditions	2	0	+2	Differ by 2+	Show rationale LLM Two related but distinct boundary-prone mechanisms require coverage: selection between gas-used branches and transaction validity against competing minimums. Neither is shown to need an elevated number of cases, matching score 2. Human Contains edge-cases but automatic test generators for these conditions already exist as part of tests for EIP-7623.
Cross-EIP interactions	2	0	+2	Differ by 2+	Show rationale LLM The proposal directly depends on and modifies EIP-7623 and composes with EIP-3860 for creation transactions. Coordinated boundary and creation testing is required, but the interactions are narrow arithmetic composition rather than complex multi-EIP redesign, matching score 2. Human No rationale recorded.
Patterns affecting pre-existing tests	1	2	−1	Differ by 1	Show rationale LLM The parameter change affects a focused subset of pre-existing tests whose expected gas use or validity is floor-sensitive. The sealed evidence supports a minor, localized subset rather than a considerable or diverse test rewrite, matching score 1. Human Pattern affects many tests but the test framework is already well prepared for this change due work already done in EIP-7623 testing. However, static tests might break after these change because these have to be manually updated.
Added opcodes	0	0	0	Agree	Show rationale LLM No opcode is introduced; score 0 applies. Human No rationale recorded.
Modified opcodes	0	0	0	Agree	Show rationale LLM No pre-existing opcode behavior is modified or deprecated, and the row explicitly excludes gas-only changes; score 0 applies. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM No precompile is introduced; score 0 applies. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM No pre-existing precompile is modified; score 0 applies. Human No rationale recorded.
Added system contracts	0	0	0	Agree	Show rationale LLM No system contract is introduced; score 0 applies. Human No rationale recorded.
Modified system contracts	0	0	0	Agree	Show rationale LLM No direct or discernible indirect modification of a pre-existing system contract is specified; score 0 applies. Human No rationale recorded.
EVM Gas rule changes	1	1	0	Agree	Show rationale LLM The proposal updates an existing EVM transaction gas-accounting mechanism by repricing its floor parameter; it does not introduce a different accounting mechanism. This matches score 1. Human Affects an existing mechanism for which tests are already prepared to be automatically updated.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM No blob gas accounting mechanism is added or modified, so the row scores 0. Human No rationale recorded.
New EVM gas refund	0	0	0	Agree	Show rationale LLM Referencing refund-adjusted execution gas does not introduce a gas-refund mechanism; score 0 applies. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM No new transaction type is introduced; score 0 applies. Human No rationale recorded.
New or modified transaction validity mechanisms	2	2	0	Agree	Show rationale LLM Raising the floor changes the validity threshold for existing transactions and therefore changes floor-sensitive validity tests, but the sealed evidence indicates limited expected-value and boundary updates rather than test-infrastructure redesign. This matches score 2. Human Mechanism affects validity, but we only have to pay attention to the fork transition when the values change, as the rest of the scenarios will be automatically updated by updating a few constants.
New block / header fields	0	0	0	Agree	Show rationale LLM No new block or block-header field is introduced; score 0 applies. Human No rationale recorded.
Encoding changes (RLP/SSZ)	0	0	0	Agree	Show rationale LLM No RLP, SSZ, transaction, block, or interface encoding change is introduced; score 0 applies. Human No rationale recorded.
Block syncing changes	0	0	0	Agree	Show rationale LLM No new block RLP validation mechanism requiring sync testing is introduced; score 0 applies. Human No rationale recorded.
New fork activation mechanism	0	0	0	Agree	Show rationale LLM A scheduled ruleset change is required, but the row scores activation-block state or internal-variable modifications; none is specified, so the score is 0. Human No rationale recorded.
Engine API changes	0	0	0	Agree	Show rationale LLM An execution RPC estimation update is not an Engine API field change under the row definition; score 0 applies. Human No rationale recorded.
Engine API encoding changes	0	0	0	Agree	Show rationale LLM Because the historical checklist supplies no definition for this row, it is scored conservatively from the label alone. No Engine API encoding change is visible, so the score is 0. Human No rationale recorded.
Transition-tool interface changes	0	0	0	Agree	Show rationale LLM The proposal requires a ruleset update but specifies no transition-tool interface field or new interface mechanism; score 0 applies. Human No rationale recorded.
Cryptography	0	0	0	Agree	Show rationale LLM No cryptographic mechanism or cryptographic functionality is introduced or modified; score 0 applies. Human No rationale recorded.

Compare EIP-7976 with other assessments All Amsterdam / Glamsterdam 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.

OP+
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.
PC+
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.
ORD
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.
SGAS
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.
ENC
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.
ACT
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).
T8N
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.).
INV
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.

XEIP
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.
UNSP
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.