EIP complexity assessment

EIP-7981: Increase Access List Cost

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

RetrospectiveAmsterdam / GlamsterdamAssessment cutoff 2025-08-26Included by cutoffLayers: execution

LLM Completescore 11

Human Completescore 6 · Checklist revision 1· merged checklist

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

Evaluated on: 2026-08-25 · Spec revision: 2025-08-24 · acc2533ec9

Scope at the cutoff. At the information cutoff, EIP-7981 was a draft execution-layer proposal that added an intrinsic-gas charge of 40 gas per non-zero byte and 10 gas per zero byte in every address and storage key contained in an existing access list. It retained EIP-2930's per-address and per-storage-key charges and access-list format, while applying the additional charge to existing access-list-bearing transaction classes to close the EIP-7623 block-size pricing loophole.

11LowLow

Evaluator: LLMChecklist v2
Confidence: High
Under-specified at assessment cutoff: No
Plausible range: 11–11 (Low)
Assessment cutoff: 2025-08-26 · EIP revision acc2533ec9 (2025-08-24)

Score bands · Checklist revision 2

Low <12
Medium 12–22
High ≥23

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

Complexity profile

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

Top complexity drivers

New or modified transaction validity mechanisms2
Patterns affecting pre-existing tests2
Security risks2
Cross-EIP interactions2

Under-specified at assessment cutoff: No

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

The assessor found no material behavior left unresolved by the EIP text at the cutoff.

Notable ambiguities noted by the assessor (2)

The sealed package does not enumerate the pre-existing test inventory, so the breadth of required vector updates is estimated from the four transaction classes explicitly named by the proposal.
The reference implementation names three additional access-list-bearing transaction classes without identifying their EIP numbers; no later identifiers were inferred.

Criterion breakdown

EIP-7981 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
New or modified transaction validity mechanisms	2	Increasing intrinsic gas changes whether existing transactions have sufficient gas and therefore modifies their validity mechanism. Existing gas-boundary vectors require limited numeric updates, but no test-infrastructure redesign is specified, which fits anchor 2.	eip.md · Reference Implementation, lines 155-190 The reference implementation adds access-list byte cost to the intrinsic cost returned for four existing access-list-bearing transaction classes. eip.md · Backwards Compatibility, lines 85-89 The proposal calls the repricing backwards incompatible, requires a scheduled upgrade, and requires wallet and node gas-estimation updates. Confidence: High
Patterns affecting pre-existing tests	2	A considerable but bounded category of pre-existing access-list transaction tests across several transaction classes must have gas totals, gas limits, and validity expectations reworked. The updates are mechanical and need no broad infrastructure redesign, fitting anchor 2 rather than anchor 3.	eip.md · Reference Implementation, lines 155-190 The reference implementation changes intrinsic cost for AccessListTransaction, FeeMarketTransaction, BlobTransaction, and SetCodeTransaction whenever their access list is charged. supporting/eip-2930.md · Specification, lines 75-107 The prior rule charged each address and key a fixed amount, including repeated entries, without per-byte fees; existing expectations encode that behavior. Confidence: Medium Uncertainty: The package does not enumerate the historical test inventory, so the exact number of affected vectors is uncertain, but the affected behavioral category and transaction classes are explicit.
Security risks	2	Incorrect byte counting or inconsistent intrinsic charging could preserve the block-size loophole or cause consensus disagreement. The change touches the existing access-list and intrinsic-validity paths and their floor-pricing goal, but the interaction set is limited and suitable for targeted review and fuzzing, fitting anchor 2.	eip.md · Abstract and Motivation, lines 14-20 The proposal closes an underpriced-data path that combines access lists with calldata to create blocks larger than the existing floor-pricing intent. eip.md · Security Considerations, lines 193-195 The claimed security effect is improved network stability from reducing the maximum block size while retaining access-list compatibility. Confidence: Medium Uncertainty: The proposal characterizes the intended effect as risk-reducing and does not enumerate failure modes, so the implementation-risk classification is inferred from the consensus-critical gas and validity consequences in the text.
Cross-EIP interactions	2	The proposal directly modifies EIP-2930 pricing and must be tested together with EIP-7623's calldata-floor objective, including combined data-bearing transactions. The interactions require coordinated cases but are confined to intrinsic gas and block-size pricing, fitting anchor 2.	eip.md · Front matter and Abstract, lines 1-16 EIP-7981 formally requires EIP-2930 and states that its new access-list charge closes a floor-pricing loophole in EIP-7623. eip.md · Specification and Test Cases, lines 24-62 and 109-117 The proposal modifies EIP-2930's access-list cost formula, while the combined access-list-plus-calldata case is expected no longer to circumvent EIP-7623. eip.md · Reference Implementation, lines 155-190 The charge is also applied to named fee-market, blob, and set-code transaction classes, though their EIP numbers are not identified in the package. Confidence: High Uncertainty: The package does not identify the EIP numbers corresponding to three additional transaction classes named by the reference implementation, so they are recorded without inferred numbers. Interacting EIPs: EIP-2930, EIP-7623
EVM Gas rule changes	1	This updates the existing intrinsic-gas accounting mechanism for access lists; it does not introduce a separate gas-accounting mechanism, matching anchor 1.	eip.md · Specification, lines 24-62 The proposal retains the existing address and storage-key charges and adds zero-byte and non-zero-byte terms to the access-list gas-cost formula. Confidence: High
Performance risks	1	The additional linear byte scan and its block-size effect merit isolated cost validation, but the mechanism is self-contained, linear, and intended to reduce worst-case payload size. This fits anchor 1 rather than a coupled benchmark risk.	eip.md · Reference Implementation, lines 124-153 The new count_access_list_bytes routine scans every address and storage-key byte and performs a simple zero/non-zero classification. eip.md · Maximum Block Size Impact, lines 75-83 The proposal quantifies its intended reduction in the maximum access-list block payload under the revised prices. Confidence: Medium Uncertainty: The package supplies analytical size examples but no benchmark data; the scan's performance cost is nevertheless directly isolatable from the specified loop.
Edge/boundary conditions	1	The single per-byte charging mechanism is boundary-prone at empty, all-zero, all-non-zero, mixed, duplicated, and exact-intrinsic-gas cases. These are a bounded set around one mechanism rather than multiple mechanisms with an elevated case explosion, fitting anchor 1.	eip.md · Specification, lines 28-62 The new mechanism separates zero from non-zero bytes across fixed-size addresses and storage keys and adds the resulting amount to intrinsic gas. supporting/eip-2930.md · Specification, lines 75-107 Access lists may be empty and may contain duplicate addresses or storage keys, with every occurrence charged, supplying edge cases for the new byte count. Confidence: Medium Uncertainty: The line between one mechanism with several input partitions and multiple edge-prone mechanisms is judgmental; the proposal specifies only one new cost calculation.

Show 21 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 22-62 The specification adds access-list cost constants and formula terms, with no opcode number, stack behavior, or EVM instruction definition.
Modified opcodes	Gas repricing outside opcode execution does not modify an opcode's behavior; therefore the binary modified-opcode anchor scores 0.	eip.md · Reference Implementation, lines 155-190 The additional charge is calculated before EVM execution as intrinsic cost, and the proposal specifies no change to any opcode's result or behavior.
Added precompiles	No precompile is introduced, so anchor 0 applies.	eip.md · Specification, lines 22-62 The specification contains only access-list gas parameters and arithmetic and defines no precompile address or callable precompile behavior.
Modified precompiles	No existing precompile logic or gas accounting is modified, matching anchor 0.	eip.md · Specification, lines 22-62 The proposal changes access-list intrinsic gas and names no precompile or precompile gas schedule.
Added system contracts	No system contract is introduced, so anchor 0 applies.	eip.md · Specification, lines 24-62 The specified feature is an intrinsic-gas formula implemented in transaction processing and defines no contract address, code, state, or system action.
Modified system contracts	No direct or indirect system-contract behavior is specified, matching anchor 0.	eip.md · Reference Implementation, lines 155-190 The implementation modifies transaction intrinsic-cost calculation only and neither calls nor changes any pre-existing system contract.
State-access ordering within opcode execution	Because the proposal neither moves a state access inside an opcode nor changes when opcode gas is charged relative to such an access, anchor 0 applies.	eip.md · Reference Implementation, lines 155-190 The new charge is computed by calculate_intrinsic_cost before execution and is added to the transaction's intrinsic cost; no opcode execution is changed.
Blob gas accounting changes	Applying an execution-gas access-list charge to a blob transaction does not modify blob gas accounting, so anchor 0 applies.	eip.md · Reference Implementation, lines 155-190 BlobTransaction is one existing transaction class receiving the same new access-list intrinsic cost, while no blob-gas variable or formula is changed.
State gas accounting changes	The proposal prices transaction input metadata rather than writing state, so it triggers none of the state-gas anchors and scores 0.	eip.md · Specification, lines 31-62 The formula charges execution gas for the byte content of transaction access lists and contains no state-write gas, state budget, reservoir, or spill rule.
New EVM gas refund	No gas-refund mechanism is introduced or modified, matching anchor 0.	eip.md · Specification, lines 43-62 The complete new calculation is an unconditional positive addition to the existing access-list cost and defines no refund condition or refund amount.
New transaction types	Repricing fields of existing transaction classes introduces no new transaction type, so the binary anchor scores 0.	eip.md · Reference Implementation, lines 155-178 The change is applied through isinstance checks to four existing transaction classes and does not define another class or type identifier.
New block / header fields	No new block or header field is introduced, so the binary anchor scores 0.	eip.md · Specification, lines 24-62 The normative parameters and calculation are transaction-level access-list gas rules and define no block or header field.
Encoding changes (RLP/SSZ)	Reading existing encoded values for pricing leaves transaction, block, and interface encodings unchanged, so the binary encoding anchor scores 0.	eip.md · Specification, lines 31-62 The new charge counts bytes in the already-defined 20-byte addresses and 32-byte storage keys; it does not change their transaction representation. supporting/eip-2930.md · Specification, lines 49-57 EIP-2930 defines the existing typed-transaction RLP payload and access-list shape that EIP-7981 reuses.
Block syncing changes	No new block RLP validation mechanism requires sync testing, so anchor 0 applies.	eip.md · Specification, lines 24-62 The proposal changes only access-list gas constants and calculation and adds no block field, block RLP rule, or block decoding condition.
New fork activation mechanism	Ordinary fork-gated application of a new gas rule is not a new activation-block mutation mechanism under this anchor, so the score is 0.	eip.md · Backwards Compatibility, lines 85-89 A scheduled network upgrade is required for the backwards-incompatible repricing, but no activation-block state or internal-variable mutation is specified.
Engine API changes	The Engine API surface is unchanged, matching anchor 0.	eip.md · Specification, lines 24-62 The complete normative change concerns transaction access-list cost and does not introduce an Engine API field, endpoint, or communication mechanism.
Transition-tool interface changes	No new transition-tool input or output field is required because the needed bytes are already in the transaction, matching anchor 0.	eip.md · Specification, lines 24-62 The normative change consists of two constants and an intrinsic-cost formula derived entirely from access-list data already present in the transaction.
New invariant on pre-existing tests	Affected tests must update existing gas expectations, which is test reworking, but pre-existing tests gain no separate new invariant, so anchor 0 applies.	eip.md · Specification, lines 43-62 The proposal replaces the numeric access-list cost formula with an augmented formula; it does not define any additional output or property for unrelated tests to assert.
New test-framework primitives	Existing transaction and gas-result primitives suffice to express the feature's tests, so no test-framework extension is indicated and anchor 0 applies.	eip.md · Test Cases, lines 91-117 The proposal's cases use ordinary transactions, access-list contents, and gas arithmetic, without defining a novel expectation type, modifier, or helper.
Cryptography	Transaction signature mechanisms are untouched, and the new accounting is non-cryptographic, so anchor 0 applies.	eip.md · Reference Implementation, lines 124-190 The implementation only classifies raw bytes as zero or non-zero and adds their gas costs; it introduces no cryptographic operation or primitive.
Unspecified behavior requiring cross-client consensus	Together the normative formula, reference code, and inherited access-list rules determine the result for empty, duplicate, zero, non-zero, mixed, address, and storage-key cases. No localized client agreement is needed to baseline tests, so anchor 0 applies.	eip.md · Specification, lines 24-62 The constants, counted byte domains, fixed address and key lengths, and exact additive access-list formula are all specified. eip.md · Reference Implementation, lines 124-190 The code specifies zero/non-zero classification, iteration over every list occurrence, affected transaction classes, and placement in intrinsic cost. supporting/eip-2930.md · Specification, lines 75-107 The inherited access-list rules clarify validation, fixed lengths, and that duplicate entries remain allowed and are charged repeatedly.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@acc2533ec9 EIPS/eip-7981.md committed 2025-08-24 · information cutoff 2025-08-26T21:52:26Z
Current master · File history · blob 7947d1cc63 · sha256 061e4fa54001
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-7981.yaml · sha256 76937733b242
Supporting documents in the sealed package: supporting/eip-2930.md, supporting/eip-7623.md

Evaluated on: 2026-08-25 · Spec revision: 2025-08-24 · acc2533ec9

Scope at the cutoff. In the sealed proposal state, EIP-7981 adds zero-byte and non-zero-byte data charges to the existing intrinsic access-list cost for every access-list-bearing transaction class shown by the reference implementation. It changes neither the access-list encoding nor execution semantics, but it is a backwards-incompatible gas repricing intended to close EIP-7623's block-size loophole and requires a scheduled network upgrade.

11MediumMedium

Evaluator: LLMChecklist v1
Confidence: Medium
Under-specified at assessment cutoff: Yes — 1 criterion affected
Plausible range: 11–12 (Medium)
Assessment cutoff: 2025-08-26 · EIP revision acc2533ec9 (2025-08-24)

Score bands · Checklist revision 1

Low <10
Medium 10–19
High ≥20

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

Complexity profile

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

Top complexity drivers

New or modified transaction validity mechanisms2
Security risks2
Performance risks2
Cross-EIP interactions2

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 normative byte-counting rule is clear, but the supplied cases cover only all-non-zero access-list bytes. They do not provide expected values for empty, all-zero, mixed, or duplicate-bearing lists, and the combined access-list plus calldata case does not state the calldata byte composition underlying its four-gas-per-byte calculation.

Plausible total

11–12
recorded score 11 · plausible tiers Medium

Affected criteria (1)

Edge/boundary conditions (1)

Unresolved questions at the cutoff (2)

What exact expected intrinsic costs apply to empty, all-zero, mixed, and duplicate-bearing access lists?
In Test Case 3, what zero/non-zero calldata composition supports the stated four-gas-per-byte old calldata cost?

Notable ambiguities noted by the assessor (3)

The historical checklist includes Engine API encoding changes but provides no dedicated definition; that row was scored conservatively with low confidence.
The proposal's test cases omit zero-byte and mixed-byte access lists even though their pricing differs materially from all-non-zero lists.
Test Case 3 states a calldata cost of four gas per byte without specifying the calldata byte composition.

Criterion breakdown

EIP-7981 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
New or modified transaction validity mechanisms	2	The intrinsic-gas calculation, which the anchor expressly treats as transaction validity, changes for existing access-list-bearing transactions; affected tests need expected-cost and gas-limit updates but no infrastructure redesign is indicated. Exceptional score: Not applicable; the score is not 4.	eip.md · Specification Every access-list transaction must pay the existing per-item costs plus new byte-sensitive charges as part of its intrinsic cost. eip.md · Backwards Compatibility The repricing is backwards incompatible and requires updated wallet and node gas estimation. Confidence: High Uncertainty: The proposal does not quantify the existing validity-test corpus, but the calculation and localized update path are explicit.
Security risks	2	Correctness interacts with the existing access-list and calldata-floor resource assumptions, so targeted review of byte counting, transaction coverage, and intrinsic-gas enforcement is warranted, while the interaction remains limited in scope. Exceptional score: Not applicable; the score is not 4.	eip.md · Abstract The proposal is intended to close an access-list loophole in EIP-7623 floor pricing. eip.md · Security Considerations Correct proportional charging is presented as reducing maximum block size and improving network stability. Confidence: Medium Uncertainty: The security section asserts improvement but does not analyze inconsistent transaction-family implementations, counting errors, or consensus effects of divergent intrinsic gas.
Performance risks	2	Byte counting is locally benchmarkable, but the intended end-to-end change in adversarial block size and the added validation work cannot be fully assessed in isolation; impact is limited to access-list-bearing traffic. Exceptional score: Not applicable; the score is not 4.	eip.md · Rationale > Maximum Block Size Impact The proposal estimates that an all-non-zero access-list-heavy 36M-gas block falls from roughly 607 KB to 362 KB. eip.md · Reference Implementation Intrinsic-cost processing gains a traversal over every address and storage-key byte in each access list. Confidence: Medium Uncertainty: No benchmarks are supplied for validation overhead, realistic byte distributions, or end-to-end block processing, so the boundary between scores 1 and 2 is not fully evidenced.
Cross-EIP interactions	2	The proposal modifies EIP-2930 pricing to preserve EIP-7623's resource-pricing objective, requiring coordinated but limited-scope testing across both mechanisms. Exceptional score: Not applicable; the score is not 4.	eip.md · Front matter and Abstract EIP-7981 requires EIP-2930 and is expressly designed to close a way of circumventing EIP-7623 floor pricing. supporting/eip-2930.md · Specification EIP-2930 supplies the existing per-item access-list charges and permits duplicates, which EIP-7981 retains while adding per-byte charges. supporting/eip-7623.md · Specification EIP-7623 defines the calldata floor whose block-size objective motivates the access-list repricing. Confidence: High Uncertainty: The reference implementation names additional existing transaction classes, but their defining EIPs are not in the allowlisted evidence; the score rests on the explicit EIP-2930 and EIP-7623 interactions.
EVM Gas rule changes	1	The proposal updates the existing intrinsic access-list gas-accounting mechanism, matching the score-1 anchor. Exceptional score: Not applicable; the score is not 4.	eip.md · Specification The existing per-address and per-storage-key access-list cost is augmented by 10 gas per zero byte and 40 gas per non-zero byte. Confidence: High Uncertainty: The added byte-count component could be described as a new sub-mechanism, but it is integrated directly into the existing access-list cost rather than establishing an independent accounting system.
Patterns affecting pre-existing tests	1	Existing tests involving non-empty access lists and their intrinsic gas expectations need updates, but the affected pattern is localized. Exceptional score: Not applicable; the score is not 4.	eip.md · Backwards Compatibility The EIP identifies a backwards-incompatible gas repricing and required updates to gas estimation while saying normal usage is largely unaffected. eip.md · Reference Implementation The changed intrinsic-cost calculation covers four access-list-bearing transaction classes. Confidence: Medium Uncertainty: The sealed sources do not inventory pre-existing tests, so the distinction between a minor and considerable subset cannot be established precisely.
Edge/boundary conditionsUnder-specified	1	One byte-classification and counting mechanism creates discernible boundary cases such as empty, all-zero, all-non-zero, mixed, and duplicate-bearing lists. Exceptional score: Not applicable; the score is not 4.	eip.md · Specification Gas depends on the exact partition of fixed-length address and storage-key bytes into zero and non-zero counts. supporting/eip-2930.md · Specification Access lists may be empty and may contain duplicate addresses or storage keys, with duplicates charged repeatedly. Confidence: Medium Uncertainty: The supplied EIP-7981 examples assume all bytes are non-zero and do not resolve the breadth of boundary-focused testing; this is recorded separately as under-specification.

Show 17 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No opcode is introduced.	eip.md · Specification The change is applied during transaction intrinsic-cost calculation and defines no opcode. Uncertainty: None material in the sealed sources.
Modified opcodes	No pre-existing opcode behavior is modified; the rubric also excludes gas-only changes from the score-3 condition.	eip.md · Reference Implementation The added charge is computed before execution as intrinsic gas and does not change opcode behavior. Uncertainty: None material in the sealed sources.
Added precompiles	No precompile is introduced.	eip.md · Reference Implementation The mechanism is ordinary intrinsic-cost calculation and introduces no precompile address or call behavior. Uncertainty: None material in the sealed sources.
Modified precompiles	No pre-existing precompile is modified.	eip.md · Specification Only access-list intrinsic gas is repriced; no precompile logic or gas schedule is mentioned. Uncertainty: None material in the sealed sources.
Added system contracts	No system contract is introduced.	eip.md · Reference Implementation The implementation consists of constants and intrinsic-cost helper logic, with no contract deployment or system address. Uncertainty: None material in the sealed sources.
Modified system contracts	No pre-existing system contract is modified directly or indirectly by the described mechanism.	eip.md · Specification The proposal changes transaction access-list gas calculation only and specifies no system-contract code, state, or behavior. Uncertainty: None material in the sealed sources.
Blob gas accounting changes	The proposal changes access-list data pricing, not blob gas accounting.	eip.md · Reference Implementation BlobTransaction is included only when calculating ordinary intrinsic access-list cost; no blob-gas variable or formula is changed. Uncertainty: The presence of BlobTransaction in the implementation scope does not itself modify blob gas accounting.
New EVM gas refund	No new gas-refund mechanism is introduced.	eip.md · Specification The new charges are always-added intrinsic access-list costs with no refund condition or refund calculation. Uncertainty: None material in the sealed sources.
New transaction types	The proposal modifies handling of existing transaction classes and introduces no transaction type.	eip.md · Reference Implementation The new cost is applied to already existing AccessListTransaction, FeeMarketTransaction, BlobTransaction, and SetCodeTransaction classes. Uncertainty: The normative prose says transactions generally, while the reference implementation enumerates the affected existing classes; neither introduces a new class.
New block / header fields	No block or block-header field is introduced.	eip.md · Specification The proposal adds two gas constants and a transaction-local access-list cost component, not block or header data. Uncertainty: None material in the sealed sources.
Encoding changes (RLP/SSZ)	No transaction, block, or interface encoding change is introduced.	supporting/eip-2930.md · Specification EIP-2930 defines the existing RLP transaction payload and access-list shape. eip.md · Specification EIP-7981 counts and prices the existing 20-byte addresses and 32-byte keys without altering their representation. Uncertainty: None material in the sealed sources.
Block syncing changes	No new block RLP validation mechanism requiring client syncing is introduced.	supporting/eip-2930.md · Specification The existing access-list RLP structure fixes addresses at 20 bytes and storage keys at 32 bytes. eip.md · Specification EIP-7981 prices the bytes already present in that structure without changing its validation or encoding. Uncertainty: None material in the sealed sources.
New fork activation mechanism	Ordinary scheduling of the rule change does not create the state or internal-variable modification required by the score-3 anchor.	eip.md · Backwards Compatibility The gas repricing requires a scheduled network upgrade, but no activation-block state or internal-variable mutation is specified. Uncertainty: The sealed proposal does not specify an activation block, but it also specifies no special activation transition.
Engine API changes	No Engine API field or communication mechanism is introduced.	eip.md · Reference Implementation The proposal changes execution-layer intrinsic-cost calculation using transaction-local access-list bytes and specifies no Engine API field or endpoint. Uncertainty: The absence of an Engine API section is consistent with the transaction-local data needed by the specified calculation.
Engine API encoding changes	Conservatively applying the row label, no Engine API encoding change is described.	eip.md · Specification The change adds byte-sensitive pricing to existing access-list contents and specifies no Engine API representation change. Uncertainty: The historical checklist provides no dedicated definition for this row, so the score is based only on the label and global score range as required.
Transition-tool interface changes	No modification to the transition-tool interface is required by the described mechanism.	eip.md · Reference Implementation The change is represented by two internal constants, byte counting, and an added intrinsic-cost term; no transition-tool field is specified. Uncertainty: The proposal does not discuss tooling explicitly, but all required inputs already exist in the transaction access list.
Cryptography	No cryptographic mechanism or cryptographic functionality is introduced or modified.	eip.md · Specification The mechanism only classifies bytes as zero or non-zero and applies fixed gas multipliers. Uncertainty: None material in the sealed sources.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@acc2533ec9 EIPS/eip-7981.md committed 2025-08-24 · information cutoff 2025-08-26T21:52:26Z
Current master · File history · blob 7947d1cc63 · sha256 061e4fa54001
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-7981.yaml · sha256 da14a23b3990
Supporting documents in the sealed package: supporting/eip-2930.md, supporting/eip-7623.md

Evaluated on: Not recorded · Spec revision: 2025-09-04 · 5aea12c20e

6LowLow

Evaluator: HumanChecklist v1
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2025-12-04 · EIP at 5aea12c20e
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 changes2
Patterns affecting pre-existing tests2
New or modified transaction validity mechanisms1
Edge/boundary conditions1

Criterion breakdown

EIP-7981 Amsterdam / Glamsterdam: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
EVM Gas rule changes	2	It's a small change but we also have to update the intrinsic gas cost calculator and probably its interface used in many access list tests to include checking the bytes in them.	—
Patterns affecting pre-existing tests	2	We have to update tests that rely on the exact intrinsic gas cost of the transactions and use access lists. Mid complexity because number of tests is not that many.	—
New or modified transaction validity mechanisms	1	Modifies the intrinsic gas cost calculation.	—
Edge/boundary conditions	1	Checks for the type of byte require boundary condition checks but minimal complexity.	—

Show 20 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Notes
Added opcodes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Modified opcodes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Added precompiles	No rationale recorded.	Blank cell read as zero because the published total proves it.
Modified precompiles	No rationale recorded.	Blank cell read as zero because the published total proves it.
Added system contracts	No rationale recorded.	Blank cell read as zero because the published total proves it.
Modified system contracts	No rationale recorded.	Blank cell read as zero because the published total proves it.
Blob gas accounting changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
New EVM gas refund	No rationale recorded.	Blank cell read as zero because the published total proves it.
New transaction types	No rationale recorded.	Blank cell read as zero because the published total proves it.
New block / header fields	No rationale recorded.	Blank cell read as zero because the published total proves it.
Encoding changes (RLP/SSZ)	No rationale recorded.	Blank cell read as zero because the published total proves it.
Block syncing changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
New fork activation mechanism	No rationale recorded.	Blank cell read as zero because the published total proves it.
Engine API changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Engine API encoding changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Transition-tool interface changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Security risks	No rationale recorded.	Blank cell read as zero because the published total proves it.
Performance risks	No rationale recorded.	Blank cell read as zero because the published total proves it.
Cryptography	No rationale recorded.	Blank cell read as zero because the published total proves it.
Cross-EIP interactions	No rationale recorded.	Blank cell read as zero because the published total proves it.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@5aea12c20e EIPS/eip-7981.md committed 2025-09-04
EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.
Current master · File history · blob f621574739 · sha256 558a702401bf
Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Merged checklist ethspecs/pm@eb0d24aec5 complexity_assessments/EIPs/EIP-7981.md · committed 2025-12-04
blob 69f777a90c · sha256 7bbd980c0a04
Research record: research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7981.yaml · sha256 d6bacd2127c0

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

LLM11Medium

Human6Low

Δ total+5Tiers differ: Medium vs Low

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

Exposure evidence

The assessment reasons from an existing intrinsic-gas calculator interface used by many access-list tests.

Substantive intervening revisions: Re-parameterises the surcharge in terms of the EIP-7623 token abstraction. The two EIP-owned constants ACCESS_LIST_NONZERO_BYTE_COST and ACCESS_LIST_ZERO_BYTE_COST are replaced in the parameter table by TOTAL_COST_FLOOR_PER_TOKEN = 10, sourced from EIP-7623, and the formula becomes access_list_tokens = nonzero * 4 + zero followed by access_list_data_cost = access_list_tokens * TOTAL_COST_FLOOR_PER_TOKEN. Description, Abstract and Motivation are rewritten (adding the '~21% worst-case block size reduction' claim and the 'contributing to EVM gas while still lea…

Complexity profiles side by side

LLM

Human

Largest disagreements: Performance risks (+2), Security risks (+2), Cross-EIP interactions (+2), EVM Gas rule changes (−1), Patterns affecting pre-existing tests (−1)

Show differences only (6 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
Security risks	2	0	+2	Differ by 2+	Show rationale LLM Correctness interacts with the existing access-list and calldata-floor resource assumptions, so targeted review of byte counting, transaction coverage, and intrinsic-gas enforcement is warranted, while the interaction remains limited in scope. Human No rationale recorded.
Performance risks	2	0	+2	Differ by 2+	Show rationale LLM Byte counting is locally benchmarkable, but the intended end-to-end change in adversarial block size and the added validation work cannot be fully assessed in isolation; impact is limited to access-list-bearing traffic. Human No rationale recorded.
Cross-EIP interactions	2	0	+2	Differ by 2+	Show rationale LLM The proposal modifies EIP-2930 pricing to preserve EIP-7623's resource-pricing objective, requiring coordinated but limited-scope testing across both mechanisms. Human No rationale recorded.
EVM Gas rule changes	1	2	−1	Differ by 1	Show rationale LLM The proposal updates the existing intrinsic access-list gas-accounting mechanism, matching the score-1 anchor. Human It's a small change but we also have to update the intrinsic gas cost calculator and probably its interface used in many access list tests to include checking the bytes in them.
New or modified transaction validity mechanisms	2	1	+1	Differ by 1	Show rationale LLM The intrinsic-gas calculation, which the anchor expressly treats as transaction validity, changes for existing access-list-bearing transactions; affected tests need expected-cost and gas-limit updates but no infrastructure redesign is indicated. Human Modifies the intrinsic gas cost calculation.
Patterns affecting pre-existing tests	1	2	−1	Differ by 1	Show rationale LLM Existing tests involving non-empty access lists and their intrinsic gas expectations need updates, but the affected pattern is localized. Human We have to update tests that rely on the exact intrinsic gas cost of the transactions and use access lists. Mid complexity because number of tests is not that many.
Added opcodes	0	0	0	Agree	Show rationale LLM No opcode is introduced. Human No rationale recorded.
Modified opcodes	0	0	0	Agree	Show rationale LLM No pre-existing opcode behavior is modified; the rubric also excludes gas-only changes from the score-3 condition. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM No precompile is introduced. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM No pre-existing precompile is modified. Human No rationale recorded.
Added system contracts	0	0	0	Agree	Show rationale LLM No system contract is introduced. Human No rationale recorded.
Modified system contracts	0	0	0	Agree	Show rationale LLM No pre-existing system contract is modified directly or indirectly by the described mechanism. Human No rationale recorded.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM The proposal changes access-list data pricing, not blob gas accounting. Human No rationale recorded.
New EVM gas refund	0	0	0	Agree	Show rationale LLM No new gas-refund mechanism is introduced. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM The proposal modifies handling of existing transaction classes and introduces no transaction type. Human No rationale recorded.
New block / header fields	0	0	0	Agree	Show rationale LLM No block or block-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 change is introduced. Human No rationale recorded.
Block syncing changes	0	0	0	Agree	Show rationale LLM No new block RLP validation mechanism requiring client syncing is introduced. Human No rationale recorded.
New fork activation mechanism	0	0	0	Agree	Show rationale LLM Ordinary scheduling of the rule change does not create the state or internal-variable modification required by the score-3 anchor. Human No rationale recorded.
Engine API changes	0	0	0	Agree	Show rationale LLM No Engine API field or communication mechanism is introduced. Human No rationale recorded.
Engine API encoding changes	0	0	0	Agree	Show rationale LLM Conservatively applying the row label, no Engine API encoding change is described. Human No rationale recorded.
Transition-tool interface changes	0	0	0	Agree	Show rationale LLM No modification to the transition-tool interface is required by the described mechanism. Human No rationale recorded.
Edge/boundary conditions	1	1	0	Agree	Show rationale LLM One byte-classification and counting mechanism creates discernible boundary cases such as empty, all-zero, all-non-zero, mixed, and duplicate-bearing lists. Human Checks for the type of byte require boundary condition checks but minimal complexity.
Cryptography	0	0	0	Agree	Show rationale LLM No cryptographic mechanism or cryptographic functionality is introduced or modified. Human No rationale recorded.

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