EIP complexity assessment

EIP-8038: State-access gas cost update

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-10-16Included by cutoffLayers: execution

LLM Completescore 14

Human Completescore 20 · Checklist revision 1· merged checklist

LLM · Checklist revision 32026-10-08 · Opus 5.5 · primary · 14 Human · Checklist revision 1Complete · 20 CompareHuman vs LLM · shared criteria

Evaluated on: 2026-10-08 · Spec revision: 2025-10-08 · 2023b9c151

Scope at the cutoff. At this revision, EIP-8038 reprices state access. It raises four existing gas parameters: GAS_STORAGE_UPDATE, GAS_COLD_SLOAD, GAS_COLD_ACCOUNT_ACCESS and GAS_WARM_ACCESS. All new values are TBD. These parameters affect SSTORE, SLOAD, the *CALL family, BALANCE, SELFDESTRUCT and the EXT* opcodes. The EIP also adds one GAS_WARM_ACCESS to the cold and warm access cost of EXTCODESIZE and EXTCODECOPY. The Rationale coordinates the values with EIP-8032's depth-based SSTORE pricing and says that under EIP-2926, EXTCODESIZE keeps its previous formula. It adds no new mechanisms, encodings, header fields, opcodes or transaction types.

14MediumMedium

Evaluator: LLMChecklist v3
Confidence: Medium
Under-specified at assessment cutoff: Yes — 6 criteria affected
Plausible range: 13–18 (Medium)
Assessment cutoff: 2025-10-16 · EIP revision 2023b9c151 (2025-10-08)

Score bands · Checklist revision 3

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.

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: All new parameter values are TBD. The Specification applies the extra GAS_WARM_ACCESS to EXTCODESIZE, but the EIP-2926 Rationale says EXTCODESIZE keeps its previous formula, even though EIP-2926 is required. The before- and after-EIP-8032 parameter regimes are described without a normative choice. The Backwards Compatibility text refers to calldata and floor cost rules that do not apply here.

Plausible total

13–18
recorded score 14 · plausible tiers Medium

Affected criteria (6)

State gas accounting changes (1)
New test-framework primitives (0)
Performance risks (2)
Edge/boundary conditions (2)
Cross-EIP interactions (2)
Unspecified behavior requiring cross-client consensus (2)

Unresolved questions at the cutoff (6)

What are the new values of GAS_STORAGE_UPDATE, GAS_COLD_SLOAD, GAS_COLD_ACCOUNT_ACCESS and GAS_WARM_ACCESS?
With EIP-2926 active, does EXTCODESIZE pay the extra GAS_WARM_ACCESS or not?
Which parameter regime (before or after EIP-8032) applies when both EIPs are in the same fork?
Does the extra EXTCODECOPY warm charge stack with EIP-2926 per-chunk warming costs?
Do intrinsic access-list costs or EIP-7702 delegation access costs change along with GAS_COLD_ACCOUNT_ACCESS and GAS_WARM_ACCESS?
Is GAS_WARM_ACCESS meant to change? The Abstract omits it but the table lists it.

Notable ambiguities noted by the assessor (6)

The Specification and the EIP-2926 interaction section contradict each other on the EXTCODESIZE formula.
All values are TBD (TODO markers), so expected gas results cannot be derived.
The title and Abstract say 'increase', but the table includes GAS_WARM_ACCESS, which the Abstract does not mention.
Backwards Compatibility refers to 'calldata cost rules' and 'floor cost values', apparently copied from another EIP.
The table lists SELFDESTRUCT for cold account access but not for warm access.
The SSTORE refund amounts that derive from the repriced parameters are not discussed.

Criterion breakdown

EIP-8038 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Patterns affecting pre-existing tests	3	One common change, the repricing of the warm/cold and storage parameters, changes expected gas results in ordinary cases across distinct families. These include storage opcodes (SLOAD and SSTORE gas and refund paths), the call family (including calls to warm precompiles), account introspection (BALANCE and EXT*) and SELFDESTRUCT. It also changes any test whose gas outcome depends on these opcodes.	eip.md · Specification — "Operations affected" column The repricing affects SSTORE, SLOAD, CALL opcodes, BALANCE, SELFDESTRUCT and EXT opcodes, including warm-access costs. eip.md · Specification — EXTCODESIZE/EXTCODECOPY formula The cold and warm expected costs for EXTCODESIZE and EXTCODECOPY change. Confidence: High Uncertainty: Exact rework depends on the TBD values. If GAS_WARM_ACCESS ends up unchanged, the rework is somewhat narrower, but it still spans several families.
Performance risksUnder-specified	2	The changed gas bounds for state-access workloads need targeted integrated, state-dependent benchmarks against a large state and worst-case contract sizes. These cover database reads for accounts, storage and code. No new cross-subsystem resource coupling is introduced.	eip.md · Benchmarking — "we require stateful benchmarks, which are currently in development" Setting the values depends on stateful benchmarks of state-access operations. eip.md · Interaction with EIP-8032 The values must reflect worst-case contract size, either overall or up to ACTIVATION_THRESHOLD. eip.md · Interaction with EIP-7928 The initial benchmarks will not take BAL-enabled optimizations into account. Confidence: Medium Uncertainty: With TBD values, it is unclear how much the worst-case benchmarking would also need to cover EIP-8032 depth regimes and BAL parallel-IO interactions.
Edge/boundary conditionsUnder-specified	2	Several boundary-sensitive rules change: exact-gas out-of-gas thresholds for SSTORE and SLOAD, for cold and warm account access, and for the new EXTCODE* formula. Cold/warm and exact-gas dimensions can mostly be tested per opcode, so no elevated matrix is established.	eip.md · Specification — parameter table Several independent cost parameters change, each moving exact out-of-gas boundaries for the opcodes that use it. eip.md · Specification — EXTCODESIZE/EXTCODECOPY formula A new cold/warm cost formula introduces new exact-gas boundaries for two opcodes. Confidence: Medium Uncertainty: Interaction with EIP-8032's ACTIVATION_THRESHOLD and EIP-2200-style SSTORE paths could form an elevated matrix, but that depends on TBD values and on the prerequisite's own rules.
Cross-EIP interactionsUnder-specified	2	The interactions with EIP-8032 (SSTORE below and above the threshold), EIP-2926 (EXTCODESIZE vs EXTCODECOPY, converted vs legacy code, delegated accounts) and EIP-2929 (cold/warm paths for each repriced opcode) each need coordinated cases. They are largely separable per opcode family rather than a coupled multi-EIP restructuring, so this is level 2. EIP-7928 needs only local checks.	eip.md · Interaction with EIP-8032 SSTORE pricing combines the new GAS_STORAGE_UPDATE and GAS_COLD_SLOAD with EIP-8032's depth-based term above ACTIVATION_THRESHOLD. supporting/eip-8032.md · Gas cost changes — "constant_sstore_gas(addr, slot) + LIN_FACTOR * ..." The constant SSTORE part, which this EIP reprices, is added to the depth term. eip.md · Interaction with EIP-2926 Under EIP-2926, EXTCODESIZE uses the previous formula while EXTCODECOPY gets the extra warm charge. supporting/eip-2926.md · Updating existing code — "EXTCODESIZE/EXTCODEHASH/EXTCODECOPY behave the same" EIP-7702 delegated accounts and legacy (not yet converted) contracts during the transition affect EXTCODE* cases. eip.md · Motivation — EIP-2929 The repriced parameters are EIP-2929's cold/warm access parameters. supporting/eip-7928.md · Scope and Inclusion — "Targets of BALANCE, EXTCODESIZE, EXTCODECOPY" BAL recording of accessed addresses is unchanged, but gas-boundary cases affect which accesses occur. Confidence: Medium Uncertainty: If SSTORE vectors must jointly cover EIP-2929 cold/warm, EIP-8032 depth and EIP-2926 states, this could reach level 3. Interacting EIPs: EIP-8032, EIP-2926, EIP-2929, EIP-7928
Unspecified behavior requiring cross-client consensusUnder-specified	2	There are localized competing outcomes. The EXTCODESIZE formula conflicts between the Specification and the Rationale under the EIP-2926 baseline. The choice between EIP-8032 regimes is open, and how EXTCODECOPY combines with chunk warming is unspecified. These need spec and client agreement before expected results can be fixed. Previously unobservable behaviour does not become consensus-visible.	eip.md · Specification — parameter table "TBD" and "<-- TODO -->" All new parameter values are unspecified, so expected gas results cannot be fixed. eip.md · Interaction with EIP-2926 — "EXTCODESIZE should maintain its previous cost formula" This contradicts the Specification, which applies the extra GAS_WARM_ACCESS to EXTCODESIZE, even though EIP-2926 is a required prerequisite. eip.md · Interaction with EIP-8032 Two parameter regimes (before and after EIP-8032) are described without a normative selection rule or values. supporting/eip-2926.md · Gas cost of code-accessing opcodes — "reading a non-accessed chunk will incur a 200 warming cost" It is unclear whether the extra EXTCODECOPY warm charge stacks with per-chunk warming. Confidence: Medium Uncertainty: The EXTCODECOPY and chunk-warming question partly depends on EIP-2926's own incompletely specified gas rules.
EVM Gas rule changes	1	Existing accounting rules and parameters change: constant repricing plus an additive term in an existing cold/warm formula. No new accounting mechanism is introduced, so this is level 1.	eip.md · Specification — parameter table Existing parameters GAS_STORAGE_UPDATE, GAS_COLD_SLOAD, GAS_COLD_ACCOUNT_ACCESS and GAS_WARM_ACCESS get new values, which are still TBD. eip.md · Specification — "access_gas_cost = GAS_WARM_ACCESS2" The existing EIP-2929-style cold/warm access formula for EXTCODESIZE and EXTCODECOPY gains one extra GAS_WARM_ACCESS term. Confidence:* High
State gas accounting changesUnder-specified	1	The only state-write-related change is the value of the existing SSTORE update cost parameter. No new state-gas mechanism or budget exists, so this is at most level 1.	eip.md · Specification — "GAS_STORAGE_UPDATE \| 5,000 \| TBD" The existing SSTORE storage-write cost parameter is repriced. eip.md · Motivation The repricing is justified by state-access performance, not by state growth. Confidence: Low Uncertainty: GAS_STORAGE_UPDATE could be read purely as an execution-gas access charge, which would make this criterion 0.
Security risks	1	The changed security conditions are local: whether the new prices bound worst-case state-access DoS, and whether behaviour under fixed gas budgets (for example the 2300 stipend) is consistent. No cross-component trust invariant changes.	eip.md · Security Considerations Only application usability impact is noted. eip.md · Specification — GAS_WARM_ACCESS row Warm access costs may change, affecting fixed-gas-stipend execution paths. Confidence: Medium Uncertainty: Breakage of existing contracts that rely on the stipend is an application concern and is not analysed in the EIP.

Show 20 zero-score criteria

Zero-score criteria (Checklist revision 3)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No new opcode.	eip.md · Specification No new instructions.
Modified opcodes	These are gas-only changes, so the criterion is 0 by definition.	eip.md · Specification — "gas cost formula for EXTCODESIZE and EXTCODECOPY is updated" Only gas cost changes are specified for existing opcodes.
Added precompiles	No new precompile.	eip.md · Specification No precompiles are introduced.
Modified precompiles	Calls to warm precompiles cost more through the CALL access cost, but no precompile's own gas schedule or semantics changes.	eip.md · Specification — parameter table Only *CALL access costs change. Precompile gas schedules are not touched.
Added system contracts	No system contract is added.	eip.md · Specification No contracts are introduced.
Modified system contracts	System contract rules and code are unchanged. Higher gas costs for user calls into them are an ordinary repricing effect.	eip.md · Specification Only gas parameters change. No system contract is referenced. Uncertainty: Gas consumed by system calls or user calls into existing system contracts rises. If any fee or gas assumption around them is tight, this could count as an indirect local change (level 1).
State-access ordering within opcode execution	No instruction's order of state access versus gas charging changes, and the definition of a recordable access is unchanged.	eip.md · Specification — EXTCODESIZE/EXTCODECOPY formula Only the charged amount changes. The accessed_addresses check-then-add sequence is the same as the existing cold/warm logic. eip.md · Interaction with EIP-7928 The text does not change which accesses are recorded in the block-level access list. Uncertainty: Higher costs move out-of-gas points, which may change whether an access happens before a halt. That ordering is defined by EIP-2929 and EIP-7928, not changed by this EIP.
Blob gas accounting changes	No blob-gas accounting change.	eip.md · Specification Only execution-gas parameters for state access are changed. Blob gas is not mentioned.
New EVM gas refund	No new refund mechanism. Any knock-on effect on existing SSTORE restore refunds that derive from these parameters is a repricing, which belongs under GAS and PAT.	eip.md · Specification No refund mechanism is introduced. Only cost parameters are changed.
New transaction types	No new envelope.	eip.md · Specification No transaction types.
New or modified transaction validity mechanisms	No consensus transaction-validity or intrinsic-gas rule change is specified.	eip.md · Specification Intrinsic gas and access-list costs are not mentioned. Only opcode execution costs change. Uncertainty: It is not stated whether intrinsic access-list per-address or per-slot costs, or authorization-related account-access costs, track GAS_COLD_ACCOUNT_ACCESS.
New block / header fields	No new header member.	eip.md · Specification No header fields are added.
Encoding changes (RLP/SSZ)	The target introduces no schema or codec change.	eip.md · Interaction with EIP-2926 The codeSize account field is introduced by EIP-2926, not by this EIP.
Block syncing changes	No RLP decoding or structural validation changes.	eip.md · Specification No block structure or decoding changes.
New fork activation mechanism	Selecting a new gas schedule at the fork is not an activation-specific state transition.	eip.md · Specification — "Upon activation of this EIP, the following parameters ... are updated" Activation is a rule and constant switch only.
Engine API changes	No Engine API change.	eip.md · Specification No Engine API content.
Transition-tool interface changes	No transition-tool interface change is required. The fork-specific gas schedule is internal.	eip.md · Specification Only gas parameters and one formula change. No input or output fields are introduced.
New invariant on pre-existing tests	Only expected gas values change, which is rework rather than a new assertion.	eip.md · Specification No new output, field, log or commitment is introduced.
New test-framework primitivesUnder-specified	New parameter values in a fork gas schedule are not new primitives. Depth-aware SSTORE costing is EIP-8032's primitive.	eip.md · Specification Only parameter values change, plus one additive cost term. Uncertainty: Fork gas-cost helpers may need a local extension to distinguish the EXTCODESIZE and EXTCODECOPY formulas, especially under EIP-2926. That would be level 1 at most.
Cryptography	No cryptographic mechanism changes.	eip.md · Specification No cryptographic content.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@2023b9c151 EIPS/eip-8038.md committed 2025-10-08 · information cutoff 2025-10-16T08:11:36Z
Current master · File history · blob 63255d55d9 · sha256 8b5fa9f486be
Rubric: Checklist revision 3 · ethspecs/pm@fe2f793b03
Evaluator: Opus 5.5 (claude-opus-5-5) at high effort, one tool-less call per EIP · isolation bubblewrap_claude_p_no_tools_v1
Source record: Frozen research record research/tasks/10-opus-v3-reassessment/retrospective/outputs/assessments/amsterdam/eip-8038.yaml · sha256 c8062ef4da75
Supporting documents supplied with the EIP: supporting/eip-2926.md, supporting/eip-7928.md, supporting/eip-8032.md

Evaluated on: Not recorded · Spec revision: 2025-10-24 · a691b7ad1a

20HighHigh

Evaluator: HumanChecklist v1
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2025-11-07 · EIP at a691b7ad1a
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

EVM Gas rule changes3
Patterns affecting pre-existing tests3
Security risks3
Performance risks3

Criterion breakdown

EIP-8038 Amsterdam / Glamsterdam: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
EVM Gas rule changes	3	Updated mechanism introduced to cold and warm account accesses	—
Patterns affecting pre-existing tests	3	11 opcodes affected	—
Security risks	3	Any time gas costs are modified introduces inherent risk. Better specification may bring this number down.	—
Performance risks	3	New values are unspecified, and the EIP does not have current benchmarking numbers yet	—
Cross-EIP interactions	3	Strong interactions with EIP-8032, EIP-2926, EIP-2929, EIP-2930/EIP-1559,and EIP-7928.	—
New or modified transaction validity mechanisms	2	Access list cost change which affects type 1 and type 2 intrinsic gas.	—
Edge/boundary conditions	2	Many edge-case and boundary condition prone mechanisms	—
New EVM gas refund	1	`GAS_STORAGE_CLEAR_REFUND` is modified.	—

Show 16 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 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.	Blank cell read as zero because the published total proves it.
Cryptography	No rationale recorded.	—

Assessment provenance

Assessed EIP revision: ethereum/EIPs@a691b7ad1a EIPS/eip-8038.md committed 2025-10-24
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 cdbf7e8c47 · sha256 d4f4e83f2ba6
Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Merged checklist ethspecs/pm@3b1cc85210 complexity_assessments/EIPs/EIP-8038.md · committed 2025-11-07
blob 284c321322 · sha256 cf9187ccf3b6
Research record: research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-8038.yaml · sha256 a106b274163b

The LLM applied checklist revision 3 and the human reviewers revision 1 to EIP-8038 in Amsterdam / Glamsterdam. Revision 3 phrases the same criteria more precisely; differences cover the 23 criteria both revisions share, and each total keeps its own revision. Δ is LLM minus Human.

LLM14Medium

Human20High

Δ total−6Tiers differ: Medium vs High

Criteria17/23agree exactly · 3 differ by 1 · 3 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: substantive drift; human hindsight exposure: possible exposure.

Exposure evidence

The assessment notes that benchmark numbers were not yet available, showing fork-development awareness without reporting completed implementation outcomes.

Substantive intervening revisions: Retitles the EIP to 'State-access gas cost update' (PR #10582); renames GAS_STORAGE_UPDATE to GAS_COLD_STORAGE_WRITE and GAS_COLD_SLOAD to GAS_COLD_STORAGE_ACCESS; expands the repricing scope to GAS_STORAGE_CLEAR_REFUND, ACCESS_LIST_STORAGE_KEY_COST, and ACCESS_LIST_ADDRESS_COST; updates the discussions-to link.

Complexity profiles side by side

LLM

Human

Largest disagreements: EVM Gas rule changes (−2), New or modified transaction validity mechanisms (−2), Security risks (−2), New EVM gas refund (−1), Performance risks (−1)

Show differences only (12 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
EVM Gas rule changes	1	3	−2	Differ by 2+	Show rationale LLM Existing accounting rules and parameters change: constant repricing plus an additive term in an existing cold/warm formula. No new accounting mechanism is introduced, so this is level 1. Human Updated mechanism introduced to cold and warm account accesses
New or modified transaction validity mechanisms	0	2	−2	Differ by 2+	Show rationale LLM No consensus transaction-validity or intrinsic-gas rule change is specified. Human Access list cost change which affects type 1 and type 2 intrinsic gas.
Security risks	1	3	−2	Differ by 2+	Show rationale LLM The changed security conditions are local: whether the new prices bound worst-case state-access DoS, and whether behaviour under fixed gas budgets (for example the 2300 stipend) is consistent. No cross-component trust invariant changes. Human Any time gas costs are modified introduces inherent risk. Better specification may bring this number down.
New EVM gas refund	0	1	−1	Differ by 1	Show rationale LLM No new refund mechanism. Any knock-on effect on existing SSTORE restore refunds that derive from these parameters is a repricing, which belongs under GAS and PAT. Human `GAS_STORAGE_CLEAR_REFUND` is modified.
Performance risks	2	3	−1	Differ by 1	Show rationale LLM The changed gas bounds for state-access workloads need targeted integrated, state-dependent benchmarks against a large state and worst-case contract sizes. These cover database reads for accounts, storage and code. No new cross-subsystem resource coupling is introduced. Human New values are unspecified, and the EIP does not have current benchmarking numbers yet
Cross-EIP interactions	2	3	−1	Differ by 1	Show rationale LLM The interactions with EIP-8032 (SSTORE below and above the threshold), EIP-2926 (EXTCODESIZE vs EXTCODECOPY, converted vs legacy code, delegated accounts) and EIP-2929 (cold/warm paths for each repriced opcode) each need coordinated cases. They are largely separable per opcode family rather than a coupled multi-EIP restructuring, so this is level 2. EIP-7928 needs only local checks. Human Strong interactions with EIP-8032, EIP-2926, EIP-2929, EIP-2930/EIP-1559,and EIP-7928.
Added opcodes	0	0	0	Agree	Show rationale LLM No new opcode. Human No rationale recorded.
Modified opcodes	0	0	0	Agree	Show rationale LLM These are gas-only changes, so the criterion is 0 by definition. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM No new precompile. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM Calls to warm precompiles cost more through the CALL access cost, but no precompile's own gas schedule or semantics changes. Human No rationale recorded.
Added system contracts	0	0	0	Agree	Show rationale LLM No system contract is added. Human No rationale recorded.
Modified system contracts	0	0	0	Agree	Show rationale LLM System contract rules and code are unchanged. Higher gas costs for user calls into them are an ordinary repricing effect. Human No rationale recorded.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM No blob-gas accounting change. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM No new envelope. Human No rationale recorded.
New block / header fields	0	0	0	Agree	Show rationale LLM No new header member. Human No rationale recorded.
Encoding changes (RLP/SSZ)	0	0	0	Agree	Show rationale LLM The target introduces no schema or codec change. Human No rationale recorded.
Block syncing changes	0	0	0	Agree	Show rationale LLM No RLP decoding or structural validation changes. Human No rationale recorded.
New fork activation mechanism	0	0	0	Agree	Show rationale LLM Selecting a new gas schedule at the fork is not an activation-specific state transition. Human No rationale recorded.
Engine API changes	0	0	0	Agree	Show rationale LLM No Engine API change. Human No rationale recorded.
Transition-tool interface changes	0	0	0	Agree	Show rationale LLM No transition-tool interface change is required. The fork-specific gas schedule is internal. Human No rationale recorded.
Patterns affecting pre-existing tests	3	3	0	Agree	Show rationale LLM One common change, the repricing of the warm/cold and storage parameters, changes expected gas results in ordinary cases across distinct families. These include storage opcodes (SLOAD and SSTORE gas and refund paths), the call family (including calls to warm precompiles), account introspection (BALANCE and EXT*) and SELFDESTRUCT. It also changes any test whose gas outcome depends on these opcodes. Human 11 opcodes affected
Edge/boundary conditions	2	2	0	Agree	Show rationale LLM Several boundary-sensitive rules change: exact-gas out-of-gas thresholds for SSTORE and SLOAD, for cold and warm account access, and for the new EXTCODE* formula. Cold/warm and exact-gas dimensions can mostly be tested per opcode, so no elevated matrix is established. Human Many edge-case and boundary condition prone mechanisms
Cryptography	0	0	0	Agree	Show rationale LLM No cryptographic mechanism changes. Human No rationale recorded.
State-access ordering within opcode execution	0	n/a	—	Only in revision 3	Show rationale LLM No instruction's order of state access versus gas charging changes, and the definition of a recordable access is unchanged. Human No rationale recorded.
State gas accounting changes	1	n/a	—	Only in revision 3	Show rationale LLM The only state-write-related change is the value of the existing SSTORE update cost parameter. No new state-gas mechanism or budget exists, so this is at most level 1. Human No rationale recorded.
Engine API encoding changes	n/a	0	—	Only in revision 1	—
New invariant on pre-existing tests	0	n/a	—	Only in revision 3	Show rationale LLM Only expected gas values change, which is rework rather than a new assertion. Human No rationale recorded.
New test-framework primitives	0	n/a	—	Only in revision 3	Show rationale LLM New parameter values in a fork gas schedule are not new primitives. Depth-aware SSTORE costing is EIP-8032's primitive. Human No rationale recorded.
Unspecified behavior requiring cross-client consensus	2	n/a	—	Only in revision 3	Show rationale LLM There are localized competing outcomes. The EXTCODESIZE formula conflicts between the Specification and the Rationale under the EIP-2926 baseline. The choice between EIP-8032 regimes is open, and how EXTCODECOPY combines with chunk warming is unspecified. These need spec and client agreement before expected results can be fixed. Previously unobservable behaviour does not become consensus-visible. Human No rationale recorded.

Compare EIP-8038 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 · not in checklist revision 1
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 · not in checklist revision 1
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 · not in checklist revision 1
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 · not in checklist revision 1
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 · not in checklist revision 1
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.