EIP complexity assessment

EIP-2780: Resource-based intrinsic transaction gas

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

LLM Completescore 25

Human Completescore 13 · Checklist revision 1· merged checklist

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

Evaluated on: 2026-08-25 · Spec revision: 2025-09-08 · 2fd1e5e98e

Scope at the cutoff. At the recorded cutoff, EIP-2780 lowered the intrinsic transaction base cost from 21,000 to 6,000 gas for existing transaction formats. It also added a state-dependent 25,000-gas intrinsic surcharge for a non-creation, value-transferring transaction whose non-precompile destination is non-existent under the proposal's EIP-161-based rule at the start of execution. Calldata and access-list metering were otherwise unchanged, while transaction validation, gas estimation, regression vectors, and high-transaction-count performance behavior were in scope.

25HighHigh

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: Yes — 4 criteria affected
Plausible range: 24–26 (High)
Assessment cutoff: 2025-09-12 · EIP revision 2fd1e5e98e (2025-09-08)

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

Cross-EIP interactions5
EVM Gas rule changes3
New or modified transaction validity mechanisms3
Patterns affecting pre-existing tests3

Under-specified at assessment cutoff: Yes

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

Why: Material but localized under-specification remains in the CREATE path and destination-account predicate. The general intrinsic-gas pseudocode lowers the base for every transaction, while separate prose says CREATE transactions are unchanged; the surcharge language also mixes EIP-161 non-existent, empty, and creation concepts.

Plausible total

24–26
recorded score 25 · plausible tiers High

Affected criteria (4)

EVM Gas rule changes (3)
New or modified transaction validity mechanisms (3)
Edge/boundary conditions (3)
Unspecified behavior requiring cross-client consensus (2)

Unresolved questions at the cutoff (3)

Does 'CREATE transaction: unchanged' mean only that the existing creation component receives no new surcharge, or that CREATE retains the full prior 21,000 base?
Does the surcharge apply only when the destination account is strictly absent, or whenever it is EIP-161 dead, including an existing empty account?
At which precise pre-execution point is state_at_start sampled relative to upfront sender accounting and other transaction initialization?

Notable ambiguities noted by the assessor (2)

CREATE handling is internally inconsistent between the normative general calculation and prose/test wording that says CREATE is unchanged.
The surcharge predicate mixes 'non-existent,' EIP-161 'emptiness,' and account creation without explicitly selecting strict non-existence versus EIP-161 dead-account semantics.

Criterion breakdown

EIP-2780 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Cross-EIP interactionsExceptional	5	There are 11 identified interactions: 161, 1559, 2718, 2929, 2930, 7623, 7702, 7782, 7934, 7976, and 7999. Core validity and intrinsic formulas require coordinated vectors, while the latter capacity and fee-market proposals add coactivation/performance axes. Under the uncapped rule, anchor 3 plus two complete groups of three additional EIPs beyond the first three yields 5. Exceptional score: Cross-EIP interactions is explicitly uncapped: 11 identified interacting EIPs produce score 3 + floor((11 - 3) / 3) = 5.	eip.md · Front matter and Specification — New-account surcharge, lines 1-12 and 68-77 The EIP declares dependencies on EIPs 1559, 2718, 2929, and 2930, and normatively relies on EIP-161 destination-account semantics. eip.md · Specification — Code change example and Edits and interactions with other EIPs, lines 111-127 Existing EIP-1559/EIP-2930 typed transactions inherit the new base, EIP-7702 inherits it through EIP-2930, and EIP-7623 calldata rules must compose unchanged around it. eip.md · Rationale and Backwards Compatibility — Effects on transactions per block, lines 165-195 The text connects envelope neutrality and calldata floors to EIPs 2718, 7623, and 7976, and identifies capacity interactions with EIPs 7934, 7782, and 7999. supporting/eip-7976.md · Specification, lines 29-59 EIP-7976's calldata-floor and validity formulas embed a 21,000 base, so coactivation requires coordinated replacement or composition. supporting/eip-7999.md · Specification for aggregate and hybrid EVM gas, lines 429-459 EIP-7999 treats TX_BASE_COST as a deterministic fee component, creating a direct formula interaction with this repricing. Confidence: Medium Uncertainty: Some later-listed interactions are capacity or fee-composition axes rather than direct normative dependencies, so the breadth of coordinated testing is less certain than for EIPs 161, 1559, 2718, 2929, 2930, 7623, and 7702. Interacting EIPs: EIP-161, EIP-1559, EIP-2718, EIP-2929, EIP-2930, EIP-7623, EIP-7702, EIP-7782, EIP-7934, EIP-7976, EIP-7999
EVM Gas rule changesUnder-specified	3	A new state-dependent intrinsic-gas mechanism is introduced on top of a broad update to the existing base-cost mechanism, changing existing transaction gas and validity vectors. This matches anchor 3.	eip.md · Specification — Parameters and New-account surcharge, lines 57-77 The proposal replaces the universal transaction base with 6,000 gas and introduces a conditional 25,000-gas surcharge based on transaction kind, value, precompile status, and destination existence. eip.md · Specification — Intrinsic gas computation, lines 84-120 Normative pseudocode changes intrinsic gas for existing transaction formats and makes it depend on state at the start of the transaction. Confidence: High Uncertainty: The intended CREATE-transaction treatment has conflicting wording, recorded under under-specification, but does not change that the proposal triggers anchor 3.
New or modified transaction validity mechanismsUnder-specified	3	This changes a validity threshold across existing transaction types and makes formerly transaction-local intrinsic-gas validation state-dependent. That demands extensive vector rework and state-aware validation/harness handling, matching anchor 3.	eip.md · Specification — Intrinsic gas computation, lines 84-109 Intrinsic gas for all existing transaction formats changes, and the calculation gains a state-at-start input plus a conditional destination-state surcharge. eip.md · Backwards Compatibility, lines 177-181 The EIP identifies the repricing as consensus-incompatible and requires wallets, RPCs, estimators, and all logic assuming a 21,000 base to update. Confidence: High Uncertainty: The package does not detail test-infrastructure changes, and the exact CREATE path is textually inconsistent.
Patterns affecting pre-existing tests	3	The universal base-cost change alters a major and diverse body of pre-existing transaction gas, validity, fork, estimator, and benchmark cases; the state-dependent surcharge adds further rework. This matches anchor 3.	eip.md · Specification — Intrinsic gas computation and Edits and interactions with other EIPs, lines 84-127 Every hardcoded 21,000 base is replaced for existing typed transactions, and existing EIP-2930-derived intrinsic formulas inherit the new base. eip.md · Backwards Compatibility and Test Cases, lines 177-181 and 226-239 The EIP is a consensus repricing requiring existing assumptions to update and calls for recipient-state, precompile, creation, access-list, contract-execution, and performance vectors. Confidence: High Uncertainty: Exact test counts are not supplied, but the affected rule is universal across transaction formats.
Security risks	3	The change touches critical transaction validity and state-growth pricing while materially expanding worst-case transaction counts, affecting execution, state, resource-exhaustion, and estimation assumptions. These multiple critical interactions warrant extensive security and adversarial workload review, matching anchor 3.	eip.md · Specification — New-account surcharge, lines 68-77 Consensus intrinsic cost now depends on state existence, value, transaction kind, and precompile classification, with the surcharge intended to preserve state-growth pricing. eip.md · Security Considerations, lines 241-247 The EIP explicitly recognizes risk from a significant increase in maximum transactions per block and relies on equivalence between newly priced transaction components and existing internal work. Confidence: Medium Uncertainty: The security section is brief and does not quantify client-specific resource or state-growth limits.
Performance risks	3	The repricing substantially changes block-level workload composition and existing throughput assumptions, and cannot be validated solely as a single isolated transaction operation. Cross-client block benchmarks are required, matching anchor 3.	eip.md · Abstract — Capacity Impact, lines 24-28 The proposal estimates 18.5% more average transactions and up to 250% more minimal transactions per block at an unchanged nominal gas limit. eip.md · Test Cases and Security Considerations, lines 226-247 It calls for all-client Perfnet blocks of ETH transfers and contract-activation workloads and acknowledges risk from significantly increasing maximum transaction count. Confidence: High Uncertainty: The EIP supplies claimed headroom but no packaged all-client result for the specified workloads.
Edge/boundary conditionsUnder-specified	3	Several boundary-prone mechanisms interact, and the destination-state condition must be crossed with transaction kind, value, recipient class, transaction format, gas limit, and fork activation. This elevated matrix matches anchor 3.	eip.md · Specification — New-account surcharge, lines 68-82 The surcharge branches on creation versus call, zero versus positive value, precompile status, and EIP-161 destination existence at transaction start. eip.md · Test Cases, lines 226-239 Explicit vectors combine recipient state, precompiles, value boundaries, creation, typed access lists, and maximal-address contract execution. Confidence: High Uncertainty: The CREATE wording and EIP-161 existence terminology leave two boundary expectations under-specified.
Unspecified behavior requiring cross-client consensusUnder-specified	2	Clients need localized agreement on whether CREATE retains only its existing creation component or its entire prior intrinsic cost, and on whether the surcharge uses strict non-existence or EIP-161 dead/empty semantics. The intended reading is inferable but not fully determined, matching anchor 2.	eip.md · Specification — New-account surcharge, lines 68-82 The condition says 'non-existent per EIP-161 emptiness,' while adjacent notes alternate among non-existent, empty, creation, and no-creation terminology. eip.md · Specification — Intrinsic gas computation and Test Cases, lines 84-109 and 232-238 Normative pseudocode applies the 6,000 base to transaction calculation generally, but the prose and test list say CREATE transactions are unchanged from prior rules. supporting/eip-161.md · Specification, lines 20-36 EIP-161 separately defines empty and dead accounts, with dead including either non-existent or empty, making the EIP-2780 terminology relevant to constructible state cases. Confidence: High Uncertainty: The invariant against persistent empty accounts may make some empty-versus-non-existent cases rare, but the packaged text does not eliminate the semantic conflict.

Show 20 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No opcode is introduced, so anchor 0 applies.	eip.md · Specification, lines 57-127 The specification changes transaction intrinsic gas and defines no opcode number, stack behavior, or EVM instruction.
Modified opcodes	No pre-existing opcode behavior is modified; gas-only context would be excluded by this anchor in any event. Anchor 0 applies.	eip.md · Abstract and Specification — Intrinsic gas computation, lines 16-22 and 84-109 The change occurs during initial transaction processing, and the normative pseudocode modifies no opcode result or non-gas behavior.
Added precompiles	No precompile is added, so anchor 0 applies.	eip.md · Specification — New-account surcharge, lines 68-77 Existing precompiles are only recognized as destinations exempt from the new-account surcharge; none is introduced.
Modified precompiles	An exemption in transaction intrinsic accounting is not a modification to a precompile's gas schedule or behavior, so anchor 0 applies.	eip.md · Specification — New-account surcharge and Test Cases, lines 68-77 and 232-238 A top-level transfer to a precompile uses the new transaction base without the surcharge, but the precompile's own logic and gas schedule are untouched.
Added system contracts	No system contract is introduced, so anchor 0 applies.	eip.md · Specification, lines 57-127 The proposal consists of gas constants and transaction-processing rules and deploys no contract.
Modified system contracts	A general intrinsic-cost change without a specified system-contract effect is not a modification of a pre-existing system contract, so anchor 0 applies.	eip.md · Abstract and Specification, lines 14-22 and 57-127 The focused change applies before transaction execution and identifies no existing system contract code, state, or special action affected by it. Uncertainty: The package does not enumerate system contracts, so only explicit proposal effects are scored.
State-access ordering within opcode execution	The state lookup used to calculate top-level intrinsic gas is not a change to ordering inside opcode execution, so anchor 0 applies.	eip.md · Abstract and Specification — Intrinsic gas computation, lines 14-22 and 84-109 The change is confined to initial transaction intrinsic-gas processing; the pseudocode does not alter state access or gas charging within any opcode.
Blob gas accounting changes	No blob-gas accounting mechanism or parameter is changed, so anchor 0 applies.	eip.md · Abstract, lines 16-22 The proposal changes transaction intrinsic gas while expressly leaving calldata and access-list metering unchanged; it specifies no blob-gas rule.
State gas accounting changes	The proposal uses execution/intrinsic gas rather than the rubric's separate state-gas accounting system, so anchor 0 applies.	eip.md · Specification — Parameters and Intrinsic gas computation, lines 61-109 State growth is priced through an ordinary intrinsic-gas surcharge; no state-gas budget, state-gas charging site, reservoir, or spill rule is introduced.
New EVM gas refund	No new EVM gas-refund mechanism is introduced, so anchor 0 applies.	eip.md · Specification — Intrinsic gas computation, lines 84-109 The normative calculation only adds intrinsic charges and returns the resulting cost; it defines no refund path.
New transaction types	The EIP modifies existing transaction formats rather than introducing a new type, so anchor 0 applies.	eip.md · Specification — Code change example and Edits and interactions with other EIPs, lines 111-127 Existing typed transactions inherit the replacement base cost; the proposal assigns no new EIP-2718 type or payload.
New block / header fields	No new block or header field is introduced, so anchor 0 applies.	eip.md · Specification, lines 57-127 The specification changes transaction-level gas parameters and rules without adding a block or header field.
Encoding changes (RLP/SSZ)	No RLP-to-SSZ or other encoding change is introduced, so anchor 0 applies.	eip.md · Rationale — Why not charge full tx data as calldata?, lines 165-171 The proposal deliberately keeps intrinsic pricing independent of envelope RLP size and preserves typed-envelope neutrality; it does not change transaction, block, or interface encoding.
Block syncing changes	Higher possible transaction counts do not constitute an RLP validation mechanism, so anchor 0 applies.	eip.md · Specification, lines 57-127 The consensus change is to transaction intrinsic-gas calculation; no block RLP validation rule is introduced or modified.
New fork activation mechanism	Ordinary fork-gated rule activation without an activation-block state modification is anchor 0.	eip.md · Specification, lines 57-66 Activation at FORK_BLOCK sets two gas parameters and applies transaction rules; it specifies no one-time state or internal-variable migration at the activation block.
Engine API changes	No Engine API change is specified, so anchor 0 applies.	eip.md · Specification, lines 57-127 The specification adds no Engine API endpoint, field, or communication mechanism.
Transition-tool interface changes	State-aware execution logic changes do not by themselves add or modify the transition-tool interface, so anchor 0 applies.	eip.md · Specification, lines 57-127 The specification changes intrinsic transaction processing and parameters but introduces no transition-tool request or response field. Uncertainty: The EIP does not discuss transition-tool integration; the score is based strictly on the absence of an interface change in the packaged text.
New invariant on pre-existing tests	Existing expectations must be reworked, but unrelated tests do not gain a distinct new invariant to assert; anchor 0 applies.	eip.md · Specification — Intrinsic gas computation, lines 84-109 The proposal changes the intrinsic-gas result itself but does not add a new protocol output or assertion that unrelated tests must additionally check. Uncertainty: Some harnesses may mechanically assert the recalculated intrinsic result, but that is an updated expectation rather than a new invariant.
New test-framework primitives	Existing transaction, state, and block test primitives are sufficient for the described cases, so anchor 0 applies.	eip.md · Test Cases, lines 226-239 The requested coverage consists of ordinary transaction vectors, block workloads, access-list variants, recipient-state cases, and performance runs; no new expectation or modifier abstraction is specified. Uncertainty: The package does not describe the historical test framework's exact helper inventory.
Cryptography	Repricing unchanged signature recovery does not introduce or modify cryptography, so anchor 0 applies.	eip.md · Specification — Derivation, lines 128-147 ECDSA recovery appears only as an unchanged cost component used to derive the 6,000-gas base; no cryptographic algorithm or functionality changes.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@2fd1e5e98e EIPS/eip-2780.md committed 2025-09-08 · information cutoff 2025-09-12T13:12:54Z
Current master · File history · blob 61527a7b30 · sha256 93fb43bd8718
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-2780.yaml · sha256 23973bd9b6f6
Supporting documents in the sealed package: supporting/eip-161.md, supporting/eip-1559.md, supporting/eip-2718.md, supporting/eip-2929.md, supporting/eip-2930.md, supporting/eip-7623.md, supporting/eip-7782.md, supporting/eip-7934.md, supporting/eip-7976.md, supporting/eip-7999.md

Evaluated on: 2026-08-25 · Spec revision: 2025-09-08 · 2fd1e5e98e

Scope at the cutoff. Blinded assessment of the sealed Draft EIP-2780 revision: reduce TX_BASE_COST from 21,000 to 6,000 for existing transaction types and add a 25,000-gas surcharge for qualifying top-level value transfers that create an account, using only the historical 24-row execution checklist and allowlisted package sources.

20HighHigh

Evaluator: LLMChecklist v1
Confidence: Medium
Under-specified at assessment cutoff: Yes — 3 criteria affected
Plausible range: 18–21 (Medium–High)
Assessment cutoff: 2025-09-12 · EIP revision 2fd1e5e98e (2025-09-08)

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

EVM Gas rule changes3
New or modified transaction validity mechanisms3
Patterns affecting pre-existing tests3
Security risks3

Under-specified at assessment cutoff: Yes

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

Why: The state predicate uses the phrase “non-existent per EIP-161 emptiness” even though EIP-161 separately defines empty and dead accounts, and the statement that CREATE transactions are unchanged is unclear beside the universal TX_BASE_COST replacement. The proposal also names an EIP-7702 interaction without an allowlisted definition and leaves FORK_BLOCK unspecified. These gaps principally affect boundary, validity, and cross-EIP test design.

Plausible total

18–21
recorded score 20 · plausible tiers Medium, High

Affected criteria (3)

New or modified transaction validity mechanisms (3)
Edge/boundary conditions (2)
Cross-EIP interactions (3)

Unresolved questions at the cutoff (4)

Does the surcharge apply only to a strictly non-existent account, or to every EIP-161 dead account, including an existent-but-empty account?
Does “CREATE transaction: unchanged” mean only that no GAS_NEW_ACCOUNT surcharge applies, while its 21,000 base still becomes 6,000, or that the entire prior intrinsic cost remains unchanged?
What exact EIP-7702 intrinsic-cost and access-list cases must be coordinated, given that its definition is not present in the allowlisted package?
What fork activation value replaces FORK_BLOCK?

Notable ambiguities noted by the assessor (4)

The historical checklist contains an Engine API encoding row but supplies no dedicated definition; it was scored conservatively at low confidence.
EIP-2780’s “non-existent per EIP-161 emptiness” wording does not cleanly select among EIP-161’s non-existent, empty, and dead categories.
The universal base-cost replacement and the test-vector statement that CREATE is unchanged can be read differently.
The proposal discusses EIP-7702 even though it is absent from the front-matter requires list and from the supporting-source allowlist.

Criterion breakdown

EIP-2780 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
EVM Gas rule changes	3	A new state-dependent intrinsic-gas component is introduced while the existing base-cost mechanism is changed for every transaction type. Both changes alter existing gas accounting paths and their tests, matching score 3.	eip.md · Specification > Parameters; New-account surcharge; Intrinsic gas computation Changes TX_BASE_COST from 21,000 to 6,000 and adds a 25,000-gas, state-dependent surcharge for qualifying value transfers to non-existent accounts. supporting/eip-2930.md · Specification, paragraph beginning “At the beginning of execution” The pre-change access-list transaction intrinsic calculation uses the existing 21,000 base, showing the mechanism being replaced. Confidence: High Uncertainty: The proposal’s statement that CREATE transactions are “unchanged” is ambiguous relative to the universal TX_BASE_COST replacement, but it does not change the presence or breadth of the gas-rule change.
New or modified transaction validity mechanismsUnder-specified	3	The proposal changes intrinsic-gas validity across all transaction types and introduces a state-dependent validity input. Updating broad existing vectors and test machinery to cover account-start-state permutations is extensive enough for score 3.	eip.md · Specification > New-account surcharge; Intrinsic gas computation; Test Cases Makes intrinsic gas depend on start-state account existence and changes the required base for every transaction type, with explicit valid-cost boundary vectors. supporting/eip-7623.md · Specification, invalid-transaction paragraph Existing validity takes the maximum of the calldata floor and intrinsic gas, so changing the base propagates into gas-limit validity checks. supporting/eip-7976.md · Specification, invalid-transaction paragraph The later calldata-floor rule likewise compares the gas limit with an intrinsic calculation beginning at the old 21,000 base. Confidence: Medium Uncertainty: The package does not describe the existing testing infrastructure, and the exact CREATE and EIP-161 empty/non-existent semantics remain ambiguous; a more localized implementation could support score 2.
Patterns affecting pre-existing tests	3	The universal base-cost replacement changes a major and diverse set of existing transaction tests, while the new surcharge adds state-dependent cases across transaction forms. This matches the row’s broadest defined regression impact.	eip.md · Specification > Intrinsic gas computation; Test Cases Requires replacement of the 21,000 base for each typed transaction and adds state-, value-, destination-, and creation-sensitive vectors. eip.md · Backwards Compatibility Calls the change a non-backward-compatible consensus gas repricing and says wallets, RPCs, estimators, and logic assuming a 21,000 base must update. supporting/eip-1559.md · Specification, intrinsic-cost paragraph The EIP-1559 transaction type inherits an intrinsic formula beginning at 21,000, one of the established test patterns affected by the replacement. Confidence: High Uncertainty: The package does not inventory the pre-existing test suite; breadth is inferred from the normative requirement covering every transaction type and from the listed regression vectors.
Security risks	3	The change touches critical transaction admission, block workload/DoS pricing, and account-creation state-growth assumptions, with substantial effects across multiple existing components. The magnitude and consensus-sensitive state predicate warrant extensive security review and fuzzing, matching score 3.	eip.md · Security Considerations; Abstract > Capacity Impact Explicitly identifies risk from a significantly higher maximum transaction count while reducing the base charge by 71% for minimal existing-account transfers. eip.md · Motivation; Specification > New-account surcharge Changes the resource-pricing assumptions for universal transaction work and adds a state-growth charge keyed to account existence. supporting/eip-161.md · Addendum; Specification Shows that empty/non-existent account handling is consensus-sensitive and historically required precise revert and deletion semantics. Confidence: Medium Uncertainty: The proposal acknowledges risk but provides only brief security analysis, so the exact breadth of necessary review is not fully specified.
Performance risks	3	The repricing materially changes whole-block workload and existing performance behavior, and its interaction with transaction count, state updates, and byte-size limits cannot be validated solely by benchmarking the arithmetic in isolation. This matches score 3.	eip.md · Abstract > Capacity Impact; Motivation > Equivalent gas-limit increase; Backwards Compatibility > Effects on transactions per block Claims an average 18.5% throughput increase, up to 250% more minimal transactions, and analyzes interactions with much larger transaction counts and block limits. eip.md · Test Cases; Security Considerations Calls for blocks of transfers across all execution clients and warns that the significantly increased maximum transaction count carries risk. supporting/eip-7934.md · Specification > Block Size Cap Defines the independent RLP block-size ceiling that can become the binding resource as cheaper transactions increase count. Confidence: High Uncertainty: The sealed package does not provide a reproducible benchmark methodology; the score rests on the normative repricing, required whole-block validation, and stated magnitude rather than external outcomes.
Cross-EIP interactionsUnder-specified	3	The repricing has strong formula- and validity-level dependencies across multiple transaction, access-list, calldata-floor, and fee-market EIPs. Coordinated updates and cross-type vectors are required, matching score 3.	eip.md · Front matter, requires; Specification > Edits and interactions with other EIPs Requires EIPs 1559, 2718, 2929, and 2930 and explicitly coordinates the new base with EIP-2930, EIP-7702, and active calldata-pricing rules. supporting/eip-1559.md · Specification, intrinsic-cost paragraph The EIP-1559 type inherits EIP-2930’s fixed 21,000-based intrinsic formula, which must be revised coherently. supporting/eip-7623.md · Specification Its calldata floor and validity formulas embed the 21,000 transaction base, creating a direct formula-level interaction. supporting/eip-7999.md · Specification for aggregate and hybrid EVM gas, get_required_max_fee pseudocode Treats TX_BASE_COST as a deterministic fee component, showing another fee-market mechanism whose accounting depends on the base. Confidence: High Uncertainty: EIP-7702 is named by the proposal but is not included in the allowlisted supporting sources, and the CREATE ambiguity may affect coordinated vectors.
Edge/boundary conditionsUnder-specified	2	Multiple boundary-prone conditions must be combined, especially around value, destination class, transaction creation, and EIP-161 account state. The package supplies a finite set of direct vectors and does not establish that any one mechanism needs an elevated number of cases, matching score 2.	eip.md · Specification > New-account surcharge; Test Cases The surcharge depends on four predicates and the test vectors distinguish positive versus zero value, precompile versus ordinary destination, CREATE versus non-CREATE, and account existence. supporting/eip-161.md · Specification, clauses b–d and definitions of empty and dead Account existence semantics distinguish non-existent, empty, and dead accounts and include transaction-end deletion behavior. Confidence: Medium Uncertainty: “Non-existent per EIP-161 emptiness” is not fully aligned with EIP-161’s separate empty and dead terms, and the CREATE wording leaves the exact boundary matrix under-specified.

Show 17 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No opcode is added.	eip.md · Specification Specifies constants and top-level transaction intrinsic-gas logic, with no opcode number, stack behavior, or new instruction. Uncertainty: No opcode addition is specified.
Modified opcodes	No pre-existing opcode behavior is modified, and the row expressly excludes mere gas changes in any event.	eip.md · Specification > Intrinsic gas computation; Derivation Changes transaction-level intrinsic gas; mentions ECRECOVER only as a cost proxy and does not alter any existing opcode’s behavior. Uncertainty: No opcode behavior change is specified.
Added precompiles	No precompile is added.	eip.md · Specification > New-account surcharge Existing precompiles are only excluded from the new-account surcharge; no new precompile is defined. Uncertainty: The precompile predicate relies on the existing precompile set.
Modified precompiles	The exemption is transaction intrinsic-gas logic around a destination, not a modification to any precompile.	eip.md · Specification > New-account surcharge; Test Cases, vector 2 A transfer to a precompile keeps the 6,000 intrinsic base and receives no surcharge, but no precompile logic or precompile gas schedule changes. Uncertainty: No precompile implementation behavior is specified.
Added system contracts	No system contract is added.	eip.md · Specification Adds two gas parameters and transaction-processing rules only; no contract address, code, deployment, or system action is introduced. Uncertainty: No system-contract addition is specified.
Modified system contracts	No direct or described indirect modification to a pre-existing system contract is introduced.	eip.md · Specification > Parameters; Intrinsic gas computation The normative change is confined to intrinsic transaction gas and does not modify any system-contract code or state. Uncertainty: No system contract is identified in the sealed proposal.
Blob gas accounting changes	No blob-gas accounting mechanism is added or modified, so the row’s zero anchor applies.	eip.md · Abstract; Specification > Intrinsic gas computation The normative changes are limited to TX_BASE_COST and the new-account surcharge; calldata and access-list metering are explicitly unchanged and no blob-gas rule is specified. Uncertainty: The conclusion is based on the proposal’s expressly limited normative scope and the absence of any blob-gas rule.
New EVM gas refund	The proposal introduces no gas-refund mechanism.	eip.md · Specification > Intrinsic gas computation, CalculateIntrinsicGas pseudocode The calculation changes upfront intrinsic charges only and contains no refund counter, refund condition, or refund schedule. Uncertainty: No refund behavior is specified anywhere in the sealed proposal.
New transaction types	The proposal modifies processing of existing transaction types and introduces no new transaction type.	eip.md · Specification > Code change example; Edits and interactions with other EIPs Existing EIP-1559 and EIP-2930 typed transactions inherit the new TX_BASE_COST; no new type identifier or payload is defined. Uncertainty: The reference to EIP-7702 is an interaction with an existing type, not a definition of a new one in this proposal.
New block / header fields	No new block or header field is introduced.	eip.md · Specification > Parameters Introduces transaction gas constants and rules only, with no block or block-header field. Uncertainty: No header-format change is specified.
Encoding changes (RLP/SSZ)	No transaction, block, or interface encoding changes are introduced.	eip.md · Rationale > Why not charge full tx data as calldata? > Serialization neutrality The proposal deliberately keeps the base encoding-agnostic and does not alter the transaction envelope’s RLP or introduce another encoding. supporting/eip-2718.md · Specification > Transactions Defines the existing typed and legacy transaction envelopes that EIP-2780 continues to process without a format change. Uncertainty: No RLP-to-SSZ or other format transition is specified.
Block syncing changes	The historical row is specifically about block RLP validation requiring syncing tests, and no such mechanism is introduced.	eip.md · Specification; Backwards Compatibility Defines a consensus intrinsic-gas repricing but no block RLP field, decoding rule, or RLP validation mechanism. Uncertainty: No block-RLP change appears in the sealed proposal.
New fork activation mechanism	A normal fork-gated rule change is specified, but no new activation mechanism or activation-block state/internal-variable modification is introduced.	eip.md · Specification, opening sentence Activates ordinary parameter and rule changes after FORK_BLOCK, without a one-time state transition or modification of an existing internal variable at the activation block. Uncertainty: FORK_BLOCK is left as a placeholder, but the missing activation value does not itself establish the score-3 mechanism defined by the row.
Engine API changes	No Engine API directive or field is introduced.	eip.md · Specification > Intrinsic gas computation; Backwards Compatibility Places the change in transaction intrinsic-gas processing and identifies client, wallet, RPC, and estimator updates, without adding an Engine API field, endpoint, or communication mechanism. Uncertainty: The package contains no Engine API specification; score 0 is based on the proposal not requesting an Engine API change.
Engine API encoding changes	Conservatively applying the row label and global scale, the proposal contains no Engine API encoding change, so score 0 is warranted.	eip.md · Specification > Intrinsic gas computation; Rationale > Why not charge full tx data as calldata? Changes arithmetic applied to existing transactions and explicitly avoids coupling the fee rule to envelope encoding; no Engine API encoding is described. Uncertainty: The historical checklist provides no dedicated definition for this row; no substitute definition was imported.
Transition-tool interface changes	Although transition execution must apply the new rule, the proposal specifies no transition-tool interface field or new interface mechanism.	eip.md · Specification > Intrinsic gas computation, CalculateIntrinsicGas pseudocode Expresses the rule as an intrinsic-gas calculation over the transaction and start-state, without adding any transition-tool input or output field. Uncertainty: The sealed sources do not define the transition-tool interface itself; score 0 reflects the absence of any requested interface modification.
Cryptography	Repricing already-performed signature recovery is not a new or modified cryptographic mechanism.	eip.md · Specification > Derivation; Rationale Treats existing ECDSA signature recovery as part of the base-cost derivation but introduces no new algorithm, primitive, signature rule, or cryptographic behavior. Uncertainty: No cryptographic change is specified.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@2fd1e5e98e EIPS/eip-2780.md committed 2025-09-08 · information cutoff 2025-09-12T13:12:54Z
Current master · File history · blob 61527a7b30 · sha256 93fb43bd8718
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-2780.yaml · sha256 12ba59185966
Supporting documents in the sealed package: supporting/eip-161.md, supporting/eip-1559.md, supporting/eip-2718.md, supporting/eip-2929.md, supporting/eip-2930.md, supporting/eip-7623.md, supporting/eip-7782.md, supporting/eip-7934.md, supporting/eip-7976.md, supporting/eip-7999.md

Evaluated on: Not recorded · Spec revision: 2025-10-26 · d5e16901ed

13MediumMedium

Evaluator: HumanChecklist v1
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2025-11-05 · EIP at d5e16901ed
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
New or modified transaction validity mechanisms3
Patterns affecting pre-existing tests3
Edge/boundary conditions2

Criterion breakdown

EIP-2780 Amsterdam / Glamsterdam: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
EVM Gas rule changes	3	Affects the intrinsic gas cost of every transaction, which could break many pre-existing tests.	—
New or modified transaction validity mechanisms	3	Modifies the intrinsic transaction gas cost of all pre-existing transaction types. This will potentially break previous tests which will need to be updated and re-evaluated, e.g. intrinsic gas cost 7702 tests now have to be updated depending on whether they target a `GAS_NEW_ACCOUNT` account or not.	—
Patterns affecting pre-existing tests	3	Potentially a many of the pre-existing tests that require exact gas costs need rework. Although normal tests that don't rely on exact gas costs might not necessarily be affected since the cost is going down instead of up.	—
Edge/boundary conditions	2	Mainly due to the logic introduced that affects the intrinsic gas cost, and the new-account surcharge cost calculation, all combinations need to be tested.	—
Blob gas accounting changes	1	Minimal testing required due to type-3 transaction changing its intrinsic gas cost too.	—
Performance risks	1	Does not pose a performance risk but rather affects how we calculate worst case scenarios because more transactions (potentially) fit in each block.	—

Show 18 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.	—
New EVM gas refund	No rationale recorded.	Blank cell read as zero because the published total proves it.
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.	—
Cryptography	No rationale recorded.	—
Cross-EIP interactions	No rationale recorded.	—

Assessment provenance

Assessed EIP revision: ethereum/EIPs@d5e16901ed EIPS/eip-2780.md committed 2025-10-26
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 5b09bf7e29 · sha256 3c6c007bdadb
Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Merged checklist ethspecs/pm@d49a44fe77 complexity_assessments/EIPs/EIP-2780.md · committed 2025-11-05
blob e31e27bde7 · sha256 057e21adfca9
Research record: research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-2780.yaml · sha256 d3e77c8c9c5a

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

LLM20High

Human13Medium

Δ total+7Tiers differ: High vs Medium

Criteria20/24agree exactly · 1 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. The study's primary LLM score under checklist revision 2 is 25; it uses a different criterion inventory and thresholds and is not directly comparable to either total here.

Exposure evidence

The rationale discusses existing EIP-7702 tests needing updates, indicating awareness of a concrete test corpus but not a completed implementation of EIP-2780.

Substantive intervening revisions: Extends the proposal into a granular state-operation gas model (PR #10594, 'Include Call changes'): TX_BASE_COST 6,000 to 4,500; introduces STATE_UPDATE = 1,000, COLD_ACCOUNT_COST_CODE = 2,600, COLD_ACCOUNT_COST_NOCODE = 500, WARM_STATE_READ = 100; reprices value-moving calls (CALL_VALUE_COST 9,000 to 2,000, or 26,000 when creating an account); specifies a PAY-style primitive's warmth/code-load behavior, self-transfer rule, and warmth policy; adds transaction reference cases; EIP-2929 described as 'refined by this EIP'. | Adds an explicit warmth-pricing spec…

Complexity profiles side by side

LLM

Human

Largest disagreements: Security risks (+3), Cross-EIP interactions (+3), Performance risks (+2), Blob gas accounting changes (−1)

Show differences only (4 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
Security risks	3	0	+3	Differ by 2+	Show rationale LLM The change touches critical transaction admission, block workload/DoS pricing, and account-creation state-growth assumptions, with substantial effects across multiple existing components. The magnitude and consensus-sensitive state predicate warrant extensive security review and fuzzing, matching score 3. Human No rationale recorded.
Cross-EIP interactions	3	0	+3	Differ by 2+	Show rationale LLM The repricing has strong formula- and validity-level dependencies across multiple transaction, access-list, calldata-floor, and fee-market EIPs. Coordinated updates and cross-type vectors are required, matching score 3. Human No rationale recorded.
Performance risks	3	1	+2	Differ by 2+	Show rationale LLM The repricing materially changes whole-block workload and existing performance behavior, and its interaction with transaction count, state updates, and byte-size limits cannot be validated solely by benchmarking the arithmetic in isolation. This matches score 3. Human Does not pose a performance risk but rather affects how we calculate worst case scenarios because more transactions (potentially) fit in each block.
Blob gas accounting changes	0	1	−1	Differ by 1	Show rationale LLM No blob-gas accounting mechanism is added or modified, so the row’s zero anchor applies. Human Minimal testing required due to type-3 transaction changing its intrinsic gas cost too.
Added opcodes	0	0	0	Agree	Show rationale LLM No opcode is added. Human No rationale recorded.
Modified opcodes	0	0	0	Agree	Show rationale LLM No pre-existing opcode behavior is modified, and the row expressly excludes mere gas changes in any event. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM No precompile is added. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM The exemption is transaction intrinsic-gas logic around a destination, not a modification to any precompile. 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 No direct or described indirect modification to a pre-existing system contract is introduced. Human No rationale recorded.
EVM Gas rule changes	3	3	0	Agree	Show rationale LLM A new state-dependent intrinsic-gas component is introduced while the existing base-cost mechanism is changed for every transaction type. Both changes alter existing gas accounting paths and their tests, matching score 3. Human Affects the intrinsic gas cost of every transaction, which could break many pre-existing tests.
New EVM gas refund	0	0	0	Agree	Show rationale LLM The proposal introduces no gas-refund mechanism. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM The proposal modifies processing of existing transaction types and introduces no new transaction type. Human No rationale recorded.
New or modified transaction validity mechanisms	3	3	0	Agree	Show rationale LLM The proposal changes intrinsic-gas validity across all transaction types and introduces a state-dependent validity input. Updating broad existing vectors and test machinery to cover account-start-state permutations is extensive enough for score 3. Human Modifies the intrinsic transaction gas cost of all pre-existing transaction types. This will potentially break previous tests which will need to be updated and re-evaluated, e.g. intrinsic gas cost 7702 tests now have to be updated depending on whether they target a `GAS_NEW_ACCOUNT` account or not.
New block / header fields	0	0	0	Agree	Show rationale LLM No new block or header field is introduced. Human No rationale recorded.
Encoding changes (RLP/SSZ)	0	0	0	Agree	Show rationale LLM No transaction, block, or interface encoding changes are introduced. Human No rationale recorded.
Block syncing changes	0	0	0	Agree	Show rationale LLM The historical row is specifically about block RLP validation requiring syncing tests, and no such mechanism is introduced. Human No rationale recorded.
New fork activation mechanism	0	0	0	Agree	Show rationale LLM A normal fork-gated rule change is specified, but no new activation mechanism or activation-block state/internal-variable modification is introduced. Human No rationale recorded.
Engine API changes	0	0	0	Agree	Show rationale LLM No Engine API directive or field is introduced. Human No rationale recorded.
Engine API encoding changes	0	0	0	Agree	Show rationale LLM Conservatively applying the row label and global scale, the proposal contains no Engine API encoding change, so score 0 is warranted. Human No rationale recorded.
Transition-tool interface changes	0	0	0	Agree	Show rationale LLM Although transition execution must apply the new rule, the proposal specifies no transition-tool interface field or new interface mechanism. Human No rationale recorded.
Patterns affecting pre-existing tests	3	3	0	Agree	Show rationale LLM The universal base-cost replacement changes a major and diverse set of existing transaction tests, while the new surcharge adds state-dependent cases across transaction forms. This matches the row’s broadest defined regression impact. Human Potentially a many of the pre-existing tests that require exact gas costs need rework. Although normal tests that don't rely on exact gas costs might not necessarily be affected since the cost is going down instead of up.
Edge/boundary conditions	2	2	0	Agree	Show rationale LLM Multiple boundary-prone conditions must be combined, especially around value, destination class, transaction creation, and EIP-161 account state. The package supplies a finite set of direct vectors and does not establish that any one mechanism needs an elevated number of cases, matching score 2. Human Mainly due to the logic introduced that affects the intrinsic gas cost, and the new-account surcharge cost calculation, all combinations need to be tested.
Cryptography	0	0	0	Agree	Show rationale LLM Repricing already-performed signature recovery is not a new or modified cryptographic mechanism. Human No rationale recorded.

Compare EIP-2780 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.