{
"assessments": {
"amsterdam:2780:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [
"Blank cells are interpreted as zero only because the published total exactly equals the sum of every nonblank parsed contribution."
],
"published_tier": "medium",
"published_total": 13,
"recomputed_tier": "medium",
"recomputed_total": 13,
"timing_exposure": "possible_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Affects the intrinsic gas cost of every transaction, which could break many pre-existing tests.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Minimal testing required due to type-3 transaction changing its intrinsic gas cost too.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "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.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "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.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "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.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Does not pose a performance risk but rather affects how we calculate worst case scenarios because more transactions (potentially) fit in each block.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 2780,
"fork": "amsterdam",
"id": "amsterdam:2780:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "d5e16901ed417747af2177275838c74075a61d38",
"committed_at": "2025-10-26T10:26:32Z",
"content_sha256": "3c6c007bdadbe15435cbdbca04cbf7bbf08272aeff492664a18681951cdaf71f",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2780.md",
"git_blob_sha": "5b09bf7e29956e8037a538addf885b6ba4052ef0",
"immutable_url": "https://github.com/ethereum/EIPs/blob/d5e16901ed417747af2177275838c74075a61d38/EIPS/eip-2780.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-2780.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-2780.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-2780.yaml",
"sha256": "d3e77c8c9c5a7d0578e8b302a97f8a5b3cc137d1b20e0148f70ba2a8dcaaca91"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "d49a44fe77adadea547a939e4e473a949e7b5a99",
"committed_at": "2025-11-05T23:48:51Z",
"content_sha256": "057e21adfca9f56416c7d699ed21b1d91d2a0cd7fd646028ddad62919696e144",
"git_blob_sha": "e31e27bde7d154975dae24f29929e540c88f014a",
"immutable_url": "https://github.com/ethspecs/pm/blob/d49a44fe77adadea547a939e4e473a949e7b5a99/complexity_assessments/EIPs/EIP-2780.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-2780.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 13,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "medium",
"title": "Resource-based intrinsic transaction gas",
"under_specification": null
},
"amsterdam:2780:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters; New-account surcharge; Intrinsic gas computation",
"source": "eip.md",
"summary": "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."
},
{
"locator": "Specification, paragraph beginning “At the beginning of execution”",
"source": "supporting/eip-2930.md",
"summary": "The pre-change access-list transaction intrinsic calculation uses the existing 21,000 base, showing the mechanism being replaced."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "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.",
"score": 3,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Intrinsic gas computation",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas accounting mechanism is added or modified, so the row’s zero anchor applies.",
"score": 0,
"uncertainty_note": "The conclusion is based on the proposal’s expressly limited normative scope and the absence of any blob-gas rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Intrinsic gas computation, CalculateIntrinsicGas pseudocode",
"source": "eip.md",
"summary": "The calculation changes upfront intrinsic charges only and contains no refund counter, refund condition, or refund schedule."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no gas-refund mechanism.",
"score": 0,
"uncertainty_note": "No refund behavior is specified anywhere in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Intrinsic gas computation; Test Cases",
"source": "eip.md",
"summary": "Requires replacement of the 21,000 base for each typed transaction and adds state-, value-, destination-, and creation-sensitive vectors."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Calls the change a non-backward-compatible consensus gas repricing and says wallets, RPCs, estimators, and logic assuming a 21,000 base must update."
},
{
"locator": "Specification, intrinsic-cost paragraph",
"source": "supporting/eip-1559.md",
"summary": "The EIP-1559 transaction type inherits an intrinsic formula beginning at 21,000, one of the established test patterns affected by the replacement."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "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.",
"score": 3,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Intrinsic gas computation, CalculateIntrinsicGas pseudocode",
"source": "eip.md",
"summary": "Expresses the rule as an intrinsic-gas calculation over the transaction and start-state, without adding any transition-tool input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Although transition execution must apply the new rule, the proposal specifies no transition-tool interface field or new interface mechanism.",
"score": 0,
"uncertainty_note": "The sealed sources do not define the transition-tool interface itself; score 0 reflects the absence of any requested interface modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Derivation; Rationale",
"source": "eip.md",
"summary": "Treats existing ECDSA signature recovery as part of the base-cost derivation but introduces no new algorithm, primitive, signature rule, or cryptographic behavior."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Repricing already-performed signature recovery is not a new or modified cryptographic mechanism.",
"score": 0,
"uncertainty_note": "No cryptographic change is specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > New-account surcharge; Test Cases",
"source": "eip.md",
"summary": "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."
},
{
"locator": "Specification, clauses b–d and definitions of empty and dead",
"source": "supporting/eip-161.md",
"summary": "Account existence semantics distinguish non-existent, empty, and dead accounts and include transaction-end deletion behavior."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "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.",
"score": 2,
"uncertainty_note": "“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.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "Defines a consensus intrinsic-gas repricing but no block RLP field, decoding rule, or RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "The historical row is specifically about block RLP validation requiring syncing tests, and no such mechanism is introduced.",
"score": 0,
"uncertainty_note": "No block-RLP change appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Intrinsic gas computation; Backwards Compatibility",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API directive or field is introduced.",
"score": 0,
"uncertainty_note": "The package contains no Engine API specification; score 0 is based on the proposal not requesting an Engine API change.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Intrinsic gas computation; Rationale > Why not charge full tx data as calldata?",
"source": "eip.md",
"summary": "Changes arithmetic applied to existing transactions and explicitly avoids coupling the fee rule to envelope encoding; no Engine API encoding is described."
}
],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Conservatively applying the row label and global scale, the proposal contains no Engine API encoding change, so score 0 is warranted.",
"score": 0,
"uncertainty_note": "The historical checklist provides no dedicated definition for this row; no substitute definition was imported.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Adds two gas parameters and transaction-processing rules only; no contract address, code, deployment, or system action is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No system-contract addition is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters; Intrinsic gas computation",
"source": "eip.md",
"summary": "The normative change is confined to intrinsic transaction gas and does not modify any system-contract code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or described indirect modification to a pre-existing system contract is introduced.",
"score": 0,
"uncertainty_note": "No system contract is identified in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Specifies constants and top-level transaction intrinsic-gas logic, with no opcode number, stack behavior, or new instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No opcode addition is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Intrinsic gas computation; Derivation",
"source": "eip.md",
"summary": "Changes transaction-level intrinsic gas; mentions ECRECOVER only as a cost proxy and does not alter any existing opcode’s behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified, and the row expressly excludes mere gas changes in any event.",
"score": 0,
"uncertainty_note": "No opcode behavior change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > New-account surcharge",
"source": "eip.md",
"summary": "Existing precompiles are only excluded from the new-account surcharge; no new precompile is defined."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "The precompile predicate relies on the existing precompile set.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > New-account surcharge; Test Cases, vector 2",
"source": "eip.md",
"summary": "A transfer to a precompile keeps the 6,000 intrinsic base and receives no surcharge, but no precompile logic or precompile gas schedule changes."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "The exemption is transaction intrinsic-gas logic around a destination, not a modification to any precompile.",
"score": 0,
"uncertainty_note": "No precompile implementation behavior is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Why not charge full tx data as calldata? > Serialization neutrality",
"source": "eip.md",
"summary": "The proposal deliberately keeps the base encoding-agnostic and does not alter the transaction envelope’s RLP or introduce another encoding."
},
{
"locator": "Specification > Transactions",
"source": "supporting/eip-2718.md",
"summary": "Defines the existing typed and legacy transaction envelopes that EIP-2780 continues to process without a format change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding changes are introduced.",
"score": 0,
"uncertainty_note": "No RLP-to-SSZ or other format transition is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Code change example; Edits and interactions with other EIPs",
"source": "eip.md",
"summary": "Existing EIP-1559 and EIP-2930 typed transactions inherit the new TX_BASE_COST; no new type identifier or payload is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The proposal modifies processing of existing transaction types and introduces no new transaction type.",
"score": 0,
"uncertainty_note": "The reference to EIP-7702 is an interaction with an existing type, not a definition of a new one in this proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > New-account surcharge; Intrinsic gas computation; Test Cases",
"source": "eip.md",
"summary": "Makes intrinsic gas depend on start-state account existence and changes the required base for every transaction type, with explicit valid-cost boundary vectors."
},
{
"locator": "Specification, invalid-transaction paragraph",
"source": "supporting/eip-7623.md",
"summary": "Existing validity takes the maximum of the calldata floor and intrinsic gas, so changing the base propagates into gas-limit validity checks."
},
{
"locator": "Specification, invalid-transaction paragraph",
"source": "supporting/eip-7976.md",
"summary": "The later calldata-floor rule likewise compares the gas limit with an intrinsic calculation beginning at the old 21,000 base."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "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.",
"score": 3,
"uncertainty_note": "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.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters",
"source": "eip.md",
"summary": "Introduces transaction gas constants and rules only, with no block or block-header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "No header-format change is specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, opening sentence",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "A normal fork-gated rule change is specified, but no new activation mechanism or activation-block state/internal-variable modification is introduced.",
"score": 0,
"uncertainty_note": "FORK_BLOCK is left as a placeholder, but the missing activation value does not itself establish the score-3 mechanism defined by the row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract > Capacity Impact; Motivation > Equivalent gas-limit increase; Backwards Compatibility > Effects on transactions per block",
"source": "eip.md",
"summary": "Claims an average 18.5% throughput increase, up to 250% more minimal transactions, and analyzes interactions with much larger transaction counts and block limits."
},
{
"locator": "Test Cases; Security Considerations",
"source": "eip.md",
"summary": "Calls for blocks of transfers across all execution clients and warns that the significantly increased maximum transaction count carries risk."
},
{
"locator": "Specification > Block Size Cap",
"source": "supporting/eip-7934.md",
"summary": "Defines the independent RLP block-size ceiling that can become the binding resource as cheaper transactions increase count."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "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.",
"score": 3,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations; Abstract > Capacity Impact",
"source": "eip.md",
"summary": "Explicitly identifies risk from a significantly higher maximum transaction count while reducing the base charge by 71% for minimal existing-account transfers."
},
{
"locator": "Motivation; Specification > New-account surcharge",
"source": "eip.md",
"summary": "Changes the resource-pricing assumptions for universal transaction work and adds a state-growth charge keyed to account existence."
},
{
"locator": "Addendum; Specification",
"source": "supporting/eip-161.md",
"summary": "Shows that empty/non-existent account handling is consensus-sensitive and historically required precise revert and deletion semantics."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "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.",
"score": 3,
"uncertainty_note": "The proposal acknowledges risk but provides only brief security analysis, so the exact breadth of necessary review is not fully specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter, requires; Specification > Edits and interactions with other EIPs",
"source": "eip.md",
"summary": "Requires EIPs 1559, 2718, 2929, and 2930 and explicitly coordinates the new base with EIP-2930, EIP-7702, and active calldata-pricing rules."
},
{
"locator": "Specification, intrinsic-cost paragraph",
"source": "supporting/eip-1559.md",
"summary": "The EIP-1559 type inherits EIP-2930’s fixed 21,000-based intrinsic formula, which must be revised coherently."
},
{
"locator": "Specification",
"source": "supporting/eip-7623.md",
"summary": "Its calldata floor and validity formulas embed the 21,000 transaction base, creating a direct formula-level interaction."
},
{
"locator": "Specification for aggregate and hybrid EVM gas, get_required_max_fee pseudocode",
"source": "supporting/eip-7999.md",
"summary": "Treats TX_BASE_COST as a deterministic fee component, showing another fee-market mechanism whose accounting depends on the base."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "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.",
"score": 3,
"uncertainty_note": "EIP-7702 is named by the proposal but is not included in the allowlisted supporting sources, and the CREATE ambiguity may affect coordinated vectors.",
"under_specified": true
}
],
"eip": 2780,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:2780:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"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."
],
"provenance": {
"assessed_revision": {
"commit": "2fd1e5e98e9150750217ddd5d5f22291d5c1e2a6",
"committed_at": "2025-09-08T06:11:31Z",
"content_sha256": "93fb43bd87187541673e77373b944bdf54f8d519fe00264698a633b3de1884ee",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2780.md",
"git_blob_sha": "61527a7b300578d3d08a6439efd16093130eedcb",
"immutable_url": "https://github.com/ethereum/EIPs/blob/2fd1e5e98e9150750217ddd5d5f22291d5c1e2a6/EIPS/eip-2780.md",
"information_cutoff_at": "2025-09-12T13:12:54Z",
"path": "EIPS/eip-2780.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-2780.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-2780.yaml",
"sha256": "12ba5918596612a4282dce63638650fc436915832f1a809c132f0c32e08af5f4"
},
"supporting_documents": [
"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"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 20,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "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.",
"tier": "high",
"title": "Resource-based intrinsic transaction gas",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"new_or_modified_transaction_validity_mechanisms",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 21,
"minimum": 18
},
"present": true,
"summary": "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.",
"unresolved_questions": [
"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?"
]
}
},
"amsterdam:2780:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Parameters and New-account surcharge, lines 57-77",
"source": "eip.md",
"summary": "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."
},
{
"locator": "Specification — Intrinsic gas computation, lines 84-120",
"source": "eip.md",
"summary": "Normative pseudocode changes intrinsic gas for existing transaction formats and makes it depend on state at the start of the transaction."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "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.",
"score": 3,
"uncertainty_note": "The intended CREATE-transaction treatment has conflicting wording, recorded under under-specification, but does not change that the proposal triggers anchor 3.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification — Intrinsic gas computation, lines 14-22 and 84-109",
"source": "eip.md",
"summary": "The change is confined to initial transaction intrinsic-gas processing; the pseudocode does not alter state access or gas charging within any opcode."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The state lookup used to calculate top-level intrinsic gas is not a change to ordering inside opcode execution, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 16-22",
"source": "eip.md",
"summary": "The proposal changes transaction intrinsic gas while expressly leaving calldata and access-list metering unchanged; it specifies no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas accounting mechanism or parameter is changed, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Parameters and Intrinsic gas computation, lines 61-109",
"source": "eip.md",
"summary": "State growth is priced through an ordinary intrinsic-gas surcharge; no state-gas budget, state-gas charging site, reservoir, or spill rule is introduced."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal uses execution/intrinsic gas rather than the rubric's separate state-gas accounting system, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Intrinsic gas computation, lines 84-109",
"source": "eip.md",
"summary": "The normative calculation only adds intrinsic charges and returns the resulting cost; it defines no refund path."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Intrinsic gas computation and Edits and interactions with other EIPs, lines 84-127",
"source": "eip.md",
"summary": "Every hardcoded 21,000 base is replaced for existing typed transactions, and existing EIP-2930-derived intrinsic formulas inherit the new base."
},
{
"locator": "Backwards Compatibility and Test Cases, lines 177-181 and 226-239",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "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.",
"score": 3,
"uncertainty_note": "Exact test counts are not supplied, but the affected rule is universal across transaction formats.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Intrinsic gas computation, lines 84-109",
"source": "eip.md",
"summary": "The proposal changes the intrinsic-gas result itself but does not add a new protocol output or assertion that unrelated tests must additionally check."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing expectations must be reworked, but unrelated tests do not gain a distinct new invariant to assert; anchor 0 applies.",
"score": 0,
"uncertainty_note": "Some harnesses may mechanically assert the recalculated intrinsic result, but that is an updated expectation rather than a new invariant.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 57-127",
"source": "eip.md",
"summary": "The specification changes intrinsic transaction processing and parameters but introduces no transition-tool request or response field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "State-aware execution logic changes do not by themselves add or modify the transition-tool interface, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "The EIP does not discuss transition-tool integration; the score is based strictly on the absence of an interface change in the packaged text.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases, lines 226-239",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing transaction, state, and block test primitives are sufficient for the described cases, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "The package does not describe the historical test framework's exact helper inventory.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Derivation, lines 128-147",
"source": "eip.md",
"summary": "ECDSA recovery appears only as an unchanged cost component used to derive the 6,000-gas base; no cryptographic algorithm or functionality changes."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Repricing unchanged signature recovery does not introduce or modify cryptography, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — New-account surcharge, lines 68-82",
"source": "eip.md",
"summary": "The surcharge branches on creation versus call, zero versus positive value, precompile status, and EIP-161 destination existence at transaction start."
},
{
"locator": "Test Cases, lines 226-239",
"source": "eip.md",
"summary": "Explicit vectors combine recipient state, precompiles, value boundaries, creation, typed access lists, and maximal-address contract execution."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "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.",
"score": 3,
"uncertainty_note": "The CREATE wording and EIP-161 existence terminology leave two boundary expectations under-specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-127",
"source": "eip.md",
"summary": "The consensus change is to transaction intrinsic-gas calculation; no block RLP validation rule is introduced or modified."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Higher possible transaction counts do not constitute an RLP validation mechanism, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-127",
"source": "eip.md",
"summary": "The specification adds no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is specified, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-127",
"source": "eip.md",
"summary": "The proposal consists of gas constants and transaction-processing rules and deploys no contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-22 and 57-127",
"source": "eip.md",
"summary": "The focused change applies before transaction execution and identifies no existing system contract code, state, or special action affected by it."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "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.",
"score": 0,
"uncertainty_note": "The package does not enumerate system contracts, so only explicit proposal effects are scored.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-127",
"source": "eip.md",
"summary": "The specification changes transaction intrinsic gas and defines no opcode number, stack behavior, or EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification — Intrinsic gas computation, lines 16-22 and 84-109",
"source": "eip.md",
"summary": "The change occurs during initial transaction processing, and the normative pseudocode modifies no opcode result or non-gas behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified; gas-only context would be excluded by this anchor in any event. Anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — New-account surcharge, lines 68-77",
"source": "eip.md",
"summary": "Existing precompiles are only recognized as destinations exempt from the new-account surcharge; none is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — New-account surcharge and Test Cases, lines 68-77 and 232-238",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "An exemption in transaction intrinsic accounting is not a modification to a precompile's gas schedule or behavior, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale — Why not charge full tx data as calldata?, lines 165-171",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP-to-SSZ or other encoding change is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Code change example and Edits and interactions with other EIPs, lines 111-127",
"source": "eip.md",
"summary": "Existing typed transactions inherit the replacement base cost; the proposal assigns no new EIP-2718 type or payload."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The EIP modifies existing transaction formats rather than introducing a new type, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Intrinsic gas computation, lines 84-109",
"source": "eip.md",
"summary": "Intrinsic gas for all existing transaction formats changes, and the calculation gains a state-at-start input plus a conditional destination-state surcharge."
},
{
"locator": "Backwards Compatibility, lines 177-181",
"source": "eip.md",
"summary": "The EIP identifies the repricing as consensus-incompatible and requires wallets, RPCs, estimators, and all logic assuming a 21,000 base to update."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "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.",
"score": 3,
"uncertainty_note": "The package does not detail test-infrastructure changes, and the exact CREATE path is textually inconsistent.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-127",
"source": "eip.md",
"summary": "The specification changes transaction-level gas parameters and rules without adding a block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-66",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork-gated rule activation without an activation-block state modification is anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract — Capacity Impact, lines 24-28",
"source": "eip.md",
"summary": "The proposal estimates 18.5% more average transactions and up to 250% more minimal transactions per block at an unchanged nominal gas limit."
},
{
"locator": "Test Cases and Security Considerations, lines 226-247",
"source": "eip.md",
"summary": "It calls for all-client Perfnet blocks of ETH transfers and contract-activation workloads and acknowledges risk from significantly increasing maximum transaction count."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "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.",
"score": 3,
"uncertainty_note": "The EIP supplies claimed headroom but no packaged all-client result for the specified workloads.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — New-account surcharge, lines 68-77",
"source": "eip.md",
"summary": "Consensus intrinsic cost now depends on state existence, value, transaction kind, and precompile classification, with the surcharge intended to preserve state-growth pricing."
},
{
"locator": "Security Considerations, lines 241-247",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "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.",
"score": 3,
"uncertainty_note": "The security section is brief and does not quantify client-specific resource or state-growth limits.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — New-account surcharge, lines 68-82",
"source": "eip.md",
"summary": "The condition says 'non-existent per EIP-161 emptiness,' while adjacent notes alternate among non-existent, empty, creation, and no-creation terminology."
},
{
"locator": "Specification — Intrinsic gas computation and Test Cases, lines 84-109 and 232-238",
"source": "eip.md",
"summary": "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."
},
{
"locator": "Specification, lines 20-36",
"source": "supporting/eip-161.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "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.",
"score": 2,
"uncertainty_note": "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.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter and Specification — New-account surcharge, lines 1-12 and 68-77",
"source": "eip.md",
"summary": "The EIP declares dependencies on EIPs 1559, 2718, 2929, and 2930, and normatively relies on EIP-161 destination-account semantics."
},
{
"locator": "Specification — Code change example and Edits and interactions with other EIPs, lines 111-127",
"source": "eip.md",
"summary": "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."
},
{
"locator": "Rationale and Backwards Compatibility — Effects on transactions per block, lines 165-195",
"source": "eip.md",
"summary": "The text connects envelope neutrality and calldata floors to EIPs 2718, 7623, and 7976, and identifies capacity interactions with EIPs 7934, 7782, and 7999."
},
{
"locator": "Specification, lines 29-59",
"source": "supporting/eip-7976.md",
"summary": "EIP-7976's calldata-floor and validity formulas embed a 21,000 base, so coactivation requires coordinated replacement or composition."
},
{
"locator": "Specification for aggregate and hybrid EVM gas, lines 429-459",
"source": "supporting/eip-7999.md",
"summary": "EIP-7999 treats TX_BASE_COST as a deterministic fee component, creating a direct formula interaction with this repricing."
}
],
"exceptional_score_justification": "Cross-EIP interactions is explicitly uncapped: 11 identified interacting EIPs produce score 3 + floor((11 - 3) / 3) = 5.",
"id": "cross_eip_interactions",
"interacting_eips": [
161,
1559,
2718,
2929,
2930,
7623,
7702,
7782,
7934,
7976,
7999
],
"rationale": "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.",
"score": 5,
"uncertainty_note": "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.",
"under_specified": false,
"unidentified_interactions": [
"The specification says any other active calldata-pricing EIPs continue to supply GasForCalldata unchanged, but it does not identify their EIP numbers."
]
}
],
"eip": 2780,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:2780:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"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."
],
"provenance": {
"assessed_revision": {
"commit": "2fd1e5e98e9150750217ddd5d5f22291d5c1e2a6",
"committed_at": "2025-09-08T06:11:31Z",
"content_sha256": "93fb43bd87187541673e77373b944bdf54f8d519fe00264698a633b3de1884ee",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2780.md",
"git_blob_sha": "61527a7b300578d3d08a6439efd16093130eedcb",
"immutable_url": "https://github.com/ethereum/EIPs/blob/2fd1e5e98e9150750217ddd5d5f22291d5c1e2a6/EIPS/eip-2780.md",
"information_cutoff_at": "2025-09-12T13:12:54Z",
"path": "EIPS/eip-2780.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-2780.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-2780.yaml",
"sha256": "23973bd9b6f6a75fac3960a4f82a8480b2b9687c9a792406c3c15598b00ed483"
},
"supporting_documents": [
"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"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 25,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "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.",
"tier": "high",
"title": "Resource-based intrinsic transaction gas",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"edge_boundary_conditions",
"new_or_modified_transaction_validity_mechanisms",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 26,
"minimum": 24
},
"present": true,
"summary": "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.",
"unresolved_questions": [
"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?"
]
}
},
"amsterdam:7610:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [],
"published_tier": "low",
"published_total": 7,
"recomputed_tier": "low",
"recomputed_total": 7,
"timing_exposure": "possible_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Some static tests might break as noted by Pawel in the magicians thread.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "EELS might be updated to handle this EIP.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The EIP is an even stricter version of `684`, adding the rule that the storage also has to be empty.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The EIP helps improve security.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7610,
"fork": "amsterdam",
"id": "amsterdam:7610:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "7707fe333322ed68d1b5efa50bdb4f35909255a7",
"committed_at": "2025-11-06T01:04:36Z",
"content_sha256": "e934db8fded813da2d2cf231dbdcd0f829418b5394db3750fb31292d3dbfacd6",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7610.md",
"git_blob_sha": "5e96d303039e4bf1d9ee1d597ca70baadfa5822b",
"immutable_url": "https://github.com/ethereum/EIPs/blob/7707fe333322ed68d1b5efa50bdb4f35909255a7/EIPS/eip-7610.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7610.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7610.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7610.yaml",
"sha256": "2bd91d1cf2c5699ae7c47c881995ed3f5a8dde146a8b477f08c9416e366f9cfc"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "0a80baf1747d4fe9f0ee65446e3f70d06b01a8ba",
"committed_at": "2026-01-09T11:28:09Z",
"content_sha256": "ebca2ea04f8fbfff2242022fa5680acc97716c71c80111a621b9dd4def51608a",
"git_blob_sha": "d9250b95ed69fe6a0662e55d941cb375f3b00270",
"immutable_url": "https://github.com/ethspecs/pm/blob/0a80baf1747d4fe9f0ee65446e3f70d06b01a8ba/complexity_assessments/EIPs/EIP-7610.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7610.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 7,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "low",
"title": "Revert creation in case of non-empty storage",
"under_specification": null
},
"amsterdam:7610:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, second paragraph",
"source": "eip.md",
"summary": "Adds non-empty storage to the destination-address collision predicate and requires creation to throw; it specifies no gas schedule or accounting rule."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes a contract-creation failure condition, not an EVM gas-accounting mechanism, so the no-change anchor applies.",
"score": 0,
"uncertainty_note": "The invalid-opcode-equivalent failure changes which attempts consume failure-path gas, but the package defines no gas-accounting rule or schedule change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "The proposal is limited to rejecting contract creation at an address with non-empty storage; no blob behavior or blob accounting is specified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None material within the package; the normative scope is execution-layer contract creation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The only prescribed outcome is a creation throw on a destination collision involving nonce, code, or storage; no refund is prescribed."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "The package does not discuss refunds, but nothing in the specified rule creates or modifies one.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "States that quite a number of existing Ethereum tests and execution-spec tests cover deployment to targets with non-empty storage and that refilling those tests provides coverage."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable existing-test subset is described as affected, but it is confined to the contrived category of deployment against destinations with non-empty storage.",
"score": 2,
"uncertainty_note": "The package gives no test count, fork matrix, or inventory, so the affected subset could prove minor rather than considerable.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Defines an internal contract-creation collision check and failure outcome without adding any transition-tool input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "The transition tool is not discussed explicitly, so implementation implications are not enumerated, but the proposal requests no interface data.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "The change is a state predicate over destination nonce, code length, and storage emptiness; it introduces no cryptographic primitive or operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None material; cryptography is outside the stated mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, second paragraph",
"source": "eip.md",
"summary": "Introduces one new collision boundary—empty versus non-empty destination storage—and applies it to creation transactions, CREATE, CREATE2, and any other creation cause."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The storage-emptiness decision is one edge-condition-prone mechanism; the several creation entry paths are applications of that same predicate.",
"score": 1,
"uncertainty_note": "The open-ended phrase 'any other reason' and retroactive application may add cases, but the package does not enumerate them or define a larger boundary matrix.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Changes execution-time contract-creation collision handling and defines no block RLP field or RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism requiring sync testing is introduced.",
"score": 0,
"uncertainty_note": "Retroactive application may motivate historical execution tests, but the rubric row is specifically about block RLP validation, which is unchanged in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative rule uses existing account state and creation execution; it adds no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API fields or endpoints are introduced.",
"score": 0,
"uncertainty_note": "The Engine API is not discussed explicitly, but no new information exchange is specified.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Specifies only a contract-creation state predicate and throw behavior, with no Engine API encoding change."
},
{
"locator": "Checklist row 'Engine API encoding changes'",
"source": "rubric.md",
"summary": "The checklist contains this row but provides no dedicated scoring definition."
}
],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Scored conservatively from the row label: the proposal describes no Engine API encoding change.",
"score": 0,
"uncertainty_note": "The historical checklist has no dedicated definition for this row, so the exact intended scoring boundary is unavailable.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "Adds a general contract-creation rejection condition and does not deploy or designate any system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contract is introduced.",
"score": 0,
"uncertainty_note": "None material; no contract address, code, state, or system action is specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Applies a general creation-collision rule without naming or changing the code or state of any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal does not directly or indirectly identify a modification to a pre-existing system contract.",
"score": 0,
"uncertainty_note": "The package does not inventory system-contract creation behavior, but it identifies no system contract affected by the change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, second paragraph",
"source": "eip.md",
"summary": "References the existing CREATE and CREATE2 opcodes as entry paths and introduces no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None material; all named opcodes are pre-existing mechanisms being covered by the rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, second paragraph",
"source": "eip.md",
"summary": "Requires attempts caused by CREATE or CREATE2 to throw when the destination has non-empty storage, adding a new non-gas failure condition."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The binary rubric anchor assigns 3 when any pre-existing opcode behavior changes; both CREATE and CREATE2 gain an additional failure case.",
"score": 3,
"uncertainty_note": "The rule also covers creation transactions and other causes, but that broader scope does not change the direct opcode modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "The proposal adds a creation-collision condition and specifies no precompile address, interface, or logic."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None material; precompiles are absent from the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No precompile behavior or gas accounting is part of the contract-creation collision rule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "None material; the package identifies no precompile interaction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Changes an execution validity outcome without adding or changing transaction, block, interface, RLP, or SSZ encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No encoding change is introduced at transaction, block, or interface level.",
"score": 0,
"uncertainty_note": "None material; the proposal defines no serialized field or format.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, second paragraph",
"source": "eip.md",
"summary": "Applies to an existing creation transaction and opcode-based creation paths; it defines no new transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None material; creation transactions are an existing path within the proposal's stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, second paragraph",
"source": "eip.md",
"summary": "A creation transaction encountering the new collision condition throws as if init code began with an invalid opcode; the transaction itself is not declared invalid and intrinsic gas is unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The change affects execution outcome for contract creation, not transaction validity rules or intrinsic gas calculation.",
"score": 0,
"uncertainty_note": "There is a rubric-boundary ambiguity between transaction execution failure and transaction invalidity, but the specification consistently describes a throw rather than invalidation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Defines a contract-creation state check and adds no block or block-header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced.",
"score": 0,
"uncertainty_note": "None material; block structure is outside the specified change.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Backwards Compatibility",
"source": "eip.md",
"summary": "States that the rule applies retroactively and requires a hard fork, but specifies no state or internal-variable modification at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "A fork is required, but the rubric scores activation-block state or internal-variable modifications, none of which are specified.",
"score": 0,
"uncertainty_note": "The relationship between retroactive application and hard-fork activation is not explained, though no activation-block state transition is stated.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Adds a destination-storage-emptiness predicate to contract creation but gives no performance requirement, benchmark concern, or broader performance mechanism."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "On the sealed evidence, no mechanism is identified as requiring performance validation, so the zero anchor is applied.",
"score": 0,
"uncertainty_note": "The package omits how storage emptiness is determined and its cost; an isolated performance check could justify score 1 if that detail were material.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Calls the proposal a security upgrade that enforces immutability of deployed code."
},
{
"locator": "Specification and Rationale",
"source": "eip.md",
"summary": "Changes creation collision handling for all creation paths to protect addresses having zero nonce and code length but non-empty storage."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches a limited set of critical components—contract creation, collision checks, and destination storage—and changes a code-immutability security assumption, warranting targeted review and fuzzing.",
"score": 2,
"uncertainty_note": "The package does not specify review or fuzzing breadth, so a self-contained score of 1 remains plausible; it does not support the multi-component breadth required for 3.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale",
"source": "eip.md",
"summary": "Explicitly amends EIP-684 with an empty-storage condition and explains the historical account state in relation to EIP-161."
},
{
"locator": "Specification",
"source": "supporting/eip-684.md",
"summary": "Defines the existing creation-collision rule using nonzero nonce or nonzero code length, which EIP-7610 extends."
},
{
"locator": "Specification item a and Rationale",
"source": "supporting/eip-161.md",
"summary": "Requires newly created accounts to increment nonce before initialization and explains avoiding zero nonce for created accounts."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "The proposal directly modifies EIP-684 and relies on EIP-161-era account semantics, requiring coordinated consideration while keeping the interaction narrowly scoped to contract creation.",
"score": 2,
"uncertainty_note": "The dependency is explicit, but the package does not enumerate the exact coordinated cross-EIP test matrix.",
"under_specified": false
}
],
"eip": 7610,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7610:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The historical checklist includes Engine API encoding changes but supplies no dedicated definition.",
"The requirement to apply the change retroactively to all existing blocks is not reconciled with the statement that activation requires a hard fork.",
"The phrase 'or any other reason' leaves additional contract-creation causes open-ended.",
"The phrase 'quite a number of tests' does not quantify the affected subset or its fork and client breadth."
],
"provenance": {
"assessed_revision": {
"commit": "fd89c8f734f4ddd6abee784cf91cf8e38e117d75",
"committed_at": "2024-11-07T08:14:40Z",
"content_sha256": "32737f15ce361d36c07bd84790f4e56059f5f170b032869556807d839e2de9bc",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7610.md",
"git_blob_sha": "6e7d1900da8e7b159ceb01ff02cf550a850b2c39",
"immutable_url": "https://github.com/ethereum/EIPs/blob/fd89c8f734f4ddd6abee784cf91cf8e38e117d75/EIPS/eip-7610.md",
"information_cutoff_at": "2025-09-24T14:40:52Z",
"path": "EIPS/eip-7610.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7610.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7610.yaml",
"sha256": "d377fa85b3251f314d58f9def3a73c9878afc209745a52e088ebb797414ff290"
},
"supporting_documents": [
"supporting/eip-161.md",
"supporting/eip-684.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 10,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the sealed historical revision, EIP-7610 adds non-empty storage to EIP-684's contract-creation collision predicate for creation transactions, CREATE, CREATE2, and any other creation cause. A collision must throw as though init code began with an invalid opcode; the rule is stated to apply retroactively and to require a hard fork.",
"tier": "medium",
"title": "Revert creation in case of non-empty storage",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"performance_risks",
"security_risks"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 8
},
"present": true,
"summary": "The proposal defines the collision predicate and failure result but does not quantify the affected test inventory, enumerate creation causes covered by 'any other reason,' detail storage-emptiness and reversion handling, or explain performance and security validation. These omissions are kept localized to test breadth, edge cases, performance, and security.",
"unresolved_questions": [
"How many existing tests, forks, and execution paths need changed expectations rather than simple refilling?",
"Which creation causes are included by 'any other reason,' and what boundary cases are required for nested creation and state reversion?",
"How is non-empty storage determined in each relevant state context, and does that check require isolated performance validation?",
"What targeted security and consensus-divergence review is required for retroactive application?"
]
}
},
"amsterdam:7610:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The specification adds non-empty storage to the conditions that make a creation throw, without changing any gas price, charge, or accounting mechanism."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes the result of a creation collision, not EVM gas accounting, so it matches the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "Non-empty storage is added to the existing destination-collision predicate inherited from EIP-684; the text does not move that predicate within CREATE or CREATE2 or change gas charging relative to it."
},
{
"locator": "Specification, lines 17-21",
"source": "supporting/eip-684.md",
"summary": "EIP-684 already performs a destination-account collision check for nonce and code across creation transactions, CREATE, CREATE2, and other paths."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The added condition changes the collision result but does not specify a new ordering point or move an existing state access inside an opcode, matching the zero anchor.",
"score": 0,
"uncertainty_note": "The proposal does not discuss whether an implementation treats determining storage emptiness as a separate observable access, but it places the condition in the already existing collision check.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The entire normative change concerns contract-creation collision state and contains no blob gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The specification reads whether destination storage is empty to decide a collision but defines no charge for writing state, state-gas rate, budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "A state-dependent validity condition is not a state gas accounting change, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The collision rule only requires creation to throw under an added state condition and introduces no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases, lines 36-40",
"source": "eip.md",
"summary": "The EIP identifies existing tests in two test repositories for deployment to non-empty-storage targets and says refilling those tests is sufficient coverage."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing expected outcomes must be updated, but only for the narrow and contrived category of creation into non-empty storage. This is best matched by the minor-subset score-one anchor.",
"score": 1,
"uncertainty_note": "The EIP calls the affected tests \"quite a number\" but does not quantify their share of either test corpus.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 36-40",
"source": "eip.md",
"summary": "Coverage is described as refilling tests that already target the precise non-empty-storage creation scenario, not adding a new assertion to tests about unrelated behavior."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The affected tests change their expected result; pre-existing unrelated tests gain no additional invariant to assert, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The rule is expressed entirely in terms of existing creation context and destination account state, with no new input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is required by the proposal, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 36-40",
"source": "eip.md",
"summary": "The EIP states that refilling existing tests will provide sufficient coverage."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Reusing and refilling existing tests indicates that existing framework primitives suffice, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The specified mechanism is a destination-account state predicate and contains no cryptographic construction or modification."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced or changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, lines 26-30",
"source": "eip.md",
"summary": "The motivating boundary case is a legacy destination with zero nonce and zero-length code but non-empty storage, which the two existing EIP-684 conditions do not reject."
},
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "The same collision boundary applies to creation transactions, CREATE, CREATE2, and any other creation reason."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The EIP introduces one edge-case-prone mechanism: distinguishing empty from non-empty destination storage when the other collision fields are zero. Multiple entry paths are cases of that single mechanism, matching score one.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The proposal changes execution behavior for contract creation and defines no block RLP field or validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The creation-collision predicate uses execution-state information and adds no Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The Engine API is unchanged, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The proposal adds a general contract-creation rejection condition and does not introduce a contract or reserved address."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The rule applies generically to creation attempts and identifies no pre-existing system contract code, state, or behavior to modify."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or package-identified indirect system-contract modification is introduced, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "CREATE and CREATE2 are named as existing creation paths to which the new condition applies; no new opcode is defined."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "CREATE and CREATE2 must now throw when the destination has non-empty storage, extending their pre-existing collision behavior beyond nonzero nonce or code length."
},
{
"locator": "Specification, lines 17-21",
"source": "supporting/eip-684.md",
"summary": "The prior collision rule for CREATE and CREATE2 rejects only a nonzero destination nonce or nonzero code length."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least two pre-existing opcodes have a non-gas behavioral result changed; the rubric's binary modified-opcode anchor therefore requires score three.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The normative change is confined to contract creation and does not define a precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The proposal changes creation collision handling and identifies no precompile logic or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The proposal defines an execution-state collision predicate without changing transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other covered encoding change is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "Existing contract-creation transactions are one path governed by the new collision condition; no transaction type is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "A creation transaction whose destination collides must execute as a throwing creation; the text does not make the transaction itself invalid or alter intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The change is to execution outcome after a creation is attempted, not to transaction validity or intrinsic-gas calculation, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 18-24",
"source": "eip.md",
"summary": "The rule relies on existing destination account state and introduces no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 32-34",
"source": "eip.md",
"summary": "The EIP says the execution-layer change requires a hard fork but specifies no activation-block state transition or mutation of an internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activating an execution rule in a hard fork is not itself the special activation-block modification covered by this anchor, so the score is zero.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "The only added work described is evaluating one more destination-account condition in the existing creation-collision rule."
},
{
"locator": "Test Cases, lines 36-40",
"source": "eip.md",
"summary": "The testing plan calls only for refilling existing functional tests and identifies no performance-validation requirement."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The historical text presents no mechanism whose test complexity requires performance benchmarking, so the zero anchor is the best-supported score.",
"score": 0,
"uncertainty_note": "The EIP does not discuss the runtime cost of determining storage emptiness; no package evidence establishes a material performance risk.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 42-44",
"source": "eip.md",
"summary": "The EIP characterizes the change as a security upgrade that enforces the immutability of deployed code."
},
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "The protection must be implemented consistently across creation transactions, CREATE, CREATE2, and other creation paths, and it amends the existing EIP-684 collision rule."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A mistake could leave a creation path able to violate the intended code- immutability protection. The change is limited to creation collision and destination state but spans several existing entry paths, supporting the targeted-review score-two anchor rather than a fully isolated score one.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "The text enumerates the creation paths and collision conditions and specifies that a collision throws as though the first init-code byte were invalid."
},
{
"locator": "Test Cases, lines 36-40",
"source": "eip.md",
"summary": "Although clients previously handled the scenario differently, the EIP states that refilling the existing tests is sufficient under the new rejection rule."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "For constructible empty-versus-non-empty-storage collision cases, the proposal supplies a single result and inherited failure semantics. The reported prior disagreement is the behavior the rule resolves, not an open choice left for cross-client agreement.",
"score": 0,
"uncertainty_note": "\"Non-empty storage\" is not separately formalized in the EIP, but its intended state predicate is sufficiently direct that no alternative outcome is supported by the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-30",
"source": "eip.md",
"summary": "EIP-7610 explicitly amends EIP-684 with the storage condition and explains that the relevant legacy state was possible before EIP-161 began incrementing a newly created contract's nonce."
},
{
"locator": "Specification, lines 17-21",
"source": "supporting/eip-684.md",
"summary": "EIP-684 supplies the existing nonce-or-code collision rule that EIP-7610 modifies."
},
{
"locator": "Specification, lines 18-26",
"source": "supporting/eip-161.md",
"summary": "EIP-161 changes creation nonce handling and account-state invariants, defining the historical boundary relevant to the newly covered accounts."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
161,
684
],
"rationale": "The proposal directly modifies EIP-684 and must account for the EIP-161 historical boundary. Coordinated testing is therefore required across two identified EIPs, but the interaction is confined to creation collision and legacy account state, matching score two.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7610,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7610:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The EIP does not quantify what share of the existing test corpora is meant by \"quite a number,\" so the boundary between scores one and two for affected pre-existing tests is judgmental."
],
"provenance": {
"assessed_revision": {
"commit": "fd89c8f734f4ddd6abee784cf91cf8e38e117d75",
"committed_at": "2024-11-07T08:14:40Z",
"content_sha256": "32737f15ce361d36c07bd84790f4e56059f5f170b032869556807d839e2de9bc",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7610.md",
"git_blob_sha": "6e7d1900da8e7b159ceb01ff02cf550a850b2c39",
"immutable_url": "https://github.com/ethereum/EIPs/blob/fd89c8f734f4ddd6abee784cf91cf8e38e117d75/EIPS/eip-7610.md",
"information_cutoff_at": "2025-09-24T14:40:52Z",
"path": "EIPS/eip-7610.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7610.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7610.yaml",
"sha256": "01edd717bb9c9988a1236d42d97184095c533334ceb2b33807ea5b29f6914037"
},
"supporting_documents": [
"supporting/eip-161.md",
"supporting/eip-684.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 9,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the selected historical revision, EIP-7610 extends the contract-creation collision rule so that creation transactions, CREATE, CREATE2, and any other creation path must fail when the destination has non-empty storage, in addition to the existing nonzero-nonce and nonzero-code conditions. It amends EIP-684 to protect legacy accounts whose zero nonce and zero-length code could coexist with storage before EIP-161, and specifies the same invalid-init-code failure behavior for all creation paths. The EIP expects existing non-empty-storage deployment tests to provide coverage after their expected results are refilled.",
"tier": "low",
"title": "Revert creation in case of non-empty storage",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 9,
"minimum": 9
},
"present": false,
"summary": "No material consensus behavior is left unresolved: the proposal defines the relevant destination-state predicate, covered creation paths, and failure result. Its informal use of \"non-empty storage\" does not support competing test outcomes within the sealed package.",
"unresolved_questions": []
}
},
"amsterdam:7708:human:r1": {
"checklist": {
"input_alignment": "exact_blob",
"parser_notes": [],
"published_tier": "low",
"published_total": 9,
"recomputed_tier": "low",
"recomputed_total": 9,
"timing_exposure": "high_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "All tests will now issue Eth-transfer logs, which might be a non-issue but does touch basically every single test.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Rather than a change to the T8N interface, we have to enhance execution-specs testing framework to verify the logs returned from T8N, because at the moment we just pass along the log list that was received from T8N to the test to be compared against the clients.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "All 0->1 boundaries have to be tested in all possible scenarios where Eth is transfered.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Some system contracts do receive/transfer Eth, and while existing tests might be sufficient, we need to double check that this change does not break current behavior (particularly the beacon deposit contract).",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "*CALL opcodes and SELFDESTRUCT/SENDALL behavior is slightly modified.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Test worst-case scenario of a transaction/block transfering Eth in multiple ways.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7708,
"fork": "amsterdam",
"id": "amsterdam:7708:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "7466599174141c30561e1366d5aead63080c277a",
"committed_at": "2025-04-13T00:47:51Z",
"content_sha256": "87520fb55cfbd55e385972510efa0ea5650710d9c686179dde450cf9fd3a508e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7708.md",
"git_blob_sha": "a0758eccabd947fe350a768c050b5254b3862084",
"immutable_url": "https://github.com/ethereum/EIPs/blob/7466599174141c30561e1366d5aead63080c277a/EIPS/eip-7708.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7708.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7708.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7708.yaml",
"sha256": "4e334dac152a9f229ff44a38c14cb236bee027ddd94101612a127f70123a4505"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "72a1fc653db7587eb37bd80eaf82f3e8e45727e3",
"committed_at": "2025-11-05T22:50:54Z",
"content_sha256": "a2652b18c2cf7fd9d197536f80880e0e448db66bf1e16170be0f6ddc54d35b41",
"git_blob_sha": "092e5bab2aa5317d14ff6832cc3b0371db773c3f",
"immutable_url": "https://github.com/ethspecs/pm/blob/72a1fc653db7587eb37bd80eaf82f3e8e45727e3/complexity_assessments/EIPs/EIP-7708.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7708.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 9,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "low",
"title": "ETH transfers emit a log",
"under_specification": null
},
"amsterdam:7708:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The normative change is automatic log emission for three nonzero-value transfer paths; it specifies no gas-accounting rule."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The proposal compares the existing minimum transfer cost with LOG3 cost to bound log volume, without normatively changing either cost."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "evm_gas_rule_changes",
"rationale": "No existing gas-accounting mechanism is explicitly updated and no new gas-accounting mechanism is specified, matching score 0.",
"score": 0,
"uncertainty_note": "The proposal does not state whether generated logs consume gas or how any charge would be applied; that omission is recorded as under-specification rather than scored as a gas change.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The feature is confined to logs generated by ETH transfers and contains no blob-gas mechanism."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting change is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "Blob gas is not mentioned anywhere in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The specified behavior emits logs for value transfers and does not define a refund."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no gas-refund discussion.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "Every nonzero-value CALL, value-transferring SELFDESTRUCT, and value-transferring transaction gains an additional log with prescribed topics, data, and placement."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The historical proposal supplies no test cases and marks the section TODO."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Expected logs and receipts change across a considerable set of existing value-transfer tests, but the affected cases remain a bounded category rather than the diverse major subset required for score 3.",
"score": 2,
"uncertainty_note": "No test inventory is provided, so the exact number and diversity of pre-existing vectors needing updates cannot be established from the package.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The proposal changes execution-produced logs but specifies no new transition-tool input or output field and no interface mechanism."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "transition_tool_interface_changes",
"rationale": "No modification to the transition-tool interface is required by the text, matching score 0.",
"score": 0,
"uncertainty_note": "Transition-tool integration is not discussed; the score therefore reflects the absence of any specified interface field rather than implementation evidence.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The change reuses log topics and a 32-byte value encoding; it introduces no cryptographic primitive or modification."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced or changed, matching score 0.",
"score": 0,
"uncertainty_note": "The proposal contains no cryptography-specific behavior.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "Emission is conditional on nonzero value across three transfer paths; transaction logs precede execution logs, while CALL and SELFDESTRUCT logs occur when their transfers execute."
},
{
"locator": "Rationale > Open questions",
"source": "eip.md",
"summary": "Withdrawal inclusion, its sender address, and fee-payment inclusion remain unresolved."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "edge_boundary_conditions",
"rationale": "The zero/nonzero boundary, three distinct transfer paths, and path-dependent log timing create multiple edge-prone mechanisms; ordering and execution-outcome combinations require an elevated case matrix, matching score 3.",
"score": 3,
"uncertainty_note": "Failure and reversion semantics, exact CALL-family scope, and the unresolved withdrawal and fee paths are not specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The specification changes generated log contents and ordering but defines no block RLP validation mechanism."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "block_syncing_changes",
"rationale": "Because no new block RLP validation mechanism is introduced, the block-syncing anchor scores 0.",
"score": 0,
"uncertainty_note": "Generated logs will change derived receipt data, but the proposal does not describe syncing or alter an RLP validation rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The complete normative functionality adds transfer logs and identifies no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "engine_api_changes",
"rationale": "No Engine API field or endpoint is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "Engine API integration is not discussed in the sealed proposal.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The proposal specifies only generated log topics, data, and placement, with no Engine API encoding change."
},
{
"locator": "Testing > Checklist > Engine API encoding changes",
"source": "rubric.md",
"summary": "The checklist contains this row, but the rubric provides no dedicated scoring definition for it."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "engine_api_encoding_changes",
"rationale": "Scored conservatively from the row label: the proposal specifies no Engine API encoding change, so score 0 is the closest allowed value.",
"score": 0,
"uncertainty_note": "The historical rubric omits a dedicated definition for this row; no definition has been invented or imported.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "Automatic log generation is specified directly in transaction, CALL, and SELFDESTRUCT processing; no contract is added."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_system_contracts",
"rationale": "No new system contract is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "The proposal identifies no system-contract address, code, state, or system action.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The proposal modifies general ETH-transfer execution behavior and names no pre-existing system contract or system-contract transition."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_system_contracts",
"rationale": "There is no evidenced direct or indirect modification of a pre-existing system contract, matching score 0.",
"score": 0,
"uncertainty_note": "The universal CALL and SELFDESTRUCT rule could apply when an unspecified system contract transfers value, but the package identifies no such contract or effect.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The specification refers to existing CALL, SELFDESTRUCT, and LOG3 behavior and assigns no new opcode."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_opcodes",
"rationale": "No new opcode is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "The generated log is described as identical to LOG3, not as a new instruction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "A nonzero-value CALL and a value-transferring SELFDESTRUCT must now emit a generated log at the time the transfer executes."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_opcodes",
"rationale": "The non-gas behavior of the pre-existing CALL and SELFDESTRUCT opcodes is modified, so the binary historical anchor requires score 3.",
"score": 3,
"uncertainty_note": "The exact handling of failed or reverted opcode execution is not specified, but the behavioral modification itself is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The feature is implemented as automatic transfer logs and does not introduce a precompile."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_precompiles",
"rationale": "No new precompile is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "No precompile address, input, output, or gas schedule appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The specified transfer-log rule names no precompile and changes no precompile logic or gas schedule."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified, matching score 0.",
"score": 0,
"uncertainty_note": "Precompiles are not discussed in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The generated record is identical to an existing LOG3, with a specified 32-byte big-endian data payload; no transaction, block, or interface encoding is replaced or altered."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "Specifying log payload bytes is not an RLP/SSZ-level transaction, block, or interface encoding change under this anchor, so the binary score is 0.",
"score": 0,
"uncertainty_note": "Receipt contents change because logs are added, but the sealed text specifies no change to their protocol encoding.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "Existing value-transferring transactions gain an automatic log; no distinct transaction envelope or type is defined."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "The proposal applies to value-transferring transactions generically and does not enumerate transaction-type-specific behavior.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "The proposal adds a log when an existing nonzero-value transaction takes place and states no validity condition or intrinsic-gas calculation change."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity rules and intrinsic gas calculations are not modified, matching score 0.",
"score": 0,
"uncertainty_note": "Gas treatment for the generated transaction log is unspecified, but no normative validity or intrinsic-gas rule can be inferred from that omission.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale",
"source": "eip.md",
"summary": "The proposal relies on logs being accessible through node RPCs or proofs tied to the existing block root and does not define a new block or header field."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "Generated logs alter committed receipt-derived values, but no field is added.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification defines transfer-time log emission and no activation-block state modification, internal-variable modification, or special transition."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_fork_activation_mechanism",
"rationale": "No new fork-activation mechanism meeting the binary anchor is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "The historical proposal does not describe activation handling; absence of such text is not treated as evidence of a special activation transition.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The proposal says worst-case logs per block do not increase because ETH transfers already cost more than LOG3, but the average number of logs will increase."
},
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "Log creation is integrated into transaction, CALL, and SELFDESTRUCT transfer processing rather than being a standalone operation."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "performance_risks",
"rationale": "Workload-wide receipt and log-volume effects cannot be fully benchmarked in isolation, while the proposal's existing transfer-cost bound indicates limited rather than substantial worst-case impact, matching score 2.",
"score": 2,
"uncertainty_note": "No benchmarks or quantitative estimate of the average increase are supplied, and resolving fee-payment logging could materially change volume.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Functionality",
"source": "eip.md",
"summary": "Consensus-generated logs are inserted across transaction, CALL, and SELFDESTRUCT paths with explicit topic, data, and ordering requirements."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The proposal considers log-volume denial-of-service exposure and argues the existing minimum transfer cost bounds worst-case log count."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "security_risks",
"rationale": "The mechanism touches a limited set of existing execution and receipt-production components and slightly changes their correctness assumptions, warranting targeted review or fuzzing but not the extensive multi-critical-component review of score 3.",
"score": 2,
"uncertainty_note": "The text does not analyze client divergence, reversion, receipt-root, or indexer-consistency failure modes, and its security section addresses only log volume.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The proposal contrasts missing ETH transfer logs with ERC-20 token logs and links EIP-20 as the comparison."
},
{
"locator": "Rationale",
"source": "eip.md",
"summary": "The proposed log type is described as compatible with the ERC-20 token standard while intentionally omitting ERC-20-specific ABI features."
},
{
"locator": "Body",
"source": "supporting/eip-20.md",
"summary": "The allowlisted EIP-20 snapshot contains only a notice that the document moved, so it supplies no further interaction details."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cross_eip_interactions",
"rationale": "There is a limited, non-critical compatibility interaction with EIP-20's logging model, but EIP-7708 does not normatively depend on or modify EIP-20 and can largely be tested independently, matching score 1.",
"score": 1,
"uncertainty_note": "The sealed supporting EIP-20 file contains no standard text, and unresolved withdrawal and fee-payment scope could add interactions not specified in this revision.",
"under_specified": true
}
],
"eip": 7708,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7708:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The checklist includes Engine API encoding changes but supplies no dedicated definition; that row is conservatively scored from its label with low confidence.",
"The abstract says all ETH transfers, while the normative functionality enumerates transactions, CALL, and SELFDESTRUCT and separately leaves withdrawals and fees open.",
"The phrase identical to a LOG3 defines record shape, but the proposal does not say whether automatic emission inherits LOG3 gas charging or execution-failure behavior.",
"MAGIC is TBD and Test Cases is TODO, leaving both a consensus constant and the intended conformance vectors unspecified."
],
"provenance": {
"assessed_revision": {
"commit": "7466599174141c30561e1366d5aead63080c277a",
"committed_at": "2025-04-13T00:47:51Z",
"content_sha256": "87520fb55cfbd55e385972510efa0ea5650710d9c686179dde450cf9fd3a508e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7708.md",
"git_blob_sha": "a0758eccabd947fe350a768c050b5254b3862084",
"immutable_url": "https://github.com/ethereum/EIPs/blob/7466599174141c30561e1366d5aead63080c277a/EIPS/eip-7708.md",
"information_cutoff_at": "2025-10-22T20:52:23Z",
"path": "EIPS/eip-7708.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7708.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7708.yaml",
"sha256": "fff459214997f181368f32c61086c50172342972b81c589d15056f4fab99d1fc"
},
"supporting_documents": [
"supporting/eip-20.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 13,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the sealed revision, EIP-7708 specifies automatically generated LOG3-shaped records for nonzero ETH transfers made by transactions, CALL, and SELFDESTRUCT, with path-specific placement. MAGIC remains TBD, test cases are TODO, and withdrawal and fee-payment coverage are open questions.",
"tier": "medium",
"title": "ETH transfers emit a log",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"cross_eip_interactions"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 18,
"minimum": 8
},
"present": true,
"summary": "The historical proposal leaves the log-signature MAGIC value undefined, supplies no test cases, does not resolve withdrawal or fee-payment logging, and does not normatively specify gas charging or failure/reversion treatment for generated logs. These omissions chiefly affect regression breadth, edge-case coverage, and performance/security confidence.",
"unresolved_questions": [
"What concrete value replaces the MAGIC parameter?",
"Should withdrawals and fee payments emit logs, and what sender address applies to a withdrawal?",
"Do generated logs consume execution or intrinsic gas, and what happens when gas is insufficient?",
"Are generated logs retained or reverted for failed or reverted transactions, CALLs, and SELFDESTRUCT paths, and what exact ordering vectors are normative?"
]
}
},
"amsterdam:7708:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The specification adds generated logs and their ordering but states no gas charge, schedule, or accounting rule."
},
{
"locator": "Security Considerations, lines 50-52",
"source": "eip.md",
"summary": "The text compares the pre-existing minimum transfer cost with LOG3 cost only to reason about maximum log throughput."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No gas-accounting change is specified, so the score follows the zero anchor rather than inferring a charge for the generated log.",
"score": 0,
"uncertainty_note": "The phrase \"identical to a LOG3\" and the gas-cost comparison do not say whether any LOG3 gas is charged; a future clarification could change this score.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "The proposal places generated logs at transfer execution time but does not move a state access or a gas charge relative to an access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Log placement alone is not a change to state-access or gas-charge ordering inside an opcode, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "Exact failure and rollback timing is not specified, but the text still proposes no change to when state is accessed.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-31",
"source": "eip.md",
"summary": "The proposal is confined to logs for ETH transfers and contains no blob mechanism or blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting changes are introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The specified effect is receipt-log generation; it does not define a state-writing gas cost, state-byte rate, budget, reservoir, or spill path."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas accounting mechanism or charging site is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The log-generation rule contains no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 13-19",
"source": "eip.md",
"summary": "The new rule covers ordinary transactions as well as internal CALL and SELFDESTRUCT value transfers so that all such ETH transfers are logged."
},
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "Existing execution paths gain new log contents and ordering, changing receipts for three common and technically distinct transfer categories."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests spanning transactions, CALL, and SELFDESTRUCT with nonzero value must have expected logs, ordering, blooms, or receipt commitments reworked. This is a major and diverse rather than contrived subset, meeting the score-3 anchor.",
"score": 3,
"uncertainty_note": "The EIP supplies no test cases, so the exact fraction of the pre-existing corpus affected cannot be established from the package.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "Every covered nonzero transfer must now produce a log with fixed topics, data encoding, and a specified relative placement."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests not principally about this EIP but containing a covered value transfer gain a mechanically checkable log invariant. The category is broad, but zero-value tests and tests without these transfers do not gain it, so score 2 applies rather than score 3.",
"score": 2,
"uncertainty_note": "Unresolved fee and withdrawal scope prevents an exact boundary for the set of pre-existing tests that would gain the assertion.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The change produces ordinary-style logs and does not specify a new input, output field, or activation indicator for a transition tool."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is required by the text.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "Expected behavior is expressed as a LOG3-compatible log with topics, byte data, and ordering, all conventional log properties."
},
{
"locator": "Test Cases, lines 46-48",
"source": "eip.md",
"summary": "The historical proposal contains only a TODO for test cases."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The described outputs can be checked with existing log expectations; the text does not require a new framework-level expectation or modifier.",
"score": 0,
"uncertainty_note": "With no test cases, the package cannot demonstrate whether convenience helpers would later be desirable, though no new primitive is required by the specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "The mechanism only constructs log topics and a big-endian value encoding; it introduces no cryptographic primitive or modification."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The rule has a zero/nonzero boundary, three distinct trigger paths, and path-dependent log placement and ordering."
},
{
"locator": "Rationale / Open questions, lines 37-40",
"source": "eip.md",
"summary": "Withdrawals and fee payments, including the withdrawal sender identity, remain explicit boundary questions."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Transactions, CALL, and SELFDESTRUCT each introduce success, rollback, sender/recipient, value-boundary, and ordering cases. Their combined matrix requires an elevated number of cases, meeting the score-3 anchor.",
"score": 3,
"uncertainty_note": "The unresolved scope and absent tests obscure the exact case matrix, but they do not remove the multiple discernible boundary-prone mechanisms.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The proposal changes generated logs and contains no block RLP field or validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No RLP validation mechanism requiring client syncing is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The specification introduces no Engine API field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API communication change is specified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-31",
"source": "eip.md",
"summary": "The feature is implemented as automatic protocol logs for existing transfer paths; no contract address, code, deployment, or state is added."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-31",
"source": "eip.md",
"summary": "The proposal names transaction, CALL, and SELFDESTRUCT transfer behavior but identifies no pre-existing system contract or contract transition."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or package-established indirect system-contract modification is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 27-31",
"source": "eip.md",
"summary": "The proposal refers to existing CALL, SELFDESTRUCT, and LOG3 behavior and assigns no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15",
"source": "eip.md",
"summary": "The abstract explicitly includes CALL and SELFDESTRUCT."
},
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "A nonzero-value CALL or value-transferring SELFDESTRUCT now emits a log at the time its transfer executes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least two pre-existing opcodes acquire a non-gas behavioral side effect. The rubric assigns score 3 whenever any pre-existing opcode behavior is modified.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-31",
"source": "eip.md",
"summary": "The described logging feature adds no precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-31",
"source": "eip.md",
"summary": "No precompile behavior or gas schedule is mentioned or changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "Generated entries use an existing LOG3-style structure and a specified 32-byte big-endian data value; no transaction, block, or interface encoding format is replaced or extended."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "New log contents within the existing log representation are not an RLP/SSZ encoding change at the rubric's transaction, block, or interface levels.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "The rule applies to nonzero-value-transferring transactions without defining a new transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Functionality, lines 29-31",
"source": "eip.md",
"summary": "A qualifying transaction gains an output log, but the proposal states no new acceptance rule or intrinsic-gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Receipt behavior changes without any specified transaction-validity or intrinsic-gas change, so the score is 0.",
"score": 0,
"uncertainty_note": "Gas treatment for the generated transaction log is unstated, but the text does not establish a change to intrinsic gas or validity.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, lines 33-35",
"source": "eip.md",
"summary": "The proposal relies on logs already reachable through node RPCs or the existing block-root commitment and adds no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-31",
"source": "eip.md",
"summary": "The specification defines ongoing transfer behavior and no activation- block state transition, migration, or internal-variable modification."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No new fork-activation mechanism is specified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, lines 50-52",
"source": "eip.md",
"summary": "The authors reason that worst-case log count does not increase because a transfer already costs more than LOG3, but acknowledge an increase in the average number of logs."
},
{
"locator": "Motivation and Specification, lines 17-31",
"source": "eip.md",
"summary": "Automatic logs are added across external transactions and two EVM transfer paths, tying overhead to real block workloads."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Average receipt/log construction, commitment, storage, and indexing impact depends on workload and cannot be fully benchmarked as an isolated opcode, but the text bounds worst-case log throughput and characterizes the average increase as limited. This matches score 2.",
"score": 2,
"uncertainty_note": "Whether fees and withdrawals are included could materially change log volume, and no benchmark results are packaged.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 17-19",
"source": "eip.md",
"summary": "The generated records are intended to let exchanges and other consumers track ETH transfers that were not automatically logged before."
},
{
"locator": "Security Considerations, lines 50-52",
"source": "eip.md",
"summary": "The proposal analyzes log-volume safety, concluding no worse maximum but acknowledging a higher average log count."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Correctness matters across the transaction, CALL, and SELFDESTRUCT paths because users may treat these consensus-committed records as transfer evidence. This touches a limited set of existing components and warrants targeted review and fuzzing, fitting score 2 rather than an extensive multi-component score 3.",
"score": 2,
"uncertainty_note": "The Security Considerations discuss capacity but not spoofing, rollback, emitter identity, or inconsistent-log risks, leaving the precise review surface uncertain.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 21-25",
"source": "eip.md",
"summary": "The consensus-visible MAGIC topic remains TBD."
},
{
"locator": "Rationale / Open questions, lines 37-40",
"source": "eip.md",
"summary": "Whether withdrawals and fee payments generate logs, and the withdrawal sender address if they do, are explicitly unresolved."
},
{
"locator": "Specification and Test Cases, lines 27-31 and 46-48",
"source": "eip.md",
"summary": "The proposal defines broad timing language but no cases for failure, rollback, contract creation, or the generated log's emitting address, and its entire test section is TODO."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously absent automatic transfer records become consensus-committed outputs while their selector, scope, identity, and edge semantics remain unsettled. Constructible cases cannot be baselined until clients agree, and amendments can change expected receipts, meeting the score-3 anchor.",
"score": 3,
"uncertainty_note": "Some missing execution details may have an obvious intended reading from ordinary log semantics, but MAGIC and transfer scope are expressly open.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Rationale, lines 17-19 and 33-35",
"source": "eip.md",
"summary": "EIP-7708 explicitly compares ETH tracking with ERC-20 logs and designs its log type for ERC-20 compatibility while avoiding ERC-20-specific ABI features."
},
{
"locator": "Front matter and notice, lines 1-7",
"source": "supporting/eip-20.md",
"summary": "The packaged linked document identifies the referenced proposal as EIP-20 and records that its content had moved."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
20
],
"rationale": "Compatibility with EIP-20 is an identified but limited interaction: the new ETH log can be tested mostly independently and does not modify or depend on EIP-20 behavior. This meets score 1.",
"score": 1,
"uncertainty_note": "The packaged EIP-20 file contains only a move notice, but EIP-7708 itself clearly identifies the intended compatibility relationship.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7708,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7708:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"\"Identical to a LOG3\" fixes topics and data in the next clause but does not identify the generated log's emitting address or say whether LOG3 gas is charged.",
"\"At the time that the value transfer executes\" does not fully define success, failure, and rollback behavior or exact ordering against surrounding opcode effects.",
"The stated goal of all ETH transfers conflicts with expressly unresolved fee and withdrawal coverage and leaves creation-recipient handling unstated."
],
"provenance": {
"assessed_revision": {
"commit": "7466599174141c30561e1366d5aead63080c277a",
"committed_at": "2025-04-13T00:47:51Z",
"content_sha256": "87520fb55cfbd55e385972510efa0ea5650710d9c686179dde450cf9fd3a508e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7708.md",
"git_blob_sha": "a0758eccabd947fe350a768c050b5254b3862084",
"immutable_url": "https://github.com/ethereum/EIPs/blob/7466599174141c30561e1366d5aead63080c277a/EIPS/eip-7708.md",
"information_cutoff_at": "2025-10-22T20:52:23Z",
"path": "EIPS/eip-7708.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7708.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7708.yaml",
"sha256": "0151b8078c388d8c870c86003b0c442d913b927f67c8aacf64cc47fe26829d95"
},
"supporting_documents": [
"supporting/eip-20.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 19,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7708 proposed automatically emitting an existing-style log for every nonzero-value transaction, CALL, and value-transferring SELFDESTRUCT. Each generated log would carry a MAGIC topic, sender and recipient topics, and a 32-byte transfer value, with the transaction log ordered before EVM-created logs and the other logs emitted when their transfers execute. The MAGIC value, treatment of withdrawals and fees, and test cases remained unresolved.",
"tier": "medium",
"title": "ETH transfers emit a log",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"edge_boundary_conditions",
"new_or_modified_transaction_validity_mechanisms",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 25,
"minimum": 13
},
"present": true,
"summary": "Material consensus-visible behavior is unresolved: MAGIC is TBD; fee and withdrawal coverage is open; the withdrawal sender is unspecified; and the generated log's emitter, gas treatment, and detailed success, failure, rollback, and creation semantics are not determined. Depending on those choices, the breadth of affected tests, invariants, edge cases, transaction validity, performance, and security review could shift, and charging LOG3-equivalent gas could introduce an EVM gas-rule score.",
"unresolved_questions": [
"What concrete value is assigned to MAGIC?",
"Do withdrawals emit logs, and what address is their sender topic?",
"Do fee payments emit logs?",
"Which account is the emitter/address of each generated log?",
"Are generated logs and any associated charge reverted on failed or reverted execution exactly like opcode-created logs?",
"Does \"identical to a LOG3\" imply a gas charge, and if so how is it charged for each of the three trigger paths?",
"How are creation transactions and other cases without an ordinary recipient address represented?"
]
}
},
"amsterdam:7778:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [],
"published_tier": "medium",
"published_total": 10,
"recomputed_tier": "medium",
"recomputed_total": 10,
"timing_exposure": "low_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This has the potential to affect any tests near the block gas limit that contain refunds.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": null,
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "All refunding opcodes need to be tested near the block gas limit.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Technically block validity, but a transaction that could be included previously would make a block invalid after this EIP",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7778,
"fork": "amsterdam",
"id": "amsterdam:7778:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "3a8ab8c6bc1a4df8f413d198005e2a1b09577621",
"committed_at": "2025-12-04T23:21:25Z",
"content_sha256": "2ade451bb835dbfd07b9dbfd0560685f680a6c6f286fce3a01ed213da056ad43",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7778.md",
"git_blob_sha": "e968d850d55b39b8756247f9fc4702392659274f",
"immutable_url": "https://github.com/ethereum/EIPs/blob/3a8ab8c6bc1a4df8f413d198005e2a1b09577621/EIPS/eip-7778.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7778.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7778.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7778.yaml",
"sha256": "0d6537908e3fa1f5c715b6dfc32bc912af53d8c3ff9befc0884dfe69d8fc1cc8"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "099b684c84c0a9f08578715a1c78369f1c51d1e6",
"committed_at": "2025-12-19T05:24:08Z",
"content_sha256": "d3c6080a3fba6143b2b007d51f3b34cbac824ef9d080ac5db9304390db172946",
"git_blob_sha": "459b3510b04d23cb099ecb5f1379a7b183eb407a",
"immutable_url": "https://github.com/ethspecs/pm/blob/099b684c84c0a9f08578715a1c78369f1c51d1e6/complexity_assessments/EIPs/EIP-7778.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7778.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 10,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "medium",
"title": "Block Gas Accounting without Refunds",
"under_specification": null
},
"amsterdam:7778:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification > ### Gas Accounting Changes",
"source": "eip.md",
"summary": "User transaction gas remains net of refunds, while block accounting changes to accumulate gas before subtracting refunds."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This updates the existing block gas accounting mechanism, matching score 1; the proposal does not introduce a separate gas domain independent of existing gas use.",
"score": 1,
"uncertainty_note": "The accounting intent is explicit, although the exact propagation of the two gas quantities is under-specified elsewhere in the draft.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Abstract; ## Specification",
"source": "eip.md",
"summary": "The proposal is limited to execution gas refunds and the block gas limit and specifies no blob gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is added or modified.",
"score": 0,
"uncertainty_note": "No blob behavior is described anywhere in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification > ### Gas Accounting Changes > 1. User Gas Costs (Unchanged)",
"source": "eip.md",
"summary": "Existing qualifying refunds continue to reduce transaction gas cost; no refund type or calculation is introduced."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal preserves existing refunds rather than creating a new refund mechanism.",
"score": 0,
"uncertainty_note": "None material; the draft expressly labels user gas costs unchanged.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Test Cases",
"source": "eip.md",
"summary": "Tests must distinguish user gas from block gas and cover storage-clearing transactions and blocks near the gas limit."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests involving refundable operations at block-gas boundaries form a focused, minor subset, matching score 1 rather than a broad rework.",
"score": 1,
"uncertainty_note": "The draft gives test categories but no inventory or count of pre-existing tests, so the affected subset cannot be measured directly.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification; ## Backwards Compatibility",
"source": "eip.md",
"summary": "The draft specifies an internal accounting rule and producer selection changes, but no transition-tool field or interface mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is specified, so score 0 applies.",
"score": 0,
"uncertainty_note": "The draft does not say whether tooling must expose the unrefunded block-gas total; that integration detail is materially under-specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The specification changes gas accounting and introduces no cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism or cryptographic functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "No cryptographic scope is present in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Test Cases > 2. Block Gas Limit Edge Cases",
"source": "eip.md",
"summary": "The draft calls for blocks with varying refundable operations and enforcement at the block gas limit."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The revised block-gas accumulator is one boundary-prone mechanism, so the single- mechanism score of 1 applies.",
"score": 1,
"uncertainty_note": "Exact numeric vectors and the normative boundary between refunds and retained storage discounts are not supplied.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification > ### Block Gas Limit Enforcement; ## Backwards Compatibility",
"source": "eip.md",
"summary": "A block is invalid when its transactions' unrefunded gas sum exceeds the limit, and the change is declared hard-fork incompatible."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "This is one simple new block-validation rule that syncing clients must enforce, matching score 1.",
"score": 1,
"uncertainty_note": "The draft does not describe RLP validation, header consistency, or sync fixtures, so the rubric's specific RLP mapping is inferred only from the stated block rule.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification; ## Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal adds no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The score-0 definition applies because no new Engine API field or mechanism is specified.",
"score": 0,
"uncertainty_note": "The draft does not explain whether existing payload gas values need semantic coordination, but that is not an added field or endpoint under this row.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "No Engine API encoding is specified or modified."
},
{
"locator": "### Testing > #### Anchors; ### Checklist",
"source": "rubric.md",
"summary": "The checklist names Engine API encoding changes but supplies no dedicated anchor definition for that row."
}
],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Conservatively applying the row label and global score range, no visible Engine API encoding change supports a nonzero score.",
"score": 0,
"uncertainty_note": "The historical rubric has no dedicated definition for this row, so its precise scope and score anchors are unavailable.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The accounting change introduces no contract or contract deployment."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No system-contract mechanism is present in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The draft modifies block gas accounting without mentioning any system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or indirect system-contract modification is specified.",
"score": 0,
"uncertainty_note": "No system-contract dependency is identified in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification > ### Gas Accounting Changes",
"source": "eip.md",
"summary": "The draft changes accounting around existing operations and adds no opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is introduced.",
"score": 0,
"uncertainty_note": "None material; no opcode addition appears in the specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification > ### Gas Accounting Changes; ## Test Cases > 1. SSTORE Operations",
"source": "eip.md",
"summary": "SSTORE is an example source of an existing refund; user-visible transaction behavior remains unchanged and only block-level gas accounting changes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified apart from the gas-accounting change, which the rubric expressly excludes from this binary row.",
"score": 0,
"uncertainty_note": "None material under the row's explicit exclusion of gas changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "No precompile is introduced by the accounting rule."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is specified.",
"score": 0,
"uncertainty_note": "No precompile scope is present in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "No precompile logic or gas schedule is named or modified."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "No precompile interaction is identified in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The draft changes an accounting rule and specifies no transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other encoding change is introduced.",
"score": 0,
"uncertainty_note": "None material; the specification contains no encoding change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification > ### Gas Accounting Changes > 1. User Gas Costs (Unchanged)",
"source": "eip.md",
"summary": "Existing transactions retain their user gas-cost treatment; no transaction type is added."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None material; the draft defines no transaction envelope or type.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification > ### Gas Accounting Changes; ## Backwards Compatibility",
"source": "eip.md",
"summary": "Transaction gas cost remains net of refunds and individual user/developer experience is stated to remain unchanged; enforcement changes at block level."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic gas calculation changes, so score 0 applies despite the separate block-validity change.",
"score": 0,
"uncertainty_note": "The draft clearly locates the new constraint at block rather than transaction validity.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification > ### Block Gas Limit Enforcement",
"source": "eip.md",
"summary": "The proposal changes calculation and enforcement but introduces no new block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new field is specified, so the binary row scores 0.",
"score": 0,
"uncertainty_note": "The meaning and propagation of the named block gas-used quantity are not fully defined, but the draft does not add a field.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Backwards Compatibility",
"source": "eip.md",
"summary": "A hard fork is required, with no state or internal-variable modification at activation specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Requiring fork activation does not itself meet the row's state/internal-variable modification condition, so score 0 applies.",
"score": 0,
"uncertainty_note": "The draft provides no special activation-block transition or state mutation.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Motivation; ## Backwards Compatibility; ## Security Considerations",
"source": "eip.md",
"summary": "The rule bounds computational work more strictly, changes producer transaction selection, and is intended to improve block-processing-time predictability."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The added pre-refund accumulator and selection constraint are localized and can be benchmarked in isolation; no complex performance interaction is specified.",
"score": 1,
"uncertainty_note": "No benchmarks or performance-validation plan is supplied, and the effect on existing maximum-block workloads is described only qualitatively.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Motivation; ## Security Considerations",
"source": "eip.md",
"summary": "The proposal changes consensus enforcement intended to prevent oversized-work blocks, denial of service, and unstable block-processing loads."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Correctness links existing refund calculation with block-limit validation and producer selection, slightly altering a consensus-critical security invariant and warranting targeted review or fuzzing; the interaction remains limited in scope.",
"score": 2,
"uncertainty_note": "The draft states the protected risks but supplies no detailed threat model or malformed-block/fuzzing plan.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification > ### Gas Accounting Changes; ## Rationale",
"source": "eip.md",
"summary": "The rule depends on existing refund behavior and expressly preserves storage discounts while changing how refunds contribute at block level."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "This is a limited interaction with pre-existing refund and storage-gas mechanisms that remains mostly independently testable, matching score 1.",
"score": 1,
"uncertainty_note": "No interacting EIP identifiers or normative dependency list is provided, so the full cross-EIP surface cannot be established from the sealed draft.",
"under_specified": true
}
],
"eip": 7778,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7778:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The historical checklist includes Engine API encoding changes but provides no dedicated definition or score anchors for that row.",
"The draft uses gas_used for both the pre-refund quantity and the derived transaction and block accounting expressions without defining all externally observable values.",
"The draft preserves discounts reflecting reduced work but gives examples rather than a complete normative classification separating those discounts from refunds."
],
"provenance": {
"assessed_revision": {
"commit": "9f795ed2983dc76b5c6138a507751d2a760030e3",
"committed_at": "2025-09-03T08:03:05Z",
"content_sha256": "f52d1a5d0a1298a7cc89ab98b3c6a583af11b7ecc2e0fee832fd1df8b9097bc0",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7778.md",
"git_blob_sha": "e4bdd606c2c6dacb9fb936ff4749847308b26c55",
"immutable_url": "https://github.com/ethereum/EIPs/blob/9f795ed2983dc76b5c6138a507751d2a760030e3/EIPS/eip-7778.md",
"information_cutoff_at": "2025-09-03T20:52:20Z",
"path": "EIPS/eip-7778.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7778.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7778.yaml",
"sha256": "1cb50433da6b338496a2f36fe71930093fedcb071fa33045c22222c71f836f10"
},
"supporting_documents": []
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 8,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the sealed historical cutoff, draft EIP-7778 changes existing execution-layer block gas accounting so refunds still reduce user transaction cost but no longer reduce gas counted against the block gas limit. The assessment covers only the draft text and the sealed historical checklist.",
"tier": "low",
"title": "Block Gas Accounting without Refunds",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"new_block_header_fields",
"performance_risks",
"security_risks",
"cross_eip_interactions"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 13,
"minimum": 5
},
"present": true,
"summary": "The draft states the high-level split between net transaction gas and unrefunded block gas but does not fully define how the gross quantity propagates through block/header consistency, receipts, validation tooling, or execution interfaces. It also gives no normative classification of every retained discount versus excluded refund and provides only qualitative test and risk guidance.",
"unresolved_questions": [
"What exact gas quantity must populate each block-level and receipt-level gas value after the fork?",
"What normative rule distinguishes excluded refunds from discounts that continue to reduce block gas accounting?",
"Must transition tooling or an existing Engine API value expose the unrefunded gas total, and if so with what semantics?",
"What exact boundary vectors, pre-existing test updates, benchmarks, and security cases are required?",
"What prior EIPs form the intended normative dependency and interaction set?"
]
}
},
"amsterdam:7778:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - Gas Accounting Changes, lines 33-45",
"source": "eip.md",
"summary": "Transaction gas remains net of refunds, while the existing block gas accumulator and block-limit check use gas without subtracting refunds."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This updates the existing EVM block gas accounting rule, matching anchor 1; the proposal characterizes it as a modification rather than a separate new gas accounting mechanism.",
"score": 1,
"uncertainty_note": "The precise protocol representation of block.gas_used is not defined, but the existence of an update to the existing accounting rule is clear.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - Gas Accounting Changes, lines 33-40",
"source": "eip.md",
"summary": "The change concerns whether refunds are subtracted at transaction and block aggregation time; it does not move a state access or a gas charge within an opcode's execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode-internal state-access or gas-charge ordering changes, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-45",
"source": "eip.md",
"summary": "The proposal addresses ordinary block gas and EVM refunds; it specifies no blob gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is changed, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - Gas Accounting Changes, lines 33-45",
"source": "eip.md",
"summary": "Storage clearing is used as an example of an EVM refund, but the specified change is to ordinary block gas accounting and not to a separate state-gas cost, budget, reservoir, or spill path."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The rubric's distinct state-gas mechanism is not introduced or adjusted, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - User Gas Costs, lines 33-35",
"source": "eip.md",
"summary": "Users continue to receive already-qualifying refunds and transaction gas remains gas used minus gas refund."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Existing refunds are preserved rather than a new refund mechanism being added, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases, lines 66-78",
"source": "eip.md",
"summary": "The EIP calls for refund-producing SSTORE cases, blocks with varying amounts of refundable work, gas-limit enforcement cases, and comparisons of transaction gas with block gas."
},
{
"locator": "Backwards Compatibility, lines 60-64",
"source": "eip.md",
"summary": "The accounting change is not backwards compatible and requires a hard fork."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing block and refund vectors containing refundable operations need their expected block accounting or validity reworked. This can be a considerable set, but it is confined to the refund-bearing category, matching anchor 2.",
"score": 2,
"uncertainty_note": "The text does not identify the historical test corpus or state whether the changed block accumulator is reflected in every existing block-gas expectation.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Test Cases, lines 37-45 and 66-78",
"source": "eip.md",
"summary": "The proposal changes the value used by an existing block-limit rule and asks for direct feature tests, but specifies no additional output or assertion for otherwise unrelated tests."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing expectations may be reworked, but tests do not clearly gain a distinct new invariant to assert; anchor 0 applies.",
"score": 0,
"uncertainty_note": "A fuller definition of whether block.gas_used denotes an existing header value or a separate accumulator could change whether a new assertion is needed.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification - Gas Accounting Changes, lines 33-45",
"source": "eip.md",
"summary": "The EIP changes the calculation of block gas used but introduces no new transition input, output, or fork-activation flag."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The changed result can be expressed through the existing block gas result; no transition-tool interface modification is specified as required, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "The text does not define whether both refunded transaction gas and unrefunded block gas must be surfaced separately by a transition tool.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 66-78",
"source": "eip.md",
"summary": "The requested tests construct ordinary SSTORE transactions and blocks and compare transaction and block gas values."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "These cases can use existing transaction, block, gas, and validity assertions; no new framework abstraction is required, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-45",
"source": "eip.md",
"summary": "The proposal is solely a gas-refund and block-limit accounting change and contains no cryptographic construction or operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Test Cases, lines 33-45 and 68-78",
"source": "eip.md",
"summary": "Tests must cover the unrefunded cumulative gas at the block limit, varying refund amounts, the divergence between transaction and block gas, and the distinction between refunds and retained storage discounts."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "There are multiple boundary-prone aspects: cumulative equality versus excess, variable refund amounts across transactions, and classification of discounts that remain applied. None is described as requiring an exceptionally large case matrix, matching anchor 2.",
"score": 2,
"uncertainty_note": "The exact refund and discount cases covered by the general wording are not exhaustively enumerated.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - Block Gas Limit Enforcement, lines 42-45",
"source": "eip.md",
"summary": "Block validity uses the sum of unrefunded gas, but the EIP introduces no new RLP field, decoding rule, or RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "A consensus block-validity calculation changes without an RLP validation mechanism being added, so the rubric's block-syncing anchor remains 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 29-45 and 60-64",
"source": "eip.md",
"summary": "The proposal specifies gas accounting and producer selection behavior but no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or endpoint is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-45",
"source": "eip.md",
"summary": "The complete mechanism is expressed as gas accounting and block-limit enforcement, with no contract deployment or designated system address."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-45",
"source": "eip.md",
"summary": "The gas-accounting rule does not identify or alter the code, state, or behavior of any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or package-established indirect system-contract modification exists, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Test Cases, lines 13-15 and 66-78",
"source": "eip.md",
"summary": "SSTORE is an example used to produce an existing refund; the proposal defines no new instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - User Gas Costs, lines 33-40",
"source": "eip.md",
"summary": "Qualifying operations and user refund behavior remain unchanged; only the downstream block accumulator stops subtracting refunds."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No opcode result or non-gas behavior is modified, and gas-only changes are excluded by this anchor; score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-45",
"source": "eip.md",
"summary": "The proposal adds only a block gas accounting rule and no callable precompiled function or address."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-45",
"source": "eip.md",
"summary": "No precompile logic or precompile-specific gas schedule is mentioned or changed by the refund treatment."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 29-45 and 60-64",
"source": "eip.md",
"summary": "The hard-fork change concerns how a gas value is calculated and supplies no transaction, block, or interface encoding change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface encoding is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - User Gas Costs, lines 33-40",
"source": "eip.md",
"summary": "Existing transactions retain their gas-cost behavior while their gas is accumulated differently at block scope; no transaction envelope is added."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 33-45 and 60-64",
"source": "eip.md",
"summary": "Transaction gas costs are explicitly unchanged; the new limit is a block-level sum and does not alter transaction validity or intrinsic gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The change is to block validity, not existing transaction-type validity, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification - Block Gas Accounting, lines 37-45",
"source": "eip.md",
"summary": "The proposal changes block.gas_used accumulation and enforcement but does not add a block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "Modification of the calculation associated with an existing value is not the introduction of a new field; anchor 0 applies.",
"score": 0,
"uncertainty_note": "The EIP does not explicitly identify how block.gas_used maps to the encoded header and receipts, but it never specifies an additional field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 60-64",
"source": "eip.md",
"summary": "A hard fork is required, but the EIP specifies no one-time state mutation or internal-variable modification at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Fork-gated use of a new rule alone is not an activation-block modification; anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 19-27",
"source": "eip.md",
"summary": "The EIP identifies blocks whose gross work exceeds their net gas and cites oversized blocks, instability, denial of service, and excess computational load as the problem."
},
{
"locator": "Rationale and Security Considerations, lines 49-53 and 80-84",
"source": "eip.md",
"summary": "The intended effect is to constrain actual block workload and make processing time more predictable."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Validating the new workload bound requires mixed transaction and refund-bearing block benchmarks rather than only an isolated accumulator benchmark. Its effect on existing performance workloads is limited to blocks using refunds, matching anchor 2.",
"score": 2,
"uncertainty_note": "The EIP gives one observed workload example but no benchmark methodology or complete set of refund-heavy workloads.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 23-27",
"source": "eip.md",
"summary": "The stated failure mode includes oversized blocks, denial-of-service vectors, and computational loads beyond the intended limit."
},
{
"locator": "Security Considerations, lines 80-84",
"source": "eip.md",
"summary": "The new enforcement is intended to prevent producers from including excessive aggregate work and to improve block-processing predictability."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The consensus-critical accumulator interacts with existing transaction refunds and block validation. Incorrect implementation could create divergent block acceptance or preserve the stated denial-of-service condition, warranting targeted review and fuzzing of a limited component set under anchor 2.",
"score": 2,
"uncertainty_note": "The security section states intended benefits but does not analyze divergence, overflow, or mixed-refund failure cases in detail.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification - Gas Accounting Changes, lines 33-45",
"source": "eip.md",
"summary": "The text gives formulas for transaction and block gas and says some storage discounts remain, but it does not define the protocol fields carrying each value or exhaustively distinguish retained discounts from excluded refunds."
},
{
"locator": "Test Cases, lines 66-78",
"source": "eip.md",
"summary": "The requested comparisons and varying-refund blocks require exact expected values that the short specification does not fully enumerate."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients must agree on localized, constructible cases such as the mapping of gross gas to block and receipt values and the refund-versus-discount boundary before vectors can be baselined. This matches anchor 2, not anchor 3, because the EIP is not making a formerly unobservable behavior consensus-critical.",
"score": 2,
"uncertainty_note": "The package contains no supporting specification that resolves these localized accounting semantics.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 33-40",
"source": "eip.md",
"summary": "The proposal changes the block-level effect of established gas-refund rules, particularly refunds arising from storage clearing, while retaining their transaction-level effect."
},
{
"locator": "Specification - Block Gas Accounting, lines 37-40",
"source": "eip.md",
"summary": "Existing warm-access and revert-to-original-value discounts are stated to remain applied, requiring their treatment to be coordinated with the new rule."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The proposal centrally modifies how pre-existing refund rules feed block gas and must be tested together with the retained storage-discount rules. That requires coordinated but limited-scope testing, matching anchor 2. The historical EIP supplies no EIP numbers for those interactions, so none are inferred.",
"score": 2,
"uncertainty_note": "The interacting mechanisms are named, but their EIP identifiers and complete boundaries are absent from the package.",
"under_specified": true,
"unidentified_interactions": [
"Existing gas-refund rules, particularly storage-clearing refunds from SSTORE.",
"Existing storage discounts for warm access and reverting to original values."
]
}
],
"eip": 7778,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7778:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The notation block.gas_used is not tied explicitly to the block header, receipts, or an internal-only accumulator.",
"The examples distinguish refunds from storage discounts, but do not provide a complete classification of adjustments for consensus testing.",
"Backwards compatibility says only producers need to adjust transaction selection, while the specification also imposes a consensus block-limit rule that validators must evaluate."
],
"provenance": {
"assessed_revision": {
"commit": "9f795ed2983dc76b5c6138a507751d2a760030e3",
"committed_at": "2025-09-03T08:03:05Z",
"content_sha256": "f52d1a5d0a1298a7cc89ab98b3c6a583af11b7ecc2e0fee832fd1df8b9097bc0",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7778.md",
"git_blob_sha": "e4bdd606c2c6dacb9fb936ff4749847308b26c55",
"immutable_url": "https://github.com/ethereum/EIPs/blob/9f795ed2983dc76b5c6138a507751d2a760030e3/EIPS/eip-7778.md",
"information_cutoff_at": "2025-09-03T20:52:20Z",
"path": "EIPS/eip-7778.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7778.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7778.yaml",
"sha256": "56ab266703097378b12a8dfb81b992d178570122f65b5d96a513632ffdc65233"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 13,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7778 proposed retaining existing gas refunds for user transaction costs while counting gas before refunds toward the block gas limit. It required the sum of unrefunded transaction gas to remain within the block limit, while retaining discounts described as reflecting reduced work, and identified a hard fork plus block-producer transaction-selection changes.",
"tier": "medium",
"title": "Block Gas Accounting without Refunds",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"edge_boundary_conditions",
"performance_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 15,
"minimum": 10
},
"present": true,
"summary": "The proposal defines the high-level split between refunded transaction gas and unrefunded block gas, but does not fully specify how the two quantities map to consensus block and receipt values or exhaustively define the boundary between excluded refunds and retained storage discounts. These omissions affect exact vector baselines without changing the proposal's core accounting direction.",
"unresolved_questions": [
"Does block.gas_used denote the encoded block-header gas-used value, only an internal validity accumulator, or both?",
"What gas values should receipts and cumulative transaction-gas fields expose when transaction accounting remains refunded but block accounting is gross?",
"Which adjustments are refunds excluded from block accounting, and which are discounts that remain applied, especially for reverting storage to its original value?",
"Must a transition-tool interface expose both net transaction gas and gross block gas separately, or is changing an existing result sufficient?"
]
}
},
"amsterdam:7843:human:r1": {
"checklist": {
"input_alignment": "no_substantive_drift",
"parser_notes": [],
"published_tier": "low",
"published_total": 7,
"recomputed_tier": "low",
"recomputed_total": 7,
"timing_exposure": "low_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "new field, `slot_number` will need to be added",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Minimal, but need to check 0, and `uint64` big endian",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "new field, `slot_number` is passed in the engine API",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "New opcode added: `SLOTNUM`",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7843,
"fork": "amsterdam",
"id": "amsterdam:7843:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "77f096af0ce517c3f7d7644f189845e06612905c",
"committed_at": "2025-06-09T08:48:46Z",
"content_sha256": "56d948e7e04ec88f9aef1dafc4abe6d2a7760ff45cbeb009680dba116ebc82ad",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7843.md",
"git_blob_sha": "aeeffed14ee510c2831b4198d4a6b6b1f2bcf360",
"immutable_url": "https://github.com/ethereum/EIPs/blob/77f096af0ce517c3f7d7644f189845e06612905c/EIPS/eip-7843.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7843.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7843.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7843.yaml",
"sha256": "70779e4b9d459a657d2bb2013a97757e1b41d18a2853eeebc31596c94e132282"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "6b2c7cd0b1d59eda05cad78bdf4c2674250c5d47",
"committed_at": "2025-11-07T21:05:37Z",
"content_sha256": "5f036b6626bc7cb2b6d6c19d0604473df2cfef517f3160ebe3bc1939b9f3e638",
"git_blob_sha": "1bb42233b4bcd5d5ba3b5ad93e637096504cc488",
"immutable_url": "https://github.com/ethspecs/pm/blob/6b2c7cd0b1d59eda05cad78bdf4c2674250c5d47/complexity_assessments/EIPs/EIP-7843.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7843.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 7,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "low",
"title": "SLOTNUM opcode",
"under_specification": null
},
"amsterdam:7843:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "SLOTNUM is assigned a fixed gas fee of 2."
},
{
"locator": "Rationale > Gas Price",
"source": "eip.md",
"summary": "The price is selected to match existing W_base opcodes."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "evm_gas_rule_changes",
"rationale": "Adding a fixed charge for the new opcode extends the existing EVM gas schedule, but introduces no dynamic or independent accounting mechanism.",
"score": 1,
"uncertainty_note": "The rubric does not say explicitly whether the unavoidable fixed price of a new opcode counts here in addition to the Added opcodes row; score 1 treats it as an update to the existing mechanism.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete section)",
"source": "eip.md",
"summary": "The specified changes are SLOTNUM, its fixed EVM fee, a slot_number header field, and a PayloadAttributes field; no blob-gas rule is specified."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "blob_gas_accounting_changes",
"rationale": "The proposal contains no blob gas accounting change.",
"score": 0,
"uncertainty_note": "No blob-related behavior appears anywhere in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "The only gas behavior specified is a fixed fee of 2 for SLOTNUM."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no refund behavior.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification; Test Cases",
"source": "eip.md",
"summary": "The draft allocates opcode 0x4b and extends the header and PayloadAttributes schemas, while its Test Cases section is N/A."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The new opcode assignment and post-fork schema additions imply localized updates to existing opcode-invalidity and block/interface fixtures, fitting a minor subset rather than a broad redesign.",
"score": 1,
"uncertainty_note": "No test inventory or activation rules are supplied, so the number and categories of pre-existing tests affected cannot be established from the package.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > RPC changes > Header extension",
"source": "eip.md",
"summary": "Execution headers gain one slot_number field whose value is consumed by the new opcode."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "transition_tool_interface_changes",
"rationale": "A transition tool executing SLOTNUM needs the one new block-environment value, corresponding conservatively to a single added interface field.",
"score": 1,
"uncertainty_note": "The draft never defines a transition-tool interface or says whether slot_number is supplied as a new field or derived from an existing header input.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Rationale > ZK-VM proving",
"source": "eip.md",
"summary": "The change returns a uint64 slot value and states that proving remains analogous to TIMESTAMP with no extra circuit input."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "cryptography",
"rationale": "No cryptographic primitive, proof rule, or cryptographic functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "The ZK-VM discussion concerns proving inputs, not a new cryptographic mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Output > Stack; RPC changes",
"source": "eip.md",
"summary": "One uint64/8-byte big-endian value is propagated from consensus through header and Engine API to an EVM stack result."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "edge_boundary_conditions",
"rationale": "The bounded uint64 value and its cross-layer representation form one boundary-condition-prone mechanism, particularly at numeric limits and at the stack-width conversion.",
"score": 1,
"uncertainty_note": "The draft does not state the 8-to-32-byte EVM stack padding, overflow behavior, or consistency checks among PayloadAttributes, the header, and opcode output.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > RPC changes > Header extension",
"source": "eip.md",
"summary": "The header encoding is extended by one uint64 slot_number field."
},
{
"locator": "Specification > Block structure and validity",
"source": "supporting/eip-4788.md",
"summary": "The allowlisted related EIP demonstrates that execution-header schema extensions alter the header RLP and require header-value validation."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "block_syncing_changes",
"rationale": "One fixed-width header-field addition is a single simple block-encoding validation change relevant to syncing.",
"score": 1,
"uncertainty_note": "EIP-7843 does not specify the field's exact RLP position, canonical integer constraints, or explicit block-validation rule.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > RPC changes > PayloadAttributes change",
"source": "eip.md",
"summary": "PayloadAttributes is extended with one slot_number field of type uint64."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "engine_api_changes",
"rationale": "The proposal introduces exactly one new field in an existing Engine API object, matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "The draft does not identify endpoint versions or state how the field is handled when absent, but the specified field count is unambiguous.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > RPC changes > PayloadAttributes change",
"source": "eip.md",
"summary": "The encoded Engine API object gains one uint64 slot_number field."
},
{
"locator": "Checklist > Engine API encoding changes",
"source": "rubric.md",
"summary": "The checklist contains this row but the rubric provides no dedicated scoring definition."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "engine_api_encoding_changes",
"rationale": "Judged conservatively from the label alone, encoding one additional scalar in an existing Engine API object is a limited change warranting score 1.",
"score": 1,
"uncertainty_note": "The historical rubric has no dedicated definition for this row, so no authoritative mapping from the field addition to scores 0-3 is available.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete section)",
"source": "eip.md",
"summary": "The proposal adds an opcode and two data fields, with no contract deployment or system call."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "The sealed proposal specifies no contract code, address, deployment, or system action.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation; Specification (complete sections)",
"source": "eip.md",
"summary": "EIP-4788 is mentioned only as an existing alternative for proving a supplied slot; SLOTNUM itself does not change a contract."
},
{
"locator": "Specification > Beacon roots contract",
"source": "supporting/eip-4788.md",
"summary": "The existing beacon-roots contract operates on timestamps and parent beacon block roots; EIP-7843 specifies no change to those operations."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "modified_system_contracts",
"rationale": "Neither code nor state behavior of a pre-existing system contract is modified, directly or indirectly by the specified mechanism.",
"score": 0,
"uncertainty_note": "The motivational reduction in use of the EIP-4788 alternative is not a protocol-level behavioral modification to that system contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Specification > Output > Stack; Specification > Gas Cost",
"source": "eip.md",
"summary": "One opcode, SLOTNUM at 0x4b, returns one stack element, takes no stated input or data portion, and costs a constant 2 gas."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "added_opcodes",
"rationale": "This is one simple opcode with simple stack mechanics and constant gas, exactly matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "The output padding is underspecified, but that does not make the opcode data-bearing, dynamically priced, or stack-complex under this row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The change is expressly the addition of SLOTNUM at 0x4b; no existing opcode behavior is changed or deprecated."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "modified_opcodes",
"rationale": "No pre-existing opcode is modified.",
"score": 0,
"uncertainty_note": "The comparison to TIMESTAMP is rationale only and does not modify TIMESTAMP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete section)",
"source": "eip.md",
"summary": "The executable feature is defined as an EVM opcode; no precompile address or precompile behavior is specified."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no precompile mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete section)",
"source": "eip.md",
"summary": "No existing precompile logic or gas schedule appears among the specified changes."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no reference to precompile behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > RPC changes > Header extension",
"source": "eip.md",
"summary": "The proposal expressly extends header encoding with a uint64 slot_number field."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "A block-header encoding change is introduced, which maps to the rubric's binary score of 3.",
"score": 3,
"uncertainty_note": "The existence of the encoding change is explicit, although the draft omits the field's exact position and canonical encoding details.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete section)",
"source": "eip.md",
"summary": "The proposal adds an opcode, a header field, and a PayloadAttributes field, but no transaction envelope or type."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "No transaction-format change appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete section)",
"source": "eip.md",
"summary": "No transaction validity rule or intrinsic-gas calculation is added or changed."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The new block/header value does not alter transaction validity or intrinsic gas under the sealed specification.",
"score": 0,
"uncertainty_note": "Block-header validity questions are assessed under block/header-related rows rather than treated as transaction validity.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > RPC changes > Header extension",
"source": "eip.md",
"summary": "The execution header gains a slot_number field of type uint64."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_block_header_fields",
"rationale": "One new header field is explicit, which maps to the rubric's binary score of 3.",
"score": 3,
"uncertainty_note": "The field's exact header position and validation source are omitted, but its addition is unambiguous.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification (complete section)",
"source": "eip.md",
"summary": "The draft specifies the opcode and fields but no one-time state mutation or existing internal-variable modification at fork activation."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_fork_activation_mechanism",
"rationale": "Introducing the new opcode/header semantics at a fork is not itself a scored activation mutation, and no special state or variable modification is specified.",
"score": 0,
"uncertainty_note": "The draft contains no activation or genesis rules; if a later mechanism required a one-time modification, it is not part of the sealed evidence.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Gas Cost; Rationale > ZK-VM proving",
"source": "eip.md",
"summary": "SLOTNUM is a fixed-cost scalar-returning opcode, and the draft says it is analogous to TIMESTAMP and should add neither proving complexity nor circuit inputs."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "performance_risks",
"rationale": "The new opcode and scalar data path can be benchmarked in isolation and are not specified to disturb existing performance behavior, matching score 1.",
"score": 1,
"uncertainty_note": "No benchmarks are provided; the no-impact statement addresses ZK proving but not client processing of the added header/API field.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > RPC changes; Security Considerations",
"source": "eip.md",
"summary": "A consensus-layer-calculated slot is carried through Engine API and the block header into EVM-visible execution, while the Security Considerations section says only 'None.'"
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "security_risks",
"rationale": "Correctness spans a limited set of existing consensus, Engine API, header-validation, and EVM components; disagreement could expose an incorrect context value or cause block disagreement, supporting targeted review rather than extensive multi-mechanism review.",
"score": 2,
"uncertainty_note": "The draft defines neither who validates slot_number nor the behavior on a header/PayloadAttributes mismatch, and supplies no substantive security analysis.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "EIP-4788 is cited as one existing, costly alternative for proving a caller-supplied slot number, not as a dependency of SLOTNUM."
},
{
"locator": "Abstract; Specification > Beacon roots contract",
"source": "supporting/eip-4788.md",
"summary": "EIP-4788 exposes beacon roots through a header commitment and contract, mechanisms that EIP-7843 neither modifies nor invokes."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "cross_eip_interactions",
"rationale": "The proposed opcode and slot-number data path are self-contained with respect to the cited EIP-4788 mechanism; the comparison does not create a protocol dependency or required coordinated testing.",
"score": 0,
"uncertainty_note": "The sealed proposal names no required EIP and describes EIP-4788 only as an alternative approach.",
"under_specified": false
}
],
"eip": 7843,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7843:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"Engine API encoding changes has no dedicated definition in the historical rubric; its score is therefore conservative and low-confidence.",
"The phrase '8 byte uint in big endian encoding' does not specify left-padding into an EVM stack word.",
"The header extension lacks field order, canonical integer constraints, explicit validation, and activation/genesis semantics.",
"The proposal says the slot is calculated in consensus and passed through Engine API but does not define the calculation or cross-layer mismatch handling.",
"The historical gas row does not explicitly resolve whether assigning the mandatory fixed fee of a new opcode also counts as updating the existing gas mechanism."
],
"provenance": {
"assessed_revision": {
"commit": "0aefdc9d5a4b637ca280832f5fe617a5f4dd4f3f",
"committed_at": "2025-05-20T16:23:34Z",
"content_sha256": "9f15ade995d4baf3e9cdcff6b921ccf3163447deef81087f2c738285834b1852",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7843.md",
"git_blob_sha": "0f5d0ef12b1a050a1c8a67117740ca0ff04568bd",
"immutable_url": "https://github.com/ethereum/EIPs/blob/0aefdc9d5a4b637ca280832f5fe617a5f4dd4f3f/EIPS/eip-7843.md",
"information_cutoff_at": "2025-06-09T07:29:29Z",
"path": "EIPS/eip-7843.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7843.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7843.yaml",
"sha256": "785e0c03f7ef09c1545df93a8033961b02892833fb35a5a28dde88f29acde3d5"
},
"supporting_documents": [
"supporting/eip-4788.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 17,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "Blinded assessment of the sealed Draft EIP-7843: one fixed-cost SLOTNUM opcode, one uint64 execution-header field, and one uint64 PayloadAttributes field carrying a consensus-layer-derived slot number to the execution layer.",
"tier": "medium",
"title": "SLOTNUM opcode",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"engine_api_encoding_changes",
"performance_risks",
"security_risks"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 22,
"minimum": 11
},
"present": true,
"summary": "The draft defines the high-level opcode and cross-layer fields but omits the slot calculation/validation rule, exact header position and canonical encoding, Engine API endpoint/version and mismatch behavior, transition-tool representation, EVM stack padding, activation/genesis handling, tests, and substantive security analysis. The 11-22 range varies only rows directly sensitive to those omissions or to the rubric's undefined Engine API encoding row; the explicit opcode, header-field, and block-encoding scores remain fixed.",
"unresolved_questions": [
"What exact consensus rule calculates slot_number, and which layer validates it against the block context?",
"Where is slot_number placed in the execution-header encoding, what are its canonical uint64 rules, and how is it handled at activation or genesis?",
"Which Engine API endpoint versions carry the PayloadAttributes field, and what happens when it is absent or conflicts with the eventual header?",
"How is the 8-byte big-endian value represented in the 32-byte EVM stack word and in transition-tool inputs?",
"Which existing test categories require updates, and what boundary, mismatch, and security cases are required?"
]
}
},
"amsterdam:7843:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cost, lines 43-45",
"source": "eip.md",
"summary": "SLOTNUM is assigned a fixed gas fee of 2."
},
{
"locator": "Rationale — Gas Price, lines 61-63",
"source": "eip.md",
"summary": "The fee is chosen to match similar opcodes in the existing W_base set."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Adding SLOTNUM to the existing constant-cost base-opcode schedule updates an existing gas-accounting mechanism; it does not introduce dynamic metering or affect an existing opcode's gas rule.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-45",
"source": "eip.md",
"summary": "The new opcode returns one context-derived stack value for a fixed fee and specifies no account, storage, or other state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "SLOTNUM does not access state, so it neither changes an existing opcode's state-access ordering nor introduces an ordering point for a new state-accessing operation.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "The specified changes are a fixed-cost opcode, a header field, and a PayloadAttributes field; no blob-gas rule is introduced or changed."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal contains no blob gas accounting change.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "The opcode reads block context and the RPC changes transport a slot number; no state write, state-gas rate, budget, reservoir, or spill rule is specified."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas-charging site or state gas mechanism is added or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cost, lines 43-45",
"source": "eip.md",
"summary": "The only EVM gas behavior specified is a fixed charge of 2 for SLOTNUM; no refund behavior is described."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — RPC changes, lines 47-57",
"source": "eip.md",
"summary": "The proposal transports slot_number across the consensus/execution boundary and extends both the block-header encoding and PayloadAttributes."
},
{
"locator": "Test Cases, lines 77-79",
"source": "eip.md",
"summary": "The historical proposal supplies no test cases that narrow or demonstrate the required regression updates."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A mandatory post-fork header-schema change plus an Engine API input change requires existing block, payload, syncing, and execution-test paths to construct and carry the new field. That reaches diverse categories rather than a narrow contrived subset, matching the major-subset anchor.",
"score": 3,
"uncertainty_note": "The proposal does not describe the historical test infrastructure, so the exact amount of mechanical versus hand-authored rework is not determined.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Header extension and PayloadAttributes change, lines 51-57",
"source": "eip.md",
"summary": "Post-fork payload and block representations gain a slot_number that must be propagated consistently even when a test is about unrelated execution behavior."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of post-fork block and payload tests gains a mechanical consistency assertion for slot_number, but the text does not establish that every test type or pre-fork vector must gain that assertion.",
"score": 2,
"uncertainty_note": "The proposal does not specify which test formats assert header fields or whether any harness derives the field automatically.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 31-45",
"source": "eip.md",
"summary": "Execution of SLOTNUM requires one new current-block input value and produces the slot number on the EVM stack."
},
{
"locator": "RPC changes, lines 47-57",
"source": "eip.md",
"summary": "The slot number is a single uint64 value carried into execution and added to PayloadAttributes."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool must receive one slot_number context field so it can execute the opcode and form the extended header, matching the single-new-field anchor.",
"score": 1,
"uncertainty_note": "The transition-tool interface is not named in the proposal, and the missing validation flow could ultimately require more than one representation of the value.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "The feature adds a block-context opcode and extends header and PayloadAttributes data models with slot_number."
},
{
"locator": "Test Cases, lines 77-79",
"source": "eip.md",
"summary": "No feature-specific testing abstractions or cases are supplied."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing opcode-test and block-test primitives remain applicable, but their environment and header builders need a minor slot_number extension. The text provides no basis for a new reusable expectation or modifier primitive.",
"score": 1,
"uncertainty_note": "Because no tests are described, it is unclear whether an existing generic block-context field mechanism would make the framework change unnecessary.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 29-45",
"source": "eip.md",
"summary": "The proposal adds a context-reading opcode with integer output and fixed gas; it introduces no cryptographic algorithm or modification."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Output and RPC changes, lines 33-57",
"source": "eip.md",
"summary": "The same slot number crosses an eight-byte big-endian stack-output description, a uint64 header field, and a uint64 PayloadAttributes field."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The fixed-width slot-number path is one boundary-prone mechanism, requiring at least zero and uint64-limit representation cases across the API, header, and stack. It does not introduce multiple independently complex boundary mechanisms.",
"score": 1,
"uncertainty_note": "The text does not state overflow handling or precisely define how the eight-byte value occupies an EVM stack word.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Header extension, lines 51-53",
"source": "eip.md",
"summary": "The block-header encoding is extended with one uint64 slot_number field."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "One additional header field creates a single simple RLP/schema validation change for imported blocks, matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "The field's exact header position, canonical encoding details, and validation rule are not specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "RPC changes and PayloadAttributes change, lines 47-57",
"source": "eip.md",
"summary": "The slot number is passed from consensus to execution through the Engine API, with one explicit new uint64 slot_number field in PayloadAttributes."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The historical text explicitly adds a single field to an existing Engine API object, matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "The proposal does not say whether ExecutionPayload, newPayload, forkchoiceUpdated, or versioned endpoint schemas also require changes.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 29-57",
"source": "eip.md",
"summary": "The feature consists of an opcode and cross-layer/header fields; no contract deployment or system action is proposed."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 19-27",
"source": "eip.md",
"summary": "EIP-4788 is described only as an existing proof-based alternative to obtaining the slot number."
},
{
"locator": "Abstract, lines 14-18",
"source": "supporting/eip-4788.md",
"summary": "EIP-4788 exposes beacon roots and stores them in a contract, functionality that EIP-7843 does not amend."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "EIP-7843 neither changes the EIP-4788 system contract's code or state nor specifies any indirect protocol behavior for that contract.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-45",
"source": "eip.md",
"summary": "One opcode, SLOTNUM at 0x4b, returns one stack element and has a fixed gas fee of 2."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This is one simple opcode: it has no data portion, no complex stack mechanics, and a constant gas cost.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-45",
"source": "eip.md",
"summary": "The proposal allocates a new opcode at 0x4b and does not change or deprecate the behavior of any existing opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 29-45",
"source": "eip.md",
"summary": "The execution feature is expressly a new opcode; no precompile address or precompile behavior is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "The specified opcode and metadata changes do not mention or alter any existing precompile's logic or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension, lines 51-53",
"source": "eip.md",
"summary": "The proposal explicitly requires the header encoding to be extended with a uint64 slot_number field."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "A block-header encoding change directly triggers the rubric's binary score-3 anchor.",
"score": 3,
"uncertainty_note": "The existence of the encoding change is explicit, although its exact field placement and canonical encoding are not.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "The proposal adds an opcode, block-header field, and Engine API field, with no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "Nothing in the specified opcode, header, or Engine API changes alters transaction validity or intrinsic gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The proposal does not create or modify transaction validity rules.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension, lines 51-53",
"source": "eip.md",
"summary": "The proposal mandates a new slot_number field of type uint64 in the block-header encoding."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The introduction of a new block-header field directly triggers the rubric's binary score-3 anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "The proposal defines ongoing opcode and per-block data behavior but no one-time state mutation or existing internal-variable modification at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No special fork-activation state transition or internal-variable modification is specified.",
"score": 0,
"uncertainty_note": "The activation rules are not described, but the text provides no evidence of a one-time mutation that would trigger this criterion.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale — ZK-VM proving, lines 69-71",
"source": "eip.md",
"summary": "The proposal characterizes SLOTNUM as similar to TIMESTAMP, says proving complexity should not increase, and keeps the value in the self-contained block header."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new context read and metadata transport can be benchmarked in isolation and are not specified to alter existing performance behavior, matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "The proposal gives an expectation rather than benchmark evidence and does not quantify header or Engine API overhead.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "RPC changes, lines 47-57",
"source": "eip.md",
"summary": "A consensus-layer-calculated value is transported through the Engine API, committed in the execution header, and exposed to EVM execution."
},
{
"locator": "Security Considerations, lines 81-83",
"source": "eip.md",
"summary": "The historical proposal states that there are no security considerations and provides no analysis of cross-layer consistency or validation."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect propagation or validation could make a consensus-derived opcode value disagree across block construction, validation, and execution. The mechanism touches a limited set of critical components and warrants targeted cross-layer review, but the proposal does not establish the broad, substantial invariant changes required for score 3.",
"score": 2,
"uncertainty_note": "The missing payload-validation rule makes the precise security surface and ownership of consistency checks unclear.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-57",
"source": "eip.md",
"summary": "The text specifies the opcode, an eight-byte big-endian output, a header field, and one PayloadAttributes field, but does not give exact header placement or the full block-building and validation data flow."
},
{
"locator": "Test Cases and Security Considerations, lines 77-83",
"source": "eip.md",
"summary": "No test cases or security discussion resolve the missing details."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need agreement on localized consensus details before baselining tests: the header field's exact encoding position, how validating execution clients receive or check slot_number, and how the eight-byte value maps to a 256-bit EVM stack item. These are localized to the new slot-number path rather than a wholesale newly observable class of behavior.",
"score": 2,
"uncertainty_note": "Some omissions have an apparent intended reading, but the proposal does not select those readings normatively.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 19-27",
"source": "eip.md",
"summary": "The proposal identifies proving a supplied slot number against a beacon block root using EIP-4788 as an existing onchain access path that SLOTNUM is intended to improve upon."
},
{
"locator": "Abstract and Motivation, lines 14-25",
"source": "supporting/eip-4788.md",
"summary": "EIP-4788 exposes beacon-chain roots in the EVM for proofs of consensus state, the proof mechanism referenced by EIP-7843."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "EIP-4788 is cited only to describe an existing alternative access path. EIP-7843 does not depend on, modify, or conflict with EIP-4788 and requires no coordinated EIP-4788 test cases, so it is self-contained under this anchor.",
"score": 0,
"uncertainty_note": "None identified; a motivational comparison is not treated as a protocol interaction.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7843,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7843:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The historical text says to extend the header encoding but does not place the new field within the header or define its canonical encoded form.",
"PayloadAttributes gains slot_number, but the proposal does not specify the corresponding payload-delivery and validation-side Engine API changes.",
"The output is called an eight-byte big-endian value even though an EVM stack element is wider, leaving the normative stack representation implicit.",
"Test Cases is N/A and Security Considerations is None, leaving the intended regression and cross-layer consistency rules undocumented."
],
"provenance": {
"assessed_revision": {
"commit": "0aefdc9d5a4b637ca280832f5fe617a5f4dd4f3f",
"committed_at": "2025-05-20T16:23:34Z",
"content_sha256": "9f15ade995d4baf3e9cdcff6b921ccf3163447deef81087f2c738285834b1852",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7843.md",
"git_blob_sha": "0f5d0ef12b1a050a1c8a67117740ca0ff04568bd",
"immutable_url": "https://github.com/ethereum/EIPs/blob/0aefdc9d5a4b637ca280832f5fe617a5f4dd4f3f/EIPS/eip-7843.md",
"information_cutoff_at": "2025-06-09T07:29:29Z",
"path": "EIPS/eip-7843.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7843.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7843.yaml",
"sha256": "40911b1426c62f536630aa3ea0bca01deb0accb2e4ff1909ed5b36736d3d1c7a"
},
"supporting_documents": [
"supporting/eip-4788.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 23,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7843 was a Draft proposal for a new fixed-cost SLOTNUM opcode at 0x4b that returns the current block's slot number as an eight-byte unsigned value. The slot number was to be calculated by the consensus layer, carried to the execution layer through the Engine API, committed in a new uint64 block-header field, and supplied in a new uint64 PayloadAttributes field. The proposal presented EIP-4788 proof-based access as an existing but more expensive alternative, and it supplied no test cases or substantive security analysis.",
"tier": "high",
"title": "SLOTNUM opcode",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 28,
"minimum": 20
},
"present": true,
"summary": "Material details of the new consensus value's complete path are unresolved: the header field's exact position and canonical encoding, its representation in payload validation and Engine API messages beyond PayloadAttributes, the rule by which execution clients validate the consensus-computed value, and the mapping of the stated eight-byte value into an EVM stack word. These omissions affect the size of the interface, syncing, regression-test, and security work without changing the explicit existence of the opcode or header field.",
"unresolved_questions": [
"Where in the header is slot_number placed, and what is its exact canonical RLP encoding and validation rule?",
"Which Engine API payload or endpoint objects, in addition to PayloadAttributes, carry slot_number during block production and validation?",
"From which value does a validating execution client derive or obtain slot_number, and what mismatch makes a payload invalid?",
"How is the eight-byte big-endian SlotNumber represented in the 256-bit EVM stack word, and what happens at or beyond the uint64 limit?"
]
}
},
"amsterdam:7928:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [],
"published_tier": "high",
"published_total": 29,
"recomputed_tier": "high",
"recomputed_total": 29,
"timing_exposure": "high_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No new gas schedule, but the EIP imposes a hard pre-state / post-state validation ordering on every state-accessing opcode (`BALANCE`, `EXT*`, `*CALL`, `CREATE*`, `SLOAD`, `SSTORE`, `SELFDESTRUCT`). Gas-charge sites had to be re-ordered across the spec because state was being accessed before gas was charged; off-by-one boundaries determine whether an address appears in the BAL, so the rule change cascades into existing gas tests across multiple forks.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable subset of existing tests is affected, but the impact is concentrated in a contrived category: benchmarks and gas-boundary fixtures. BAL changes the cost surface (added per-block data, propagation overhead, builder/validator work) so pre-existing benchmarks no longer represent worst cases — new adversarial scenarios (fan-out reads, many-slot touches, deep delegation chains, large BAL-item counts approaching `block_gas_limit // ITEM_COST`) need to be researched and added, and the benchmarking framework needs new metrics for BAL size, generation cost, and validation cost. Existing OOG-boundary fixtures across forks need their warm/cold/touch assumptions re-verified under BAL inclusion semantics. Outside those categories, most pre-existing tests need no rework — Amsterdam-filled tests generate and validate a BAL automatically as a consensus artefact.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A single new mechanism — the BAL builder/validator wired into the t8n (`block_access_lists.py`, `BlockAccessListBuilder`, `hash_block_access_list`, `validate_block_access_list_gas_limit`) — surfaces one new payload output (`blockAccessList` on `ExecutionPayloadV4`). The `block_access_list_hash` on the header is **not an independent field**: it is fully determined as `keccak256(rlp(BAL))` and carries no information not already present in the BAL itself. It is a Merkle/checksum binding, comparable to `transactionsRoot` vs. the transaction list — counting it as a second \"new field\" would double-count one piece of information. So in t8n terms this is \"a new mechanism\" (singular) producing one new output, not \"multiple new fields **and** a new mechanism\" (the 3 bucket). Per the anchor's footnote, the t8n must additionally be fork-aware (Amsterdam-only activation), which warrants special consideration regardless of score.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Keccak-256 over RLP only — already covered.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "An elevated number of cases is required. Per `test_cases.md` the BAL implementation drove gas off-by-one boundary tests at every state-access opcode (cold vs warm × OOG-before-target-access / OOG-after-target-access / success-minus-1 / success). Add: net-zero storage filtering (intra-tx coalescing, cross-frame shadowing, nested DELEGATECALL net-zero), CREATE/CREATE2 collisions, same-tx create+SELFDESTRUCT, 7702 invalid-nonce/invalid-chain-id, static-context filtering across all call opcodes, empty-block coinbase, zero-tip coinbase, system-address surplus filtering, RIPEMD-160 cross-block state leak, lexicographic byte-ordering endian traps.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "A single complex RLP validation mechanism is introduced: the BAL itself, whose sub-rules include hash binding to the header, lexicographic address ordering, ascending `block_access_index` per change list, uniqueness per `(address, slot)`, mutual exclusion between `storage_changes` and `storage_reads`, `bal_items <= block_gas_limit // ITEM_COST`, and `SYSTEM_ADDRESS` exclusion unless touched. The three new block exceptions (`INVALID_BLOCK_ACCESS_LIST`, `INVALID_BAL_HASH`, `BLOCK_ACCESS_LIST_GAS_LIMIT_EXCEEDED`) all stem from this single validator.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "Multiple fields **and** multiple new endpoints: `ExecutionPayloadV4` adds `blockAccessList`; new `engine_newPayloadV5`, `engine_getPayloadV6`, `engine_getPayloadBodiesByHashV2`, `engine_getPayloadBodiesByRangeV2` returning `ExecutionPayloadBodyV2`. EL must also retain BALs ≥ weak-subjectivity period.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Still RLP — no new wire encoding format introduced at the Engine API layer beyond what is captured under \"Encoding changes (RLP/SSZ)\".",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct modification, but **major** indirect effects on every system contract whose storage diffs/queue dequeues must now be recorded: EIP-2935 (HISTORY_STORAGE_ADDRESS), EIP-4788 (BEACON_ROOTS_ADDRESS), EIP-7002 (withdrawal requests), EIP-7251 (consolidation requests). Cross-index semantics (pre-execution `index=0`, post-execution `index=n+1`), partial vs. clean sweep for 7002/7251 queues, and `SYSTEM_ADDRESS` exclusion-unless-touched all required new tests.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Final EVM semantics (gas charged, state changes, reverts) are unchanged. Only the observation order for BAL inclusion is constrained, which is a spec-framework concern, not a behavior change in the anchor's sense.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction structure and intrinsic gas are unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "New `block_access_list_hash` (Hash32) on the header; `blockAccessList` carried out-of-header via the Engine API.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state mutation or pre-existing internal variable is modified at the activation block (the builder is initialized fresh per block).",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The BAL adds ~70 KiB/block of propagation overhead and is interwoven with execution — it cannot be benchmarked in isolation because validation requires re-deriving the BAL during the state transition. Builder behavior interacts with intra-tx coalescing, cross-frame shadowing, net-zero filtering, and the `R_remaining * 2000` gas-budget feasibility check. Benchmark suites under `tests/benchmark/stateful/eip7928_block_level_access_lists/` and `tests/benchmark/compute/eip7928_block_level_access_lists/` were added.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The BAL elevates **every state-access check** — not just state writes — into consensus-critical territory. Whether an account or slot appears in the BAL depends on whether the caller had enough gas to *touch* it (cold/warm cache, account existence, 7702 delegation load, static-context check, value-transfer gas), and whether ambient artefacts like the coinbase or precompiles are deemed \"touched\" under fee-burning, empty-block, zero-tip, and selfdestruct-to-self scenarios. Any client that mis-orders a gas check vs. a state observation, mis-classifies a touch, or leaks cross-block precompile state diverges from the block-hash-bound BAL and breaks consensus. This is a substantial expansion of the consensus surface that interacts with multiple critical components (EVM gas accounting, EIP-2929 warm/cold tracking, EIP-6780 selfdestruct semantics, EIP-7702 delegation resolution, system-contract handling) and warrants extensive review and fuzzing.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Strong interdependencies, with existing test vectors actively redesigned: EIP-2929 (warm/cold) drives the gas-boundary cliffs that gate BAL inclusion; EIP-2930 listed-but-untouched entries are explicitly excluded; EIP-1559 coinbase tipping vs. burned base fee determines coinbase inclusion; EIP-6780 changes selfdestruct persistence semantics that the BAL must mirror; EIP-7702 delegation creates a two-level access model (target vs. delegated target) with multiple OOG boundaries and authorization-failure cases; EIP-4895 withdrawals are credited at `index=n+1` with no EVM execution; EIP-2935, EIP-4788, EIP-7002, EIP-7251 each require system-contract storage diff and cross-index handling; EIP-1153 transient storage must be explicitly *excluded*; EIP-214 static-context restrictions must fire before BAL inclusion.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7928,
"fork": "amsterdam",
"id": "amsterdam:7928:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "645099785a50a0c9eb568496fffc2a8978b3e9f4",
"committed_at": "2026-04-20T23:50:20Z",
"content_sha256": "304c0e626e12477d42321ec4ae09f16a3b3e1e4234fb104cbdb2050c64230c6c",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7928.md",
"git_blob_sha": "f744fd9572464a705823b203e7dd3d9b1c1e0741",
"immutable_url": "https://github.com/ethereum/EIPs/blob/645099785a50a0c9eb568496fffc2a8978b3e9f4/EIPS/eip-7928.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7928.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7928.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7928.yaml",
"sha256": "b0ff6c50cbc4542bd8f14d47fb407f43d939c03bc43a58eaed6252036844e7b3"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "6d744f3a809a69182166c8c76e793ac2fcb34bd4",
"committed_at": "2026-05-12T20:24:34Z",
"content_sha256": "a8d3e39c4aa0e201274d762d033c008dafdf25c68341e5c8e4b5fa0c6001eafc",
"git_blob_sha": "509dfc6013eeb510ca1cb4e53a2fd08f06284da4",
"immutable_url": "https://github.com/ethspecs/pm/blob/6d744f3a809a69182166c8c76e793ac2fcb34bd4/complexity_assessments/EIPs/EIP-7928.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7928.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 29,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "high",
"title": "Block-Level Access Lists",
"under_specification": null
},
"amsterdam:7928:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition Function; Important Implementation Details > Edge Cases",
"source": "eip.md",
"summary": "The new logic gathers accesses and post-state changes and validates a BAL commitment; gas refunds are mentioned only as a reason to record the sender's final balance."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal adds observability and block validation around execution but specifies no new or updated EVM gas-accounting rule.",
"score": 0,
"uncertainty_note": "The draft does not explicitly state that gas schedules are unchanged, but none of its specified transition rules charges or recalculates gas.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block Structure Modification; Specification > SSZ Data Structures",
"source": "eip.md",
"summary": "The added data is a block access list and its header commitment; the defined structures contain account and state-access data, not blob-gas fields or accounting."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "Absence is assessed from the complete sealed draft; no separate blob behavior is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Important Implementation Details > Edge Cases",
"source": "eip.md",
"summary": "For gas refunds, the proposal only requires recording the sender's final balance after each transaction."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Recording the post-refund balance does not create or alter an EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "No refund formula or refund-counter behavior is provided, so the reference to refunds is treated as tracking existing behavior only.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition Function",
"source": "eip.md",
"summary": "Every BAL must exactly match execution-gathered accesses and changes; missing or spurious entries invalidate the block."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal changes the block structure incompatibly and requires a hard fork."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A mandatory, execution-derived validation object affects valid and invalid block construction across ordinary transfers, contract execution, withdrawals, exceptional halts, and system operations, requiring broad reworking of pre-existing block/state-transition test patterns.",
"score": 3,
"uncertainty_note": "The package contains no test inventory, so the exact number of affected suites is not measurable; the score follows from the rule applying to every post-fork block and diverse execution categories.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Block Structure Modification",
"source": "eip.md",
"summary": "A new bal_hash header field and a BlockAccessList in the block body are introduced."
},
{
"locator": "Specification > State Transition Function",
"source": "eip.md",
"summary": "The transition must gather accesses, construct the BAL, hash it, and compare it with the block commitment."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The state-transition workflow needs a new BAL validation mechanism and access to new block data, which best fits the rubric's score-2 anchor even though a concrete tool schema is absent.",
"score": 2,
"uncertainty_note": "The draft never specifies transition-tool request/result fields, so whether this is one field, multiple fields, or an interface-internal mechanism is unresolved.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > SSZ Data Structures; Rationale > BAL Design Choice",
"source": "eip.md",
"summary": "The proposal uses SSZ data structures and cites efficient Merkle proofs, but defines no novel cryptographic primitive or modification to an existing primitive."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Serialization, commitment use, and proof compatibility alone do not introduce a new cryptography mechanism under this anchor.",
"score": 0,
"uncertainty_note": "compute_bal_hash is invoked but not defined, leaving the exact commitment construction under-specified; nothing in the sealed text establishes that it is a new cryptographic mechanism.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Important Implementation Details > Edge Cases",
"source": "eip.md",
"summary": "The draft enumerates SELFDESTRUCT, unchanged accesses, zero-value transfers, refunds, rewards, read-only operations, exceptional halts, withdrawals, and multiple system-contract cases."
},
{
"locator": "Specification > SSZ Data Structures > Ordering requirements",
"source": "eip.md",
"summary": "Addresses, storage keys, and transaction indices have distinct ordering constraints, bounded list sizes, and inclusion/exclusion rules for reads and writes."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Several interacting boundary-prone mechanisms require elevated combinatorial testing, especially revert/exception behavior, read-versus-write classification, system-operation indexing, ordering, and maximum lengths.",
"score": 3,
"uncertainty_note": "Some enumerated cases have inconsistent or incomplete indexing semantics, increasing test uncertainty but not requiring an exceptional score beyond the defined score-3 anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale > BAL Design Choice",
"source": "eip.md",
"summary": "The SSZ BAL is embedded as opaque bytes in the RLP block for compatibility and carries post-execution values intended to permit state reconstruction during sync."
},
{
"locator": "Specification > Block Structure Modification; Specification > State Transition Function",
"source": "eip.md",
"summary": "The block gains a header commitment and body object whose completeness and hash must be validated."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "This is a single but complex new block-encoding and validation mechanism that sync clients must ingest, decode, commit, and validate, matching score 2.",
"score": 2,
"uncertainty_note": "The exact RLP body position, envelope, hash construction, and sync validation path are not specified, so the boundary between one and multiple RLP validation mechanisms is unclear.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Block Structure Modification",
"source": "eip.md",
"summary": "The draft defines bal_hash in the block header and a BAL in the body but does not identify any Engine API directive, endpoint, or field."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "Under the rubric's endpoint-specific definition, no Engine API field or communication mechanism is actually specified.",
"score": 0,
"uncertainty_note": "Transport of the new block data may require Engine API work, but its field count and endpoint placement are materially absent and cannot be supplied from outside the package.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Rationale > BAL Design Choice",
"source": "eip.md",
"summary": "The only explicit transport encoding says the SSZ BAL is embedded as opaque bytes in an RLP block; no Engine API encoding is described."
}
],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Scored conservatively at zero from the row label and global scale because the proposal contains no explicit Engine API encoding change.",
"score": 0,
"uncertainty_note": "The historical checklist provides no dedicated definition for this row, and the proposal also omits Engine API serialization details; both limitations prevent a more authoritative mapping.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Important Implementation Details > Edge Cases; Specification > State Transition Function > process_system_contracts",
"source": "eip.md",
"summary": "The proposal tracks state changes caused by already-identified EIP-7002, EIP-7251, EIP-2935, and EIP-4788 system contracts/addresses."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "It integrates existing system operations into BAL generation but introduces no new system contract.",
"score": 0,
"uncertainty_note": "The sealed draft labels these as existing EIP-defined operations and gives no deployment or initialization for a new contract.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Important Implementation Details > Edge Cases",
"source": "eip.md",
"summary": "Storage diffs caused by four existing system mechanisms must be represented in the BAL under a system-operation transaction index."
},
{
"locator": "Specification > State Transition Function > process_system_contracts",
"source": "eip.md",
"summary": "BAL collection explicitly records the storage writes of the EIP-7002, EIP-7251, EIP-2935, and EIP-4788 addresses."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No system-contract code or state-transition behavior is directly changed, but their effects now have a minor indirect requirement: canonical BAL tracking and validation.",
"score": 1,
"uncertainty_note": "The text does not define whether BAL-invalidating behavior is considered a major indirect behavioral effect, and its pre/post processing pseudocode is internally ambiguous.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSZ Data Structures; Specification > Important Implementation Details > Edge Cases",
"source": "eip.md",
"summary": "The proposal observes accesses made by existing operations such as SLOAD, SSTORE, STATICCALL, BALANCE, EXTCODEHASH, EXTCODESIZE, CREATE, and CREATE2."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is defined.",
"score": 0,
"uncertainty_note": "The complete opcode-related specification describes tracking only; no opcode number, stack signature, or new instruction appears.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > SSZ Data Structures; Specification > Important Implementation Details > Edge Cases",
"source": "eip.md",
"summary": "Existing opcode targets and storage accesses are included in an execution-derived block record, including read-only and unchanged accesses."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The EVM results, stack behavior, and state semantics of existing opcodes are not modified; BAL recording is block-validation instrumentation rather than opcode behavior under this anchor.",
"score": 0,
"uncertainty_note": "One could view mandatory access recording as externally observable execution behavior, but the rubric explicitly targets opcode behavior and the draft specifies no opcode semantic change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSZ Data Structures; Specification > State Transition Function",
"source": "eip.md",
"summary": "The defined feature consists of BAL data and access-tracking validation, with no precompile address, input, gas schedule, or execution function introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced.",
"score": 0,
"uncertainty_note": "Absence is based on the complete sealed specification; no precompile construction is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSZ Data Structures; Specification > State Transition Function",
"source": "eip.md",
"summary": "BAL collection covers accounts and storage touched during execution but gives no changed behavior or gas schedule for any precompile."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile logic or gas accounting is modified.",
"score": 0,
"uncertainty_note": "The draft does not enumerate precompile-specific BAL treatment, but that omission is not evidence of a precompile modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSZ Data Structures",
"source": "eip.md",
"summary": "A nested bounded SSZ BlockAccessList encoding is defined for account, storage, balance, nonce, and code changes."
},
{
"locator": "Rationale > BAL Design Choice",
"source": "eip.md",
"summary": "The SSZ BAL is to be embedded as opaque bytes in the RLP block."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal explicitly introduces a new block-level SSZ encoding carried within the RLP block, satisfying the binary score-3 anchor.",
"score": 3,
"uncertainty_note": "The exact RLP envelope and commitment/hash construction are omitted, but the existence of a block-level encoding change is explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block Structure Modification",
"source": "eip.md",
"summary": "The feature adds data at block header and block body level rather than defining a transaction envelope or transaction-type identifier."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "The BAL contains per-transaction indices, but indexing existing transactions is not a new transaction type.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > State Transition Function",
"source": "eip.md",
"summary": "Missing or spurious BAL entries invalidate the block after transactions are executed and tracked; no transaction envelope validity or intrinsic-gas rule is specified."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The new validity condition applies to the block's BAL commitment, not to the validity rules of existing transaction types or their intrinsic gas calculation.",
"score": 0,
"uncertainty_note": "The sentence permitting immediate invalidation when a transaction exceeds declared state is not formally defined, but the draft provides no transaction-level declaration or validity algorithm to score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block Structure Modification",
"source": "eip.md",
"summary": "The Header class is extended with bal_hash: Hash32, and the block body gains a BlockAccessList."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The explicit new bal_hash header field satisfies the rubric's binary score-3 condition.",
"score": 3,
"uncertainty_note": "The header field's exact RLP position is not stated, but its introduction is unambiguous.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility; Specification > State Transition Function",
"source": "eip.md",
"summary": "The change requires a hard fork and initializes per-block access collection during validation, but specifies no one-time state or existing-internal-variable modification at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "A fork requirement alone is not a new activation mechanism, and initialization of the new tracking structure is excluded by the rubric's special note.",
"score": 0,
"uncertainty_note": "Activation-block handling and migration are not described explicitly; no sealed evidence supports a score-3 state or internal-variable modification.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation; Rationale > Block Size Considerations; Rationale > Asynchronous Validation",
"source": "eip.md",
"summary": "The design changes disk-read and EVM scheduling, adds about 40 KiB average and up to about 0.93 MiB worst-case data in the stated analysis, and performs BAL verification alongside parallel IO and EVM operations."
},
{
"locator": "Security Considerations > Validation Overhead; Security Considerations > Block Size",
"source": "eip.md",
"summary": "The draft acknowledges added validation overhead and propagation impact from larger blocks."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance cannot be fully isolated because BAL construction, database access, execution scheduling, block propagation, and sync interact across the full block-processing path, with substantial effects on existing benchmarks.",
"score": 3,
"uncertainty_note": "The cited empirical analysis is not included in the allowlist and the asynchronous-performance claim is not supported by implementation evidence, so magnitudes cannot be independently confirmed.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > State Transition Function",
"source": "eip.md",
"summary": "BAL completeness and accuracy become consensus validity conditions, and post-state changes are intended to support state reconstruction without transaction execution."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The draft identifies validation overhead needed to prevent invalid-block acceptance and block-size propagation impact."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect access capture, canonicalization, hashing, or state-diff handling can affect consensus block acceptance and reconstructed state across execution, syncing, withdrawals, and system operations, warranting extensive review and fuzzing across critical components.",
"score": 3,
"uncertainty_note": "The security section is brief and the hash/state-reconstruction algorithms are incomplete, so the full invariant set cannot be enumerated from the sealed draft.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation; Specification > State Transition Function; Specification > Important Implementation Details > Edge Cases",
"source": "eip.md",
"summary": "BAL semantics build on EIP-2929 access collection, contrast with EIP-2930 access lists, and explicitly incorporate EIP-7002, EIP-7251, EIP-2935, EIP-4788, and purported EIP-7702 authority changes."
},
{
"locator": "Specification > Parameters; Storage read changes; SSTORE changes",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 defines the transaction-scoped accessed-address and accessed-storage-key sets whose access semantics EIP-7928 says clients must compare against the BAL."
},
{
"locator": "Abstract; Specification",
"source": "supporting/eip-2930.md",
"summary": "EIP-2930 transaction access lists prepopulate the same EIP-2929 access sets, creating coordinated semantics with block-level collection."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "The proposal has strong dependencies on multiple past and same-era mechanisms whose accesses and state changes must be represented canonically, requiring extensive coordinated cross-EIP vectors.",
"score": 3,
"uncertainty_note": "The EIP-7702 text link points to the allowlisted EIP-7792 document, which is about verifiable logs rather than authorities, and the other named system EIPs are not allowlisted; exact interaction semantics therefore remain partly unresolved.",
"under_specified": true
}
],
"eip": 7928,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7928:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The prose assigns system-contract changes transaction index transaction_count + 1, while the pseudocode comments and calls use len(block.transactions); withdrawals also use that index.",
"process_system_contracts is called both before and after transaction execution, while its body appears to process the same EIP-7002, EIP-7251, EIP-2935, and EIP-4788 cases each time.",
"The EIP names EIP-7702 authorities but links ./eip-7792.md; the packaged EIP-7792 is Verifiable logs and contains no authority semantics.",
"The draft says storage_reads include slots in pre-state but not written, which could be read as broader than actually accessed slots and conflicts with the stated access-list scope.",
"The concrete example describes a roughly 400-500-byte compressed BAL, while the rationale states roughly 40 KiB average; these may refer to example versus historical average but are not labeled consistently."
],
"provenance": {
"assessed_revision": {
"commit": "59be93753454b530b063d6d1b8c9acbff4116fe5",
"committed_at": "2025-07-31T13:42:40Z",
"content_sha256": "c1973b06017a4f8c036524a3b4a6746be994ccc95f90fe24f1a0e1e0103176bb",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7928.md",
"git_blob_sha": "23900781a2af96728f3f82bf0a91c2bdc1867320",
"immutable_url": "https://github.com/ethereum/EIPs/blob/59be93753454b530b063d6d1b8c9acbff4116fe5/EIPS/eip-7928.md",
"information_cutoff_at": "2025-07-31T16:00:14Z",
"path": "EIPS/eip-7928.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7928.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7928.yaml",
"sha256": "900cf876cd5ac525a1cb588e8ad63f04d9c0a0980aeb90c665044d79b5074de2"
},
"supporting_documents": [
"supporting/eip-2929.md",
"supporting/eip-2930.md",
"supporting/eip-7792.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 26,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "Assessment of the sealed 2025-07-31 Draft of EIP-7928: a mandatory SSZ-encoded block-level access list committed by a new header field and validated against execution-gathered account, storage, balance, nonce, and code accesses. The assessment covers only the proposal and allowlisted historical supporting EIPs, with no implementation or outcome evidence.",
"tier": "high",
"title": "Block-Level Access Lists",
"under_specification": {
"affected_criteria": [
"transition_tool_interface_changes",
"cryptography",
"block_syncing_changes",
"engine_api_changes",
"engine_api_encoding_changes",
"modified_system_contracts",
"encoding_changes_rlp_ssz",
"new_fork_activation_mechanism",
"security_risks",
"cross_eip_interactions"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 33,
"minimum": 21
},
"present": true,
"summary": "Material gaps remain in BAL commitment/hash construction, exact RLP block-body placement, transition-tool and Engine API schemas, system-operation ordering/indexing, and several canonical inclusion rules. These gaps are recorded once here and reflected only in directly affected criteria.",
"unresolved_questions": [
"What exact SSZ root/hash construction does compute_bal_hash use, and how is bal_hash validated and serialized in the header?",
"Where and in what exact envelope is the SSZ BAL carried in the RLP block body, including canonical empty and maximum-size encodings?",
"Which transition-tool and Engine API request/result fields and endpoint versions carry bal_hash and the BAL?",
"Do system-contract changes use transaction_count or transaction_count + 1, how are withdrawals ordered relative to them, and why are system contracts processed both before and after transactions?",
"Does the reference to EIP-7702 authorities intend a different supporting EIP than the packaged EIP-7792 Verifiable logs document?",
"How are unchanged writes, pre-state slots, reverts, repeated changes, and uint128 balance overflow handled canonically at all list limits?"
]
}
},
"amsterdam:7928:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State Transition Function, lines 271-336",
"source": "eip.md",
"summary": "The transition pseudocode executes transactions and observes their accesses and state changes, but introduces no gas charge or gas-accounting rule."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The BAL is an observation and block-validation mechanism. It neither adjusts an existing EVM gas rule nor introduces a new one, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State Transition Function, lines 417-421",
"source": "eip.md",
"summary": "Clients compare execution-gathered accesses, expressly referring to the pre-existing EIP-2929 access mechanism; no opcode's access or charge point is moved."
},
{
"locator": "Specification / Storage read changes, lines 60-71",
"source": "supporting/eip-2929.md",
"summary": "The supporting EIP already fixes when account and storage access charges and accessed-set updates occur inside affected opcodes."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "EIP-7928 makes the gathered accesses consensus-observable but does not itself change where an opcode accesses state or where gas is charged relative to that access. The rubric directs that observability alone is not scored here.",
"score": 0,
"uncertainty_note": "The draft does not fully map every exceptional execution path to a BAL entry; that missing consensus definition is scored under unspecified behavior, not as an ordering change.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / SSZ Data Structures, lines 43-119",
"source": "eip.md",
"summary": "The new structures contain account and state-access data and specify no blob-gas fields, prices, or accounting behavior."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is changed or introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 121-159",
"source": "eip.md",
"summary": "The proposal records storage, balance, nonce, and code accesses or changes, but assigns no state-gas costs, budget, reservoir, or spill behavior to them."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Recording state diffs is not a state-gas charging rule, so none of the state-gas anchors is triggered.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Important Implementation Details, lines 163-172",
"source": "eip.md",
"summary": "Gas refunds are mentioned only to require recording the sender's final balance after each transaction."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No refund is created or modified; the proposal only observes a balance after ordinary refund processing.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Structure Modification, lines 29-45",
"source": "eip.md",
"summary": "Every post-fork block gains a header commitment and a body-level BlockAccessList."
},
{
"locator": "Specification / State Transition Function, lines 417-419",
"source": "eip.md",
"summary": "Any missing or spurious BAL entry invalidates the block, and clients must compare the supplied list with execution-gathered accesses."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork block and execution scenarios across diverse opcode, transaction, system-action, and sync categories must be reworked to carry a correctly derived BAL and commitment. This is a major, diverse subset rather than a narrow contrived class.",
"score": 3,
"uncertainty_note": "The draft does not describe a test migration plan, but the fork-wide block-validity consequence is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State Transition Function, lines 295-299 and 417-419",
"source": "eip.md",
"summary": "A computed BAL must match the new header commitment, and completeness and absence of spurious entries are mandatory block-validity conditions."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Regardless of what an execution test principally exercises, every test instantiated at the fork must additionally satisfy and check the BAL commitment and exact-content invariant. Existing scenarios carried into the fork therefore require mechanically re-derived BAL data.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block Structure Modification and State Transition Function, lines 29-45 and 271-299",
"source": "eip.md",
"summary": "The transition consumes a new body-level BAL and header commitment and must execute a new access-collection and commitment-comparison mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Even though the draft does not name a transition-tool schema, the tool must represent the BAL validation mechanism and its new block data. That establishes at least the score-2 anchor for a new interface mechanism; the exact multiplicity of fields is not specified well enough to select 3.",
"score": 2,
"uncertainty_note": "The input/output ownership of bal_hash, the encoded BAL, and any computed BAL artifact is not defined; a fully specified interface could warrant score 3.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / SSZ Data Structures and State Transition Function, lines 43-119 and 295-299",
"source": "eip.md",
"summary": "Tests need to construct a nested ordered SSZ BAL, derive its commitment, and compare it with execution-collected accesses."
},
{
"locator": "Specification / State Transition Function, lines 417-419",
"source": "eip.md",
"summary": "Missing and spurious entries are consensus-invalid, requiring reusable exact-BAL expectations and mutation support."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Because every post-fork block needs this artifact, BAL derivation, encoding, commitment, and invalid-entry expectations must be framework-level primitives used by unrelated EIP tests, not helpers confined to EIP-7928's own cases.",
"score": 3,
"uncertainty_note": "The historical package contains no test-framework design, so the exact primitive split remains an implementation choice.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / BAL Design Choice, lines 425-437",
"source": "eip.md",
"summary": "The proposal selects SSZ for encoding and its existing Merkle-proof properties; it does not define a new cryptographic construction."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Existing SSZ commitment and hash use do not introduce or modify a cryptography mechanism under this anchor.",
"score": 0,
"uncertainty_note": "The exact compute_bal_hash derivation is unspecified, but the text provides no evidence that it is novel cryptography.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 128-177",
"source": "eip.md",
"summary": "The BAL distinguishes changed, zeroed, unchanged, read-only, and read-write slots and enumerates SELFDESTRUCT, zero-value, exceptional-halt, withdrawal, and system-contract cases."
},
{
"locator": "Specification / SSZ Data Structures, lines 47-118",
"source": "eip.md",
"summary": "Nested lists have several independent maxima and ordering requirements, with transaction indices and multiple state-field change lists."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact, and exact-list validity requires an elevated matrix over state value transitions, transaction ordering, reverts or halts, system actions, and maximum lengths. This satisfies score 3.",
"score": 3,
"uncertainty_note": "Several boundary outcomes are unresolved in the draft, especially non-transaction indices and reverted or failed accesses.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block Structure Modification, lines 29-45",
"source": "eip.md",
"summary": "The block header gains bal_hash and the block body gains a BlockAccessList."
},
{
"locator": "Rationale / BAL Design Choice and Backwards Compatibility, lines 431-437 and 459-461",
"source": "eip.md",
"summary": "The SSZ BAL is embedded as opaque bytes in the RLP block, supports executionless state reconstruction, and is a non-backward-compatible block-structure change."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Sync validation must handle multiple related mechanisms: the changed header/body RLP shape, nested SSZ decoding and limits, commitment matching, and full semantic validation. At least one is complex, meeting score 3.",
"score": 3,
"uncertainty_note": "The exact RLP body placement and hash derivation are absent, so some validation cases cannot yet be baselined.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / Block Structure Modification, lines 29-45",
"source": "eip.md",
"summary": "The execution block acquires two distinct protocol data elements, bal_hash in the header and the BlockAccessList in the body."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "Payload construction and validation must convey the new commitment and BAL data across the execution-payload interface, implying multiple Engine API fields or equivalent versioned representations. The draft does not propose a new endpoint, so score 3 is not supported.",
"score": 2,
"uncertainty_note": "No Engine API directive or field ownership is specified. Depending on whether one side derives bal_hash, the eventual interface could require only one new field and score 1.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Important Implementation Details, lines 173-177",
"source": "eip.md",
"summary": "The proposal records effects caused by already-referenced system contracts but does not introduce a contract, address, code deployment, or new system action of its own."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added by EIP-7928.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Important Implementation Details, lines 173-177",
"source": "eip.md",
"summary": "Storage effects of EIP-7002, EIP-7251, EIP-2935, and EIP-4788 system processing must be represented in the BAL."
},
{
"locator": "Specification / State Transition Function, lines 376-404",
"source": "eip.md",
"summary": "The pseudocode adds tracking around several existing system contracts and records their storage writes under a block-level index."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal does not alter those contracts' code or underlying state-transition rules, but it gives the outputs of multiple system-contract actions a major new indirect effect on block validity. That matches score 2 rather than the direct-modification anchor at 3.",
"score": 2,
"uncertainty_note": "The pseudocode is internally unclear about which contracts run before or after transactions and withdrawals and about their assigned index.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 121-170",
"source": "eip.md",
"summary": "Existing opcodes such as SLOAD, SSTORE, BALANCE, STATICCALL, CREATE, and SELFDESTRUCT are discussed only as sources of accesses or changes."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 121-170",
"source": "eip.md",
"summary": "The proposal records effects of existing opcodes without changing their stack behavior, returned values, state-transition results, or deprecating them."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "BAL observability does not modify an opcode's result or non-gas behavior under this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / SSZ Data Structures and Important Implementation Details, lines 43-177",
"source": "eip.md",
"summary": "The complete data-model and edge-case specification adds no precompile address, input format, or execution rule."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State Transition Function, lines 271-336",
"source": "eip.md",
"summary": "Generic execution access tracking is added, but no precompile logic or gas schedule is changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile behavior or gas accounting is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Structure Modification and SSZ Data Structures, lines 29-119",
"source": "eip.md",
"summary": "A new header field and an SSZ-encoded nested BlockAccessList are added at block level."
},
{
"locator": "Rationale / BAL Design Choice, lines 425-437",
"source": "eip.md",
"summary": "The design explicitly embeds the SSZ BAL as opaque bytes in the RLP block."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The rubric assigns score 3 whenever encoding changes are introduced at block level; this proposal does so directly.",
"score": 3,
"uncertainty_note": "The exact SSZ commitment and RLP placement are missing, but the existence of a block-level encoding change is unambiguous.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Structure Modification, lines 29-45",
"source": "eip.md",
"summary": "The new data is attached to the block header and body, not to a new transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State Transition Function, lines 273-299 and 417-421",
"source": "eip.md",
"summary": "Transactions execute under their existing rules; the new assertion compares a block-level BAL after gathering their effects."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The EIP changes block validity, not transaction-type validity or intrinsic gas calculation.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Structure Modification, lines 29-41",
"source": "eip.md",
"summary": "The Header class is explicitly extended with a new Hash32 bal_hash field, and the body carries the corresponding BAL."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The binary rubric anchor assigns score 3 for any new block or header field.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 459-461",
"source": "eip.md",
"summary": "The proposal requires a hard fork because of its block-structure change but specifies no activation-block state mutation or modification of an existing internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "A schema change beginning at a fork is not the activation-block mutation scored by this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Motivation, lines 13-25",
"source": "eip.md",
"summary": "The mechanism is intended to reshape disk reads, transaction validation, and EVM execution through parallelism."
},
{
"locator": "Rationale / Block Size Considerations and Asynchronous Validation, lines 439-457",
"source": "eip.md",
"summary": "The draft reports about 40 KiB average compressed overhead, a 0.93 MiB worst case at 36m gas, and concurrent BAL verification with I/O and EVM work."
},
{
"locator": "Security Considerations, lines 463-471",
"source": "eip.md",
"summary": "Validation overhead and increased propagation size are acknowledged explicitly."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Full-block access instrumentation, sorting, SSZ construction, hashing, propagation, and parallel scheduling cannot be validated wholly in isolation and interact with existing execution, database, sync, and networking performance. The expected impact on established benchmarks is substantial, satisfying score 3.",
"score": 3,
"uncertainty_note": "The cited size analysis is summarized but its linked asset is not in the sealed package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State Transition Function, lines 295-299 and 417-421",
"source": "eip.md",
"summary": "Consensus acceptance depends on exact equality between an untrusted block commitment and execution-gathered accesses, with missing or spurious entries invalidating the block."
},
{
"locator": "Abstract and Security Considerations, lines 13-15 and 463-471",
"source": "eip.md",
"summary": "The BAL is also intended to enable executionless state updates, while the draft acknowledges validation and propagation overhead."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect implementation can affect consensus validity and state reconstruction, and the mechanism spans critical execution, state, serialization, sync, and networking components. Those altered assumptions require extensive security review and fuzzing, matching score 3.",
"score": 3,
"uncertainty_note": "The draft's security section does not analyze malformed encodings, commitment ambiguity, or access-tracking disagreement in detail.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 121-177 and 417-419",
"source": "eip.md",
"summary": "The draft demands a complete and exact list of every access while describing categories and selected edge cases rather than a complete per-operation observation rule."
},
{
"locator": "Specification / State Transition Function, lines 271-299 and 376-414",
"source": "eip.md",
"summary": "Illustrative pseudocode leaves compute_bal_hash undefined, processes system contracts in apparently conflicting phases, and assigns non-transaction effects an index inconsistently with the prose."
},
{
"locator": "Specification, lines 47-49 and 65-74",
"source": "supporting/eip-2929.md",
"summary": "The referenced access sets have revert and precise in-opcode timing semantics, making the exact mapping from attempted execution to persistent BAL entries observable at gas, failure, and revert boundaries."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "EIP-7928 turns the previously non-committed exact set and timing of accesses into consensus-critical block data, yet constructible failure, revert, preload, system-action, indexing, and commitment cases do not have a unique answer. This is the score-3 case of previously unobservable behavior becoming consensus-critical and requiring repeated cross-client re-baselining as the draft is clarified.",
"score": 3,
"uncertainty_note": "Material gaps include commitment derivation, RLP placement, failed or reverted accesses, EIP-2930 preloads, system-action ordering and indices, and the mismatched EIP-7702/EIP-7792 reference.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Specification, lines 17-20, 159-177, and 417-419",
"source": "eip.md",
"summary": "The proposal contrasts EIP-2930 lists, relies on EIP-2929 access gathering, records EIP-7702 authority nonces, and incorporates effects attributed to EIPs 7002, 7251, 2935, and 4788."
},
{
"locator": "Abstract and Specification, lines 17-21 and 75-104",
"source": "supporting/eip-2930.md",
"summary": "EIP-2930 populates the EIP-2929 accessed sets before execution, creating a coordinated question about whether declared-but-unused items belong in the BAL."
},
{
"locator": "Front matter and Abstract, lines 1-16",
"source": "supporting/eip-7792.md",
"summary": "The packaged target of the draft's EIP-7702 hyperlink is actually EIP-7792, Verifiable logs, exposing a historical cross-reference ambiguity rather than establishing a verifiable-logs interaction."
}
],
"exceptional_score_justification": "Cross-EIP interactions is explicitly uncapped. Seven identified interacting EIPs leave four beyond the first three, which triggers one rubric-defined +1 increment and produces score 4.",
"id": "cross_eip_interactions",
"interacting_eips": [
2929,
2930,
7702,
7002,
7251,
2935,
4788
],
"rationale": "The BAL has strong, test-relevant interdependencies with seven identified EIPs: 2929, 2930, 7702, 7002, 7251, 2935, and 4788. Access-set initialization and per-opcode tracking, authority nonce changes, and four system-transition paths each need coordinated expected BAL cases. A base score of 3 plus one increment for four additional EIPs beyond the first three yields 4.",
"score": 4,
"uncertainty_note": "The authority reference names EIP-7702 but links to the packaged EIP-7792; 7702 is retained because it is the number stated in the normative sentence, while 7792 is not counted as an interaction. Some system EIP timing is contradictory.",
"under_specified": true,
"unidentified_interactions": []
}
],
"eip": 7928,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7928:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The normative source defines bal_hash only as Hash32 and calls compute_bal_hash without specifying the commitment derivation.",
"The prose assigns system-contract effects transaction_count + 1, while the pseudocode uses transaction_count and also assigns that value to withdrawals.",
"The two process_system_contracts calls are described as covering different EIP sets, but the single function body tracks all four named system mechanisms on either call.",
"The text names EIP-7702 authorities but links to eip-7792.md; the packaged EIP-7792 concerns verifiable logs and supplies no authority definition.",
"Storage reads include the phrase \"slots in pre-state but not written,\" which does not state whether access is required and conflicts with the surrounding access-based definition if read literally."
],
"provenance": {
"assessed_revision": {
"commit": "59be93753454b530b063d6d1b8c9acbff4116fe5",
"committed_at": "2025-07-31T13:42:40Z",
"content_sha256": "c1973b06017a4f8c036524a3b4a6746be994ccc95f90fe24f1a0e1e0103176bb",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7928.md",
"git_blob_sha": "23900781a2af96728f3f82bf0a91c2bdc1867320",
"immutable_url": "https://github.com/ethereum/EIPs/blob/59be93753454b530b063d6d1b8c9acbff4116fe5/EIPS/eip-7928.md",
"information_cutoff_at": "2025-07-31T16:00:14Z",
"path": "EIPS/eip-7928.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7928.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7928.yaml",
"sha256": "3b2272986a041633b681ebcae0b5678d6d59ed6c0f94ef3bd279efe6689e0ffe"
},
"supporting_documents": [
"supporting/eip-2929.md",
"supporting/eip-2930.md",
"supporting/eip-7792.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 40,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this draft introduced a consensus-enforced Block-Level Access List in the block body and a new header commitment, with an ordered SSZ structure covering accessed accounts, storage reads, and per-transaction storage, balance, nonce, and code changes. Clients were required to gather accesses and changes during execution, system processing, and withdrawals, then reject a block whose committed BAL was incomplete, spurious, or inaccurate. The stated goals were parallel I/O and transaction validation, plus state reconstruction without transaction execution.",
"tier": "high",
"title": "Block-Level Access Lists",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"transition_tool_interface_changes",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"modified_system_contracts",
"encoding_changes_rlp_ssz",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 41,
"minimum": 37
},
"present": true,
"summary": "The draft establishes exact BAL validity without fully specifying how every execution path maps into the list, how the SSZ object is committed and embedded in the RLP body, or how system and withdrawal effects are ordered and indexed. It also omits transition-tool and Engine API representations and contains an EIP-7702 hyperlink that resolves to the packaged EIP-7792. These are material because distinct client choices can produce different bal_hash values for the same execution.",
"unresolved_questions": [
"What exact SSZ serialization or tree root does compute_bal_hash use, is compression consensus-visible, and where are the opaque BAL bytes placed in the RLP block body?",
"Do failed, reverted, out-of-gas, or declared-but-unused EIP-2930 accesses remain in the BAL, and at what exact point does each state-accessing operation become recordable?",
"Are EIP-7002 and EIP-7251 processed only after transactions, are EIP-2935 and EIP-4788 processed only before them, and why does the generic pseudocode process all four in both calls?",
"Do system effects use transaction_count or transaction_count + 1, and how are they distinguished from withdrawals that also use transaction_count in the pseudocode?",
"Which new fields are inputs or outputs of transition-tool and Engine API interfaces, and which component derives bal_hash?",
"Does the authority nonce rule intend EIP-7702 as written, or EIP-7792 as linked, whose packaged text instead specifies verifiable logs?"
]
}
},
"amsterdam:7954:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal changes the two size-limit constants and expressly describes the change as limited to those thresholds, with no other protocol changes."
},
{
"locator": "Parameters and Rules, lines 42-60",
"source": "supporting/eip-3860.md",
"summary": "EIP-3860 separately defines the existing per-word initcode gas formula and the maximum-size checks; EIP-7954 changes the latter but specifies no change to the former."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Raising an admissibility threshold allows the existing metering formula to cover larger inputs, but it neither updates nor introduces a gas-accounting rule. This matches the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The complete normative change consists of two size-limit updates and does not change state access or gas charging relative to state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state-access site or within-opcode ordering rule is changed, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal is confined to deployed-code and initcode size limits and introduces no blob-related rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "There is no blob gas accounting change, satisfying the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "Only maximum code and initcode lengths are changed; no state-byte cost, state-gas budget, reservoir, or spill rule is specified."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "A code-size admission cap is not a state-gas charging rule, and none of the state-gas mechanisms named by this anchor changes. The score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal changes only size limits and contains no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced or modified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-25",
"source": "eip.md",
"summary": "Both previously established size thresholds are replaced with larger exact values."
},
{
"locator": "Test Cases, lines 105-113",
"source": "supporting/eip-3860.md",
"summary": "Existing EIP-3860 tests explicitly cover the initcode maximum and one byte above it for CREATE, CREATE2, and creation transactions."
},
{
"locator": "Specification, lines 19-21",
"source": "supporting/eip-170.md",
"summary": "EIP-170 makes creation fail when returned code is more than its maximum, establishing an existing boundary expectation affected by the new value."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests at and around the old code and initcode limits need updated inputs or expectations. This is a minor, narrow subset of creation tests, so score 1 fits better than the considerable-subset anchor.",
"score": 1,
"uncertainty_note": "The package does not enumerate the full pre-existing test corpus, but it does identify the boundary cases that necessarily change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal replaces two validation thresholds and adds no new output or property that unrelated tests must assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Boundary tests change their expected result, but pre-existing tests do not gain an additional invariant to assert. This is the score-0 case.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 22-35",
"source": "eip.md",
"summary": "The proposal specifies two fork-gated constant changes and no new input or output field for a state transition tool."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Ordinary fork selection can select the constants; no transition-tool interface field or mechanism is required. The score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-25",
"source": "eip.md",
"summary": "The normative change is expressible as ordinary length-boundary behavior for contract creation and initcode."
},
{
"locator": "Test Cases, lines 105-113",
"source": "supporting/eip-3860.md",
"summary": "The underlying mechanism's tests are conventional creation cases at the maximum and maximum plus one, with no special expectation abstraction described."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing transaction and opcode test primitives suffice for updated boundary cases, so no new framework primitive is required and the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal changes only code-size limits and introduces no cryptographic algorithm or functionality."
},
{
"locator": "Gas cost per word, lines 75-79",
"source": "supporting/eip-3860.md",
"summary": "The supporting EIP mentions existing CREATE2 hash-cost compatibility, but EIP-7954 does not alter that mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Existing hashing may process a larger admissible initcode input, but no cryptographic mechanism changes. The score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-25",
"source": "eip.md",
"summary": "The proposal changes two distinct byte-length boundaries: deployed runtime code and initcode."
},
{
"locator": "Specification, lines 19-21",
"source": "supporting/eip-170.md",
"summary": "The runtime-code boundary distinguishes lengths at the maximum from lengths greater than it, with over-limit creation failing out of gas."
},
{
"locator": "Rules and Test Cases, lines 55-60 and 105-113",
"source": "supporting/eip-3860.md",
"summary": "The initcode boundary applies through transaction invalidity and exceptional aborts for CREATE and CREATE2, with explicit maximum and maximum-plus-one cases."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Two boundary-prone mechanisms must be covered, and the initcode threshold has three execution or validation paths. These are multiple boundary conditions, but none requires the elevated combinatorial case count of score 3, so the score is 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 22-35",
"source": "eip.md",
"summary": "The hard-fork change concerns contract-creation size limits and specifies no new block RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Although create-transaction validity changes, block encoding and RLP validation do not. Under this anchor's RLP-specific definition, the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal contains only two size-limit changes and no Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal changes constants governing ordinary contract creation and does not introduce a system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal changes general code and initcode size limits without naming or altering any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "There is no direct or identified indirect system-contract modification, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal updates limits inherited from EIPs 170 and 3860 and introduces no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-25",
"source": "eip.md",
"summary": "EIP-7954 raises EIP-3860's initcode maximum from 48 KiB to 64 KiB."
},
{
"locator": "Rules, lines 55-60",
"source": "supporting/eip-3860.md",
"summary": "The EIP-3860 limit governs whether CREATE and CREATE2 exceptionally abort; inputs above the old limit but at or below the new limit therefore change opcode outcome."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least CREATE and CREATE2 have non-gas behavior modified for initcode in the newly admitted range. The rubric assigns score 3 whenever any pre-existing opcode behavior changes apart from gas changes.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The size-limit update adds no precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The size-limit update does not name or modify precompile logic or gas accounting."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal adjusts byte-length limits but does not change transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Permitting a larger payload within an existing representation is not an RLP, SSZ, or interface encoding change. The score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-25",
"source": "eip.md",
"summary": "The proposal changes limits applicable to existing creation behavior and defines no transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-25",
"source": "eip.md",
"summary": "The EIP raises EIP-3860's initcode size limit from 48 KiB to 64 KiB."
},
{
"locator": "Rules, lines 55-60",
"source": "supporting/eip-3860.md",
"summary": "EIP-3860 makes a create transaction invalid when its initcode exceeds the maximum, so raising the maximum changes validity for transactions in the intervening range."
},
{
"locator": "Test Cases, lines 105-113",
"source": "supporting/eip-3860.md",
"summary": "Existing tests exercise creation transactions at the maximum and maximum plus one, showing the limited boundary updates required."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The validity threshold of an existing create transaction is modified and its boundary tests must change, but updates are localized and require no testing infrastructure redesign. This matches score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 22-31",
"source": "eip.md",
"summary": "The proposal changes two creation-related constants and introduces no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is added, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 22-35",
"source": "eip.md",
"summary": "The limit change requires a network upgrade, but the proposal specifies no activation-block state mutation or modification of an internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "A normal hard-fork rule change is not itself the activation mechanism scored here. No state or internal variable is modified at activation, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Security Considerations, lines 18-20 and 37-39",
"source": "eip.md",
"summary": "The proposal permits larger contracts while seeking reasonable growth constraints and characterizes the resulting denial-of-service increase as marginal with a conservative new limit."
},
{
"locator": "Rationale, lines 23-25",
"source": "supporting/eip-170.md",
"summary": "The code-size cap bounds linear disk reads, VM preprocessing, and Merkle proof data, which are existing performance-sensitive paths."
},
{
"locator": "Motivation and Reason for size limit, lines 22-24 and 81-85",
"source": "supporting/eip-3860.md",
"summary": "The initcode cap bounds linearly scaling jump-destination analysis and helps constrain worst-case performance searches."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Raising both caps expands worst-case inputs across several existing performance paths, so validation is not confined to a new isolated mechanism. The EIP describes the increment as marginal and conservative, supporting the limited-impact score-2 anchor rather than substantial score 3.",
"score": 2,
"uncertainty_note": "The package supplies qualitative risk statements and the prior mechanisms' scaling rationale, but no benchmark of the proposed new limits.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, lines 37-39",
"source": "eip.md",
"summary": "The EIP expressly says the higher contract size limit may marginally increase denial-of-service risk, while calling the new limit conservative."
},
{
"locator": "Rationale, lines 23-25",
"source": "supporting/eip-170.md",
"summary": "EIP-170's cap mitigates a linear-cost vulnerability spanning disk reads, VM code preprocessing, and proof data."
},
{
"locator": "Motivation and Security Considerations, lines 22-34 and 114-120",
"source": "supporting/eip-3860.md",
"summary": "The initcode limit and metering protect jump-destination analysis, an existing denial-of-service-sensitive client path."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The larger caps slightly relax existing denial-of-service bounds and touch a limited set of code-loading, preprocessing, proof, and initcode-analysis components. That alters existing security assumptions enough for targeted review or fuzzing but is not the broad critical interaction of score 3, so the score is 2.",
"score": 2,
"uncertainty_note": "The proposal calls the increase marginal but provides no quantitative security analysis of the proposed thresholds.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-25",
"source": "eip.md",
"summary": "The proposal gives exact replacement values for both affected maximum-size constants."
},
{
"locator": "Specification, lines 19-21",
"source": "supporting/eip-170.md",
"summary": "The inherited runtime-code rule precisely specifies failure for a returned length greater than the maximum."
},
{
"locator": "Parameters and Rules, lines 42-60",
"source": "supporting/eip-3860.md",
"summary": "The inherited initcode rules precisely distinguish over-limit transaction invalidity from CREATE/CREATE2 exceptional abort and retain an exact gas formula."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Substituting the two exact constants into the linked rules determines equality and over-limit behavior for transaction and opcode paths. No constructible case in the described scope requires a new cross-client agreement, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Specification, lines 1-12 and 22-25",
"source": "eip.md",
"summary": "EIP-7954 formally requires EIPs 170 and 3860 and directly replaces one limit defined by each."
},
{
"locator": "Parameters and Specification, lines 14-21",
"source": "supporting/eip-170.md",
"summary": "EIP-170 defines the maximum deployed code size and the creation-failure rule that the proposal modifies."
},
{
"locator": "Abstract and Rules, lines 14-20 and 55-60",
"source": "supporting/eip-3860.md",
"summary": "EIP-3860 ties its initcode maximum to EIP-170 and applies it to creation transactions, CREATE, and CREATE2, requiring coordinated boundary coverage."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
170,
3860
],
"rationale": "The proposal directly modifies two prior EIPs and their related transaction and opcode boundary tests. Coordination is required, but the interactions are limited to two size constants and their existing failure paths, matching score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7954,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7954:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The increased initcode maximum lets the unchanged EIP-3860 metering formula apply over a larger admissible range. This assessment treats that as a validity and opcode-behavior change, not an EVM gas-accounting rule change, because no cost or formula is modified.",
"The supporting EIP-3860 text mentions CREATE2's EIP-1014 hash-cost mechanism, but EIP-7954 neither identifies EIP-1014 as a requirement nor changes that gas mechanism; therefore only EIPs 170 and 3860 are recorded as interacting EIPs."
],
"provenance": {
"assessed_revision": {
"commit": "e43e899bb103f267a7844599c7cd3226518b519d",
"committed_at": "2026-01-18T00:29:01Z",
"content_sha256": "1bf217c99adf734189de03ae8b9828ff17a2a3a779b6fe12e8fba1718fb20ced",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7954.md",
"git_blob_sha": "d3dde5b7cd6564fb8aefb26050abcd5b02a2ffb7",
"immutable_url": "https://github.com/ethereum/EIPs/blob/e43e899bb103f267a7844599c7cd3226518b519d/EIPS/eip-7954.md",
"information_cutoff_at": "2026-01-20T14:22:47Z",
"path": "EIPS/eip-7954.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7954.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7954.yaml",
"sha256": "a66e9938499f0c1ca29c557d5d17260987a21e70ab10368da835491c291da09c"
},
"supporting_documents": [
"supporting/eip-170.md",
"supporting/eip-3860.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 14,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7954 proposed raising the maximum deployed contract code size from 24,576 to 32,768 bytes and the maximum initcode size from 49,152 to 65,536 bytes. This changes the EIP-170 contract-creation result threshold and the EIP-3860 create-transaction and CREATE/CREATE2 initcode thresholds, while the proposal states that only the size limits change. Activation requires a network upgrade, and the proposal identifies a marginal denial-of-service risk from permitting larger contracts.",
"tier": "medium",
"title": "Increase Maximum Contract Size",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 14
},
"present": false,
"summary": "No material under-specification is present. The proposal supplies exact new constants, and the allowlisted EIPs define the equality, over-limit, transaction-validity, and opcode-failure semantics into which those constants are substituted.",
"unresolved_questions": []
}
},
"amsterdam:7976:human:r1": {
"checklist": {
"input_alignment": "no_substantive_drift",
"parser_notes": [],
"published_tier": "low",
"published_total": 5,
"recomputed_tier": "low",
"recomputed_total": 5,
"timing_exposure": "high_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Affects an existing mechanism for which tests are already prepared to be automatically updated.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Pattern affects many tests but the test framework is already well prepared for this change due work already done in EIP-7623 testing. However, static tests might break after these change because these have to be manually updated.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Contains edge-cases but automatic test generators for these conditions already exist as part of tests for EIP-7623.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Mechanism affects validity, but we only have to pay attention to the fork transition when the values change, as the rest of the scenarios will be automatically updated by updating a few constants.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7976,
"fork": "amsterdam",
"id": "amsterdam:7976:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "173fe4aade1b70114347b6566bb96ed17959c696",
"committed_at": "2025-11-04T14:01:49Z",
"content_sha256": "34c48660c11fbdc111c12ce09cf320829e1d1124aa03be0717c218a631bcb953",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7976.md",
"git_blob_sha": "7310f62b56234d3d2e7715cdd9d10ea173116d65",
"immutable_url": "https://github.com/ethereum/EIPs/blob/173fe4aade1b70114347b6566bb96ed17959c696/EIPS/eip-7976.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7976.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7976.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7976.yaml",
"sha256": "a2808654dc90de2790f6264debf2ebfa1006dda9d7e72566c46e53f4d349d716"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "ce4d90eda1388dde9e23e42f804a82830779a8ef",
"committed_at": "2025-11-06T14:00:18Z",
"content_sha256": "221b4016db2b1153cb5dcb7b38ccc8a443afaf1da1d0eca85d454bb51a72a532",
"git_blob_sha": "d3e6776fa94c999bf4b0b2254e9ee7f716282612",
"immutable_url": "https://github.com/ethspecs/pm/blob/ce4d90eda1388dde9e23e42f804a82830779a8ef/complexity_assessments/EIPs/EIP-7976.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7976.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 5,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "low",
"title": "Increase Calldata Floor Cost",
"under_specification": null
},
"amsterdam:7976:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — parameter table and `tx.gasUsed` formula",
"source": "eip.md",
"summary": "Sets `TOTAL_COST_FLOOR_PER_TOKEN` to 15 and applies it through the existing maximum of standard execution cost and calldata floor cost."
},
{
"locator": "Specification — parameter table and changed `tx.gasUsed` formula",
"source": "supporting/eip-7623.md",
"summary": "Defines the pre-existing floor mechanism with the same formula and a floor parameter of 10."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "evm_gas_rule_changes",
"rationale": "The proposal updates an existing EVM transaction gas-accounting mechanism by repricing its floor parameter; it does not introduce a different accounting mechanism. This matches score 1.",
"score": 1,
"uncertainty_note": "The arithmetic change is explicit; concrete client/spec pseudocode beyond the formula is not included.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale — calldata floor formula and Better blob incentivization",
"source": "eip.md",
"summary": "The normative change prices transaction calldata; blobs appear only as an incentive rationale, with no blob-gas rule specified."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is added or modified, so the row scores 0.",
"score": 0,
"uncertainty_note": "The proposal may indirectly encourage blob use, but an economic incentive is not a blob gas accounting change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — definition of `execution_gas_used` and `tx.gasUsed` formula",
"source": "eip.md",
"summary": "Uses execution gas after subtracting an existing refund in the floor calculation but specifies no new refund rule."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_evm_gas_refund",
"rationale": "Referencing refund-adjusted execution gas does not introduce a gas-refund mechanism; score 0 applies.",
"score": 0,
"uncertainty_note": "Refund behavior at the floor crossover is not illustrated with vectors, but no new refund is specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases — items 1–5",
"source": "eip.md",
"summary": "Calls for coverage of data-heavy and EVM-heavy transactions, the branch boundary, gas estimation, and insufficient-gas rejection under the new floor."
},
{
"locator": "Specification — `TOTAL_COST_FLOOR_PER_TOKEN` and validity threshold",
"source": "supporting/eip-7623.md",
"summary": "Shows that the affected behavior already exists with a floor parameter of 10, so prior floor-sensitive expectations must be repriced."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The parameter change affects a focused subset of pre-existing tests whose expected gas use or validity is floor-sensitive. The sealed evidence supports a minor, localized subset rather than a considerable or diverse test rewrite, matching score 1.",
"score": 1,
"uncertainty_note": "No pre-existing test inventory or concrete vectors are supplied, so the exact number of affected tests cannot be established.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Backwards Compatibility",
"source": "eip.md",
"summary": "Defines a fork-scheduled gas repricing and calls for wallet/node gas-estimation updates without adding transition-tool input or output fields."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "transition_tool_interface_changes",
"rationale": "The proposal requires a ruleset update but specifies no transition-tool interface field or new interface mechanism; score 0 applies.",
"score": 0,
"uncertainty_note": "The proposal does not describe a transition-tool mapping, so the conclusion rests on the absence of any specified interface change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — calldata token counting and gas-used formula",
"source": "eip.md",
"summary": "The complete normative mechanism consists of byte counting, integer constants, and gas arithmetic, with no cryptographic operation."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cryptography",
"rationale": "No cryptographic mechanism or cryptographic functionality is introduced or modified; score 0 applies.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — `max(...)` gas-used formula and minimum gas-limit validity rule",
"source": "eip.md",
"summary": "Creates floor-sensitive boundaries at equality between the standard and floor branches and at the maximum of intrinsic cost and the reserved floor."
},
{
"locator": "Test Cases — items 2, 3, and 5",
"source": "eip.md",
"summary": "Explicitly requests EVM-heavy exemption, equality/crossover, and insufficient-gas-limit cases."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "edge_boundary_conditions",
"rationale": "Two related but distinct boundary-prone mechanisms require coverage: selection between gas-used branches and transaction validity against competing minimums. Neither is shown to need an elevated number of cases, matching score 2.",
"score": 2,
"uncertainty_note": "No numeric boundary vectors are supplied, and coverage across zero/non-zero calldata and contract creation is not enumerated.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Changes transaction gas accounting and gas-limit validity without specifying block RLP validation."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requiring sync testing is introduced; score 0 applies.",
"score": 0,
"uncertainty_note": "The proposal discusses maximum payload size but not block encoding or sync-validation rules.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility — Wallets and Node Software",
"source": "eip.md",
"summary": "Requires `eth_estimateGas` handling updates but introduces no Engine API endpoint, directive field, or communication mechanism."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "engine_api_changes",
"rationale": "An execution RPC estimation update is not an Engine API field change under the row definition; score 0 applies.",
"score": 0,
"uncertainty_note": "No Engine API consequences are described in the sealed sources.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification and Backwards Compatibility",
"source": "eip.md",
"summary": "Specifies arithmetic gas-rule and `eth_estimateGas` updates, with no Engine API encoding described."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "engine_api_encoding_changes",
"rationale": "Because the historical checklist supplies no definition for this row, it is scored conservatively from the label alone. No Engine API encoding change is visible, so the score is 0.",
"score": 0,
"uncertainty_note": "The source template has no dedicated definition for Engine API encoding changes; no substitute definition was imported.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Defines constants and transaction gas formulas only; it does not deploy or invoke a new system contract."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_system_contracts",
"rationale": "No system contract is introduced; score 0 applies.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative change is confined to transaction calldata floor accounting and validity, with no system-contract code, state, or action identified."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_system_contracts",
"rationale": "No direct or discernible indirect modification of a pre-existing system contract is specified; score 0 applies.",
"score": 0,
"uncertainty_note": "Generic transactions involving system contracts are not identified as a distinct interaction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Changes transaction-level gas arithmetic without defining an opcode."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_opcodes",
"rationale": "No opcode is introduced; score 0 applies.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The floor applies to transaction gas used and gas-limit validity; no pre-existing opcode behavior is changed."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated, and the row explicitly excludes gas-only changes; score 0 applies.",
"score": 0,
"uncertainty_note": "Contract-creation cost is an input to the transaction formula, not an opcode behavior change in this proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Defines no precompile address, input, output, behavior, or gas schedule."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_precompiles",
"rationale": "No precompile is introduced; score 0 applies.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Only the transaction calldata floor parameter and related formulas are changed; no precompile logic or gas schedule is mentioned."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified; score 0 applies.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Reprices calldata through gas arithmetic while leaving transaction, block, and interface encodings unspecified and unchanged."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, transaction, block, or interface encoding change is introduced; score 0 applies.",
"score": 0,
"uncertainty_note": "Payload-size effects do not themselves alter payload encoding.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — transaction gas-used and gas-limit rules",
"source": "eip.md",
"summary": "Applies rules to transactions generically and defines no new transaction envelope or type."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced; score 0 applies.",
"score": 0,
"uncertainty_note": "The proposal does not enumerate existing typed-transaction coverage, but it does not define a new type.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — paragraph beginning `Any transaction with a gas limit below`",
"source": "eip.md",
"summary": "Declares transactions invalid when their gas limit is below the updated floor or intrinsic gas, using the maximum of the two."
},
{
"locator": "Test Cases — Invalid transactions",
"source": "eip.md",
"summary": "Requires rejection tests for insufficient gas limits under the updated floor."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Raising the floor changes the validity threshold for existing transactions and therefore changes floor-sensitive validity tests, but the sealed evidence indicates limited expected-value and boundary updates rather than test-infrastructure redesign. This matches score 2.",
"score": 2,
"uncertainty_note": "Concrete before/after validity vectors and transaction-type coverage are not provided, limiting certainty about test volume.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Defines transaction-local gas calculations and no block or header field."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced; score 0 applies.",
"score": 0,
"uncertainty_note": "The stated payload-size reduction changes possible contents, not header structure.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "States that the repricing requires a scheduled network upgrade but specifies no activation-block state or internal-variable modification."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_fork_activation_mechanism",
"rationale": "A scheduled ruleset change is required, but the row scores activation-block state or internal-variable modifications; none is specified, so the score is 0.",
"score": 0,
"uncertainty_note": "The draft does not name an activation point or describe transition handling, but it also defines no new activation mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Rationale",
"source": "eip.md",
"summary": "Targets lower maximum block size and variance, estimates a roughly 33% reduction for data-heavy payloads, and preserves pricing for EVM-heavy transactions."
},
{
"locator": "Backwards Compatibility — gas estimation handling",
"source": "eip.md",
"summary": "Requires wallet and node gas estimators to incorporate the changed floor."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "performance_risks",
"rationale": "The arithmetic can be isolated, but its intended block-size/variance and estimation effects require system-level validation. The impact is confined mainly to floor-bound data-heavy transactions while EVM-heavy behavior is retained, fitting score 2 rather than the substantial or complex-interaction anchor.",
"score": 2,
"uncertainty_note": "The proposal gives approximate maxima but no benchmark methodology, workload set, or performance acceptance criteria.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — gas-used formula and transaction invalidity rule",
"source": "eip.md",
"summary": "Changes consensus-relevant gas accounting and the minimum gas limit accepted for a transaction."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Claims no additional security concern beyond EIP-7623 and identifies transaction bundling as an existing, practically limited consideration."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "security_risks",
"rationale": "The repricing is narrow, but it changes existing gas-used and transaction-validity assumptions and touches execution validation and gas estimation. That supports targeted review and boundary fuzzing across a limited component set, matching score 2; the proposal does not support broad critical-component interactions for score 3.",
"score": 2,
"uncertainty_note": "The security section is qualitative and supplies no explicit threat model or negative test vectors for inconsistent implementation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter `requires: 7623` and Specification",
"source": "eip.md",
"summary": "Explicitly requires and modifies EIP-7623's floor mechanism while incorporating EIP-3860's initcode word cost for creation transactions."
},
{
"locator": "Specification",
"source": "supporting/eip-7623.md",
"summary": "Provides the floor mechanism and validity rule whose parameter EIP-7976 changes."
},
{
"locator": "Specification — Parameters and Rules",
"source": "supporting/eip-3860.md",
"summary": "Defines `INITCODE_WORD_COST = 2` and creation-transaction intrinsic cost used by the combined formula."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cross_eip_interactions",
"rationale": "The proposal directly depends on and modifies EIP-7623 and composes with EIP-3860 for creation transactions. Coordinated boundary and creation testing is required, but the interactions are narrow arithmetic composition rather than complex multi-EIP redesign, matching score 2.",
"score": 2,
"uncertainty_note": "The proposal does not provide combined numeric vectors for the EIP-7623/EIP-3860 creation path.",
"under_specified": false
}
],
"eip": 7976,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7976:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The historical checklist includes Engine API encoding changes but supplies no dedicated definition; that row is conservatively scored from its label with low confidence.",
"The EIP gives test categories but no concrete expected-value vectors or inventory of pre-existing tests, leaving the exact regression breadth uncertain.",
"The Rationale's `45s_000_000/40` literal appears malformed; the surrounding prose indicates an approximate payload-size calculation, but the sealed evidence does not correct it."
],
"provenance": {
"assessed_revision": {
"commit": "c582d21e5075522a6d5852f53156045f1c77f86d",
"committed_at": "2025-09-03T08:10:21Z",
"content_sha256": "0785ed008ee2b3c0af23215a27775d89f0f96662ad0970b3956d9719e5f6fdb2",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7976.md",
"git_blob_sha": "4d5904c24634313051cef7fda1f03c2030be07b6",
"immutable_url": "https://github.com/ethereum/EIPs/blob/c582d21e5075522a6d5852f53156045f1c77f86d/EIPS/eip-7976.md",
"information_cutoff_at": "2025-09-03T20:52:20Z",
"path": "EIPS/eip-7976.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7976.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7976.yaml",
"sha256": "3451bf7d1c3c2774be7349d26e822a2222be8fca04621ccdaa32fb300bab5282"
},
"supporting_documents": [
"supporting/eip-3860.md",
"supporting/eip-7623.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 12,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the sealed historical cutoff, Draft EIP-7976 raises EIP-7623's calldata floor from 10/40 to 15/60 gas per zero/non-zero byte by changing `TOTAL_COST_FLOOR_PER_TOKEN` from 10 to 15. It retains the existing max-based transaction gas-used mechanism, updates the minimum gas-limit validity threshold, and targets lower worst-case execution-payload size while leaving EVM-heavy transactions on standard calldata pricing.",
"tier": "medium",
"title": "Increase Calldata Floor Cost",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"new_or_modified_transaction_validity_mechanisms",
"performance_risks"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 9
},
"present": true,
"summary": "The core constant and formulas are clear, but the draft provides categories rather than concrete numeric vectors, does not quantify the pre-existing test set or enumerate transaction-type/creation-path coverage, and gives approximate performance outcomes without a benchmark method. The Rationale also contains the apparent malformed literal `45s_000_000/40`. These omissions principally limit confidence in test breadth, boundary coverage, and performance validation rather than the basic gas-rule classification.",
"unresolved_questions": [
"What exact before/after vectors cover zero-byte, non-zero-byte, mixed-calldata, refund-adjusted, and branch-equality cases?",
"Which existing transaction types and EIP-7623 tests change validity or expected gas use at the 10-to-15 floor repricing?",
"What workload and measurement method substantiate the projected block-size and variance effects?"
]
}
},
"amsterdam:7976:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-58",
"source": "eip.md",
"summary": "The proposal changes TOTAL_COST_FLOOR_PER_TOKEN to 15 and applies it in the existing EIP-7623 max-based transaction gas-used and gas-limit rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This is an update to an existing transaction gas-accounting mechanism, not a new accounting mechanism, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 35-58",
"source": "eip.md",
"summary": "All specified changes concern transaction calldata accounting and a transaction gas-limit validity threshold; no opcode state access appears."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal does not move state access or gas charging relative to state access within any opcode, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, lines 62-70",
"source": "eip.md",
"summary": "The proposal describes migration toward blobs only as an incentive resulting from higher calldata cost and specifies no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "An economic incentive to use blobs is not a change to blob gas accounting; the anchor therefore scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-58",
"source": "eip.md",
"summary": "The formula adjusts calldata-related execution gas usage and transaction validity without defining any charge for writing state or a state budget."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas cost, charging site, budget, reservoir, or spill rule changes, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 35-55",
"source": "eip.md",
"summary": "The formula consumes execution_gas_used after an existing refund has been subtracted but introduces no refund trigger, amount, or mechanism."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Referring to the already-subtracted refund in an input does not introduce a new gas-refund mechanism, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases, lines 84-92",
"source": "eip.md",
"summary": "Tests must cover data-heavy and EVM-heavy transactions, the floor boundary, gas estimation, and rejection below the raised threshold."
},
{
"locator": "Specification, lines 52-67",
"source": "supporting/eip-7623.md",
"summary": "EIP-7623 already defines the same formula and validity rule with a floor value of 10, whose threshold expectations EIP-7976 changes."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests around the EIP-7623 calldata floor need localized expected value and boundary updates, a minor subset matching score 1.",
"score": 1,
"uncertainty_note": "The sealed package does not enumerate the pre-existing test corpus, so the exact number of affected vectors is not stated.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 84-92",
"source": "eip.md",
"summary": "The requested assertions are confined to tests of the calldata floor, its branch boundary, estimation, and insufficient-gas rejection."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The proposal changes expected results in relevant tests but does not require tests unrelated to this EIP to assert a new output, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 72-82",
"source": "eip.md",
"summary": "The only named interface handling change is to wallet and node gas estimation through eth_estimateGas; no transition-tool field is added."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or mechanism is specified, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 84-92",
"source": "eip.md",
"summary": "The prescribed cases are ordinary transaction gas-use, boundary, estimation, and invalidity checks, with no new expectation abstraction."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The listed cases can be expressed with existing transaction and gas assertions; no framework primitive is required, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The specification consists of byte counting and integer gas arithmetic and introduces no cryptographic operation or construction."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography is added or modified, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Test Cases, lines 43-58 and 84-92",
"source": "eip.md",
"summary": "The max selects between ordinary computation-inclusive cost and the calldata floor, and the EIP explicitly calls for equality-boundary and insufficient-gas-limit cases."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The adjusted max-based floor is one boundary-prone mechanism, including its validity threshold, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The change is a transaction gas formula and validity threshold; it adds no block field, RLP element, or block-RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No RLP validation mechanism requiring sync testing is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 72-82",
"source": "eip.md",
"summary": "The proposal calls for eth_estimateGas updates but specifies no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "JSON-RPC gas estimation is not an Engine API schema change, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The complete specified mechanism is transaction gas arithmetic and does not introduce a contract address, code, state, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "No existing system contract code, state, or behavior is named or changed by the transaction-level calldata floor adjustment."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal has no direct or identified indirect effect on a pre-existing system contract, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The proposal defines no opcode and changes only transaction-level gas accounting and validity."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 35-58",
"source": "eip.md",
"summary": "The formula treats EVM execution gas as an input but specifies no change to any existing opcode's non-gas behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No opcode result or behavior is modified; transaction gas repricing alone does not trigger this anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The specified transaction formula introduces no precompile address or callable function."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "No existing precompile or precompile gas schedule appears in the proposed calldata floor change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile behavior or gas schedule is modified, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "Existing calldata bytes are counted for gas purposes without changing transaction, block, or interface serialization."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Repricing encoded data is not an encoding-format change, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 35-58",
"source": "eip.md",
"summary": "The rules apply a revised calculation to transactions generally and do not define a new typed transaction or envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-58",
"source": "eip.md",
"summary": "A transaction is invalid when its gas limit is below the greater of the raised calldata-floor requirement and its intrinsic gas cost."
},
{
"locator": "Test Cases, lines 84-92",
"source": "eip.md",
"summary": "The requested coverage includes the new equality boundary and rejection of transactions whose gas limit is insufficient under the raised floor."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The existing validity threshold is materially raised and existing boundary vectors must change, but updates are localized and need no test-framework redesign, matching score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The specification changes transaction gas calculations and adds no block body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 72-80",
"source": "eip.md",
"summary": "The repricing requires a scheduled network upgrade, but the text defines no activation-block state mutation or internal-variable modification."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Fork scheduling alone is not the activation mechanism scored by this anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Rationale, lines 18-26 and 62-70",
"source": "eip.md",
"summary": "The repricing is intended to reduce the maximum data-heavy payload by about one third and reduce block-size variance while permitting gas-limit headroom."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Validating the claimed block-level payload and variance effect cannot be fully reduced to a transaction microbenchmark, but it has limited scope in existing performance behavior because it targets data-heavy transactions; this matches score 2.",
"score": 2,
"uncertainty_note": "The package quantifies the payload-size bound but supplies no benchmark plan for propagation, processing, or mixed block workloads.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 94-104",
"source": "eip.md",
"summary": "The EIP states that the lower maximum block size adds no concern beyond EIP-7623, bundling does not defeat the objective, and no new attack vector is introduced."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The constant increase does not add a security-sensitive mechanism or alter an identified security invariant, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 43-58",
"source": "eip.md",
"summary": "The equation floors tx.gasUsed through max, while the following validity paragraph says there are valid cases where gasUsed is below that floor."
},
{
"locator": "Test Cases, lines 84-92",
"source": "eip.md",
"summary": "The test guidance says data-heavy transactions pay the floor and asks for boundary and insufficient-limit coverage, supporting the equation's apparent intended reading."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The inconsistent use of gasUsed leaves a localized wording ambiguity, but the equation and test guidance make the intended floor-charging behavior obvious enough to match score 1 rather than requiring broad coordination.",
"score": 1,
"uncertainty_note": "The text does not explicitly distinguish raw execution consumption from final transaction gasUsed when describing cases below the reserved floor.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Specification, lines 1-12 and 41-58",
"source": "eip.md",
"summary": "EIP-7976 formally requires EIP-7623, changes its floor formula, and uses EIP-3860's INITCODE_WORD_COST in the contract-creation branch."
},
{
"locator": "Specification, lines 42-60",
"source": "supporting/eip-3860.md",
"summary": "EIP-3860 defines the value and intrinsic-cost treatment of the initcode term incorporated by the EIP-7976 creation-transaction calculation."
},
{
"locator": "Specification, lines 26-67",
"source": "supporting/eip-7623.md",
"summary": "EIP-7623 defines the pre-existing floor mechanism and its validity rule, including the EIP-3860 creation-cost term, with the earlier value of 10."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
3860,
7623
],
"rationale": "The proposal directly modifies EIP-7623 and must preserve EIP-3860 creation accounting in coordinated boundary tests, but these interactions are explicit and limited in scope, matching score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7976,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7976:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"Specification line 58 uses gasUsed in a way that conflicts with the preceding max-based tx.gasUsed equation; the primary score follows the equation and test guidance while recording the ambiguity as under-specification."
],
"provenance": {
"assessed_revision": {
"commit": "c582d21e5075522a6d5852f53156045f1c77f86d",
"committed_at": "2025-09-03T08:10:21Z",
"content_sha256": "0785ed008ee2b3c0af23215a27775d89f0f96662ad0970b3956d9719e5f6fdb2",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7976.md",
"git_blob_sha": "4d5904c24634313051cef7fda1f03c2030be07b6",
"immutable_url": "https://github.com/ethereum/EIPs/blob/c582d21e5075522a6d5852f53156045f1c77f86d/EIPS/eip-7976.md",
"information_cutoff_at": "2025-09-03T20:52:20Z",
"path": "EIPS/eip-7976.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7976.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7976.yaml",
"sha256": "0b6bcc06f544b7d9f1c974c06776b91f5d2910ea18c0e909517c1a4214084115"
},
"supporting_documents": [
"supporting/eip-3860.md",
"supporting/eip-7623.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 10,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7976 was a draft execution-layer proposal to raise EIP-7623's existing calldata floor from 10/40 to 15/60 gas per zero/non-zero byte for data-heavy transactions. It retained the existing max-based transaction gas-used formula, including EIP-3860's initcode term, and raised the corresponding minimum gas-limit validity threshold while leaving EVM-heavy transactions on standard calldata pricing.",
"tier": "low",
"title": "Increase Calldata Floor Cost",
"under_specification": {
"affected_criteria": [
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 10,
"minimum": 9
},
"present": true,
"summary": "The specification's equation and test guidance require final transaction gasUsed to meet the calldata floor, but the adjacent prose says valid cases can have gasUsed below the floor. The likely intended distinction is between pre-floor execution consumption and final charged gas, but that distinction is not stated explicitly.",
"unresolved_questions": [
"Does final tx.gasUsed always include the floor as the equation and test case state, with only pre-floor execution consumption allowed below it, or is the floor intended solely as a gas-limit reservation in some valid cases?"
]
}
},
"amsterdam:7981:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [
"Blank cells are interpreted as zero only because the published total exactly equals the sum of every nonblank parsed contribution."
],
"published_tier": "low",
"published_total": 6,
"recomputed_tier": "low",
"recomputed_total": 6,
"timing_exposure": "high_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "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.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "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.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Checks for the type of byte require boundary condition checks but minimal complexity.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Modifies the intrinsic gas cost calculation.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7981,
"fork": "amsterdam",
"id": "amsterdam:7981:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "5aea12c20ee27b3d85f7c2ec9e6a09e451fd81f0",
"committed_at": "2025-09-04T12:47:19Z",
"content_sha256": "558a702401bf964c94c8b84c8bef17d408aed434803a2e1b9a00d423c48825b9",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7981.md",
"git_blob_sha": "f6215747399f93b1d5e47c1925841d82a50fc21f",
"immutable_url": "https://github.com/ethereum/EIPs/blob/5aea12c20ee27b3d85f7c2ec9e6a09e451fd81f0/EIPS/eip-7981.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7981.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7981.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7981.yaml",
"sha256": "d6bacd2127c0c3a01fca32aef03605cdc7be3ca4b12c2d97900a1abbd5d9f3c2"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "eb0d24aec552ce5ec5eca689a37f0eb47fe75203",
"committed_at": "2025-12-04T14:04:31Z",
"content_sha256": "7bbd980c0a0423ade93ee051919982ec873b52febccaf301db09308172d19442",
"git_blob_sha": "69f777a90c07f0797f6c625f7642820e76b78811",
"immutable_url": "https://github.com/ethspecs/pm/blob/eb0d24aec552ce5ec5eca689a37f0eb47fe75203/complexity_assessments/EIPs/EIP-7981.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7981.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 6,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "low",
"title": "Increase Access List Cost",
"under_specification": null
},
"amsterdam:7981:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "evm_gas_rule_changes",
"rationale": "The proposal updates the existing intrinsic access-list gas-accounting mechanism, matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "BlobTransaction is included only when calculating ordinary intrinsic access-list cost; no blob-gas variable or formula is changed."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "blob_gas_accounting_changes",
"rationale": "The proposal changes access-list data pricing, not blob gas accounting.",
"score": 0,
"uncertainty_note": "The presence of BlobTransaction in the implementation scope does not itself modify blob gas accounting.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The new charges are always-added intrinsic access-list costs with no refund condition or refund calculation."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP identifies a backwards-incompatible gas repricing and required updates to gas estimation while saying normal usage is largely unaffected."
},
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "The changed intrinsic-cost calculation covers four access-list-bearing transaction classes."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests involving non-empty access lists and their intrinsic gas expectations need updates, but the affected pattern is localized.",
"score": 1,
"uncertainty_note": "The sealed sources do not inventory pre-existing tests, so the distinction between a minor and considerable subset cannot be established precisely.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "The change is represented by two internal constants, byte counting, and an added intrinsic-cost term; no transition-tool field is specified."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "transition_tool_interface_changes",
"rationale": "No modification to the transition-tool interface is required by the described mechanism.",
"score": 0,
"uncertainty_note": "The proposal does not discuss tooling explicitly, but all required inputs already exist in the transaction access list.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The mechanism only classifies bytes as zero or non-zero and applies fixed gas multipliers."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cryptography",
"rationale": "No cryptographic mechanism or cryptographic functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Gas depends on the exact partition of fixed-length address and storage-key bytes into zero and non-zero counts."
},
{
"locator": "Specification",
"source": "supporting/eip-2930.md",
"summary": "Access lists may be empty and may contain duplicate addresses or storage keys, with duplicates charged repeatedly."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "edge_boundary_conditions",
"rationale": "One byte-classification and counting mechanism creates discernible boundary cases such as empty, all-zero, all-non-zero, mixed, and duplicate-bearing lists.",
"score": 1,
"uncertainty_note": "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.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "supporting/eip-2930.md",
"summary": "The existing access-list RLP structure fixes addresses at 20 bytes and storage keys at 32 bytes."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "EIP-7981 prices the bytes already present in that structure without changing its validation or encoding."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requiring client syncing is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "The proposal changes execution-layer intrinsic-cost calculation using transaction-local access-list bytes and specifies no Engine API field or endpoint."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "engine_api_changes",
"rationale": "No Engine API field or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "The absence of an Engine API section is consistent with the transaction-local data needed by the specified calculation.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The change adds byte-sensitive pricing to existing access-list contents and specifies no Engine API representation change."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "engine_api_encoding_changes",
"rationale": "Conservatively applying the row label, no Engine API encoding change is described.",
"score": 0,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "The implementation consists of constants and intrinsic-cost helper logic, with no contract deployment or system address."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes transaction access-list gas calculation only and specifies no system-contract code, state, or behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is modified directly or indirectly by the described mechanism.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The change is applied during transaction intrinsic-cost calculation and defines no opcode."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "The added charge is computed before execution as intrinsic gas and does not change opcode behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified; the rubric also excludes gas-only changes from the score-3 condition.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "The mechanism is ordinary intrinsic-cost calculation and introduces no precompile address or call behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Only access-list intrinsic gas is repriced; no precompile logic or gas schedule is mentioned."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "supporting/eip-2930.md",
"summary": "EIP-2930 defines the existing RLP transaction payload and access-list shape."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "EIP-7981 counts and prices the existing 20-byte addresses and 32-byte keys without altering their representation."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding change is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "The new cost is applied to already existing AccessListTransaction, FeeMarketTransaction, BlobTransaction, and SetCodeTransaction classes."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_transaction_types",
"rationale": "The proposal modifies handling of existing transaction classes and introduces no transaction type.",
"score": 0,
"uncertainty_note": "The normative prose says transactions generally, while the reference implementation enumerates the affected existing classes; neither introduces a new class.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Every access-list transaction must pay the existing per-item costs plus new byte-sensitive charges as part of its intrinsic cost."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The repricing is backwards incompatible and requires updated wallet and node gas estimation."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "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.",
"score": 2,
"uncertainty_note": "The proposal does not quantify the existing validity-test corpus, but the calculation and localized update path are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal adds two gas constants and a transaction-local access-list cost component, not block or header data."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The gas repricing requires a scheduled network upgrade, but no activation-block state or internal-variable mutation is specified."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary scheduling of the rule change does not create the state or internal-variable modification required by the score-3 anchor.",
"score": 0,
"uncertainty_note": "The sealed proposal does not specify an activation block, but it also specifies no special activation transition.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale > Maximum Block Size Impact",
"source": "eip.md",
"summary": "The proposal estimates that an all-non-zero access-list-heavy 36M-gas block falls from roughly 607 KB to 362 KB."
},
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "Intrinsic-cost processing gains a traversal over every address and storage-key byte in each access list."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "performance_risks",
"rationale": "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.",
"score": 2,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal is intended to close an access-list loophole in EIP-7623 floor pricing."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Correct proportional charging is presented as reducing maximum block size and improving network stability."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "security_risks",
"rationale": "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.",
"score": 2,
"uncertainty_note": "The security section asserts improvement but does not analyze inconsistent transaction-family implementations, counting errors, or consensus effects of divergent intrinsic gas.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Abstract",
"source": "eip.md",
"summary": "EIP-7981 requires EIP-2930 and is expressly designed to close a way of circumventing EIP-7623 floor pricing."
},
{
"locator": "Specification",
"source": "supporting/eip-2930.md",
"summary": "EIP-2930 supplies the existing per-item access-list charges and permits duplicates, which EIP-7981 retains while adding per-byte charges."
},
{
"locator": "Specification",
"source": "supporting/eip-7623.md",
"summary": "EIP-7623 defines the calldata floor whose block-size objective motivates the access-list repricing."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cross_eip_interactions",
"rationale": "The proposal modifies EIP-2930 pricing to preserve EIP-7623's resource-pricing objective, requiring coordinated but limited-scope testing across both mechanisms.",
"score": 2,
"uncertainty_note": "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.",
"under_specified": false
}
],
"eip": 7981,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7981:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"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."
],
"provenance": {
"assessed_revision": {
"commit": "acc2533ec925d0659d2001d64edc3e6466e62400",
"committed_at": "2025-08-24T10:46:57Z",
"content_sha256": "061e4fa54001523af4772d9bb979b330fbf42698c83075b1462818d451f1e9e6",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7981.md",
"git_blob_sha": "7947d1cc630194a6fbcae98344cc8650c4110255",
"immutable_url": "https://github.com/ethereum/EIPs/blob/acc2533ec925d0659d2001d64edc3e6466e62400/EIPS/eip-7981.md",
"information_cutoff_at": "2025-08-26T21:52:26Z",
"path": "EIPS/eip-7981.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7981.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7981.yaml",
"sha256": "da14a23b399011cca800703c0ac400f8d73c18cbe45d8f356520e866a888e681"
},
"supporting_documents": [
"supporting/eip-2930.md",
"supporting/eip-7623.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 11,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "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.",
"tier": "medium",
"title": "Increase Access List Cost",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 11
},
"present": true,
"summary": "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.",
"unresolved_questions": [
"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?"
]
}
},
"amsterdam:7981:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-62",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This updates the existing intrinsic-gas accounting mechanism for access lists; it does not introduce a separate gas-accounting mechanism, matching anchor 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 155-190",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "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.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 155-190",
"source": "eip.md",
"summary": "BlobTransaction is one existing transaction class receiving the same new access-list intrinsic cost, while no blob-gas variable or formula is changed."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Applying an execution-gas access-list charge to a blob transaction does not modify blob gas accounting, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-62",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal prices transaction input metadata rather than writing state, so it triggers none of the state-gas anchors and scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-62",
"source": "eip.md",
"summary": "The complete new calculation is an unconditional positive addition to the existing access-list cost and defines no refund condition or refund amount."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced or modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Reference Implementation, lines 155-190",
"source": "eip.md",
"summary": "The reference implementation changes intrinsic cost for AccessListTransaction, FeeMarketTransaction, BlobTransaction, and SetCodeTransaction whenever their access list is charged."
},
{
"locator": "Specification, lines 75-107",
"source": "supporting/eip-2930.md",
"summary": "The prior rule charged each address and key a fixed amount, including repeated entries, without per-byte fees; existing expectations encode that behavior."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "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.",
"score": 2,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-62",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Affected tests must update existing gas expectations, which is test reworking, but pre-existing tests gain no separate new invariant, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-62",
"source": "eip.md",
"summary": "The normative change consists of two constants and an intrinsic-cost formula derived entirely from access-list data already present in the transaction."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No new transition-tool input or output field is required because the needed bytes are already in the transaction, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 91-117",
"source": "eip.md",
"summary": "The proposal's cases use ordinary transactions, access-list contents, and gas arithmetic, without defining a novel expectation type, modifier, or helper."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing transaction and gas-result primitives suffice to express the feature's tests, so no test-framework extension is indicated and anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 124-190",
"source": "eip.md",
"summary": "The implementation only classifies raw bytes as zero or non-zero and adds their gas costs; it introduces no cryptographic operation or primitive."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Transaction signature mechanisms are untouched, and the new accounting is non-cryptographic, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-62",
"source": "eip.md",
"summary": "The new mechanism separates zero from non-zero bytes across fixed-size addresses and storage keys and adds the resulting amount to intrinsic gas."
},
{
"locator": "Specification, lines 75-107",
"source": "supporting/eip-2930.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "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.",
"score": 1,
"uncertainty_note": "The line between one mechanism with several input partitions and multiple edge-prone mechanisms is judgmental; the proposal specifies only one new cost calculation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-62",
"source": "eip.md",
"summary": "The proposal changes only access-list gas constants and calculation and adds no block field, block RLP rule, or block decoding condition."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requires sync testing, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-62",
"source": "eip.md",
"summary": "The complete normative change concerns transaction access-list cost and does not introduce an Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The Engine API surface is unchanged, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-62",
"source": "eip.md",
"summary": "The specified feature is an intrinsic-gas formula implemented in transaction processing and defines no contract address, code, state, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 155-190",
"source": "eip.md",
"summary": "The implementation modifies transaction intrinsic-cost calculation only and neither calls nor changes any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or indirect system-contract behavior is specified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-62",
"source": "eip.md",
"summary": "The specification adds access-list cost constants and formula terms, with no opcode number, stack behavior, or EVM instruction definition."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 155-190",
"source": "eip.md",
"summary": "The additional charge is calculated before EVM execution as intrinsic cost, and the proposal specifies no change to any opcode's result or behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Gas repricing outside opcode execution does not modify an opcode's behavior; therefore the binary modified-opcode anchor scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-62",
"source": "eip.md",
"summary": "The specification contains only access-list gas parameters and arithmetic and defines no precompile address or callable precompile behavior."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-62",
"source": "eip.md",
"summary": "The proposal changes access-list intrinsic gas and names no precompile or precompile gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas accounting is modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-62",
"source": "eip.md",
"summary": "The new charge counts bytes in the already-defined 20-byte addresses and 32-byte storage keys; it does not change their transaction representation."
},
{
"locator": "Specification, lines 49-57",
"source": "supporting/eip-2930.md",
"summary": "EIP-2930 defines the existing typed-transaction RLP payload and access-list shape that EIP-7981 reuses."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Reading existing encoded values for pricing leaves transaction, block, and interface encodings unchanged, so the binary encoding anchor scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 155-178",
"source": "eip.md",
"summary": "The change is applied through isinstance checks to four existing transaction classes and does not define another class or type identifier."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "Repricing fields of existing transaction classes introduces no new transaction type, so the binary anchor scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 155-190",
"source": "eip.md",
"summary": "The reference implementation adds access-list byte cost to the intrinsic cost returned for four existing access-list-bearing transaction classes."
},
{
"locator": "Backwards Compatibility, lines 85-89",
"source": "eip.md",
"summary": "The proposal calls the repricing backwards incompatible, requires a scheduled upgrade, and requires wallet and node gas-estimation updates."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "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.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-62",
"source": "eip.md",
"summary": "The normative parameters and calculation are transaction-level access-list gas rules and define no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced, so the binary anchor scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 85-89",
"source": "eip.md",
"summary": "A scheduled network upgrade is required for the backwards-incompatible repricing, but no activation-block state or internal-variable mutation is specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "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.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Reference Implementation, lines 124-153",
"source": "eip.md",
"summary": "The new count_access_list_bytes routine scans every address and storage-key byte and performs a simple zero/non-zero classification."
},
{
"locator": "Maximum Block Size Impact, lines 75-83",
"source": "eip.md",
"summary": "The proposal quantifies its intended reduction in the maximum access-list block payload under the revised prices."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "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.",
"score": 1,
"uncertainty_note": "The package supplies analytical size examples but no benchmark data; the scan's performance cost is nevertheless directly isolatable from the specified loop.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 14-20",
"source": "eip.md",
"summary": "The proposal closes an underpriced-data path that combines access lists with calldata to create blocks larger than the existing floor-pricing intent."
},
{
"locator": "Security Considerations, lines 193-195",
"source": "eip.md",
"summary": "The claimed security effect is improved network stability from reducing the maximum block size while retaining access-list compatibility."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "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.",
"score": 2,
"uncertainty_note": "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.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-62",
"source": "eip.md",
"summary": "The constants, counted byte domains, fixed address and key lengths, and exact additive access-list formula are all specified."
},
{
"locator": "Reference Implementation, lines 124-190",
"source": "eip.md",
"summary": "The code specifies zero/non-zero classification, iteration over every list occurrence, affected transaction classes, and placement in intrinsic cost."
},
{
"locator": "Specification, lines 75-107",
"source": "supporting/eip-2930.md",
"summary": "The inherited access-list rules clarify validation, fixed lengths, and that duplicate entries remain allowed and are charged repeatedly."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "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.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Abstract, lines 1-16",
"source": "eip.md",
"summary": "EIP-7981 formally requires EIP-2930 and states that its new access-list charge closes a floor-pricing loophole in EIP-7623."
},
{
"locator": "Specification and Test Cases, lines 24-62 and 109-117",
"source": "eip.md",
"summary": "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."
},
{
"locator": "Reference Implementation, lines 155-190",
"source": "eip.md",
"summary": "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."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2930,
7623
],
"rationale": "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.",
"score": 2,
"uncertainty_note": "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.",
"under_specified": false,
"unidentified_interactions": [
"Existing FeeMarketTransaction, BlobTransaction, and SetCodeTransaction classes receive the new access-list intrinsic charge, but their EIP numbers are not identified in the sealed package."
]
}
],
"eip": 7981,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7981:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"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."
],
"provenance": {
"assessed_revision": {
"commit": "acc2533ec925d0659d2001d64edc3e6466e62400",
"committed_at": "2025-08-24T10:46:57Z",
"content_sha256": "061e4fa54001523af4772d9bb979b330fbf42698c83075b1462818d451f1e9e6",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7981.md",
"git_blob_sha": "7947d1cc630194a6fbcae98344cc8650c4110255",
"immutable_url": "https://github.com/ethereum/EIPs/blob/acc2533ec925d0659d2001d64edc3e6466e62400/EIPS/eip-7981.md",
"information_cutoff_at": "2025-08-26T21:52:26Z",
"path": "EIPS/eip-7981.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7981.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7981.yaml",
"sha256": "76937733b242460b4a891574c82fbd31cdd9027eb5add0c845e13a6a8c63a67b"
},
"supporting_documents": [
"supporting/eip-2930.md",
"supporting/eip-7623.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 11,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "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.",
"tier": "low",
"title": "Increase Access List Cost",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 11,
"minimum": 11
},
"present": false,
"summary": "No material under-specification was identified. The proposal fixes both byte prices, defines which bytes are counted, gives the additive formula, names the affected transaction classes, and inherits duplicate and shape semantics from EIP-2930.",
"unresolved_questions": []
}
},
"amsterdam:7997:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [],
"published_tier": "low",
"published_total": 5,
"recomputed_tier": "low",
"recomputed_total": 5,
"timing_exposure": "low_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "A new system contract is added in the precompile range.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The EIP adds a new system contract at the next fork. It does not affect state but it might be called an 'internal variable' depending on how this is defined exactly.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "There is an open frontrunning risk that has not been solved. Whether this qualifies as security risk or inconvenience is subjective.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7997,
"fork": "amsterdam",
"id": "amsterdam:7997:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "ec05b85e530a7ea97ea52a1f0312d88eb0eb1be2",
"committed_at": "2025-11-05T22:05:32Z",
"content_sha256": "41984b52620bb6cf807abfd3bc08909a61cdf42a75ff244b3e483f11e3767db6",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7997.md",
"git_blob_sha": "3ac0f2270c8efcc662053137642a298e2026a7bc",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ec05b85e530a7ea97ea52a1f0312d88eb0eb1be2/EIPS/eip-7997.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-7997.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7997.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7997.yaml",
"sha256": "848d3ee0d3a577742ed8093aba2907168ad7567adb47602dd053d55e3d7ef857"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "676285451c6aac875ab7d0422bd17060b33552e2",
"committed_at": "2026-01-07T14:34:21Z",
"content_sha256": "bf037d2949856757d224cb32ac8ff67b261210cb70958bfbaf7c902c59857bd2",
"git_blob_sha": "0b3e3f469875edf56c7c6afac5d9acf8c1ab0c22",
"immutable_url": "https://github.com/ethspecs/pm/blob/676285451c6aac875ab7d0422bd17060b33552e2/complexity_assessments/EIPs/EIP-7997.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7997.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 5,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "low",
"title": "Deterministic Factory Contract",
"under_specification": null
},
"amsterdam:7997:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "The proposal installs fixed bytecode composed of existing EVM instructions and specifies no gas schedule or gas-accounting rule."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas accounting mechanism is added or updated; the factory executes under the already-defined gas behavior of its existing opcodes.",
"score": 0,
"uncertainty_note": "The proposal provides no gas analysis, so the score is limited to the absence of a specified gas-rule change in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The change is a CREATE2 factory system contract; no blob fields, blob gas, or blob-processing behavior is specified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "Blob behavior is not discussed; the zero reflects the sealed proposal's stated scope rather than external implementation evidence.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "The factory forwards value to CREATE2 and either returns the created address or reverts; it defines no refund counter or refund rule."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "The proposal does not analyze refunds, but none is present in its normative factory behavior.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Parameters; Specification > Factory Contract",
"source": "eip.md",
"summary": "At activation, address 0x0B changes from its prior state to a callable code-backed factory with input validation and CREATE2 behavior."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The test section is marked TODO and TBD."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The changed behavior of a single reserved address and its activation transition plausibly affects a minor, localized subset of existing state and call tests, rather than diverse test categories.",
"score": 1,
"uncertainty_note": "The proposal supplies no test inventory, so the existence and size of the pre-existing test subset are inferred from the normative address change.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "The transition at EIP activation must set fixed code at FACTORY_ADDRESS."
},
{
"locator": "Rationale > Precompile-range system contract",
"source": "eip.md",
"summary": "The proposal describes the deployment as an irregular insertion of code at a special address."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The activation-dependent irregular state insertion is a new transition mechanism and requires the transition process to distinguish activation, matching the rubric's new-mechanism score even though no fields are stated.",
"score": 2,
"uncertainty_note": "No transition-tool interface or activation input is specified, so whether an actual interface change is needed cannot be established from the package.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "The factory invokes the already-existing CREATE2 opcode."
},
{
"locator": "Specification",
"source": "supporting/eip-1014.md",
"summary": "EIP-1014 defines CREATE2's existing keccak256-based deterministic address formula and hashing gas cost."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "EIP-7997 reuses existing CREATE2 cryptography and introduces no new cryptographic primitive or modified cryptographic functionality.",
"score": 0,
"uncertainty_note": "Deterministic addressing relies on existing keccak256 behavior, which is treated as a dependency rather than newly introduced cryptography.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract; Rationale > Input validation",
"source": "eip.md",
"summary": "The bytecode distinguishes calldata shorter than 32 bytes, copies variable-size initcode, forwards call value, and branches on CREATE2 success or failure while propagating failure data."
},
{
"locator": "Clarifications; Examples",
"source": "supporting/eip-1014.md",
"summary": "CREATE2 includes collision behavior and examples spanning empty and differently sized initcode and salts."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The feature exposes multiple boundary-prone mechanisms: the 32-byte input boundary, variable initcode, CREATE2 success/collision/failure, return data, and value forwarding. None is shown to demand an elevated test count.",
"score": 2,
"uncertainty_note": "Test cases are TBD, so the exact case matrix and activation-address edge behavior are not enumerated.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification changes account code at activation and defines contract execution, without adding block RLP fields or block-validation rules."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requiring sync testing is introduced.",
"score": 0,
"uncertainty_note": "Sync behavior is not discussed; the score follows the absence of a block encoding or validation change in the sealed specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal specifies only an activation-time account-code insertion and the factory's EVM behavior; it introduces no Engine API endpoint or field."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "The Engine API is not discussed, so the zero is based on the complete sealed specification containing no such change.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No Engine API payload, field, endpoint, or serialization is defined by the proposal."
}
],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Conservatively, the row label does not apply because the proposal specifies no Engine API encoding change.",
"score": 0,
"uncertainty_note": "The historical checklist has no dedicated definition for this row; no replacement definition was imported, and the score is conservative.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Factory Contract",
"source": "eip.md",
"summary": "One minimal system contract is inserted at 0x0B with fixed bytecode; the code contains no storage operations and exposes ordinary CREATE2 deployment."
},
{
"locator": "Rationale > Precompile-range system contract",
"source": "eip.md",
"summary": "The proposal expressly classifies the new account as a precompile-range system contract inserted irregularly."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Exactly one non-stateful system contract is added, and its user-invoked CREATE2 behavior is not a new protocol system action such as a request to the consensus layer.",
"score": 1,
"uncertainty_note": "The rubric does not state whether ordinary contract creation initiated by a system contract counts as a system action; it is treated here as normal EVM execution rather than a new system action.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Precompile-range system contract",
"source": "eip.md",
"summary": "Address 0x0B is selected as the next lowest address after existing precompiles, and the factory is described as a newly inserted contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "The proposal assumes the address is reserved but does not inventory every possible chain's prior state; the assessment is limited to the assigned proposal's protocol scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "The factory bytecode uses existing instructions including CREATE2, RETURNDATASIZE, and RETURNDATACOPY; no opcode number is allocated."
},
{
"locator": "Specification",
"source": "supporting/eip-211.md",
"summary": "EIP-211 already defines RETURNDATASIZE and RETURNDATACOPY."
},
{
"locator": "Specification",
"source": "supporting/eip-1014.md",
"summary": "EIP-1014 already defines CREATE2 at opcode 0xf5."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "The proposal adds contract bytecode but no EVM opcode.",
"score": 0,
"uncertainty_note": "Opcode availability is an explicit dependency; reusing those opcodes is not scored as adding them again.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "The proposal invokes existing opcodes from fixed bytecode and states no change to their behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "The contract depends on existing CREATE2 and return-data semantics, but no semantic amendment to those instructions is specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Rationale > Precompile-range system contract",
"source": "eip.md",
"summary": "The feature is a system contract with fixed EVM bytecode placed in the precompile address range, not a native precompile implementation."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added; the separately scored addition is one code-backed system contract.",
"score": 0,
"uncertainty_note": "The phrase \"precompile range\" creates terminology ambiguity, but the proposal consistently specifies account code and calls the feature a system contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Precompile-range system contract",
"source": "eip.md",
"summary": "Address 0x0B is chosen after existing precompiles; no existing precompile's logic or gas schedule is changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "The new account is adjacent to precompiles, but adjacency alone does not alter any precompile behavior in the sealed specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "The factory accepts a contract-local calldata convention of a 32-byte salt followed by initcode, without changing transaction, block, RLP, SSZ, or protocol-interface serialization."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction-, block-, or protocol-interface encoding change is introduced.",
"score": 0,
"uncertainty_note": "The new contract has an input format, but it is treated as ordinary calldata to a new contract rather than the RLP/SSZ-level encoding change named by the rubric.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Not a new transaction type",
"source": "eip.md",
"summary": "The proposal explicitly chooses a system contract instead of a new creation transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "The alternative transaction design is discussed only as a rejected option.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract; Rationale > Not a new transaction type",
"source": "eip.md",
"summary": "Input shorter than 32 bytes causes a contract revert, while transactions continue to use existing types and no intrinsic-gas or validity rule is specified."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The factory's runtime calldata check is contract execution behavior, not a new or modified transaction validity mechanism.",
"score": 0,
"uncertainty_note": "The proposal does not discuss transaction validation because the mechanism is accessed through ordinary calls.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The only parameter is FACTORY_ADDRESS and no block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "Block headers are outside the stated mechanism and are not discussed in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "Upon EIP activation, the protocol sets the code of address 0x0B to the specified byte sequence."
},
{
"locator": "Rationale > Precompile-range system contract",
"source": "eip.md",
"summary": "The code placement is described as an irregular insertion at a special address because a normal deployment transaction is unsuitable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Setting account code at the activation point is a state modification at the fork activation block, directly matching the rubric's score-3 condition.",
"score": 3,
"uncertainty_note": "The state modification is explicit, but the proposal does not specify its ordering within the activation block or the treatment of any pre-existing account fields at 0x0B.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract",
"source": "eip.md",
"summary": "A small fixed contract copies variable-length initcode into memory and invokes CREATE2 using existing gas-metered operations."
},
{
"locator": "Specification; Rationale > Gas cost",
"source": "supporting/eip-1014.md",
"summary": "CREATE2 already charges for initcode hashing to address repeated hashing and denial-of-service cost."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The factory's variable-input execution and deployment path merit isolated benchmarking, but the mechanism is small, independently exercisable, and does not modify existing performance behavior.",
"score": 1,
"uncertainty_note": "The proposal contains no performance analysis or tests, so the need for validation is inferred from variable-size input rather than measured impact.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations > Frontrunnable deployments",
"source": "eip.md",
"summary": "Deployments of contracts that read environmental values can be frontrun and created with attacker-chosen parameters; fully deterministic contracts are recommended."
},
{
"locator": "Rationale > No frontrunning protection",
"source": "eip.md",
"summary": "Caller-bound salt protection was considered but omitted to retain permissionless multi-chain deployment."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The explicit frontrunning risk is localized to use of the self-contained factory and can be reviewed and tested in isolation without a stated change to broader protocol security invariants.",
"score": 1,
"uncertainty_note": "The security discussion is narrow and the Test Cases section is TBD, so the sealed package does not demonstrate the full adversarial test surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Specification > Factory Contract",
"source": "eip.md",
"summary": "EIP-7997 normatively requires EIP-211 and EIP-1014 and its bytecode uses their return-data instructions and CREATE2 behavior."
},
{
"locator": "Specification",
"source": "supporting/eip-211.md",
"summary": "EIP-211 specifies that CREATE2 has empty return data on success and failure data on failure, which the factory copies and reverts with."
},
{
"locator": "Specification; Clarifications",
"source": "supporting/eip-1014.md",
"summary": "EIP-1014 defines the address formula, gas behavior, and collision semantics of the factory's core CREATE2 operation."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "The proposal depends on two prior EIPs, so coordinated testing of address creation and failure-data propagation is required, but the interactions are limited to the factory's compact execution path.",
"score": 2,
"uncertainty_note": "EIP-155, EIP-5792, and EIP-7702 appear as motivation or alternatives rather than normative dependencies and are not used to raise this score.",
"under_specified": false
}
],
"eip": 7997,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7997:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The historical checklist includes Engine API encoding changes without a dedicated definition; it is scored conservatively at zero with low confidence.",
"The proposal calls the feature a precompile-range system contract. Because it installs EVM bytecode in account state, it is scored as an added system contract and not as an added or modified precompile.",
"\"Upon activation, set the code\" establishes a state modification but does not fully specify activation ordering or pre-existing account-field handling.",
"The factory's salt-plus-initcode calldata convention is treated as a contract-local interface, not an RLP/SSZ transaction, block, or protocol- interface encoding change."
],
"provenance": {
"assessed_revision": {
"commit": "f8be9ce27bdb513ba72abddde06cb5e806447230",
"committed_at": "2025-08-19T16:32:51Z",
"content_sha256": "8fec7a727f75a9762f34427ed5046b49d59b63a9c16d38f319c8e1060ebd93bd",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7997.md",
"git_blob_sha": "9bd8766f329acc3b21d2fa6dc53d5655488891ab",
"immutable_url": "https://github.com/ethereum/EIPs/blob/f8be9ce27bdb513ba72abddde06cb5e806447230/EIPS/eip-7997.md",
"information_cutoff_at": "2025-08-21T13:34:18Z",
"path": "EIPS/eip-7997.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7997.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7997.yaml",
"sha256": "0924c92fbea8e7df0c2b20a4a4927940afb0ba09f06505a2283413b707612cb8"
},
"supporting_documents": [
"supporting/eip-155.md",
"supporting/eip-211.md",
"supporting/eip-1014.md",
"supporting/eip-5792.md",
"supporting/eip-7702.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 13,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "Blinded assessment of the sealed Draft EIP-7997, which inserts fixed bytecode for a minimal CREATE2 factory at address 0x0B upon fork activation. The scope includes only the proposal, the historical checklist, and the five allowlisted linked EIPs; the proposal's Test Cases section is still TBD.",
"tier": "medium",
"title": "Deterministic Factory Contract",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes",
"edge_boundary_conditions",
"new_fork_activation_mechanism",
"performance_risks"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 16,
"minimum": 8
},
"present": true,
"summary": "The proposal normatively identifies the bytecode and activation-time code insertion but leaves its Test Cases section TBD. It also does not define the transition-tool interface, activation ordering, or the disposition of any pre-existing nonce, balance, storage, or code at address 0x0B. These gaps chiefly affect estimates of regression-test breadth, transition integration, edge cases, and performance validation.",
"unresolved_questions": [
"What exact account-state transition applies if 0x0B already has code, a nonce, balance, or storage at activation?",
"At what point in the activation block is the code inserted, and how must the transition tool be told that it is processing that block?",
"Which pre-existing tests require updates, and what boundary, adversarial, and performance cases are required beyond the currently TBD test section?"
]
}
},
"amsterdam:7997:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "The proposal installs fixed EVM bytecode composed of existing instructions, including CALLDATACOPY and CREATE2, without specifying any new gas prices or charging rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The factory pays the existing gas schedules of the ordinary opcodes it executes, so the score-0 anchor for no gas-accounting change applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "All factory behavior is expressed as contract bytecode; the proposal does not change any opcode's internal state-access or gas-charge sequence."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Executing existing CREATE2 from a new contract does not modify where state is accessed inside CREATE2 or any other opcode, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 37-104",
"source": "eip.md",
"summary": "The proposal is limited to installing and invoking a CREATE2 factory and contains no blob-related mechanism."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 41-45",
"source": "eip.md",
"summary": "Activation sets fixed code at the factory address but defines no state-gas rate, budget, reservoir, spill rule, or new state-gas charging site."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The state insertion is a protocol state change, not a change to state-gas accounting as defined by this anchor; score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "The bytecode copies calldata, invokes CREATE2, and returns or reverts; it defines no refund-counter behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameters and Factory Contract, lines 39-45",
"source": "eip.md",
"summary": "At activation, formerly ordinary address 0x0B receives fixed executable code."
},
{
"locator": "Rationale > Precompile-range system contract, lines 108-112",
"source": "eip.md",
"summary": "The address is selected immediately after existing precompiles and the insertion is explicitly irregular."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests that assume 0x0B is empty, call it as an empty account, or cross the activation transition need localized updates. This is a minor, narrow subset rather than a considerable or diverse body of pre-existing tests, matching score 1.",
"score": 1,
"uncertainty_note": "The sealed package does not enumerate the pre-existing test corpus, so the exact affected count cannot be established; the narrow address-specific impact is clear from the specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 43-45",
"source": "eip.md",
"summary": "The activation transition must leave the specified code at FACTORY_ADDRESS."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests not principally about the factory but which span this fork activation must additionally observe the code insertion in resulting state. That is a narrow activation-focused category, not a mechanically added assertion for every test in the fork, so score 1 applies.",
"score": 1,
"uncertainty_note": "The package specifies no test vectors, so whether a particular framework expresses this as an explicit assertion or through a state root is not established.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 43-45",
"source": "eip.md",
"summary": "Code is inserted upon activation, making the insertion specific to the activation transition rather than an ordinary rule run on every post-fork block."
},
{
"locator": "Rationale > Precompile-range system contract, lines 108-110",
"source": "eip.md",
"summary": "The EIP characterizes installing the account as an irregular insertion at a special address."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool must have a new activation-aware mechanism that distinguishes the one block where code is inserted from later blocks. This is more than one ordinary data field but does not imply multiple new fields plus another mechanism, fitting score 2.",
"score": 2,
"uncertainty_note": "The EIP does not prescribe a transition-tool API; an environment with sufficient existing fork-activation context might implement the behavior without a new external field.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "Expected behavior consists of ordinary account code, calldata, value forwarding, contract creation, return data, and revert outcomes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing state, call, creation, return-data, and revert expectations are sufficient to test the fixed bytecode; no new framework-level expectation or modifier is required, so score 0 applies.",
"score": 0,
"uncertainty_note": "The test section is TBD, but the specified behaviors do not reveal a need for a novel primitive.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 50-98",
"source": "eip.md",
"summary": "The contract supplies a salt and initcode to the already-defined CREATE2 opcode and introduces no cryptographic construction of its own."
},
{
"locator": "Specification, lines 11-21",
"source": "supporting/eip-1014.md",
"summary": "CREATE2 already defines its deterministic address formula and fixed hash preimage as part of the existing opcode."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Reusing CREATE2's existing Keccak-based address derivation is not a new or modified cryptography mechanism, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 50-103",
"source": "eip.md",
"summary": "The code has a 32-byte input-length boundary, variable-length initcode copying, CREATE2 success and zero-result branches, failure-returndata propagation, and full call-value forwarding."
},
{
"locator": "Clarifications, lines 41-57",
"source": "supporting/eip-1014.md",
"summary": "Existing CREATE2 behavior includes collision failure and same-transaction recreation boundaries that factory tests inherit."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Several edge-prone mechanisms must be covered: 31 versus 32-byte input, empty and variable initcode, creation success versus collision or initcode failure, return-data lengths, and value forwarding. They are multiple but remain bounded combinations around a small fixed contract, fitting score 2 rather than the elevated-case score 3.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 37-104",
"source": "eip.md",
"summary": "The proposal defines a state insertion and contract execution behavior, with no block RLP or block-validation encoding rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 37-104",
"source": "eip.md",
"summary": "The entire change is within execution-layer state and EVM contract behavior; no Engine API endpoint or field is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or communication mechanism is added, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-16",
"source": "eip.md",
"summary": "A new minimal CREATE2 factory is inserted as a system contract at a fixed address."
},
{
"locator": "Specification > Factory Contract, lines 45-98",
"source": "eip.md",
"summary": "The contract accepts value and variable initcode, invokes CREATE2, and thereby can create a new state account before returning its address."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "The proposal adds one system contract whose operation can create contracts and transfer the forwarded value, making it stateful in effect. The single stateful-system-contract anchor is score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Rationale > Precompile-range system contract, lines 14-16 and 108-112",
"source": "eip.md",
"summary": "The EIP adds a factory at the next address after existing precompiles; it does not alter the code, state, or behavior of a pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Addition of a distinct system contract is scored in the preceding criterion and causes no direct or identified indirect modification to an existing system contract, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "The factory is bytecode assembled entirely from existing EVM instructions, including CREATE2, RETURNDATASIZE, and RETURNDATACOPY."
},
{
"locator": "Specification, lines 27-42",
"source": "supporting/eip-211.md",
"summary": "RETURNDATASIZE and RETURNDATACOPY are pre-existing opcodes with specified behavior and gas costs."
},
{
"locator": "Specification, lines 11-21",
"source": "supporting/eip-1014.md",
"summary": "CREATE2 is likewise an already-defined opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "The EIP deploys code that uses existing opcodes and allocates no opcode number, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "The exact factory program invokes existing instructions but supplies no amended opcode semantics."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Calling CREATE2 and return-data opcodes from a newly installed contract does not modify their behavior, so the binary score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification > Factory Contract, lines 14-16 and 43-45",
"source": "eip.md",
"summary": "The proposal explicitly calls the factory a system contract and installs ordinary bytecode, although its address lies in the precompile range."
},
{
"locator": "Rationale > Precompile-range system contract, lines 108-112",
"source": "eip.md",
"summary": "The range is used to obtain a special reserved address; no native precompile function or gas schedule is defined."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "Placement in the precompile address range does not make fixed EVM bytecode a precompile. No native precompile is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Precompile-range system contract, lines 108-112",
"source": "eip.md",
"summary": "Address 0x0B is selected as the next address after existing precompiles, leaving the existing precompile addresses and behavior untouched."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "The proposal neither changes an existing precompile's logic nor its gas schedule, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "The factory has a raw calldata convention of salt followed by initcode and does not change transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "An application-level calldata layout for one contract is outside the RLP/SSZ transaction, block, and interface encoding anchor; no such encoding changes are introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Not a new transaction type, lines 126-128",
"source": "eip.md",
"summary": "A new creation transaction type was considered and rejected in favor of the system-contract approach."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The proposal explicitly introduces no transaction type, so the binary score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Not a new transaction type, lines 126-128",
"source": "eip.md",
"summary": "The design deliberately uses calls to a system contract instead of adding a transaction form."
},
{
"locator": "Specification > Factory Contract, lines 45-104",
"source": "eip.md",
"summary": "Input rejection and CREATE2 failure are EVM call execution outcomes, not transaction validity or intrinsic-gas rules."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No existing transaction validity rule or intrinsic gas calculation is changed, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 37-104",
"source": "eip.md",
"summary": "The complete specification consists of a fixed address and contract code; it defines no block or block-header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced, so the binary score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 41-45",
"source": "eip.md",
"summary": "Upon activation, clients must set the code of address 0x0B to a specified byte sequence."
},
{
"locator": "Rationale > Precompile-range system contract, lines 108-110",
"source": "eip.md",
"summary": "The EIP states that normal deployment cannot provide the desired guarantee and therefore requires irregular code insertion at a special address."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The fork activation block directly modifies state by installing account code. The rubric assigns score 3 whenever activation modifies state or internal variables.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 50-98",
"source": "eip.md",
"summary": "Variable input copying and contract creation are performed by ordinary EVM bytecode using existing calldata, memory, and CREATE2 operations."
},
{
"locator": "Specification and Rationale > Gas cost, lines 13-21 and 37-39",
"source": "supporting/eip-1014.md",
"summary": "CREATE2 already meters initcode hashing by length to cover the associated computation and denial-of-service concern."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new fixed account exposes no new client execution algorithm or unmetered workload beyond already metered EVM execution; therefore it does not introduce a mechanism requiring separate protocol performance validation and scores 0.",
"score": 0,
"uncertainty_note": "Adoption could increase use of CREATE2 factories, but workload popularity is not a new protocol performance mechanism specified by this EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > No frontrunning protection, lines 118-124",
"source": "eip.md",
"summary": "The minimal factory deliberately omits caller-bound salt protection and leaves more feature-rich protected factories to applications."
},
{
"locator": "Security Considerations > Frontrunnable deployments, lines 139-143",
"source": "eip.md",
"summary": "Environment-dependent initcode can be frontrun and deployed with attacker-selected parameters, so use is recommended only for fully deterministic contracts."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The security exposure is explicit but localized to the small factory's deployment semantics and can be reviewed and tested in isolation. It does not substantially alter multiple critical component assumptions, fitting score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Factory Contract, lines 41-104",
"source": "eip.md",
"summary": "The activation address and exact bytecode are fixed, and the bytecode explicitly defines the input-length rejection, CREATE2 invocation, success return, and failure revert paths."
},
{
"locator": "Specification, lines 27-42",
"source": "supporting/eip-211.md",
"summary": "The return-data behavior used by the factory, including CREATE2 failure data, is specified by the required EIP."
},
{
"locator": "Specification and Clarifications, lines 11-21 and 41-57",
"source": "supporting/eip-1014.md",
"summary": "The required CREATE2 proposal fixes address derivation, gas timing, collision failure, and same-transaction collision behavior."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The fixed bytecode plus the two required opcode specifications determines outcomes for constructible execution cases; the missing test vectors do not themselves leave consensus behavior unspecified. The score-0 anchor applies.",
"score": 0,
"uncertainty_note": "The Test Cases section is TBD, but this is a coverage gap rather than an identified behavioral question requiring client agreement.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter, lines 1-12",
"source": "eip.md",
"summary": "The proposal declares direct requirements on EIPs 211 and 1014."
},
{
"locator": "Specification > Factory Contract, lines 73-90",
"source": "eip.md",
"summary": "Its core success and failure flow invokes CREATE2 and uses the return-data buffer opcodes to propagate failure data."
},
{
"locator": "Specification, lines 27-42",
"source": "supporting/eip-211.md",
"summary": "EIP-211 defines the return-data buffer and its specific CREATE2 success and failure behavior used by the factory."
},
{
"locator": "Specification, lines 11-21",
"source": "supporting/eip-1014.md",
"summary": "EIP-1014 defines the CREATE2 address, dynamic hash cost, and gas-charge timing inherited by factory calls."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
211,
1014
],
"rationale": "Correct testing must coordinate the new factory with two directly required EIPs, especially CREATE2 success or collision failure and EIP-211 failure-returndata propagation. The dependencies are important but limited to this small call path, matching score 2 rather than extensive multi-EIP interdependence.",
"score": 2,
"uncertainty_note": "References to EIPs 155, 5792, and 7702 describe motivation or rejected workarounds, not protocol dependencies or behavior modified by EIP-7997, so they are not counted as interacting EIPs.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7997,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:7997:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The manifest and output template title the item Deterministic Factory Contract, while the sealed historical EIP front matter says Deterministic Factory Predeploy; the EIP number, revision identity, and hashes match.",
"The proposal requires an activation-only state insertion but does not prescribe a transition-tool API; the interface-change score therefore reflects the required activation-aware mechanism rather than a named field."
],
"provenance": {
"assessed_revision": {
"commit": "f8be9ce27bdb513ba72abddde06cb5e806447230",
"committed_at": "2025-08-19T16:32:51Z",
"content_sha256": "8fec7a727f75a9762f34427ed5046b49d59b63a9c16d38f319c8e1060ebd93bd",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7997.md",
"git_blob_sha": "9bd8766f329acc3b21d2fa6dc53d5655488891ab",
"immutable_url": "https://github.com/ethereum/EIPs/blob/f8be9ce27bdb513ba72abddde06cb5e806447230/EIPS/eip-7997.md",
"information_cutoff_at": "2025-08-21T13:34:18Z",
"path": "EIPS/eip-7997.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7997.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7997.yaml",
"sha256": "aada0f5dcac593430a1597b63880afaa624afdb6127acf6b66ba33f04b61c2af"
},
"supporting_documents": [
"supporting/eip-155.md",
"supporting/eip-211.md",
"supporting/eip-1014.md",
"supporting/eip-5792.md",
"supporting/eip-7702.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 14,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7997 proposed an activation-time insertion of fixed runtime bytecode at address 0x0B, creating a minimal factory available at the same address on adopting EVM chains. The factory interprets calldata as a 32-byte salt followed by variable-length initcode, forwards all call value to CREATE2, returns the created address on success, and propagates failure returndata by reverting. It adds no transaction type, opcode, or custom gas schedule; its protocol changes are the predeployed system account and the one-time state change that installs it.",
"tier": "medium",
"title": "Deterministic Factory Contract",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 14
},
"present": false,
"summary": "The Test Cases section is unfinished, but the exact installed bytecode and its required opcode semantics determine the consensus behavior; no material unresolved behavior was identified.",
"unresolved_questions": []
}
},
"amsterdam:8024:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [],
"published_tier": "low",
"published_total": 6,
"recomputed_tier": "low",
"recomputed_total": 6,
"timing_exposure": "low_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": null,
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Introduces 3 new opcodes",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance may be impacted if a client implementation doesn't keep the whole stack in memory",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8024,
"fork": "amsterdam",
"id": "amsterdam:8024:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "db5c483ea122c6735cd92ff135de985f0e9253e2",
"committed_at": "2025-11-04T03:54:51Z",
"content_sha256": "eb387a1073ee5e4869d769e3351e2c8dafb9073e6054f5a9819b8239fda1eb8a",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8024.md",
"git_blob_sha": "6d23fa7554175e3b14c2523fe118525e97f15bc1",
"immutable_url": "https://github.com/ethereum/EIPs/blob/db5c483ea122c6735cd92ff135de985f0e9253e2/EIPS/eip-8024.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-8024.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8024.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-8024.yaml",
"sha256": "4f3e36e040922e33a9323ab66e2da84b8cd12685ea887a11eb57c0a9b37e4989"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "e4f314d97a66349444ae7e562a13f6120a8b509c",
"committed_at": "2025-11-05T23:27:24Z",
"content_sha256": "b5a8ce9a96384bd02be21fd97e2752a102bcb9749be675b139089a86c257c528",
"git_blob_sha": "466f9a56d9f575e733f0aecbae0e7a49d8a51d47",
"immutable_url": "https://github.com/ethspecs/pm/blob/e4f314d97a66349444ae7e562a13f6120a8b509c/complexity_assessments/EIPs/eip8024.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/eip8024.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 6,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "low",
"title": "Backward compatible SWAPN, DUPN, EXCHANGE",
"under_specification": null
},
"amsterdam:8024:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Rationale > Gas cost",
"source": "eip.md",
"summary": "Each of DUPN, SWAPN, and EXCHANGE charges a constant 3 gas, explicitly matching existing DUP and SWAP instructions."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal extends the existing constant-cost EVM gas schedule to three new instructions, but introduces no new accounting mechanism or dynamic interaction; this is an update to the existing mechanism.",
"score": 1,
"uncertainty_note": "The checklist does not explicitly distinguish a new opcode's fixed gas assignment from an existing-mechanism update; the score conservatively treats it as the latter.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal is confined to three EVM stack-manipulation instructions and specifies no blob mechanism or blob gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting change is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; blob accounting is outside its stated and specified scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Rationale > Gas cost",
"source": "eip.md",
"summary": "The instructions charge 3 gas and the proposal defines no refund action or refund accounting."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; only up-front constant instruction charges are specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility; Test Cases > Assembly/Disassembly",
"source": "eip.md",
"summary": "The proposal allocates previously undefined bytes e6-e8 while preserving existing jump targets; its cases distinguish valid new instructions from invalid-immediate decoding."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Only the minor subset of pre-existing tests that assumes e6-e8 are undefined or exercises decoding around those bytes would need adjustment; the stated compatibility guarantee limits wider regression impact.",
"score": 1,
"uncertainty_note": "The sealed package contains no pre-existing test inventory, so the subset size is inferred solely from the proposal's narrow opcode allocation and compatibility discussion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification defines EVM instruction execution, immediate decoding, stack effects, and program-counter updates, with no transition-tool fields or interface mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No modification to the transition-tool interface is required by the proposal as written.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; no transition-tool interface is mentioned or implied by the specified execution-local inputs.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal performs stack duplication and swaps plus integer immediate decoding; it introduces no cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism or cryptographic functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; all defined operations are stack indexing and basic arithmetic.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Rationale > Disallowed immediate range; Test Cases",
"source": "eip.md",
"summary": "Three instructions use different discontinuous valid byte ranges, decoder boundary mappings, depth-dependent stack indexes, and special decoding around JUMPDEST and PUSH bytes."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms require coverage: opcode-specific immediate cutoffs, allowed-range discontinuities, decoder endpoints, deep stack availability, DUPN stack growth, and instruction-boundary/JUMPDEST behavior. The byte-domain and stack-depth combinations create an elevated test matrix.",
"score": 3,
"uncertainty_note": "The exact behavior for a missing immediate byte and for insufficient or full stack conditions is not explicit, so boundary expectations at those points remain under-specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes EVM bytecode instruction execution and explicitly leaves JUMPDEST analysis unchanged; it defines no block RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requiring client syncing is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; block encoding and sync validation are outside its specified scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "All inputs and effects are local to EVM code, stack, gas, and program counter; no Engine API field, endpoint, or communication mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API fields or communication mechanisms are introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; there is no Engine API surface in the described change.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The only encoding defined is an immediate byte inside EVM code; no Engine API object, field, or wire encoding is described."
}
],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Conservatively applying the row label, no Engine API encoding change is present.",
"score": 0,
"uncertainty_note": "The historical checklist contains this row but supplies no dedicated definition; the score is therefore based only on the row label and the proposal's absence of any Engine API surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal introduces EVM instructions only and specifies no contract deployment, address, code, state, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; no system-contract component appears in the design.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The change is limited to opcode allocation and execution semantics, and the compatibility section claims no effect on contracts that never execute the allocated opcodes."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract code or state is directly modified, and no system-contract-specific indirect effect is specified.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; the evidence identifies no system contract affected by the instructions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal allocates DUPN (0xe6), SWAPN (0xe7), and EXCHANGE (0xe8); each carries an immediate byte and performs depth-dependent or paired stack manipulation."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Three opcodes are added, and all are complex under the checklist because they have an immediate data portion and nontrivial stack mechanics; this directly matches score 3.",
"score": 3,
"uncertainty_note": "The complexity classification is clear from the specified immediate operands and stack indexing, although some exceptional execution details are under-specified separately.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal allocates previously undefined bytes for new instructions, states JUMPDEST analysis is unchanged, and preserves existing jump targets."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode's behavior is modified or deprecated; converting formerly undefined byte values into added opcodes is accounted for by the added-opcodes row.",
"score": 0,
"uncertainty_note": "The allocated bytes previously behaved as undefined instructions, but the checklist distinguishes adding opcodes from modifying a pre-existing opcode.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal adds EVM opcodes and no addressed native function or precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; precompiles are absent from the specified architecture.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Rationale > Gas cost",
"source": "eip.md",
"summary": "The gas and behavior changes apply only to the three new instructions; no precompile logic or gas schedule is mentioned."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile logic or gas accounting is modified.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; there is no precompile-related mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal defines one-byte immediate encodings within EVM bytecode, not transaction, block, or interface RLP/SSZ encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No encoding change at the transaction, block, or interface level is introduced, so the rubric's binary RLP/SSZ row scores zero.",
"score": 0,
"uncertainty_note": "The proposal uses the word encoding for opcode immediates, but that code-level encoding is outside the row's expressly stated transaction/block/interface scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal defines three EVM instructions and does not define a transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; transactions are not part of the specified change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The validity checks concern opcode immediate bytes during EVM execution; no transaction validity rule or intrinsic gas calculation is changed."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No new or modified transaction validity mechanism is introduced.",
"score": 0,
"uncertainty_note": "The invalid-immediate rules are execution semantics, not transaction admission or intrinsic-gas validity rules under this row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification adds opcode numbers and immediate semantics only; it defines no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal; block structure is outside its scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "Activation makes three opcode bytes executable but specifies no activation-block state transition, internal-variable modification, or initialization procedure."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state or internal-variable modification at the fork activation block is introduced.",
"score": 0,
"uncertainty_note": "The proposal does not provide a separate activation section; the score is limited to the absence of the state/internal-variable changes defined by this row.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale > Gas cost; Security Considerations",
"source": "eip.md",
"summary": "The proposal characterizes the operations as pointer swaps with negligible immediate decoding and notes that implementations generally keep the fixed 1024-item stack in memory."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new instruction paths merit isolated benchmarking, but their fixed-size decoding and pointer-based stack operations are self-contained and are not specified to change existing performance behavior.",
"score": 1,
"uncertainty_note": "The performance claims are qualitative and no measurements are present in the sealed evidence; deep-stack access behavior may vary by implementation.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale > Use of an immediate operand; Rationale > Disallowed immediate range; Security Considerations",
"source": "eip.md",
"summary": "The design protects static analysis and existing JUMPDEST/PUSH decoding by forbidding immediate ranges, while adding deep-stack access through three new execution paths."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Correctness interacts with a limited set of existing critical behaviors—bytecode decoding, program-counter advancement, jump-target analysis, and stack indexing. A defect could create consensus-visible execution differences, so targeted review and fuzzing are warranted, but the interaction surface remains limited.",
"score": 2,
"uncertainty_note": "The authors report no additional risks, but no implementation evidence is allowed and exceptional behavior for missing immediates or unavailable stack items is not fully specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal is self-contained around three opcode allocations and references no dependency on, modification of, or conflict with another EIP."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "No cross-EIP dependency or coordinated cross-EIP testing requirement is established by the sealed evidence.",
"score": 0,
"uncertainty_note": "No supporting documents are allowlisted, but the proposal itself declares no other-EIP interaction.",
"under_specified": false
}
],
"eip": 8024,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8024:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The gas row does not expressly classify fixed gas assigned to new opcodes; score 1 treats it as an update to the existing constant-cost mechanism, not a new mechanism.",
"The exact extent of affected pre-existing tests is unavailable; score 1 is inferred from the narrow formerly-undefined opcode range and stated backwards-compatibility guarantee.",
"The historical checklist provides no definition for Engine API encoding changes; that row is conservatively scored from its label with low confidence.",
"Opcode-immediate encoding is distinct from the transaction/block/interface encoding covered by the RLP/SSZ row."
],
"provenance": {
"assessed_revision": {
"commit": "28578c7ba0e3c7831a91a9784e85ce9b400c29a8",
"committed_at": "2025-09-17T17:24:56Z",
"content_sha256": "c4de111b08cfda07cfd60702295e534ca31ae972d649a07bbb490d34d9802ba1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8024.md",
"git_blob_sha": "b519c1ce6054ddfdbcb580af246786b466667522",
"immutable_url": "https://github.com/ethereum/EIPs/blob/28578c7ba0e3c7831a91a9784e85ce9b400c29a8/EIPS/eip-8024.md",
"information_cutoff_at": "2025-10-29T02:00:31Z",
"path": "EIPS/eip-8024.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8024.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-8024.yaml",
"sha256": "462eeb34487d7a5723f2fb68b6956500b1bddca607f0319fc92047be99624565"
},
"supporting_documents": []
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 11,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "Blinded assessment of the sealed Review-stage proposal introducing three one-byte-immediate EVM stack-manipulation opcodes, evaluated only against the sealed historical checklist and allowlisted package evidence.",
"tier": "medium",
"title": "Backward compatible SWAPN, DUPN, EXCHANGE",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"security_risks"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 10
},
"present": true,
"summary": "The specification does not explicitly define behavior when the immediate byte is absent at end of code, when the referenced stack item is unavailable, or when DUPN would exceed the stack limit; it also says invalid immediates 'revert, consuming all gas' without defining the exact exceptional-halt semantics. These omissions are recorded once here rather than added as separate complexity in unrelated rows.",
"unresolved_questions": [
"What exact execution result applies if code[pc + 1] is beyond the bytecode?",
"What exact exceptional behavior applies to insufficient stack depth and to DUPN at the 1024-item stack limit?",
"Does 'revert, consuming all gas' denote the EVM's exceptional halt, and what precise state and returndata effects are required?"
]
}
},
"amsterdam:8024:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-65",
"source": "eip.md",
"summary": "Each of the three newly allocated opcodes charges a fixed 3 gas before decoding and executing its immediate operand."
},
{
"locator": "Rationale / Gas cost, lines 142-144",
"source": "eip.md",
"summary": "The fixed cost is justified by comparison to existing DUP and SWAP operations and by the negligible cost of pointer swapping and immediate decoding."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal creates gas rules for new operations but leaves existing opcode gas schedules and accounting mechanisms unchanged. This matches the score-2 anchor for a new, isolated gas-accounting rule that does not alter existing mechanisms.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 37-67",
"source": "eip.md",
"summary": "The new operations read, duplicate, or swap only stack entries and do not access persistent state."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode performs a state access, so neither state-access placement nor gas-charge ordering relative to a state access changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-65",
"source": "eip.md",
"summary": "The specification is limited to three stack instructions with ordinary fixed gas charges and contains no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 37-65",
"source": "eip.md",
"summary": "All specified effects are on the program counter and in-memory EVM stack; no state write or state-gas site is present."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-writing charge, state-gas rate, budget, reservoir, or spill rule changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-65",
"source": "eip.md",
"summary": "The opcode algorithms charge 3 gas and specify no refund action."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Disallowed immediate range, lines 117-125",
"source": "eip.md",
"summary": "Bytes 0xe6 through 0xe8 change from undefined opcodes to immediate-bearing operations, while forbidden immediate values are designed to preserve existing JUMPDEST and PUSH boundaries."
},
{
"locator": "Backwards Compatibility and Test Cases, lines 150-175",
"source": "eip.md",
"summary": "Existing code is unaffected unless it attempts to execute an allocated opcode, and examples exercise the changed invalid-opcode and jump-target cases."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests that deliberately execute the formerly undefined opcode bytes or test nearby instruction boundaries need limited expectation updates. The explicit compatibility design prevents this from extending beyond a minor, specialized subset, matching score 1.",
"score": 1,
"uncertainty_note": "The sealed package contains no pre-existing test inventory, so the affected subset size is inferred from the proposal's compatibility guarantee.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Disallowed immediate range, lines 119-125",
"source": "eip.md",
"summary": "Preserving existing execution traces and JUMPDEST locations is a compatibility property of this EIP rather than a new output every unrelated test must assert."
},
{
"locator": "Test Cases, lines 154-175",
"source": "eip.md",
"summary": "The listed assertions are feature-specific assembly and execution examples, not a new assertion applied to all pre-existing tests."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Some old invalid-opcode expectations may be reworked, but unrelated tests do not gain an additional EIP-produced value or invariant to assert.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-109",
"source": "eip.md",
"summary": "The entire specified input is opcode bytecode and one-byte immediates; no transition-tool field or interface mechanism is defined."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Opcode execution can be exercised through existing transition inputs, with no new transition-tool interface field.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases, lines 154-175",
"source": "eip.md",
"summary": "Tests are expressed as ordinary bytecode assembly/disassembly mappings and execution results or halts."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Raw bytecode, stack-result, success, and exceptional-halt cases can be represented with ordinary EVM test capabilities; the proposal does not require a new reusable expectation or modifier primitive.",
"score": 0,
"uncertainty_note": "The package does not describe the test framework, but none of the proposed assertions requires a novel result type.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 29-89",
"source": "eip.md",
"summary": "The feature consists of stack indexing, swapping, and arithmetic decoding, with no cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-89",
"source": "eip.md",
"summary": "Each opcode has immediate-validity boundaries, decoded stack-index boundaries, stack access behavior, and a two-branch pair-decoding function."
},
{
"locator": "Rationale / Disallowed immediate range and EXCHANGE immediate, lines 117-131",
"source": "eip.md",
"summary": "The encoding excludes JUMPDEST and PUSH bytes to prevent cascading instruction-boundary changes, while EXCHANGE deliberately maps a constrained set of stack-index pairs."
},
{
"locator": "Test Cases, lines 154-175",
"source": "eip.md",
"summary": "Examples cover valid and invalid single and pair encodings, multiple PUSH widths, JUMPDEST preservation, and execution outcomes."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple independent boundary families require coverage: allowed versus forbidden immediate ranges, both decode branches, pair constraints, program-counter and instruction-boundary behavior, and stack underflow/overflow at decoded depths. The combinatorial encoding and JUMPDEST/PUSH compatibility surface calls for an elevated number of cases, matching score 3.",
"score": 3,
"uncertainty_note": "The terminal-byte immediate case is not explicitly specified and is recorded under under-specification.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-69",
"source": "eip.md",
"summary": "The proposal changes EVM bytecode execution and explicitly discusses code-level JUMPDEST analysis, not block RLP validation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP field or validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-109",
"source": "eip.md",
"summary": "The specification defines only opcode numbers, immediates, execution semantics, and assembler encodings; it defines no Engine API field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API communication field or mechanism changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 29-35",
"source": "eip.md",
"summary": "The feature allocates three opcodes and does not introduce any contract address, code deployment, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 150-152",
"source": "eip.md",
"summary": "Contracts that never execute the newly allocated opcode bytes are unaffected, and existing jump targets are preserved."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system-contract code or state is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-65",
"source": "eip.md",
"summary": "Three new opcodes, DUPN, SWAPN, and EXCHANGE, are allocated; all consume an immediate byte and perform decoded stack manipulation."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "The EIP introduces multiple opcodes and each has a data portion plus nontrivial decoded stack indexing; EXCHANGE also decodes two operands. At least one is complex under the anchor, so multiple additions warrant score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 31-35 and 150-152",
"source": "eip.md",
"summary": "The proposal allocates previously undefined bytes as new instructions while preserving existing JUMPDEST behavior; it does not change a pre-existing opcode's result."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Adding behavior at formerly undefined opcode values is scored as added opcodes, not modification or deprecation of an existing opcode.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-65",
"source": "eip.md",
"summary": "The change is fully specified as ordinary opcode execution and contains no precompile address or call interface."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-65",
"source": "eip.md",
"summary": "Only new stack opcodes and their fixed gas charges are specified; no precompile behavior or gas schedule appears."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas accounting is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-41 and 91-109",
"source": "eip.md",
"summary": "The only encoding introduced is an immediate byte inside EVM bytecode; no transaction, block, or interface encoding changes."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Bytecode instruction encoding is outside this anchor's transaction, block, and interface RLP/SSZ scope.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 29-35",
"source": "eip.md",
"summary": "The proposal introduces stack instructions only and defines no transaction envelope or type identifier."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-109",
"source": "eip.md",
"summary": "All validation conditions concern opcode immediate bytes during VM execution, not transaction validity or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic-gas calculation changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 29-109",
"source": "eip.md",
"summary": "The specification contains opcode and bytecode fields only and defines no block-body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 29-35 and 150-152",
"source": "eip.md",
"summary": "Activation allocates three instruction bytes, with no stated one-time state transition or modification of an internal variable at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The EIP requires no fork-block state or internal-variable modification.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Gas cost and EXCHANGE vs SWAPN, lines 142-148",
"source": "eip.md",
"summary": "The implementation model is a pointer swap plus simple immediate decoding, asserted to have negligible decoding overhead and no extra runtime cost."
},
{
"locator": "Security Considerations, lines 177-179",
"source": "eip.md",
"summary": "The stack remains fixed at 1024 items and is described as already held in memory by most implementations."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new deep-index decode and stack operations merit isolated validation of the fixed gas-cost assumption, but are self-contained and are not expected to disturb existing performance behavior. This matches score 1.",
"score": 1,
"uncertainty_note": "No benchmark evidence is packaged; the validation scope is inferred from the proposal's gas-cost rationale.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Use of an immediate operand, lines 111-115",
"source": "eip.md",
"summary": "Static immediates are chosen specifically to preserve stack-content analysis used by security auditors."
},
{
"locator": "Rationale / Disallowed immediate range, lines 117-125",
"source": "eip.md",
"summary": "Incorrect instruction-boundary handling could remove or create JUMPDESTs and cascade through later bytecode, while arbitrary sequences can exist in deployed or pending code."
},
{
"locator": "Security Considerations, lines 177-179",
"source": "eip.md",
"summary": "The authors report no additional known risks but acknowledge that one instruction can newly access deeper stack items."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The stack operations are localized, but their unusual immediate-validity rules interact with instruction decoding, static analysis, and consensus-critical jump destinations. Preserving the stated backwards-compatibility invariant warrants targeted review and fuzzing across this limited set of components, matching score 2.",
"score": 2,
"uncertainty_note": "The proposal asserts that no additional risks are known, so the score reflects review burden from the documented decoding interaction rather than a known vulnerability.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 43-69",
"source": "eip.md",
"summary": "Each algorithm reads code[pc + 1] and indexes the stack, but the text does not explicitly state the result when the opcode is the final code byte; invalid present immediates and instruction-boundary handling are specified."
},
{
"locator": "Test Cases, lines 154-175",
"source": "eip.md",
"summary": "The examples cover numerous valid and invalid two-byte forms but do not include a missing immediate at end-of-code."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A few constructible boundary cases rely on an implicit base-EVM reading, most notably an opcode at the final byte with no immediate available. The intended use of established code-fetch and stack-fault conventions is apparent and localized, so this fits score 1 rather than requiring broad design agreement.",
"score": 1,
"uncertainty_note": "It is unclear from the sealed text alone whether end-of-code reads and all stack fault paths are intended to inherit existing EVM conventions without an explicit rule.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 29-69 and 111-148",
"source": "eip.md",
"summary": "The feature refers only to existing EVM opcodes and stack behavior and identifies no dependency on, modification of, or conflict with another numbered EIP."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The proposal is self-contained at the EIP level and identifies no coordinated cross-EIP testing requirement.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8024,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8024:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The final-byte immediate case is not explicitly defined even though every formal opcode algorithm reads code[pc + 1].",
"The phrase \"revert, consuming all gas\" appears to specify an exceptional halt, but it does not use a precise named base-EVM exception.",
"The gas anchor can be read narrowly as only a new fixed opcode cost; this assessment treats the three isolated cost rules as a new accounting rule without effects on existing schedules."
],
"provenance": {
"assessed_revision": {
"commit": "28578c7ba0e3c7831a91a9784e85ce9b400c29a8",
"committed_at": "2025-09-17T17:24:56Z",
"content_sha256": "c4de111b08cfda07cfd60702295e534ca31ae972d649a07bbb490d34d9802ba1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8024.md",
"git_blob_sha": "b519c1ce6054ddfdbcb580af246786b466667522",
"immutable_url": "https://github.com/ethereum/EIPs/blob/28578c7ba0e3c7831a91a9784e85ce9b400c29a8/EIPS/eip-8024.md",
"information_cutoff_at": "2025-10-29T02:00:31Z",
"path": "EIPS/eip-8024.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8024.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-8024.yaml",
"sha256": "5f3bb2571aaeeb825cd449a9c1f1e103e18e8a3ab20b47b2bf24fd77bba4e05c"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 13,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, the proposal added three execution-layer opcodes at 0xe6 through 0xe8 for immediate-encoded deep duplication, deep swapping, and pairwise exchange of stack items. Each opcode carries a one-byte immediate and charges a fixed 3 gas, while selected immediate values are forbidden so that existing JUMPDEST and PUSH interpretation remains unchanged. The stated scope is opcode semantics, encoding and decoding, assembly/disassembly, and execution; it does not introduce transaction, block, state, precompile, or external-interface changes.",
"tier": "medium",
"title": "Backward compatible SWAPN, DUPN, EXCHANGE",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 12
},
"present": true,
"summary": "Material but localized under-specification is present. The formal algorithms read code[pc + 1] without explicitly defining a missing immediate at end-of-code, and stack-fault behavior is left to implicit base-EVM conventions. This chiefly affects boundary baselining rather than the proposal's overall design.",
"unresolved_questions": [
"What exact execution result and program-counter treatment applies when DUPN, SWAPN, or EXCHANGE is the final byte of code and code[pc + 1] is unavailable?",
"Are stack underflow and overflow for every decoded depth intended to inherit existing EVM exceptional-halt behavior without additional wording?"
]
}
},
"amsterdam:8037:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [
"Blank cells are interpreted as zero only because the published total exactly equals the sum of every nonblank parsed contribution."
],
"published_tier": "high",
"published_total": 28,
"recomputed_tier": "high",
"recomputed_total": 28,
"timing_exposure": "high_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "GAS_CREATE + GAS_CODE_DEPOSIT can be considered the same category of change; CALL by itself requires testing must be separated; SSTORE requires its own testing plus the new multidimensional metering logic; EOA changes are simple and reduced in scope.",
"raw_score_cell": "2 + 2 + 3 + 1",
"score": 8,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Refund tests are indirectly affected by the SSTORE change.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "CREATE, CALL, and SSTORE are values that have not been updated since Frontier. This change will break an excessive amount of static tests (https://github.com/ethereum/execution-specs/tree/forks/osaka/tests/static) and will require some rework in existing python tests. Counting each of these as a multiplier for this row.",
"raw_score_cell": "3 + 3 + 3",
"score": 9,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Bundling all changes into this single row since they are similar.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Modifies the contract creation from a contract-creating transaction, and the EOA delegation cost.",
"raw_score_cell": "3 + 1",
"score": 4,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Considering contract creation and account calling are so fundamental, this will require oversight on other EIPs that are CFI'd.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8037,
"fork": "amsterdam",
"id": "amsterdam:8037:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "dee539a58f206ce2a3bf08130605adf50938c40f",
"committed_at": "2025-10-28T10:20:33Z",
"content_sha256": "8ee674c5e6bb08ab4888df2571c712a17dfddfbbb492583caad8061f9e54366e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8037.md",
"git_blob_sha": "176cab4ecae238d73b95747591895904a1cd31ef",
"immutable_url": "https://github.com/ethereum/EIPs/blob/dee539a58f206ce2a3bf08130605adf50938c40f/EIPS/eip-8037.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-8037.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8037.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-8037.yaml",
"sha256": "2836f7a456c43785e750999867c96265a4a22a062bdef10f044d5b6242dd46ed"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "eb0d24aec552ce5ec5eca689a37f0eb47fe75203",
"committed_at": "2025-12-04T14:04:31Z",
"content_sha256": "f37704066caeca7e1e6f0275dcabc9430781fbd3bd640bf222d9683a2b2eed52",
"git_blob_sha": "55fd5115c92d96f4d16d3be69dd87e04ce037ba0",
"immutable_url": "https://github.com/ethspecs/pm/blob/eb0d24aec552ce5ec5eca689a37f0eb47fe75203/complexity_assessments/EIPs/EIP-8037.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-8037.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 28,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "high",
"title": "State Creation Gas Cost Increase",
"under_specification": null
},
"amsterdam:8037:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes; Multidimensional metering for code deposit gas",
"source": "eip.md",
"summary": "Seven existing gas parameters are repriced and a separate code_deposit_gas dimension is introduced for contract deployment."
},
{
"locator": "Specification > Contract deployment cost calculation",
"source": "eip.md",
"summary": "CREATE-family charging now depends on runtime-code existence, warm/cold access, runtime hashing, and bytecode length."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "evm_gas_rule_changes",
"rationale": "This introduces a new gas-accounting mechanism and changes existing CREATE, CREATE2, creation-transaction, SSTORE, SELFDESTRUCT, account-creation, and EIP-7702 charging, necessarily affecting existing mechanisms and their tests; this matches score 3.",
"score": 3,
"uncertainty_note": "The exact mechanics of the second gas dimension are under-specified, but the presence and broad interaction of the new mechanism are explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes; Multidimensional metering for code deposit gas",
"source": "eip.md",
"summary": "The changes concern execution gas and code-deposit gas; no blob-gas rule is introduced or modified."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting change is specified, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameter changes",
"source": "eip.md",
"summary": "PER_EMPTY_ACCOUNT_COST and PER_AUTH_BASE_COST are repriced, but no refund procedure is added."
},
{
"locator": "Specification > Set code transaction > Behavior, step 7",
"source": "supporting/eip-7702.md",
"summary": "EIP-7702 already defines the refund based on the difference between those two parameters."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "new_evm_gas_refund",
"rationale": "EIP-8037 changes inputs to an existing EIP-7702 refund but introduces no new gas-refund mechanism, which is the score-0 anchor.",
"score": 0,
"uncertainty_note": "The resulting existing refund amount changes; the historical row is specifically framed around introduction of a new refund mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes",
"source": "eip.md",
"summary": "Repricing spans contract creation, new-account funding, SELFDESTRUCT account creation, SSTORE, and EIP-7702 delegation."
},
{
"locator": "Specification > Contract deployment cost calculation; Backwards Compatibility",
"source": "eip.md",
"summary": "Contract-deployment charging gains new code-existence branches, and the proposal is explicitly backwards incompatible for gas estimation."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests across diverse transaction and opcode paths, gas-estimation cases, warm/cold access, and contract deployment must be reworked, meeting the major-and-diverse score-3 anchor.",
"score": 3,
"uncertainty_note": "The package contains no test inventory, so the exact count is unknown, but the affected categories are explicit and diverse.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Multidimensional metering for code deposit gas",
"source": "eip.md",
"summary": "The proposal names internal gas and code_deposit_gas dimensions but specifies no field or mechanism for a transition-tool interface."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "transition_tool_interface_changes",
"rationale": "No modification to the transition-tool interface is specified, so the conservative package-grounded score is 0.",
"score": 0,
"uncertainty_note": "The second-dimension execution model is incomplete and could ultimately require an interface mechanism, but no such requirement is present in the sealed proposal.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Contract deployment cost calculation; CREATE vs CREATE2",
"source": "eip.md",
"summary": "The proposal uses keccak256 of runtime bytecode for code-existence checking and charges for that hashing; it does not define a new cryptographic mechanism."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "cryptography",
"rationale": "Use of the existing runtime-code hash does not introduce new cryptography, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Contract deployment cost calculation; CREATE vs CREATE2",
"source": "eip.md",
"summary": "Charging branches on code existence and warm/cold state, rounds length to words, and distinguishes CREATE2's init-code hash from the runtime-code hash."
},
{
"locator": "Rationale > Duplicated bytecode discount",
"source": "eip.md",
"summary": "The proposal calls out same-block ordering, exact-byte equality, repeated deployments, mandatory hashing, and empty-code handling."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact across creation forms, state visibility, bytecode sizes, and access status, with the code-deduplication branch requiring an elevated matrix of cases; this matches score 3.",
"score": 3,
"uncertainty_note": "Revert and failed-creation effects on code-existence accounting are not explicitly described, adding further test uncertainty without changing the anchor selection.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Multidimensional metering for code deposit gas",
"source": "eip.md",
"summary": "EIP-8037 introduces a code-deposit meter but does not specify a block RLP field or a new block RLP validation rule."
},
{
"locator": "Specification > Block header extension; Block validity condition",
"source": "supporting/eip-8011.md",
"summary": "The referenced full EIP-8011 design has a header extension, but EIP-8037 does not state that this portion is inherited by its two-dimensional variant."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "block_syncing_changes",
"rationale": "With no block RLP validation mechanism specified for the assigned proposal, score 0 is the conservative historical-checklist result.",
"score": 0,
"uncertainty_note": "The phrase \"two-dimensional version of EIP-8011\" leaves unclear whether EIP-8011's block header and validation machinery would be inherited.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative changes are execution gas parameters, code-deposit metering, and contract deployment charging; no Engine API field, endpoint, or communication mechanism is specified."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "engine_api_changes",
"rationale": "No Engine API addition or change is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No Engine API payload, field, endpoint, or encoding is described among the proposal's execution-layer changes."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "engine_api_encoding_changes",
"rationale": "Conservatively applying the undefined row from its label and global score range, the absence of any Engine API encoding change supports score 0.",
"score": 0,
"uncertainty_note": "The historical rubric contains this checklist row but provides no dedicated definition, so the score cannot be anchored more precisely.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes gas parameters and contract-creation accounting without introducing any system-contract address, code, state, or action."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "added_system_contracts",
"rationale": "No system contract is added, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes; Contract deployment cost calculation",
"source": "eip.md",
"summary": "All listed effects concern general state-creation operations and contract deployment; no pre-existing system contract is identified as directly or indirectly affected."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "modified_system_contracts",
"rationale": "No modification or evidenced indirect effect on a pre-existing system contract is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes",
"source": "eip.md",
"summary": "Existing CREATE, CREATE2, SELFDESTRUCT, and SSTORE operations are repriced; no opcode is added."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "added_opcodes",
"rationale": "No new opcode is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes; Contract deployment cost calculation",
"source": "eip.md",
"summary": "Existing opcodes receive new gas amounts and gas-accounting branches, while their execution semantics and availability are not otherwise changed."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "modified_opcodes",
"rationale": "The historical definition explicitly excludes gas changes from modified-opcode scoring; no non-gas opcode behavior modification or deprecation is specified, so score 0 applies.",
"score": 0,
"uncertainty_note": "Runtime-code deduplication changes charging and storage implementation treatment, but the resulting account codeHash semantics described by the proposal remain the same.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No new precompile address, input, behavior, or gas schedule is specified."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "added_precompiles",
"rationale": "No precompile is added, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes",
"source": "eip.md",
"summary": "The complete parameter table covers state-creation and delegation costs and does not modify any precompile gas schedule or logic."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "EIP-8037 specifies gas and state/code-existence accounting but no transaction, block, or interface RLP/SSZ encoding change."
},
{
"locator": "Specification > Block header extension",
"source": "supporting/eip-8011.md",
"summary": "Full EIP-8011 includes a header encoding extension, but the assigned EIP neither copies that rule nor says its two-dimensional variant inherits it."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No encoding change is specified by the assigned proposal, so the binary score is 0.",
"score": 0,
"uncertainty_note": "The incomplete reference to a two-dimensional EIP-8011 variant leaves possible header encoding behavior unresolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameter changes",
"source": "eip.md",
"summary": "Existing contract-creation transactions, account-funding transactions, and EIP-7702 transactions are affected; no transaction type is defined."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed sources.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameter changes; Multidimensional metering for code deposit gas",
"source": "eip.md",
"summary": "Intrinsic and execution-related costs across existing transaction forms are repriced, while code-deposit gas is split from ordinary transaction gas."
},
{
"locator": "Specification > New-account surcharge; Intrinsic gas computation",
"source": "supporting/eip-2780.md",
"summary": "Required EIP-2780 adds GAS_NEW_ACCOUNT to intrinsic gas for value transfers creating accounts, and EIP-8037 increases that parameter."
},
{
"locator": "Specification > Gas Cap; Changes to EVM Behavior",
"source": "supporting/eip-7825.md",
"summary": "The existing transaction gas-limit cap is a validity rule; EIP-8037's separate meter is introduced specifically so code-deposit costs do not constrain deployments under that cap."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing intrinsic-gas validity changes across transaction families and a new gas dimension must be represented outside the ordinary per-transaction limit, requiring extensive test rework and multidimensional test support; this meets score 3.",
"score": 3,
"uncertainty_note": "The exact validity, fee, and failure semantics of code_deposit_gas are not fully specified, making the needed infrastructure clear in kind but uncertain in detail.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Multidimensional metering for code deposit gas",
"source": "eip.md",
"summary": "The proposal names two metering dimensions but specifies no block or header field."
},
{
"locator": "Specification > Block header extension",
"source": "supporting/eip-8011.md",
"summary": "The referenced six-dimensional proposal defines max_gas_metered, but EIP-8037 does not explicitly adopt that field."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced in the assigned proposal, so score 0 applies.",
"score": 0,
"uncertainty_note": "It is unresolved whether the required two-dimensional EIP-8011 variant is intended to inherit max_gas_metered.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameter changes; Backwards Compatibility",
"source": "eip.md",
"summary": "The new rules apply upon a scheduled network upgrade, but no one-time state mutation, existing internal-variable mutation, or special activation-block transition is specified."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "new_fork_activation_mechanism",
"rationale": "A normal scheduled rule change without an activation-block state or internal-variable transition does not introduce the mechanism described by the score-3 anchor, so score 0 applies.",
"score": 0,
"uncertainty_note": "Existing gas constants change at activation, but the proposal describes no special one-time activation operation beyond selecting the new rules.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Independent metering for code deposit costs",
"source": "eip.md",
"summary": "Code-deposit cost is excluded from traditional block and transaction gas limits, potentially allowing very large contracts that stress the network; benchmarking and analysis are required."
},
{
"locator": "Motivation; Rationale > Multidimensional metering",
"source": "eip.md",
"summary": "The repricing targets long-run database growth at much higher block limits and deliberately changes the transaction-cap treatment of contract deployments."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "performance_risks",
"rationale": "The mechanism interacts with block throughput, transaction caps, hashing, state/database growth, and maximum-size deployments and cannot be validated in isolation; the stated network-stress concern and benchmark requirement meet score 3.",
"score": 3,
"uncertainty_note": "The package supplies estimates but no benchmark results, and the final second-dimension limits are unresolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Mispricing with respect to ETH transfers",
"source": "eip.md",
"summary": "Repricing account creation creates an avoidance path unless the EIP-2780 intrinsic surcharge is coordinated with this proposal."
},
{
"locator": "Security Considerations > Independent metering for code deposit costs",
"source": "eip.md",
"summary": "The proposal explicitly identifies an attacker path using very large contracts outside the traditional block and transaction gas limits and says mitigations may be needed."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "security_risks",
"rationale": "The new accounting interacts with critical transaction validity, block resource limits, contract creation, and state-growth protections, substantially changing gas-based security assumptions across multiple components; this warrants the extensive-review score of 3.",
"score": 3,
"uncertainty_note": "The proposal itself says more analysis is needed and does not define any additional mitigation for the independent-meter attack surface.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Rationale > Multidimensional metering; Security Considerations",
"source": "eip.md",
"summary": "EIP-8037 requires EIP-2780, depends on or derives behavior from EIPs 7825 and 8011, and changes EIP-7702 parameters."
},
{
"locator": "Specification",
"source": "supporting/eip-170.md",
"summary": "EIP-170's maximum code size is part of the deployment-size behavior that independent code-deposit metering is intended to preserve."
},
{
"locator": "Specification > Parameters; Set code transaction > Gas Costs",
"source": "supporting/eip-7702.md",
"summary": "EIP-7702 uses both parameters repriced by EIP-8037 in intrinsic charging and refund behavior."
}
],
"exceptional_score_justification": "Not applicable; score is not 4.",
"id": "cross_eip_interactions",
"rationale": "Correct behavior requires coordinated testing across several strongly coupled proposals: account creation and intrinsic gas, delegation costs/refunds, transaction caps, contract size, and the multidimensional metering model. This meets score 3.",
"score": 3,
"uncertainty_note": "The exact inheritance boundary from EIP-8011 is unresolved, increasing coordination risk rather than changing the clear presence of multiple strong interdependencies.",
"under_specified": true
}
],
"eip": 8037,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8037:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"\"A two-dimensional version of EIP-8011\" is required if EIP-8011 is absent, but the proposal does not say which parts of the six-dimensional design are inherited or replaced.",
"CodeExists(keccak256(R), live_state) is not defined precisely enough to settle failed/reverted creation behavior or the boundary between consensus state and client code-storage deduplication.",
"The Backwards Compatibility section refers to \"updated gas parameters,\" \"new calldata cost rules,\" and \"new floor cost values,\" although the specification does not define calldata or floor-cost rules."
],
"provenance": {
"assessed_revision": {
"commit": "c47ae3be2144ac32c0eb9238b01b005b188139e2",
"committed_at": "2025-10-07T21:20:16Z",
"content_sha256": "03b57db0f7031fa1e29d2ae88a46a94cbd33c2c7ec8f52f0e95a531a72f2442f",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8037.md",
"git_blob_sha": "5d0192d26387e5d8f962a2ffa03df5a71a4e6b8c",
"immutable_url": "https://github.com/ethereum/EIPs/blob/c47ae3be2144ac32c0eb9238b01b005b188139e2/EIPS/eip-8037.md",
"information_cutoff_at": "2025-10-16T08:11:36Z",
"path": "EIPS/eip-8037.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8037.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-8037.yaml",
"sha256": "ae29010b277a6267b1d4a9a725dafd045a84964652a516c9e2848f82db562e2b"
},
"supporting_documents": [
"supporting/eip-170.md",
"supporting/eip-2780.md",
"supporting/eip-7702.md",
"supporting/eip-7825.md",
"supporting/eip-8011.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 21,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the sealed historical cutoff, draft EIP-8037 reprices seven state-creation-related gas parameters, adds separate code-deposit gas metering, and discounts deployments whose runtime bytecode already exists. It requires EIP-2780 and explicitly interacts with EIPs 170, 7702, 7825, and 8011.",
"tier": "high",
"title": "State Creation Gas Cost Increase",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"transition_tool_interface_changes",
"edge_boundary_conditions",
"block_syncing_changes",
"encoding_changes_rlp_ssz",
"new_or_modified_transaction_validity_mechanisms",
"new_block_header_fields",
"performance_risks",
"security_risks",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 30,
"minimum": 17
},
"present": true,
"summary": "The proposal requires a two-dimensional gas model but does not normatively define how code_deposit_gas is accumulated, limited, charged, refunded, exposed, or validated at transaction and block boundaries. It also leaves failure/revert lifecycle details for code-existence-based charging implicit. The referenced EIP-8011 model is itself six-dimensional and contains header and validity machinery that EIP-8037 does not explicitly adopt.",
"unresolved_questions": [
"What exact transaction- and block-level limits, fee rules, refund rules, and out-of-gas conditions apply to code_deposit_gas?",
"Does the required two-dimensional EIP-8011 variant inherit max_gas_metered, its block-header encoding, block-validity rule, and base-fee update rule?",
"Must a transition tool expose or accept the second dimension, and if so through which fields or mechanism?",
"How do failed or reverted creations affect CodeExists observations and charges, including repeated creations within one transaction or block?"
]
}
},
"amsterdam:8037:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 30-46",
"source": "eip.md",
"summary": "Seven existing gas parameters are increased and an independent code-deposit-gas meter is introduced alongside ordinary gas."
},
{
"locator": "Specification / Contract deployment cost calculation, lines 48-59",
"source": "eip.md",
"summary": "Deployment charging becomes conditional on live-state code existence and adds warm/cold lookup and runtime hashing charges for CREATE, CREATE2, and creation transactions."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This is anchor 3: it introduces a new multidimensional gas-accounting mechanism and makes it interact with existing creation accounting, while also repricing several existing mechanisms and therefore their gas tests.",
"score": 3,
"uncertainty_note": "The existence of the new mechanism is explicit, although its complete limit and exhaustion semantics are not.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Contract deployment cost calculation, lines 48-59",
"source": "eip.md",
"summary": "Contract creation first checks CodeExists against live state, then applies conditional deposit charging plus a warm/cold access charge and a runtime hash charge; the text expressly covers both CREATE and CREATE2."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "This is anchor 2 because a new state access and gas-charge sequence applies to multiple creation operations. The ordering must be exercised at gas boundaries for both CREATE and CREATE2, rather than for only one opcode.",
"score": 2,
"uncertainty_note": "The draft does not identify which address or code object is warmed, whether the lookup is recorded as an access, or the exact ordering at failure and out-of-gas boundaries.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Multidimensional metering for code deposit gas, lines 44-46",
"source": "eip.md",
"summary": "The only dimensions introduced by this proposal are ordinary gas and code-deposit gas; no blob resource or blob-gas rule is introduced."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "This is anchor 0 because the proposal changes execution and state-creation charging, not blob gas accounting.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 30-55",
"source": "eip.md",
"summary": "The proposal reprices storage-producing operations and introduces an independent code-deposit meter whose charge depends on whether runtime code must newly be stored."
},
{
"locator": "Rationale / Harmonization across state creation, lines 75-89",
"source": "eip.md",
"summary": "State-writing rates are derived from a unit cost of 1,900 gas per new state byte for code, account, storage-slot, and authorization growth."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "This is anchor 3: code deposit is state writing, and the proposal introduces a new independent charging mechanism for it while changing existing state creation costs and their tests.",
"score": 3,
"uncertainty_note": "The draft does not formally define the second meter's budget, exhaustion, fee, or spill relationship with ordinary execution gas.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 34-42",
"source": "eip.md",
"summary": "PER_EMPTY_ACCOUNT_COST and PER_AUTH_BASE_COST are repriced, but no refund rule is added by EIP-8037."
},
{
"locator": "Specification / Behavior, lines 104-124",
"source": "supporting/eip-7702.md",
"summary": "EIP-7702 already defines the refund as the difference between those two parameters when an authority is non-empty."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "This is anchor 0. EIP-8037 changes the numerical inputs to an existing EIP-7702 refund, but it does not introduce a new gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 32-42",
"source": "eip.md",
"summary": "Repricing reaches CREATE, CREATE2, contract-creation transactions, fresh account funding, SELFDESTRUCT, SSTORE, and EIP-7702 delegation."
},
{
"locator": "Specification / Contract deployment cost calculation, lines 48-59",
"source": "eip.md",
"summary": "All deployment paths gain conditional duplicate-code charging, state lookup, and hashing behavior."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "This is anchor 3 because a major and diverse body of pre-existing gas and state-transition tests across opcode, transaction, storage, account, and delegation paths must be reworked rather than only a contrived subset.",
"score": 3,
"uncertainty_note": "The sealed sources do not inventory existing tests, so the exact number of affected vectors is not available; the breadth follows from the listed consensus paths.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Multidimensional metering for code deposit gas, lines 44-53",
"source": "eip.md",
"summary": "Contract creation now produces a separate code-deposit-gas result, which is zero for code already present and proportional to length for new code."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "This is anchor 2 because the broad category of pre-existing contract- creation tests gains a mechanically checkable second-meter invariant in addition to its original state and ordinary-gas results.",
"score": 2,
"uncertainty_note": "The EIP does not say how code_deposit_gas is surfaced to tests, so the exact assertion plumbing and whether every creation vector exposes it are open.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / Multidimensional metering for code deposit gas, lines 44-46",
"source": "eip.md",
"summary": "The state transition must independently meter ordinary gas and code-deposit gas."
},
{
"locator": "Specification / Gas accounting, lines 61-80",
"source": "supporting/eip-8011.md",
"summary": "The referenced multidimensional design tracks a gas-used vector and returns it in addition to scalar gas used from transaction execution."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "This is anchor 2: testing an additional consensus gas dimension requires a new transition-tool mechanism, not merely one unrelated scalar input field.",
"score": 2,
"uncertainty_note": "EIP-8037 never specifies the transition-tool fields or whether the complete EIP-8011 return-vector interface is imported.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Contract deployment cost calculation, lines 44-55",
"source": "eip.md",
"summary": "Tests must express a second gas dimension and distinguish new from pre-existing runtime code, including warm/cold lookup and hash charges."
},
{
"locator": "Rationale / Duplicated bytecode discount, lines 99-104",
"source": "eip.md",
"summary": "The required cases include same-block ordering, exact-code identity, and special handling of empty code."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "This is anchor 2 because reusable expectations or modifiers are needed for code-deposit-gas outcomes and live-state code-existence setup within this EIP's suite; these go beyond writing only ordinary scalar-gas test functions.",
"score": 2,
"uncertainty_note": "The historical text does not describe the test framework, so it is unclear how much of the state setup can already be represented by existing helpers.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Contract deployment cost calculation, lines 50-59",
"source": "eip.md",
"summary": "Duplicate detection is a consensus decision keyed by keccak256 of exact runtime bytecode, and CREATE2 must perform this runtime hash separately from its existing init-code hash."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "This is anchor 1: deployment functionality gains a new consensus use of the well-known Keccak hash, but no novel cryptographic primitive is introduced.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Contract deployment cost calculation, lines 48-59",
"source": "eip.md",
"summary": "Charging branches on new versus duplicate code, warm versus cold access, runtime length rounding, and CREATE versus CREATE2 hashing."
},
{
"locator": "Rationale / Duplicated bytecode discount, lines 99-104",
"source": "eip.md",
"summary": "Same-block first/subsequent deployments, exact byte identity, and empty code are called out as distinct boundary cases."
},
{
"locator": "Specification, lines 14-21",
"source": "supporting/eip-170.md",
"summary": "Contract creation also has a maximum-code-size boundary at 24,576 bytes."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "This is anchor 3. Multiple boundary-prone mechanisms combine multiplicatively, especially code existence, same-block order, warmness, creation path, runtime length, success or failure, and meter exhaustion.",
"score": 3,
"uncertainty_note": "Exact exhaustion semantics of the independent meter are unspecified, which increases uncertainty about the final boundary matrix without reducing its evident breadth.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-59",
"source": "eip.md",
"summary": "The specified changes concern gas parameters, an internal meter, and contract-deployment charging; no block RLP validation rule is stated."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "This is anchor 0 on the primary reading because EIP-8037 introduces no explicit block-RLP validation mechanism requiring sync tests.",
"score": 0,
"uncertainty_note": "A full two-dimensional import of EIP-8011 could imply a header extension, but EIP-8037 does not state that import and says code-deposit cost is outside the block gas limit.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-59",
"source": "eip.md",
"summary": "No Engine API endpoint, payload field, or communication mechanism appears among the specified parameter, meter, and deployment changes."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "This is anchor 0 because the proposal does not specify any Engine API field or new Engine API communication mechanism.",
"score": 0,
"uncertainty_note": "The omitted block-level semantics of the second meter leave open whether a later specification would need to carry anything through execution payloads.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 30-46",
"source": "eip.md",
"summary": "The proposal modifies protocol gas parameters and metering and does not introduce a privileged contract address or system-contract code."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "This is anchor 0 because no system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 30-42",
"source": "eip.md",
"summary": "The affected objects are generic creation, account, storage, destruction, and delegation operations; no pre-existing system contract is identified."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "This is anchor 0 because the proposal specifies neither a direct system- contract modification nor an identifiable indirect effect on one.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 34-42",
"source": "eip.md",
"summary": "The operation table only reprices existing CREATE, CREATE2, SELFDESTRUCT, and SSTORE paths plus existing transaction and delegation paths."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This is anchor 0 because no opcode is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Contract deployment cost calculation, lines 48-59",
"source": "eip.md",
"summary": "CREATE and CREATE2 gain conditional deposit, lookup, and hash charges, but the described externally observable distinction is their gas charging."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "This is anchor 0 under this row's explicit exclusion of gas changes. At sufficient gas, the deployed account still receives the exact runtime code; the new-versus-duplicate distinction changes charging and code-object storage linkage rather than an opcode result.",
"score": 0,
"uncertainty_note": "The draft describes linking an account to an existing code object, but does not specify a non-gas state-transition result distinct from the normal codeHash outcome.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-59",
"source": "eip.md",
"summary": "The complete specification adds gas and deployment rules and identifies no new precompile address or callable precompile behavior."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "This is anchor 0 because no precompile is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 30-42",
"source": "eip.md",
"summary": "No precompile appears in the complete list of repriced operations or gas parameters."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "This is anchor 0 because neither precompile logic nor a precompile gas schedule is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-59",
"source": "eip.md",
"summary": "The specification defines parameter and execution-accounting changes but no transaction, block, or interface RLP/SSZ encoding change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "This is anchor 0 on the primary reading because EIP-8037 does not introduce a transaction-, block-, or interface-level encoding change.",
"score": 0,
"uncertainty_note": "The reference to a two-dimensional EIP-8011 variant does not say whether EIP-8011's header extension is imported; importing it would change this row.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 34-42",
"source": "eip.md",
"summary": "The proposal reprices existing contract-creation transactions and EIP-7702 delegation rather than defining a new typed transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "This is anchor 0 because no new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations / Mispricing with respect to ETH transfers, lines 147-151",
"source": "eip.md",
"summary": "EIP-8037 requires the EIP-2780 rule that adds the repriced GAS_NEW_ACCOUNT to intrinsic gas for value transfers to fresh accounts."
},
{
"locator": "Specification / New-account surcharge and Intrinsic gas computation, lines 68-108",
"source": "supporting/eip-2780.md",
"summary": "The required EIP defines state-dependent conditions under which existing transaction types add GAS_NEW_ACCOUNT during intrinsic-gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "This is anchor 2 because the modified intrinsic-gas calculation affects existing transaction-validity vectors and requires targeted updates across transaction types, but the localized predicate does not itself require a redesign of the whole testing infrastructure.",
"score": 2,
"uncertainty_note": "The separate code-deposit meter's relationship to transaction gas limits and out-of-gas validity is not formally defined and could expand this row.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Security Considerations / Independent metering for code deposit costs, lines 153-155",
"source": "eip.md",
"summary": "The draft says code-deposit cost is outside traditional metering and does not contribute to the block gas limit, and it specifies no header field."
},
{
"locator": "Specification / Block header extension, lines 82-97",
"source": "supporting/eip-8011.md",
"summary": "The referenced full EIP-8011 design does define max_gas_metered as a new header field, exposing an unresolved difference from EIP-8037's text."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "This is anchor 0 on the best-supported EIP-8037 reading: no new header field is specified, and its uncapped code-deposit meter does not directly require the referenced EIP-8011 max field.",
"score": 0,
"uncertainty_note": "It is unresolved whether “a two-dimensional version of EIP-8011” imports the EIP-8011 header field despite EIP-8037's statement that code-deposit cost does not contribute to the block gas limit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameter changes, lines 30-42",
"source": "eip.md",
"summary": "Activation switches gas parameter values; no one-time state migration or modification of an existing internal variable is specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "This is anchor 0 because ordinary fork-gated rule activation is used without a special fork-block state or internal-variable modification.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations / Independent metering for code deposit costs, lines 153-155",
"source": "eip.md",
"summary": "Because deposit cost is outside block and transaction limits, the draft warns that an attacker could create very large contracts that stress the network and explicitly calls for more benchmarking and analysis."
},
{
"locator": "Specification / Contract deployment cost calculation, lines 48-59",
"source": "eip.md",
"summary": "Every deployment adds a live-state existence lookup and runtime hashing, including a separate runtime hash for CREATE2."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "This is anchor 3: the uncapped meter and size-dependent hashing/state work cannot be validated wholly in isolation and have complex interactions with existing transaction limits, block limits, contract-size bounds, state storage, and deployment performance.",
"score": 3,
"uncertainty_note": "The proposal itself says benchmarking and possible mitigations remain to be determined, so the magnitude is open even though the risk class is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 143-155",
"source": "eip.md",
"summary": "The draft identifies application usability and pricing-bypass concerns and warns that uncapped very large contract creation could be exploited to stress the network, with mitigations still undetermined."
},
{
"locator": "Rationale / Multidimensional metering, lines 91-97",
"source": "eip.md",
"summary": "The independent meter deliberately changes the interaction between code deposit, EIP-7825's transaction cap, and ordinary gas accounting."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "This is anchor 3 because the mechanism touches several critical components— transaction and block resource bounds, contract deployment, persistent state, gas estimation, and denial-of-service protection—and requires broad security review, adversarial boundary tests, and performance fuzzing.",
"score": 3,
"uncertainty_note": "The absence of defined meter limits or mitigations leaves the exact attack envelope unresolved.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 18-20",
"source": "eip.md",
"summary": "The proposal observes that duplicate code may not be stored again by clients even though this implementation detail previously had no charging consequence."
},
{
"locator": "Specification / Contract deployment cost calculation, lines 48-55",
"source": "eip.md",
"summary": "CodeExists against live state now determines a consensus gas charge, but the meaning, access target, and lifecycle of that predicate are not fully defined."
},
{
"locator": "Rationale and Security Considerations, lines 91-104 and 153-155",
"source": "eip.md",
"summary": "The draft simultaneously refers to EIP-8011-style multidimensional metering and says deposit cost contributes to neither the transaction nor block gas limit, without specifying complete reconciliation semantics."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "This is anchor 3. Previously unobservable code-storage/deduplication details become consensus-visible through gas charging, while constructible cases involving reverts, same-transaction lifecycle, warmness, empty code, and second-meter exhaustion require client agreement before stable vectors can be baselined.",
"score": 3,
"uncertainty_note": "The draft gives an intended same-block and exact-bytecode reading, but does not settle all observable state-lifecycle and multidimensional-meter cases.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Rationale, lines 1-11 and 63-97",
"source": "eip.md",
"summary": "EIP-2780 is required; the pricing table and meter design directly use the EIP-170 size limit, EIP-7702 delegation costs, EIP-7825 transaction cap, and EIP-8011 multidimensional model."
},
{
"locator": "Security Considerations / Mispricing with respect to ETH transfers, lines 147-155",
"source": "eip.md",
"summary": "EIP-2780 is needed to prevent bypassing the new-account charge, while the independent meter changes the protection afforded by transaction and block gas bounds."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
170,
2780,
7702,
7825,
8011
],
"rationale": "This is anchor 3 because five identified EIPs participate in size-boundary, intrinsic-gas, delegation-refund, transaction-cap, and multidimensional- metering behavior that needs coordinated tests. There are two EIPs beyond the first three, so the uncapped row's +1-per-three rule adds no bonus.",
"score": 3,
"uncertainty_note": "EIP-170 is a bounded size interaction rather than a dependency, but it still supplies a coordinated contract-size boundary used by this proposal.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8037,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8037:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"“Derived from” and “consistent with” EIP-8011 do not establish which of that draft's transaction, block, header, and base-fee mechanics EIP-8037 imports.",
"The Backwards Compatibility section refers to “new calldata cost rules” and “floor cost values,” although the EIP's specification defines state-creation and code-deposit changes rather than a calldata floor.",
"The test matrix for the new lookup is multiplicative across CREATE/CREATE2, new/duplicate/empty runtime code, warm/cold status, same-block order, success/revert, and ordinary-gas versus code-deposit-gas boundaries."
],
"provenance": {
"assessed_revision": {
"commit": "c47ae3be2144ac32c0eb9238b01b005b188139e2",
"committed_at": "2025-10-07T21:20:16Z",
"content_sha256": "03b57db0f7031fa1e29d2ae88a46a94cbd33c2c7ec8f52f0e95a531a72f2442f",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8037.md",
"git_blob_sha": "5d0192d26387e5d8f962a2ffa03df5a71a4e6b8c",
"immutable_url": "https://github.com/ethereum/EIPs/blob/c47ae3be2144ac32c0eb9238b01b005b188139e2/EIPS/eip-8037.md",
"information_cutoff_at": "2025-10-16T08:11:36Z",
"path": "EIPS/eip-8037.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8037.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-8037.yaml",
"sha256": "87330dd8901ecba9e4d5fc02d6147613dbd5b60027254480ccf7e76a6cce0695"
},
"supporting_documents": [
"supporting/eip-170.md",
"supporting/eip-2780.md",
"supporting/eip-7702.md",
"supporting/eip-7825.md",
"supporting/eip-8011.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 35,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this Draft proposed repricing seven existing state-creation-related gas parameters spanning contract creation, new accounts, storage, self-destruction, and EIP-7702 delegation. It also made contract-deployment charging depend on whether the exact runtime bytecode already existed in live state, adding warm/cold lookup and hashing costs while waiving the code-deposit charge for duplicates. To avoid the per-transaction cap constraining contract size, it required an independent two-dimensional gas/code-deposit-gas meter derived from EIP-8011 and relied on EIP-2780 to close the fresh-account funding bypass.",
"tier": "high",
"title": "State Creation Gas Cost Increase",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"state_gas_accounting_changes",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"block_syncing_changes",
"engine_api_changes",
"encoding_changes_rlp_ssz",
"new_or_modified_transaction_validity_mechanisms",
"new_block_header_fields",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 45,
"minimum": 29
},
"present": true,
"summary": "Material behavior is missing or internally unresolved. The draft does not define the code_deposit_gas meter's limit, exhaustion, fee, refund/revert, block aggregation, or transition-tool exposure, and its EIP-8011 reference conflicts with the statement that this gas contributes to neither the transaction nor block gas limit. CodeExists is also not defined across same-transaction creations, reverts, deletion or emptiness, and the text does not identify what becomes warm or when the lookup is recorded relative to charging and failure.",
"unresolved_questions": [
"Is code_deposit_gas charged toward the transaction gas limit, a separate limit, no limit, or a spill path, and how is it converted into the fee paid?",
"Does the required two-dimensional EIP-8011 variant import max_gas_metered, the header extension, base-fee rule, and block-validity rule, or only an internal execution counter?",
"What precise live-state condition makes CodeExists true after creation, revert, deletion, empty-code return, or another creation earlier in the same transaction?",
"What state object is warm or cold for storage_access_cost, is that access recorded, and at what point relative to gas charging and possible failure?",
"How are code_deposit_gas and its failure or success outcome represented in the transition-tool and test-framework interfaces?"
]
}
},
"amsterdam:8038:human:r1": {
"checklist": {
"input_alignment": "substantive_drift",
"parser_notes": [
"Blank cells are interpreted as zero only because the published total exactly equals the sum of every nonblank parsed contribution."
],
"published_tier": "high",
"published_total": 20,
"recomputed_tier": "high",
"recomputed_total": 20,
"timing_exposure": "possible_exposure"
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Updated mechanism introduced to cold and warm account accesses",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "`GAS_STORAGE_CLEAR_REFUND` is modified.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "11 opcodes affected",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Many edge-case and boundary condition prone mechanisms",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Access list cost change which affects type 1 and type 2 intrinsic gas.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "New values are unspecified, and the EIP does not have current benchmarking numbers yet",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Any time gas costs are modified introduces inherent risk. Better specification may bring this number down.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Strong interactions with EIP-8032, EIP-2926, EIP-2929, EIP-2930/EIP-1559,and EIP-7928.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8038,
"fork": "amsterdam",
"id": "amsterdam:8038:human:r1",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "a691b7ad1a10043c9ac6cc1853f87d8cde48a35a",
"committed_at": "2025-10-24T09:51:29Z",
"content_sha256": "d4f4e83f2ba6be96d30c16bc1c95f9445f013295d4e656008ca3162fa95151d7",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8038.md",
"git_blob_sha": "cdbf7e8c47411eb5dcd9ae3c438616b4c3465552",
"immutable_url": "https://github.com/ethereum/EIPs/blob/a691b7ad1a10043c9ac6cc1853f87d8cde48a35a/EIPS/eip-8038.md",
"information_cutoff_at": null,
"note": "EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.",
"path": "EIPS/eip-8038.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8038.md"
},
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-8038.yaml",
"sha256": "a106b274163b233a8fcd478522578405af5373a6819ab29a7f0e09111e765751"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "3b1cc8521093ce2a7381a3da8341cf33a2452fad",
"committed_at": "2025-11-07T22:10:24Z",
"content_sha256": "cf9187ccf3b63b985d4e67a1c5d9bf48aa050d0ef0a1eb4b841ba99e89fb858a",
"git_blob_sha": "284c3213221ab59979604cc37e7cd83258c56889",
"immutable_url": "https://github.com/ethspecs/pm/blob/3b1cc8521093ce2a7381a3da8341cf33a2452fad/complexity_assessments/EIPs/EIP-8038.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-8038.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 20,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "high",
"title": "State-access gas cost update",
"under_specification": null
},
"amsterdam:8038:llm:r1": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, parameter table and EXTCODESIZE/EXTCODECOPY pseudocode",
"source": "eip.md",
"summary": "Updates GAS_STORAGE_UPDATE, GAS_COLD_SLOAD, GAS_COLD_ACCOUNT_ACCESS, and GAS_WARM_ACCESS, and changes access-gas calculation for two existing opcodes."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This updates the existing EVM gas-accounting mechanism rather than introducing a separate accounting mechanism, matching score 1.",
"score": 1,
"uncertainty_note": "The type of change is explicit, but every replacement parameter value is TBD.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "The proposal is limited to state-access gas parameters and EXTCODESIZE/EXTCODECOPY access charges; it specifies no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting change is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specified changes are upfront state-access charges and contain no refund rule or refund-counter change."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, parameter table",
"source": "eip.md",
"summary": "Reprices SSTORE, SLOAD, CALL-family operations, BALANCE, SELFDESTRUCT, and EXT-family operations, including the shared warm-access charge."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Identifies the repricing as backwards-incompatible and requires gas-estimation handling to change."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Exact gas expectations and out-of-gas boundaries change across several pervasive and diverse opcode families, so a major and varied body of pre-existing execution tests is affected.",
"score": 3,
"uncertainty_note": "The snapshot provides no test cases and leaves all new values TBD, so the exact regression count cannot be established.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes EVM gas parameters and opcode gas calculation without specifying a new transition-tool field or interface mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is required by the stated design.",
"score": 0,
"uncertainty_note": "The document does not discuss transition-tool integration; the zero follows from the bounded specification, not an explicit interface statement.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "Only gas constants and address-access charging are changed; no cryptographic primitive or cryptographic behavior is specified."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, EXTCODESIZE/EXTCODECOPY pseudocode",
"source": "eip.md",
"summary": "Charges differ at the warm/cold membership boundary and the cold branch mutates accessed_addresses."
},
{
"locator": "Rationale, Interaction with EIP-8032 and Interaction with EIP-2926",
"source": "eip.md",
"summary": "Parameter selection changes around EIP-8032's activation threshold, while EIP-2926 removes the extra EXTCODESIZE access charge."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The warm/cold path and the two fork-combination conditions create multiple boundary-prone mechanisms, but the sealed text does not establish that any one needs an elevated number of cases.",
"score": 2,
"uncertainty_note": "Activation ordering and final constants are unresolved, limiting enumeration of exact boundary cases.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal contains no block-RLP structure or validation change."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new RLP validation mechanism requiring syncing tests is introduced.",
"score": 0,
"uncertainty_note": "The required supporting EIPs have their own structures, but those changes are not introduced by this proposal and are accounted for under cross-EIP interactions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No Engine API field, endpoint, or communication mechanism appears in the stated gas repricing."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No new Engine API field or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "EIP-7928 specifies Engine API changes, but EIP-8038 only discusses its benchmark implications and does not introduce those API changes.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal specifies only EVM gas parameter and calculation changes, with no Engine API encoding content."
}
],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "Conservatively, the row label provides no basis for a positive score because no Engine API encoding change is stated.",
"score": 0,
"uncertainty_note": "The historical rubric has no dedicated definition for this row, so the score is based only on the label and global score range.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "The design modifies gas prices and does not create or call a new system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contract is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No pre-existing system contract code, state, or system action is identified as a target of the repricing."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The sealed proposal does not introduce a direct or discernible indirect modification to a pre-existing system contract.",
"score": 0,
"uncertainty_note": "Ordinary gas consumption by unspecified system-contract execution is not documented and is not treated as evidence of a system-contract modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, parameter table",
"source": "eip.md",
"summary": "The proposal lists only existing opcode families whose gas charges change."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, parameter table and EXTCODESIZE/EXTCODECOPY pseudocode",
"source": "eip.md",
"summary": "Existing opcodes receive changed gas charges, but their non-gas behavior is not modified."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The row definition expressly excludes gas changes; no pre-existing opcode behavior is otherwise modified or deprecated.",
"score": 0,
"uncertainty_note": "The EXTCODESIZE/EXTCODECOPY formula change remains a gas-accounting change and is scored in the gas row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification",
"source": "eip.md",
"summary": "No new precompile is named or specified."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, parameter table",
"source": "eip.md",
"summary": "The changed account-access parameters apply to listed EVM operations; no precompile logic or precompile gas schedule is changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "A CALL's generic account-access charge is distinct from a precompile's own gas schedule under this row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The EIP changes gas constants and access charging without specifying a transaction, block, or interface encoding change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other transaction/block/interface encoding change is introduced by EIP-8038.",
"score": 0,
"uncertainty_note": "EIP-2926 and EIP-7928 contain encoding changes of their own; those are dependency interactions rather than changes introduced here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal reprices execution for existing transactions and does not define a transaction envelope or new transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None material within the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Backwards Compatibility",
"source": "eip.md",
"summary": "The changes concern execution gas for state-access operations and gas estimation, not transaction validity rules or intrinsic gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity mechanism or intrinsic-gas calculation is changed.",
"score": 0,
"uncertainty_note": "Different execution gas can change out-of-gas outcomes, but the rubric's validity row is limited to validity rules and intrinsic gas.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No block or block-header field is added by the gas repricing."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "The block_access_list_hash in required EIP-7928 is not introduced by EIP-8038 and is handled as a cross-EIP dependency.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, opening sentence and parameter table",
"source": "eip.md",
"summary": "Upon activation, four existing gas-model parameters are updated from their current values."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "States that the backwards-incompatible repricing requires a scheduled network upgrade."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Existing protocol gas parameters, which are internal execution variables, are modified at fork activation, matching the row's binary score-3 definition.",
"score": 3,
"uncertainty_note": "There is no one-time state migration; the score rests on the rubric's express inclusion of internal-variable modifications. The activation timestamp and final values are unspecified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Rationale, Benchmarking",
"source": "eip.md",
"summary": "The repricing responds to state-growth-driven slowdown, requires stateful benchmarks, and cannot yet supply finalized numbers."
},
{
"locator": "Rationale, Interaction with EIP-7928 and Interaction with EIP-8032",
"source": "eip.md",
"summary": "Benchmark assumptions omit EIP-7928 optimizations and parameterization changes around EIP-8032's depth-based scaling."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "State-access pricing cannot be validated fully in isolation and has complex interactions with client state performance and the two optimization/pricing proposals, while affecting pervasive existing performance behavior.",
"score": 3,
"uncertainty_note": "The stateful benchmarks are still in development and neither measurements nor final parameters are present.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The proposal changes resource pricing because state growth has slowed state-access operations relative to their existing prices."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Warns that higher costs may affect application usability and says more analysis is needed."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The repricing alters the resource-pricing assumptions of the state-access component and many callers, warranting targeted security and compatibility review, but the mechanism is still localized to gas accounting rather than multiple substantially altered security subsystems.",
"score": 2,
"uncertainty_note": "Without final values or the promised analysis, the magnitude of underpricing, denial-of-service protection, and application failure risks cannot be bounded.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter, requires",
"source": "eip.md",
"summary": "Explicitly requires EIP-2926, EIP-7928, and EIP-8032."
},
{
"locator": "Rationale, Interaction with EIP-8032, EIP-2926, and EIP-7928",
"source": "eip.md",
"summary": "EIP-8032 changes parameter assumptions, EIP-2926 changes whether EXTCODESIZE receives the extra charge, and EIP-7928 changes benchmarking assumptions."
},
{
"locator": "Specification, Code merkleization",
"source": "supporting/eip-2926.md",
"summary": "Adds codeSize to account records, supplying the single-read behavior on which EIP-8038's EXTCODESIZE exception depends."
},
{
"locator": "Specification, Constants and parameters and Gas cost changes",
"source": "supporting/eip-8032.md",
"summary": "Defines the still-TBD ACTIVATION_THRESHOLD and depth-based SSTORE pricing that EIP-8038 uses to choose its assumptions."
},
{
"locator": "Abstract and Rationale, BAL Design Choice",
"source": "supporting/eip-7928.md",
"summary": "Describes parallel disk reads and transaction execution optimizations that EIP-8038 says its initial benchmarks will omit."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "The proposal has strong behavioral and calibration interdependencies with three required EIPs, including two that directly select different gas formulas or parameter assumptions, requiring extensive coordinated combination testing.",
"score": 3,
"uncertainty_note": "The text simultaneously declares EIP-8032 required and specifies before/after-EIP-8032 cases; fork ordering and the final combined configuration are unresolved.",
"under_specified": true
}
],
"eip": 8038,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8038:llm:r1",
"mode": "retrospective",
"notable_ambiguities": [
"The historical checklist includes Engine API encoding changes but supplies no definition; that row was scored conservatively from its label with low confidence.",
"The front matter requires EIP-2926, EIP-7928, and EIP-8032, while the rationale describes before/after-EIP-8032 cases and an EIP-2926-dependent exception without a precise activation matrix.",
"Backwards Compatibility refers to updated calldata cost rules and floor cost values, although neither term is defined by this state-access repricing specification.",
"The specification contains a TODO marker, the benchmarking rationale is unfinished, and every new parameter value is TBD."
],
"provenance": {
"assessed_revision": {
"commit": "2023b9c1519e390ef0b97ac96df796a154d9223d",
"committed_at": "2025-10-08T11:34:45Z",
"content_sha256": "8b5fa9f486beac8ab5bb214728d6f81f8b13ff610e4dab114e392c8dd4a3b1d0",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8038.md",
"git_blob_sha": "63255d55d9fcf870dbdcc032e34a2b7c59ee8e55",
"immutable_url": "https://github.com/ethereum/EIPs/blob/2023b9c1519e390ef0b97ac96df796a154d9223d/EIPS/eip-8038.md",
"information_cutoff_at": "2025-10-16T08:11:36Z",
"path": "EIPS/eip-8038.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8038.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-8038.yaml",
"sha256": "0872ca686022903b951e1c0458ac1e6b646b040e63797b248f12c96aecd46ba7"
},
"supporting_documents": [
"supporting/eip-2926.md",
"supporting/eip-7928.md",
"supporting/eip-8032.md"
]
},
"role": "historical_rubric_rerun",
"rubric_revision": 1,
"score": 17,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "The sealed Draft reprices existing state-access gas constants and adds an extra warm-access charge to EXTCODESIZE and EXTCODECOPY, with behavior coordinated with EIP-2926, EIP-7928, and EIP-8032; the numerical schedule and supporting benchmarks are not yet finalized.",
"tier": "medium",
"title": "State-access gas cost update",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 19,
"minimum": 12
},
"present": true,
"summary": "All four replacement gas values, their increases, and the benchmarking rationale are TBD; the benchmark suite is still in development, and the required-EIP activation/configuration relationships are not made operationally precise.",
"unresolved_questions": [
"What are the final values for GAS_STORAGE_UPDATE, GAS_COLD_SLOAD, GAS_COLD_ACCOUNT_ACCESS, and GAS_WARM_ACCESS, and what measurements justify them?",
"Is EIP-8038 intended to activate only with all three required EIPs, and if so, why are before/after-EIP-8032 parameter cases specified?",
"How is the EXTCODESIZE formula selected when EIP-2926 is or is not active, and which fork combinations must be tested?",
"How will stateful benchmarks account for EIP-7928 optimizations, state size, client database behavior, and EIP-8032 depth scaling?"
]
}
},
"amsterdam:8038:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "The proposal updates four existing gas-model parameters and revises the EXTCODESIZE/EXTCODECOPY charge to add one existing warm-access cost."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This updates the existing EVM warm/cold gas-accounting mechanism rather than introducing a separate accounting mechanism, matching anchor 1.",
"score": 1,
"uncertainty_note": "The numerical values are TBD, but that does not change the mechanism-level classification.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 37-45",
"source": "eip.md",
"summary": "The pseudocode retains the warm/cold accessed-address branch and changes the amount assigned to access_gas_cost for two opcodes."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state access is moved and no new rule changes where gas is charged relative to a state access; only charge amounts are revised.",
"score": 0,
"uncertainty_note": "The pseudocode does not show the eventual gas-deduction point, but the text states no ordering change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-45",
"source": "eip.md",
"summary": "The complete described change concerns state-access EVM charges and does not introduce or alter blob gas."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 26-37",
"source": "eip.md",
"summary": "GAS_STORAGE_UPDATE is repriced as part of the ordinary EVM gas model for SSTORE; no StateGasCosts schedule, state-byte rate, block state-gas budget, reservoir, or spill path is specified."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal changes execution gas for state-accessing opcodes, not the rubric's separate state-gas accounting system for writing state.",
"score": 0,
"uncertainty_note": "The parameter name includes \"STORAGE_UPDATE\", but the proposal consistently places it in the existing EVM gas model and defines no separate state gas.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "The specified changes are upfront operation charges; no refund rule or refund counter change is described."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-45",
"source": "eip.md",
"summary": "Existing gas charges change across SSTORE, SLOAD, all call-family opcodes, BALANCE, SELFDESTRUCT, and EXT-family opcodes, with a distinct formula for EXTCODESIZE and EXTCODECOPY."
},
{
"locator": "Backwards Compatibility, lines 74-83",
"source": "eip.md",
"summary": "The EIP calls the repricing backwards incompatible and requires gas estimation behavior to account for it."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A major and diverse set of existing state-access and exact-gas/OOG tests must be re-baselined across several opcode families, matching anchor 3.",
"score": 3,
"uncertainty_note": "The package contains no test inventory, and TBD constants prevent counting precisely which existing gas-limit vectors change outcome.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "The proposal changes expected gas charges but creates no additional output, commitment, or state property that unrelated tests must newly assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing gas tests need changed expectations, not an additional invariant on tests that are unrelated to this EIP.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 74-83",
"source": "eip.md",
"summary": "The only interfaces called out are wallet and node RPC gas estimation; no field or mechanism is added to the state transition-tool interface."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface change is required by the text.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 26-45",
"source": "eip.md",
"summary": "The change consists of gas constants and an existing warm/cold conditional charge, expressible with ordinary opcode execution and gas assertions."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing gas and opcode test primitives suffice.",
"score": 0,
"uncertainty_note": "The historical EIP supplies no test plan, but nothing specified requires a new expectation or modifier abstraction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-45",
"source": "eip.md",
"summary": "The proposal is limited to gas repricing and contains no cryptographic primitive or cryptographic behavior change."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-45",
"source": "eip.md",
"summary": "Four gas parameters span several opcode families, while EXTCODESIZE and EXTCODECOPY have separate warm and cold branches with an added warm charge."
},
{
"locator": "Interaction with EIP-8032, lines 59-64",
"source": "eip.md",
"summary": "SSTORE/SLOAD parameter calibration has distinct before/after-EIP-8032 cases around an activation threshold and depth-scaled cost regime."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Exact-gas boundaries must be exercised across multiple opcode families and warm/cold branches, and the EXTCODECOPY and conditional EIP-8032 cases create an elevated test matrix, matching anchor 3.",
"score": 3,
"uncertainty_note": "Missing constants prevent enumerating the exact boundary values, and final fork composition controls whether the EIP-8032 branch is active.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 24-45 and 74-83",
"source": "eip.md",
"summary": "The EIP changes execution gas and gas estimation but specifies no block RLP field or block-validation rule used during syncing."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 74-83",
"source": "eip.md",
"summary": "The proposal mentions eth_estimateGas RPC handling but no Engine API field, endpoint, or execution/consensus communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-45",
"source": "eip.md",
"summary": "The complete feature is a gas-schedule update and does not introduce a contract address, code deployment, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "The affected entities are opcode gas parameters and two opcode formulas; no pre-existing system contract code, state, or behavior is identified."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or specified indirect system-contract modification occurs.",
"score": 0,
"uncertainty_note": "Generic execution-gas changes can affect any contract invocation, but the EIP identifies no system-contract-specific effect warranting this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-45",
"source": "eip.md",
"summary": "The table and formula refer only to pre-existing opcode families and add no opcode number or new operation."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-45",
"source": "eip.md",
"summary": "SSTORE, SLOAD, call-family, BALANCE, SELFDESTRUCT, and EXT-family operations retain their functional behavior while only their gas charges change."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The rubric expressly excludes gas-only changes from the modified-opcodes anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-45",
"source": "eip.md",
"summary": "No precompile address, input processing rule, or new precompile gas schedule is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-45",
"source": "eip.md",
"summary": "The call-family account-access overhead changes generally, but no existing precompile's own logic or gas schedule is modified."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "Calls to precompile addresses may experience generic call overhead, but that is an opcode access charge rather than a precompile gas-schedule change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "The specification changes numeric gas parameters and a charge formula, not transaction, block, or interface serialization."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface-level encoding change is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-45",
"source": "eip.md",
"summary": "The proposal applies during execution of existing opcodes and defines no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 74-83",
"source": "eip.md",
"summary": "The stated compatibility impact is execution gas estimation and possible failed transactions from underestimation, not a validity or intrinsic-gas rule for any transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Execution-time opcode repricing does not modify transaction validity or intrinsic gas calculation under this anchor.",
"score": 0,
"uncertainty_note": "Higher execution charges can change whether execution runs out of gas, but that is not a transaction validity mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "Activation updates gas-model parameters only; no block-body or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 26-37 and 74-76",
"source": "eip.md",
"summary": "A scheduled upgrade selects revised gas parameters, with no activation-block state mutation, migration, or pre-existing internal-variable modification."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork selection of a gas schedule is not a new activation mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale - Benchmarking, lines 47-53",
"source": "eip.md",
"summary": "Final values depend on stateful benchmarks that were still in development, so the proposal had neither finalized numbers nor completed calibration."
},
{
"locator": "Interactions with EIP-8032, EIP-2926, and EIP-7928, lines 59-72",
"source": "eip.md",
"summary": "Calibration and even one opcode formula vary with storage-depth pricing, code layout, and BAL client optimizations; initial benchmarks explicitly omit the BAL optimizations."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance validation cannot be reduced to a context-free microbenchmark: it is stateful, affects a broad existing benchmark surface, and has complex interactions with three other mechanisms, matching anchor 3.",
"score": 3,
"uncertainty_note": "Benchmark methodology and results were not present, so the magnitude of the performance-benchmark disruption cannot be quantified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 18-22",
"source": "eip.md",
"summary": "The repricing is motivated by state growth degrading state-access performance and by different database-read costs across existing opcodes."
},
{
"locator": "Backwards Compatibility and Security Considerations, lines 74-87",
"source": "eip.md",
"summary": "Incorrect estimation can lead to failed transactions, and the proposal flags unresolved usability effects across applications and user behavior."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The change touches several existing execution and estimation components and slightly alters resource-pricing assumptions, requiring targeted review and boundary testing; it does not introduce the broad new security mechanism required for anchor 3.",
"score": 2,
"uncertainty_note": "The security section calls for more analysis and gives no threat model or quantitative application-impact results.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 26-35",
"source": "eip.md",
"summary": "Every new gas value and increase is TBD, followed by an explicit TODO, so clients cannot derive consensus gas results or exact-gas test vectors."
},
{
"locator": "Rationale - Benchmarking, lines 47-53",
"source": "eip.md",
"summary": "The document states that final numbers await stateful benchmark data and retains another TODO."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Client agreement is required before gas outcomes can be baselined, but the missing decisions are localized to parameters and conditional formulas rather than making previously unobservable behavior consensus-critical.",
"score": 2,
"uncertainty_note": "The intended direction of every change is clear, but no authoritative numeric result exists for any affected exact-gas case.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Motivation, lines 1-12 and 18-22",
"source": "eip.md",
"summary": "The EIP declares requirements on 2926, 7928, and 8032 and explicitly reprices the state-access cost model previously raised by EIP-2929."
},
{
"locator": "Interactions with EIP-8032, EIP-2926, and EIP-7928, lines 59-72",
"source": "eip.md",
"summary": "EIP-8032 changes parameter calibration, EIP-2926 removes the extra EXTCODESIZE read/charge, and EIP-7928 introduces optimizations omitted from the initial benchmarks."
},
{
"locator": "Code merkleization, lines 44-68",
"source": "supporting/eip-2926.md",
"summary": "EIP-2926 adds codeSize to contract accounts and separately changes code storage and creation costs, confirming why EXTCODESIZE treatment differs."
},
{
"locator": "Abstract and Scope and Inclusion, lines 13-15 and 96-118",
"source": "supporting/eip-7928.md",
"summary": "EIP-7928 makes executed account accesses, including EXTCODESIZE, EXTCODECOPY, calls, SLOAD-related storage, and SELFDESTRUCT targets, part of a consensus block access list."
},
{
"locator": "Specification - Gas cost changes, lines 54-62",
"source": "supporting/eip-8032.md",
"summary": "EIP-8032 makes SSTORE cost depend on an account depth field and an activation threshold, the regime for which EIP-8038 conditionally calibrates costs."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2926,
2929,
7928,
8032
],
"rationale": "The proposal has strong, design-level dependencies across three contemporaneous EIPs and modifies the earlier EIP-2929 cost model. Formula selection and benchmark baselines therefore require coordinated cross-EIP testing, matching anchor 3; four interacting EIPs do not trigger the uncapped +1 increment.",
"score": 3,
"uncertainty_note": "Fork scheduling is unresolved in the text, and the exact combined parameter values are TBD.",
"under_specified": true,
"unidentified_interactions": []
}
],
"eip": 8038,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8038:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The abstract names three raised base costs, while the specification table also changes GAS_WARM_ACCESS.",
"The front matter requires EIP-8032, yet the rationale says EIP-8032 was not scheduled and defines both before- and after-EIP-8032 calibration cases.",
"The backwards-compatibility text refers to \"calldata cost rules\" and \"floor cost values\" even though the specification is state-access opcode repricing.",
"EIP-2926 is said to preserve the old EXTCODESIZE formula, but the combined EXTCODECOPY behavior is not similarly settled."
],
"provenance": {
"assessed_revision": {
"commit": "2023b9c1519e390ef0b97ac96df796a154d9223d",
"committed_at": "2025-10-08T11:34:45Z",
"content_sha256": "8b5fa9f486beac8ab5bb214728d6f81f8b13ff610e4dab114e392c8dd4a3b1d0",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8038.md",
"git_blob_sha": "63255d55d9fcf870dbdcc032e34a2b7c59ee8e55",
"immutable_url": "https://github.com/ethereum/EIPs/blob/2023b9c1519e390ef0b97ac96df796a154d9223d/EIPS/eip-8038.md",
"information_cutoff_at": "2025-10-16T08:11:36Z",
"path": "EIPS/eip-8038.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8038.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-8038.yaml",
"sha256": "4f61b3f1be97997d16438d37eaf4b7600b6148960300bd9b3cb41fd8b5027106"
},
"supporting_documents": [
"supporting/eip-2926.md",
"supporting/eip-7928.md",
"supporting/eip-8032.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 17,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-8038 was a Draft proposal to increase four existing warm/cold state-access gas parameters affecting SSTORE, SLOAD, call-family, BALANCE, SELFDESTRUCT, and EXT-family operations. It also specified an extra warm-access charge for EXTCODESIZE and EXTCODECOPY, with conditional treatment when EIP-2926 or EIP-8032 applies. The actual gas values and supporting stateful benchmark results were not yet finalized.",
"tier": "medium",
"title": "State-access gas cost update",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 17,
"minimum": 13
},
"present": true,
"summary": "Material under-specification is present: all four replacement gas constants and increases are TBD, the stateful benchmark basis is unfinished, and the exact formula/parameter selection when EIP-2926 or EIP-8032 is active is not fully resolved. These gaps prevent authoritative exact-gas vectors even though the direction and broad opcode scope of the repricing are clear.",
"unresolved_questions": [
"What exact values replace each of the four gas parameters, and what benchmark data selects them?",
"Is GAS_WARM_ACCESS intentionally in scope even though the abstract highlights only three base costs?",
"Which parameter set applies if EIP-8032 activates in the same fork, and how is ACTIVATION_THRESHOLD incorporated into calibration?",
"Does EIP-2926 suppress only the extra EXTCODESIZE warm charge, and what combined treatment applies to EXTCODECOPY?",
"How should EIP-7928's parallel-read optimizations be reflected in the final benchmark baseline?"
]
}
},
"amsterdam:8246:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The normative changes address SELFDESTRUCT balance and finalization state, while explicitly leaving all other SELFDESTRUCT behavior unchanged."
},
{
"locator": "Security Considerations, lines 79-80",
"source": "eip.md",
"summary": "The proposal says the applicable account-creation cost is already properly included rather than defining a new or adjusted gas charge."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No gas schedule, dynamic-cost rule, or charging mechanism is changed, so the proposal meets the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The EIP changes the resulting balance and finalization state but specifies no relocation of state access or gas charging within SELFDESTRUCT execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "This is a result change, not a change to the order of state access and gas charging within an opcode; therefore the ordering anchor is not triggered.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The complete normative change is confined to SELFDESTRUCT and account state at transaction finalization; it introduces no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is added or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The EIP changes which account fields remain after finalization but defines no state-gas cost, rate, budget, reservoir, charging site, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "State contents change, but the rubric's separate state-gas accounting mechanisms do not; the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The specification enumerates balance preservation and field clearing and states that all other SELFDESTRUCT behavior is unchanged."
},
{
"locator": "Specification, lines 37-46",
"source": "supporting/eip-6780.md",
"summary": "The inherited same-transaction SELFDESTRUCT rules explicitly provide no gas refund, and EIP-8246 does not alter that rule."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, line 79",
"source": "eip.md",
"summary": "The EIP identifies a combinatorial effect across many multi-call/create test scenarios, significant testing effort, and adaptation of many EIP-6780 tests."
},
{
"locator": "Backwards Compatibility, lines 63-69",
"source": "eip.md",
"summary": "Existing expectations for burn, deletion, retained balance-only accounts, and follow-up CREATE2 change only in the same-transaction creation branch."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable set of existing SELFDESTRUCT/EIP-6780 vectors must be reworked, but it remains a specialized opcode-and-creation category rather than a diverse major subset of the whole test corpus, matching score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, line 79",
"source": "eip.md",
"summary": "Existing EIP-6780 cases are described as needing adaptation to changed behavior, not as unrelated tests gaining an additional universal assertion."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The affected tests change expected results; tests not about this EIP do not gain a new mechanically applied invariant.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The behavior is derived from ordinary transaction execution and finalization, with no new input, output, or fork-activation-block datum specified."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or mechanism is required.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, line 79",
"source": "eip.md",
"summary": "The proposal says many existing EIP-6780 test cases can be adapted, providing no indication that new framework-level expectations or modifiers are needed."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing transaction, call/create, opcode, and post-state test primitives suffice; only new or adapted cases are called for.",
"score": 0,
"uncertainty_note": "Concrete test cases are TBD, but the specified behavior exposes no need for a new framework abstraction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The changes concern SELFDESTRUCT balances and account-field clearing and do not introduce or modify a cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced or changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 22-23",
"source": "eip.md",
"summary": "Remaining burn cases distinguish same-transaction creation, self-beneficiary, and later funding via CALL or one or more SELFDESTRUCT operations."
},
{
"locator": "Backwards Compatibility, lines 63-69",
"source": "eip.md",
"summary": "Outcomes branch on zero versus nonzero final balance, later CREATE2, and whether creation occurred in the same transaction."
},
{
"locator": "Security Considerations, line 79",
"source": "eip.md",
"summary": "The proposal expressly characterizes multi-call/create interactions as combinatorial across a vast number of scenarios."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms combine multiplicatively, and the proposal itself calls out an elevated test-case count, satisfying score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The normative changes affect execution and transaction-finalization state and add no block RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block serialization or syncing validation mechanism changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "SELFDESTRUCT semantics change without any Engine API field, endpoint, or communication mechanism being introduced."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The EIP modifies an existing opcode and finalization behavior and introduces no contract address, bytecode, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The specification identifies only SELFDESTRUCT account behavior and no existing system contract code, state, or indirect system-contract effect."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is modified directly or indirectly.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The proposal changes the existing SELFDESTRUCT opcode only."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "SELFDESTRUCT with a same-transaction-created self-beneficiary now preserves balance, and marked-account finalization preserves balance instead of deleting the account while clearing nonce, code, and storage."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least one pre-existing opcode's non-gas behavior is modified, which maps directly to the rubric's fixed score-3 anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The complete normative scope changes SELFDESTRUCT and mentions no precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The complete normative scope changes SELFDESTRUCT and mentions no precompile behavior or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The account-state semantic change introduces no transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface-level encoding changes are specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The proposal applies during ordinary transaction execution and finalization and defines no transaction envelope or new transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 61-69",
"source": "eip.md",
"summary": "The hard-fork change alters successful execution post-state and CREATE2 reuse, not transaction validity or intrinsic gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction acceptance rule or intrinsic-gas validity mechanism changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The specification changes opcode and finalization behavior without adding a block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 59-65",
"source": "eip.md",
"summary": "A hard fork switches the execution rule, but the proposal specifies no one-time state mutation or internal-variable modification at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork-gated semantics do not constitute the rubric's activation-block state or internal-variable mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 20-25",
"source": "eip.md",
"summary": "The proposal removes a nearly unused special case to simplify EVM handling and says the affected path is rarer than the already changed EIP-6780 path."
},
{
"locator": "Security Considerations, line 80",
"source": "eip.md",
"summary": "Balance-only dust accounts are possible, but the applicable creation cost is already included and the text reports the triggering behavior as very rare."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The package identifies no new mechanism requiring performance validation; the change simplifies a rare existing finalization path, so score 0 is best supported.",
"score": 0,
"uncertainty_note": "The text does not supply benchmarks, but it also does not identify a material performance-sensitive mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, lines 79-80",
"source": "eip.md",
"summary": "The change combines with multi-call/create flows and can leave dust-like accounts holding locked nonzero balances when callers expected a burn."
},
{
"locator": "Rationale and Backwards Compatibility, lines 53-67",
"source": "eip.md",
"summary": "Finalization clears execution state, retains balance, resets nonce, and must preserve later CREATE2 reuse across zero- and nonzero-balance outcomes."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The change alters security-relevant balance and account-lifecycle assumptions across a limited cluster of SELFDESTRUCT, call/create, finalization, and CREATE2 behavior, warranting targeted review and fuzzing under score 2; it does not establish the broad critical-component impact required for score 3.",
"score": 2,
"uncertainty_note": "The proposal calls for significant testing but does not quantify a separate security-review or fuzzing program.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The proposal specifies the changed self-beneficiary balance, every retained account field at finalization, empty-account deletion, and that all remaining SELFDESTRUCT behavior is unchanged."
},
{
"locator": "Specification, lines 26-50",
"source": "supporting/eip-6780.md",
"summary": "The inherited baseline distinguishes same-transaction creation, defines its balance/deletion semantics, and defines what counts as contract creation."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Together the proposal and its required baseline determine constructible outcomes; missing concrete tests do not create a normative cross-client choice.",
"score": 0,
"uncertainty_note": "Test cases are TBD, but no material behavioral gap requiring client agreement is apparent in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Preamble and Specification, lines 1-11 and 46-47",
"source": "eip.md",
"summary": "EIP-8246 formally requires EIPs 161 and 6780, leaves the EIP-6780 baseline otherwise unchanged, and delegates zero-balance deletion to EIP-161."
},
{
"locator": "Specification, lines 24-36",
"source": "supporting/eip-161.md",
"summary": "EIP-161 defines end-of-transaction deletion and the empty-account predicate used by EIP-8246's resulting account state."
},
{
"locator": "Specification, lines 26-48",
"source": "supporting/eip-6780.md",
"summary": "EIP-6780 supplies the prior two-branch SELFDESTRUCT semantics that EIP-8246 selectively modifies."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
161,
6780
],
"rationale": "Coordinated testing against two required EIPs is necessary for the baseline SELFDESTRUCT branch and final empty-account deletion, but the interactions are localized, matching score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8246,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8246:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "630c3420dacd31a90ce702b76092f4c9f085d4d4",
"committed_at": "2026-05-06T12:59:06Z",
"content_sha256": "12452f4f467ef76923cb25c363ff4df9ead4f5bc953f500c980fde40173f3d75",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8246.md",
"git_blob_sha": "1f0217997e40f92717c2c41f63a54a3789169f8d",
"immutable_url": "https://github.com/ethereum/EIPs/blob/630c3420dacd31a90ce702b76092f4c9f085d4d4/EIPS/eip-8246.md",
"information_cutoff_at": "2026-05-06T12:59:06Z",
"path": "EIPS/eip-8246.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8246.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-8246.yaml",
"sha256": "943791c0969b6852954cec3cce058461316d059b5a5a36d9655a3c8a5371fdf7"
},
"supporting_documents": [
"supporting/eip-161.md",
"supporting/eip-6780.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 12,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-8246 proposed removing the remaining ETH-burn cases for SELFDESTRUCT executed by a contract created in the same transaction. It preserves the account balance while clearing nonce, code, and storage at transaction finalization, lets EIP-161 delete a resulting empty account, and leaves behavior outside the same-transaction creation case unchanged from EIP-6780. The proposal also resets nonce to zero so a later CREATE2 remains possible; it requires a hard fork and identifies a large combinatorial multi-call/create test surface, but its concrete test cases were still TBD.",
"tier": "medium",
"title": "Remove SELFDESTRUCT Burn",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 12
},
"present": false,
"summary": "No material normative under-specification is apparent. Although concrete test cases are TBD, the proposal defines the changed balance and finalization results and incorporates the EIP-161 and EIP-6780 baseline rules needed to determine the remaining cases.",
"unresolved_questions": []
}
},
"amsterdam:8282:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Request queue and system call, lines 76-78",
"source": "eip.md",
"summary": "Each new predeploy is invoked with a dedicated 30,000,000 gas allowance whose consumption is excluded from the block gas limit, and a failed call invalidates the block."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal extends the existing exceptional system-call gas-accounting path to two additional calls, fitting an update to an existing mechanism. It does not alter opcode costs or ordinary transaction gas accounting.",
"score": 1,
"uncertainty_note": "The rubric boundary is whether adding calls to an already-defined gas-exempt system-call mechanism counts as updating EVM gas accounting; this assessment treats it as score 1 rather than 0.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 162-166",
"source": "eip.md",
"summary": "The execution-layer change is described as additive through contracts at previously empty addresses, with existing validator contracts left unchanged."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Contract calls and storage operations are added, but no opcode's internal state-access position or gas-charge ordering is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Request fee, lines 80-90",
"source": "eip.md",
"summary": "The only new demand-responsive fee is a per-request fee driven by each contract's request count and excess counter."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The request fee neither meters blobs nor modifies any blob-gas mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Request queue and system call, lines 67-74",
"source": "eip.md",
"summary": "The contracts maintain ordinary storage-backed counters and FIFO records and dispatch among dequeue, write, fee-getter, and revert paths."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Although the feature writes execution state, it introduces no state-gas cost, state-byte rate, block state-gas budget, reservoir, or execution-gas spill rule.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations — Locked funds, line 181",
"source": "eip.md",
"summary": "Request fees, overpayments, remainders, and rejected first-deposit principal are permanently locked, and the predeploys have no withdrawal path."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no EVM gas-refund mechanism; its explicit no-refund economic behavior is unrelated to EVM gas refunds.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Changes to EIP-7732, lines 142-148",
"source": "eip.md",
"summary": "Existing Gloas builder branches are removed from deposit-request and voluntary-exit processing, post-fork builder routing moves to two new request handlers, and the one-time onboarding path remains."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable subset of existing EIP-7732 builder-lifecycle and fork-transition tests must be reworked for new request sources and handlers, but the affected population is concentrated in builder onboarding, top-ups, and exits rather than diverse execution behavior.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Deployment and Request queue, lines 61-78",
"source": "eip.md",
"summary": "Post-activation blocks require code at both predeploy addresses and must execute both end-of-block system calls, whose failures invalidate the block."
},
{
"locator": "Specification — Request fee, line 90",
"source": "eip.md",
"summary": "The first system call changes each predeploy's excess value from the inhibitor to normal fee state."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing activation and request-bus tests gain assertions for code presence, mandatory calls, and first-call state. This is a narrow fork-related category, not every test, because empty new request data is excluded from the existing requests hash.",
"score": 1,
"uncertainty_note": "Whether generic post-fork fixtures expose system-call outputs mechanically could broaden the affected test category, but the EIP's empty-request rule avoids a universal new requests-hash assertion.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Requests, lines 34-43",
"source": "supporting/eip-7685.md",
"summary": "The existing request bus represents every type through one generic request-type byte plus opaque request data."
},
{
"locator": "Specification — Request queue and system call, lines 76-78",
"source": "eip.md",
"summary": "The new outputs are inserted into the existing EIP-7685 block requests list."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The sealed specification requires new values within the existing generic requests mechanism but specifies no new transition-tool field or interface mechanism.",
"score": 0,
"uncertainty_note": "The package does not include a transition-tool schema, so this score relies on the sealed EIP-7685 generic request representation being sufficient without new interface fields.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Request queue and system call, lines 67-78",
"source": "eip.md",
"summary": "The two contracts reuse the established EIP-7002/EIP-7251 queue and system-call pattern while defining new fixed-size records and request types."
},
{
"locator": "Reference Implementation, lines 168-170",
"source": "eip.md",
"summary": "Test cases and a reference implementation remain TODO at the cutoff."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing system-call and request-bus primitives should remain usable, but minor extensions are needed to construct and inspect the two builder request forms and their predeploy states.",
"score": 1,
"uncertainty_note": "The absent test cases and reference implementation leave the exact helper surface unspecified; a reusable new expectation primitive could raise this to 2.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Consensus-layer processing of records, lines 136-140",
"source": "eip.md",
"summary": "First builder registration verifies a BLS proof-of-possession over a DepositMessage under a new builder-specific signing domain; top-ups ignore the signature."
},
{
"locator": "Security Considerations — Cross-class deposit signatures, lines 174-175",
"source": "eip.md",
"summary": "Domain separation prevents replay between validator and builder deposit classes while retaining the established BLS deposit-signature mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "One well-known BLS proof-of-possession mechanism is introduced in a new domain, matching score 1 rather than novel cryptography.",
"score": 1,
"uncertainty_note": "The numerical DOMAIN_BUILDER_DEPOSIT value is absent, but the cryptographic mechanism and security purpose are clear enough to select the anchor.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Deposit and exit requests, lines 92-115",
"source": "eip.md",
"summary": "Deposit processing has exact calldata, amount, fee, funding, overpayment, and endian boundaries, while exits have exact calldata, caller authorization, and fee conditions."
},
{
"locator": "Specification — Consensus-layer processing of records, lines 134-140",
"source": "eip.md",
"summary": "Outcomes branch on first registration versus top-up, exited versus swept entries, finality and activity, authorization, pending balances, and silent discard behavior."
},
{
"locator": "Security Considerations — Spam and state growth, lines 179-182",
"source": "eip.md",
"summary": "Queue draining is capped while enqueue and cross-block backlog growth are not, FIFO ordering can delay honest registrations, and rejected or overpaid records lock funds."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact across value arithmetic, byte encodings, queue caps and resets, fork timing, builder lifecycle states, and authorization. Several require an elevated combinatorial case set, meeting score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 162-166",
"source": "eip.md",
"summary": "The execution-layer addition uses existing contracts-and-requests machinery and introduces no new block field."
},
{
"locator": "Specification — Block Header, lines 45-70",
"source": "supporting/eip-7685.md",
"summary": "The requests_hash header commitment and its computation are already defined by EIP-7685."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "EIP-8282 adds request contents and validation but no block-RLP validation mechanism requiring client-sync tests.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Request queue and system call, line 76",
"source": "eip.md",
"summary": "Builder records are carried through the existing EIP-7685 requests list and requests_hash commitment."
},
{
"locator": "Specification — Engine API, lines 369-371",
"source": "supporting/eip-7732.md",
"summary": "The underlying Gloas proposal explicitly states that no Engine API changes are needed."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is added by the sealed proposal.",
"score": 0,
"uncertainty_note": "EIP-8282 has no dedicated Engine API section, but its explicit reuse of EIP-7685 and the packaged EIP-7732 statement support score 0.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-21",
"source": "eip.md",
"summary": "Two predeploy contracts accept builder deposits and exits, retain in-state queues, and emit records for consensus-layer processing."
},
{
"locator": "Specification — Request queue and system call, lines 67-78",
"source": "eip.md",
"summary": "Both contracts maintain persistent queue and fee state and are invoked as mandatory end-of-block system actions that create EIP-7685 requests."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Multiple new system contracts are introduced, and both are stateful and trigger cross-layer request actions, directly matching score 3.",
"score": 3,
"uncertainty_note": "Exact runtime code and final addresses are not frozen, but the count, statefulness, and system actions are unambiguous.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Changes to EIP-7732, lines 142-148",
"source": "eip.md",
"summary": "The deployed validator deposit contract is not changed, but after the fork its requests always follow validator processing and can no longer onboard or top up builders except through the retained one-time transition snapshot."
},
{
"locator": "Backwards Compatibility, lines 162-166",
"source": "eip.md",
"summary": "Existing validator deposit, withdrawal, and consolidation contract code remains untouched while builder lifecycle routing changes on the consensus layer."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "There is no direct code or state modification, but the validator deposit contract's post-fork output loses a major builder-routing role. That is a major indirect behavioral effect on one existing protocol contract, matching score 2.",
"score": 2,
"uncertainty_note": "The classification depends on treating changed consensus interpretation of an unchanged deposit contract's requests as an indirect system-contract effect.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 162-166",
"source": "eip.md",
"summary": "The execution-layer feature is additive through two contracts at empty addresses and the existing request bus."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 162-166",
"source": "eip.md",
"summary": "The proposal describes additive contract deployment and explicitly leaves existing execution-layer lifecycle contracts unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode's result or non-gas behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-21",
"source": "eip.md",
"summary": "The new execution components are specified as predeploy contracts with storage-backed queues, not precompiles."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 162-166",
"source": "eip.md",
"summary": "The stated execution-layer scope is two new contracts and no change to existing lifecycle contracts."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Deposit requests, lines 92-108",
"source": "eip.md",
"summary": "A 184-byte execution input is transformed into a fixed-width request record, including conversion of the amount from big-endian calldata to little-endian SSZ encoding."
},
{
"locator": "Specification — Consensus layer request objects, lines 116-132",
"source": "eip.md",
"summary": "Two new SSZ containers and fixed-size concatenated request_data encodings of 184 and 68 bytes are defined for the execution-to-consensus interface."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal introduces new SSZ-encoded interface records and a consensus-critical endian transformation, which is an interface-level encoding change and therefore score 3 under the binary anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Deposit and exit requests, lines 92-115",
"source": "eip.md",
"summary": "Users submit both request forms by ordinary calls to the two contracts with exact calldata and value conditions."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "New execution request types are not new transaction envelope types.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Deposit and exit requests, lines 92-115",
"source": "eip.md",
"summary": "Amount, fee, funding, and caller checks occur inside the called contracts; rejected inputs revert at contract execution."
},
{
"locator": "Backwards Compatibility, lines 162-166",
"source": "eip.md",
"summary": "The execution-layer change is additive and does not state any change to transaction envelopes, intrinsic gas, or transaction validity."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Contract-level request acceptance and block-level system-call validity do not modify the validity rules or intrinsic gas of existing transaction types.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Request queue and system call, line 76",
"source": "eip.md",
"summary": "The new request records are committed through the existing EIP-7685 requests_hash field."
},
{
"locator": "Specification — Block Header, lines 45-70",
"source": "supporting/eip-7685.md",
"summary": "EIP-7685 already defines requests_hash as the execution-header field for arbitrary request types."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "EIP-8282 populates an existing extensible commitment and introduces no block or header field.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Deployment, lines 61-65",
"source": "eip.md",
"summary": "Both contracts must be deployed before activation with excess set to an inhibitor, and every active block is invalid if either address lacks code."
},
{
"locator": "Specification — Request fee, line 90",
"source": "eip.md",
"summary": "The first active end-of-block call changes predeployed contract state by clearing the inhibitor and enabling normal request fees."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation requires more than initialization of a new client variable: the first active block performs a consensus-mandated modification of pre-existing deployed contract state. This meets the score-3 activation anchor.",
"score": 3,
"uncertainty_note": "Final bytecode, addresses, and presigned deployment transactions were not frozen, but the activation-state transition itself is explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale — Onboarding via the fork transition, line 160",
"source": "eip.md",
"summary": "One-time onboarding processes the entire pending-deposits queue and verifies a proof-of-possession for each new builder; its cost is not constant-bounded and clients are advised to pre-verify and cache results."
},
{
"locator": "Security Considerations — Spam and state growth, lines 174 and 179-182",
"source": "eip.md",
"summary": "Steady-state processing adds bounded consensus BLS checks and request data, but enqueue is only gas-limited, queue state can grow across blocks, and a FIFO backlog can throttle onboarding."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance spans execution storage growth and system calls, consensus BLS verification, cross-block FIFO backlog, and an unbounded activation-time scan. These interactions cannot be fully benchmarked in isolation and can substantially affect fork-transition and steady-state behavior, meeting score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 172-182",
"source": "eip.md",
"summary": "The proposal identifies deposit-signature domains and replay, sole-address exit authorization, a custodial exit standoff, reusable indices, queue spam and state growth, locked funds, and privileged system-read access as security-sensitive behavior."
},
{
"locator": "Specification — Consensus-layer processing of records, lines 136-140",
"source": "eip.md",
"summary": "Request handling mutates builder registration, balances, exit timing, and withdrawals, with several invalid records silently consumed rather than invalidating the block."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanisms cross execution contract state, request commitments, BLS registration, builder balances, cold-key authorization, and EIP-7732 withdrawals. They alter assumptions across multiple critical components and warrant extensive security review and fuzzing, matching score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Constants, lines 39-59",
"source": "eip.md",
"summary": "The proposed request bytes are not final because 0x03 conflicts with draft EIP-7804, final allocation is deferred to consensus-specs, and runtime code is delegated to the missing reference implementation."
},
{
"locator": "Specification — Deployment, lines 61-63",
"source": "eip.md",
"summary": "Predeploy addresses depend on presigned transactions for runtime bytecode that may still change before audit and freezing."
},
{
"locator": "Reference Implementation, lines 168-170",
"source": "eip.md",
"summary": "Both test cases and the reference implementation are TODO."
},
{
"locator": "Specification — Consensus-layer processing and Security Considerations, lines 138 and 174-175",
"source": "eip.md",
"summary": "A new consensus-critical DOMAIN_BUILDER_DEPOSIT is required, but the EIP gives no numeric domain constant."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients must coordinate exact request-type allocation, the signing-domain constant, and deployable bytecode and artifacts before common vectors can be baselined. The gaps are material but localized to constants and deployment artifacts rather than newly observable formerly-unspecified behavior, matching score 2.",
"score": 2,
"uncertainty_note": "Independent clients could implement much of the normative behavior from the prose, but exact cross-client byte-for-byte fixtures cannot be finalized from this revision alone.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Abstract, lines 1-21",
"source": "eip.md",
"summary": "The EIP formally requires EIPs 1559, 7685, and 7732 and models its two predeploy queues on EIPs 7002 and 7251."
},
{
"locator": "Specification — Constants, line 41",
"source": "eip.md",
"summary": "Its proposed 0x03 request type conflicts with draft EIP-7804 and requires coordinated allocation."
},
{
"locator": "Specification — Consensus layer request objects and Changes to EIP-7732, lines 132 and 142-148",
"source": "eip.md",
"summary": "The deposit object derives from EIP-6110, and EIP-7732's deposit and exit processing is directly rerouted to the new request types."
}
],
"exceptional_score_justification": "This is not an exceptional override of a capped anchor. Cross-EIP interactions is uncapped, and the rubric's mechanical formula yields 3 + 1 = 4 for seven interacting EIPs.",
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
6110,
7002,
7251,
7685,
7732,
7804
],
"rationale": "Seven identified EIPs interact: 1559, 6110, 7002, 7251, 7685, 7732, and 7804. Strong dependencies and direct EIP-7732 modification establish base score 3; four interactions beyond the first three contain one complete additional group of three, adding 1 under the uncapped formula for score 4.",
"score": 4,
"uncertainty_note": "None identified.",
"under_specified": true,
"unidentified_interactions": []
}
],
"eip": 8282,
"evaluation_date": "2026-08-25",
"fork": "amsterdam",
"id": "amsterdam:8282:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"EVM gas accounting is scored 1 because two new calls use the existing gas-exempt system-call mechanism; a stricter reading limited to opcode and ordinary transaction accounting could score it 0.",
"Modified system contracts is scored 2 because consensus interpretation of validator-deposit-contract outputs changes substantially even though the deployed contract's code and state transition are unchanged.",
"The generic EIP-7685 request transport is treated as sufficient for transition-tool and Engine API interfaces; the sealed package contains no separate transition-tool schema for confirmation."
],
"provenance": {
"assessed_revision": {
"commit": "554d3325e31c3f74078402d961355218ece16bee",
"committed_at": "2026-07-08T12:46:18Z",
"content_sha256": "ff36162c244b19266b6a97716b84d28e13a94dd24dad1e46935d50fed148a380",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8282.md",
"git_blob_sha": "35ab20cb31a416c50600da00125d262e1756850c",
"immutable_url": "https://github.com/ethereum/EIPs/blob/554d3325e31c3f74078402d961355218ece16bee/EIPS/eip-8282.md",
"information_cutoff_at": "2026-07-13T07:12:57Z",
"path": "EIPS/eip-8282.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8282.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-8282.yaml",
"sha256": "068d43f25d0f23df859ac0144538047fb070d21f250a509d3c269826e017d193"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-6110.md",
"supporting/eip-7002.md",
"supporting/eip-7251.md",
"supporting/eip-7685.md",
"supporting/eip-7732.md",
"supporting/eip-7804.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 32,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the recorded cutoff, EIP-8282 proposed two stateful predeploys that accept builder deposits and exits, queue them under demand-responsive fees, and expose bounded batches through end-of-block system calls as two EIP-7685 request types. The consensus layer would register or top up builders from deposit records, authorize exits through a builder's execution address, and replace EIP-7732's post-fork validator-deposit and voluntary-exit routing while retaining one-time fork-transition onboarding. The draft specified the normative queue and lifecycle behavior in detail, but its request-type allocation, signing-domain constant, runtime bytecode, deployment artifacts, reference implementation, and tests were not yet final.",
"tier": "high",
"title": "Builder Execution Requests",
"under_specification": {
"affected_criteria": [
"new_test_framework_primitives",
"cryptography",
"added_system_contracts",
"new_fork_activation_mechanism",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 34,
"minimum": 30
},
"present": true,
"summary": "Material under-specification remains in the request-type allocation, the numeric builder-deposit signing domain, and the exact predeploy runtime code and presigned deployment artifacts. The generic queue description also relies on obvious per-contract substitution of MAX_REQUESTS_PER_BLOCK and TARGET_REQUESTS_PER_BLOCK, while the reference implementation and tests are absent. These gaps prevent exact cross-client vectors and activation artifacts from being finalized even though the high-level mechanics are clear.",
"unresolved_questions": [
"Which unique EIP-7685 request-type bytes will be assigned after resolving the 0x03 collision with EIP-7804?",
"What numeric value and exact consensus constant definition will DOMAIN_BUILDER_DEPOSIT use?",
"What audited runtime bytecode, resulting predeploy addresses, and presigned deployment transactions will be frozen?",
"Will final test infrastructure need only extensions of existing request-predeploy helpers, or new reusable expectation primitives?"
]
}
},
"cancun:1153:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 53-55",
"source": "eip.md",
"summary": "TLOAD and TSTORE receive newly specified constant execution-gas costs, each defined by reference to an existing warm or hot storage-operation cost."
},
{
"locator": "Rationale, lines 85-90",
"source": "eip.md",
"summary": "The proposal states that existing operation semantics remain unchanged and characterizes the new opcodes' accounting as simpler."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "evm_gas_rule_changes",
"rationale": "The two opcodes add new execution-gas charging sites, so this is a new EVM gas rule. Their fixed 100-gas schedule neither changes an existing opcode's accounting nor introduces refunds, matching score 2 rather than score 3.",
"score": 2,
"uncertainty_note": "The wording does not make fully explicit whether the costs are permanently 100 or track the named warm/hot referent costs, but that does not change the anchor score at the cutoff.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Specification, lines 17-17 and 55-57",
"source": "eip.md",
"summary": "Transient values are never loaded from or written to persistent storage, have fixed warm/hot-equivalent costs, and are discarded at transaction end."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The text introduces no cold/warm recording, block-level access-list effect, or change to gas-versus-access ordering for an existing opcode. Transient map access is the new opcodes' result mechanism, but the proposal provides no recordable persistent-state access whose internal ordering changes under this anchor.",
"score": 0,
"uncertainty_note": "The proposal calls transient storage \"state\"; this assessment treats its non-persistent, fixed-cost map access as outside the rubric's recordable state-access-ordering concern.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 15-22 and 43-65",
"source": "eip.md",
"summary": "The complete feature is two transient-storage EVM opcodes and contains no blob mechanism or blob-gas rule."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Rationale, lines 17-17 and 85-91",
"source": "eip.md",
"summary": "Transient values are never serialized to persistent storage, clients need not load an original value, and future persistent-storage designs need not account for them."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "state_gas_accounting_changes",
"rationale": "The EIP adds ordinary EVM execution-gas charges but no persistent-state byte charge, state-gas budget, reservoir, charging site, or spill rule.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Rationale, lines 41-41 and 69-71",
"source": "eip.md",
"summary": "The EIP expressly says no refunds are required and prefers a mechanism that does not interact with the refund counter."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "new_evm_gas_refund",
"rationale": "No new refund mechanism is introduced; avoiding refunds is a central design choice.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 45-45 and 93-97",
"source": "eip.md",
"summary": "Bytes 0xb3 and 0xb4 become valid opcodes, while the EIP expressly leaves all existing opcode behavior unchanged."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing invalid- or undefined-opcode coverage for the two assigned bytes needs localized rework, but existing contract and opcode-behavior tests are otherwise unaffected. That is a minor subset under score 1.",
"score": 1,
"uncertainty_note": "The historical EIP does not inventory the pre-existing test corpus; the affected invalid-opcode subset is inferred directly from assigning the two opcode bytes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 57-57 and 93-97",
"source": "eip.md",
"summary": "Transaction-end clearing applies only to newly created transient values, and existing opcode and contract behavior is unchanged."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests that do not execute TLOAD or TSTORE produce no transient values and gain no new externally asserted result or invariant.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-65",
"source": "eip.md",
"summary": "All specified inputs and effects are internal EVM opcode, call-frame, and transaction-lifetime behavior; no transition interface field is introduced."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "transition_tool_interface_changes",
"rationale": "The feature requires no new transition-tool field or interface mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 47-65",
"source": "eip.md",
"summary": "The observable cases are ordinary stack operations, calls, reverts, static execution, and transaction boundaries."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "new_test_framework_primitives",
"rationale": "These cases can be constructed as EVM programs and multi-transaction tests using existing execution-test concepts; the EIP requires no new expectation type, modifier, or permanent framework abstraction.",
"score": 0,
"uncertainty_note": "The package contains no description of the historical test framework, so this is judged from the required observable cases.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-65",
"source": "eip.md",
"summary": "The mechanism consists of word-addressed transient loads and stores and contains no cryptographic operation."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-65",
"source": "eip.md",
"summary": "Tests must cover transaction-end clearing, frame sharing, ownership under four call forms, nested revert rollback, and the TSTORE/TLOAD distinction in static context."
},
{
"locator": "Reference Implementation, lines 101-108",
"source": "eip.md",
"summary": "Correct rollback requires checkpoints across frame entry, successful return, and reverse journal application on revert."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "edge_boundary_conditions",
"rationale": "Several independent boundary-prone mechanisms combine: transaction lifetime, same- versus cross-owner frames, CALL/STATICCALL versus DELEGATECALL/CALLCODE, success versus nested revert, and static write failure. The ownership-by-call-type and nested-revert matrix requires an elevated number of cases, meeting score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 43-65 and 93-97",
"source": "eip.md",
"summary": "The EIP changes EVM execution only and specifies no block RLP field or block-validation rule."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism requiring sync testing is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-65",
"source": "eip.md",
"summary": "The proposal specifies only EVM-local opcodes and transient-store lifecycle, with no Engine API field or endpoint."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "engine_api_changes",
"rationale": "No Engine API communication change is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-65",
"source": "eip.md",
"summary": "Transient storage is private runtime data belonging to ordinary contract frames, not a newly deployed protocol contract."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 43-65 and 93-97",
"source": "eip.md",
"summary": "The EIP adds general EVM functionality and states that existing smart-contract behavior is unchanged; it identifies no system contract effect."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract code, state, or behavior is modified directly or indirectly.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-55",
"source": "eip.md",
"summary": "The EIP adds TLOAD at 0xb3 and TSTORE at 0xb4, with one- and two-word stack interfaces, word addressing, and constant gas costs."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "added_opcodes",
"rationale": "Two new opcodes are introduced. Each has fixed-size stack operands, no data portion, and a constant cost, so they are multiple simple opcodes and match score 2.",
"score": 2,
"uncertainty_note": "The TLOAD result sentence has a normative stack-action typo, recorded under under-specification, but it does not make the opcode structurally complex.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale and Backwards Compatibility, lines 85-90 and 93-97",
"source": "eip.md",
"summary": "The EIP expressly says it does not change the semantics or behavior of existing operations and opcodes."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 15-22 and 43-65",
"source": "eip.md",
"summary": "The proposal adds two opcodes and no address-based precompile."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 43-65 and 93-97",
"source": "eip.md",
"summary": "The specified change is confined to new opcodes and leaves existing behavior unchanged, with no precompile gas or logic change."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 15-22 and 43-65",
"source": "eip.md",
"summary": "The EIP adds internal EVM word operations and no transaction, block, or interface serialization."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other transaction/block/interface encoding changes are introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-65",
"source": "eip.md",
"summary": "Transient storage is available through opcodes inside ordinary transaction execution; no transaction envelope or type is defined."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 43-65 and 93-97",
"source": "eip.md",
"summary": "The hard-fork change affects opcode execution only and defines no transaction validity or intrinsic-gas rule."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity and intrinsic gas calculations are unchanged.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-65",
"source": "eip.md",
"summary": "The full specification adds EVM runtime behavior and no block or header field."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "new_block_header_fields",
"rationale": "No new block body or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 57-57 and 93-95",
"source": "eip.md",
"summary": "Although a hard fork activates the opcodes, transient values are transaction-local and discarded; no activation-block state or existing internal variable is modified."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "new_fork_activation_mechanism",
"rationale": "Opcode availability changes at the fork, but there is no special activation-block state transition or variable modification.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reference Implementation, lines 101-108 and 201-201",
"source": "eip.md",
"summary": "The recommended journal is constant-time on normal paths but reverse-linear on revert; a worst-case reverting transaction performs twice the writes, although the EIP compares this with existing state journaling."
},
{
"locator": "Security Considerations, lines 225-245",
"source": "eip.md",
"summary": "TSTORE permits linear node-memory allocation up to about 9.15 MB at the stated block gas limit, and the EIP compares this with call-reset memory allocation up to about 20 MB."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "performance_risks",
"rationale": "Loads and normal stores can be benchmarked directly, but total cost cannot be validated wholly in isolation because checkpoints, nested reverts, and transaction-wide allocation interact with call execution and journaling. The EIP's comparison to existing worst cases supports limited rather than substantial benchmark impact, matching score 2.",
"score": 2,
"uncertainty_note": "The package supplies complexity bounds and gas-limit examples but no measured client benchmarks.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 59-65",
"source": "eip.md",
"summary": "Security-sensitive semantics vary across call ownership, nested reverts, and static contexts."
},
{
"locator": "Security Considerations, lines 225-249",
"source": "eip.md",
"summary": "The EIP identifies linear node-memory allocation, transaction-lifetime misuse, reentrancy-lock hazards, and unexpected persistence across frame returns as risks."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "security_risks",
"rationale": "The mechanism touches a limited but meaningful set of existing components: call-context ownership, reversion, static execution, reentrancy patterns, and node memory. These slightly alter assumptions for contracts using the feature and warrant targeted review and fuzzing, but the EIP does not alter existing opcode invariants broadly enough for score 3.",
"score": 2,
"uncertainty_note": "The document analyzes hazards qualitatively but includes no packaged implementation or security-test results.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 47-51",
"source": "eip.md",
"summary": "TLOAD is said to use the SLOAD stack interface and fetch a word, but its final normative clause says it \"pops\" the value rather than stating that it pushes the fetched word."
},
{
"locator": "Reference Implementation, lines 127-150",
"source": "eip.md",
"summary": "The non-normative implementation makes absent keys read as a zero word, clarifying a behavior not stated as directly in the opcode specification."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A few localized details are imperfectly specified, most notably the self-contradictory TLOAD result action. The SLOAD analogy, the word \"fetches,\" and the reference implementation make the intended behavior obvious enough for score 1, but clients still need a shared correction or interpretation before baselining literal opcode tests.",
"score": 1,
"uncertainty_note": "Same-transaction address destruction/recreation and whether the 100-gas values are fixed or referential are also not expressly resolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Motivation, lines 12-12 and 28-36",
"source": "eip.md",
"summary": "EIP-1153 formally requires EIP-2200 and EIP-3529 and identifies an EIP-20 temporary-approval use case."
},
{
"locator": "Specification and Rationale, lines 55-55 and 69-73",
"source": "eip.md",
"summary": "Opcode pricing is defined using storage-operation costs, while the design deliberately separates transient behavior from the refund mechanism changed by the required EIPs."
},
{
"locator": "Specification, lines 57-105",
"source": "supporting/eip-2200.md",
"summary": "EIP-2200 defines the dirty-slot SSTORE gas and refund machinery to which EIP-1153 compares TSTORE."
},
{
"locator": "Specification and Backwards Compatibility, lines 25-41 and 62-71",
"source": "supporting/eip-3529.md",
"summary": "EIP-3529 caps transaction refunds and discusses reentrancy locks and approve-and-send patterns that motivate the separate transient mechanism."
}
],
"exceptional_score_justification": "Not applicable; score 4 is not used.",
"id": "cross_eip_interactions",
"interacting_eips": [
20,
2200,
3529
],
"rationale": "Coordinated consideration with EIP-2200 and EIP-3529 is required for the referenced gas schedule and deliberate refund separation; EIP-20 supplies a limited contract-level use-case interaction. The dependencies are real but narrow and do not modify those EIPs' mechanisms, matching score 2 rather than extensive score-3 interdependence.",
"score": 2,
"uncertainty_note": "Unnumbered draft-opcode allocation and future-storage-design references are preserved separately and not inferred.",
"under_specified": false,
"unidentified_interactions": [
"Other draft EIPs competing for opcode bytes are mentioned in eip.md line 45 without EIP numbers.",
"Future storage designs such as Verkle trees are mentioned in eip.md line 91 without an EIP number."
]
}
],
"eip": 1153,
"evaluation_date": "2026-08-25",
"fork": "cancun",
"id": "cancun:1153:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The TLOAD specification says it fetches a word and then \"pops\" the value instead of specifying a pushed result.",
"The warm/hot cost analogies and parenthetical 100-gas values do not clearly state whether the schedule is referential or fixed.",
"The state-access-ordering anchor is rubric-sensitive because the EIP calls the map state while expressly excluding persistent storage and any cold/warm access-recording rule."
],
"provenance": {
"assessed_revision": {
"commit": "c282a9bd3ed750d315abbf5483ab31db2a3e5757",
"committed_at": "2022-12-07T18:16:53Z",
"content_sha256": "33bdd1ff47f8dbe93912da6a9a1564a90c761947a2840b556a9fa82b0446bfb0",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1153.md",
"git_blob_sha": "3ea30688b16741be2480987d545224fdc6ac4749",
"immutable_url": "https://github.com/ethereum/EIPs/blob/c282a9bd3ed750d315abbf5483ab31db2a3e5757/EIPS/eip-1153.md",
"information_cutoff_at": "2022-12-08",
"path": "EIPS/eip-1153.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-1153.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/cancun/eip-1153.yaml",
"sha256": "62ef329ab00496f0734c37317f204a8f753d8827cee12f82fe595f8ab74cebca"
},
"supporting_documents": [
"supporting/eip-20.md",
"supporting/eip-2200.md",
"supporting/eip-3529.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 15,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the 2022-12-08 information cutoff, EIP-1153 added two constant-cost EVM opcodes, TLOAD and TSTORE, backed by contract-private transient storage that is shared across the owning contract's frames and discarded after each transaction. The proposal specified storage-like addressing, call-type ownership, nested-revert rollback, and static-context behavior without changing existing opcode semantics or using the refund counter. It also supplied a map-and-journal reference design and analyzed worst-case memory allocation and revert work.",
"tier": "medium",
"title": "Transient storage opcodes",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"edge_boundary_conditions",
"added_opcodes",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 16,
"minimum": 15
},
"present": true,
"summary": "The normative TLOAD sentence says that after fetching a word the opcode \"pops\" the value on top of the stack, conflicting with its SLOAD-like load role and failing to state the expected pushed result. The intended reading is strongly signaled, but literal cross-client vectors require agreement; address lifecycle and whether gas values are fixed or referential are also not fully explicit.",
"unresolved_questions": [
"Does TLOAD push the fetched word, despite the normative sentence saying it pops a value?",
"Is transient storage identity strictly address-keyed if an address is destroyed and recreated within one transaction?",
"Are both opcode costs fixed at 100 gas, or do they track the named warm/dirty SSTORE and hot SLOAD referent costs?"
]
}
},
"cancun:4788:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification constants and New opcode, lines 25-31 and 72-83",
"source": "eip.md",
"summary": "The proposal assigns the new BEACON_ROOT operation a gas constant and specifies a fixed-cost storage-reading opcode."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "A gas charge is introduced for a new operation without changing an existing opcode's accounting or refund behavior, matching the anchor for a new, isolated accounting mechanism.",
"score": 2,
"uncertainty_note": "The constants table names G_beacon_root, while the opcode text names the undefined G_beacon_state_root.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / EVM changes / New opcode, lines 72-85",
"source": "eip.md",
"summary": "BEACON_ROOT pops a slot from the stack and then performs an SLOAD-like read from the history address."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The EIP introduces a new state-accessing operation whose stack, gas-charge, and storage-access ordering must be made consensus-exact, which is the score-2 anchor.",
"score": 2,
"uncertainty_note": "The pseudocode orders the pop and read but does not say where gas is charged or how exceptional execution is ordered relative to the read.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 23-31 and 41-85",
"source": "eip.md",
"summary": "The specified changes concern a header root, a pre-transaction state write, and an EVM opcode; no blob-gas rule is introduced or changed."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Nothing in the proposal meters, allocates, or otherwise changes blob gas.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / EVM changes / Block processing, lines 51-70",
"source": "eip.md",
"summary": "The proposal mandates protocol-level SSTORE-like writes before transactions but specifies no state-gas price, budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "A state mutation is introduced, but no separate state-gas accounting mechanism covered by this anchor is added or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / EVM changes / New opcode, lines 72-85",
"source": "eip.md",
"summary": "The new operation has a stated gas cost and read result, with no refund-producing condition or refund-counter change."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block structure and validity and Block processing, lines 41-68",
"source": "eip.md",
"summary": "Every post-fork block gains a mandatory header field and a pre-transaction state mutation, including fork-aware behavior based on timestamp."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork block, state-transition, syncing, and fork-transition tests would need broad reworking to supply the new header value and account for the state write, reaching the diverse-test score-3 anchor.",
"score": 3,
"uncertainty_note": "The Test Cases section is TODO, so the exact historical fixture categories and amount of rework are not documented.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block structure and validity, lines 41-47",
"source": "eip.md",
"summary": "All blocks at or after the fork timestamp must carry the parent beacon-block root in an appended 32-byte header field."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad class of otherwise unrelated post-fork block tests gains a mechanical assertion about the new field, while the text does not require all pre-fork vectors to be re-derived; this matches score 2 rather than 3.",
"score": 2,
"uncertainty_note": "The proposal supplies no test cases showing whether state-root effects would also become a universal asserted invariant.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block structure and validity and Block processing, lines 43-53",
"source": "eip.md",
"summary": "State transition after the fork requires one new 32-byte parent beacon-root value from the block header."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool must receive the single new header value to perform the mandatory pre-transaction write, matching the one-field score-1 anchor.",
"score": 1,
"uncertainty_note": "No transition-tool interface is specified, so whether auxiliary slot or fork-context inputs are also needed depends on resolving other gaps.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / Block structure and validity, lines 41-47; Test Cases, lines 111-113",
"source": "eip.md",
"summary": "The block-header schema gains a fork-conditional field, while the proposal provides no test design beyond a TODO."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing fixture primitives require at least a minor extension to represent the appended field, but the package does not establish a new reusable expectation or modifier abstraction.",
"score": 1,
"uncertainty_note": "The TODO test section leaves open whether special primitives for pre-block system writes or beacon-root expectations would be necessary.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification / Block structure and validity, lines 13-17 and 41-47",
"source": "eip.md",
"summary": "The new header commitment is the 32-byte hash-tree root of the parent beacon block."
},
{
"locator": "Merkleization, lines 210-248",
"source": "supporting/ethereum-consensus-specs--ssz-simple-serialize.md",
"summary": "The packaged reference defines the established SSZ chunking, Merkleization, and hash_tree_root construction used by the commitment."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The proposal integrates one well-specified, established Merkle-root mechanism rather than introducing novel cryptography, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / EVM changes, lines 53-85",
"source": "eip.md",
"summary": "Processing spans a start/end-slot range, converts keys to 32-byte big endian, wraps them modulo 8192, and returns zero when no root is stored."
},
{
"locator": "Specification / Background, lines 33-39",
"source": "eip.md",
"summary": "Missed slots and bounded ring-buffer storage are explicit design dimensions."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Fork boundaries, zero or many elapsed slots, modulo wraparound, absent entries, key widths, and stale-slot queries create multiple interacting boundaries; slot-gap and wraparound coverage require an elevated case set.",
"score": 3,
"uncertainty_note": "Several boundary outcomes are not fully determined because convert_to_slot and overwrite freshness semantics are unspecified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block structure and validity, lines 41-47",
"source": "eip.md",
"summary": "Post-fork execution headers append one mandatory 32-byte parent beacon-root field, changing header size and validity."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Syncing clients gain a single, structurally simple fork-conditional header-field validation rule, matching score 1.",
"score": 1,
"uncertainty_note": "The proposal does not spell out the block RLP form or validation error conditions.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / Block structure and validity, lines 43-47",
"source": "eip.md",
"summary": "Execution clients must place the consensus-derived parent beacon-block root into the execution header after the fork."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The cross-layer value must be communicated with the execution payload, implying one new payload/header field and therefore the score-1 Engine API consequence.",
"score": 1,
"uncertainty_note": "The EIP never names an Engine API endpoint, field, version, encoding, or validation responsibility.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification / Background, lines 13-18 and 33-39",
"source": "eip.md",
"summary": "Roots are stored in a contract at a canonical execution-state address using an SSTORE-like update and a bounded ring buffer."
},
{
"locator": "Specification / Block processing, lines 51-70",
"source": "eip.md",
"summary": "Protocol block processing writes the parent root into the history contract's storage before transactions."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "One new stateful system contract is introduced and receives a new protocol-level action every post-fork block, which matches score 2.",
"score": 2,
"uncertainty_note": "The account's code, initialization, and collision handling at the fixed address are not specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification constants, lines 13-18 and 25-31",
"source": "eip.md",
"summary": "The proposal introduces a contract at a newly designated history address rather than identifying or altering an existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract code, state, or behavior is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / EVM changes / New opcode, lines 72-85",
"source": "eip.md",
"summary": "One BEACON_ROOT opcode is added; it pops one word, performs one modulo-indexed storage read, pushes one word, and has a fixed stated gas cost."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This is a single opcode with no data portion, straightforward stack mechanics, and constant gas, meeting the score-1 simple-opcode anchor.",
"score": 1,
"uncertainty_note": "The gas constant name is inconsistent, and exceptional stack/gas ordering is not detailed.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Why not repurpose BLOCKHASH?, lines 93-96",
"source": "eip.md",
"summary": "The proposal explicitly leaves BLOCKHASH unchanged and adds a separate opcode to avoid breaking existing contracts."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is changed or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification / New opcode, lines 13-18 and 72-85",
"source": "eip.md",
"summary": "EVM access is provided through a new opcode reading state at a history address; no precompile is defined."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The proposal adds no precompile.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / EVM changes, lines 49-85",
"source": "eip.md",
"summary": "The EVM changes consist of protocol storage writes and a new opcode, with no reference to existing precompile logic or gas schedules."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block structure and validity, lines 41-47",
"source": "eip.md",
"summary": "A 32-byte field is appended after withdrawals_root and the block-header size grows at the fork timestamp."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Appending a consensus field changes block-header encoding at the block level, which directly triggers the binary score-3 anchor.",
"score": 3,
"uncertainty_note": "The exact RLP construction is implicit rather than written out.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-18 and 23-85",
"source": "eip.md",
"summary": "The change is to headers, block processing, state, and an opcode; it defines no transaction envelope or type identifier."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block structure and validity and Block processing, lines 41-70",
"source": "eip.md",
"summary": "The validity and processing rules are attached to blocks and occur before transactions; no transaction validity or intrinsic-gas rule is stated."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction types retain their validity and intrinsic gas rules.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block structure and validity, lines 41-47",
"source": "eip.md",
"summary": "A mandatory 32-byte parent beacon-block root is appended to the execution block header after withdrawals_root."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The proposal directly introduces a new block-header field, which is the score-3 anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block structure and validity and Block processing, lines 41-53",
"source": "eip.md",
"summary": "At the timestamp boundary the header grows, and processing the activation block performs a new history-contract storage write before transactions."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The fork-activation block modifies execution state under the new rule, directly meeting the score-3 anchor even though the action continues on later blocks.",
"score": 3,
"uncertainty_note": "FORK_TIMESTAMP is still TBD, but the activation condition itself is explicit.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block processing, lines 53-68",
"source": "eip.md",
"summary": "Every post-fork block performs protocol state writes in a loop over the elapsed slot range before transaction execution."
},
{
"locator": "Rationale / Beacon block root instead of state root, lines 98-105",
"source": "eip.md",
"summary": "The design explicitly considers work under skipped-slot conditions and chooses the block root to limit added work relative to a state-root design."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The write loop, state-trie interaction, and dependence on slot gaps require validation in full block processing and can affect existing block benchmarks, but the specified impact is bounded to this pre-block mechanism rather than clearly substantial across the system.",
"score": 2,
"uncertainty_note": "Undefined slot conversion and no stated timestamp-gap bound prevent a firm worst-case iteration and database-write assessment.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 19-21",
"source": "eip.md",
"summary": "Contracts such as staking pools and bridges are intended to rely on the exposed root for trust-minimized access to consensus state."
},
{
"locator": "Specification / Block structure and validity and EVM changes, lines 41-85",
"source": "eip.md",
"summary": "A consensus-derived value crosses into execution-header validity, protocol-managed state, and an EVM-visible opcode."
},
{
"locator": "Security Considerations, lines 119-121",
"source": "eip.md",
"summary": "The historical proposal leaves its security analysis as TODO."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect cross-layer roots, slot association, ring-buffer state, or opcode reads could undermine critical contract assumptions across several components, warranting extensive cross-layer review and fuzzing under the score-3 anchor.",
"score": 3,
"uncertainty_note": "The absence of security considerations and precise cross-layer validation responsibilities makes the exact threat surface uncertain.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification constants and Block processing, lines 25-31 and 53-70",
"source": "eip.md",
"summary": "The fork time is TBD and the consensus-critical convert_to_slot operation is used without any definition."
},
{
"locator": "Specification / New opcode, lines 72-85",
"source": "eip.md",
"summary": "The opcode refers to an undefined gas-constant name and describes absent-slot behavior despite modulo-only storage that can contain an overwritten value."
},
{
"locator": "Test Cases, Reference Implementation, and Security Considerations, lines 111-121",
"source": "eip.md",
"summary": "Tests, an implementation, and the security analysis are all left TODO at this revision."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously EVM-unobservable consensus-root and slot-association details become consensus-critical through a header field, state writes, and an opcode, while several constructible outcomes are unresolved; this matches score 3.",
"score": 3,
"uncertainty_note": "Material gaps include timestamp-to-slot conversion, gas naming and charge ordering, ring-buffer freshness, system-account initialization, and cross-layer validation/delivery.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Background, lines 33-39",
"source": "eip.md",
"summary": "The root-exposure method is explicitly described as inspired by EIP-2935."
},
{
"locator": "Simple Summary and Specification, lines 12-15 and 25-34",
"source": "supporting/eip-2935.md",
"summary": "EIP-2935 uses protocol-written history-contract state and an opcode read path for historical execution block hashes."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2935
],
"rationale": "The proposal has a limited design-level interaction with EIP-2935's history-in-state pattern but uses its own address and opcode and remains independently testable, matching score 1.",
"score": 1,
"uncertainty_note": "The text calls EIP-2935 inspiration rather than a normative dependency.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 4788,
"evaluation_date": "2026-08-25",
"fork": "cancun",
"id": "cancun:4788:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The opcode gas identifier in prose does not match the constants table.",
"The modulo ring buffer stores no slot tag, so the stated absent-root behavior is ambiguous after overwrite.",
"The draft does not define convert_to_slot or the execution/consensus interface carrying the root."
],
"provenance": {
"assessed_revision": {
"commit": "5b909b76ac2bed7fbf710b8896217e60f1c0f822",
"committed_at": "2023-04-13T13:59:33Z",
"content_sha256": "4df9dad7b1f5db2d27dd277bc04edfe12e16c2e7cf966f4db305101c6ebe81eb",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4788.md",
"git_blob_sha": "a2553d4b785e7b1231d42a99afce0ef697675d05",
"immutable_url": "https://github.com/ethereum/EIPs/blob/5b909b76ac2bed7fbf710b8896217e60f1c0f822/EIPS/eip-4788.md",
"information_cutoff_at": "2023-04-27",
"path": "EIPS/eip-4788.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-4788.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/cancun/eip-4788.yaml",
"sha256": "ed18b58392a99aa3b7521e63b549da3fc1b59eaa388e6064f6af877a4c6556ab"
},
"supporting_documents": [
"supporting/eip-2935.md",
"supporting/ethereum-consensus-specs--ssz-simple-serialize.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 38,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the assessment cutoff, EIP-4788 proposed appending the 32-byte parent beacon-block hash-tree root to every post-fork execution header. Before transactions, execution processing would write that root into a slot-keyed, modulo-8192 state ring buffer, and a new fixed-cost BEACON_ROOT opcode would expose reads from that storage. The document was still Draft and left its tests, reference implementation, security analysis, and several consensus-critical details unresolved.",
"tier": "high",
"title": "Beacon block root in the EVM",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"added_system_contracts",
"added_opcodes",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 44,
"minimum": 29
},
"present": true,
"summary": "The draft makes a new consensus-layer value observable to execution while leaving timestamp-to-slot conversion, the exact gas constant and charge ordering, the cross-layer payload/interface path, history-account initialization, and ring-buffer freshness behavior unresolved. Its tests, reference implementation, and security considerations are also TODO.",
"unresolved_questions": [
"How are execution timestamps converted to consensus slot numbers, including at the fork boundary?",
"Is the opcode cost G_beacon_root or the undefined G_beacon_state_root, and when is it charged relative to stack and storage access?",
"How is the parent beacon root delivered to and validated by the execution client and transition tooling?",
"How is the fixed-address history account initialized or protected if state already exists there?",
"Must a query for an overwritten modulo-8192 slot return the newer root, or zero as the absent-root prose suggests?",
"What timestamp or slot-gap bounds limit the pre-block write loop?"
]
}
},
"cancun:4844:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Opcode to get versioned hashes and Point evaluation precompile, lines 237-274",
"source": "eip.md",
"summary": "The new DATAHASH opcode has a fixed three-gas cost and the new point-evaluation precompile has a fixed 50,000-gas cost.\n"
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The normal EVM gas mechanism is extended with fixed charges for one opcode and one precompile, but no new execution-gas meter or interaction with existing EVM gas rules is introduced. The independent data-gas mechanism is scored in its dedicated criterion, leaving this at the anchor-1 existing-mechanism update.\n",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Opcode to get versioned hashes, lines 237-242",
"source": "eip.md",
"summary": "DATAHASH reads an index and returns a value from the transaction's versioned-hash list or zero; it neither accesses state nor changes gas charging around a state access.\n"
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No existing opcode's state-access path or gas-charge ordering is changed, and the sole new opcode is not state-accessing. The anchor therefore remains zero.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Header extension and Gas accounting, lines 177-219 and 276-312",
"source": "eip.md",
"summary": "A persistent excess-data-gas header value drives an independent exponential data-gas price; blob transactions gain affordability and fee-cap validity checks, and the actual data fee is deducted and burned even on failure.\n"
},
{
"locator": "Rationale — Data gasprice update rule, lines 422-433",
"source": "eip.md",
"summary": "The new self-correcting price responds to cumulative use relative to a target and is explicitly modeled after, but distinct from, EIP-1559.\n"
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "This is a new blob-gas accounting mechanism with persistent block state, its own target and pricing curve, transaction balance checks, fee caps, deduction, and burn. Its header and block-validity consequences affect ordinary block-processing and regression vectors, satisfying anchor 3.\n",
"score": 3,
"uncertainty_note": "The pricing pseudocode contains a header/parent naming inconsistency, but the existence and breadth of the mechanism are unambiguous.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Gas accounting, lines 276-312",
"source": "eip.md",
"summary": "The proposal defines data gas for blobs and a balance deduction; it does not define state-byte charging, a state-gas budget, or a spill path into execution gas.\n"
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The new meter prices blob data rather than state writes, so none of the rubric's state-gas mechanisms is changed.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Gas accounting, lines 296-312",
"source": "eip.md",
"summary": "The proposal states that the data fee is burned and is not refunded when a transaction fails.\n"
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM refund mechanism is introduced; the only explicit refund rule denies a data-fee refund.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — New transaction type through Beacon chain validation, lines 102-235",
"source": "eip.md",
"summary": "The proposal changes typed-transaction contexts, adds an SSZ transaction and network wrapper, extends every post-fork header, and requires beacon block, gossip, sync, and validator changes.\n"
},
{
"locator": "Specification — Gas accounting and Networking, lines 276-349",
"source": "eip.md",
"summary": "Block validity, sender affordability, fee deduction, transaction propagation, and wrapper validation all gain new rules.\n"
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing transaction, block/header, fork-transition, networking, syncing, and execution/consensus integration patterns require reworking across diverse test categories. That is a major, non-contrived regression surface and meets anchor 3.\n",
"score": 3,
"uncertainty_note": "The historical draft's Test Cases section is TBD, so the exact inventory of affected pre-existing suites is not stated.\n",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Header extension, lines 177-219",
"source": "eip.md",
"summary": "Every post-fork header gains excess_data_gas, whose expected value is derived from the parent and the new block's blob count, including an explicit first-block rule.\n"
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of pre-existing block tests must mechanically assert the new header field and its recurrence even when blob behavior is not their subject. The text does not establish that every test or pre-fork vector must be re-derived, so anchor 2 is the best fit rather than anchor 3.\n",
"score": 2,
"uncertainty_note": "The proposal does not describe the historical test harness or enumerate which vector families materialize complete headers.\n",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — New transaction type and Header extension, lines 102-219",
"source": "eip.md",
"summary": "State transition processing must consume a transaction with several new fields and SSZ encoding and must produce or validate a new parent-dependent header field.\n"
},
{
"locator": "Specification — Gas accounting, lines 276-312",
"source": "eip.md",
"summary": "Transition processing also needs a separate data-gas price, affordability cap, up-front deduction, and burn mechanism.\n"
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Representing blob transactions and the new header result requires multiple new interface fields, while data-gas accounting is a new transition mechanism. This matches anchor 3, although the draft does not name a concrete transition-tool API.\n",
"score": 3,
"uncertainty_note": "The exact transition-tool field layout and whether KZG validation is performed inside or outside that interface are unspecified.\n",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — New transaction type and Networking, lines 102-175 and 314-349",
"source": "eip.md",
"summary": "Tests need to build and distinguish SSZ signed payloads, minimal block encodings, network wrappers, blobs, commitments, and aggregate proofs.\n"
},
{
"locator": "Introduction and KZG public methods, lines 45-49 and 318-453",
"source": "supporting/ethereum-consensus-specs--specs-eip4844-polynomial-commitments.md",
"summary": "The KZG specification requires public library methods for commitments, point proofs, and aggregate proof construction and verification.\n"
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing transaction-test primitives cannot by themselves express blob fixtures, SSZ/network dual encodings, and KZG proof expectations. New reusable builders and expectations are required within the EIP suite, fitting anchor 2; the sealed text does not establish permanent reuse by other EIPs.\n",
"score": 2,
"uncertainty_note": "The EIP's Test Cases section is TBD and does not describe the test framework, so the precise primitive boundary is inferred from required fixture construction.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Cryptographic Helpers and Point evaluation precompile, lines 62-80 and 244-274",
"source": "eip.md",
"summary": "The proposal introduces versioned KZG commitments, point-evaluation proof verification, BLS-field canonicality checks, and a cryptographic precompile.\n"
},
{
"locator": "Preset, Fiat-Shamir challenges, and KZG, lines 70-94, 180-217, and 318-453",
"source": "supporting/ethereum-consensus-specs--specs-eip4844-polynomial-commitments.md",
"summary": "The sealed cryptographic specification defines a trusted setup, custom Fiat-Shamir aggregation, commitment and point-proof operations, and aggregate proof creation and verification.\n"
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Multiple new cryptographic mechanisms must be tested: KZG commitment and point verification plus a custom aggregated-proof protocol and its transcript, all dependent on a trusted setup. The custom aggregate construction supplies the novel component required by anchor 3.\n",
"score": 3,
"uncertainty_note": "Mainnet trusted-setup contents are still TBD in the packaged cryptographic specification, which affects final vectors but not this complexity classification.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Parameters, wrapper validation, DATAHASH, precompile, and gas accounting, lines 38-60, 149-161, 237-312",
"source": "eip.md",
"summary": "The design introduces list and per-block limits, equality among three wrapper lists, version-byte checks, indexed access with an out-of-range result, fixed input slices and field canonicality, fee caps, balance bounds, and a recurrent exponential price calculation.\n"
},
{
"locator": "Field conversion and aggregate proof functions, lines 153-178 and 388-453",
"source": "supporting/ethereum-consensus-specs--specs-eip4844-polynomial-commitments.md",
"summary": "Cryptographic handling includes modulus boundaries, empty aggregate inputs, equal-length requirements, and evaluation-domain division constraints.\n"
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Numerous independent boundaries combine across transaction shape, blob count, fees, header recurrence, field encoding, proof verification, and opcode indices. Cryptographic and pricing boundaries require an elevated matrix of cases, meeting anchor 3.\n",
"score": 3,
"uncertainty_note": "Some malformed-input outcomes are not fully specified, increasing rather than reducing the boundary-testing burden.\n",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Header extension and Beacon chain validation, lines 177-235",
"source": "eip.md",
"summary": "The execution header RLP gains a parent- and blob-dependent field, while beacon syncing must handle updated block types and separately propagated blob sidecars.\n"
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "The RLP header extension is not merely structural: sync validation must derive its value from the parent and blob content, while the associated block data is split into sidecars. This is best treated as a single complex block-validation change under anchor 2.\n",
"score": 2,
"uncertainty_note": "Detailed consensus sync rules are delegated to a linked directory whose packaged directory entry lists files but does not expose their contents other than the polynomial-commitment document.\n",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification — Header extension and Beacon chain validation, lines 177-235",
"source": "eip.md",
"summary": "The execution payload header gains excess_data_gas and the proposal assigns execution/consensus cross-verification for blob-bearing blocks.\n"
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "At minimum, the new execution-payload header value must cross the execution and consensus boundary as one additional payload field, matching anchor 1. The draft does not specify additional Engine API endpoints or an explicit interface schema.\n",
"score": 1,
"uncertainty_note": "Engine API directives are not named, and the transport and validation split for blob commitments and sidecars is not defined in the packaged text.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Opcode to get versioned hashes and Point evaluation precompile, lines 237-274",
"source": "eip.md",
"summary": "Execution access is added through an opcode and a precompile, not through a deployed system contract.\n"
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced; the cryptographic execution facility is scored as a precompile instead.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Opcode to get versioned hashes and Point evaluation precompile, lines 237-274",
"source": "eip.md",
"summary": "The proposal adds new execution facilities and specifies no change to any existing system contract's code, state, or behavior.\n"
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified, so the criterion is zero.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Opcode to get versioned hashes, lines 237-242",
"source": "eip.md",
"summary": "One DATAHASH opcode is added; it consumes one stack index, returns one hash or zero, and has a constant gas cost.\n"
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This is one simple opcode with no variable data portion, simple stack behavior, and constant gas, exactly matching anchor 1.\n",
"score": 1,
"uncertainty_note": "The result when DATAHASH executes in a non-blob transaction is not stated because those transactions lack the referenced blob_versioned_hashes member.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Opcode to get versioned hashes, lines 237-242",
"source": "eip.md",
"summary": "The proposal allocates and defines a new opcode and does not alter or deprecate an existing opcode.\n"
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode result or behavior changes.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Point evaluation precompile, lines 244-274",
"source": "eip.md",
"summary": "One precompile is added with a 192-byte field layout, a fixed gas charge, KZG verification, and a fixed 64-byte result on success.\n"
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The precompile has constant input layout and constant gas, so it is simple under this anchor; its substantial cryptographic complexity is separately scored.\n",
"score": 1,
"uncertainty_note": "Exact malformed-length failure handling is not explicit, but it does not make input length or gas dynamic.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Point evaluation precompile, lines 244-274",
"source": "eip.md",
"summary": "The EIP allocates a new precompile address and contains no modification to an existing precompile's gas schedule or logic.\n"
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — New transaction type and Header extension, lines 102-205",
"source": "eip.md",
"summary": "The new typed transaction uses SSZ, has distinct network and minimal encodings, extends EIP-2718 with wrapper data, and adds a field to the RLP header.\n"
},
{
"locator": "Specification — Networking, lines 314-349",
"source": "eip.md",
"summary": "The network payload is a new SSZ wrapper containing the signed transaction, commitments, blobs, and an aggregate proof.\n"
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal makes encoding changes at transaction, network-interface, execution- payload, and block-header levels. Encoding changes are binary-scored at anchor 3.\n",
"score": 3,
"uncertainty_note": "The EIP's Blob type differs in presentation from the byte-vector Blob type in the packaged polynomial specification, leaving a serialization detail to reconcile.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Parameters and New transaction type, lines 38-60 and 102-175",
"source": "eip.md",
"summary": "BLOB_TX_TYPE 0x05 is assigned to a new EIP-2718 SignedBlobTransaction with a specified SSZ container and signing rule.\n"
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "A new transaction type is explicitly introduced, which receives the criterion's binary anchor-3 score.\n",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — New transaction type, lines 139-175",
"source": "eip.md",
"summary": "Blob transaction validity couples signature recovery to SSZ tree hashing and checks version bytes, list cardinalities, commitment hashes, blob contents, and network-wrapper consistency.\n"
},
{
"locator": "Specification — Gas accounting and Networking, lines 276-349",
"source": "eip.md",
"summary": "Validity further depends on data-gas affordability and fee caps plus aggregate KZG verification of the network wrapper.\n"
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The new type brings several mutually dependent structural, cryptographic, fee, and wrapper-validity rules that require new encoders, proof fixtures, and invalid- case infrastructure. This is extensive test redesign under anchor 3.\n",
"score": 3,
"uncertainty_note": "Receipt encoding, malformed blob handling, and some applicability details are absent, so exact invalid-case expectations require agreement.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Header extension, lines 177-219",
"source": "eip.md",
"summary": "The RLP block header gains the 256-bit excess_data_gas field and a rule deriving it from the parent and current blob count.\n"
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "A new block-header field is explicitly introduced, so the binary anchor-3 score applies.\n",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Header extension, lines 177-220",
"source": "eip.md",
"summary": "For the first post-fork block the missing parent excess_data_gas value is simply evaluated as zero; no existing state or internal variable is mutated at activation.\n"
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The first-block rule initializes the new header recurrence. The rubric excludes initialization of a new internal variable, and no activation-block state change is specified, so the score is zero.\n",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, Beacon chain validation, and Throughput, lines 27-34, 221-235, and 435-437",
"source": "eip.md",
"summary": "All consensus nodes download blob data, beacon nodes persist it, gossip and sync sidecars, and validators produce them, with up to roughly 0.5 MB of new data per block.\n"
},
{
"locator": "Backwards Compatibility and Security Considerations, lines 443-470",
"source": "eip.md",
"summary": "Large mempool objects create a DoS concern, while bandwidth, block propagation, storage retention, and deletion policy all change.\n"
},
{
"locator": "Introduction and polynomial/KZG helpers, lines 45-49 and 241-453",
"source": "supporting/ethereum-consensus-specs--specs-eip4844-polynomial-commitments.md",
"summary": "Practical clients are expected to optimize expensive polynomial operations, multiscalar multiplication, proof construction, and aggregate verification.\n"
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "End-to-end behavior combines cryptographic computation, mempool admission, execution validation, consensus propagation, syncing, and storage. It cannot be fully benchmarked in isolation and substantially changes existing network and block-processing paths, satisfying anchor 3.\n",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — wrapper validation and Beacon chain validation, lines 149-161 and 221-235",
"source": "eip.md",
"summary": "Security-critical checks connect signed transactions, commitments, blob data, KZG proofs, execution processing, consensus availability, gossip, and syncing.\n"
},
{
"locator": "Backwards Compatibility and Security Considerations, lines 447-470",
"source": "eip.md",
"summary": "The draft identifies mempool amplification/DoS risk and increased consensus-node storage and propagation load.\n"
},
{
"locator": "Trusted setup, lines 85-94",
"source": "supporting/ethereum-consensus-specs--specs-eip4844-polynomial-commitments.md",
"summary": "Reuse of the mainnet trusted setup is called a critical security requirement, while its packaged values remain TBD.\n"
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The proposal alters assumptions across critical execution, consensus availability, P2P, fee-accounting, and cryptographic components. Failure can invalidate blocks, accept unavailable or uncommitted data, or expose nodes to resource attacks, so extensive cross-component review and fuzzing are required under anchor 3.\n",
"score": 3,
"uncertainty_note": "The unresolved trusted setup and malformed-input semantics are themselves material review items, but the risk tier is already clear.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — DATAHASH, precompile, gas accounting, and Networking, lines 237-349",
"source": "eip.md",
"summary": "The draft does not state DATAHASH behavior for transactions without a blob-hash member, gives slice-and-assert pseudocode without complete malformed-input outcomes, contains a header/parent variable inconsistency in fee calculation, and leaves a blob-malformation assertion as a note.\n"
},
{
"locator": "Test Cases, lines 458-460",
"source": "eip.md",
"summary": "The Test Cases section is TBD."
},
{
"locator": "Trusted setup, lines 85-94",
"source": "supporting/ethereum-consensus-specs--specs-eip4844-polynomial-commitments.md",
"summary": "Consensus-critical mainnet KZG setup vectors are explicitly TBD even though using the correct setup is called a critical security requirement.\n"
},
{
"locator": "Specification — Receipts, lines 39-47",
"source": "supporting/eip-2718.md",
"summary": "EIP-2718 requires each typed transaction's receipt type to match and delegates its ReceiptPayload definition to the new transaction EIP, while EIP-4844 does not define that payload.\n"
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Several constructable cases cannot be baselined from the draft alone, including non-blob DATAHASH execution, malformed precompile/wrapper inputs, blob receipt encoding, and final KZG preset data. These gaps require agreement but are localized to new mechanisms; they do not make a previously unobservable existing behavior consensus-critical, so anchor 2 fits better than anchor 3.\n",
"score": 2,
"uncertainty_note": "Detailed consensus and interface specifications are referenced but not present beyond a directory listing and the polynomial-commitment file in the sealed package.\n",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Specification — New transaction type, lines 1-12 and 102-159",
"source": "eip.md",
"summary": "EIP-4844 requires EIPs 1559, 2718, 2930, and 4895; it reuses EIP-1559 fee fields, extends EIP-2718 with network wrapper data, carries an EIP-2930 access list, and builds its header after the EIP-4895 withdrawals root.\n"
},
{
"locator": "Backwards Compatibility — Mempool issues, lines 447-456",
"source": "eip.md",
"summary": "EIP-5793 is identified as the companion announcement change that provides type- and size-aware control for large blob transactions.\n"
},
{
"locator": "Motivation and Specification, lines 18-31",
"source": "supporting/eip-5793.md",
"summary": "EIP-5793 explicitly responds to EIP-4844's large transaction type by modifying NewPooledTransactionHashes to carry transaction types and sizes.\n"
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
2718,
2930,
4895,
5793
],
"rationale": "Five identified EIPs interact with the proposal across transaction envelopes, fee semantics, access lists, header layout, and P2P propagation. The especially strong EIP-2718 and EIP-5793 coupling and the multi-EIP header/transaction matrix require coordinated testing, supporting base anchor 3. Five interactions do not reach the first uncapped bonus threshold of six, so no +1 is added.\n",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 4844,
"evaluation_date": "2026-08-25",
"fork": "cancun",
"id": "cancun:4844:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The EIP defines Blob as a vector of BLSFieldElement values, while the linked polynomial document defines Blob as a fixed byte vector; canonical boundary serialization is not reconciled in the packaged text.\n",
"calc_data_fee accepts parent but calls get_data_gasprice(header), leaving the intended argument name and pricing reference implicit.\n",
"DATAHASH reads tx.message.blob_versioned_hashes without defining behavior for legacy or other typed transactions that do not have that member.\n",
"EIP-2718 requires typed receipt payloads to be defined by their transaction EIPs, but this draft does not define the blob transaction receipt payload.\n",
"Mainnet KZG_SETUP_G1, KZG_SETUP_G2, and KZG_SETUP_LAGRANGE values are TBD despite their critical-security status.\n"
],
"provenance": {
"assessed_revision": {
"commit": "7eac5f7f4aeb7c6f251b5e4a5ebb92d14d307d93",
"committed_at": "2022-12-05T12:02:25Z",
"content_sha256": "014ecdd0aefff19c7c1a6bf5483f4ce3facf058580e2b82eae8ef4705268b7e1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4844.md",
"git_blob_sha": "df8423c5b84df39fa5e46a0529120d092cfcffb1",
"immutable_url": "https://github.com/ethereum/EIPs/blob/7eac5f7f4aeb7c6f251b5e4a5ebb92d14d307d93/EIPS/eip-4844.md",
"information_cutoff_at": "2022-12-08",
"path": "EIPS/eip-4844.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-4844.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/cancun/eip-4844.yaml",
"sha256": "25ca3d731ccc5d04468face8727ad261a07f85a9f65d5afea53aa40669bdc7db"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-2718.md",
"supporting/eip-2930.md",
"supporting/eip-4895.md",
"supporting/eip-5793.md",
"supporting/ethereum-consensus-specs--specs-eip4844",
"supporting/ethereum-consensus-specs--specs-eip4844-polynomial-commitments.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 48,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this draft introduced an EIP-2718 blob-carrying transaction whose signed payload used SSZ and whose network form additionally carried blobs, KZG commitments, and an aggregate proof. It added a block-header excess-data-gas field, an independent data-gas fee market and burn, a DATAHASH opcode, and a KZG point-evaluation precompile. It also assigned blob persistence and availability to the consensus layer through separately propagated sidecars and changed execution-layer transaction propagation to announcement and on-demand retrieval.\n",
"tier": "high",
"title": "Shard Blob Transactions",
"under_specification": {
"affected_criteria": [
"blob_gas_accounting_changes",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"cryptography",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"added_opcodes",
"added_precompiles",
"encoding_changes_rlp_ssz",
"new_or_modified_transaction_validity_mechanisms",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 52,
"minimum": 44
},
"present": true,
"summary": "Material gaps remain in consensus-test inputs and interface behavior: the mainnet KZG setup is TBD; DATAHASH behavior outside blob transactions is not stated; blob receipt encoding is absent; malformed blob-wrapper and precompile cases are not fully determined; the Blob representation differs between the EIP and its linked cryptographic specification; and Engine API and transition-tool schemas are not defined. The Test Cases section is also TBD, and detailed consensus specifications are represented in the capsule only by a directory listing plus the polynomial document.\n",
"unresolved_questions": [
"What does DATAHASH return when the current transaction has no blob_versioned_hashes field?",
"What exact ReceiptPayload and receipt encoding apply to the new EIP-2718 transaction type?",
"What are the canonical mainnet trusted-setup contents and roots-of-unity preset used by all clients and vectors?",
"How are short, long, non-canonical, or otherwise malformed point-precompile inputs rejected?",
"Which blob and wrapper malformations are rejected, at what validation stage, and with which per-transaction size limit?",
"Is Blob canonically an SSZ vector of uint256 field elements or a fixed byte vector at the execution/network boundary?",
"Which Engine API and transition-tool fields carry the new header, blob, commitment, and validation information?",
"Does calc_data_fee use its parent argument where its body refers to header, and which block's excess value prices a transaction?"
]
}
},
"cancun:5656:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Gas costs, lines 71-80; Semantics, lines 91-93",
"source": "eip.md",
"summary": "MCOPY is assigned to the existing W_copy opcode group, with very-low base gas, a per-word copy charge, and the ordinary memory-expansion charge."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal extends an existing EVM gas-accounting mechanism to one new opcode. This matches score 1: an existing mechanism is updated, rather than a distinct new mechanism being introduced or existing opcode gas changing.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Semantics, lines 86-93",
"source": "eip.md",
"summary": "The instruction reads and writes only EVM memory and charges for copying and memory expansion; it performs no account or storage access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state access is added or reordered, and no gas charge is moved relative to a state access, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Gas costs, lines 71-80",
"source": "eip.md",
"summary": "The proposal is limited to memory copying and specifies only ordinary EVM opcode gas and memory-expansion gas."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob resource or blob-gas rule is introduced or changed; this is score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Semantics, lines 86-93",
"source": "eip.md",
"summary": "MCOPY changes transient memory only and its gas schedule contains copy and memory-expansion costs, not charges for writing persistent state."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal has no state-gas charging site, budget, reservoir, or spill interaction, satisfying the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas costs, lines 71-80; Semantics, lines 91-93",
"source": "eip.md",
"summary": "The specification defines gas charged for MCOPY and memory expansion but defines no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 102-104",
"source": "eip.md",
"summary": "Opcode 0xb7 changes from a previously nonexistent instruction to MCOPY, and the EIP notes that already-deployed code using it can change behavior."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A narrow subset of pre-fork tests exercising the formerly invalid opcode or fork-transition bytecode behavior must be reworked. That is the minor-subset impact described by score 1, not a broad rewrite of existing tests.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93; Test Cases, lines 106-161",
"source": "eip.md",
"summary": "The specification and examples define results for executions that invoke MCOPY; they do not define a new output that unrelated tests must assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing tests not concerned with MCOPY gain no cross-cutting assertion, so this criterion scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "All specified inputs and outputs belong to the EVM operand stack and memory; no transition-tool request or response field is introduced."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The transition-tool interface needs no field or mechanism change, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 106-161",
"source": "eip.md",
"summary": "The examples are ordinary opcode executions expressed as pre- and post-memory values, including same-range and overlapping copies."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Standard bytecode execution, gas, failure, and memory-result assertions can express the feature's tests; no new expectation or modifier primitive is required by the text. This matches score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Semantics, lines 86-93",
"source": "eip.md",
"summary": "MCOPY copies bytes within memory and introduces no cryptographic function or verification mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography is introduced or modified, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 26-33; Gas costs and Semantics, lines 71-93",
"source": "eip.md",
"summary": "The proposal covers arbitrary offsets and lengths, per-word rounding, partial words, overlap via intermediate-buffer semantics, the zero-length guard, and source- or destination-driven memory expansion."
},
{
"locator": "Test Cases, lines 108-161",
"source": "eip.md",
"summary": "The examples separately exercise an ordinary copy, identical source and destination, and overlaps in both directions."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Several independent boundary-prone dimensions are introduced: zero versus nonzero length, 32-byte rounding and partial words, overlap direction and equality, and expansion caused by either range. Overlap and expansion must also be combined across arbitrary offsets and lengths, producing an elevated case matrix; this meets score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The only consensus rule added is an EVM instruction over stack and memory; no block encoding or RLP validation rule is specified."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Block RLP validation and client syncing are unchanged, satisfying score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The feature is completely specified as an EVM opcode and defines no execution/consensus-client communication field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism changes; score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The proposal adds opcode 0xb7 directly to the EVM and specifies no contract address, code deployment, persistent state, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, so this criterion scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Semantics, lines 86-93",
"source": "eip.md",
"summary": "MCOPY's effects are confined to the executing frame's memory and do not call, read, write, or otherwise identify a system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified; score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The EIP introduces one opcode, MCOPY at 0xb7, taking destination, source, and length, copying a variable-size memory region, and charging dynamic per-word plus memory-expansion gas."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This is a single complex opcode because it processes a variable data portion and has dynamic gas. It therefore matches the score-2 anchor exactly.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93; Backwards Compatibility, lines 102-104",
"source": "eip.md",
"summary": "The proposal creates a previously nonexistent instruction at 0xb7; it does not change the result or deprecate any pre-existing opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Adding MCOPY is scored under Added opcodes, while no existing opcode behavior is modified; this criterion is score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 21-24; Specification, lines 57-59",
"source": "eip.md",
"summary": "The existing identity precompile is discussed only as an alternative; the actual proposal introduces MCOPY as opcode 0xb7."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 21-24; Rationale, lines 95-100",
"source": "eip.md",
"summary": "The document compares MCOPY with the existing identity precompile and its call overhead but specifies no change to that precompile's logic or gas."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "The identity precompile remains unchanged and no other precompile is altered; this criterion scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The proposal defines an opcode byte, stack operands, and memory semantics, without changing transaction, block, or interface serialization."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, transaction, block, or interface encoding changes; score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Specification, lines 57-93",
"source": "eip.md",
"summary": "EIP-5656 introduces an EVM memory instruction and contains no transaction envelope or transaction-type definition."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, so this criterion scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The specification governs execution of MCOPY after valid bytecode is run; it defines no transaction admission, validity, or intrinsic-gas rule."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity and intrinsic gas are unchanged; score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The proposal's complete specified data consists of an opcode's stack inputs and memory effects; it introduces no block or header value."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is added, so this criterion scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 57-93; Backwards Compatibility, lines 102-104",
"source": "eip.md",
"summary": "Activation makes opcode 0xb7 execute as MCOPY, but the EIP prescribes no activation-block state write or modification of an internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork-gated opcode availability is not the state/internal-variable mutation covered by this anchor; no new activation mechanism exists, score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 35-55; Gas costs and Semantics, lines 71-93",
"source": "eip.md",
"summary": "MCOPY is intended to accelerate common and computationally heavy memory copying, while accepting an arbitrary length and charging per copied word plus memory expansion."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Variable-size copying warrants validating that implementation work tracks its gas schedule, but the opcode is memory-only and can be benchmarked directly across lengths and overlap cases. It does not alter the performance path of existing opcodes, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Semantics, lines 86-93; Security Considerations, lines 164-166",
"source": "eip.md",
"summary": "The new mechanism is confined to memory copying, overlap behavior, dynamic copy gas, and memory expansion, while the security section remains TBA."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect overlap, bounds, or gas handling could create divergent execution, but the mechanism is self-contained and testable in isolation and does not alter state or cross-component security invariants. This matches score 1.",
"score": 1,
"uncertainty_note": "The historical proposal contains no substantive security analysis, so the risk classification rests on the specified memory-only scope.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 57-93",
"source": "eip.md",
"summary": "The text fixes the opcode byte, stack ordering, output arity, W_copy gas basis, byte-copy result, intermediate-buffer overlap semantics, and the condition and cost for memory expansion."
},
{
"locator": "Test Cases, lines 108-161",
"source": "eip.md",
"summary": "Concrete results cover ordinary, identical-range, and both directional overlap cases, reinforcing the specified copy semantics."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Every proposal-specific constructible case is determined by the supplied rules together with the explicitly incorporated existing W_copy calculation; no localized detail is left for clients to agree before baselining tests. The score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 21-24 and 35-47; Rationale, lines 95-100",
"source": "eip.md",
"summary": "EIP-2929 appears only in the economic comparison with memory copying through CALL to the identity precompile; MCOPY itself is independently specified."
},
{
"locator": "Abstract, lines 16-18; Storage read changes, lines 58-71",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 changes state-access and CALL-family costs and exempts precompiles; it defines no rule on which MCOPY's semantics or gas calculation depends."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The cited EIP-2929 change explains why an alternative copying technique has particular overhead, but EIP-5656 neither depends on, modifies, nor conflicts with EIP-2929. The feature can be implemented and tested independently, so it is self-contained under the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 5656,
"evaluation_date": "2026-08-25",
"fork": "cancun",
"id": "cancun:5656:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The security-considerations section is TBA, which limits explicit risk analysis but does not leave MCOPY execution behavior unresolved."
],
"provenance": {
"assessed_revision": {
"commit": "e9b6a228f04f13fbfa80552210c70a03fca36928",
"committed_at": "2023-05-11T19:30:56Z",
"content_sha256": "96c6320bdf154a7997f5c153e8d079ce9fb5d6dba813b8b97f0e28cfb323cc39",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5656.md",
"git_blob_sha": "3682a57c253779ed830f21576cdd77d438c5e46b",
"immutable_url": "https://github.com/ethereum/EIPs/blob/e9b6a228f04f13fbfa80552210c70a03fca36928/EIPS/eip-5656.md",
"information_cutoff_at": "2023-05-25",
"path": "EIPS/eip-5656.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-5656.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/cancun/eip-5656.yaml",
"sha256": "a7414c59426fee3da3ab8d2905a4449cff22beb240dd46f45e984ee223892b00"
},
"supporting_documents": [
"supporting/eip-2929.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 9,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the 2023-05-25 information cutoff, EIP-5656 introduced the single MCOPY instruction at opcode 0xb7 to copy an arbitrary byte range within EVM memory. It specified three stack inputs, no output, memmove-like overlap semantics, memory expansion, and dynamic gas by adding the instruction to the existing W_copy group. The proposal did not change state, transactions, blocks, interfaces, precompiles, or system contracts.",
"tier": "low",
"title": "MCOPY - Memory copying instruction",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 9,
"minimum": 9
},
"present": false,
"summary": "No material proposal-specific behavior is under-specified. The opcode's inputs, output arity, copy result, overlap behavior, memory expansion, and gas basis are defined sufficiently to baseline tests; the TBA security section is an analysis gap rather than an unresolved execution rule.",
"unresolved_questions": []
}
},
"cancun:6780:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-41",
"source": "eip.md",
"summary": "Both semantic branches expressly retain the EIP-3529 no-refund rule and the EIP-2929 SELFDESTRUCT gas/access rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes SELFDESTRUCT's state result, but introduces no gas accounting change and explicitly preserves the applicable existing rules.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The specification changes whether code, storage, and the account are deleted, while saying that EIP-2929's SELFDESTRUCT rules remain unchanged."
},
{
"locator": "Specification - SELFDESTRUCT changes, lines 88-92",
"source": "supporting/eip-2929.md",
"summary": "The preserved EIP-2929 rule charges and records a cold beneficiary address; EIP-6780 does not relocate that access or charge."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state access is moved within opcode execution and no gas charge is moved relative to an access, so the ordering-specific anchor is not triggered.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-44",
"source": "eip.md",
"summary": "The proposal is confined to SELFDESTRUCT execution behavior and contains no blob-gas rule or blob-related field."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The specification changes which state objects SELFDESTRUCT deletes but defines no state-gas price, state-byte rate, budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Changing state writes is not itself a change to the rubric's separate state gas accounting mechanism; no such accounting mechanism appears here.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-41",
"source": "eip.md",
"summary": "Both branches state that no refund is given under EIP-3529."
},
{
"locator": "Specification, lines 25-41",
"source": "supporting/eip-3529.md",
"summary": "EIP-3529 removed the SELFDESTRUCT refund, which EIP-6780 explicitly leaves unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no new refund mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 24-54",
"source": "eip.md",
"summary": "Pre-existing SELFDESTRUCT vectors must distinguish contracts created in the current transaction from older contracts and change expected deletion for the latter; CREATE2 recreation across transactions is explicitly breaking."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests that exercise SELFDESTRUCT state deletion require reworking, but they are a narrow opcode-specific subset rather than a broad class of the test corpus.",
"score": 1,
"uncertainty_note": "The package does not enumerate the pre-existing test corpus, so the relative size of the affected subset is inferred from the proposal's single-opcode scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "The new conditions alter expected SELFDESTRUCT results but do not define an additional output or invariant that tests unrelated to this EIP must assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Affected SELFDESTRUCT tests need changed expectations; unrelated pre-existing tests do not gain a mechanically added assertion.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "The proposal defines an execution-rule branch using transaction-local creation timing and adds no input or output interface field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 24-42",
"source": "eip.md",
"summary": "The two outcomes can be constructed with ordinary contract-creation and transaction sequences and observed through ordinary post-state behavior."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The historical text does not require a new expectation type, modifier, or reusable test-framework abstraction; existing transaction and state checks suffice.",
"score": 0,
"uncertainty_note": "No packaged test-framework description is available, so sufficiency is judged from the protocol behavior exposed by the EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-44",
"source": "eip.md",
"summary": "The proposal changes account deletion and balance-transfer semantics and introduces no cryptographic algorithm or cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "SELFDESTRUCT has two state-result branches at the same-transaction creation boundary, covering code/storage deletion, account emptiness, balance transfer, and subsequent behavior in the current and later transactions."
},
{
"locator": "Backwards Compatibility, lines 50-54",
"source": "eip.md",
"summary": "CREATE2 recreation at an address after a prior-transaction SELFDESTRUCT is singled out as the breaking boundary case."
},
{
"locator": "Specification - SELFDESTRUCT changes, lines 88-92",
"source": "supporting/eip-2929.md",
"summary": "Beneficiary warm/cold status remains an independent SELFDESTRUCT dimension that must be combined with the new semantic branches."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone effects require a large case matrix: creation by transaction/CREATE/CREATE2, current-versus-prior transaction, later access to code/storage/account, beneficiary state, and address recreation. At least the creation-timing and recreation mechanisms require elevated combinatorial coverage.",
"score": 3,
"uncertainty_note": "The draft gives no test plan, and some lifecycle cases within this matrix are not normatively resolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "The specification changes opcode execution and contains no block RLP or block-validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No RLP validation mechanism requiring syncing is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-44",
"source": "eip.md",
"summary": "The entire normative change is within SELFDESTRUCT execution; no Engine API endpoint, field, or communication mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "The proposal changes an opcode and deploys no contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 24-54",
"source": "eip.md",
"summary": "The proposal describes general account and application behavior but identifies no pre-existing system contract whose code, state, or operation is affected."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or package-identified indirect system-contract modification exists.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-16",
"source": "eip.md",
"summary": "The proposal changes the functionality of the existing SELFDESTRUCT opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-44",
"source": "eip.md",
"summary": "SELFDESTRUCT's non-gas behavior is changed so deletion occurs only for a contract created in the same transaction, while older contracts retain code and storage."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The rubric assigns 3 whenever at least one existing opcode's non-gas behavior is modified; SELFDESTRUCT is explicitly modified.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "The normative change concerns SELFDESTRUCT and adds no precompile address or logic."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "No precompile behavior or gas schedule appears in the proposal."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "The execution semantic change defines no transaction, block, or interface encoding change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface-level encoding is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 24-44",
"source": "eip.md",
"summary": "The proposal applies new semantics during ordinary transaction execution and defines no transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 24-54",
"source": "eip.md",
"summary": "The hard-fork change governs SELFDESTRUCT's execution result and does not alter transaction validity or intrinsic gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validation mechanism is added or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-44",
"source": "eip.md",
"summary": "The specification contains no new block body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 50-54",
"source": "eip.md",
"summary": "The EIP says a hard fork is required because consensus execution rules change, but specifies no activation-block state mutation or internal-variable modification."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork-gated execution semantics do not constitute the rubric's special activation-block modification mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 18-22",
"source": "eip.md",
"summary": "Existing SELFDESTRUCT can remove all code and storage and therefore causes large, storage-size-dependent state changes that the proposal seeks to avoid."
},
{
"locator": "Specification, lines 24-42",
"source": "eip.md",
"summary": "The proposal preserves deletion for current-transaction creations but removes it for older contracts, making performance dependent on creation timing and the affected account state."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance validation cannot be fully isolated from account storage size and transaction lifecycle, but the impact is limited to SELFDESTRUCT and its two branches rather than broad execution benchmarks.",
"score": 2,
"uncertainty_note": "The package provides motivation but no benchmarks or implementation detail, so the magnitude of the residual tracking and deletion costs is not quantified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility and Security Considerations, lines 50-60",
"source": "eip.md",
"summary": "Cross-transaction CREATE2 destruction-and-redeployment is explicitly broken, and applications using SELFDESTRUCT for that upgrade pattern are declared unsafe."
},
{
"locator": "Security Considerations - Do Not Self Destruct, lines 420-425",
"source": "supporting/eip-2535.md",
"summary": "The recommended alternative standard itself warns that SELFDESTRUCT misuse can delete a diamond or facet, illustrating the security sensitivity of migration."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The new semantics alter the code/storage deletion invariant and interact with CREATE2-based application upgrade assumptions. The affected components are limited enough for targeted security review and fuzzing rather than an extensive chain-wide review.",
"score": 2,
"uncertainty_note": "The EIP identifies one unsafe application pattern but does not exhaustively analyze other contracts that rely on account deletion.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 26-42",
"source": "eip.md",
"summary": "The new consensus branch depends on whether the executing contract was created in the same transaction, but the draft does not define the lifecycle of that predicate through nested creation, reversion, destruction, and address reuse."
},
{
"locator": "Abstract and Specification, lines 14-16 and 28-39",
"source": "eip.md",
"summary": "The abstract calls the transfer recipient the caller, while the specification calls it the target; the old-contract branch says transfer the entire balance but, unlike the new-contract branch, does not separately require setting the source balance to zero."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Creation history becomes a new consensus-critical discriminator for opcode results even though its difficult lifecycle cases were not previously observable through this semantic distinction. Constructible tests need agreement on those cases and on self-beneficiary balance behavior before stable baselines can be set.",
"score": 3,
"uncertainty_note": "The package records a Draft only three days after creation and contains no packaged resolution of these cases; later amendments or implementation knowledge were deliberately not consulted.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter and Specification, lines 1-12 and 24-44",
"source": "eip.md",
"summary": "The proposal declares requirements on EIPs 2681, 2929, and 3529; it explicitly preserves the latter two SELFDESTRUCT gas/refund rules and EIP-6049 deprecation."
},
{
"locator": "Rationale, lines 46-48",
"source": "eip.md",
"summary": "EIP-6046 is discussed as a rejected alternative whose storage-preservation and contract-removal design conflicts with the selected semantics."
},
{
"locator": "Specification - SELFDESTRUCT changes, lines 88-92",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 supplies the cold-beneficiary gas/access rule that remains active."
},
{
"locator": "Specification, lines 25-41",
"source": "supporting/eip-3529.md",
"summary": "EIP-3529 supplies the removed SELFDESTRUCT refund that remains active."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2681,
2929,
3529,
6046,
6049
],
"rationale": "Coordinated testing is needed across the new semantic branch, EIP-2929 access charging, and EIP-3529 refund behavior, while EIPs 2681, 6049, and the conflicting 6046 proposal add limited dependency/deprecation/design context. These interactions are multiple but localized to SELFDESTRUCT and creation behavior, matching score 2; five identified EIPs do not form the first complete group of three interactions beyond the initial three, so they do not trigger the uncapped increment.",
"score": 2,
"uncertainty_note": "EIP-2681 is declared as required without an explicit explanation of its role in the normative text; EIP-6046 is an alternative rather than a co-activated dependency.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 6780,
"evaluation_date": "2026-08-25",
"fork": "cancun",
"id": "cancun:6780:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The front matter requires EIP-2681, but the normative text does not explain how its account-nonce limit participates in EIP-6780.",
"The same-transaction branch explicitly sets the source balance to zero after transfer, while the other branch states only that the entire balance is transferred.",
"The alternative EIP-6046 is characterized briefly in EIP-6780, so it is treated as a design conflict rather than as a co-activated dependency."
],
"provenance": {
"assessed_revision": {
"commit": "a3d07639302c9664c11b1f2d693b4537402748f5",
"committed_at": "2023-03-28T20:27:21Z",
"content_sha256": "111c746d16b47cc1bb0f21f0fb0e7244105a01e529ae8282642b531af04d0363",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6780.md",
"git_blob_sha": "2f8299df31bb8173618901a03a8366a3183479b0",
"immutable_url": "https://github.com/ethereum/EIPs/blob/a3d07639302c9664c11b1f2d693b4537402748f5/EIPS/eip-6780.md",
"information_cutoff_at": "2023-03-30",
"path": "EIPS/eip-6780.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-6780.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/cancun/eip-6780.yaml",
"sha256": "bf3c82056837f819d6a8afdc382a391e6e48cadac34627d34dfc1b7ab4ead889"
},
"supporting_documents": [
"supporting/eip-2535.md",
"supporting/eip-2681.md",
"supporting/eip-2929.md",
"supporting/eip-3529.md",
"supporting/eip-6046.md",
"supporting/eip-6049.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 16,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the 2023-03-30 information cutoff, draft EIP-6780 changed the existing SELFDESTRUCT opcode so that a contract not created in the current transaction retained its code and storage while transferring its balance to the target. Contracts created and self-destructed in the same transaction retained the prior deletion behavior, with the existing EIP-2929 access rules, EIP-3529 no-refund rule, and EIP-6049 deprecation left in place. The proposal identified CREATE2 address recreation across transactions as its breaking application pattern.",
"tier": "medium",
"title": "SELFDESTRUCT only in same transaction",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"modified_opcodes",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 16,
"minimum": 14
},
"present": true,
"summary": "Material localized under-specification remains around the definition and rollback lifecycle of \"created in the same transaction,\" address reuse after destruction, and the balance result when the SELFDESTRUCT target is the executing account. The abstract's \"caller\" terminology also conflicts with the specification's \"target.\"",
"unresolved_questions": [
"Precisely which successful creation events mark an address as created in the transaction, and how is that status rolled back across reverted nested scopes?",
"If an address is destroyed, accessed, or recreated again within the same transaction, which branch applies and at what point must it behave as empty?",
"When the SELFDESTRUCT target equals the executing account, must the non-creation branch end with a zero balance, as the creation branch explicitly requires?",
"Does \"caller\" in the abstract mean the beneficiary/target, or does it prescribe a different recipient from the target named in the specification?"
]
}
},
"cancun:7516:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The new opcode is assigned a fixed cost of 2 gas while retaining the ordinary zero-input, one-output opcode execution shape."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Adding a constant gas-schedule entry for one opcode updates the existing per-opcode EVM gas mechanism; it does not create a new or dynamic gas accounting mechanism. This matches score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Gas cost, lines 35-40",
"source": "eip.md",
"summary": "The EIP says the blob base-fee value is already available before EVM execution and that the opcode adds no read or write operations."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The opcode reads no account or storage state and introduces no gas charge relative to a state access, so no state-access ordering changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "BLOBBASEFEE returns the result of EIP-4844's existing get_blob_gasprice(header) function rather than defining or changing that function."
},
{
"locator": "Gas accounting, lines 164-186",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 independently defines blob gas, its price calculation, and fee deduction; EIP-7516 only exposes the calculated price to EVM code."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Exposing an already-defined price is not an update to blob gas accounting and introduces no new blob gas accounting mechanism. The anchor therefore remains at 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 25-40",
"source": "eip.md",
"summary": "The complete change is a read-only opcode returning a header-derived value, with no state write or state-gas rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas cost, charging site, budget, reservoir, or execution-gas spill behavior is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The specification assigns the opcode a fixed gas cost and defines only its stack result; it defines no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "Byte 0x49 is made a valid constant-cost opcode with defined stack output."
},
{
"locator": "Parameters and Opcode to get versioned hashes, lines 55-56 and 188-193",
"source": "supporting/eip-4844.md",
"summary": "The packaged EIP-4844 revision assigns the same byte to BLOBHASH with a different cost and stack behavior."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing invalid-opcode coverage for byte 0x49, and any EIP-4844 BLOBHASH vectors at this shared cutoff, cannot retain their prior expected behavior. This is a narrow subset of EVM tests rather than a broad validation-pattern rewrite, matching score 1.",
"score": 1,
"uncertainty_note": "The package does not include a pre-existing test corpus, and EIP-4844's own Test Cases section is TBD, so the exact number of affected vectors is not established.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Test Cases, lines 25-33 and 46-61",
"source": "eip.md",
"summary": "The EIP defines behavior and a nominal test for the new opcode only; it does not require unrelated tests to assert a new block-wide output."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests not concerned with this opcode gain no additional invariant to assert, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Gas cost, lines 35-40",
"source": "eip.md",
"summary": "The EIP states that transaction processing already makes the blob base-fee value available before EVM code executes."
},
{
"locator": "Header extension and Gas accounting, lines 119-182",
"source": "supporting/eip-4844.md",
"summary": "The required EIP-4844 supplies the header inputs and price function on which the opcode depends."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "EIP-7516 requires the EVM to expose context already supplied by its EIP-4844 dependency; it specifies no additional transition-tool field or interface mechanism.",
"score": 0,
"uncertainty_note": "The package does not specify an actual transition-tool interface, so this score relies on the EIP's statement that the value is already available.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases / Nominal case, lines 46-61",
"source": "eip.md",
"summary": "The supplied test is ordinary bytecode execution with gas and stack expectations for BLOBBASEFEE followed by STOP."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing opcode execution, stack, and gas assertions can express the proposed test; no new framework abstraction is required.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The opcode returns an integer price obtained from a referenced accounting function and specifies no cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Although EIP-4844 contains cryptography elsewhere, EIP-7516 neither invokes nor changes it; no cryptographic mechanism is attributable to this EIP.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Test Cases, lines 25-33 and 46-61",
"source": "eip.md",
"summary": "The opcode pushes the integer returned by get_blob_gasprice, while the only example describes a small value as a left-padded byte32."
},
{
"locator": "Helpers and Gas accounting, lines 83-95 and 164-182",
"source": "supporting/eip-4844.md",
"summary": "The referenced price is produced by an integer exponential approximation over header excess_blob_gas, with no result-width bound stated there."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The single boundary-prone mechanism is mapping the calculated integer into one 256-bit EVM stack word, particularly at the word-width limit. This is one localized boundary axis and matches score 1.",
"score": 1,
"uncertainty_note": "The package does not state what BLOBBASEFEE does if the referenced integer is wider than one EVM stack word, nor does it establish whether every such value is reachable under valid-header rules.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The proposal adds only an EVM opcode and does not change block RLP or add block-validation fields."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No RLP validation mechanism requiring client syncing is introduced by this EIP.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The full normative change concerns opcode number, stack arity, cost, and returned EIP-4844 value; no Engine API directive is mentioned."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The EIP adds an opcode directly and specifies no contract address, code, state, or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 25-33 and 42-44",
"source": "eip.md",
"summary": "The proposal is limited to a new opcode and reports no backward compatibility effect; it specifies no system-contract change."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system contract's code, state, or behavior is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "BLOBBASEFEE is specified as one opcode with no inputs, one output, a constant cost of 2, and no data portion or complex stack mechanics."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "On its stated design this is exactly one simple constant-cost opcode, matching score 1.",
"score": 1,
"uncertainty_note": "The claimed new opcode number collides with EIP-4844's BLOBHASH allocation; the primary score follows EIP-7516's stated intent to add an opcode, while a resolution could instead require relocation or modification of BLOBHASH.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 25-33",
"source": "eip.md",
"summary": "EIP-7516 describes BLOBBASEFEE as an added opcode modeled on BASEFEE, not as a behavioral change to an existing opcode."
},
{
"locator": "Parameters and Opcode to get versioned hashes, lines 55-56 and 188-193",
"source": "supporting/eip-4844.md",
"summary": "The package nevertheless shows a conflicting BLOBHASH definition at the same byte in the required EIP-4844 revision."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The EIP does not normatively say that BLOBHASH or any other pre-existing opcode is modified or deprecated. The allocation conflict is scored as under-specification and cross-EIP interaction rather than treating an unstated conflict resolution as a modification.",
"score": 0,
"uncertainty_note": "If 0x49 were intended to replace EIP-4844's BLOBHASH rather than being a mistaken allocation, this anchor would be 3 under its binary definition.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The proposal adds an opcode at a byte value, not a contract-addressed precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced by EIP-7516.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The only specified mechanism is BLOBBASEFEE; no existing precompile logic or gas schedule is referenced for modification."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The opcode definition changes EVM bytecode semantics but specifies no transaction, block, RLP, SSZ, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No encoding change at the transaction, block, or interface level is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 25-33",
"source": "eip.md",
"summary": "EIP-7516 adds an opcode that reads a value defined by EIP-4844 and does not define a transaction envelope or type identifier."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "EIP-4844's blob transaction is a dependency, not a new transaction type introduced by EIP-7516.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The normative change defines opcode execution and contains no transaction validity or intrinsic-gas rule."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Reading the existing blob gas price from EVM code does not add or modify a transaction validity mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 25-40",
"source": "eip.md",
"summary": "The opcode exposes a value already available from the current header and does not specify a new field."
},
{
"locator": "Header extension, lines 119-162",
"source": "supporting/eip-4844.md",
"summary": "The blob_gas_used and excess_blob_gas header fields are introduced by the required EIP-4844, independently of EIP-7516."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced by this EIP.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "The proposal defines opcode behavior but no fork-block state transition, internal-variable mutation, or activation-block special case."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Opcode availability at the containing fork does not itself modify state or an internal variable at the activation block, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Gas cost, lines 35-40",
"source": "eip.md",
"summary": "The EIP states that the value is already available before EVM execution and that the opcode adds no complexity or additional reads or writes."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "A constant-cost stack push of an already-computed contextual value does not introduce a mechanism requiring separate performance validation.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 18-23",
"source": "eip.md",
"summary": "Contracts may use the opcode for trustless rollup cost accounting and blob gas futures, making the returned value economically consequential."
},
{
"locator": "Security Considerations, lines 63-65",
"source": "eip.md",
"summary": "The EIP characterizes the value as public, non-sensitive, and without known security implications."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "An incorrect opcode result could cause contracts or users relying on it to account for blob costs incorrectly, but the mechanism is self-contained, publicly checkable, and does not alter an existing security invariant. This matches score 1 rather than a broader interaction score.",
"score": 1,
"uncertainty_note": "The EIP gives use cases rather than a concrete dependent-contract design, so the magnitude of downstream economic harm is not quantified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-33",
"source": "eip.md",
"summary": "EIP-7516 assigns BLOBBASEFEE to 0x49 and defines it as returning the integer result of get_blob_gasprice(header)."
},
{
"locator": "Parameters and Opcode to get versioned hashes, lines 55-56 and 188-193",
"source": "supporting/eip-4844.md",
"summary": "The required EIP-4844 revision already assigns 0x49 to BLOBHASH with different stack behavior and a gas cost of 3."
},
{
"locator": "Test Cases / Nominal case, lines 46-61",
"source": "eip.md",
"summary": "The sole test covers only a small result of 7 as a left-padded byte32 and does not define behavior for a result outside the stack-word range."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot baseline byte 0x49 until the localized opcode-allocation conflict is resolved, and they also need a common interpretation for an over-wide integer result. These are localized decisions requiring client agreement, which matches score 2; they do not redefine a broad class of previously unobservable behavior.",
"score": 2,
"uncertainty_note": "The package contains neither an amendment resolving the allocation nor a bound or conversion rule that removes the result-width question.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Abstract, lines 1-16",
"source": "eip.md",
"summary": "EIP-7516 formally requires EIPs 3198 and 4844, copies the BASEFEE design, and returns EIP-4844's blob gas price."
},
{
"locator": "Specification and Rationale, lines 26-37",
"source": "supporting/eip-3198.md",
"summary": "EIP-3198 supplies the simple constant-cost BASEFEE opcode pattern that EIP-7516 follows."
},
{
"locator": "Parameters, Gas accounting, and Opcode to get versioned hashes, lines 55-56 and 164-193",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 supplies the returned price function but also assigns 0x49 to BLOBHASH, creating a direct allocation and behavior conflict."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
3198,
4844
],
"rationale": "The BASEFEE analogy is limited, but the EIP-4844 dependency and opcode collision require coordinated specification and testing. The interaction is confined to two identified EIPs and a small surface, so score 2 fits better than the extensive multi-EIP coordination required by score 3.",
"score": 2,
"uncertainty_note": "The package does not say how the 0x49 collision is intended to be resolved.",
"under_specified": true,
"unidentified_interactions": []
}
],
"eip": 7516,
"evaluation_date": "2026-08-25",
"fork": "cancun",
"id": "cancun:7516:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"Opcode 0x49 has incompatible definitions in EIP-7516 and the packaged EIP-4844 revision.",
"The EIP does not specify conversion or failure behavior if the referenced integer blob gas price exceeds the width of one EVM stack item."
],
"provenance": {
"assessed_revision": {
"commit": "ed54cdb1a790870df34ad71f55441f40d62813c3",
"committed_at": "2023-09-13T16:46:42Z",
"content_sha256": "436d072998e3d399442e9ec6875f00b85e6f7cc792c3bdb42b5e374b52d24a6e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7516.md",
"git_blob_sha": "89db18af9363cf14e06660332dffb79833a444b3",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ed54cdb1a790870df34ad71f55441f40d62813c3/EIPS/eip-7516.md",
"information_cutoff_at": "2023-09-14",
"path": "EIPS/eip-7516.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7516.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/cancun/eip-7516.yaml",
"sha256": "b2785dc0b9ff2a919adb21a110d940d3c88f5825b7549b70c7df3e5e7b0079ae"
},
"supporting_documents": [
"supporting/eip-3198.md",
"supporting/eip-4844.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 9,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the 2023-09-14 information cutoff, this Draft EIP specified one new constant-cost EVM opcode, BLOBBASEFEE at 0x49, which takes no stack input and pushes the current block's EIP-4844 blob gas price. It deliberately follows EIP-3198's BASEFEE design and says the value is already available before EVM execution, so it adds no new blob-pricing formula, transaction type, header field, or state access. In the sealed package, however, EIP-4844 also assigns 0x49 to BLOBHASH, and the EIP does not settle that opcode conflict or the representation of a blob gas price wider than an EVM stack word.",
"tier": "low",
"title": "BLOBBASEFEE opcode",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"added_opcodes",
"modified_opcodes",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 15,
"minimum": 8
},
"present": true,
"summary": "Material localized under-specification is present. The sealed EIP-7516 and required EIP-4844 revisions assign incompatible behaviors to opcode 0x49, and EIP-7516 specifies only a small byte32 example without defining how an integer result wider than one EVM stack word is handled.",
"unresolved_questions": [
"Which opcode number and behavior should prevail when EIP-7516 specifies BLOBBASEFEE at 0x49 but the required EIP-4844 specifies BLOBHASH there?",
"Is BLOBBASEFEE intended to add a relocated opcode, replace or relocate BLOBHASH, or otherwise amend EIP-4844?",
"What result must be pushed if get_blob_gasprice(header) is wider than 256 bits, and are all such inputs excluded by another validity rule?"
]
}
},
"hegota:2488:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"20 blank score cells are interpreted as zero only because the published total equals the sum of every nonblank cell."
],
"published_tier": "medium",
"published_total": 13,
"recomputed_tier": "medium",
"recomputed_total": 13,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Existing gas accounting mechanism is updated. CALLCODE today carries the full CALL-family dynamic cost: base, cold/warm account access under EIP-2929, the value-transfer and new-account surcharges, memory expansion for the argument and return regions, and the 63/64 stipend reservation. The assumed behaviour is that **the target is never warmed and no gas is consumed at all** — the opcode pops its arguments, pushes 0, and charges nothing. That is the reading to specify, and it needs stating exactly, because the EIP's one-line specification says only that the instruction \"always returns 0\".",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "A single opcode's state access changes — it disappears. Under the assumed behaviour above, CALLCODE stops touching the target account entirely, so the target is no longer warmed for subsequent opcodes under EIP-2929 and no longer contributes an entry to the block-level access list. Both are observable, so the removal has to be tested rather than assumed.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Major subset across diverse categories. CALLCODE appears in **63 hand-written test files** and **353 files under `tests/ported_static/`** in `execution-specs`. The ported static corpus is exactly the \"static, multiple forks\" case level 3 names: those tests were ported to run across every fork, so each one needs a fork-gated expectation once CALLCODE stops working.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "One boundary-prone mechanism: the always-fail path. Cases are that the opcode still pops the correct number of stack items and pushes 0, that memory arguments are not expanded, that the target stays cold, and that gas is unchanged across the call. Small, fixed set.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "CALLCODE (0xf2) is deprecated: its behaviour is replaced with an unconditional failure return.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Self-contained and validatable in isolation. Contracts that still call CALLCODE will break, but the failure is a returned 0 rather than an exceptional halt, so callers retain the chance to handle it. No existing invariant outside the opcode itself is altered.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Left undetermined by the specification: whether gas is charged for the no-op call, whether the target is warmed under EIP-2929, whether value is transferred, whether the target appears in the block-level access list, whether memory arguments are still expanded, and whether the 1024 call-frame depth limit is still checked or a depth level still consumed. Clients must agree on all of these before tests can be baselined. Localized to one opcode, so 2 rather than 3.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Interacts with one other EIP in a limited way, and can be tested independently for the most part: **EIP-7928** (block-level access lists) — whether a failed CALLCODE still contributes the target to the BAL is consensus-observable and needs settling, but CALLCODE's own cases can be written independently with a BAL expectation attached. EIP-7 (DELEGATECALL) and EIP-2929 (warm/cold) are also in play conceptually, but both have been stable for years and their only consequence here is updating tests, which is already counted under \"Patterns affecting pre-existing tests\".",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 2488,
"fork": "hegota",
"id": "hegota:2488:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-2488.yaml",
"sha256": "5e1af322ebac1ceeacceeabd4b48fd52eacb755fa44404b3cfd02d050381fec8"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "db669a2c21a168ced78bd4de56db3870f1ac0c58",
"content_sha256": "66c8591d137a8d41fff1dd0af5d8f822d8ef11f418c9261f648e8045125397c1",
"git_blob_sha": "a62792dae10fa120cbde67976efd7739e642da8c",
"immutable_url": "https://github.com/ethspecs/pm/blob/db669a2c21a168ced78bd4de56db3870f1ac0c58/complexity_assessments/EIPs/EIP-2488.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-2488.md",
"pull_request": {
"draft": false,
"number": 114,
"title": "Add EIP-2488 complexity assessment",
"updated_at": "2026-08-18T16:56:16Z",
"url": "https://github.com/ethspecs/pm/pull/114"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 13,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "Deprecate the CALLCODE opcode",
"under_specification": null
},
"hegota:2488:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The only stated post-fork rule is that CALLCODE always returns 0; the specification states no gas-accounting rule."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "evm_gas_rule_changes",
"rationale": "No gas-accounting change is specified, so the zero anchor applies. Whether existing CALLCODE charging remains in force is a material specification gap recorded separately.",
"score": 0,
"uncertainty_note": "The text does not say whether existing gas processing occurs before the forced failure, so a later clarification could change this row.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The forced return value is specified without defining any state access or the position of gas charging relative to an access."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal does not specify a change to state-access or gas-charge ordering within CALLCODE, so the zero anchor applies on the sealed text.",
"score": 0,
"uncertainty_note": "It is unresolved whether the deprecated instruction retains or bypasses any pre-existing access path; that localized ambiguity could make this a single-opcode ordering change.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The specification only changes the result of CALLCODE and mentions no blob gas."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas accounting mechanism is introduced or updated.",
"score": 0,
"uncertainty_note": "No blob-gas behavior is within the proposal's stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The specification introduces no state write or state-gas charging rule."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "state_gas_accounting_changes",
"rationale": "No state-gas cost, charging site, budget, reservoir, or spill rule is changed.",
"score": 0,
"uncertainty_note": "The separate ambiguity about CALLCODE execution gas does not establish any change to state gas for writes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The post-fork forced-failure rule introduces no refund mechanism."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas refund is specified.",
"score": 0,
"uncertainty_note": "The EIP contains no refund proposal or refund parameters.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "Post-fork CALLCODE executions must return failure rather than their prior result."
},
{
"locator": "## Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal explicitly identifies the change as breaking and potentially contract-breaking."
}
],
"exceptional_score_justification": "Not applicable; score 1 is within the defined anchors.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests that exercise CALLCODE across the fork must be updated, but the affected set is the narrow subset centered on one opcode, matching the minor-subset anchor.",
"score": 1,
"uncertainty_note": "Test cases are TBA, so the package does not enumerate the actual regression set or demonstrate broader effects.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The rule changes CALLCODE behavior but defines no new output that unrelated tests must assert."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to this EIP gain no additional invariant or mechanically applied assertion.",
"score": 0,
"uncertainty_note": "Test cases are TBA, but no package evidence identifies a cross-suite assertion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "Activation is expressed through block.number and no transition-tool field is introduced."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or mechanism is specified.",
"score": 0,
"uncertainty_note": "FORK_BLOCK is not assigned a value, but that does not itself specify a new tool field.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The observable requirement is a post-fork zero failure result for one existing opcode."
},
{
"locator": "## Test Cases",
"source": "eip.md",
"summary": "The test-cases section is TBA and requests no framework abstraction."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "new_test_framework_primitives",
"rationale": "The specified result and fork boundary can be exercised with ordinary opcode-result tests; no new expectation, modifier, or helper is required by the package.",
"score": 0,
"uncertainty_note": "The absent test plan prevents confirmation, but it supplies no basis for a nonzero score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Abstract",
"source": "eip.md",
"summary": "The proposal deprecates CALLCODE by making it return failure and introduces no cryptography."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "cryptography",
"rationale": "No cryptographic mechanism or cryptographic functionality is added or modified.",
"score": 0,
"uncertainty_note": "Cryptography is outside the stated change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The new behavior applies exactly when block.number is greater than or equal to FORK_BLOCK."
}
],
"exceptional_score_justification": "Not applicable; score 1 is within the defined anchors.",
"id": "edge_boundary_conditions",
"rationale": "The proposal introduces one explicit activation boundary at which the same opcode changes from its prior behavior to forced failure.",
"score": 1,
"uncertainty_note": "FORK_BLOCK has no concrete value in the EIP, but the before/at-boundary test dimension is clear.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The specification changes an opcode result and introduces no block RLP validation rule."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "block_syncing_changes",
"rationale": "No block encoding or RLP validation mechanism requiring sync testing is introduced.",
"score": 0,
"uncertainty_note": "The motivation mentions syncing clients, but proposes no change to block validation encoding.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The only specified change is internal EVM opcode behavior, with no API fields or endpoints."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "No Engine API surface appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The proposal changes CALLCODE behavior and does not introduce contract code or state."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "The package identifies no system-contract deployment or system action.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The proposal names only CALLCODE and identifies no pre-existing system contract."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "modified_system_contracts",
"rationale": "No direct or package-grounded indirect modification of a system contract is specified.",
"score": 0,
"uncertainty_note": "The EIP warns generically about affected contracts but does not identify any as system contracts, so no such interaction can be inferred.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Abstract",
"source": "eip.md",
"summary": "The proposal deprecates the existing CALLCODE opcode rather than allocating a new opcode."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "added_opcodes",
"rationale": "No new opcode is introduced.",
"score": 0,
"uncertainty_note": "The only opcode number named, 0xf2, is identified as CALLCODE's existing instruction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Abstract",
"source": "eip.md",
"summary": "CALLCODE is explicitly deprecated by making it always return failure."
},
{
"locator": "## Specification",
"source": "eip.md",
"summary": "After activation, CALLCODE (0xf2) always returns 0."
}
],
"exceptional_score_justification": "Not applicable; score 3 is within the defined anchors.",
"id": "modified_opcodes",
"rationale": "A pre-existing opcode is deprecated and its non-gas behavior is modified, which exactly matches the score-3 anchor.",
"score": 3,
"uncertainty_note": "Detailed secondary effects are underspecified, but the deprecation and result change are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The specification changes an opcode and introduces no precompile."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "Precompiles are outside the stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "No precompile logic or precompile gas schedule is mentioned."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile behavior or gas accounting is modified.",
"score": 0,
"uncertainty_note": "The proposal identifies only CALLCODE.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The opcode-result rule adds no transaction, block, or interface encoding."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other transaction/block/interface encoding change is introduced.",
"score": 0,
"uncertainty_note": "Encoding is outside the proposal's stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The proposal changes CALLCODE execution and defines no transaction envelope."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "The EIP contains no transaction-type specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The change applies during opcode execution and states no transaction validity or intrinsic-gas rule."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity and intrinsic gas calculation are not modified.",
"score": 0,
"uncertainty_note": "The execution result may change, but no transaction is declared invalid by this proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The existing block.number is used as an activation condition; no block or header field is added."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "FORK_BLOCK is a threshold placeholder, not a proposed header field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "Activation gates CALLCODE behavior on block.number but specifies no state or internal-variable modification at activation."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "new_fork_activation_mechanism",
"rationale": "The fork changes opcode semantics without modifying state or an internal variable at the activation block, so it does not meet the nonzero anchor.",
"score": 0,
"uncertainty_note": "No activation-time initialization or irregular transition is described.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Motivation",
"source": "eip.md",
"summary": "The stated benefit is reducing implementation burden for certain clients, not adding a performance-sensitive mechanism."
},
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The new behavior is a fixed failure result for one opcode."
}
],
"exceptional_score_justification": "Not applicable; score 0 is within the defined anchors.",
"id": "performance_risks",
"rationale": "No new mechanism requiring performance validation is introduced; the specified path is a localized forced result.",
"score": 0,
"uncertainty_note": "Implementation is TBA, but the package identifies no performance risk or benchmark requirement.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "## Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal is explicitly breaking and may break contracts; the expectation that no valuable contracts are affected remains a TODO to validate."
},
{
"locator": "## Security Considerations",
"source": "eip.md",
"summary": "Security considerations are TBA."
},
{
"locator": "## Rationale",
"source": "eip.md",
"summary": "Returning failure is chosen so a contract can detect the result and potentially recover."
}
],
"exceptional_score_justification": "Not applicable; score 2 is within the defined anchors.",
"id": "security_risks",
"rationale": "The modified opcode has a limited interaction surface but changes assumptions for contracts that execute it, with acknowledged potential breakage and no completed security analysis. That warrants targeted review rather than the self-contained score-1 treatment.",
"score": 2,
"uncertainty_note": "The package neither validates affected-contract prevalence nor supplies security considerations, so the practical reach of the risk is unknown.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "## Specification",
"source": "eip.md",
"summary": "The specification fixes only the returned failure value and does not define gas charging, state-access behavior, or which other existing CALLCODE effects remain."
},
{
"locator": "## Test Cases",
"source": "eip.md",
"summary": "Test cases are TBA."
},
{
"locator": "## Implementation",
"source": "eip.md",
"summary": "Implementation is TBA."
}
],
"exceptional_score_justification": "Not applicable; score 2 is within the defined anchors.",
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Constructible CALLCODE cases cannot be baselined from the text until clients agree on the localized operational details surrounding the forced result. The uncertainty concerns one opcode, so score 2 fits better than the broad or newly observable score-3 condition.",
"score": 2,
"uncertainty_note": "The assessment has no permitted evidence about implementations, devnets, or discussion state; the score rests only on omissions visible in the snapshot.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter: requires",
"source": "eip.md",
"summary": "EIP-2488 declares EIP-7 as its sole required EIP."
},
{
"locator": "## Motivation",
"source": "eip.md",
"summary": "The motivation says DELEGATECALL from EIP-7 rectified CALLCODE's intended design goal."
},
{
"locator": "### Overview",
"source": "supporting/eip-7.md",
"summary": "EIP-7 defines DELEGATECALL as similar in idea to CALLCODE while changing sender and value propagation."
}
],
"exceptional_score_justification": "Not applicable; score 1 is within the defined anchors.",
"id": "cross_eip_interactions",
"interacting_eips": [
7
],
"rationale": "There is one explicit, limited interaction with EIP-7. The proposal relies on DELEGATECALL as the historical replacement context but does not modify its specified behavior, so the interaction remains independently testable for the most part.",
"score": 1,
"uncertainty_note": "No other EIP interaction is identified by the package.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 2488,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:2488:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"\"Always returns 0\" does not say whether the instruction follows any of its existing execution path before producing that result.",
"The backwards-compatibility claim about valuable contracts is explicitly unvalidated, and security considerations are absent."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "e606d541a486a736c43cc9fbb2849bdcc1cab911bba54e0b891b3ccfb9d6ecd0",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2488.md",
"git_blob_sha": "5af41eb8bf07754d3213a370d91c104e93102472",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-2488.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-2488.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-2488.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-2488.yaml",
"sha256": "e3a1ee5c5b7fa250e6fe775901190c5479c8ead42ef5b9a662b435e51df080c0"
},
"supporting_documents": [
"supporting/eip-7.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 10,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the proposal to change CALLCODE (0xf2) at FORK_BLOCK so that it always returns 0. The sealed package describes a localized but breaking opcode deprecation, declares EIP-7 as a dependency, and leaves detailed opcode effects, tests, implementation, and security considerations unresolved.",
"tier": "low",
"title": "Deprecate the CALLCODE opcode",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 10
},
"present": true,
"summary": "The specification says only that post-fork CALLCODE always returns 0. It does not determine whether existing gas processing or state access occurs before that result, which other existing instruction effects remain, or a concrete FORK_BLOCK value. Test cases, implementation, and security considerations are also TBA.",
"unresolved_questions": [
"Does CALLCODE retain its existing gas accounting before returning the forced failure value?",
"Does CALLCODE perform any state access after activation, and where is gas charged relative to it?",
"Which existing CALLCODE effects other than its returned result remain in force?",
"What concrete activation block replaces FORK_BLOCK?"
]
}
},
"hegota:3298:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"21 blank score cells are interpreted as zero only because the published total equals the sum of every nonblank cell."
],
"published_tier": "low",
"published_total": 6,
"recomputed_tier": "low",
"recomputed_total": 6,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Existing gas accounting mechanism is updated by removal, which results in great simplification by removal of code.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new refund mechanism is introduced; this EIP removes the last one. Hence, this row is marked as zero due to reduction of parametrization of refund tests.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Minor subset. Measured rather than estimated: a reference implementation of this EIP against the Amsterdam set fails **63 tests** out of ~11.9k collected under `tests/amsterdam/` — under 1%, and concentrated in refund and SSTORE gas assertions. The affected tests need their expected values updated, not restructuring. `tests/amsterdam/eip7778_block_gas_accounting_without_refunds/` is the one suite retired outright, since its premise (refunds exist but do not count toward the block limit) cannot hold once refunds are gone.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The boundary conditions that have to be tested due to refunds are already present in the test set. This change will only have to modify the outcome expectation of such tests.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Note: not a direct modification but executing system contracts that touch the state and before incurred in refunds have to be sanity checked. Potentially using already-existing tests.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Amsterdam has two independent refund mechanisms and this EIP (2021) predates the second: the EIP-2200 `refund_counter` in execution gas, which this EIP removes, and `credit_state_gas_refund()` in state gas, which credits `StateGasCosts.STORAGE_SET` back when a slot is cleared (`vm/instructions/storage.py`). The state-gas refund should stay: state paid for and released within the same transaction never persisted, so crediting it is not a refund for good hygiene but correct accounting for state that was never created. That leaves only a statement to add to the EIP, so scored 1 — the resolution is clear and needs no client negotiation.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "**EIP-7778** minimal, it's implied that the mechanism is removed.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 3298,
"fork": "hegota",
"id": "hegota:3298:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-3298.yaml",
"sha256": "122ee8c3158024c26590bd7a78f561fc1d085baf869f6b37e9a739f7efb085e3"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "6672c60213099cd1726af93a556963767229ff5a",
"content_sha256": "75b5454cd77c5fc531a4ce4a35b03a574d2b133b0c3fde8fc9224f58dac5aceb",
"git_blob_sha": "760dabfde14231bcf4259f938d35a44a23c9df60",
"immutable_url": "https://github.com/ethspecs/pm/blob/6672c60213099cd1726af93a556963767229ff5a/complexity_assessments/EIPs/EIP-3298.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-3298.md",
"pull_request": {
"draft": false,
"number": 115,
"title": "Add EIP-3298 complexity assessment",
"updated_at": "2026-08-18T20:29:53Z",
"url": "https://github.com/ethspecs/pm/pull/115"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 6,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "low",
"title": "Remove storage-clear refund and refund cap",
"under_specification": null
},
"hegota:3298:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "STORAGE_CLEAR_REFUND and the two SSTORE refund rules using it are removed, while the SSTORE charging rules remain unchanged."
},
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "End-of-transaction gas settlement replaces the capped refund with direct subtraction of the refund counter."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal updates the existing EVM refund-accounting and transaction settlement rules; it does not introduce a new gas-accounting mechanism.",
"score": 1,
"uncertainty_note": "The affected existing mechanisms and their replacement formulas are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "The EIP states that SSTORE charging rules and EIP-8037 state-gas charges and refills are untouched."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Refunds are applied only in end-of-transaction settlement and cannot affect execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state access is moved and no gas charge is repositioned relative to an opcode's state access; only refund accounting and later settlement change.",
"score": 0,
"uncertainty_note": "No opcode-internal ordering change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal is limited to the storage-clearing refund, transaction refund cap, and retained STORAGE_WRITE reversal."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas rule or mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "Blob gas is outside the enumerated proposal changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "The EIP explicitly leaves EIP-8037 state-gas charges and refills untouched and distinguishes refills from the refund counter."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "State-gas charges and refills are declared orthogonal and unchanged."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Neither a state-gas cost, charging site, reservoir rule, budget, nor spill interaction is changed.",
"score": 0,
"uncertainty_note": "The unchanged state-gas boundary is stated twice.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "The clearing refund is removed and the sole remaining STORAGE_WRITE refund rule is retained unchanged from EIP-8038."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The EIP removes a refund mechanism and introduces no new refund.",
"score": 0,
"uncertainty_note": "The text explicitly identifies the single remaining rule as unchanged.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "Every STORAGE_CLEAR_REFUND entry is struck from EIP-8038's SSTORE case table, while the other entries stay unchanged."
},
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "Existing capped-settlement expectations must change to uncapped refund subtraction followed by the calldata floor."
},
{
"locator": "Test Cases > With reduced refunds",
"source": "supporting/eip-3529.md",
"summary": "The prior mechanism has a substantial table of storage sequences with clearing-refund and capped-settlement expectations affected by the delta."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable but narrow category of existing SSTORE-refund and transaction gas-settlement tests must be reworked; unrelated execution tests are not broadly affected.",
"score": 2,
"uncertainty_note": "The package specifies affected rule families but does not inventory the pre-existing test corpus, so the boundary between scores 1 and 2 is judgmental.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The requested assertions concern refund-focused sequences, uncapped settlement, the existing calldata floor, and existing block accounting."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The EIP changes expected refund and gas-used values in tests about the affected mechanisms, but adds no new output or assertion that tests unrelated to this EIP must universally check.",
"score": 0,
"uncertainty_note": "Existing gas-used expectations may change for refund-bearing cases, but that is test reworking rather than a new independently asserted invariant.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "The change is expressed entirely with existing transaction-output values: gas_left, state_gas_reservoir, and refund_counter."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool field or interface mechanism is added or modified.",
"score": 0,
"uncertainty_note": "The complete settlement delta requires no new input or output field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Tests are specified as ordinary SSTORE value sequences and assertions over charges, refund_counter, net write cost, transaction gas, and block gas."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing state-test and gas-accounting expectations suffice; no new reusable expectation type, modifier, or framework abstraction is required by the text.",
"score": 0,
"uncertainty_note": "No test case requires a capability beyond constructing transactions and checking existing outputs.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete normative delta concerns SSTORE refund entries and end-of-transaction gas settlement."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism or cryptographic functionality changes.",
"score": 0,
"uncertainty_note": "Cryptography is outside the proposal's specified surface.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Eight original/current/new SSTORE sequences are tabulated, followed by required cases for many cleared slots, crossing the former 20% cap, crossing the calldata floor, and block-versus-user gas accounting."
},
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "Refund-counter additions are journaled by call frame and discarded on revert, while state-gas refills remain separate."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact, and the SSTORE sequence matrix requires an elevated case count across original/current/new values, repeated writes, reverts, the former cap boundary, the calldata floor, and block accounting.",
"score": 3,
"uncertainty_note": "The package gives many concrete cases but does not quantify the final cross-product with call-frame success and revert variants.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "Block-level accounting is explicitly unchanged; the normative delta is a transaction-settlement formula."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "The proposal changes neither block serialization nor validation fields.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The stated external updates are to gas estimators, wallets, eth_estimateGas, and fee computation."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API endpoint, field, or communication mechanism changes.",
"score": 0,
"uncertainty_note": "The proposal's interface impact is limited to estimation and fee logic, not Engine API directives.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal's two normative changes are to SSTORE refund rules and transaction refund settlement."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "System contracts are outside the complete specified delta.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No system-contract code, state, invocation rule, or special transition is included in the normative changes."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or package-identified indirect system-contract modification is introduced.",
"score": 0,
"uncertainty_note": "The package identifies no system-contract effect to assess.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "The proposal changes refund rules associated with the existing SSTORE opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "The only named opcode is pre-existing SSTORE.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "SSTORE charging rules are untouched; only clearing-refund entries are removed and the existing STORAGE_WRITE reversal remains."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Removing the refund cannot affect execution and changes only net costs."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "SSTORE's execution result and non-gas behavior do not change; the rubric excludes gas changes from this anchor.",
"score": 0,
"uncertainty_note": "The EIP expressly confines the change to refund accounting after execution.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative delta contains no precompile definition or address."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "Precompiles are outside the specified proposal surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative delta contains no precompile logic or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "Precompile behavior and pricing are not part of the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "The transaction change is an arithmetic settlement formula using existing execution outputs and does not alter serialization."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, receipt, or interface encoding changes.",
"score": 0,
"uncertainty_note": "Receipt cumulative gas semantics are retained without an encoding change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The rules apply to SSTORE refunds and settlement of existing transactions; no transaction envelope or type is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "Transaction typing is outside the normative delta.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "The cap is removed in end-of-transaction gas settlement, and the existing calldata floor continues to apply after refunds."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Refund removal cannot affect execution and changes only net cost."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic gas calculation changes; the proposal modifies post-execution settlement of valid transactions.",
"score": 0,
"uncertainty_note": "The existing calldata-floor validity mechanism is not modified by this EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "Block-level accounting is unchanged and the existing receipt cumulative_gas_used value retains its post-floor basis."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced.",
"score": 0,
"uncertainty_note": "The proposal changes a computed transaction cost, not the block/header schema.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The gas repricing requires a scheduled network upgrade."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "No activation-block state transition or internal-variable mutation is specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Fork scheduling is required, but activation performs no special state or internal-variable modification under the rubric's definition.",
"score": 0,
"uncertainty_note": "The text contains no one-time activation procedure.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "EIP-7778 already excludes refunds from block accounting, so this EIP does not change worst-case block resource consumption."
},
{
"locator": "Rationale > Why the clearing refund goes",
"source": "eip.md",
"summary": "The proposal removes specification and implementation burden."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "No new performance-sensitive mechanism is introduced, and the package expressly states that worst-case block resource consumption is unchanged.",
"score": 0,
"uncertainty_note": "Economic changes may alter usage, but the sealed evidence identifies no required performance validation.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Safety without a cap depends on the remaining refund being backed by a same-transaction charge and on refund-counter journaling across reverts; both properties are described as load-bearing."
},
{
"locator": "Rationale > Why the write reversal stays and the cap goes",
"source": "eip.md",
"summary": "Each STORAGE_WRITE refund is paired with a prior same-slot charge, while EIP-7778 separately bounds block-size impact."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Removing the cap slightly alters the security assumptions of the refund counter and settlement path. Safety depends on a limited set of existing components—same-transaction SSTORE charge pairing, revert journaling, and refund-independent block accounting—warranting targeted review and fuzzing.",
"score": 2,
"uncertainty_note": "The invariant is clearly argued, but its load-bearing cross-component nature prevents treating the change as risk-free or fully isolated.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "The removed rules, sole retained rule, original/current-value meanings, revert journaling, and separation from state-gas refills are explicit."
},
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "The settlement order and formulas for refund subtraction, calldata floor, receipt gas, and block accounting are explicit."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The EIP determines the outcome for the constructible refund and settlement cases identified by the package; no localized consensus choice remains open.",
"score": 0,
"uncertainty_note": "Draft status alone is not evidence of an unspecified test outcome, and none is visible in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter > requires",
"source": "eip.md",
"summary": "The EIP declares dependencies on 2780, 3529, 7778, 8037, and 8038."
},
{
"locator": "Specification > SSTORE refund rules",
"source": "eip.md",
"summary": "The proposal removes EIP-8038 clearing-refund rules, retains its STORAGE_WRITE reversal, and uses EIP-2200 original/current-value semantics."
},
{
"locator": "Specification > Removal of the refund cap",
"source": "eip.md",
"summary": "EIP-8037 settlement loses the EIP-3529 cap, the EIP-7623 calldata floor remains, and EIP-7778/EIP-8037 block accounting remains before refunds."
},
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The cap's interactions with the EIP-7623/EIP-7976 floor and EIP-8037's two gas dimensions are an explicit motivation for removal."
}
],
"exceptional_score_justification": "Under the uncapped rubric, eight identified interacting EIPs yield base score 3 plus one point for the first complete group of three additional EIPs beyond the initial three.",
"id": "cross_eip_interactions",
"interacting_eips": [
2200,
2780,
3529,
7623,
7778,
7976,
8037,
8038
],
"rationale": "The change has strong coordinated interactions with 2200, 2780, 3529, 7623, 7778, 7976, 8037, and 8038: their SSTORE definitions, eliminated legacy refunds, settlement cap, calldata floor, block accounting, and state-gas separation jointly establish the remaining refund's safety and expected gas values. Cross-EIP test vectors are required for the storage case table, uncapped settlement, floor binding, and refund-independent block accounting.",
"score": 4,
"uncertainty_note": "EIP-1153 and EIP-7702 are discussed as use-case or historical context, but are not counted as direct coordinated interactions beyond the listed EIPs.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 3298,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:3298:llm:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "4ea20f9dd745a8d3d8bb26c20a973b1ccad5cf0302e0d6bbfdff9840270392f1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3298.md",
"git_blob_sha": "19be2a355694d7f2a206ea61550d40170b1929e0",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-3298.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-3298.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-3298.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-3298.yaml",
"sha256": "11c29e1e20ff22a18e7fcf58299f0380b880d24888f589374737470889c7e3ca"
},
"supporting_documents": [
"supporting/eip-1153.md",
"supporting/eip-2200.md",
"supporting/eip-2780.md",
"supporting/eip-3529.md",
"supporting/eip-7623.md",
"supporting/eip-7702.md",
"supporting/eip-7778.md",
"supporting/eip-7976.md",
"supporting/eip-8037.md",
"supporting/eip-8038.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 12,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of EIP-3298 at the sealed Hegota snapshot: removal of the SSTORE storage-clearing refund and transaction refund cap, while retaining the net-metered same-transaction STORAGE_WRITE reversal.",
"tier": "medium",
"title": "Remove storage-clear refund and refund cap",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 12
},
"present": false,
"summary": "No material under-specification is visible in the sealed package; the removed and retained refund rules, settlement order, floor behavior, revert journaling, state-gas boundary, and block-accounting boundary are explicit.",
"unresolved_questions": []
}
},
"hegota:4758:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "low",
"published_total": 8,
"recomputed_tier": "low",
"recomputed_total": 8,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Opcode gas schedule unchanged (base + cold access + account write + state gas all remain). The EIP's refund-removal clause is a no-op: SELFDESTRUCT refunds were removed by EIP-3529.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No access or gas-charge site inside the opcode moves. The removed behavior (account clearing) happens at end of transaction, outside opcode execution.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "SENDALL keeps the existing NEW_ACCOUNT / account-write charging sites; end-of-tx clearing is not gas-charged today, so removing it changes no accounting.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Adds none; the refunds it removes have been gone since London.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "EIP-6780 already narrowed deletion to same-tx-created accounts, so only that contrived family changes expectations: `tests/cancun/eip6780_selfdestruct`, `tests/amsterdam/eip8246_selfdestruct_no_burn`, CREATE2-redeploy-onto-tombstone cases. A trial removal in EELS fails only a small number of tests; the ~200 ported-static SELFDESTRUCT tests almost all use pre-existing contracts, which stopped deleting at Cancun.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "One genuinely new edge-prone surface: created-then-destroyed accounts now persist, so CREATE2 onto such an account hits the collision path. The other boundary cases (self-sweep, zero-balance sweep to a dead beneficiary, SENDALL in initcode, repeated SENDALL in one tx) already exist under EIP-6780/8246 and lose branches rather than gain them.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Rename of `0xFF`, not a new opcode.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Pre-existing opcode behavior modified: the deletion path is removed and `SELFDESTRUCT` becomes `SENDALL`.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Pre-fork state, including EIP-8246 tombstones, is untouched at activation.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Removes work (end-of-tx account clearing); no new mechanism requires performance validation.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Chain-level it removes an invariant-complicating mechanism (resurrection via CREATE2 redeploy). Breakage is application-layer (upgrade/redeploy patterns) and testable in isolation.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Stagnant two-line 2022 text predates EIP-6780/7708/8037/8246 and needs modernizing, but each open detail has an obvious intended reading: halt semantics, state-gas charging sites, and transfer-log rules carry over unchanged; only the deletion goes.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Supersedes EIP-6780's deletion gate and EIP-8246's tombstone: their suites (and those tests' EIP-7928 BAL vectors) get updated expectations, but the rework is small, mechanical, and testable independently. Interacting EIPs: 6780, 8246, 7928, 7708, 8037; no +1 increment (under six).",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 4758,
"fork": "hegota",
"id": "hegota:4758:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-4758.yaml",
"sha256": "b4717dd137d0ef500dac1f05b7ed94d12cfab466c5b229fe7556c802f7e37b11"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "87fbde51cd4dbe50f3f594e55217384549fce93e",
"content_sha256": "5a0bbd26d962cccf9e3fa8b8eb4e9f7292be6048e07caf4194fc978f5cddba09",
"git_blob_sha": "524925b9204846028697c832304f63a3d591c8b6",
"immutable_url": "https://github.com/ethspecs/pm/blob/87fbde51cd4dbe50f3f594e55217384549fce93e/complexity_assessments/EIPs/EIP-4758.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-4758.md",
"pull_request": {
"draft": false,
"number": 105,
"title": "Add EIP-4758 complexity assessment",
"updated_at": "2026-08-17T13:21:13Z",
"url": "https://github.com/ethspecs/pm/pull/105"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 8,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "low",
"title": "Deactivate SELFDESTRUCT",
"under_specification": null
},
"hegota:4758:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullet 2",
"source": "eip.md",
"summary": "All refunds related to SELFDESTRUCT are removed."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "evm_gas_rule_changes",
"rationale": "Removing an existing opcode refund updates the existing EVM gas-accounting rules, but the proposal introduces no new gas-accounting mechanism.",
"score": 1,
"uncertainty_note": "The text does not specify the opcode's remaining charge schedule, so this score is limited to the explicit refund-rule change.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, bullet 1",
"source": "eip.md",
"summary": "SENDALL immediately moves all ETH to the target and no longer destroys code or storage or alters the nonce."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal changes which state effects the opcode produces, but it does not state a change to the relative ordering of a state access and a gas charge inside opcode execution.",
"score": 0,
"uncertainty_note": "The word \"immediately\" does not define the detailed access sequence or gas boundaries; that omission is recorded as under-specification rather than scored as an ordering change.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The specified changes concern SELFDESTRUCT state effects, ETH transfer, and refunds; no blob-gas rule is specified."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob-related behavior appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullet 1",
"source": "eip.md",
"summary": "The opcode ceases to delete code or storage or alter the nonce and only moves the account's ETH."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "state_gas_accounting_changes",
"rationale": "Changing the opcode's state result is not itself a change to a state-gas cost, rate, charging site, budget, reservoir, or spill mechanism.",
"score": 0,
"uncertainty_note": "The proposal specifies no state-gas accounting rules.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullet 2",
"source": "eip.md",
"summary": "Existing SELFDESTRUCT-related refunds are removed."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_evm_gas_refund",
"rationale": "The proposal removes refunds and introduces no new refund mechanism.",
"score": 0,
"uncertainty_note": "None material for whether a new refund is introduced.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "Existing SELFDESTRUCT results and refunds change: code, storage, and nonce persist while ETH is transferred."
},
{
"locator": "Backwards Compatibility, paragraph 2",
"source": "eip.md",
"summary": "The proposal says few applications are affected and identifies same-address recreation with CREATE2 as the breaking use."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Pre-existing tests that exercise SELFDESTRUCT results, refunds, or same-address recreation need reworking, but the package characterizes the affected application set as small and ties it to a narrow opcode-focused subset.",
"score": 1,
"uncertainty_note": "The package contains no test inventory, so the exact size of the affected subset cannot be established.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The proposal changes the behavior and refund of one existing opcode but specifies no fork-wide output or assertion."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests of the changed opcode need different expectations, but tests unrelated to this proposal do not gain an additional invariant to assert.",
"score": 0,
"uncertainty_note": "No package evidence identifies a new assertion on unrelated tests.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The entire specified surface is an opcode behavior change and refund removal; no transition-tool input or output field is defined."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is required by the text.",
"score": 0,
"uncertainty_note": "The package contains no transition-tool design, but the proposal exposes no new data that such an interface must carry.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The specified outcomes are ordinary account balance, code, storage, nonce, and gas-refund observations."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_test_framework_primitives",
"rationale": "The proposal does not require a new expectation type, modifier, helper, or other test-framework abstraction.",
"score": 0,
"uncertainty_note": "No framework evidence is available in the package; the score rests on the absence of a novel observable data type in the specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The proposal specifies an ETH transfer and removal of destructive effects and refunds."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None; cryptography is outside the stated change.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, bullet 1",
"source": "eip.md",
"summary": "SENDALL transfers the account's entire ETH balance to a target while retaining code, storage, and nonce."
},
{
"locator": "Security Considerations, items 1-2",
"source": "eip.md",
"summary": "The proposal identifies token-balance burning and CREATE2 same-address redeployment, including lifecycle and upgrade uses, as broken patterns."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "edge_boundary_conditions",
"rationale": "Whole-balance transfer with retained account state and the identified token, recreation, lifecycle, and upgrade patterns create multiple boundary-prone cases. The package does not establish that any one mechanism requires the elevated case count needed for score 3.",
"score": 2,
"uncertainty_note": "Self-target, zero-balance, target-account, repeated-call, and execution-halting semantics are not expressly resolved by the short specification.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "No block RLP field or block-validation encoding rule is specified."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "block_syncing_changes",
"rationale": "The proposal introduces no block RLP validation mechanism.",
"score": 0,
"uncertainty_note": "None; the specified change is confined to opcode execution and refunds.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "No Engine API endpoint, field, or communication mechanism is specified."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "engine_api_changes",
"rationale": "The proposal requires no Engine API change on the evidence provided.",
"score": 0,
"uncertainty_note": "None; no cross-layer API surface appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The proposal changes an opcode and adds no contract or contract address."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None; no system contract is part of the specified mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility, paragraph 2",
"source": "eip.md",
"summary": "The proposal describes affected applications generally and identifies CREATE2 recreation, but names no pre-existing system contract."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "modified_system_contracts",
"rationale": "No direct modification or package-grounded indirect effect on a pre-existing system contract is identified.",
"score": 0,
"uncertainty_note": "The package does not inventory system-contract use of SELFDESTRUCT, so no such interaction can be inferred.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "SELFDESTRUCT is renamed to SENDALL and its functionality is replaced."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "added_opcodes",
"rationale": "Renaming and redefining the existing opcode is a modification, not the introduction of an additional opcode.",
"score": 0,
"uncertainty_note": "The text does not state an opcode byte, but consistently frames SENDALL as a rename of SELFDESTRUCT rather than an addition.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullet 1",
"source": "eip.md",
"summary": "SELFDESTRUCT is renamed to SENDALL and no longer destroys code or storage or alters the nonce; it only moves all ETH to the target."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "modified_opcodes",
"rationale": "The existing opcode's non-gas behavior is directly modified, which maps to the rubric's only nonzero score for this anchor.",
"score": 3,
"uncertainty_note": "None material to the fact that existing opcode behavior changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "No precompile or precompile address is introduced."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "added_precompiles",
"rationale": "The proposal adds no precompile.",
"score": 0,
"uncertainty_note": "None; the proposal changes an opcode only.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "No precompile logic or gas schedule is mentioned."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "modified_precompiles",
"rationale": "No existing precompile behavior or gas accounting is modified.",
"score": 0,
"uncertainty_note": "None; precompiles are outside the stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The proposal defines no transaction, block, or interface encoding change."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other encoding change is introduced.",
"score": 0,
"uncertainty_note": "None; the specified behavior does not alter encoded data.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "No transaction type is introduced; the change applies during opcode execution."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_transaction_types",
"rationale": "The proposal adds no transaction type.",
"score": 0,
"uncertainty_note": "None; transaction envelopes are outside the specified change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "The proposal changes an executed opcode's result and refund, not transaction validity or intrinsic gas calculation."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity mechanism or intrinsic gas rule changes.",
"score": 0,
"uncertainty_note": "None; consensus-rule modification alone does not imply transaction validity changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "No block or header field is introduced."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_block_header_fields",
"rationale": "The proposal adds no block or block-header field.",
"score": 0,
"uncertainty_note": "None; the proposal has no block-format surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, paragraph 1",
"source": "eip.md",
"summary": "The proposal requires a hard fork because it modifies consensus rules."
},
{
"locator": "Specification, bullets 1-2",
"source": "eip.md",
"summary": "No activation-block state mutation or modification of an internal variable is specified."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "new_fork_activation_mechanism",
"rationale": "Requiring fork activation is not itself a new activation mechanism under the anchor; no activation-block mutation is defined.",
"score": 0,
"uncertainty_note": "None; the text specifies no one-time activation action.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, paragraph 1",
"source": "eip.md",
"summary": "SELFDESTRUCT is described as requiring large account-state changes because it removes code and storage."
},
{
"locator": "Specification, bullet 1",
"source": "eip.md",
"summary": "The replacement avoids code and storage deletion and nonce alteration, retaining only the ETH transfer."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "performance_risks",
"rationale": "The proposal removes the large destructive state operation and introduces no new mechanism that the package says requires performance validation.",
"score": 0,
"uncertainty_note": "The package contains no benchmarks, but it identifies no new performance-sensitive path beyond the narrowed balance-transfer behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, items 1-2",
"source": "eip.md",
"summary": "The proposal breaks SELFDESTRUCT-based non-ETH token burning and CREATE2-based lifecycle and upgrade patterns, including a pattern intended to prevent later withdrawals."
},
{
"locator": "Backwards Compatibility, paragraph 2",
"source": "eip.md",
"summary": "Same-address contract recreation after SELFDESTRUCT no longer works."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "security_risks",
"rationale": "The changed opcode affects multiple security-relevant components and assumptions: account persistence, token balances, CREATE2 recreation, withdrawal gating, and upgrade patterns. Incorrect handling therefore calls for extensive review across critical account-lifecycle behavior.",
"score": 3,
"uncertainty_note": "The package states that few applications are affected but gives no deployment inventory; this limits prevalence estimates, not the depth of the identified security interactions.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The replacement is described as sending all Ether in the account to the caller."
},
{
"locator": "Specification, bullet 1",
"source": "eip.md",
"summary": "The normative bullet instead says all ETH moves to the target and does not define halting or detailed target-account edge semantics."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Test-constructible questions require localized agreement, including the caller-versus-target wording and whether renamed SENDALL retains terminating behavior. The core effect is defined, so the uncertainty is localized rather than a newly exposed fork-wide behavior.",
"score": 2,
"uncertainty_note": "The package provides no implementation, devnet, or discussion evidence and the EIP status is Stagnant, so resolution of these questions cannot be inferred.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, item 1",
"source": "eip.md",
"summary": "The proposal explicitly identifies EIP-20 token balances as affected by deactivation."
},
{
"locator": "Backwards Compatibility, paragraph 2; Security Considerations, item 2",
"source": "eip.md",
"summary": "Same-address recreation and upgrade patterns using CREATE2 after SELFDESTRUCT are explicitly broken."
},
{
"locator": "Frontmatter and body",
"source": "supporting/eip-20.md",
"summary": "The allowlisted supporting document identifies EIP 20 but states that its specification was moved, so it supplies no additional interaction detail."
}
],
"exceptional_score_justification": "Not applicable; score is below 4.",
"id": "cross_eip_interactions",
"interacting_eips": [
20
],
"rationale": "EIP-20 token-state behavior and CREATE2-based address lifecycle behavior need coordinated consideration, but the package describes a limited interaction surface centered on SELFDESTRUCT-dependent patterns.",
"score": 2,
"uncertainty_note": "The package does not provide a numbered EIP for CREATE2, and the supporting EIP-20 file contains no substantive token specification.",
"under_specified": false,
"unidentified_interactions": [
"CREATE2-based same-address recreation"
]
}
],
"eip": 4758,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:4758:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The Abstract says funds go to the caller, while the Specification says they go to the target.",
"The word \"immediately\" does not define a complete execution or state-access sequence.",
"The opcode's post-rename halting behavior and unchanged base gas treatment are not expressly stated."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "8e4973a1ea21de41953a6ff56ba17f2e45067559963e8f9ab5aeb3b624ea5def",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4758.md",
"git_blob_sha": "df7433a9a0f56d5629e9ec2219623540590487ef",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-4758.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-4758.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-4758.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-4758.yaml",
"sha256": "78d6ec6f4430d09e3655a9b15fa55c404c9a8182ce7d78b1478a87a7c621a6df"
},
"supporting_documents": [
"supporting/eip-20.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 14,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the sealed EIP-4758 snapshot. The proposal renames and changes the existing SELFDESTRUCT opcode to SENDALL so that it transfers the account's ETH without deleting code or storage or changing the nonce, and it removes SELFDESTRUCT-related refunds.",
"tier": "medium",
"title": "Deactivate SELFDESTRUCT",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 17,
"minimum": 12
},
"present": true,
"summary": "The proposal clearly removes destructive account effects and refunds, but it does not fully specify SENDALL's execution semantics. In particular, the beneficiary wording differs between the Abstract and Specification, and halting, detailed access sequencing, and target-account edge cases are not stated. These are recorded once here rather than reused as independent complexity mechanisms.",
"unresolved_questions": [
"Is the beneficiary the opcode target, as the Specification states, or the caller, as the Abstract states?",
"Does SENDALL retain SELFDESTRUCT's execution-halting behavior after the rename?",
"What are the exact balance and account-touch semantics when the target is self, empty, or newly created?",
"At what execution point do the balance accesses and transfer occur relative to gas charging and exceptional execution?"
]
}
},
"hegota:5920:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 14,
"recomputed_tier": "medium",
"recomputed_total": 14,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No new mechanism. PAY composes existing ones: warm/cold access, `GAS_NEW_ACCOUNT`, `GAS_CALL_VALUE`. Its dynamic cost is scored under Added opcodes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "New state-accessing operation whose order must be settled. PAY's gas depends on whether `addr` exists, read before the transfer is known to succeed. Unspecified: whether `addr` enters the BAL when PAY returns 0 for insufficient balance, and whether `GAS_NEW_ACCOUNT` is still charged for an account never created.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "New state-gas charging site. PAY creates an account when `addr` is absent and `val` non-zero, costing `StateGasCosts.NEW_ACCOUNT` (183,600 state gas) plus `ACCOUNT_WRITE` (9,000 execution gas). The EIP's gas table has no state-gas term, so this branch is unpriced.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Purely additive; no existing test changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing primitives suffice: balance expectations and BAL balance-change primitives already exist.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms, none needing elevated cases: `val` 0, zero-address, `addr` equal to self, the two exceptional halts (high 12 bytes set, static frame), and the gas tree over warm/cold, `addr` exists or not, and `val` zero or not. All within one opcode, so 2 rather than the revision-1 score of 3.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "One new complex opcode: `PAY` (`0xfc`), complex via its dynamic gas cost. Was 3 under revision 1; level 3 requires multiple opcodes.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Force-funding without calling is already possible via `SELFDESTRUCT` and coinbase priority fees, so no invariant is newly broken, but `PAY` makes it much cheaper.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Predates three live Amsterdam mechanisms and requires an update: whether `PAY` emits an EIP-7708 transfer log, how its accesses and balance changes enter the EIP-7928 BAL, and how account creation is priced under EIP-8037. Self-directed PAY (`addr` equal to the current address) is also unstated.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Five interacting EIPs, each individually simple: **EIP-7523** (hard precondition — PAY \"cannot be implemented on networks with empty accounts\"), **EIP-7708** (should emit a transfer log), **EIP-7928** (BAL entries), **EIP-8037** (state gas), **EIP-6780** (cited as the existing force-send route). Was 0 under revision 1.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 5920,
"fork": "hegota",
"id": "hegota:5920:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-5920.yaml",
"sha256": "133e9319f25bd9097c37495e8398243fc37a847d7a18de9014a1afe81a267ed3"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "c2b40ca1b8b4529ecee5bc90581e7e76a4b47a68",
"content_sha256": "6f9c855fe336e454e7e2e51c906e84698060f662d85e595a7c964d47ebe82324",
"git_blob_sha": "ff44f79881510d7940b6804fdc710672b49608cc",
"immutable_url": "https://github.com/ethspecs/pm/blob/c2b40ca1b8b4529ecee5bc90581e7e76a4b47a68/complexity_assessments/EIPs/EIP-5920.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-5920.md",
"pull_request": {
"draft": false,
"number": 116,
"title": "Update EIP-5920 complexity assessment to checklist revision 2",
"updated_at": "2026-08-18T21:00:22Z",
"url": "https://github.com/ethspecs/pm/pull/116"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 14,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "PAY opcode",
"under_specification": null
},
"hegota:5920:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "PAY has a new dynamic gas schedule summing warm/cold account access, new-account, and nonzero-value charges."
},
{
"locator": "Specification > Parameters; Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "The referenced warm/cold constants and transaction-wide accessed_addresses mechanism supply the account-access component."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "A new opcode-specific dynamic gas calculation is introduced using existing gas constants and access-list machinery; the proposal does not reprice or rewrite the gas rule of an existing opcode.",
"score": 2,
"uncertainty_note": "The schedule reuses existing mechanisms, but its three-part conditional sum is still a new charging rule, placing it at the score-2 anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "PAY checks static mode, pops and validates inputs, charges gas, warms the address, then conditionally transfers value and pushes success."
},
{
"locator": "Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 establishes that account-access gas and warming timing are consensus-visible and that reverted scopes restore access sets."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "PAY is a new state-accessing operation whose ordered gas charge, warm-set update, balance check, and transfer must be tested at each reachable gas boundary. This matches the score-2 new-operation anchor.",
"score": 2,
"uncertainty_note": "The broad order is explicit. Boundary coverage still multiplies across cold/warm, static/non-static, validity, balance, value, and outcome cases.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "The complete PAY schedule uses account-access, new-account, and value transfer gas only; it defines no blob gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob-related behavior appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "PAY charges ordinary EVM gas constants and specifies no StateGasCosts, state-byte rate, state-gas budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Although PAY can change balances, the snapshot adds no state-gas accounting site or mechanism as that rubric row defines it.",
"score": 0,
"uncertainty_note": "No future Hegotá state-gas integration is inferred beyond the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "The PAY gas formula contains charges only and specifies no refund."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "No refund behavior appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior; Backwards Compatibility",
"source": "eip.md",
"summary": "Opcode byte 0xfc becomes PAY and the EIP states that the change requires a hard fork."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The narrow pre-existing category that treats 0xfc as an unavailable or exceptional instruction must be fork-aware; other bytecode behavior is not changed by the proposal.",
"score": 1,
"uncertainty_note": "The package contains no test inventory, so only the mechanically implied opcode-byte regression category is counted.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "All new outputs and state effects are conditional on executing PAY; no block-wide or transaction-wide output is added for unrelated executions."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests not exercising PAY gain no new value or artifact that they must additionally assert.",
"score": 0,
"uncertainty_note": "Fork-aware invalid-opcode reworking is scored in the preceding row, not duplicated here as a new invariant.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification changes EVM opcode execution and introduces no external transition-tool field or mode."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Existing transition-tool inputs and outputs are sufficient.",
"score": 0,
"uncertainty_note": "The hard-fork requirement alone is not a new transition-tool interface.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior; Specification > Gas Cost",
"source": "eip.md",
"summary": "PAY produces ordinary EVM stack, gas, access-set, balance, success, and exceptional-halt outcomes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "These outcomes can be expressed with existing opcode/state/gas expectations; no new framework abstraction is required by the text.",
"score": 0,
"uncertainty_note": "Framework implementations and tests are prohibited and absent, so the score is limited to requirements evident from the specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "PAY validates an address, charges gas, and transfers ether without adding or modifying any cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or changed.",
"score": 0,
"uncertainty_note": "No cryptography-related behavior appears in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "Defined branches include static exceptional failure, high-byte address failure, sufficient versus insufficient balance, and success status."
},
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "Gas branches independently on warm/cold address, account existence, and zero/nonzero value."
},
{
"locator": "Specification",
"source": "supporting/eip-7523.md",
"summary": "Post-merge empty accounts are prohibited and tests containing them are invalid, creating a network-state boundary for PAY compatibility."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple edge-prone mechanisms combine, and gas-boundary ordering across the independent access, static, address, existence, value, balance, and outcome dimensions requires an elevated number of cases.",
"score": 3,
"uncertainty_note": "Exact case counts are unavailable because tests are prohibited, but the multiplicative dimensions are explicit in the sealed specifications.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "PAY changes opcode execution and defines no block RLP field or validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-RLP syncing mechanism is introduced.",
"score": 0,
"uncertainty_note": "No syncing surface appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal contains no Engine API endpoint, field, or communication rule."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced.",
"score": 0,
"uncertainty_note": "No Engine API surface appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The feature is implemented as an EVM opcode, not a system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No system-contract deployment or address is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "PAY applies generally to EVM execution and names no system contract or special system-contract behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "No system-contract interaction appears in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Behavior; Specification > Gas Cost",
"source": "eip.md",
"summary": "One opcode, PAY at 0xfc, takes two stack values, performs conditional balance transfer, and has dynamic gas based on state and value."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "PAY is a single complex opcode because it has nontrivial stack/state behavior and a dynamic gas cost.",
"score": 2,
"uncertainty_note": "The dynamic gas schedule independently satisfies the score-2 complexity anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "The specification introduces PAY and does not change any existing opcode result or deprecate an opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified.",
"score": 0,
"uncertainty_note": "References to CALL, EXTCALL, and INVALID are comparative or motivational only.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal adds an opcode and no precompile address or precompile function."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "No precompile mechanism appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "PAY performs no recipient code call and specifies no precompile logic or gas change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "A precompile address can receive value like another address, but its precompile behavior is untouched.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes EVM bytecode execution only and defines no transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface-level encoding change is introduced.",
"score": 0,
"uncertainty_note": "The opcode byte assignment is not a transaction/block/interface encoding change under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "PAY is available through EVM bytecode and no transaction envelope or type is added."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "No transaction-type surface appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The hard-fork change concerns opcode execution and does not alter transaction validity or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic-gas calculation is changed.",
"score": 0,
"uncertainty_note": "Exceptional opcode execution is not transaction-envelope validity under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal defines no block-body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "No block/header surface appears in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility; Specification",
"source": "eip.md",
"summary": "The proposal requires a hard fork but specifies only post-activation opcode behavior, with no activation-block state or internal-variable mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No fork-block migration or modification is introduced.",
"score": 0,
"uncertainty_note": "Activation of a new opcode rule alone does not satisfy this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior; Specification > Gas Cost",
"source": "eip.md",
"summary": "PAY adds bounded account lookup, access-set update, balance checks, and at most one balance transfer, without recipient execution."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new mechanism warrants isolated benchmarks for cold/warm and account creation/value-transfer paths, but it is bounded and does not alter performance of executions that do not use PAY.",
"score": 1,
"uncertainty_note": "No package implementation or benchmark evidence is available or permitted; the score reflects only the specified work.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation; Specification > Behavior; Security Considerations",
"source": "eip.md",
"summary": "PAY changes balances without recipient execution, must reject static execution, returns failure for insufficient balance, and makes forced funding cheaper and easier."
},
{
"locator": "Abstract; Backwards Compatibility",
"source": "supporting/eip-7702.md",
"summary": "Delegated EOAs can execute code and spend their balances when called, making PAY's no-code-execution guarantee relevant to delegated accounts."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Balance mutation interacts with static-state protection, account/access bookkeeping, and delegated-code expectations. These are a limited set of critical components requiring targeted review and fuzzing, not an extensive redesign across multiple security subsystems.",
"score": 2,
"uncertainty_note": "The EIP argues forced funding is already possible, reducing but not removing implementation risk; no prohibited deployment evidence is used.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior; Specification > Gas Cost",
"source": "eip.md",
"summary": "The text specifies warming and value transfer but does not explicitly say whether zero-value PAY to a nonexistent address performs account-touch or account-creation bookkeeping, nor precisely define the existence predicate."
},
{
"locator": "Specification",
"source": "supporting/eip-7523.md",
"summary": "Empty accounts are prohibited post-merge and test cases containing them are invalid, making the missing zero-value/nonexistent-account wording localized and strongly constraining its intended resolution."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A small, localized account-lifecycle detail is not stated normatively, but the zero new-account charge and EIP-7523 dependency give it an obvious intended reading. This matches the score-1 anchor.",
"score": 1,
"uncertainty_note": "The package contains no permitted client, devnet, or discussion evidence; the ambiguity is assessed from the sealed specification alone.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Specification > Behavior; Specification > Gas Cost; Motivation",
"source": "eip.md",
"summary": "EIP-5920 requires 214, 2929, and 7523, and explicitly motivates PAY for delegated EOAs introduced by EIP-7702."
},
{
"locator": "Specification",
"source": "supporting/eip-214.md",
"summary": "Static execution makes state-changing operations exceptional."
},
{
"locator": "Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "Warm/cold account charging and accessed-address updates are transaction scoped."
},
{
"locator": "Specification",
"source": "supporting/eip-7523.md",
"summary": "Post-merge empty accounts are prohibited and such test cases are invalid."
},
{
"locator": "Specification > Delegation indicator; Backwards Compatibility",
"source": "supporting/eip-7702.md",
"summary": "Delegated EOAs execute pointed-to code on calls and can spend balances during execution."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
214,
2929,
7523,
7702
],
"rationale": "Coordinated cases are needed for static failure (214), warm/cold access effects (2929), the empty-account network constraint (7523), and payment to delegated EOAs without code execution (7702). The interactions are explicit but localized and do not require extensive redesign of existing vectors.",
"score": 2,
"uncertainty_note": "References to EIPs 141, 1153, 1283, 2200, and 6780 are rationale, historical context, or alternative mechanisms and are not counted as coordinated mechanism dependencies.",
"under_specified": false,
"unidentified_interactions": [
"Existing CALL-style value-transfer and new-account gas semantics; no EIP number is identified in the package."
]
}
],
"eip": 5920,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:5920:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The specification's ordered list places gas charging before warming, but the existence lookup needed to calculate gas necessarily precedes the charge; tests should distinguish lookup, charge, recorded access, and transfer at exact gas boundaries.",
"PAY to the current address and PAY to a delegated EOA are constructible balance-transfer cases; the general transfer wording implies ordinary balance semantics while expressly excluding recipient code execution."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "f9b6d29381744114128f035d4a2a989a3d6ae08f838506fff96cd3c76e26ff11",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-5920.md",
"git_blob_sha": "f8c6f353cb4690043c096995ea1877bf763fb987",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-5920.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-5920.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-5920.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-5920.yaml",
"sha256": "8f536805b310c84df98dbb82f22fc4f3806391cd8e032b7264ce305b24773803"
},
"supporting_documents": [
"supporting/eip-141.md",
"supporting/eip-214.md",
"supporting/eip-1153.md",
"supporting/eip-1283.md",
"supporting/eip-2200.md",
"supporting/eip-2929.md",
"supporting/eip-6780.md",
"supporting/eip-7523.md",
"supporting/eip-7702.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 16,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the sealed Draft EIP-5920 snapshot. The proposal adds one state-accessing, dynamically priced PAY opcode that moves ether without executing recipient code. The principal test matrix combines gas-boundary ordering with warm/cold, static/non-static, valid/invalid address, existing/nonexistent recipient, zero/nonzero value, sufficient/insufficient balance, success/revert, and direct/delegated recipient cases; independent dimensions multiply rather than merely add.",
"tier": "medium",
"title": "PAY opcode",
"under_specification": {
"affected_criteria": [
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 16,
"minimum": 15
},
"present": true,
"summary": "The proposal is materially but narrowly under-specified for zero-value PAY to a nonexistent address: it gives the gas branch and warm-set update but does not normatively state whether account-touch/account-creation bookkeeping occurs or define the account-existence predicate. EIP-7523 strongly constrains the intended result, so this is recorded once under the consensus-ambiguity criterion and is not multiplied across other anchors.",
"unresolved_questions": [
"Does zero-value PAY to a nonexistent address only warm the address, or also touch or create an account for state-transition bookkeeping?",
"What exact account-existence predicate governs GAS_NEW_ACCOUNT and recipient creation for PAY on EIP-7523-compatible networks?"
]
}
},
"hegota:7645:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"22 blank score cells are interpreted as zero only because the published total equals the sum of every nonblank cell."
],
"published_tier": "low",
"published_total": 8,
"recomputed_tier": "low",
"recomputed_total": 8,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Considerable, but one contrived category — tests that read ORIGIN. `Op.ORIGIN` appears in **9 hand-written test files**, and ORIGIN in **121 files under `tests/ported_static/`**. Unlike CALLCODE or SELFDESTRUCT, ORIGIN is not woven through call-graph or state-lifecycle tests; the affected set is precisely the tests that assert on the transaction initiator. This row also absorbs the cost of re-baselining tests that exercise ORIGIN alongside other features.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "A single boundary-prone mechanism. The cases are the top-level frame (where ORIGIN and SENDER already agree, so the change is invisible), then one frame-entry variant each for CALL, CALLCODE, DELEGATECALL and STATICCALL, plus an EIP-7702 delegated frame. Small and fixed — the EIP's own Test Cases section says exactly this.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "ORIGIN (0x32) keeps its opcode and cost but returns the current frame's caller instead of the transaction initiator. Scored 1 rather than the anchor's binary 3 because the change is a one-line substitution with no new mechanism: the value pushed comes from a field the frame already carries. See Special Considerations — this row is defined as 0/3 with no intermediate level, which over-scores trivial opcode changes.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The blast radius is unknown and has to be determined before this can ship. The EIP asserts that for existing misuse affected negatively \"a clear example has yet to be identified\" — but `require(tx.origin == msg.sender)` is the standard idiom for \"the caller is an EOA, not a contract\", and aliasing makes it unconditionally true. Every contract using that guard silently loses it, and it fails **open**: the contract-caller patterns it was written to block (flash-loan and reentrancy shapes) become reachable again. Nobody has measured how many deployed contracts depend on it, in what value, or what each one gates. That is a substantial change to the security assumptions of an unquantified set of live contracts, and it needs on-chain analysis plus extensive review before the change can be judged safe — not a test-suite exercise.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A few details unspecified but with an obvious intended reading. \"Return the same value as CALLER\" fully determines the pushed value in every frame type, including DELEGATECALL. The one genuine omission is that **the EIP does not state a gas cost at all** — not that it is unchanged, not what it becomes. Left at 1 rather than 2 because either answer is trivial on both the specs and the testing side: ORIGIN and CALLER are both fixed-cost, and settling it needs no back-and-forth with clients.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Not scored. ORIGIN is read by EIP-7702 delegated frames and is load-bearing in the ERC-4337 bundler-authority example the EIP cites, but in every case the consequence is only that existing tests need updating — which is already counted under \"Patterns affecting pre-existing tests\". There is no coordinated cross-EIP design question and no other EIP's vectors need re-deriving, so scoring here would double-count.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7645,
"fork": "hegota",
"id": "hegota:7645:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7645.yaml",
"sha256": "ae8feeb96072a833ab223bf238b67f2d35110a8eb13799d9c4803718188d0ce2"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "2f541d3e66f737d089c3a3e89707988637af2948",
"content_sha256": "ea15e0e024f426a7ef02284d2c13239f19716fdf6c56f3110182fa358016ffae",
"git_blob_sha": "3e6403a4b06ef577fecd83e870f54f48ae721187",
"immutable_url": "https://github.com/ethspecs/pm/blob/2f541d3e66f737d089c3a3e89707988637af2948/complexity_assessments/EIPs/EIP-7645.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7645.md",
"pull_request": {
"draft": false,
"number": 113,
"title": "Add EIP-7645 complexity assessment",
"updated_at": "2026-08-18T16:39:57Z",
"url": "https://github.com/ethspecs/pm/pull/113"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 8,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "low",
"title": "Alias ORIGIN to SENDER",
"under_specification": null
},
"hegota:7645:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Definition Change; EVM Implementation",
"source": "eip.md",
"summary": "The only required opcode change is the value pushed by ORIGIN: the current call's sender, as if SENDER were executed."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes an opcode result but specifies no gas cost, schedule, charging site, or accounting mechanism change.",
"score": 0,
"uncertainty_note": "The package supplies no gas schedule text for ORIGIN, but the normative change is expressly limited to the pushed value.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — EVM Implementation",
"source": "eip.md",
"summary": "ORIGIN is required only to push the current call's sender address, as if SENDER had executed."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state access is introduced or moved, and no gas charge is repositioned relative to a state access within the modified opcode.",
"score": 0,
"uncertainty_note": "No state-access pseudocode is provided, but the specified operation has no state-access step to order.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Transaction Validation",
"source": "eip.md",
"summary": "Transactions remain validated as before, with no processing change beyond the specified EVM opcode behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "blob_gas_accounting_changes",
"rationale": "The proposal neither introduces nor modifies blob gas accounting.",
"score": 0,
"uncertainty_note": "Blob gas is not discussed; the stated transaction-processing scope excludes such a change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Definition Change; Transaction Validation",
"source": "eip.md",
"summary": "The proposal changes only ORIGIN's returned value and leaves transaction processing otherwise unchanged."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "state_gas_accounting_changes",
"rationale": "No state write, state-gas charging site, state-gas rate, budget, reservoir, or spill behavior is changed.",
"score": 0,
"uncertainty_note": "State gas is not mentioned, consistently with the proposal's value-only opcode change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — EVM Implementation",
"source": "eip.md",
"summary": "The EVM change is solely to substitute the current sender value for the original transaction initiator value returned by ORIGIN."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_evm_gas_refund",
"rationale": "No refund mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "Refunds are not discussed, and none is implied by the specified stack-value substitution.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Tests must compare ORIGIN and SENDER for CALL, STATICCALL, DELEGATECALL, and CALLCODE in direct and multi-hop executions at each frame."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Contracts relying on the distinction between ORIGIN and SENDER for logic or security are stated to be affected."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing ORIGIN expected-result tests in nested call contexts must be updated, but this is a localized subset centered on one opcode rather than a broad reworking of unrelated test categories.",
"score": 1,
"uncertainty_note": "The package contains no inventory of pre-existing vectors, so the size of the affected subset cannot be established precisely.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The ORIGIN-equals-SENDER assertions are prescribed for direct and multi-hop call tests of this feature."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The package does not require tests unrelated to EIP-7645 to assert a new block-wide or transaction-wide artifact; the equality is the behavior under test in feature-specific cases.",
"score": 0,
"uncertainty_note": "The package does not describe the existing test suite, but it specifies no new invariant output that every pre-existing test must gain.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Transaction Validation",
"source": "eip.md",
"summary": "Transaction structure and processing logic remain unchanged beyond the internal EVM opcode behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool field or interface mechanism is required by the proposal.",
"score": 0,
"uncertainty_note": "Transition tooling is not discussed, but the normative inputs and outputs do not change.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Required cases consist of ordinary call-family executions and comparisons of the values produced by two existing opcodes."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_test_framework_primitives",
"rationale": "The described tests require no new expectation type, modifier, helper, or framework-level abstraction.",
"score": 0,
"uncertainty_note": "The package does not document a specific framework, so this conclusion is limited to the primitives demanded by the EIP text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Definition Change",
"source": "eip.md",
"summary": "The feature aliases the return value of one existing environmental opcode to another existing environmental opcode."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cryptography",
"rationale": "No cryptographic primitive or cryptographic behavior is introduced or modified.",
"score": 0,
"uncertainty_note": "None; the complete specification contains no cryptographic operation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The test matrix explicitly spans CALL, STATICCALL, DELEGATECALL, and CALLCODE, both direct and multi-hop, with equality checked at each frame."
},
{
"locator": "Specification — Definition Change",
"source": "eip.md",
"summary": "The alias is required in all execution contexts."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "edge_boundary_conditions",
"rationale": "Multiple call-context boundaries must be covered because sender propagation differs across the four call mechanisms and across nested frames. The EIP identifies these cases directly, and none is shown to need an elevated case count beyond that bounded matrix.",
"score": 2,
"uncertainty_note": "Creation and other less common execution contexts are covered normatively by \"all contexts\" but are not enumerated in the supplied test cases.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Transaction Validation",
"source": "eip.md",
"summary": "Transactions retain their existing structure and processing logic outside the opcode behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "block_syncing_changes",
"rationale": "No block RLP validation or syncing mechanism is introduced.",
"score": 0,
"uncertainty_note": "Block synchronization is not discussed because no block encoding or validation surface changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — EVM Implementation; Transaction Validation",
"source": "eip.md",
"summary": "The complete normative change is internal EVM opcode behavior, with transaction structure and processing otherwise unchanged."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "The Engine API is not named, and the specified change requires no new consensus-to-execution input.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification requires only a behavioral alteration to ORIGIN in all EVM clients."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_system_contracts",
"rationale": "No system contract is created.",
"score": 0,
"uncertainty_note": "None; the proposal's complete mechanism is an opcode alias.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No system contract code, state, or action is identified; only ORIGIN's EVM return value is changed."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_system_contracts",
"rationale": "The package provides no direct modification or package-grounded indirect effect on a pre-existing system contract.",
"score": 0,
"uncertainty_note": "Arbitrary contracts that execute ORIGIN can be affected, but no such system contract is identified in the sealed evidence and none is inferred.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Definition Change",
"source": "eip.md",
"summary": "The proposal alters the already identified ORIGIN opcode at 0x32 and references the existing SENDER/CALLER opcode at 0x33."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None; both opcodes are presented as existing instructions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Definition Change; EVM Implementation",
"source": "eip.md",
"summary": "ORIGIN (0x32) must cease returning the original transaction initiator and instead push the current call's sender, as if SENDER/CALLER executed."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_opcodes",
"rationale": "A pre-existing opcode's non-gas behavior and observable result are directly modified, which maps to the row's score-3 anchor.",
"score": 3,
"uncertainty_note": "None; this is the proposal's explicit normative change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specified mechanism is an opcode behavior change only."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None; no precompile surface appears in the specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specified mechanism modifies ORIGIN and no precompile logic or gas."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "None; no precompile is identified by the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Transaction Validation",
"source": "eip.md",
"summary": "Transaction structure remains unchanged, with no processing change beyond the EVM opcode behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding changes are introduced.",
"score": 0,
"uncertainty_note": "Encoding formats are not discussed because the proposal changes no encoded object.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Transaction Validation",
"source": "eip.md",
"summary": "Transactions must retain their prior structure and validation."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None; unchanged transaction structure is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Transaction Validation",
"source": "eip.md",
"summary": "Transactions must be validated as before; transaction structure and processing logic do not change beyond the opcode behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity rules and intrinsic gas calculation are expressly unchanged.",
"score": 0,
"uncertainty_note": "None; the absence of a validity change is normative.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete change is confined to ORIGIN's EVM stack result."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced.",
"score": 0,
"uncertainty_note": "None; no block-level data is required by the mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal specifies a runtime opcode-result change and no fork-block state transition or mutation of a pre-existing internal variable."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary activation of the new opcode rule does not add the state or internal-variable modification required by this anchor.",
"score": 0,
"uncertainty_note": "The EIP does not name an activation block, but it also specifies no special activation-block action.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — EVM Implementation",
"source": "eip.md",
"summary": "ORIGIN substitutes one already available execution-context address for another when pushing a single stack value."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "performance_risks",
"rationale": "The package identifies no new mechanism requiring performance validation or interaction with existing performance behavior.",
"score": 0,
"uncertainty_note": "No benchmarks are supplied, but the normative operation remains a single environmental-value push.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Contracts relying on the ORIGIN/SENDER distinction for logic or security are explicitly stated to be affected."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The EIP aims to remove ORIGIN-specific vulnerabilities but acknowledges possible negative effects on existing ORIGIN misuse and says no clear example had yet been identified."
},
{
"locator": "Rationale — Allowing tx.origin as Signer; Security Considerations — Allowing tx.origin as Signer",
"source": "supporting/eip-3074.md",
"summary": "Package evidence identifies nested msg.sender-equals-tx.origin behavior as capable of breaking atomic-sandwich protections and reentrancy guards."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "security_risks",
"rationale": "Taken together, the sealed evidence shows that making ORIGIN equal CALLER in all call frames substantially changes a security-critical identity invariant across multiple call mechanisms and ORIGIN-dependent authorization patterns. Incorrect implementation or incomplete compatibility analysis therefore warrants extensive security review and fuzzing.",
"score": 3,
"uncertainty_note": "The EIP supplies no affected-contract inventory and concedes that a clear negative legacy example had not been identified, so practical prevalence is unresolved even though the altered invariant is explicit.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Definition Change; EVM Implementation",
"source": "eip.md",
"summary": "In all execution contexts, ORIGIN must return exactly the value SENDER/ CALLER would return in the current call."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Direct and multi-hop expected behavior is stated as equality at the target and at each frame for all four listed call-family instructions."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The as-if-SENDER rule determines the observable result for constructible execution contexts without requiring clients to select a new value or precedence rule.",
"score": 0,
"uncertainty_note": "The package has no implementation, devnet, or open-question record, and the EIP is marked Stagnant; however, no specific unresolved consensus behavior appears in the normative text.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The proposal explicitly identifies EIPs 3074, 4337, and 7377 as account- abstraction efforts whose handling of ORIGIN is affected."
},
{
"locator": "Rationale — Allowing tx.origin as Signer",
"source": "supporting/eip-3074.md",
"summary": "EIP-3074 permits authorized to equal tx.origin and analyzes the resulting nested msg.sender-equals-tx.origin invariant and compatibility risks."
},
{
"locator": "Entire packaged file",
"source": "supporting/eip-4337.md",
"summary": "The packaged EIP-4337 document contains only moved-file metadata, while EIP-7645 itself supplies the bundler/ORIGIN interaction description."
},
{
"locator": "Specification — Processing — Transaction Execution; Rationale — Manipulating transaction origin",
"source": "supporting/eip-7377.md",
"summary": "EIP-7377 deliberately assigns a derived transaction origin so caller-equals-origin checks keep their intended role, directly intersecting EIP-7645's ORIGIN alias."
}
],
"exceptional_score_justification": "Not applicable; the score is not 4.",
"id": "cross_eip_interactions",
"interacting_eips": [
3074,
4337,
7377
],
"rationale": "Three identified account-abstraction proposals require coordinated consideration and interaction cases, but the interaction is localized to the ORIGIN/CALLER identity axis rather than a broad redesign of each proposal's other mechanisms.",
"score": 2,
"uncertainty_note": "The EIP refers more broadly to all or most account-abstraction proposals, but names only three; the packaged EIP-4337 body is unavailable because the snapshot file only records that it moved.",
"under_specified": true,
"unidentified_interactions": [
"Other account-abstraction proposals encompassed by eip.md's statement that ORIGIN affects all or most such proposals; no additional EIP numbers are supplied in the package."
]
}
],
"eip": 7645,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7645:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"Backwards Compatibility first says the change is not fully backwards compatible and affects contracts relying on the ORIGIN/SENDER distinction, then ends with \"No backward compatibility issues found.\"",
"Security Considerations acknowledges possible harm to existing ORIGIN use but states that a clear negative example had not yet been identified, leaving the affected security population unquantified.",
"The EIP's broad reference to all or most account-abstraction proposals exceeds the three proposals identified by number in the sealed evidence."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "57c2d8606b731a01ae2077f817032f31629a379fa8b403fe66e67a5fc6660647",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7645.md",
"git_blob_sha": "305bff3d36a5de20d5071f4c85ec9a4bcc6bc677",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7645.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7645.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7645.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7645.yaml",
"sha256": "0808da455469dbfd26fe27b907a801c40ae629ea952647f5e3680bea7d2a45b7"
},
"supporting_documents": [
"supporting/eip-3074.md",
"supporting/eip-4337.md",
"supporting/eip-7377.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 11,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the sealed EIP-7645 snapshot. The proposal changes the existing ORIGIN opcode (0x32) to return the current execution frame's SENDER/CALLER value in all contexts, while leaving transaction structure, validation, and processing otherwise unchanged. The package's supporting evidence is used only for the explicitly linked account- abstraction interactions.",
"tier": "low",
"title": "Alias ORIGIN to SENDER",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 9
},
"present": true,
"summary": "The normative opcode result is precise, but the package does not inventory affected pre-existing tests or deployed security patterns, contains inconsistent backwards-compatibility statements, provides no implementation or devnet/open-question evidence, and does not identify the additional account-abstraction proposals covered by its broad interaction claim.",
"unresolved_questions": [
"Which pre-existing execution test vectors exercise ORIGIN in nested call contexts and therefore require changed expected results?",
"Which existing contract authorization, sandwich-protection, or reentrancy patterns materially rely on ORIGIN differing from SENDER?",
"Have clients or devnets exposed any constructible case not resolved by the as-if-SENDER rule? The sealed package provides no such process evidence.",
"Which additional account-abstraction EIPs are included in the phrase \"all or most account abstraction proposals,\" and how many require coordinated cases?"
]
}
},
"hegota:7666:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 12,
"recomputed_tier": "medium",
"recomputed_total": 12,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No gas accounting mechanism changes: the identity price constants disappear with the precompile, and the pricing shift is the \"Modified precompiles\" row's substance.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Measured: an EELS prototype flips 141 fixture executions across 11 functions — a minor, well-scoped subset, every flip diagnosed. Notably, several ported static fillers use the identity precompile as a memory-copy *primitive* inside unrelated harnesses (the MODEXP boundary suites), so the flips reach slightly beyond nominal identity tests.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing primitives suffice with minor extension: a fork precompile-list subtraction and code pre-allocation at the retired address.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The identity function is a memory copy; nothing cryptographic is touched.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "A single boundary-prone mechanism: equivalence of the replacement code across calldata lengths, gas boundaries, and call contexts (STATICCALL, DELEGATECALL, EIP-7702 delegation with precompiles disabled). The 7-byte program keeps the surface small.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "One stateless code deposit at the retired address; nothing in the protocol invokes it as a system actor. The deployment act is scored under \"New fork activation mechanism\".",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "A single pre-existing precompile's behavior changes: identity pricing moves from the precompile schedule to ordinary EVM execution, and EIP-2929 pre-warming at `0x04` is silently lost (unstated by the EIP) — first access in a transaction becomes cold.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Code is written to `0x04` at the start of the activation block — a protocol-mandated install with no deploying transaction, implemented in the prototype through the spec's irregular-state-transition hook (code only, nonce and balance preserved) plus a genesis pre-allocation for test fixtures.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "A seven-opcode copy program with gas scaling identical in shape to the precompile it replaces; nothing requires performance validation.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Consensus-critical bytecode replaces a native implementation, but the program is seven bytes, specified verbatim in the EIP, and validated in isolation by differential runs against the retired implementation.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The bytecode itself is pinned by the EIP, but deployment-account details are not: nonce/balance handling and interaction with any pre-existing state at `0x04` at the activation block (the prototype preserves both, installing code only), and the EIP-2929 warm-set consequence is unstated. All have an obvious intended reading.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Limited, independently testable interactions: EIP-2929 (warm-set membership at the retired address) and EIP-8200 (the shared retire-and-install mechanism, whose deployment semantics should be specified identically).",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7666,
"fork": "hegota",
"id": "hegota:7666:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7666.yaml",
"sha256": "dd0394a463f7869f2840bdd2161bf8defa5b7e8f0273c3e200996517b7c43ca9"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "4a25f38a8f36442fdb10dcae447a51a85f82c7e8",
"content_sha256": "28cc3069dff9b777a277374637afd8c47c3c75b35f6c83ac8bc922888f9c8d44",
"git_blob_sha": "7e1838587c5e474282b381c5a899eab09fd3b0d3",
"immutable_url": "https://github.com/ethspecs/pm/blob/4a25f38a8f36442fdb10dcae447a51a85f82c7e8/complexity_assessments/EIPs/EIP-7666.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-7666.md",
"pull_request": {
"draft": true,
"number": 112,
"title": "Add EIP-7666 complexity assessment",
"updated_at": "2026-08-18T08:55:08Z",
"url": "https://github.com/ethspecs/pm/pull/112"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 12,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "medium",
"title": "EVM-ify the identity precompile",
"under_specification": null
},
"hegota:7666:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The identity address stops using precompile handling and instead executes fixed EVM code; the proposal explicitly says the resulting gas costs are slightly different."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Existing identity-precompile metering is replaced by ordinary opcode, copy, and memory-expansion metering. This updates an existing gas-accounting path without introducing a new gas-accounting mechanism.",
"score": 1,
"uncertainty_note": "The text does not enumerate the exact gas deltas, but the fixed bytecode determines the post-activation execution path under existing EVM rules.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The change installs code at the activation boundary and removes precompile treatment; it specifies no reordering of state access or gas charging inside any opcode."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's internal state-access or gas-charge ordering is changed. The activation write is a block-boundary transition and is outside this anchor.",
"score": 0,
"uncertainty_note": "Calls to 0x04 take a different callee execution path, but the package does not change the within-opcode ordering measured by this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification is limited to address 0x04 code and precompile treatment."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas rule or mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob-related behavior appears anywhere in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal mandates a one-time code assignment at activation but defines no StateGasCosts, state-byte rate, state-gas budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The irregular activation state change does not introduce a state-gas charging site or alter state-gas accounting; its complexity is scored under fork activation.",
"score": 0,
"uncertainty_note": "The EIP does not discuss charging the protocol-directed activation write, so no state-gas mechanism can be scored from the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The only stated gas effect is a different execution cost for identity behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is added or modified.",
"score": 0,
"uncertainty_note": "The proposal contains no refund behavior.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "Identity calls change from precompile execution to EVM bytecode and have slightly different gas costs beginning at one fork boundary."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor, localized subset of existing tests covering identity-precompile calls, their gas thresholds, or the activation boundary must be reworked. No diverse or major test category is changed by the package evidence.",
"score": 1,
"uncertainty_note": "The package contains no test inventory, so the size classification follows only the proposal's single-address scope.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "At activation, address 0x04 must contain the specified bytecode and must cease to be treated as a precompile from that block onward."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Activation-spanning post-state tests form a broad category that mechanically gains an assertion about code at 0x04. The text does not support the stronger claim that every fork test gains a dedicated assertion or that pre-fork vectors are re-derived.",
"score": 2,
"uncertainty_note": "The exact breadth depends on how existing tests represent fork-transition post-state, which is not described in the package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification keys the state change to the activation block but adds no input, output, field, or communication mechanism for transition tools."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is specified or required by the text.",
"score": 0,
"uncertainty_note": "A tool must apply the rule at the activation block, but any implementation-specific plumbing cannot be inferred as a new interface field from this package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Rationale",
"source": "eip.md",
"summary": "The behavior is expressed as fixed code installation plus ordinary EVM calldata copying and return operations."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The package provides no requirement for a new expectation type, modifier, helper, or other test-framework abstraction.",
"score": 0,
"uncertainty_note": "Fork-transition tests may need ordinary setup, but the sealed evidence does not show that existing primitives are insufficient.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale",
"source": "eip.md",
"summary": "The replacement code only copies calldata to memory and returns it."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No cryptographic operation appears in the specified bytecode.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Rationale; Backwards Compatibility",
"source": "eip.md",
"summary": "Behavior changes exactly at the activation block, while the replacement handles variable-length calldata through copy and memory operations with different gas costs."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Testing has at least two boundary-prone dimensions: before/at/after activation and calldata/memory/gas thresholds for equivalent output versus out-of-gas behavior. Neither is shown to require an elevated case count.",
"score": 2,
"uncertainty_note": "The EIP gives no explicit boundary test matrix, so only boundaries directly implied by the activation rule and bytecode are counted.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The block format and RLP validation are not changed."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-RLP validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "The activation state transition is not a block-encoding change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal defines no Engine API endpoint, field, or message change."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "No Engine API surface is present in the package evidence.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification; Rationale",
"source": "eip.md",
"summary": "The protocol installs fixed EVM code at address 0x04; that code only echoes calldata and contains no state-writing or system-action instruction."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "One stateless protocol-installed contract is introduced, and it triggers no new system action.",
"score": 1,
"uncertainty_note": "The contract occupies a former precompile address, but after activation it is ordinary EVM code and fits the rubric's non-stateful system-contract anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal replaces a precompile with newly installed code and identifies no pre-existing system contract whose code, state, or behavior is changed."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is modified; the precompile change is scored in its dedicated anchor and the replacement contract in the added-contract anchor.",
"score": 0,
"uncertainty_note": "The package does not classify the identity precompile as a system contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale",
"source": "eip.md",
"summary": "The replacement bytecode is composed entirely of named existing opcodes."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced by EIP-7666.",
"score": 0,
"uncertainty_note": "PUSH0 is a dependency defined by EIP-3855, not an opcode newly introduced by this proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Rationale",
"source": "eip.md",
"summary": "The proposal changes precompile classification and installs code, not opcode results."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "Different gas and callee execution at address 0x04 do not constitute a specified result change to an opcode under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal removes identity-precompile treatment and adds no precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced.",
"score": 0,
"uncertainty_note": "The replacement is explicitly EVM code, not another precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "Identity at 0x04 ceases to be treated as a precompile and its equivalent output is supplied by EVM code with slightly different gas costs."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "One pre-existing precompile has its behavior modified through removal of precompile handling and replacement by contract execution. It is the simple identity operation, so the complex-single-precompile score does not apply.",
"score": 2,
"uncertainty_note": "Functional output is intended to remain equal, but execution classification and gas behavior change unambiguously.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No transaction, block, or interface encoding is changed."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal introduces no RLP, SSZ, or other interface-level encoding change.",
"score": 0,
"uncertainty_note": "The literal EVM bytecode value is contract code, not an interface encoding.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification introduces no transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "Transactions may call 0x04, but their type is unchanged.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The change affects execution and gas consumed at one called address, not transaction validity rules or intrinsic-gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity mechanism or intrinsic gas rule is changed.",
"score": 0,
"uncertainty_note": "Runtime out-of-gas outcomes are covered by EVM gas behavior, not validity.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The activation rule adds no block-body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "Activation at a block boundary does not itself add a field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "At the start of the activation block, clients must set address 0x04 code to the specified seven-byte EVM program and stop treating the address as a precompile."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The proposal explicitly mandates a state modification at the fork-activation block, exactly matching the score-3 anchor.",
"score": 3,
"uncertainty_note": "Precompile classification also changes at the same boundary, but score 3 is already the permitted non-exceptional maximum.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation; Specification; Rationale",
"source": "eip.md",
"summary": "Native identity-precompile handling is replaced by a short EVM program that performs calldata copying and memory return at a single address."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The replacement execution path warrants isolated benchmarking across input sizes, but it is self-contained and does not alter general EVM performance behavior.",
"score": 1,
"uncertainty_note": "The package gives no benchmark results or usage profile that would support a broader impact score.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Security Considerations",
"source": "eip.md",
"summary": "A precompile is replaced by fixed stateless code; the EIP says no functionality is made cheaper or newly introduced and identifies no security concern."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Correct code installation, precompile deactivation, and output equivalence are consensus-sensitive, but the mechanism is self-contained, isolatable, and does not state a change to existing security invariants.",
"score": 1,
"uncertainty_note": "The package assertion of no security concern is not implementation evidence, so a minimal self-contained review burden remains.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Rationale",
"source": "eip.md",
"summary": "The address, exact bytecode, activation timing, post-activation classification, and intended calldata-return behavior are all stated explicitly."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "For the specified execution-layer surface, constructible outcomes follow from the exact code and existing EVM execution semantics; no unresolved consensus choice is exposed by the sealed text.",
"score": 0,
"uncertainty_note": "External implementation, devnet, and discussion status are prohibited and unavailable; confidence is therefore limited to the textual completeness of the snapshot.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter `requires`; Rationale",
"source": "eip.md",
"summary": "The proposal requires EIP-3855 because its fixed bytecode uses PUSH0."
},
{
"locator": "Specification",
"source": "supporting/eip-3855.md",
"summary": "EIP-3855 defines PUSH0 at opcode 0x5f with a cost of 2 gas."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
3855
],
"rationale": "EIP-7666 has one narrow dependency on EIP-3855 for execution of the embedded PUSH0 instructions. The interaction is limited and most replacement behavior can be tested independently, so coordinated testing is non-critical.",
"score": 1,
"uncertainty_note": "EIP-5656 appears only as motivation and is neither required nor used by the specified replacement bytecode, so it is not counted as an interacting EIP.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7666,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7666:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The package does not describe the test inventory or transition-tool plumbing, limiting confidence in test-breadth and interface scores without creating a textual consensus gap.",
"The normative instruction to set code does not separately enumerate unchanged account fields; the assessment reads it as a code-only update and does not multiply that ordinary reading across state-gas or system-contract anchors."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "ea392f32efc0ae218c2f37d75577976a067f6a846caeb228fb76fa2ae3c2227b",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7666.md",
"git_blob_sha": "6b0b4a6d131d9a24ef90b455739dde0c46f524a3",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7666.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7666.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7666.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7666.yaml",
"sha256": "3bc02ad8f419204ceaece7a9ffd8fe399694ae6ef5a2a555816e6fb0df36bd0d"
},
"supporting_documents": [
"supporting/eip-3855.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 15,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the Draft EIP-7666 snapshot. The proposal removes identity-precompile treatment at address 0x04 on the activation block and installs fixed stateless EVM bytecode there, preserving calldata echo functionality while changing gas behavior. Only eip.md, rubric.md, and supporting/eip-3855.md were used as scoring evidence.",
"tier": "medium",
"title": "EVM-ify the identity precompile",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 15,
"minimum": 15
},
"present": false,
"summary": "No material execution-layer under-specification is identified in the sealed proposal. The exact activation, address, code bytes, and removal of precompile treatment define the state transition and subsequent execution path.",
"unresolved_questions": []
}
},
"hegota:7668:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"22 blank score cells are interpreted as zero only because the published total equals the sum of every nonblank cell."
],
"published_tier": "low",
"published_total": 7,
"recomputed_tier": "low",
"recomputed_total": 7,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "1 hand-written test file references bloom, 0 under `tests/ported_static/`. Every fixture regenerates since block hashes move, but the sources stay put.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "29 framework files under `packages/testing/src` touch the bloom: header and receipt types, blockchain builder, RPC/hive. Both types need a fork-conditional shape, 256 bytes before and zero-length after.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "`fork.py` rejects `block_logs_bloom != block.header.bloom`; that becomes a zero-length requirement. Receipts need no separate check, since a wrong bloom already surfaces as a `receipt_root` mismatch.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No field is added, an existing one is emptied. Deliberate departure: this anchor is binary 0/3 and recognises only additions. Actual removal is deferred to a future EIP.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "`eth_getLogs` might be affected and requires further review.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "**EIP-7745** and **EIP-8304** both replace what blooms were for, so whether this EIP is redundant or complementary to them needs deciding. Testable independently.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7668,
"fork": "hegota",
"id": "hegota:7668:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7668.yaml",
"sha256": "cba2a0be698b97ef6b0a708fcc55076a1040825265933209d83a6274e9033497"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "0125045895b5e3dab780afbf490a8d68c06abd1b",
"content_sha256": "6020f3af4efa29a99ef65eedfdd58b003ccb2ddfdc119db2763794d2cf0b3d89",
"git_blob_sha": "e0cc4d5614e274e0df403c26343be0a27f89461c",
"immutable_url": "https://github.com/ethspecs/pm/blob/0125045895b5e3dab780afbf490a8d68c06abd1b/complexity_assessments/EIPs/EIP-7668.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7668.md",
"pull_request": {
"draft": false,
"number": 118,
"title": "Update EIP-7668 complexity assessment to checklist revision 2",
"updated_at": "2026-08-18T23:06:30Z",
"url": "https://github.com/ethspecs/pm/pull/118"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 7,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "low",
"title": "Remove bloom filters",
"under_specification": null
},
"hegota:7668:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, paragraph 2",
"source": "eip.md",
"summary": "The proposal explicitly says that gas costs of LOG are not reduced."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas-accounting rule is changed; the only opcode-related gas decision is to retain the existing LOG costs.",
"score": 0,
"uncertainty_note": "No material uncertainty: unchanged LOG gas costs are explicit, and no other gas rule is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative requirements only make the execution-block and transaction-receipt logs blooms empty."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal does not move a state access or a gas charge within any opcode; it changes block and receipt output fields.",
"score": 0,
"uncertainty_note": "No opcode-internal state-access ordering change is stated in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative change is limited to logs-bloom values in execution blocks and receipts."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas rule or mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no blob-gas provision.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative change only requires empty logs blooms at block and receipt level."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-writing gas cost, state-gas charging site, budget, reservoir, or spill rule is changed.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no state-gas provision.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, paragraph 2",
"source": "eip.md",
"summary": "LOG gas costs remain unchanged while bloom handling is removed."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no gas-refund mechanism.",
"score": 0,
"uncertainty_note": "No refund behavior is specified anywhere in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Both every execution block's logs bloom and every transaction receipt's logs bloom are newly required to be zero bytes long."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Applications that depend on bloom filters to read events cease to work."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Pre-existing vectors that construct or validate blocks or receipts with the former bloom representation require updates across two broad output surfaces. The update is structurally mechanical, and the package does not establish the diverse test-category impact required for score 3.",
"score": 2,
"uncertainty_note": "The EIP has no testing section or test inventory, so the exact breadth of pre-existing test rework is not quantified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Bloom filters in an execution block, at top level and in receipt objects, must be empty."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "The zero-length requirement is stated for execution-block and transaction-receipt logs blooms without limiting it to logging-focused cases."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of existing block and receipt tests gains a mechanical empty-value invariant even when the test is about another behavior. The package does not show that every fork test gains the assertion or that pre-fork vectors must be re-derived, so score 3 is not supported.",
"score": 2,
"uncertainty_note": "The universal protocol wording supports broad mechanical coverage, but the sealed package does not describe how all test categories expose these outputs.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale, paragraph 1",
"source": "eip.md",
"summary": "The proposal intentionally retains the bloom fields and leaves complete field removal to a future EIP."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Existing field values change, but no transition-tool interface field or new interface mechanism is introduced.",
"score": 0,
"uncertainty_note": "The EIP does not discuss transition tools; the score follows the rubric's field/mechanism criterion and the explicit retention of existing fields.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The required result is a direct zero-byte-length condition on two existing bloom fields."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Testing an existing field for an empty byte value does not require a new expectation type, modifier, or helper on the evidence provided.",
"score": 0,
"uncertainty_note": "No framework or testing design is supplied, but the specified assertion uses ordinary value and length checks.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, paragraph 3",
"source": "eip.md",
"summary": "ZK-SNARK-based indexes are only an encouraged external application direction, not a protocol feature introduced by this EIP."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "The only normative rules require empty logs blooms."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is added or modified by the proposal.",
"score": 0,
"uncertainty_note": "The cryptographic indexing idea is non-normative and extra-protocol, so it does not create execution-layer cryptography testing here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Valid block and receipt bloom values are placed at the zero-length boundary."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The proposal introduces one simple boundary-prone rule—exactly zero bytes—applied at the block and receipt levels; tests must distinguish empty values from any non-empty representation.",
"score": 1,
"uncertainty_note": "The same simple length boundary is repeated at two sites, but the package identifies no additional interacting boundary mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "A synced execution block's top-level logs bloom and each transaction receipt's logs bloom must each satisfy a new zero-byte-length rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Block/receipt ingestion gains two simple encoded-field validation rules, one at the block level and one at the receipt level, matching the multiple-simple-mechanism anchor.",
"score": 2,
"uncertainty_note": "The EIP does not name RLP or describe sync workflows; the score is grounded in the two explicit encoded execution-object validity conditions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes existing block and receipt bloom values and specifies no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No new Engine API field or endpoint is introduced.",
"score": 0,
"uncertainty_note": "No Engine API change appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative change consists only of emptying two existing bloom fields."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no contract deployment or system action.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative change only affects execution-block and receipt bloom values."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract code, state, or behavior is directly or indirectly modified by a stated mechanism.",
"score": 0,
"uncertainty_note": "No system contract is identified in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, paragraph 2",
"source": "eip.md",
"summary": "The proposal discusses retaining the gas costs of existing LOG operations and introduces no opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is introduced.",
"score": 0,
"uncertainty_note": "The only opcode reference concerns unchanged gas costs for existing LOG operations.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specified behavior change is to block and receipt bloom fields, not to an opcode result."
},
{
"locator": "Rationale, paragraph 2",
"source": "eip.md",
"summary": "LOG gas costs are explicitly left unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode's behavior is modified or deprecated; bloom output handling changes outside the stated opcode behavior.",
"score": 0,
"uncertainty_note": "The sealed text does not define any LOG semantic change beyond explaining why its gas price stays unchanged.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Only existing logs-bloom fields receive new empty-value requirements."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no precompile mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Only existing logs-bloom fields receive new empty-value requirements."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no precompile provision.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The existing logs-bloom values in the execution block and transaction receipt are newly required to encode as zero bytes long."
},
{
"locator": "Rationale, paragraph 1",
"source": "eip.md",
"summary": "The fields are retained for now rather than removed entirely."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "This is an encoding-level change at the block and receipt interfaces: retained fields must carry a zero-length byte value. The rubric assigns 3 whenever a transaction, block, or interface encoding change is introduced.",
"score": 3,
"uncertainty_note": "The EIP does not name the serialization codec, but it explicitly changes the byte length of fields in encoded execution objects.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal applies to receipt bloom values and introduces no transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "The sealed proposal contains no transaction envelope or type addition.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The new conditions apply to execution blocks and transaction receipts, not to transaction validity or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No existing transaction type's validity rules or intrinsic gas calculation are changed.",
"score": 0,
"uncertainty_note": "Receipt-output validity is separate from the transaction-validity mechanism scored by this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, paragraph 1",
"source": "eip.md",
"summary": "The minimally disruptive design retains the existing bloom field; a future EIP may remove it entirely."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The value constraint on an existing field changes, but no new block or header field is introduced.",
"score": 0,
"uncertainty_note": "Field retention is explicit in the rationale.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal states an ongoing empty-bloom validity rule and specifies no activation-block state or internal-variable mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No special state transition or internal-variable modification at the fork-activation block is introduced.",
"score": 0,
"uncertainty_note": "Ordinary application of a new fork rule is not the activation mechanism scored by this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The proposal removes an impractical historical-query aid rather than adding a new execution mechanism."
},
{
"locator": "Rationale, paragraph 1",
"source": "eip.md",
"summary": "The stated design goal is to remove the need for clients to handle blooms while retaining the fields."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The proposal removes bloom-filter handling and introduces no new mechanism whose performance must be validated under this risk anchor.",
"score": 0,
"uncertainty_note": "The package provides no benchmarks, but it specifies removal of work rather than a new or more complex performance-sensitive mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The EIP states that no new feature is introduced or made cheaper and therefore raises no security concerns."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "No new mechanism that changes stakeholder security assumptions is introduced.",
"score": 0,
"uncertainty_note": "The sealed proposal explicitly assesses the change as raising no security concern.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "For both affected locations, the required value is expressly defined as empty, meaning zero bytes long."
},
{
"locator": "Rationale, paragraph 2",
"source": "eip.md",
"summary": "The only nearby gas question is resolved explicitly by retaining LOG gas costs."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "For constructible cases within the proposal's stated surface, clients have a determinate required byte length at both locations, and the proposal does not expose a formerly unobservable choice that needs coordination.",
"score": 0,
"uncertainty_note": "Implementation, devnet, and discussion evidence is absent from the sealed evidence set, but no unresolved normative case is visible in the provided text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, paragraph 1",
"source": "eip.md",
"summary": "A possible future EIP could remove the retained fields, but this proposal neither depends on that future cleanup nor identifies an EIP number."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "The current proposal is self-contained as two empty-bloom requirements."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "No numbered EIP dependency, modification, or conflict is identified, and the mentioned optional future cleanup is not required for this proposal to operate or be tested.",
"score": 0,
"uncertainty_note": "The prospective unnumbered cleanup is contextual sequencing, not a current coordinated-testing interaction.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7668,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7668:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The EIP mandates zero-byte values but does not name the serialization codec or describe block-sync validation workflows; the assessment treats the two object-level length requirements as two simple encoded-field validation changes."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "816047a5594113227ddc9f64b7bcc1bc56bb66f4135c03c3cb526d3049ae3882",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7668.md",
"git_blob_sha": "fbd998df2618dbc95d60be74c7bdad76f5042bd1",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7668.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7668.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7668.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7668.yaml",
"sha256": "94c2708c61ea77c286cea05504e0e49746ad76aa7951b39ea0ee67c28971d7c9"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 10,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the sealed EIP-7668 snapshot: the proposal requires the existing logs-bloom values in every execution block and transaction receipt to be zero bytes long while retaining the fields and leaving LOG gas costs unchanged.",
"tier": "low",
"title": "Remove bloom filters",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 8
},
"present": true,
"summary": "The proposal supplies no testing section or inventory of existing execution tests. Its universal block/receipt rule establishes broad structural impact, but the package does not quantify how many pre-existing test categories must be reworked or which tests expose these fields as added assertions.",
"unresolved_questions": [
"How broadly do existing execution-test categories construct or assert block-level and receipt-level logs-bloom encodings?",
"Does every test in the target fork expose these fields to an additional invariant, and do any pre-fork vectors require re-derivation?"
]
}
},
"hegota:7709:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 17,
"recomputed_tier": "medium",
"recomputed_total": 17,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "`BLOCKHASH` opcode gas costs now follow state access rules, accounting for cold/warm scenarios. This affects existing `BLOCKHASH` test cases but not other pre-existing scenarios. Given 1 point consider the impact should be limited.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Only `BLOCKHASH` being impacted and now accounting for state access cost.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas accounting changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanisms are introduced.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Most of the `BLOCKHASH` related tests need refactoring, but impact is limited (27 places under tests/ folder, excluding `tests/benchmark`)",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing tests that call `BLOCKHASH` for an in-window ancestor must now assert a storage-read entry for `HISTORY_STORAGE_ADDRESS` in the BAL and the post-call warmth of that slot—even though these tests aren't about access lists. This narrowly affects only tests that already touch `BLOCKHASH`",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No interface changes",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Add storage-access tracking to `BLOCKHASH`. Follow `Op.SLOAD(key_warm=...)` and integrate into fork gas map.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism added",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple interacting edge cases: (1) window boundary (`arg == block.number`, `> block.number`, `== 2**256-1`, `-1`, `-256 vs -257`), (2) young chain (`block.number < 256`, cold charge on unwritten slots), (3) modulus mismatch (`8191` vs `256`, `EIP-2935` slot warming), (4) cold/warm state (`EIP-2930` access lists, `SLOAD` collisions), (5) revert rollback and OOG at cold-charge boundary, (6) fork-transition window.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block syncing changes",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No engine API changes",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contracts added",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The history contract's code and state are not directly modified, but there's an indirect effect: `BLOCKHASH` warms the contract's storage slot, making subsequent `SLOAD` calls within `get()` warm. Conversely, `SLOAD` on that slot warms it for `BLOCKHASH`.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode added",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "BLOCKHASH now has state-access side effects: slot warming and state-access records, observable independently of gas. At activation, in-window lookups return 0 if < 256 blocks since EIP-2935 fork (vs pre-fork real hash).",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No added precompile",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No modified precompile",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No encoding rules changes",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction types added",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No changes to transaction validity mechanisms",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header fields are introduced.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state modifications, internal variables or similar are modified at the fork activation block.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new work reduces to an `SLOAD`, which is already benchmarked and already priced; the EIP strictly raises the cost of the operation, so worst-case throughput moves in the safe direction.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "106x cost increase might break `BLOCKHASH` callers. Interacts with EIP-2929/BAL. \"MAY\" clause risks consensus divergence if warming/recording skipped. Needs targeted review and fuzz testing on state-access accounting.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "(1) does the lookup add HISTORY_STORAGE_ADDRESS to accessed_addresses? (2) whether the account appears in the BAL account list when only a slot is read through the opcode, and whether the access is recorded when the opcode OOGs on the cold charge.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "4 interacting EIPs: EIP-2935 (hard dependency, ring-buffer state), EIP-2929 (cold/warm foundation), EIP-2930 (access list pre-warming), EIP-7928 (BAL recording). Test vectors need redesign.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7709,
"fork": "hegota",
"id": "hegota:7709:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7709.yaml",
"sha256": "3feafcaf1e70499aa50e2a309c32f34b86eaac6e2eea818e8956588cba8d6520"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "e75fc8b75e247b545d095a86de2ab939270c20e4",
"content_sha256": "5a2a2b3c930846de46187e053a0f5f748633a73fc0fceee56518a045cf53056d",
"git_blob_sha": "f9b1c0170d522549e86f70a5dcb5af5da821208c",
"immutable_url": "https://github.com/ethspecs/pm/blob/e75fc8b75e247b545d095a86de2ab939270c20e4/complexity_assessments/EIPs/EIP-7709.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7709.md",
"pull_request": {
"draft": false,
"number": 120,
"title": "Add EIP-7709 complexity assessment",
"updated_at": "2026-08-24T12:41:48Z",
"url": "https://github.com/ethspecs/pm/pull/120"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 17,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "Read BLOCKHASH from Storage and Update Cost",
"under_specification": null
},
"hegota:7709:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification > Gas costs; § Test Cases bullets 2-4",
"source": "eip.md",
"summary": "In-window BLOCKHASH keeps its own charge and additionally applies cold or warm SLOAD cost for the corresponding history slot."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The gas accounting of an existing opcode is updated by composing it with the existing SLOAD schedule; no separate new gas-accounting mechanism is defined.",
"score": 1,
"uncertainty_note": "The amounts are inherited from the active fork, while their exact ordering is handled separately under state-access ordering and under-specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Specification, resolve_blockhash pseudocode and following SLOAD-effects list",
"source": "eip.md",
"summary": "A single existing opcode now conditionally performs an SLOAD-like access, charge, warm-up, and state-access record after its window checks."
},
{
"locator": "§ Test Cases bullets 1-4",
"source": "eip.md",
"summary": "Out-of-window calls have no storage effects, while in-window calls distinguish cold and warm slots and retain the BLOCKHASH charge."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The state-access and gas-charge path changes for the one BLOCKHASH opcode, which matches the single-opcode anchor.",
"score": 1,
"uncertainty_note": "The text does not explicitly order the original BLOCKHASH charge, the SLOAD charge, access recording, and warming at every insufficient-gas boundary.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification > Gas costs",
"source": "eip.md",
"summary": "The only added charge is an execution-gas SLOAD charge for BLOCKHASH; no blob gas rule is specified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting changes are introduced.",
"score": 0,
"uncertainty_note": "The package contains no blob-gas surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification, SLOAD-effects list; § Gas costs",
"source": "eip.md",
"summary": "The proposal applies a storage read and its execution-gas effects, not a state write or state-gas charge."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-writing gas rate, charging site, budget, reservoir, or spill rule changes.",
"score": 0,
"uncertainty_note": "Slot warming is an access effect and is not a state-gas write charge.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification > Gas costs; § Test Cases",
"source": "eip.md",
"summary": "The specified gas effects are charges only; no refund is introduced."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM gas-refund mechanism is added or changed.",
"score": 0,
"uncertainty_note": "No refund behavior appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Backwards Compatibility; § Test Cases bullets 1-4",
"source": "eip.md",
"summary": "Existing in-window BLOCKHASH use receives a significant gas increase and new cold/warm and state-access effects, but return-value semantics stay unchanged."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor, opcode-specific subset of existing tests must be updated for gas and access effects; the change does not rework diverse transaction or block categories.",
"score": 1,
"uncertainty_note": "The package does not enumerate the pre-existing test corpus.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Specification, SLOAD-effects list; § Test Cases bullets 1-3",
"source": "eip.md",
"summary": "Tests executing an in-window BLOCKHASH must additionally observe the matching slot's warming and any active-fork state-access recording."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A narrow category of otherwise pre-existing BLOCKHASH tests gains additional access-state assertions, rather than every test in the fork gaining an invariant.",
"score": 1,
"uncertainty_note": "Which test formats expose active-fork access records is not specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification parameter table; § Activation",
"source": "eip.md",
"summary": "The proposal supplies a normal fork timestamp parameter and execution rule but defines no transition-tool field or interface mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification is required by the text.",
"score": 0,
"uncertainty_note": "FORK_TIMESTAMP is TBD, but that is a parameter gap rather than a new interface field.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Test Cases",
"source": "eip.md",
"summary": "The listed cases use ordinary opcode result, gas, repeated-access, and direct-call observations."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing EVM gas, storage-access, and fork test primitives appear sufficient.",
"score": 0,
"uncertainty_note": "No test-framework inventory is part of the package, so this rests on the specified case shapes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification",
"source": "eip.md",
"summary": "The mechanism reads an already-stored block hash by slot and introduces no cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No new or modified cryptography mechanism is specified.",
"score": 0,
"uncertainty_note": "Block hashes are data being retrieved, not a new cryptographic mechanism here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification, resolve_blockhash pseudocode; § Activation; § Test Cases",
"source": "eip.md",
"summary": "Cases span both edges of the 256-block serve window, a distinct 8191-slot modulus, cold versus warm repetition, zero-effect out-of-window execution, and activation only after enough EIP-2935 history or at genesis."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact, and the in/out-of-window boundary requires an elevated matrix across gas sufficiency, cold/warm status, repeated access, access recording, and activation history.",
"score": 3,
"uncertainty_note": "The package specifies representative cases but not the complete cross-product or the handling of an incorrectly spaced activation.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification",
"source": "eip.md",
"summary": "The change is opcode execution against state and introduces no block RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-RLP validation or sync mechanism is introduced.",
"score": 0,
"uncertainty_note": "The proposal's history prerequisite does not itself modify block encoding validation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification",
"source": "eip.md",
"summary": "No Engine API field, endpoint, or communication mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The proposal has no Engine API surface.",
"score": 0,
"uncertainty_note": "None within the sealed package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires field; § Specification; § Activation",
"source": "eip.md",
"summary": "EIP-7709 assumes and reads the EIP-2935 history contract rather than introducing one."
},
{
"locator": "§ Specification > Block hash history contract; § Deployment",
"source": "supporting/eip-2935.md",
"summary": "The stateful history contract and its deployment are defined by EIP-2935."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contract is added by this proposal.",
"score": 0,
"uncertainty_note": "Dependency on an existing system contract is scored under cross-EIP interactions.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Specification, resolution alternatives and SLOAD-effects list; § Reading from the System contract",
"source": "eip.md",
"summary": "No history-contract code or persistent state is changed, but BLOCKHASH now reads its slot and must warm that slot even if a client resolves by another method."
},
{
"locator": "§ Gas costs",
"source": "supporting/eip-2935.md",
"summary": "Normal calls to the history contract pay account and slot warming costs because its block-start system update does not warm them."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The pre-existing history contract has a minor indirect gas-context effect: a prior BLOCKHASH can warm its storage slot for later access, without code or state modification.",
"score": 1,
"uncertainty_note": "Clients may avoid executing the contract, but must reproduce the same warming effect.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification",
"source": "eip.md",
"summary": "The proposal updates the existing BLOCKHASH opcode at byte 0x40."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification, resolve_blockhash pseudocode and SLOAD-effects list",
"source": "eip.md",
"summary": "Existing BLOCKHASH gains non-gas behavioral effects: state-slot access, slot warming, and active-fork state-access recording for in-window arguments."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Although its returned value is preserved, at least one pre-existing opcode's observable behavior beyond gas is modified, invoking the rubric's binary score of 3.",
"score": 3,
"uncertainty_note": "The precise ordering of those effects is unresolved but their introduction is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification",
"source": "eip.md",
"summary": "The scope is an opcode and an existing system-contract storage slot, not a precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification",
"source": "eip.md",
"summary": "No precompile logic or gas schedule is mentioned or changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification",
"source": "eip.md",
"summary": "The proposal changes opcode resolution and state effects without transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other transaction/block/interface encoding change is introduced.",
"score": 0,
"uncertainty_note": "The modulo slot mapping is not an interface encoding change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Abstract; § Specification",
"source": "eip.md",
"summary": "No transaction envelope or transaction type is introduced."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification > Gas costs; § Backwards Compatibility",
"source": "eip.md",
"summary": "Execution may consume more gas and break gas-sensitive use cases, but no transaction validity rule or intrinsic-gas calculation is changed."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The change affects runtime opcode execution only, not transaction validity mechanisms.",
"score": 0,
"uncertainty_note": "Runtime out-of-gas behavior is distinct from intrinsic validity under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification",
"source": "eip.md",
"summary": "Existing block number, timestamp, and hash information is consumed; no field is added."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "§ Specification, fork_block definition; § Activation",
"source": "eip.md",
"summary": "Opcode logic switches at the timestamp and assumes EIP-2935 history is already available; no one-time state or internal-variable modification is prescribed at activation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "This is an ordinary rule switch, not a fork-block state mutation mechanism.",
"score": 0,
"uncertainty_note": "The timestamp and deployment spacing remain TBD, but the EIP prescribes no activation-block mutation.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Motivation; § Specification, resolution alternatives and SLOAD-effects list; § Rationale",
"source": "eip.md",
"summary": "Existing BLOCKHASH execution is coupled to state-access machinery and witness recording, while clients may implement resolution by direct SLOAD, system call, or maintained history."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The cost can be microbenchmarked, but end-to-end effects depend on state/cache and access-recording behavior; impact is limited to in-window BLOCKHASH execution.",
"score": 2,
"uncertainty_note": "The permitted implementation choices leave concrete performance costs client-dependent.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Backwards Compatibility; § Security Considerations",
"source": "eip.md",
"summary": "The proposal significantly increases in-window BLOCKHASH gas and refers security considerations to EIP-2935 rather than supplying an independent analysis."
},
{
"locator": "§ Specification, SLOAD-effects list",
"source": "eip.md",
"summary": "Correctness spans opcode execution, gas, warming, state access recording, and history-contract storage."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches a limited set of existing consensus-critical components and slightly alters resource and access-state assumptions, warranting targeted review and fuzzing.",
"score": 2,
"uncertainty_note": "The snapshot gives no EIP-7709-specific threat analysis beyond inheriting EIP-2935 considerations.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "§ Specification, resolve_blockhash pseudocode and SLOAD-effects list; § Test Cases bullets 1-4",
"source": "eip.md",
"summary": "The text requires the original BLOCKHASH charge plus SLOAD charging, warming, and access recording, but does not explicitly sequence those actions at insufficient-gas boundaries."
},
{
"locator": "Front matter status; § Specification parameter table; § Activation",
"source": "eip.md",
"summary": "The proposal is Draft, leaves FORK_TIMESTAMP TBD, and assumes either at least 256 blocks of prior EIP-2935 activation or activation at genesis."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A previously non-state-accessing opcode gains consensus-observable access records and warming. The unspecified charge/access sequence can produce different observable results at gas boundaries and therefore requires cross-client agreement and re-baselining.",
"score": 3,
"uncertainty_note": "Referring to the entire active-fork SLOAD semantics may settle part of the sequence, but the placement of the existing BLOCKHASH charge relative to that sequence is not explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires field; § Activation; § Backwards Compatibility; § Test Cases bullets 5-6",
"source": "eip.md",
"summary": "EIP-7709 requires EIP-2935, relies on its populated ring buffer, and needs direct contract access to retain normal execution effects."
},
{
"locator": "§ Specification > Gas costs",
"source": "supporting/eip-2935.md",
"summary": "The history system update does not warm its account or slots under EIP-2929, so later access follows the normal cold/warm rules that EIP-7709 imports."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2935,
2929
],
"rationale": "Coordinated testing is required with EIP-2935 and its EIP-2929 cold/warm behavior, plus whatever active-fork access-recording rule applies; the dependency is strong but localized.",
"score": 2,
"uncertainty_note": "The active-fork state-access-recording dependency is not identified by EIP number in the package.",
"under_specified": true,
"unidentified_interactions": [
"Active-fork state-access-recording rules inherited for the corresponding SLOAD."
]
}
],
"eip": 7709,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7709:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"“Entire semantics and effects of SLOAD” is clear about the required effect set but not about its placement relative to the pre-existing BLOCKHASH charge.",
"Three resolution strategies are allowed, so clients must demonstrate identical gas, warming, and access-recording behavior without a single prescribed execution path.",
"The activation section states prerequisites as assumptions and does not normatively define behavior for a deployment that violates them."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "ed806dda2e43f8c887e52a89988dbe7354a8dfd305587955e09b6254994716ea",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7709.md",
"git_blob_sha": "0c7c4c625efdd4e0a8932f38d005c39463284cf1",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7709.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7709.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7709.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7709.yaml",
"sha256": "a0e76be8f159c1c898b2519c60db424aae838fc6602826ef5a2b6fbd51de8bbd"
},
"supporting_documents": [
"supporting/eip-2935.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 20,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the draft EIP-7709 snapshot. The proposal changes the existing BLOCKHASH opcode so that in-window lookups have the gas, warming, and state-access-recording effects of an SLOAD from the EIP-2935 history contract's ring-buffer slot, while preserving the existing return-value window.",
"tier": "medium",
"title": "Read BLOCKHASH from Storage and Update Cost",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 21,
"minimum": 18
},
"present": true,
"summary": "The draft fixes the result, slot, and required SLOAD-like effects, but does not explicitly specify their ordering relative to the original BLOCKHASH charge at insufficient-gas boundaries. It also leaves the fork timestamp and concrete satisfaction of the EIP-2935 history-age prerequisite unresolved.",
"unresolved_questions": [
"In what exact order are the base BLOCKHASH charge, cold/warm determination, SLOAD charge, state-access recording, and slot warming applied when available gas ends between steps?",
"What FORK_TIMESTAMP will be used, and how is the requirement for at least 256 prior EIP-2935 blocks (or genesis activation) guaranteed for each activated network?",
"If that activation-age assumption is violated, is the value read from the unfilled history slot authoritative, or must clients apply another behavior?"
]
}
},
"hegota:7805:human:r1": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 15,
"recomputed_tier": "medium",
"recomputed_total": 15,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "\"After all of the transactions in the payload have been executed, we check whether any transaction from ILs, that is not already present in the payload, could be validly included...\". Additionally, there is further validation for each Transaction in the IL",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "new field, new mechanism for tx validation, new error",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Many boundary/edge cases to test, but standard checks",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "2 new engine apis included, 1 modified",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Need to validate each transation in the IL, but limited in scope and straightforward checks",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Each transaction not in block requires state access, adding latency to block validation time",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Consensus-critical validations, new economic incentives",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Interacts with AA",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7805,
"fork": "hegota",
"id": "hegota:7805:human:r1",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7805.yaml",
"sha256": "0a29be7f88aefa8b7e3d69e0080f4c2eb15cabdcb48796837eeecfc4082859dc"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"known_source_defects": [
"The checklist contains Engine API encoding changes but the template has no dedicated definition for that row."
],
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"branch": "main",
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"committed_at": "2026-01-12T14:16:48Z",
"content_sha256": "ed018ce5a7fc1f7d3439207f74e4964d1144c687cf881b17f307fa0dd20b2a3a",
"git_blob_sha": "b452b3c506b855dc72f2731ab8d832df71fe5b54",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/complexity_assessments/EIPs/EIP-7805.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7805.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 15,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "medium",
"title": "Fork-choice enforced Inclusion Lists (FOCIL)",
"under_specification": null
},
"hegota:7805:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer, introductory paragraph and steps 1-3",
"source": "eip.md",
"summary": "The new check consumes the already-computed remaining block gas and a transaction gas value; it does not define a new gas charge, schedule, or accounting mechanism."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Comparing a listed transaction's gas against gas_left is a payload satisfaction condition, not a change to EVM gas accounting.",
"score": 0,
"uncertainty_note": "No gas-accounting rule change is described in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer, introductory paragraph and step 3",
"source": "eip.md",
"summary": "Nonce and balance are checked against state S after all payload transactions execute; the proposal does not move an access or gas charge within any opcode."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The new observation is block-level and post-transaction, outside opcode execution, so opcode state-access ordering is unchanged.",
"score": 0,
"uncertainty_note": "None material for this anchor within the execution-layer scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer, steps 1-3",
"source": "eip.md",
"summary": "The satisfaction algorithm describes transaction presence, remaining execution gas, nonce, and balance only; it specifies no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None material in the sealed execution-layer specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer, introductory paragraph and step 3",
"source": "eip.md",
"summary": "The EL reads post-payload nonce and balance to classify missing IL transactions; no state-write gas cost, state-gas budget, reservoir, or spill rule is specified."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal does not change state gas accounting.",
"score": 0,
"uncertainty_note": "None material in the sealed execution-layer specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The complete EL algorithm adds an inclusion-satisfaction check and does not introduce refund creation, accrual, or settlement behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed execution-layer specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Engine API Changes",
"source": "eip.md",
"summary": "Existing forkchoiceUpdated and newPayload flows are modified to carry IL data, and newPayload can return INCLUSION_LIST_UNSATISFIED."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor, focused subset of pre-existing Engine API and payload-processing tests must be adapted for the added IL input and response path; the EIP does not rework broad EVM or transaction-test categories.",
"score": 1,
"uncertainty_note": "Exact endpoint schemas and versioning are absent, so the precise count of pre-existing API vectors needing edits is not determined.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer; Specification > Engine API Changes",
"source": "eip.md",
"summary": "The new status is conditional on supplied IL transactions and the EIP states that an unsatisfied block remains valid; it does not prescribe a new assertion for unrelated tests."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests not exercising FOCIL do not gain a specified additional invariant or universally required assertion.",
"score": 0,
"uncertainty_note": "The missing concrete API schema leaves test plumbing open, but no new unrelated-test assertion is stated.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer; Specification > Engine API Changes",
"source": "eip.md",
"summary": "Evaluating the new post-state rule requires IL transactions that are not block contents, and produces a distinct INCLUSION_LIST_UNSATISFIED outcome."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Transition testing requires a new side-input mechanism for the IL set and a distinguishable satisfaction result, which is more than a single ordinary field even though the exact tool schema is not specified.",
"score": 2,
"uncertainty_note": "The EIP specifies Engine API behavior, not the transition-tool mapping, so the exact number and shape of tool fields remain open.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Engine API Changes",
"source": "eip.md",
"summary": "Tests must provide IL transactions to modified calls, exercise a new getInclusionList endpoint, and recognize INCLUSION_LIST_UNSATISFIED."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing endpoint and result helpers need minor extension for the new IL input and status, but the package does not establish a reusable permanent framework-level primitive.",
"score": 1,
"uncertainty_note": "No test-framework design is included, so a dedicated expectation type is possible but not demonstrably required by this snapshot.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer; Specification > Consensus Layer > New containers",
"source": "eip.md",
"summary": "The execution check uses presence, gas, nonce, and balance; the BLS signature appears only in the consensus-layer SignedInclusionList."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified on the execution-layer surface; consensus-layer signature work is excluded from scoring.",
"score": 0,
"uncertainty_note": "None material after applying the required layer boundary.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer, steps 1-3",
"source": "eip.md",
"summary": "Each listed transaction branches on payload presence, the gas-left boundary, and post-state nonce and balance validity."
},
{
"locator": "Security Considerations > Payload Construction",
"source": "eip.md",
"summary": "Multiple IL transactions can become valid through nonce and balance state changes, producing a naive O(n^2) rechecking pattern and requiring live EOA tracking, including balance changes caused by AA transactions."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "There are multiple boundary-prone mechanisms, and interacting transaction sequences create an elevated combinatorial case set across ordering, validity, state changes, and available gas.",
"score": 3,
"uncertainty_note": "Precise validity and list-normalization rules are missing, so the full case matrix is not yet enumerable.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer; Specification > Engine API Changes",
"source": "eip.md",
"summary": "FOCIL supplies IL data across Engine API calls and expressly leaves an unsatisfied execution block valid; it adds no execution-block RLP field or RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-RLP validation change requiring execution-client sync testing is introduced. Consensus gossip and availability behavior are outside scope.",
"score": 0,
"uncertainty_note": "The supporting EIP's consensus syncing design is not a syncing rule of EIP-7805 and is not attributed to this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Engine API Changes",
"source": "eip.md",
"summary": "The proposal adds engine_getInclusionListV1, extends engine_forkchoiceUpdated payloadAttributes with an IL, and adds IL transactions plus an INCLUSION_LIST_UNSATISFIED result to engine_newPayload."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "A new endpoint is introduced alongside changes to multiple existing Engine API endpoints, exactly matching the score-3 anchor.",
"score": 3,
"uncertainty_note": "Concrete types and versioned method signatures are under-specified, but the number and classes of API changes are explicit enough to fix this score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The EL feature is specified as a post-payload client check over IL transactions, with no contract address, code, state, or system call."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contract is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The post-payload check does not invoke, modify, or assign behavior to any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or indirect system-contract modification is specified.",
"score": 0,
"uncertainty_note": "None material in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The proposed logic runs after payload transactions have executed and defines no EVM instruction or opcode number."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None material in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The new rule is a post-execution payload check and does not change the result or behavior of any existing opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified.",
"score": 0,
"uncertainty_note": "None material in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution specification adds client-side satisfaction logic and no precompile address, input contract, output, or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None material in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "No existing precompile logic or gas accounting is referenced by the post-payload inclusion-list check."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None material in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > IL Building",
"source": "eip.md",
"summary": "The byte cap is measured over RLP-encoded transactions, reusing the transaction encoding; no transaction, execution-block, or Engine API encoding is changed."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Carrying existing encoded transactions in an IL does not itself introduce an RLP/SSZ encoding change on the execution-layer surface.",
"score": 0,
"uncertainty_note": "The new Engine API schemas are absent, but no switch of interface encoding is proposed.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer; Specification > IL Building",
"source": "eip.md",
"summary": "Inclusion lists contain transactions selected from the public mempool and the EL checks those transactions; no new transaction envelope is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None material in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer, step 3",
"source": "eip.md",
"summary": "The new payload-satisfaction decision queries whether a missing existing transaction passes nonce and balance checks against post-state S; it does not redefine those transactions' validity or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The EIP uses transaction-validity information as an input to a new inclusion condition but does not modify transaction-type validity rules.",
"score": 0,
"uncertainty_note": "The exact subset of validity checks is under-specified; that gap is recorded under cross-client consensus rather than treated as a validity-rule change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Engine API Changes",
"source": "eip.md",
"summary": "ILs are supplied through payloadAttributes and a newPayload parameter; the EIP specifies no new execution payload, block, or block-header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No execution-layer block or header field is introduced.",
"score": 0,
"uncertainty_note": "Consensus-layer IL containers are excluded and are not execution block or header fields.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal requires a hard fork for consensus-layer validation changes but specifies no activation-block state mutation or modification of an existing internal variable on the EL."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Fork scheduling alone is not a new fork-activation mechanism.",
"score": 0,
"uncertainty_note": "No special execution-layer activation transition is described.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Payload Construction",
"source": "eip.md",
"summary": "Naive payload construction can require O(n^2) validity checks; the proposed mitigation tracks nonce and balance changes of involved EOAs throughout payload construction, including AA-induced balance changes."
},
{
"locator": "Roles And Participants > Builder",
"source": "eip.md",
"summary": "The builder must update its payload with collected IL transactions inside a time-sensitive slot workflow, and the exact timing is deferred pending tests and benchmarks."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The mechanism interacts continuously with existing payload construction and state changes, cannot be validated solely as an isolated fixed-cost check, and has an explicit quadratic naive path plus latency sensitivity.",
"score": 3,
"uncertainty_note": "The optimized algorithm, maximum effective transaction count, and timing budget are not normatively fixed in the package.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer; Specification > Engine API Changes",
"source": "eip.md",
"summary": "Post-state transaction classification produces a new Engine API status that the CL uses to decide whether the otherwise-valid block satisfies ILs."
},
{
"locator": "Security Considerations > Consensus Liveness; Security Considerations > Payload Construction",
"source": "eip.md",
"summary": "Canonical block production depends on builders receiving and satisfying ILs in time, while correct construction must account for interdependent nonce and balance changes among listed transactions."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "On the EL surface, correctness spans critical payload execution, state-dependent hypothetical validity, builder construction, and the Engine-API result consumed by fork choice; errors can impair liveness or the intended censorship-resistance guarantee and warrant extensive review and fuzzing.",
"score": 3,
"uncertainty_note": "Consensus gossip, committee behavior, and attester logic are excluded; the score rests on the EL classification and construction boundary alone.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer, steps 1-3",
"source": "eip.md",
"summary": "The consensus-relevant INCLUSION_LIST_UNSATISFIED decision is stated in terms of T.gas, T.origin, presence, nonce, and balance without fully defining transaction identity, ordering/duplication handling, or exact validity and affordability calculations across transaction forms."
},
{
"locator": "Specification > Engine API Changes",
"source": "eip.md",
"summary": "The endpoint changes are listed without normative request/response types, IL aggregation rules, or versioned signatures for the modified methods."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A newly observable cross-layer status directly controls attestation, while constructible cases affecting that status lack a unique EL answer. Clients must agree on these details before authoritative vectors can be baselined.",
"score": 3,
"uncertainty_note": "This score reflects the sealed Draft text only; prohibited implementation, devnet, discussion, and later-revision information was not consulted.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Core Properties > Same-slot",
"source": "eip.md",
"summary": "FOCIL explicitly contrasts its same-slot constraints with the forward inclusion-list design of EIP-7547 and calls the removed one-slot delay an improvement."
},
{
"locator": "Specification > Execution layer",
"source": "supporting/eip-7547.md",
"summary": "EIP-7547 defines overlapping inclusion-list retrieval, forkchoiceUpdated, newPayload, and EL validation surfaces, but with summary and exclusion objects rather than EIP-7805's committee IL input."
},
{
"locator": "Security Considerations > Payload Construction",
"source": "eip.md",
"summary": "The optimization must notice EOA balance changes caused by Account Abstraction transactions, an interaction named without an EIP number."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7547
],
"rationale": "The identified EIP-7547 relationship is a limited alternative-design interaction requiring compatibility and vector consideration, not a stated dependency. The package also identifies a bounded AA behavior interaction without assigning it an EIP number.",
"score": 1,
"uncertainty_note": "The proposal does not state coexistence, replacement, or dependency semantics for EIP-7547, so the interaction is kept at the limited score.",
"under_specified": false,
"unidentified_interactions": [
"Account Abstraction transactions that change tracked EOA balances during payload construction"
]
}
],
"eip": 7805,
"evaluation_date": "2026-09-11",
"fork": "hegota",
"id": "hegota:7805:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The text says an unsatisfied block is valid while requiring the EL to return a special status to the CL, leaving the exact Engine API validity/status model unspecified.",
"The phrase nonce and balance checks does not fully specify the hypothetical append-validity predicate for all existing transaction forms.",
"Consensus-layer SignedInclusionList containers and gossip rules provide context but are intentionally excluded from this execution-only score."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "81096dd37cab86a5007e50d9357f0230f2f3dcbdf4df16b9afd44da6c74098a1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7805.md",
"git_blob_sha": "0a3955d9e8772b7666f560402b2d81ae032a3d06",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7805.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7805.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7805.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/extensions/sfi-cfi-2026-08-26/outputs/assessments/eip-7805.yaml",
"sha256": "d944ac078c13ca84227aa23754dddd2824036f4d44480325b7934d45cad3151f"
},
"supporting_documents": [
"supporting/eip-7547.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 20,
"scored": true,
"snapshot_id": "hegota-sfi-cfi-2026-08-26-ac450a4",
"snapshot_status": "SFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the draft FOCIL proposal at the sealed snapshot. The scored surface is the post-payload inclusion-list satisfaction check, its payload-construction implications, and its Engine API inputs, endpoint, and status. Committee selection, beacon-state containers, consensus fork choice, validator timing, CL gossip/RPC, and BLS signatures are cross-layer context and are not scored as execution-layer complexity.",
"tier": "medium",
"title": "Fork-choice enforced Inclusion Lists (FOCIL)",
"under_specification": {
"affected_criteria": [
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 23,
"minimum": 14
},
"present": true,
"summary": "Material EL details are unresolved: the exact hypothetical transaction validity/affordability predicate, transaction identity and list normalization, and normative Engine API schemas are not defined. The builder timing and optimization are also deferred. These gaps chiefly affect the new side-input/result tooling, boundary matrix, performance/security validation, and cross-client baselining; they are not reused to inflate unrelated gas, opcode, encoding, or transaction-type anchors.",
"unresolved_questions": [
"What exact transaction-validity and balance-affordability rules, including fee components and transaction forms, define validly includable at post-state S?",
"How are transaction presence, duplicates, ordering, and aggregation across multiple committee ILs normalized before the EL check?",
"What are the normative request and response schemas and versioned signatures for getInclusionList, forkchoiceUpdated, and newPayload?",
"Is gas_left tested independently for each missing transaction, and what exact transaction gas value is denoted by T.gas?",
"Which payload-construction algorithm and timing budget are normative rather than implementation guidance?"
]
}
},
"hegota:7807:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas amounts",
"source": "eip.md",
"summary": "Gas values are regrouped into SSZ containers, with no rule changing how execution gas is charged."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes representation of gas amounts and fees, not EVM gas accounting.",
"score": 0,
"uncertainty_note": "No gas-charging rule is specified anywhere in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block hash computation",
"source": "eip.md",
"summary": "The only opcode-specific change is the value of the block hash used by BLOCKHASH; no state access or gas-charge ordering is defined."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state-access path or relative gas-charge position changes.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas amounts",
"source": "eip.md",
"summary": "Blob gas and blob fees are fields in SSZ containers, but their accounting rules are not modified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Encoding blob-related values does not introduce or update blob gas accounting.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas amounts",
"source": "eip.md",
"summary": "The specified gas structures contain regular and blob dimensions only and define no state-gas cost, budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas accounting mechanism or charging site is introduced.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas amounts",
"source": "eip.md",
"summary": "The proposal only represents gas amounts and fees and specifies no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM gas-refund mechanism is introduced or changed.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block",
"source": "eip.md",
"summary": "New blocks use a normalized SSZ payload and an SSZ-summary header while retaining typed-envelope and selected RLP-encoded elements."
},
{
"locator": "Specification > Execution block hash computation",
"source": "eip.md",
"summary": "The SSZ hash-tree root becomes the block hash for opcode, JSON-RPC, devp2p, and consensus references."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing block, header, receipt-root, block-hash, RPC, opcode, and synchronization expectations span diverse test categories and must be reworked for the new representation and hash, meeting the major-subset anchor.",
"score": 3,
"uncertainty_note": "Exact test inventories are unavailable by package policy, but the specification explicitly changes all listed execution-block contexts.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution block; Execution block hash computation; JSON-RPC",
"source": "eip.md",
"summary": "Existing block representation, hash, and logsBloom expectations change, but the EIP does not require tests unrelated to it to assert an additional product."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The proposal changes existing expected values and encodings rather than adding a separate assertion to otherwise unchanged tests.",
"score": 0,
"uncertainty_note": "Test-suite assertion structure is not present in the package; this score distinguishes changed expectations from the anchor's additional-invariant requirement.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification (all subsections)",
"source": "eip.md",
"summary": "The specification defines execution-block, hashing, consensus-payload, and JSON-RPC behavior but no transition-tool field or transport contract."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification can be assigned from the sealed proposal text.",
"score": 0,
"uncertainty_note": "A transition tool may need representation support, but its required fields and mechanism are materially unspecified and cannot be inferred.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution block",
"source": "eip.md",
"summary": "Tests must construct and hash a ProgressiveContainer payload, ProgressiveLists, ProgressiveByteLists, and an SSZ-summary header."
},
{
"locator": "Specification > ProgressiveContainer(active_fields) > Merkleization",
"source": "supporting/eip-7495.md",
"summary": "Progressive containers add active-field-aware progressive Merkleization."
},
{
"locator": "Specification > Progressive Merkle tree; ProgressiveList[type] and ProgressiveBitlist",
"source": "supporting/eip-7916.md",
"summary": "Progressive list types add a recursive Merkle-tree shape and length-mixed roots."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Generic construction, serialization, summary, and hash-tree-root support for the new permanent block format and its reusable progressive SSZ types is a framework-level primitive, not merely EIP-specific test code.",
"score": 3,
"uncertainty_note": "The package excludes the actual test framework, so the amount of pre-existing SSZ support cannot be observed.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The new SSZ block hash is SHA256-based and shares a namespace with existing keccak256-based block hashes."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "A well-known hash mechanism is newly used for execution block identity, fitting the single well-known cryptographic-mechanism anchor.",
"score": 1,
"uncertainty_note": "The package asserts no significant collision risk but does not remove the need for cross-context hash-vector testing.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block",
"source": "eip.md",
"summary": "The payload combines fixed and variable fields, multiple progressive lists, retained typed/RLP elements, and a derived summary header."
},
{
"locator": "Specification > Progressive Merkle tree",
"source": "supporting/eip-7916.md",
"summary": "Progressive roots change shape at recursively increasing chunk thresholds and define a distinct empty-list root."
},
{
"locator": "Specification > ProgressiveContainer(active_fields)",
"source": "supporting/eip-7495.md",
"summary": "Progressive containers constrain active-field configurations and mix those bits into their Merkle roots."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Empty and non-empty lists, recursive subtree growth thresholds, variable-offset serialization, active-field roots, summary-versus-payload equivalence, and mixed nested encodings create multiple boundaries; progressive-tree thresholds require an elevated vector set.",
"score": 3,
"uncertainty_note": "Context-specific size bounds for unbounded progressive lists are not supplied by EIP-7807.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Specification > Execution block; Execution block hash computation",
"source": "eip.md",
"summary": "The block and its per-block tries migrate from RLP/Merkle-Patricia representation to SSZ, and devp2p uses the new block hash."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Replacing the block-level RLP/header validation path with SSZ and a new hash is a single complex synchronization-validation migration.",
"score": 2,
"uncertainty_note": "The devp2p message encoding, validation sequence, fork negotiation, and invalid-block rules are not specified, preventing a supported score for multiple mechanisms.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Rationale > Engine API",
"source": "eip.md",
"summary": "The shared SSZ hash lets the Engine API drop the redundant block_hash field and adopt binary ForkDigest-context encoding."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The package identifies one Engine API field modification (removing block_hash) and a transport-encoding change, but no new endpoint or set of new fields; the closest supported interface-impact anchor is 1.",
"score": 1,
"uncertainty_note": "This behavior is stated in rationale rather than a normative endpoint/version specification, so the exact Engine API change is materially under-specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (all subsections)",
"source": "eip.md",
"summary": "The proposal defines block data, hashing, and external representations and introduces no system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract or system action is added.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The identified compatibility impact concerns contracts that parse the previous header format, not changes to any system contract's code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Consumer incompatibility does not directly or indirectly modify a pre-existing system contract.",
"score": 0,
"uncertainty_note": "No particular system contract is identified in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block hash computation",
"source": "eip.md",
"summary": "The proposal refers to the existing BLOCKHASH opcode and defines no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block hash computation",
"source": "eip.md",
"summary": "BLOCKHASH uses ExecutionPayload.hash_tree_root() as the execution block hash."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The observable result of the pre-existing BLOCKHASH opcode changes from the prior block-hash computation, meeting the rubric's binary score-3 condition.",
"score": 3,
"uncertainty_note": "Historical and fork-boundary BLOCKHASH cases are not explicitly resolved.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (all subsections)",
"source": "eip.md",
"summary": "No precompile address, input, output, behavior, or gas schedule is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (all subsections)",
"source": "eip.md",
"summary": "No existing precompile logic or gas accounting is mentioned or changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile is modified.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Execution block",
"source": "eip.md",
"summary": "Execution blocks and per-block tries migrate from Merkle-Patricia/RLP to normalized SSZ, with an SSZ-summary header and selected RLP elements retained inside the payload."
},
{
"locator": "Motivation > Optimized engine API; Rationale > Engine API",
"source": "eip.md",
"summary": "The proposal targets binary SSZ encoding for Engine API exchange in place of textual JSON."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "A block-level RLP-to-SSZ encoding migration directly satisfies the rubric's binary score-3 condition.",
"score": 3,
"uncertainty_note": "The exact Engine API wire specification is absent, but the normative execution-block encoding change alone determines this score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block",
"source": "eip.md",
"summary": "Transaction elements retain their existing EIP-2718 typed-envelope representation."
},
{
"locator": "Specification > Transactions",
"source": "supporting/eip-2718.md",
"summary": "EIP-2718 defines the existing typed or legacy transaction envelope carried unchanged by EIP-7807."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The block container changes, but no new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Execution block",
"source": "eip.md",
"summary": "Individual transactions are unaffected and retain their existing typed-envelope representation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic gas calculation changes.",
"score": 0,
"uncertainty_note": "None material within the package scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block",
"source": "eip.md",
"summary": "A new 18-field SSZ ExecutionPayload includes block_access_list and slot_number and derives the header as an SSZ summary."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The proposal introduces a new block/header field representation and explicitly includes fields in the new execution block, satisfying the binary score-3 anchor.",
"score": 3,
"uncertainty_note": "The package does not distinguish which individual field semantics originate in dependencies versus this migration; the new SSZ block/header definition is explicit regardless.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification (all subsections)",
"source": "eip.md",
"summary": "The proposal defines the post-activation representation but specifies no state mutation or modification of an internal variable at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "A format transition alone does not meet this anchor's state/internal-variable modification condition.",
"score": 0,
"uncertainty_note": "The activation point and handling of pre-fork history are not specified, but no activation-block mutation can be inferred.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation > Optimized engine API; Execution block hash computation",
"source": "eip.md",
"summary": "The EIP claims roughly 50 percent smaller Engine API exchange and significantly improved encoding/parsing while changing block hashing across opcode, RPC, devp2p, and consensus references."
},
{
"locator": "Motivation; Rationale > Why a recursive structure?",
"source": "supporting/eip-7916.md",
"summary": "Progressive Merkleization changes hash work and tree growth as list sizes increase."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Whole-block serialization, parsing, Merkleization, networking, and hash lookup behavior interact with existing block-processing paths and cannot be fully benchmark-isolated; the proposal itself makes substantial performance claims.",
"score": 3,
"uncertainty_note": "No context-specific maximum list sizes or benchmark parameters are supplied.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution block hash computation; Security Considerations",
"source": "eip.md",
"summary": "A SHA256-based SSZ root becomes block identity across BLOCKHASH, JSON-RPC, devp2p, and consensus references while sharing a namespace with keccak256 hashes."
},
{
"locator": "Specification > Execution block",
"source": "eip.md",
"summary": "Receipt and request commitments and the derived header depend on correct SSZ list/container roots while selected inner elements retain other encodings."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect encoding, Merkleization, or hash-context handling can split consensus across block validation and cross-layer references and can expose inconsistent results through critical opcode, networking, and API surfaces, requiring broad review and fuzzing.",
"score": 3,
"uncertainty_note": "The EIP dismisses significant cross-algorithm collision risk, but implementation-consistency risk across the listed critical components remains.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution block hash computation; Rationale > Engine API",
"source": "eip.md",
"summary": "The hash is mandated in all contexts, but fork-boundary/history behavior and the proposed binary Engine API version, framing, and endpoint mappings are not defined."
},
{
"locator": "Specification > Execution block; JSON-RPC",
"source": "eip.md",
"summary": "The payload and logsBloom response are defined, while devp2p wire encoding and complete JSON-RPC field derivation are absent."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Constructible fork-boundary, historical BLOCKHASH, synchronization, and interface cases need localized cross-client agreement before vectors can be baselined; the gaps are material but do not establish the anchor-3 condition of newly observable previously unspecified execution behavior.",
"score": 2,
"uncertainty_note": "Implementations, devnets, discussions, and post-snapshot clarifications are prohibited, so only the Draft text's visible gaps are assessed.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Specification > Execution block; Rationale > Forward compatibility",
"source": "eip.md",
"summary": "EIP-7807 requires EIPs 7495, 7773, and 7916 and retains EIP-2718 typed transaction and receipt envelopes inside the SSZ block."
},
{
"locator": "Specification > ProgressiveContainer(active_fields)",
"source": "supporting/eip-7495.md",
"summary": "EIP-7495 supplies the forward-compatible container and depends on EIP-7916 progressive Merkleization."
},
{
"locator": "Specification",
"source": "supporting/eip-7773.md",
"summary": "EIP-7773 is the required hard-fork meta proposal and identifies EIP-7843 SLOTNUM and EIP-7928 Block-Level Access Lists, whose outputs correspond to slot_number and block_access_list fields in EIP-7807."
},
{
"locator": "Specification > ProgressiveList[type] and ProgressiveBitlist",
"source": "supporting/eip-7916.md",
"summary": "EIP-7916 supplies the unbounded progressive list and byte-list types used repeatedly by the new payload."
}
],
"exceptional_score_justification": "Six identified EIPs each contribute a coordinated test axis: the score-3 strong interdependency anchor plus the mandatory +1 for three additional EIPs beyond the first three yields 4.",
"id": "cross_eip_interactions",
"interacting_eips": [
2718,
7495,
7773,
7916,
7843,
7928
],
"rationale": "The block format has strong coordinated dependencies on three required EIPs and embeds EIP-2718 envelopes, EIP-7843 slot data, and EIP-7928 block access lists, so cross-EIP vectors must cover container/list roots, fork composition, and preserved or produced field bytes. Six identified interactions produce base score 3 plus the rubric's first +1 for three interacting EIPs beyond the first three.",
"score": 4,
"uncertainty_note": "Several package-grounded structures have no EIP number in the sealed evidence and are recorded separately rather than guessed.",
"under_specified": false,
"unidentified_interactions": [
"Consensus ExecutionPayload and ExecutionPayloadEnvelope replacement at the execution-layer boundary",
"Consensus ExecutionRequests root equivalence"
]
}
],
"eip": 7807,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7807:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The statement that the Engine API can drop block_hash and adopt binary encoding is rationale, not a normative endpoint specification; score 1 reflects one identified field modification while keeping confidence low.",
"The execution payload includes block_access_list and slot_number, but the package does not allocate their semantic origin among EIP-7807 and its fork/dependency context; the block/header-field anchor scores the explicit resulting definition.",
"Transactions and receipts retain EIP-2718 envelopes while withdrawals and the block access list retain RLP, so SSZ validation must preserve and commit to nested bytes without treating those inner objects as migrated SSZ values."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "bc279f875c28fa1b1ee26a21312533dac2d3cca2a8f682725e2485b5bd275562",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7807.md",
"git_blob_sha": "3f2dc991ac65153842fd9b894c04ba590d58d3e6",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7807.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7807.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7807.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7807.yaml",
"sha256": "44920c361615bba8a912be7cd35f7797bc78ef10a6c55b16b322cc87316bd85a"
},
"supporting_documents": [
"supporting/eip-2718.md",
"supporting/eip-7495.md",
"supporting/eip-7773.md",
"supporting/eip-7916.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 34,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Prospective complexity assessment of EIP-7807 at the sealed Hegota snapshot, limited to its execution-layer effects: SSZ execution-block and header representation, block-hash computation, retained nested encodings, execution interfaces, JSON-RPC, devp2p, and the BLOCKHASH opcode. Consensus-layer-only behavior is excluded except where the EIP defines an execution-layer boundary.",
"tier": "high",
"title": "SSZ execution blocks",
"under_specification": {
"affected_criteria": [
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 39,
"minimum": 32
},
"present": true,
"summary": "The Draft fixes the core SSZ payload and hash rule but does not normatively define transition-tool representation, Engine API endpoint/version/framing changes, devp2p wire and invalid-input handling, context-specific bounds for progressive lists, or historical and activation-boundary hash behavior. These are recorded as distinct gaps and are not used to inflate unrelated anchors.",
"unresolved_questions": [
"What exact transition-tool fields or encoding carry the new payload, header summary, receipts, and resulting block hash?",
"Which Engine API methods and versions use binary ForkDigest-context encoding, how are messages framed, and is block_hash removal normative?",
"How are SSZ blocks negotiated, encoded, and rejected in devp2p synchronization across the activation boundary?",
"What execution-layer bounds apply to each ProgressiveList and ProgressiveByteList before allocation, decoding, and Merkleization?",
"How must BLOCKHASH and external block-hash lookups treat pre-activation blocks when executed or queried after activation?"
]
}
},
"hegota:7819:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 22,
"recomputed_tier": "medium",
"recomputed_total": 22,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "`SETDELEGATE` introduces a dynamic schedule composed of cold/warm access and an account-write charge. It does not change another opcode's schedule, but exact and repeat-write cases need dedicated accounting tests.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "A new state-accessing opcode must check state-independent access gas before reading the location, then calculate and charge state-dependent costs. BAL output changes at those boundaries.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas behavior changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The prototype adds a new `NEW_ACCOUNT`/`AUTH_BASE` state-gas charging site and a journaled designation refill on clear or frame rollback. It reuses the reservoir and spill mechanism rather than changing it.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The current EIP text specifies a simple existence-based global refund. The Amsterdam prototype replaces it with EIP-8037 state-gas accounting, so the normative disposition of that refund still needs agreement.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Three fixture executions of one existing constant-gas opcode-sweep function flipped because `SETDELEGATE` is dynamic; the sweep now excludes it. No other existing test was reworked or parked.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to EIP-7819 gain no new assertion.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The transition-tool request and result interfaces are unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The framework gains one opcode definition with dynamic metadata and a reusable address-derivation helper; existing fillers and expectation types suffice.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Address derivation reuses existing Keccak-256 and introduces no new cryptographic primitive.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Testing spans target truncation/padding, salt/address order, zero-target clearing, nonce zero/nonzero, exact and malformed collision code, cold/warm access, fresh/existing leaves and designations, exact/one-short gas, static mode, call contexts, and success/revert interactions. Several axes combine in elevated gas/state matrices.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Block encoding and RLP validation are unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or endpoint changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system contract is modified directly or indirectly.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "One complex opcode is added: it has dynamic access, write, and state-gas costs and mutates another account while returning its derived address.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode's result changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity and intrinsic gas rules are unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is added.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation only makes the opcode valid; it does not mutate state at the fork block.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The opcode adds account reads and code/nonce writes, but it can be benchmarked in isolation and does not alter existing benchmark behavior.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The opcode creates and upgrades immediately effective EIP-7702 designations and interacts with collision, nonce, delegation-resolution, and `SELFDESTRUCT` invariants. These interactions are limited but warrant targeted review and fuzzing.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The current EIP leaves localized consensus questions around post-EIP-8037 gas, operand order, prefix-only versus exact designation collisions, and the state point used for trie existence. The prototype records assumptions, but clients need agreement before production vectors are baselined.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Coordinated cases cover EIP-7702 designation semantics, EIP-2929 warming, EIP-7523 nonce persistence, EIP-3541 collision reachability, EIP-6780 `SELFDESTRUCT`, EIP-7928 BAL observability, EIP-8037 state gas, and EIP-8038 access/write pricing. The base interaction level is 2; eight interacting EIPs add 1 for the five beyond the first three.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7819,
"fork": "hegota",
"id": "hegota:7819:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7819.yaml",
"sha256": "46b88a993f3e2da5fe41394340f9ed434292539bf2963322ebd98cd4d2b73f49"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "664f62e0e0ac2db5426796bd76ffca420e491bf0",
"content_sha256": "7202736865a996ab705d8ecaecaed8b635aeba4422add03ea74bb18e48e5646b",
"git_blob_sha": "a34cb992641aba1c4db15cd39466d50ad056d359",
"immutable_url": "https://github.com/ethspecs/pm/blob/664f62e0e0ac2db5426796bd76ffca420e491bf0/complexity_assessments/EIPs/EIP-7819.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-7819.md",
"pull_request": {
"draft": true,
"number": 128,
"title": "Add EIP-7819 complexity assessment",
"updated_at": "2026-08-24T13:25:20Z",
"url": "https://github.com/ethspecs/pm/pull/128"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 22,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "medium",
"title": "SETDELEGATE instruction",
"under_specification": null
},
"hegota:7819:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior, steps 1 and 7; Parameters",
"source": "eip.md",
"summary": "SETDELEGATE deducts EMPTY_ACCOUNT_COST, conditionally adds EMPTY_ACCOUNT_COST minus BASE_COST to the refund counter, and defines both constants numerically."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The opcode introduces its own gas-accounting rule, including a state-dependent refund, while leaving the gas rules of existing opcodes unchanged. This is a new mechanism confined to the new operation.",
"score": 2,
"uncertainty_note": "The treatment of repeated writes to an account that begins absent is not fully determined by the phrase \"already exists in the trie,\" but the presence and general scope of the new gas rule are clear.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior, steps 1-10",
"source": "eip.md",
"summary": "The new operation charges gas, checks static mode, derives and warms a location, reads its code and existence, writes code and nonce, and returns the location in a specified sequence."
},
{
"locator": "Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 makes the timing and rollback behavior of additions to accessed_addresses transaction-observable."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "SETDELEGATE is a new state-accessing operation whose charge, warm-access, read, refund, and write positions require boundary testing. It does not change the ordering rule for an existing class of opcodes, so score 2 rather than 3 applies.",
"score": 2,
"uncertainty_note": "The word \"Halt\" does not say whether the warm-address update at step 5 is retained or rolled back when step 6 rejects the location, increasing the uncertainty at that particular boundary.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior; Parameters",
"source": "eip.md",
"summary": "The proposal defines only execution gas constants and opcode behavior; it introduces no blob-gas rule or blob-related field."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob-gas ambiguity is visible in the sealed proposal.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Behavior, steps 7-9; Parameters",
"source": "eip.md",
"summary": "The operation writes code and may increment a nonce, but the only charging terms specified are EMPTY_ACCOUNT_COST, BASE_COST, and an execution-gas refund; no state-gas charge is defined."
},
{
"locator": "Mempool > Validation Trace Rules",
"source": "supporting/eip-8141.md",
"summary": "The snapshot's frame-transaction proposal explicitly permits SETDELEGATE to install code during a deploy frame, where separate state budgets exist."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "As written, EIP-7819 neither adjusts an existing state-gas rate nor defines a new state-gas charging site. The apparent omission for its durable code and nonce writes is recorded as material under-specification rather than repaired by assigning an unstated mechanism.",
"score": 0,
"uncertainty_note": "It is unresolved whether SETDELEGATE should receive a new state-gas charge for code and account-state growth in the Hegota setting; such a resolution could move this row to score 2.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior, step 7",
"source": "eip.md",
"summary": "The opcode conditionally adds 12,500 gas to the transaction-global refund counter when the derived location already exists in the trie."
},
{
"locator": "Security Considerations > Multiple Delegation Changes Within a Single Transaction",
"source": "eip.md",
"summary": "The same derived location may be updated, cleared, and reset multiple times within one transaction."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "This is a simple conditional refund, but it shares the global refund counter with existing refund behavior and has state-dependent interactions under repeated writes, so targeted mixed-refund and cap testing is required.",
"score": 2,
"uncertainty_note": "The proposal does not define whether \"already exists in the trie\" refers to original or current transaction state, so the refund outcome for repeated creation, clearing, and rollback is uncertain.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "A new instruction is assigned to opcode byte 0xf6."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing fork/opcode-validity coverage for byte 0xf6 must distinguish the activation boundary and the new behavior. That is a minor, localized subset of pre-existing tests; the broader SETDELEGATE matrix consists of new tests.",
"score": 1,
"uncertainty_note": "The package contains no implementation test inventory, so the exact number of pre-existing vectors requiring rework cannot be established.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "Code, nonce, access-list, refund, and stack effects arise only when the new SETDELEGATE instruction executes."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The proposal does not require tests unrelated to SETDELEGATE to assert a new output or invariant.",
"score": 0,
"uncertainty_note": "The package has no test-suite mapping, but the specification states no universal per-test artifact or assertion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "All new inputs and outputs are EVM stack operands and ordinary account state; no transition-tool request or response field is introduced."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Existing transition-tool interface shapes are sufficient as specified.",
"score": 0,
"uncertainty_note": "The package does not prescribe tooling, but no new block or transaction input is needed to execute the opcode.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "Observable results are conventional stack, gas/refund, accessed-address, code, nonce, call, and revert effects."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The EIP does not demonstrate a need for a new expectation type, modifier, or permanent framework abstraction beyond composing existing EVM state and execution checks.",
"score": 0,
"uncertainty_note": "No test-framework description is included in the package, so sufficiency of existing helpers cannot be confirmed from an implementation inventory.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior, step 4; Rationale > Address Derivation",
"source": "eip.md",
"summary": "Address derivation applies keccak256 to a domain-separated preimage; no new hash, signature, proof system, or cryptographic verification is defined."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Using an existing hash in a new derivation is not a new cryptographic mechanism.",
"score": 0,
"uncertainty_note": "No cryptographic mechanism is under-specified in this proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "Cases include static mode, stack-size failures, 20-byte target padding and truncation, empty versus delegated versus other code, trie existence, zero-target clearing, nonce zero versus nonzero, immediate calls, and refund behavior."
},
{
"locator": "Security Considerations > Delegator Chaining; Multiple Delegation Changes Within a Single Transaction",
"source": "eip.md",
"summary": "Delegation targets can chain or loop, and one location can hold and execute multiple code values, including cleared code, within a transaction."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms combine, and repeated same-location changes multiply success, failure, revert, refund, warm/cold, target, and call-timing cases. At least this repeated-update mechanism requires an elevated test matrix.",
"score": 3,
"uncertainty_note": "Ambiguous halt and trie-existence semantics make some expected boundary results unresolved, but clearly do not reduce the number of boundaries.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal adds an EVM opcode and no block RLP field or block-validation encoding rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism requiring sync testing is introduced.",
"score": 0,
"uncertainty_note": "No syncing-surface ambiguity is present in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification contains no Engine API endpoint, field, or communication change."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API surface is introduced or modified.",
"score": 0,
"uncertainty_note": "No Engine API uncertainty is present in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal adds opcode 0xf6 and does not deploy or designate a system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "No system-contract addition is described.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "State changes target an address derived from the executing contract and salt; no pre-existing system contract is named or modified."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal has no direct or specified indirect system-contract modification.",
"score": 0,
"uncertainty_note": "No system-contract interaction is identified in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Specification > Behavior",
"source": "eip.md",
"summary": "One new opcode, SETDELEGATE at 0xf6, takes salt and target, derives and returns an address, performs state reads and writes, and has a state-dependent refund."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "A single opcode is added, but its state-dependent net gas, multi-step stack behavior, state access, code/nonce mutation, and failure paths make it a complex opcode under the rubric.",
"score": 2,
"uncertainty_note": "The classification remains complex regardless of the unresolved details of halt and refund semantics.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior, text following step 10",
"source": "eip.md",
"summary": "Created indicators inherit EIP-7702 behavior for CODESIZE, CODECOPY, precompile targets, and chaining; the proposal does not specify a changed result for an existing opcode."
},
{
"locator": "Specification > Delegation indicator",
"source": "supporting/eip-7702.md",
"summary": "Existing delegation-indicator execution and code-reading behavior is already defined for CALL-family, transaction execution, CODESIZE, and CODECOPY operations."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "SETDELEGATE adds another way to create an already-defined delegation object; it does not itself modify the behavior of a pre-existing opcode.",
"score": 0,
"uncertainty_note": "Existing opcode suites need new SETDELEGATE-created fixtures, but the sealed text says their delegated-object semantics are identical rather than changed.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "Precompiles are mentioned only as possible delegation targets through inherited EIP-7702 behavior; none is added."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "No precompile-addition ambiguity is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior, text following step 10",
"source": "eip.md",
"summary": "The proposal adopts EIP-7702's already-defined behavior when a delegation targets a precompile and specifies no precompile logic or gas change."
},
{
"locator": "Specification > Delegation indicator > Precompiles",
"source": "supporting/eip-7702.md",
"summary": "A precompile address reached through a delegation is treated as empty code, so no precompile logic executes."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Existing precompile behavior and gas schedules are not modified.",
"score": 0,
"uncertainty_note": "The inherited edge case requires tests but is specified by EIP-7702.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Inputs are opcode stack values and state code bytes; no transaction, block, receipt, or interface encoding changes are defined."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface-level encoding change is introduced.",
"score": 0,
"uncertainty_note": "No encoding uncertainty is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal introduces an instruction, not a transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "No transaction-type ambiguity is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "All checks occur during EVM execution of SETDELEGATE; the proposal defines no transaction validity or intrinsic-gas rule."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Runtime opcode failure conditions do not modify transaction-envelope validity.",
"score": 0,
"uncertainty_note": "The meaning of runtime \"Halt\" is uncertain but does not create a static validity rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No block body or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The proposal introduces no new block or header field.",
"score": 0,
"uncertainty_note": "No header-surface uncertainty is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The text specifies opcode behavior but no activation-block state mutation, migration, or change to an existing internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Enabling a new opcode requires no special activation mechanism as written.",
"score": 0,
"uncertainty_note": "The proposal contains no activation procedure to assess beyond opcode availability.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Behavior",
"source": "eip.md",
"summary": "Each execution hashes a fixed-format preimage, accesses an account, and may update its code and nonce."
},
{
"locator": "Motivation > Scalability",
"source": "eip.md",
"summary": "The intended performance effects are lower state growth and cheaper call redirection through 23-byte delegation indicators."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new opcode's hashing, state access, fixed-size code write, and delegated call path require benchmarking, but the operation is bounded and can be benchmarked in isolation; the delegated execution mechanism already comes from EIP-7702.",
"score": 1,
"uncertainty_note": "The package supplies motivations but no benchmark results for SETDELEGATE, so the size of its runtime and state-backend impact is not established.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Delegator Upgrades and Deletion; Delegator Chaining",
"source": "eip.md",
"summary": "Factories control upgrades and deletion, while targets can be delegation chains or loops with unexpected behavior."
},
{
"locator": "Security Considerations > Multiple Delegation Changes Within a Single Transaction",
"source": "eip.md",
"summary": "A single address can have multiple code values installed, removed, and executed during one transaction."
},
{
"locator": "Specification > Behavior, steps 5-9",
"source": "eip.md",
"summary": "The opcode couples access-list state, code eligibility, refunds, code-hash replacement, account nonce mutation, and immediate execution semantics."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Contract-controlled, immediately effective code replacement interacts with multiple critical mechanisms: account code and nonce state, delegation execution, access journaling, refunds, upgrade authorization, and deletion assumptions. Mistakes can change which code executes or who controls an account, requiring extensive security review and fuzzing across components.",
"score": 3,
"uncertainty_note": "Factory-level authorization policy is intentionally outside the protocol, so application guarantees vary, but the protocol integration risks are explicit and broad.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Behavior, steps 2 and 6",
"source": "eip.md",
"summary": "Static-mode execution and a disallowed destination are said only to \"Halt,\" without defining exceptional-halt, revert, success, return value, or journaling consequences."
},
{
"locator": "Specification > Behavior, step 7; Security Considerations > Multiple Delegation Changes Within a Single Transaction",
"source": "eip.md",
"summary": "A refund depends on whether the location \"already exists in the trie,\" yet the same location may be changed repeatedly in one transaction and the temporal reference for existence is not defined."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need agreement on localized, constructible cases: the exact failure semantics and rollback boundary of both halt sites, and original-versus-current existence for refunds. Most other opcode behavior is specified, so the gaps are material but localized rather than a wholesale redefinition.",
"score": 2,
"uncertainty_note": "The separate omission of state-gas charging is recorded under under_specification and is not used again to inflate this row.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Specification > Behavior, steps 5 and 8-9",
"source": "eip.md",
"summary": "EIP-7819 requires EIP-7702, uses EIP-2929 accessed_addresses, creates the same delegation indicators as EIP-7702, and uses nonce initialization to satisfy EIP-7523 account non-emptiness."
},
{
"locator": "Specification > Delegation indicator",
"source": "supporting/eip-7702.md",
"summary": "Delegation indicators use EIP-3541's 0xef marker and alter code execution and code-reading dispatch for several operations."
},
{
"locator": "Mempool > Validation Trace Rules > Banned Opcodes",
"source": "supporting/eip-8141.md",
"summary": "EIP-8141 explicitly recognizes SETDELEGATE in the first deploy frame and requires the deployment to install code at the frame transaction sender."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2929,
3541,
7523,
7702,
8141
],
"rationale": "SETDELEGATE strongly extends EIP-7702's shared delegation object, must coordinate access warming with EIP-2929 and non-empty-account preservation with EIP-7523, relies on the EIP-3541 marker convention, and is explicitly integrated into EIP-8141 deployment and mempool validation. These multiple interdependencies require coordinated cross-EIP execution, failure, introspection, and deployment tests.",
"score": 3,
"uncertainty_note": "ERC-721, ERC-1155, ERC-1167, ERC-1967, and ERC-4337 are cited as use cases or comparisons, not counted as protocol-test interactions requiring their own coordinated vectors.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7819,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7819:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"Step 6 accepts any non-empty code that starts with 0xEF0100, while the text elsewhere describes delegation indicators as exactly 23 bytes; the intended eligibility of a longer prefixed code value is not expressly reconciled.",
"The recommendation that only the creator should be able to destroy a delegation is not a protocol check; authority is instead determined entirely by possession of the same executing address and salt path."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "431cc6e41caf5e4ada27a3a94e55af40cc9bec7434502c05e87fbeabdade346e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7819.md",
"git_blob_sha": "1af30928edc05bac3aa54fc7f011eb2449b06b63",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7819.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7819.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7819.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7819.yaml",
"sha256": "aff55796c7070d7d92a46e5716feabd6a41073841b9b852ce9a1314aca13faf4"
},
"supporting_documents": [
"supporting/eip-721.md",
"supporting/eip-1155.md",
"supporting/eip-1167.md",
"supporting/eip-1967.md",
"supporting/eip-2929.md",
"supporting/eip-4337.md",
"supporting/eip-7523.md",
"supporting/eip-7702.md",
"supporting/eip-8141.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 21,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Assessment of the execution-layer complexity of draft EIP-7819 as sealed in the Hegota PFI snapshot, limited to its new SETDELEGATE opcode and the package-grounded interactions of the delegation accounts it creates.",
"tier": "medium",
"title": "SETDELEGATE instruction",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"state_gas_accounting_changes",
"new_evm_gas_refund",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 23,
"minimum": 20
},
"present": true,
"summary": "The draft leaves material execution-layer outcomes unresolved: it does not define state-gas charging for durable code and nonce writes, uses the unqualified result \"Halt\" at two consensus-visible failure sites, and does not anchor trie existence to original or current transaction state for its refund.",
"unresolved_questions": [
"Does SETDELEGATE charge state gas for the 23-byte code write, account creation, or nonce initialization, and at which exact charge points?",
"Does \"Halt\" in steps 2 and 6 mean an exceptional halt, a revert, or a successful stop, and which gas, accessed-address, and state effects survive?",
"For step 7, is \"already exists in the trie\" evaluated against transaction original state or the current journaled state after earlier SETDELEGATE executions and rollbacks?"
]
}
},
"hegota:7851:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters; Specification > SETSELFDELEGATE",
"source": "eip.md",
"summary": "SETSELFDELEGATE has a fixed cost of 9500 for every execution attempt."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Adding a fixed charge for one opcode updates the existing opcode gas-cost mechanism; it does not introduce a separate or dynamic execution-gas model.",
"score": 1,
"uncertainty_note": "The amount is explicit, but charge ordering relative to checks and state access is unspecified and scored in the state-access-ordering row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETSELFDELEGATE, execution rules 1-3",
"source": "eip.md",
"summary": "The new opcode charges 9500, checks the authority's raw code, and may replace that code, without explicitly ordering the charge and accesses."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "A new state-accessing and state-writing operation is introduced whose position in the gas/access order must be settled, matching score 2.",
"score": 2,
"uncertainty_note": "Ordering relative to the static check, raw-code read, no-op branches, and code write is not specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete specification covers delegation execution, one opcode, and ECDSA-related validation; it defines no blob behavior or cost."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob surface appears in the snapshot.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > SETSELFDELEGATE; Rationale, final paragraph",
"source": "eip.md",
"summary": "Success writes one 23-byte code value, while the only defined charge is the fixed 9500 SETSELFDELEGATE execution-gas cost."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No StateGasCosts rate, state-gas charging site, block budget, reservoir, or spill rule is defined, so the documented proposal scores zero.",
"score": 0,
"uncertainty_note": "Integration of this new code-writing path with a separate state-gas regime is materially unspecified and recorded separately.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETSELFDELEGATE; Rationale, final paragraph",
"source": "eip.md",
"summary": "Each attempt pays a fixed charge and either writes code or returns zero; no refund action is defined."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "EIP-7702's refund is not extended or invoked by EIP-7851's opcode.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Delegated Code Execution; Specification > Validation; Backwards Compatibility",
"source": "eip.md",
"summary": "Clients must recognize a second delegation prefix across execution and reject or skip ECDSA actions for it; enabled delegations remain unchanged."
},
{
"locator": "Specification > Set code transaction > Behavior > Delegation indicator",
"source": "supporting/eip-7702.md",
"summary": "Existing delegation behavior spans CALL, CALLCODE, DELEGATECALL, STATICCALL, transaction destinations, CODESIZE, and CODECOPY."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing delegation and transaction-validation suites need coordinated updates across several paths, but only for the delegated-EOA category.",
"score": 2,
"uncertainty_note": "The package has no test inventory, so the exact number of pre-existing vectors needing rework is unavailable.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > SETSELFDELEGATE; Backwards Compatibility",
"source": "eip.md",
"summary": "New outputs apply to EIP-7851 cases, while existing enabled delegations are explicitly unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The snapshot defines feature-specific expectations but no new assertion that unrelated pre-existing tests must carry.",
"score": 0,
"uncertainty_note": "No packaged test-format material identifies a mechanically added invariant outside EIP-7851 cases.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes execution and transaction validation but defines no transition-tool request or response field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or mechanism is specified.",
"score": 0,
"uncertainty_note": "Implementing the rules in a transition tool is distinct from changing its external interface.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > SETSELFDELEGATE; Specification > Validation",
"source": "eip.md",
"summary": "Observable outcomes are stack success, exceptional halt, account code, revert behavior, and transaction validity."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "These are expressible with ordinary EVM state and transaction expectations; no new framework abstraction is required by the snapshot.",
"score": 0,
"uncertainty_note": "No test-framework implementation is packaged, so this is limited to the specified observable outcomes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Validation; Rationale, final paragraph",
"source": "eip.md",
"summary": "The feature disables existing ECDSA authority, and the new opcode performs no signature verification or authority recovery."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic primitive or functionality is introduced or modified; an already recovered identity is gated by raw account code.",
"score": 0,
"uncertainty_note": "ECDSA is context, but its algorithm is unchanged.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETSELFDELEGATE",
"source": "eip.md",
"summary": "Cases include low-160-bit truncation, zero-address no-op, exact 23-byte raw-code and two-prefix checks, static halt, revert, and success/no-change."
},
{
"locator": "Specification > SETSELFDELEGATE, frame-local paragraphs; Specification > Validation",
"source": "eip.md",
"summary": "Loaded frames keep old code while re-entrant calls load the new target; current-state sender and authorization checks add further boundaries."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact, with an elevated matrix across frame locality, re-entrancy, revert, static execution, and raw-code shape.",
"score": 3,
"uncertainty_note": "Gas/access ordering at boundary gas amounts is unspecified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No block RLP field or block RLP validation rule is defined."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No RLP validation mechanism for block syncing is introduced.",
"score": 0,
"uncertainty_note": "Transaction validity affects block acceptance but is not block-RLP validation under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No Engine API field, endpoint, or communication mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The Engine API is unchanged.",
"score": 0,
"uncertainty_note": "No Engine API surface appears in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The feature consists of an account-code prefix, an opcode, and validation rules; it deploys no protocol-designated contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "No system-contract surface appears in the snapshot.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal names no pre-existing system contract or its state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or indirect system-contract modification is specified.",
"score": 0,
"uncertainty_note": "No system-contract dependency is identified by the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters; Specification > SETSELFDELEGATE",
"source": "eip.md",
"summary": "One opcode is added with one stack input, one output, no data portion, and a constant 9500 gas cost."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Under this anchor it is one simple opcode: small stack mechanics and constant gas, despite its stateful semantic importance.",
"score": 1,
"uncertainty_note": "The opcode byte is TBD, but the count and stack/gas shape are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Delegated Code Execution",
"source": "eip.md",
"summary": "Clients must treat new 0xef0101 identically to existing 0xef0100 for delegated code execution."
},
{
"locator": "Specification > Set code transaction > Behavior > Delegation indicator",
"source": "supporting/eip-7702.md",
"summary": "Delegation affects CALL, CALLCODE, DELEGATECALL, STATICCALL, transaction destinations, CODESIZE, and CODECOPY."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Existing code-executing opcodes obtain a different result for the new recognized prefix; any such non-gas behavior modification mandates score 3.",
"score": 3,
"uncertainty_note": "Existing-operation vectors must be repeated for the second prefix.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Security Considerations, final paragraph",
"source": "eip.md",
"summary": "EIP-7851 defines no precompile and leaves ecrecover behavior to companion EIP-8151."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced by this proposal.",
"score": 0,
"uncertainty_note": "The companion is an interaction, not part of EIP-7851's mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, final paragraph",
"source": "eip.md",
"summary": "EIP-7851 does not make direct ECDSA checks reject disabled authorities and points ecrecover behavior to EIP-8151."
},
{
"locator": "Abstract; Specification > Modified ecRecover Behavior",
"source": "supporting/eip-8151.md",
"summary": "The companion, rather than EIP-7851, modifies ecrecover."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "EIP-7851 modifies no existing precompile logic or gas schedule.",
"score": 0,
"uncertainty_note": "Coordination with EIP-8151 is scored under Cross-EIP interactions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The new 0xef0101 sequence is raw account code; no transaction, block, or interface encoding is changed."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "An account-code marker is outside this anchor's RLP/SSZ scope.",
"score": 0,
"uncertainty_note": "EIP-7702 transaction structures are reused without re-encoding.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Validation",
"source": "eip.md",
"summary": "Rules apply to EIP-7702 authorization processing and existing ECDSA-authenticated transactions; no transaction type is added."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The proposal introduces no new transaction type.",
"score": 0,
"uncertainty_note": "It depends on the existing EIP-7702 transaction mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Validation",
"source": "eip.md",
"summary": "EIP-7702 authorizations from exact 0xef0101 code are invalid and skipped; an ECDSA transaction from such a sender is invalid for blocks and pools."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing authorization and sender-validity paths gain a state-dependent branch requiring updated vectors, but no redesigned testing infrastructure.",
"score": 2,
"uncertainty_note": "ECDSA-authenticated transaction is not enumerated by transaction type, so coverage across existing families must be derived.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The block and header schemas are unchanged.",
"score": 0,
"uncertainty_note": "No block/header surface appears in the snapshot.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "Rules apply when new prefixes or actions are encountered; no activation-block state rewrite or internal-variable modification exists."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state or internal variable is modified specifically at activation.",
"score": 0,
"uncertainty_note": "Existing enabled delegations are explicitly unchanged.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, third paragraph",
"source": "eip.md",
"summary": "Delegated-code lookup can reuse an existing path, while transaction pools may require an additional sender account-code read."
},
{
"locator": "Specification > SETSELFDELEGATE",
"source": "eip.md",
"summary": "Success reads and replaces the authority's raw code."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The opcode is locally benchmarkable, but sender-state reads and delegation resolution affect existing pool and execution paths with stated limited impact.",
"score": 2,
"uncertainty_note": "No benchmarks are packaged; the EIP characterizes execution-load change as small.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, first two paragraphs",
"source": "eip.md",
"summary": "Disabling ECDSA is irreversible, the original key cannot restore it, and wallets are told to treat SETSELFDELEGATE as their highest privilege."
},
{
"locator": "Specification > SETSELFDELEGATE; Specification > Validation",
"source": "eip.md",
"summary": "The mechanism changes account code, re-entrant targets, authorization processing, sender validity, and pool admission."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A defect can permanently affect user control and funds while interacting with multiple critical execution and authorization components, requiring extensive review and fuzzing.",
"score": 3,
"uncertainty_note": "Application-level ECDSA verification remains outside the protection.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter; Specification > Parameters",
"source": "eip.md",
"summary": "The snapshot is Draft and leaves SETSELFDELEGATE_OPCODE as TBD."
},
{
"locator": "Specification > SETSELFDELEGATE",
"source": "eip.md",
"summary": "The opcode charges per attempt and performs raw-code checks and writes, without stating their exact consensus-visible gas/access order."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need agreement on localized details, especially the opcode byte and within-opcode order, before complete vectors can be baselined.",
"score": 2,
"uncertainty_note": "Implementation, devnet, and discussion evidence is absent from the sealed package and was not consulted.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Abstract; Specification > Validation",
"source": "eip.md",
"summary": "EIP-7851 requires and extends EIP-7702 delegation execution and authorization processing."
},
{
"locator": "Security Considerations, final paragraph",
"source": "eip.md",
"summary": "EIP-8151 is the companion for ecrecover behavior."
},
{
"locator": "Specification > Account Code Check",
"source": "supporting/eip-8151.md",
"summary": "EIP-8151 permits only empty or 0xef0100 raw code, distinguishing the disabled 0xef0101 prefix."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7702,
8151
],
"rationale": "EIP-7851 depends on and modifies EIP-7702 and needs coordinated ecrecover consideration with EIP-8151; the interactions are important but limited.",
"score": 2,
"uncertainty_note": "Only the two explicit numbered interactions are counted; indirect dependencies of supporting documents are excluded.",
"under_specified": false,
"unidentified_interactions": [
"Existing ECDSA-authenticated transaction families covered by sender-code validity"
]
}
],
"eip": 7851,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7851:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"Special consideration: gas-boundary vectors multiply across static/non-static context, enabled/disabled prefix, valid/invalid code shape, zero/nonzero delegate, success/no-op, revert/success, and re-entrant/direct execution.",
"ECDSA-authenticated transaction is not enumerated by type, so the breadth of sender-code validity coverage must be explicit in tests."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "92d7407d2d3c6e2d797e4f6f91e74aa0eba18f1ba82daa9b90cb981eab61de66",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7851.md",
"git_blob_sha": "a659ac72d473505f6a106e7bfa0364df16808cf1",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7851.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7851.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7851.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7851.yaml",
"sha256": "6934ca2deb9d2580c0981bc9877c2389b518193ec46d218b4c50442acd78f357"
},
"supporting_documents": [
"supporting/eip-7702.md",
"supporting/eip-8151.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 23,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the Draft EIP-7851 snapshot. The proposal extends EIP-7702 with an ECDSA-disabled delegation prefix, adds the state-writing SETSELFDELEGATE opcode, changes delegated-code recognition, and adds authorization, transaction-validity, and transaction-pool rules.",
"tier": "high",
"title": "Code-Controlled EOA Delegation",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"state_gas_accounting_changes",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 25,
"minimum": 23
},
"present": true,
"summary": "The opcode byte is TBD. The snapshot also does not fully specify charge and state-access ordering or how its new code write participates in a separate block-level state-gas regime. These omissions are confined to the directly affected anchors.",
"unresolved_questions": [
"What byte value is assigned to SETSELFDELEGATE_OPCODE?",
"At what point is fixed gas charged relative to stack validation, the static check, raw-code access, no-op decisions, and the write?",
"Does a successful code replacement incur distinct state gas or affect a state-gas budget or spill path, and if so how?",
"Which opcode accesses or writes are recordable in the block-level access list at each gas boundary?"
]
}
},
"hegota:7862:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"The checklist total and the Final Assessment total differ.",
"The published total 26 differs from the cell sum 19; the cells are the primary record, so the cell sum is used."
],
"published_tier": "high",
"published_total": 26,
"recomputed_tier": "medium",
"recomputed_total": 19,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No gas accounting is touched.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's state-access site or gas-charge ordering changes. Although the EIP leverages the BAL to parallelize root computation, it neither modifies what the BAL records nor when it records it.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No interaction with blob gas.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas charging site, rate or budget is touched.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No refund mechanism.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Every blockchain-test fixture for this fork must be regenerated: each header now commits a different state_root, causing all block hashes and downstream parent_hash values to be re-derived. Two categories require redesign: (1) tests with deliberately wrong state_root now expect rejection on the successor rather than the offending block, and (2) state_test-derived fixtures no longer commit their post-state root anywhere since they execute as single-block chains. Affects state, blockchain, transition, and benchmark fixtures.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Every test in the fork, regardless of its purpose, requires two additional assertions: that its header's state_root matches the parent's post-state root, and that its own post-state root is not established by its header. Fork-transition vectors must be re-derived, as block F repeats F-1's root—a configuration no pre-fork vector exhibits.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The t8n tool is per-block and stateless, but the delayed root requires chain-level state across invocations. Two approaches: (1) thread invocation n's stateRoot output into block n+1's header, or (2) have the tool take an explicit lastComputedStateRoot env input to validate headers and detect faults. Either way requires a new mechanism, not a field addition.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Header assembly is framework-level. Block n's root comes from block n-1's execution, changing data flow globally. New primitives needed: (1) final post-state validation (sealing block or fixture-level field), (2) consume simulators modeling valid-then-invalidated payloads. Permanent framework change.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography introduced or modified. The state root is computed by the same trie machinery as before.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Deferred detection means invalid post-states surface only on successors, crossed with cases where the successor is absent, also invalid, or reorged away. Fork activation has distinctive edge cases: block F repeats state_root with its predecessor, and header.number < 1 must be handled at genesis. Empty blocks and reorgs allow stale last_computed_state_root values to pass undetected.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No RLP or encoding changes, but the header's state-root validation becomes stateful across blocks. A syncing client must accept a block with mismatched state_root, retain its computed root, and apply it to the successor. This cannot be tested with t8n alone—it requires a real client syncing a multi-block chain, including chains ending on unvalidated tips.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No new fields and no new endpoints",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contracts.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No system contract's code, state or invocation is affected, directly or indirectly.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcodes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No changes to the opcode",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompiles.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompiles modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No encoding changes",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity rules and intrinsic gas are entirely unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The `state_root` field semantics change but no new fields are added.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No new mechanism introduced",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The performance benefit (root off critical path, parallelized) is a pipeline property under ePBS, not isolatable for benchmarking. Secondary cost: parent pre-state held one slot longer.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Detection latency ripples through attestations, fork choice, builders, light clients, and tips. Mis-attributing faults is consensus-critical. Needs extensive review and fuzzing.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "which block is invalid when state roots disagree? The pseudocode marks n+1, but the defect is in n. Fork choice, newPayload, and peer scoring lack attribution guidance. Unsettled: genesis handling, RPC state root reporting, tip root exposure.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "EIP-7928 (BAL) enables parallel root computation; header includes block_access_list_hash. EIP-7732 (ePBS) provides builder-timing and introduces CL-side state_root needing coordinated testing.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7862,
"fork": "hegota",
"id": "hegota:7862:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7862.yaml",
"sha256": "293e1d8032a660cfffcfe5623c08614fd9877c79b64e2b9df6040b9c01e45fec"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "1dc6a162915c5d1dba92ba64efa8d8bef9981bcb",
"content_sha256": "40f8fb876f968f42545bcde3f802e5f9eb45989df8a8ee720c2bcdf9fed3025c",
"git_blob_sha": "440aa59d0d7596a119a93e1c99fbd48a6cc174ed",
"immutable_url": "https://github.com/ethspecs/pm/blob/1dc6a162915c5d1dba92ba64efa8d8bef9981bcb/complexity_assessments/EIPs/EIP-7862.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7862.md",
"pull_request": {
"draft": false,
"number": 124,
"title": "Add EIP-7862 complexity assessment",
"updated_at": "2026-08-24T06:38:06Z",
"url": "https://github.com/ethspecs/pm/pull/124"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 19,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "Delayed State Root",
"under_specification": null
},
"hegota:7862:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition",
"source": "eip.md",
"summary": "The transition applies the body as before and changes only when the resulting state root is stored; it specifies no EVM gas calculation."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Deferring the header commitment does not change execution-gas prices or introduce a gas-accounting mechanism.",
"score": 0,
"uncertainty_note": "No gas behavior is specified anywhere in the proposal's change surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > BAL Synergy",
"source": "eip.md",
"summary": "BAL data is described only as an optional input for parallel state-root computation after execution; no opcode execution path is changed."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal changes block-level root timing, not where an opcode accesses state or where gas is charged relative to that access.",
"score": 0,
"uncertainty_note": "State-access ordering rules in the linked EIP-7928 are not changes introduced by EIP-7862 and are therefore excluded.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Header",
"source": "eip.md",
"summary": "The existing blob_gas_used and excess_blob_gas fields are shown unchanged; only state_root receives new semantics."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas accounting rule is added or modified.",
"score": 0,
"uncertainty_note": "None; blob-gas fields are outside the specified change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition",
"source": "eip.md",
"summary": "The only post-body addition is computing and storing the root for the next block; no state-gas budget, rate, charging site, or spill path is defined."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "State-root computation timing is not a state-gas charging change.",
"score": 0,
"uncertainty_note": "None; the proposal contains no state-gas mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition",
"source": "eip.md",
"summary": "The transaction/body application remains unchanged and no refund rule is introduced."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None; refunds are not part of the specified change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Every block header changes from committing to its own post-state to committing to the preceding block's post-state."
},
{
"locator": "Specification > Header Validation; State Transition",
"source": "eip.md",
"summary": "Header validation compares state_root with a carried prior root, while the current post-state root is computed for the next block."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The change requires a hard fork and unmodified clients reject delayed-root blocks."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork block tests across transaction contents and block sequences must re-derive a consensus-critical header expectation and its validation timing. This is a major, diverse regression surface rather than a contrived category.",
"score": 3,
"uncertainty_note": "The package provides no test inventory, so the exact number of rewritten vectors is unknown, but the rule applies to every post-activation block.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Header",
"source": "eip.md",
"summary": "No field is added; the already-existing state_root field receives different semantics."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests must change an existing state-root expectation, scored above as test rework, but do not gain a separate new artifact or assertion.",
"score": 0,
"uncertainty_note": "Internal last_computed_state_root bookkeeping need not be exposed as an additional test invariant.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > BlockChain; State Transition; Fork Activation",
"source": "eip.md",
"summary": "The prior root is represented as internal BlockChain state, is initialized from the current State at activation, and is updated from the resulting State after each block."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The proposal requires transition logic changes but evidences no new external transition-tool field: the delayed header value and current State provide the values needed by the specified transition.",
"score": 0,
"uncertainty_note": "No transition-tool contract is included in the package, so this score is limited to the absence of a required external interface change in the EIP.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Header Validation; State Transition; Fork Activation",
"source": "eip.md",
"summary": "The behavior can be exercised using block sequences, existing header fields, state roots, and fork activation."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Nothing in the sealed specification requires a new expectation type, modifier, or permanent framework abstraction beyond constructing sequential blocks with chosen header roots.",
"score": 0,
"uncertainty_note": "The package contains no test-framework description; implementation-specific convenience helpers are not treated as required primitives.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Header; State Transition",
"source": "eip.md",
"summary": "The proposal reuses the existing Root type and state_root computation and changes only which block's result is placed in the header."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No new or modified cryptographic mechanism is introduced.",
"score": 0,
"uncertainty_note": "None; reuse of an existing state-root function is not new cryptography.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Fork Activation",
"source": "eip.md",
"summary": "Activation block F must contain the post-state root of F-1, and the steady delayed rule applies from F+1 onward."
},
{
"locator": "Security Considerations > Reorganization Handling",
"source": "eip.md",
"summary": "A reorganization requires recomputing last_computed_state_root for every block on the new canonical chain."
},
{
"locator": "Specification > Header Validation",
"source": "eip.md",
"summary": "Headers with number below 1 are explicitly invalid under the specified validation."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Activation/first-successor behavior and branch changes are multiple boundary mechanisms. Reorg tests require an elevated matrix over branch depth, activation position, and valid versus stale delayed roots.",
"score": 3,
"uncertainty_note": "The exact reorg test matrix is not enumerated, but per-block recomputation on the replacement branch is normative.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Header Validation",
"source": "eip.md",
"summary": "A single validation rule checks the existing header state_root against the carried root from the preceding state transition."
},
{
"locator": "Security Considerations > Reorganization Handling",
"source": "eip.md",
"summary": "Syncing across a branch change must recompute the carried root on the new chain."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "This is one simple new validation mechanism for a header field that syncing clients process; it does not add or alter RLP fields.",
"score": 1,
"uncertainty_note": "The package specifies validation semantics but no dedicated sync protocol or sync-test procedure.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Header",
"source": "eip.md",
"summary": "The proposal expressly adds no header field and only changes state_root semantics."
},
{
"locator": "Specification > Engine API",
"source": "supporting/eip-7732.md",
"summary": "The linked ePBS proposal states that no Engine API changes are needed."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "EIP-7862 introduces no Engine API field, endpoint, or communication mechanism. A semantic change to an existing EL header value does not meet this anchor's field/endpoint thresholds.",
"score": 0,
"uncertainty_note": "The EIP does not separately describe propagation of the changed existing state_root semantics through Engine API methods.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete change surface consists of header semantics, chain bookkeeping, validation, transition timing, and activation; no contract is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None; system contracts do not appear in the proposal's mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition",
"source": "eip.md",
"summary": "The body application and other validations remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system-contract code, state, or behavior is directly or indirectly modified by deferring the header root.",
"score": 0,
"uncertainty_note": "System-contract details in linked EIP-7928 describe that proposal and are not attributed to EIP-7862.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No opcode is defined in any part of the specified change."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "The proposal adds no opcode.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition",
"source": "eip.md",
"summary": "Transaction/body execution is retained and only state-root validation timing changes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode result or behavior is modified.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No precompile is introduced in the specified mechanism."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The proposal adds no precompile.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No precompile logic or gas schedule appears in the change surface."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "The proposal modifies no precompile.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Header",
"source": "eip.md",
"summary": "No field is added; the existing state_root field retains its Root type."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Changing the meaning of an existing same-typed field is not an RLP, SSZ, transaction, block, or interface encoding change.",
"score": 0,
"uncertainty_note": "The block_access_list_hash shown in the header belongs to linked EIP-7928 and is not introduced by EIP-7862.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition",
"source": "eip.md",
"summary": "Existing transactions are passed unchanged to apply_body."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State Transition",
"source": "eip.md",
"summary": "Transactions and withdrawals are applied through the existing body path; the new validation applies to the block header root."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic-gas calculation is changed.",
"score": 0,
"uncertainty_note": "None; block-header validity is scored separately.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Header",
"source": "eip.md",
"summary": "The specification explicitly states that no new fields are added."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The existing state_root field is reinterpreted; no block or header field is new.",
"score": 0,
"uncertainty_note": "None; the proposal is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Fork Activation",
"source": "eip.md",
"summary": "Activation initializes the newly introduced internal last_computed_state_root from the current State."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The only activation action is initialization of a new internal variable, which the rubric expressly excludes from a score on this anchor; no protocol state is modified.",
"score": 0,
"uncertainty_note": "Activation-boundary test complexity is captured under Edge/boundary conditions, not duplicated here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "State-root computation is identified as a significant production bottleneck, and the proposal moves it out of the attestation critical path."
},
{
"locator": "Rationale > BAL Synergy",
"source": "eip.md",
"summary": "The intended path uses the preceding block's BAL for parallel proof generation and may let builders construct without fully executing the preceding block."
},
{
"locator": "Security Considerations > Pre-state Availability",
"source": "eip.md",
"summary": "Clients must retain the pre-state until its root is committed in the next block."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The feature changes timing and retention in the existing block-production and validation pipeline and has complex interaction with BAL-assisted root computation. Its impact cannot be validated fully in isolation and directly targets a substantial existing performance bottleneck.",
"score": 3,
"uncertainty_note": "The package gives qualitative claims but no benchmark results; the score is for breadth and coupling of required performance validation, not claimed gain.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Header Validation",
"source": "eip.md",
"summary": "Validators may attest without waiting for current state-root computation, while header validity instead checks the carried preceding-state root."
},
{
"locator": "Security Considerations > Reorganization Handling; Pre-state Availability",
"source": "eip.md",
"summary": "Correctness depends on recomputing the carried root on a new canonical branch and retaining the prior state through the delayed commitment."
},
{
"locator": "Rationale > Light Client Impact",
"source": "eip.md",
"summary": "State proofs acquire one slot of additional latency."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A core state-commitment invariant is changed across header validation, state transition bookkeeping, reorg handling, retained state, and proof consumers. These include critical components and require extensive branch, invalid-root, and delayed-commitment review and fuzzing.",
"score": 3,
"uncertainty_note": "The EIP states that the light-client security model is unchanged, but that claim does not remove implementation risk from the altered commitment timing.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Header Validation; State Transition; Fork Activation",
"source": "eip.md",
"summary": "The compared value, update point, activation value, and F/F+1 header roots are all specified normatively or in executable pseudocode."
},
{
"locator": "Security Considerations > Reorganization Handling",
"source": "eip.md",
"summary": "The required carried-root outcome on a new canonical branch is specified as per-block recomputation."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The sealed text determines the consensus result for the constructible delayed root, activation, and reorg cases it introduces; no previously unobservable choice is left for clients to baseline.",
"score": 0,
"uncertainty_note": "Prohibited implementation, devnet, and discussion evidence is unavailable by design; operational algorithms are not treated as consensus ambiguity where the required root value is deterministic.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > ePBS Compatibility",
"source": "eip.md",
"summary": "EIP-7732's ExecutionPayloadEnvelope has a distinct CL state_root; EIP-7862 changes only the EL header state_root and says CL verification is unaffected."
},
{
"locator": "Specification > Execution Layer; Engine API",
"source": "supporting/eip-7732.md",
"summary": "The linked ePBS proposal specifies no EL or Engine API changes."
},
{
"locator": "Rationale > BAL Synergy",
"source": "eip.md",
"summary": "EIP-7928 BAL data can parallelize computation of the root to be included in the following block."
},
{
"locator": "Abstract; Specification > State Transition Function",
"source": "supporting/eip-7928.md",
"summary": "The linked BAL proposal supplies state accesses and post-transaction diffs and validates them against block execution."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7732,
7928
],
"rationale": "The proposal has two explicit but bounded interactions: a field-semantics boundary with 7732 and optional performance synergy with 7928. Neither linked proposal is modified, and delayed-root correctness remains mostly testable on its own.",
"score": 1,
"uncertainty_note": "Coordinated tests should distinguish the EL and CL fields and compare BAL-derived roots with the next header, but linked-EIP complexity is excluded.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7862,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7862:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The package does not define transition-tool or test-framework adaptations; the corresponding scores therefore reflect protocol necessity, not a particular implementation's convenience interface.",
"EIP-7732's CL state_root and EIP-7862's EL header state_root share a name but are explicitly separate; only the EL field is assessed here."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "2f044dc1c00ae5558aa3c17367da056acf0f76701f492ae63e77fb0b9b293cdc",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7862.md",
"git_blob_sha": "771e60beb3251184761a71e4734d6a793731c928",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7862.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7862.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7862.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7862.yaml",
"sha256": "f2c6a70f8b1c3815341e52e657284aebb0c2de589af945bc9f4e34b5b1e0346f"
},
"supporting_documents": [
"supporting/eip-7732.md",
"supporting/eip-7928.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 14,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the sealed EIP-7862 draft. The proposal changes the semantics of the existing EL header state_root to commit to the parent post-state, tracks the next root internally, and initializes that internal value at activation. EIP-7732 and EIP-7928 are considered only for their stated interactions; no consensus-layer complexity or linked-EIP implementation complexity is attributed to EIP-7862.",
"tier": "medium",
"title": "Delayed State Root",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 14
},
"present": false,
"summary": "No material consensus under-specification was identified in the sealed execution-layer proposal. Tool and framework integration details are absent, but the delayed root values and state-transition timing are sufficiently determined and those omissions do not change the score.",
"unresolved_questions": []
}
},
"hegota:7906:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"17 blank score cells are interpreted as zero only because the published total equals the sum of every nonblank cell."
],
"published_tier": "high",
"published_total": 23,
"recomputed_tier": "high",
"recomputed_total": 23,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "EIP-2929 access-list accounting is extended to a new class of read: `TXDIFF` params 0x00–0x05 fall back to live state, priced warm/cold, and add the slot or address to the access list afterwards.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "New state-accessing operations whose position must be settled per param. `TXDIFF` 0x00–0x05 read live state and record in the EIP-7928 BAL; 0x06–0x0A answer from the diff and touch neither. Each of the 11 params needs its access-list and BAL behaviour verified.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Additive. The three opcodes halt outside a `POST_TX` frame, so legacy and EIP-1559 transactions are unaffected.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "New primitives needed to build `POST_TX` frames and to express an expected transaction diff and event enumeration. The BAL expectation types are the closest existing analogue but do not cover balances, codehashes or event ordering.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Elevated case counts. `TXTRACE` has 22 params and `TXDIFF` 11, each with index bounds; every *must be 0* operand halts on non-zero; `event_topic0`–`3` halt past `event_topic_count`; `EVENTDATACOPY` halts on both out-of-range index and `dataOffset + length`. Plus net-zero collapsing (modified-then-restored sets no entry and no flag bit), canonical uint160/uint256 sort order, `CREATE` leaving empty code, and EIP-7702 designators excluded from `contracts_deployed`.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Three new opcodes, at least one complex: `TXTRACE` (22 params), `TXDIFF` (11 params, dynamic warm/cold gas), `EVENTDATACOPY` (4 stack inputs, memory expansion, `CALLDATACOPY` semantics).",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Amends EIP-8141's structural rules: `assert frame.mode < 3` becomes `< 4`, and `POST_TX` frames must form a contiguous trailing suffix or the transaction is invalid. Coordinated with EIP-8141 but no existing vectors to redesign.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "`TXDIFF` 0x00–0x05 take an arbitrary address, so this is the first mechanism by which execution can read another account's storage slot. Those reads enter the BAL, so an assertion can populate the BAL with `(address, slot)` pairs the owning contract never touched, which breaks the assumption that a BAL entry implies interaction by that contract.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Introspection is inert: `POST_TX` is a `STATICCALL` that cannot modify state. But `TXDIFF` can still add arbitrary storage keys to the BAL reads, and we need to prove that this does not affect present usecases or future EIPs (the witness generation is affected by this).",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously unobservable behaviour becomes consensus-critical and has to be settled by discussion before vectors can be baselined: what counts as a change, how net-zero writes collapse, and the canonical enumeration order. Localized to the diff model.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Strong interdependencies. **EIP-8141** is a hard dependency that this EIP *amends* — nothing here is testable without it, and EIP-8141 is itself Draft and assessed 🔴 38. **EIP-2929** (pricing, and `TXDIFF` mutates the access list), **EIP-7928** (BAL recording for live-state reads), **EIP-7702** (designators excluded from `contracts_deployed`), **EIP-4844** (blob fees folded into `gas_pre_charge`).
The \"valid only inside a `POST_TX` frame\" restriction then pulls in every transaction type as a negative case: the three opcodes must be shown to halt in legacy, **EIP-2930**, **EIP-1559**, **EIP-4844** and **EIP-7702** transactions, and in the `DEFAULT`, `VERIFY` and `SENDER` frame modes — roughly 3 x 8 coordinated cases, each owned by a different EIP's transaction format. With **EIP-2718** framing those types, 8 interacting EIPs gives +1 for 5 beyond the first 3.",
"raw_score_cell": "3 + 1",
"score": 4,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7906,
"fork": "hegota",
"id": "hegota:7906:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7906.yaml",
"sha256": "f363d8a27dc31b9e263b9c2788a48f09e1a7acc05cc0a8cfc94bd39ba25aa071"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "18cfcab5e295ad9e544c8bf8b57f998defaa7b31",
"content_sha256": "34e1b22f395fbbc4059ecfad790448556206aedd716763d5e6aa31a806fdabd1",
"git_blob_sha": "e2bc9d7fc5c9666952f06054ddb3a82f0fa4f15d",
"immutable_url": "https://github.com/ethspecs/pm/blob/18cfcab5e295ad9e544c8bf8b57f998defaa7b31/complexity_assessments/EIPs/EIP-7906.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7906.md",
"pull_request": {
"draft": false,
"number": 132,
"title": "Add EIP-7906 complexity assessment",
"updated_at": "2026-08-24T18:46:05Z",
"url": "https://github.com/ethspecs/pm/pull/132"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 23,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "high",
"title": "Transaction Assertions via State Diff Opcode",
"under_specification": null
},
"hegota:7906:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction Diff Lookup Opcode > Gas Cost",
"source": "eip.md",
"summary": "TXDIFF params 0x00–0x05 use EIP-2929 cold/warm costs and add the queried address or slot to the shared access list after the call."
},
{
"locator": "Specification > Results Ordering > EVENTDATACOPY opcode",
"source": "eip.md",
"summary": "EVENTDATACOPY uses CALLDATACOPY-style fixed, copying, and memory-expansion charges."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal adds several opcode-specific gas rules, including dynamic memory/copy charging and state-dependent cold/warm charging. TXDIFF also changes shared warmness, so it can change the gas charged by later existing operations; this reaches score 3.",
"score": 3,
"uncertainty_note": "TXTRACE_GAS_COST and the constants-table EVENTDATACOPY_GAS_COST remain TBD, and no opcode-wide charge/error ordering is fully specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction Diff Lookup Opcode > Gas Cost",
"source": "eip.md",
"summary": "For TXDIFF params 0x00–0x05, cost depends on pre-call warmness; the address or slot is added to EIP-2929 access lists after the call and recorded in the EIP-7928 BAL where active."
},
{
"locator": "Specification > Gas Validation Before State Access",
"source": "supporting/eip-7928.md",
"summary": "BAL inclusion is consensus-critical at gas boundaries: pre-state validation must pass before the target is accessed and recorded."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "TXDIFF is a new state-accessing operation whose gas validation, live-state read, warmness update, and BAL recording position must be fixed. This matches the score-2 anchor for a new state-accessing operation whose ordering must be settled.",
"score": 2,
"uncertainty_note": "The draft says the access-list addition occurs after the call but does not define ordering for invalid params, reserved operands, failed reads, or insufficient gas.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction Trace Opcode",
"source": "eip.md",
"summary": "For blob transactions, gas_pre_charge reports the existing blob-fee component as blob_count × GAS_PER_BLOB × blob_base_fee."
},
{
"locator": "Specification > Gas accounting",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already defines blob gas, GAS_PER_BLOB, and blob fee calculation."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "EIP-7906 exposes an already-computed blob fee through TXTRACE but does not alter blob-gas charging, limits, base-fee calculation, or refund behavior.",
"score": 0,
"uncertainty_note": "The exposed gas_pre_charge value is underspecified in other respects, but the package contains no blob-gas accounting change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "POST_TX executes as STATICCALL and disallows state manipulation, including the APPROVE exception."
},
{
"locator": "Specification > Transaction Diff Lookup Opcode > Gas Cost",
"source": "eip.md",
"summary": "The new opcode costs are EIP-2929 execution-gas access charges or a flat TXTRACE cost, not state-gas charges."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal observes state differences but introduces no state write, state-gas charging site, state budget change, or spill/reservoir rule.",
"score": 0,
"uncertainty_note": "This is limited to EIP-7906; the underlying EIP-8141 transaction already has a separate state-gas model.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Gas Pre-Charge Parameter",
"source": "eip.md",
"summary": "The text describes the ordinary refund of unused prepaid gas as provisional fee settlement; it does not define a new refund mechanism."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund counter rule or refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "The exact fee view visible during POST_TX is ambiguous, but that does not itself add a refund mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "The proposal amends EIP-8141 mode validity, frame ordering, caller/static behavior, atomic-batch rollback, transaction validity, gas payment, and failure receipt behavior."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "All three opcodes are restricted to EIP-8141 POST_TX frames and halt exceptionally in legacy, EIP-1559, and other frame modes."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable but specialized category of pre-existing frame-transaction and opcode-context tests must be reworked for a fourth mode, a trailing-suffix rule, and failure semantics that override atomic batches. The affected category is contrived to EIP-8141/frame execution, fitting score 2.",
"score": 2,
"uncertainty_note": "The sealed package contains no test inventory, so the size of the pre-existing EIP-8141 test subset is inferred only from the normative amendments.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The new opcodes occupy unused slots, are unavailable outside POST_TX, and make no changes to existing opcodes, transaction types, or precompiles."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The proposal changes targeted frame-transaction logic, but it does not add a mechanically required output that unrelated pre-existing tests must additionally assert.",
"score": 0,
"uncertainty_note": "EIP-8141-specific tests are reworked under the preceding anchor; no package evidence requires a new assertion across unrelated tests.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Frame Transaction > Payload Encoding",
"source": "supporting/eip-8141.md",
"summary": "The existing frame payload already carries a numeric mode field inside each frame."
},
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "EIP-7906 admits one additional value in that existing mode field; it does not define a new external transition-tool field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The package supports an extension of an existing encoded field's accepted values, not a new transition-tool interface field or mechanism.",
"score": 0,
"uncertainty_note": "No transition-tool design is included in the sealed evidence; the score reflects only explicit interface changes in the proposal.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > The POST_TX Frame Mode; Transaction Trace Opcode; Transaction Diff Lookup Opcode; EVENTDATACOPY opcode",
"source": "eip.md",
"summary": "The proposal's cases are expressible as frame transactions plus EVM bytecode invoking numeric opcode parameters and checking execution outcomes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The sealed specification does not establish a need for a new reusable expectation, modifier, or framework-level abstraction beyond existing transaction/frame construction and EVM execution assertions.",
"score": 0,
"uncertainty_note": "The package contains no test-framework design or tests, so a minor helper extension may prove useful even though none is demonstrated as required.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Transaction Trace Opcode",
"source": "eip.md",
"summary": "The feature exposes transaction outcomes, state differences, and event data; it defines no cryptographic primitive or verification rule."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is added or modified.",
"score": 0,
"uncertainty_note": "Code hashes are returned as state data, but computing or validating a new cryptographic construction is outside this proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction Trace Opcode; Transaction Diff Lookup Opcode > Params; Reserved Inputs",
"source": "eip.md",
"summary": "The opcodes expose many parameter domains, must-be-zero operands, indexed tables, 0–4 event topics, local-to-global remapping, bit flags, and exceptional-halt cases."
},
{
"locator": "Specification > Results Ordering > EVENTDATACOPY opcode",
"source": "eip.md",
"summary": "Copy behavior adds event-index and data-range boundaries plus memory expansion and variable-length data."
},
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "POST_TX adds suffix boundaries, multiple-frame composition, STATICCALL violations, ordinary reverts, exceptional halts, atomic-batch override, validation-prefix persistence, and failed-receipt outcomes."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple independent boundary-prone mechanisms require an elevated matrix: params and indices, empty/restored/deployed state, event topic/data limits, warm/cold accesses, POST_TX placement, failure kind, and rollback scope. This meets score 3.",
"score": 3,
"uncertainty_note": "Several boundary outcomes are themselves unspecified, increasing coordination risk but not counted again as extra edge mechanisms.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal lists opcode and frame-execution changes and states that existing transaction types are unchanged; it defines no block RLP validation change."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism requiring sync testing is introduced.",
"score": 0,
"uncertainty_note": "EIP-7928 BAL recording is an interaction of state accesses, not a block-sync format change made by EIP-7906.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative changes are confined to EIP-8141 frame processing and EVM opcodes; no Engine API field, version, or endpoint is defined."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced by this proposal.",
"score": 0,
"uncertainty_note": "EIP-7928 has Engine API changes, but EIP-7906 only records compatible accesses into its BAL and does not modify that interface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > The POST_TX Frame Mode Requirement",
"source": "eip.md",
"summary": "Assertion providers execute their own assertion logic in ordinary POST_TX frames; no protocol-installed contract or fixed system address is specified."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "The assertion contracts are user-selected contracts, not new system contracts.",
"score": 0,
"uncertainty_note": "The EIP recommends immutable assertion targets but does not mandate deployment of a system contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "POST_TX targets are dispatched as EIP-8141 frames and the proposal does not alter code or state of any named system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified by a specified transition.",
"score": 0,
"uncertainty_note": "Ordinary contracts may opt into assertions, but that application behavior is not a system-contract modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction Trace Opcode; Transaction Diff Lookup Opcode; EVENTDATACOPY opcode",
"source": "eip.md",
"summary": "The proposal introduces TXTRACE, TXDIFF, and EVENTDATACOPY. They have multi-operand parameter spaces, dynamic cold/warm or memory/copy gas, indexed state/event data, and exceptional-halt branches."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Three opcodes are added and all have complex mechanics or dynamic gas/data behavior; this directly matches score 3.",
"score": 3,
"uncertainty_note": "The opcode byte values and complete stack/error definitions are missing, but the number and complexity class of the proposed opcodes are clear.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal explicitly states that no changes are made to existing opcodes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "Sharing EIP-2929 warmth with TXDIFF affects later gas, scored under gas and access ordering rather than as a result change to an existing opcode.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal explicitly states that no changes are made to precompiles."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None material in the sealed package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal explicitly states that no changes are made to precompiles."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "None material in the sealed package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Frame Transaction > Payload Encoding",
"source": "supporting/eip-8141.md",
"summary": "EIP-8141 already RLP-encodes mode inside each frame."
},
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "EIP-7906 extends the accepted numeric domain from mode < 3 to mode < 4 without changing the RLP shape or encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Adding a semantic value to an existing scalar field is a validity change, not an RLP/SSZ encoding change under this anchor.",
"score": 0,
"uncertainty_note": "The statement that a failed frame transaction generates a status=0 receipt is ambiguous against EIP-8141, but no replacement receipt encoding is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > The POST_TX Frame Mode; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal amends the existing EIP-8141 frame transaction and explicitly states that it introduces no new transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction envelope or transaction-type byte is introduced.",
"score": 0,
"uncertainty_note": "The feature has a hard dependency on the separate EIP-8141 transaction type.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "Mode 3 becomes valid, POST_TX frames must be a contiguous suffix, violations invalidate the transaction, and POST_TX failure reverts execution while leaving the transaction valid with a failed outcome."
},
{
"locator": "Specification > Frame Transaction > Constraints; Behavior",
"source": "supporting/eip-8141.md",
"summary": "The parent proposal previously requires mode < 3, treats VERIFY failure as transaction-invalid, and defines atomic-batch rollback and payer approval."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The proposal modifies validity and failure classification for an existing transaction type. Updates are substantial but localized to frame mode validation and POST_TX execution, with no demonstrated test-infrastructure redesign, fitting score 2.",
"score": 2,
"uncertainty_note": "The exact execution-body rollback boundary and failed-receipt representation are not fully reconciled with EIP-8141.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal defines frame and opcode behavior only and introduces no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "BAL recording uses the field already proposed by EIP-7928; EIP-7906 does not add another one.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > The POST_TX Frame Mode; Backwards Compatibility",
"source": "eip.md",
"summary": "The behavior applies wherever EIP-7906 is active, but no activation-block state transition or modification of an existing internal variable is defined."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork gating of opcodes and validity rules is not a new activation mechanism under the rubric.",
"score": 0,
"uncertainty_note": "Opcode byte assignments remain unspecified, but no activation-time state mutation is proposed.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > State Difference Semantics; Results Ordering",
"source": "eip.md",
"summary": "Clients must expose transaction-prestate versus current values, collapse repeated writes, maintain per-address views, enumerate events, and deterministically sort address and slot changes."
},
{
"locator": "Security Considerations > Assertion Gas Exhaustion",
"source": "eip.md",
"summary": "The proposal states that a transaction can produce about 42,600 events and that full enumeration requires significant gas; unrelated events may be attacker-controlled."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Transaction-wide diff capture and canonical enumeration cannot be validated only as an isolated opcode microbenchmark; they interact with state journaling, reverts, logs, access lists, and worst-case transaction contents. The stated event scale and attacker-controlled padding create substantial benchmark impact, reaching score 3.",
"score": 3,
"uncertainty_note": "The package gives no client data-structure design or benchmarks, and the flat TXTRACE gas cost is TBD, so the exact overhead is unknown.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Insufficiently Restrictive Assertions; Enforcing POST_TX Frame Inclusion",
"source": "eip.md",
"summary": "Incomplete assertions can create a false sense of safety; wallets must require the intended POST_TX frame and an immutable assertion target to avoid bypass or same-transaction upgrade attacks."
},
{
"locator": "Security Considerations > Assertion Gas Exhaustion; The POST_TX Frame Mode Not Reverting Validation Prefix",
"source": "eip.md",
"summary": "Attacker-controlled enumeration can exhaust assertion gas, and POST_TX failure preserves the validation prefix and gas payment, leaving deploy-frame side effects outside rollback."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism spans critical transaction validity, rollback, gas payment, wallet authorization, contract immutability, and adversarial resource exhaustion. Incorrect implementation or integration could compromise users or create DoS behavior, requiring extensive review and fuzzing; score 3.",
"score": 3,
"uncertainty_note": "Some risks depend on wallet/assertion construction, but the protocol's rollback and gas-exhaustion surfaces are independently security-critical.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants",
"source": "eip.md",
"summary": "TXTRACE_GAS_COST and EVENTDATACOPY_GAS_COST are TBD, and the proposal supplies no opcode byte constants for TXTRACE, TXDIFF, or EVENTDATACOPY."
},
{
"locator": "Specification > Transaction Trace Opcode; Reserved Inputs; EVENTDATACOPY opcode",
"source": "eip.md",
"summary": "TXTRACE's general invalid-param/index behavior and several charge/access/error orderings are not defined, while EVENTDATACOPY defines only selected out-of-bounds cases."
},
{
"locator": "Specification > The POST_TX Frame Mode",
"source": "eip.md",
"summary": "The text says a POST_TX failure yields a receipt with status=0 and reverts the execution body up to the validation prefix."
},
{
"locator": "Specification > Frame Transaction > Receipt Encoding",
"source": "supporting/eip-8141.md",
"summary": "EIP-8141 defines per-frame statuses and explicitly carries no transaction-level status, leaving the EIP-7906 failed-receipt statement unreconciled."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously internal transaction-prestate/current-state, event, access, fee, and rollback details become directly observable and consensus-critical. Multiple constructible cases lack determined outcomes or constants, and the receipt/rollback text is not fully reconciled with the required frame transaction; this meets score 3.",
"score": 3,
"uncertainty_note": "The score is based solely on visible Draft/TBD and normative gaps; prohibited implementation, devnet, discussion-thread, or later-revision evidence was not consulted.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Specification > The POST_TX Frame Mode; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal requires EIPs 2929 and 8141, directly amends EIP-8141 frame semantics, and restricts all new opcodes to the new EIP-8141 mode."
},
{
"locator": "Specification > Transaction Diff Lookup Opcode > Gas Cost",
"source": "eip.md",
"summary": "TXDIFF uses EIP-2929 warmth and, where active, must record accesses in the EIP-7928 block-level access list."
},
{
"locator": "Specification > Transaction Trace Opcode > State Difference Semantics; Rationale > Gas Pre-Charge Parameter",
"source": "eip.md",
"summary": "Deployment enumeration excludes EIP-7702 designators; gas_pre_charge covers EIP-4844 blob fees and identifies the EIP-8141 payer; EIP-1559 and legacy contexts reject the opcodes."
}
],
"exceptional_score_justification": "Score 4 is warranted by the rubric's uncapped formula: six package-grounded interacting EIPs are three beyond the first three, adding +1 to the base score of 3. The interactions span separate consensus-sensitive dimensions rather than repeated references to one mechanism.",
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
2929,
4844,
7702,
7928,
8141
],
"rationale": "Six identified EIPs create coordinated test axes: EIP-8141 frame validity/rollback/payment, EIP-2929 warm/cold access, EIP-7928 BAL recording, EIP-4844 blob pre-charge, EIP-7702 deployment classification, and EIP-1559 context/fee behavior. Strong interdependence gives base score 3, plus one point for the three interactions beyond the first three, for score 4.",
"score": 4,
"uncertainty_note": "The interaction list includes only EIPs explicitly grounded in the sealed package and requiring distinct cases; no external or latent interaction was added.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7906,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7906:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"EIP-7906 says POST_TX failure generates a receipt with status = 0, while required EIP-8141 defines only per-frame statuses and explicitly no transaction-level status.",
"The constants table leaves EVENTDATACOPY_GAS_COST TBD, while the later opcode section says its fixed cost is 3 plus copying and memory expansion.",
"The phrase 'execution body ... up to the validation prefix' does not precisely partition all possible EIP-8141 frames around payer approval.",
"TXTRACE enumerates events and net state changes but does not comprehensively state treatment of reverted subcalls, restored writes, fee settlement, and intermediate POST_TX-frame observations."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "0a621cf6154e4b6baf050c197c7f33f893f48db42f75a8f440c7c333a414dc64",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7906.md",
"git_blob_sha": "799d721e74024629d7de1017532fc16352250b3d",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7906.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7906.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7906.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7906.yaml",
"sha256": "52daf889b96d0289b58ae4a93be9b78c66b3cf5bf6d7bb63eb3b8ea12487f171"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-2929.md",
"supporting/eip-4844.md",
"supporting/eip-7702.md",
"supporting/eip-7928.md",
"supporting/eip-8141.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 28,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Draft execution-layer proposal adding a POST_TX frame mode to EIP-8141 and three EVM opcodes—TXTRACE, TXDIFF, and EVENTDATACOPY—to expose transaction-local state differences and events to assertion contracts. The assessment covers only behavior and evidence sealed in this package.",
"tier": "high",
"title": "Transaction Assertions via State Diff Opcode",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"patterns_affecting_pre_existing_tests",
"new_test_framework_primitives",
"edge_boundary_conditions",
"added_opcodes",
"new_or_modified_transaction_validity_mechanisms",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 30,
"minimum": 24
},
"present": true,
"summary": "Material consensus details remain open: opcode byte assignments and stack/error behavior are incomplete; two gas constants are TBD; state-access and exceptional-halt ordering is not comprehensive; and POST_TX rollback/receipt semantics are not fully reconciled with EIP-8141. These gaps make constructible state-diff and failure cases impossible to baseline authoritatively from the snapshot alone.",
"unresolved_questions": [
"Which opcode byte is assigned to each of TXTRACE, TXDIFF, and EVENTDATACOPY, and what are the exact stack pop/push conventions for TXTRACE and TXDIFF?",
"What final values replace TXTRACE_GAS_COST and EVENTDATACOPY_GAS_COST, and is EVENTDATACOPY_GAS_COST the fixed base in addition to copying and memory expansion?",
"For every opcode, when are gas charged, live state read, EIP-2929 warmth updated, and EIP-7928 access recorded relative to invalid params, reserved operands, out-of-range indices, and insufficient gas?",
"What happens for undefined TXTRACE/TXDIFF params and for out-of-range TXTRACE indices other than the event-topic cases explicitly called out?",
"Exactly which frames and effects constitute the validation prefix and execution body when a POST_TX frame fails, especially for frames after payer approval but before the POST_TX suffix?",
"How is a failed POST_TX outcome represented in the EIP-8141 per-frame receipt format, which has no transaction-level status?",
"Which fee-settlement, reverted-call, restored-write, and log states are included in each trace table at the moment an assertion executes?"
]
}
},
"hegota:7923:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"18 blank score cells are interpreted as zero only because the published total equals the sum of every nonblank cell."
],
"published_tier": "medium",
"published_total": 15,
"recomputed_tier": "medium",
"recomputed_total": 15,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Deletes the linear and quadratic memory terms and replaces them with a 100-gas charge per newly touched 4 KiB page. Repricing reaches all 18 memory-expanding opcodes, and page 0 being free makes `MSTORE(0, x)` cost 3 instead of 6.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "1982 test files pair a memory-expanding opcode with an exact-gas expectation: 1831 in `tests/ported_static/`, 151 hand-written across 14 forks plus `tests/benchmark/`. Also, a single MSTORE(x, 1) can no longer cause an OOG, which is one of the go-to ways that tests use to produce one.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "`MemoryExpansionGasCalculator` is `(new_bytes, previous_bytes) -> int`, a pure function of sizes. Page cost depends on which offsets are touched and on what the frame touched before, so the protocol, the `new_memory_size`/`old_memory_size` opcode metadata and its six per-EIP consumers all need a page-aware replacement that stays fork-scoped.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Memory allocation change from continuous to sparse: an instruction pays only for the pages its own range covers, so touching page 1000 leaves pages 1-999 unallocated. On top of that, page-crossing reads and writes on 18 opcodes, free page 0 against paid page 1, first touch against re-touch, the 2**32 address halt, the 16384-page transaction halt, and `MCOPY` with source and destination straddling different pages.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Row excludes gas changes, accounted for in the first row.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Memory benchmark tests need to be written from the ground up to cover the new memory allocation mechanism.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Small risk: contracts that previously ran out of gas by memory allocation, potentially now will not, therefore it's worth exploring if this could be an issue with currently existing contracts.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 7923,
"fork": "hegota",
"id": "hegota:7923:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-7923.yaml",
"sha256": "f1e40df995212b2604cb66cd1857ad67daa5deb30a4d2f2f0bb27a1a4f0e7003"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "5f85492e085509e32602538d721e23fc11be6323",
"content_sha256": "e6260a5df1ebe00699afa03d1d74c7ec8e7837742cbaa37f9531e81e3a14f0ec",
"git_blob_sha": "77392502f74959d36064a9446a01a6b56f33e13b",
"immutable_url": "https://github.com/ethspecs/pm/blob/5f85492e085509e32602538d721e23fc11be6323/complexity_assessments/EIPs/EIP-7923.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7923.md",
"pull_request": {
"draft": false,
"number": 134,
"title": "Add EIP-7923 complexity assessment",
"updated_at": "2026-08-25T00:42:59Z",
"url": "https://github.com/ethspecs/pm/pull/134"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 15,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "Linear, Page-Based Memory Costing",
"under_specification": null
},
"hegota:7923:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, memory costing algorithm (lines 41-54)",
"source": "eip.md",
"summary": "Untouched pages cost 100 gas when first touched in a message call, page 0 is free, and the existing linear and quadratic expansion terms are removed."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This is a new page-history-based EVM gas mechanism that replaces the existing expansion mechanism for all memory instructions, necessarily changing existing gas expectations and tests.",
"score": 3,
"uncertainty_note": "The exact instruction coverage and touch ordering are underspecified, but the replacement of the existing gas mechanism is explicit and fixes this anchor at 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification (lines 13-15, 39-59)",
"source": "eip.md",
"summary": "The proposal changes volatile EVM memory costing and limits; it introduces no state access or gas ordering relative to a state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Page touches concern EVM memory, not chain state, so no state-access ordering within an opcode is changed.",
"score": 0,
"uncertainty_note": "No package evidence identifies a state-accessing operation in scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "The complete normative change is limited to EVM memory page pricing, address width, and an allocated-memory limit."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas rule is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob mechanism appears in the package evidence.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "The proposal meters transient EVM memory pages and does not charge state writes or alter a state-gas budget or spill path."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "EVM memory allocation gas is execution gas, not the rubric-defined gas for writing state.",
"score": 0,
"uncertainty_note": "No state-gas facility is mentioned in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, memory costing algorithm (lines 49-59)",
"source": "eip.md",
"summary": "The algorithm only charges gas and raises exceptional halts; it defines no refund."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "No refund behavior is stated or implied by page deallocation.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, memory costing algorithm (lines 49-59)",
"source": "eip.md",
"summary": "Every memory instruction moves from high-water linear/quadratic expansion pricing to first-touch page pricing, with new exceptional-halt limits."
},
{
"locator": "Backwards Compatibility and Security Considerations (lines 89-91, 328-338)",
"source": "eip.md",
"summary": "Some contracts that formerly ran out of gas may complete, and the proposal explicitly raises contract-compatibility and memory-DoS questions."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Gas and outcome vectors across the broad, diverse class of existing memory-using opcode and nested-call tests must be reworked, rather than only a narrow contrived category.",
"score": 3,
"uncertainty_note": "The Test Cases section is empty, so the package does not quantify the affected corpus or enumerate all memory instructions.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification (lines 49-59)",
"source": "eip.md",
"summary": "The transaction-global page ceiling changes execution behavior but the EIP specifies no new result or artifact that unrelated tests must additionally assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing gas and outcome tests may need changed expectations, which belongs to the prior anchor; they do not gain a separate universal assertion.",
"score": 0,
"uncertainty_note": "The empty Test Cases section provides no explicit assertion plan, but no externally assertable invariant is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Reference Implementation (lines 39-59, 313-325)",
"source": "eip.md",
"summary": "The only new counter shown is internal transaction-context state; no transition-tool input or output field is defined."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The execution change can be derived from ordinary transaction execution without a new transition-tool interface field or mechanism.",
"score": 0,
"uncertainty_note": "No transition-tool interface is discussed in the package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases (lines 93-94) and Specification (lines 49-59)",
"source": "eip.md",
"summary": "No test cases or new expectation, modifier, or helper primitive are specified; observable gas use and exceptional halts are ordinary execution outcomes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The sealed proposal does not establish a need for a new test-framework abstraction beyond constructing calls and checking gas or halt results.",
"score": 0,
"uncertainty_note": "Because the Test Cases section is empty, framework needs are not demonstrated; this score does not assume unprovided infrastructure.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification (lines 13-15, 39-59)",
"source": "eip.md",
"summary": "The feature consists of memory address, page-accounting, gas, and limit rules and introduces no cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography mechanism is added or modified.",
"score": 0,
"uncertainty_note": "The rationale uses keccak256 only as a benchmark calibration reference, not as a cryptographic protocol change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 41-59)",
"source": "eip.md",
"summary": "Consensus boundaries include free page 0, 4096-byte page crossings, repeated first touches, 32-bit addresses, and the 16384-page transaction limit."
},
{
"locator": "Reference Implementation, memory extension and write paths (lines 136-159, 242-312)",
"source": "eip.md",
"summary": "The example handles zero sizes, computes inclusive end pages, tracks per-call pages, and contains a separate end-address check, exposing several boundary paths."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact across zero-length accesses, cross-page ranges, maximum addresses, gas exhaustion, and nested calls; at least the transaction-global cap and page-touch matrix require elevated case counts.",
"score": 3,
"uncertainty_note": "The normative text does not settle several off-by-one, lifetime, and failure-order cases, increasing rather than removing the boundary burden.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "No block RLP field or block-validation encoding rule is introduced; the change occurs during EVM execution."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "There is no new RLP validation mechanism requiring client syncing tests.",
"score": 0,
"uncertainty_note": "No block serialization change appears in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "The proposal defines no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced.",
"score": 0,
"uncertainty_note": "Engine API behavior is outside the stated proposal surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "The memory rules are implemented in EVM execution and do not deploy or designate a contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No contract address, code, state, or system action is specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Reference Implementation (lines 39-59, 95-325)",
"source": "eip.md",
"summary": "All described changes are to generic computation, memory, and transaction-context logic; no pre-existing system contract is identified or modified."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The package provides no grounded direct or indirect system-contract modification to score.",
"score": 0,
"uncertainty_note": "The package contains no system-contract inventory; prohibited external knowledge was not used to infer an interaction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 49-59)",
"source": "eip.md",
"summary": "The proposal applies new rules to existing memory instructions and retains MSIZE semantics; it allocates no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No opcode number or new instruction semantics are present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, address and transaction limits (lines 55-59)",
"source": "eip.md",
"summary": "Existing memory operations now exceptionally halt for out-of-range addresses or when transaction-wide allocated pages exceed 16384; these are behavior changes beyond gas repricing."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least one pre-existing memory-using opcode gains new non-gas exceptional-halt behavior, meeting the rubric binary score of 3.",
"score": 3,
"uncertainty_note": "The exact affected instruction set and boundary convention are underspecified, but the existence of modified behavior is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "No precompile address, input contract, or gas schedule is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "The proposal contains no precompile mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 49-59)",
"source": "eip.md",
"summary": "Generic EVM memory charging changes, but no pre-existing precompile logic or precompile gas schedule is modified."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Call-site memory expansion is not a modification to a precompile itself under this anchor.",
"score": 0,
"uncertainty_note": "No precompile is named in the sealed evidence.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "The proposal changes runtime memory accounting without altering transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface-level encoding change is introduced.",
"score": 0,
"uncertainty_note": "No encoding format appears in the normative change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Specification (lines 1-10, 39-59)",
"source": "eip.md",
"summary": "This Core EVM memory proposal defines no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "No transaction-type identifier or fields are specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 49-59)",
"source": "eip.md",
"summary": "The new limits produce exceptional halts during EVM execution; they do not change transaction validity or intrinsic gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Runtime memory failure is distinct from transaction admission validity under this anchor.",
"score": 0,
"uncertainty_note": "No transaction validation rule is stated.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (lines 39-59)",
"source": "eip.md",
"summary": "All new values are constants or per-execution accounting; no block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "The proposal does not alter block structure.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Reference Implementation, transaction context (lines 39-59, 313-325)",
"source": "eip.md",
"summary": "The proposal has no activation-block state transition; the example merely initializes a new per-transaction page counter to zero."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No existing state or internal variable is modified specially at the activation block, and initialization of a new variable is excluded by the rubric.",
"score": 0,
"uncertainty_note": "Fork-choice or activation plumbing is expressly absent from the reference implementation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, implementation approaches, and Rationale (lines 17-37, 61-87)",
"source": "eip.md",
"summary": "The proposal replaces contiguous growth with sparse pages or a 4 GiB virtual mapping, tracks page sets, cites allocation/cache/TLB benchmarks, and permits up to 64 MiB across active calls."
},
{
"locator": "Security Considerations (lines 328-338)",
"source": "eip.md",
"summary": "The EIP explicitly requires maximum-memory analysis and evaluates recursive calls allocating memory across the call stack."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Core memory behavior, OS allocation strategy, page tracking, and nested-call resource limits have substantial and complex interactions with existing execution performance that cannot be validated by isolated microbenchmarks alone.",
"score": 3,
"uncertainty_note": "Only selected microbenchmarks and a rough maximum-memory comparison are supplied; no end-to-end workload results are in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations (lines 328-338)",
"source": "eip.md",
"summary": "The proposal identifies compatibility changes for contracts that used to run out of gas and asks whether the new model enables client memory-based denial of service."
},
{
"locator": "Specification (lines 49-59)",
"source": "eip.md",
"summary": "Security-sensitive controls span per-call page pricing, a 32-bit address cap, and a transaction-global page limit."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Gas metering, memory allocation, exceptional halts, and nested message calls are critical interacting components; incorrect implementation could enable resource exhaustion or consensus-divergent execution and warrants extensive review and fuzzing.",
"score": 3,
"uncertainty_note": "The EIP provides only a coarse maximum-memory comparison and does not resolve the detailed limit semantics needed for a complete security analysis.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and empty Test Cases section (lines 49-59, 93-94)",
"source": "eip.md",
"summary": "The normative text uses \"page touched\" and \"pages allocated in a transaction\" without defining exact touch ranges, lifetime/counting, failure ordering, or boundary cases, and supplies no tests."
},
{
"locator": "Reference Implementation (lines 136-159, 185-200, 242-312)",
"source": "eip.md",
"summary": "The example makes particular choices about zero size, inclusive end pages, restoring child page counts, and an end-address comparison that are not all stated normatively and includes an incomplete allocated-pages assertion."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Exact per-page touch history was not previously a consensus-visible gas dimension, but now determines charges and halts. The unresolved definitions therefore make previously unobservable details consensus-critical and require re-baselining as the draft is clarified.",
"score": 3,
"uncertainty_note": "The package prohibits discussion-thread, implementation, devnet, and later-revision evidence, so the score is based solely on the material gaps visible in the sealed Draft text.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation (line 22) and Rationale (lines 78-82)",
"source": "eip.md",
"summary": "The proposal explicitly frames total memory through recursive message calls under EIP-150 gas forwarding and makes the new memory limit transaction-global rather than call-local."
},
{
"locator": "Specification, all-but-one-64th call gas rule",
"source": "supporting/eip-150.md",
"summary": "EIP-150 computes forwarded call gas after subtracting call cost and memory expansion, directly coupling the replaced memory charge to nested-call gas availability."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
150
],
"rationale": "EIP-7923 modifies the memory-expansion term used around EIP-150 call gas forwarding and adds a limit spanning nested calls, requiring coordinated but limited cross-EIP gas and call-depth tests.",
"score": 2,
"uncertainty_note": "EIP-150 is the only numbered interaction established by the package; no other EIPs are inferred.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7923,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7923:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The phrase \"maximum byte touched ... rounded up by 32\" for MSIZE can be read as inclusive-byte or exclusive-end accounting, although the example uses ceil32(start + size).",
"The example restores transaction_context.num_pages after a child computation, a lifetime rule absent from the normative transaction-global limit text.",
"The example checks start_position + size >= 2**32 only in the write path, which does not cleanly match the normative allowance of addresses through 2**32 - 1.",
"The normative phrase \"all memory instructions\" gives examples but no exhaustive list or per-instruction touched ranges."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "38077cfd67bac06d3ccf95979440d99d8eb9218da855a68a097bfb8084677844",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7923.md",
"git_blob_sha": "474d96e62f5962ce6098f83dda4cd3b4a6106c98",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7923.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7923.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7923.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7923.yaml",
"sha256": "c9a7a0db1b1a6acdd254057a167736a430c47cfac665d0b5185a256d0a531540"
},
"supporting_documents": [
"supporting/eip-150.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 23,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Draft execution-layer assessment of EIP-7923 at the sealed Hegota PFI snapshot: replacement of quadratic EVM memory expansion pricing with per-message-call page charging, 32-bit addressing, and a transaction-global 64 MiB allocated-page limit.",
"tier": "high",
"title": "Linear, Page-Based Memory Costing",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 23,
"minimum": 21
},
"present": true,
"summary": "The Draft does not normatively define what each memory instruction touches, whether the transaction-global count is cumulative or the simultaneously live allocation restored after child calls, whether free page 0 counts toward the cap, or the precise address/size and failure-order rules. The example selects some behaviors but is internally incomplete and does not consistently specify all bounds.",
"unresolved_questions": [
"For every affected instruction, which source and destination byte ranges count as touching a page, especially for zero length, range overflow, and multi-range copy operations?",
"Does the 16384-page transaction limit count cumulative first allocations or pages simultaneously live across the active message-call stack, and exactly when are child pages released on success or revert?",
"Does free page 0 count toward the transaction limit, and is it considered already touched for MSIZE or only for charging?",
"Is the 32-bit rule applied to the start operand, every byte in the accessed range, or the exclusive end, and what exception takes precedence over page gas charging or the global limit?"
]
}
},
"hegota:7979:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > CALLSUB; Specification > CALLDEST; Specification > RETURNSUB",
"source": "eip.md",
"summary": "The three instructions have fixed costs of mid (8), jumpdest (1), and low (5)."
},
{
"locator": "Reference Implementation > The three new instructions",
"source": "eip.md",
"summary": "Each new handler charges an existing GAS_MID, GAS_JUMPDEST, or GAS_LOW constant."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The opcode gas schedule is extended, but charging uses the existing fixed execution-gas mechanism and existing cost constants; no new metering mechanism is introduced.",
"score": 1,
"uncertainty_note": "The EIP says cost balance needs benchmarking, but the accounting form and proposed values are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The instructions manipulate only the data stack, return stack, and program counter."
},
{
"locator": "Reference Implementation > The three new instructions",
"source": "eip.md",
"summary": "The reference handlers contain no account, storage, or other state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode adds, moves, or reorders a state access or a gas charge relative to state access.",
"score": 0,
"uncertainty_note": "None; the specified execution steps contain no state-access surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal is limited to three EVM control-flow instructions and their machine-state behavior."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas rule or blob-related mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None; blobs are outside the proposal's stated and normative scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Reference Implementation > The three new instructions",
"source": "eip.md",
"summary": "The new operations change control flow and private machine state but do not write persistent state."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "There is no state-gas charging site, state-byte rate, budget, reservoir, or spill-path change.",
"score": 0,
"uncertainty_note": "None; persistent-state writes and state-gas accounting are absent.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Costs; Reference Implementation > The three new instructions",
"source": "eip.md",
"summary": "The proposal specifies only positive fixed gas charges for the three instructions."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No refund mechanism or interaction with existing refunds is specified.",
"score": 0,
"uncertainty_note": "None; the gas provisions contain no refund behavior.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP says existing EVM code semantics do not change, subject to unspecified behavior."
},
{
"locator": "Test Cases > introductory note",
"source": "eip.md",
"summary": "Tests use placeholder bytes 0xB0-0xB2 because final opcode assignments are not confirmed."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The change should affect only a minor fork-specific subset of existing invalid-opcode and destination-validation vectors once opcode bytes are allocated; the EIP does not indicate broad reworking of diverse existing tests.",
"score": 1,
"uncertainty_note": "The exact pre-existing vectors affected cannot be identified until the opcode bytes are assigned.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Notes",
"source": "eip.md",
"summary": "The return stack's actual state is not observable by EVM code and is stated not to be consensus-critical."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP states that existing EVM code semantics are unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to this EIP do not gain a new consensus-visible value or invariant to assert.",
"score": 0,
"uncertainty_note": "None; internal return-stack representation is explicitly excluded from consensus observability.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Reference Implementation",
"source": "eip.md",
"summary": "All specified inputs and effects are internal to EVM bytecode execution and machine state."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool input, output, field, or fork-activation awareness mechanism is specified.",
"score": 0,
"uncertainty_note": "None; the package contains no transition-tool interface change.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The supplied cases are expressed as bytecode, execution traces, gas totals, and success or exceptional-halt outcomes."
},
{
"locator": "Specification > Notes",
"source": "eip.md",
"summary": "The return stack representation itself is not consensus-critical or EVM-observable."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The specified behavior can be tested with existing bytecode execution, gas, and failure expectations; no new framework abstraction is required by the text.",
"score": 0,
"uncertainty_note": "No test-framework source is in the package; the score follows the behavioral form of the included tests.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal adds control-flow labels, calls, returns, and a private return stack only."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic primitive or cryptographic functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "None; cryptography is absent from the normative mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > CALLSUB; Specification > RETURNSUB",
"source": "eip.md",
"summary": "Exceptional halts cover non-CALLDEST targets, return-stack depth 1024, and an empty return stack."
},
{
"locator": "Test Cases > Failure 1; Failure 2; Subroutine at end of code",
"source": "eip.md",
"summary": "Cases exercise an out-of-range target, return underflow, and return to the implicit STOP just past code."
},
{
"locator": "Rationale > Why may JUMP land on a CALLDEST?",
"source": "eip.md",
"summary": "Tail calls, mutual recursion, and jumps entering subroutines create distinct return-stack control-flow paths."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "There are multiple boundary-prone mechanisms, and the 1024-depth limit plus mixed CALLSUB/JUMP/JUMPI/RETURNSUB paths requires an elevated set of depth, destination, and exceptional-halt cases.",
"score": 3,
"uncertainty_note": "The exact opcode bytes are open, but that does not reduce the stated semantic boundary set.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The entire normative change is inside EVM instruction execution."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP field or block-validation rule requiring sync testing is introduced.",
"score": 0,
"uncertainty_note": "None; block encoding and syncing are outside the specified scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification adds EVM machine state and opcodes without any engine communication field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "None; the Engine API is not part of the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal introduces instructions and private per-execution machine state, not deployed code."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None; no contract address, code, state, or system action is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal states that existing EVM code semantics are unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system contract code or state is directly or indirectly modified by the specified mechanism.",
"score": 0,
"uncertainty_note": "None; system contracts are not identified or targeted.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "CALLSUB, CALLDEST, and RETURNSUB are three new instructions."
},
{
"locator": "Specification > CALLSUB; Specification > RETURNSUB",
"source": "eip.md",
"summary": "CALLSUB consumes a dynamic data-stack destination and pushes a bounded private return stack; RETURNSUB pops that separate stack into PC."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Multiple opcodes are added and at least CALLSUB and RETURNSUB have nontrivial cross-stack/control-flow mechanics, satisfying score 3.",
"score": 3,
"uncertainty_note": "Opcode numbers are TBD, but the count and semantic complexity of the instructions are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > CALLDEST",
"source": "eip.md",
"summary": "CALLDEST is declared a valid destination for the existing JUMP and JUMPI opcodes."
},
{
"locator": "Reference Implementation > get_valid_destinations; final paragraph",
"source": "eip.md",
"summary": "Destination analysis adds every CALLDEST to valid jump destinations, changing the set consumed by JUMP and JUMPI even though their handlers need no edit."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The observable destination-validity behavior of pre-existing JUMP and JUMPI is modified, so the rubric's binary score 3 applies.",
"score": 3,
"uncertainty_note": "The implementation location of the change is destination analysis rather than the opcode handlers, but the opcode result is still changed.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "Only EVM instructions are added."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None; precompiles are absent from the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The change is confined to new control-flow instructions and does not alter existing EVM code semantics."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "None; no precompile is identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Why no immediate arguments or code sections?",
"source": "eip.md",
"summary": "The design deliberately avoids immediate arguments and code sections that would increase instruction-encoding complexity."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "No transaction, block, or interface encoding is changed."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Assigning opcode bytes is not an RLP/SSZ transaction, block, or interface encoding change under this anchor.",
"score": 0,
"uncertainty_note": "Final opcode byte values are open, but they do not create an encoding change in the anchor's stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal changes EVM instruction execution only."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None; transactions are outside the normative change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The rules concern execution of three bytecode instructions and claim no change to existing EVM code semantics."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic gas calculation is added or modified.",
"score": 0,
"uncertainty_note": "None; instruction exceptional halts are execution results, not transaction-validity changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The only new field is an internal EVM return stack."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "None; the return stack is machine state, not a block field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal adds instruction semantics and new per-execution machine state without prescribing activation-block mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state or existing internal variable is modified specifically at the fork-activation block.",
"score": 0,
"uncertainty_note": "Return-stack initialization is under-specified, but initialization of a new internal variable is excluded by this rubric anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Costs",
"source": "eip.md",
"summary": "The EIP explicitly says benchmarking is needed to determine whether the three fixed costs are balanced."
},
{
"locator": "Rationale > Are there real-time performance gains?",
"source": "eip.md",
"summary": "Performance claims are framed around control-flow workloads and compiler/interpreter execution paths."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new opcode paths and return-stack operations require validation, but they can be benchmarked in isolation and existing bytecode behavior is stated unchanged.",
"score": 1,
"uncertainty_note": "The EIP cites asset benchmarks, but no supporting asset is allowlisted in this package; only the text's need for benchmarking is used.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Safety depends on return-address isolation plus runtime checks for destination validity, underflow, and overflow."
},
{
"locator": "Reference Implementation > get_valid_destinations; The three new instructions",
"source": "eip.md",
"summary": "The mechanism interacts with code scanning, data-stack popping, gas charging, PC changes, exceptional halts, and the new return stack."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches a limited set of existing but security-sensitive EVM control-flow components and changes destination-validity assumptions, so it warrants targeted review and fuzzing rather than isolated validation alone.",
"score": 2,
"uncertainty_note": "The EIP describes safety checks but provides no allowlisted implementation or fuzzing evidence.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Notes",
"source": "eip.md",
"summary": "Opcode values are explicitly still to be determined."
},
{
"locator": "Test Cases > introductory note",
"source": "eip.md",
"summary": "All bytecode tests use placeholder opcode assignments that must be confirmed."
},
{
"locator": "Specification > opening paragraphs; Reference Implementation > Evm field addition",
"source": "eip.md",
"summary": "A return stack is added to EVM machine state, but its required initialization and lifetime boundaries are not stated explicitly."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Canonical bytecode vectors cannot be baselined until clients agree on opcode assignments, and return-stack initialization/lifetime needs a localized consensus reading. These are localized agreements, not a broad redefinition of previously unobservable behavior.",
"score": 2,
"uncertainty_note": "Implementation, devnet, and discussion status are unavailable by package policy, so this score uses the snapshot text alone.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP says the change does not preclude EOF, RISC-V, or other changes."
},
{
"locator": "Rationale > Why no immediate arguments or code sections?",
"source": "eip.md",
"summary": "EVM Object Format is discussed as a complementary design comparison, not as a dependency, modification, or conflict."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The normative proposal is self-contained; named design comparisons and statements of non-preclusion do not establish a coordinated cross-EIP testing dependency.",
"score": 0,
"uncertainty_note": "No interacting EIP number or normative dependency is identified in the package.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7979,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:7979:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The prose defines PC as the index of the next byte to execute while the algorithms and traces use PC as the current instruction position; the observable return target PC+1 is nevertheless clear from the tests.",
"The EIP calls the change backwards compatible while final opcode allocation—and therefore the exact pre-existing opcode-recognition vectors affected—remains unknown."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "377407cd734259c8065e2a95ff4e3bf70f35f534084e05cf6fb873596064941b",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7979.md",
"git_blob_sha": "1276ae53548fe920c37b52260285e6bb4fd1e1aa",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-7979.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-7979.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7979.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-7979.yaml",
"sha256": "a72e886bb5d2c7b0daa82625e643c18562313fe6a20fed93b5bc4b40e4f8c353"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 16,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Draft EIP-7979 execution-layer snapshot introducing CALLSUB, CALLDEST, and RETURNSUB, a bounded separate return stack, fixed opcode gas costs, and CALLDEST as a valid JUMP/JUMPI target. Opcode byte assignments remain undetermined. The assessment uses only package/eip.md and package/rubric.md.",
"tier": "medium",
"title": "Call and Return Opcodes for the EVM",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 16,
"minimum": 14
},
"present": true,
"summary": "Final opcode byte assignments are absent, and the required initialization and lifetime boundaries of the return stack are not explicit. These gaps are material to canonical vectors and client agreement but localized to opcode/test baselining and return-stack semantics.",
"unresolved_questions": [
"Which byte values are assigned to CALLSUB, CALLDEST, and RETURNSUB?",
"Must each EVM machine instance initialize an empty return stack, and what are its exact lifetime boundaries across nested executions?"
]
}
},
"hegota:8025:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "The guest invokes the normal payload-validation and block-execution path against witness-backed state."
},
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The optional mechanism is stated not to change consensus validity rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal proves and replays existing execution rules; it specifies no new or modified EVM gas-accounting rule.",
"score": 0,
"uncertainty_note": "No gas schedule or gas-charging site is introduced in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Host-side input construction",
"source": "eip.md",
"summary": "Witness construction consumes data gathered by the existing block-level read/write tracker used for BAL construction."
},
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "The guest uses the normal execution path with WitnessState replacing the pre-state database."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "EIP-8025 observes existing accesses to build a witness and substitutes a state backend; it does not move gas checks or state accesses inside any opcode.",
"score": 0,
"uncertainty_note": "Ordering requirements belonging to EIP-7928 are a dependency interaction, not a change made by EIP-8025.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "NewPayloadRequest carries existing blob versioned hashes and the payload carries existing blob gas fields."
},
{
"locator": "Specification > Gas accounting",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 defines the blob-gas mechanism that EIP-8025's guest validates."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Blob data and accounting fields are inputs to stateless validation, but EIP-8025 does not alter their accounting mechanism.",
"score": 0,
"uncertainty_note": "None; the blob mechanism is consumed unchanged.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution-layer changes are a stateless guest and prover-side guest-input construction."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas cost, state-byte rate, state-gas budget, reservoir, or spill path is introduced or modified.",
"score": 0,
"uncertainty_note": "Witness construction changes data availability for execution, not the cost of writing state.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "Payload execution follows the normal execution-engine path without a new refund operation."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None; refunds are not changed or newly exposed by the proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The feature is fully opt-in, changes no consensus validity rules, and leaves non-participating nodes unchanged."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The proposal points to dedicated execution-layer conformance tests."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The package supports adding a dedicated stateless-validation suite, but does not require existing execution tests to be reworked.",
"score": 0,
"uncertainty_note": "The package does not describe how much of an existing payload corpus would be reused by the new guest suite.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Nodes outside the optional modes have unchanged behavior and duties."
},
{
"locator": "Rationale > Build operational experience",
"source": "eip.md",
"summary": "Proofs are non-critical artifacts and are not placed on the fork-choice or attestation path."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing tests need not additionally assert a proof, witness, or stateless result; those outputs belong to the opt-in feature's own tests.",
"score": 0,
"uncertainty_note": "None material for pre-existing tests in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "The proposal defines a separate guest input/output interface rather than a transition-tool field."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "No transition-tool interface addition is specified."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The new stateless guest is a separate mechanism; the package does not require a field or mechanism in the state transition tool interface.",
"score": 0,
"uncertainty_note": "A test implementation could choose to expose the guest through a transition tool, but that interface is not specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "Tests must construct a new StatelessInput and check a new StatelessValidationResult."
},
{
"locator": "Specification > Execution Layer > SSZ encoding",
"source": "eip.md",
"summary": "Inputs require schema-prefixed SSZ and progressive-container/list serialization with fixed subordinate bounds."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Reusable EIP-specific primitives are needed to assemble witnesses and payload requests, serialize the guest input, run it, and assert structured success or sentinel-failure output.",
"score": 2,
"uncertainty_note": "The package does not specify whether these helpers are framework expectations/modifiers or a standalone runner.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Terminology",
"source": "eip.md",
"summary": "A proof system proves guest computation and may vary in proof format, verifier logic, cost, and security assumptions."
},
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution result is accepted only after proof verification and binding to the expected guest, request root, chain, and schema."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Proving full stateless payload validation is one novel cryptographic mechanism, while the concrete proof system is deliberately not fixed; this fits the single-novel-mechanism anchor.",
"score": 2,
"uncertainty_note": "Concrete proof systems and their testing resources are not identified, so the eventual mechanism count may differ.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "Cases include decode failure sentinels, bounded and contiguous ancestor headers, missing witness data, invalid payloads, and transaction-key verification."
},
{
"locator": "Specification > Execution Layer > Host-side input construction",
"source": "eip.md",
"summary": "Witness creation must capture reads, writes, code, ancestors, and sibling trie nodes while reproducing the expected post-state root."
},
{
"locator": "Specification > Execution Layer > SSZ encoding",
"source": "eip.md",
"summary": "Schema IDs, progressive collections, and several fixed byte/header bounds add serialization boundaries."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms compose across malformed schemas, empty or non-contiguous header witnesses, trie-node completeness, code and public-key lists, invalid execution, fork selection, and post-state reconstruction. Witness completeness across arbitrary blocks requires an elevated case count.",
"score": 3,
"uncertainty_note": "Concrete proof-format boundaries remain unknown and are not added to this score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution-layer surface adds guest validation and witness construction, not block RLP validation."
},
{
"locator": "Specification > Consensus Layer > Req/resp domain",
"source": "eip.md",
"summary": "Proof backfill and synchronization protocols are specified on the consensus layer."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No execution block-RLP validation mechanism is added. The proposal's explicit proof-sync protocols are consensus-layer behavior and are excluded from this execution-only score.",
"score": 0,
"uncertainty_note": "None; the cross-layer boundary is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "The host consumes NewPayloadRequest as payload data supplied by the consensus layer."
},
{
"locator": "Specification > Consensus Layer > Proof engine interface",
"source": "eip.md",
"summary": "ProofEngine is a separate interface merely modeled on the Engine API."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "EIP-8025 consumes the dependency-defined NewPayloadRequest and adds a distinct proof-engine protocol; it specifies no new Engine API field, endpoint, or communication mechanism.",
"score": 0,
"uncertainty_note": "Any transport mapping between an EL host and proof node is implementation-dependent and not an Engine API change in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution-layer additions are off-chain host/guest and witness components."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced by EIP-8025.",
"score": 0,
"uncertainty_note": "System contracts from required EIPs remain dependency interactions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Stateless input and output > ExecutionWitness",
"source": "eip.md",
"summary": "Ancestor headers let the guest reproduce recent block hashes and existing system-contract logic."
},
{
"locator": "Specification > Execution Layer > Host-side input construction",
"source": "eip.md",
"summary": "The witness records existing state accesses rather than changing contract behavior or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Existing system-contract execution must be witnessed, but no contract code, state transition, or behavior is modified directly or indirectly.",
"score": 0,
"uncertainty_note": "None; observability for proving is not a behavioral modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "The guest reuses ordinary block execution and introduces no instruction definition."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "Existing execution is run against WitnessState without specifying any changed opcode result."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "State-backend substitution must preserve opcode behavior and is tested as equivalence, not scored as a modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The specified components do not include a precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "Proof verification is delegated to a proof node and is not exposed as an EVM precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "The normal payload path is replayed without a precompile logic or gas-schedule change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > SSZ encoding",
"source": "eip.md",
"summary": "A new host/guest interface serializes StatelessInput as a two-byte schema ID followed by SSZ and serializes a structured SSZ result."
},
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "The public payload-request commitment is an SSZ hash-tree-root binding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal introduces a new schema-versioned SSZ encoding at the execution host/guest interface, satisfying the rubric's binary interface-level encoding anchor.",
"score": 3,
"uncertainty_note": "This is a new proof-stack interface encoding, not a replacement of transaction or block RLP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "Existing serialized transactions are carried inside ExecutionPayload; no transaction envelope is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "The guest uses the normal new-payload path and verifies supplied public keys against the existing transaction signatures."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Supplied public keys are an optimization input that must reproduce existing signature recovery; transaction validity and intrinsic-gas rules are unchanged.",
"score": 0,
"uncertainty_note": "The new guest needs equivalence tests, but it does not create a new transaction-validity rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "StatelessInput packages an existing NewPayloadRequest, witness, chain ID, and public keys without defining a new canonical block/header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "EIP-8025 adds proof-stack input fields, not a field to the canonical execution block or header.",
"score": 0,
"uncertainty_note": "Payload fields originating in required EIPs are scored as interactions, not as fields introduced by EIP-8025.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "Production guests must compare the payload timestamp with fork activation data, while the reference shape uses one implementation per fork."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Selecting and checking fork rules in the guest does not modify state or an existing internal variable at the activation block; no activation transition is introduced.",
"score": 0,
"uncertainty_note": "The exact production fork-configuration input and comparison are under-specified, but initialization or selection is not a score-3 modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Host-side input construction",
"source": "eip.md",
"summary": "Witness construction is coupled to block execution, trie data, code reads, ancestor headers, and post-state-root reconstruction."
},
{
"locator": "Security Considerations > Verifier-prover decentralisation asymmetry",
"source": "eip.md",
"summary": "Provers retain full EL state and run a non-trivial stack whose cost scales as O(n log^2 n) in witnessed computation size."
},
{
"locator": "Rationale > Build operational experience",
"source": "eip.md",
"summary": "Proof size, generation latency, verifier throughput, and prover diversity require live operational measurement."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Proving performance cannot be fully isolated from payload execution, state/trie access, witness shape, and proof-system choice, and the proposal identifies a substantial, superlinear proving burden with complex interactions.",
"score": 3,
"uncertainty_note": "Concrete proof systems are unpinned, so exact resource envelopes remain unknown.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "Acceptance binds proof verification to the guest program, successful result, payload-request root, chain ID, and schema ID."
},
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "Security-sensitive logic covers witness-backed state, state-root recomputation, fork rules, payload validity, and transaction-signature/public-key equivalence."
},
{
"locator": "Security Considerations > Soundness and consensus implications",
"source": "eip.md",
"summary": "Proof results remain supplementary and cannot alter fork choice or consensus state in this optional phase."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Soundness and binding interact with several critical execution components and require targeted review and fuzzing, but the optional design preserves ordinary re-execution and bounds failure to an opted-in node's local signal.",
"score": 2,
"uncertainty_note": "Security assumptions of the concrete proof systems are not specified; load-bearing proof use is explicitly outside this EIP.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Consensus Layer > Proof types and containers",
"source": "eip.md",
"summary": "ProofType values and new proof systems are socialized out of band, with proof-system support configured dynamically."
},
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "Verification expects an exact guest plus request-root, chain, and schema binding, but no concrete proof-system/guest registry is defined."
},
{
"locator": "Specification > Execution Layer > Guest validation",
"source": "eip.md",
"summary": "Production implementations must add a fork-activation timestamp comparison whose exact configuration path is not specified."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Interoperable execution-proof tests require localized agreement on proof-type to guest/verifier dispatch, public-input binding, and production fork selection. These are open but do not make previously unobservable EVM behavior consensus-critical in this optional phase.",
"score": 2,
"uncertainty_note": "The consensus-layer threshold k is also open, but is excluded from this execution-layer score.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter > requires",
"source": "eip.md",
"summary": "The proposal explicitly requires EIPs 4844, 6110, 7002, 7251, 7688, 7732, 7928, and 8282."
},
{
"locator": "Specification > Execution Layer > Stateless input and output",
"source": "eip.md",
"summary": "NewPayloadRequest and its SSZ commitment combine blob hashes, three established request families, two builder request families, progressive SSZ, delayed execution context, and the BAL."
},
{
"locator": "Specification > Execution Layer > Host-side input construction",
"source": "eip.md",
"summary": "Witness generation reuses the BAL tracker and must cover request-driven system actions and fork-specific payload execution."
}
],
"exceptional_score_justification": "Score 4 is mechanically required by the uncapped anchor: eight interacting EIPs produce base 3 plus floor((8 - 3) / 3) = 1, and each changes a distinct input, schema, timing, or witness axis requiring coordinated cases.",
"id": "cross_eip_interactions",
"interacting_eips": [
4844,
6110,
7002,
7251,
7688,
7732,
7928,
8282
],
"rationale": "There are strong coordinated interactions with 4844 (blob hashes and blob fields), 6110 (deposits), 7002 (withdrawals), 7251 (consolidations), 7688 (progressive SSZ), 7732 (delayed execution-validation window and payload context), 7928 (BAL and access tracker), and 8282 (builder requests). The uncapped rule gives base score 3 for strong multi-EIP interdependence plus 1 for the first complete group of three among the five interactions beyond the first three.",
"score": 4,
"uncertainty_note": "All eight interactions are explicit in the sealed package; no unidentified interaction is added.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8025,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8025:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The abstract describes proof verification as a path that decouples verification from re-execution, while the current optional phase explicitly requires proof-verifying nodes to continue re-executing and treats proofs only as a supplementary signal; this assessment uses the normative optional-phase behavior.",
"PublicInput is shown with chain_config, while the execution guest's public result exposes chain_id and schema_id; the exact cross-component binding is not fully spelled out in the EIP text.",
"Consensus networking and proof retention are substantial but intentionally do not contribute to execution-layer anchors such as block syncing or Engine API changes."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "d6131d778d8903a30c2c0e432b6fae70d25aa8f77a6fb65812237946da4c94b2",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8025.md",
"git_blob_sha": "6287bacd18648daa53c955f5d4674b045b364128",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8025.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8025.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8025.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8025.yaml",
"sha256": "95df960b863bb12426648f4b229864c0b0e8ae0879de453bd699c09f8666951d"
},
"supporting_documents": [
"supporting/eip-4844.md",
"supporting/eip-6110.md",
"supporting/eip-7002.md",
"supporting/eip-7251.md",
"supporting/eip-7688.md",
"supporting/eip-7732.md",
"supporting/eip-7928.md",
"supporting/eip-8282.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 21,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Assessment of the execution-layer surface only: the stateless execution guest, witness construction, schema-prefixed SSZ input/output, payload-request binding, and proof-generation/verification implications. Consensus-layer gossip, req/resp, discovery, beacon-state processing, and fork-choice behavior are boundary context and are not scored as execution-layer complexity.",
"tier": "medium",
"title": "Optional Execution Proofs",
"under_specification": {
"affected_criteria": [
"transition_tool_interface_changes",
"new_test_framework_primitives",
"cryptography",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 25,
"minimum": 17
},
"present": true,
"summary": "Material execution-layer details remain open: concrete proof systems and ProofType-to-guest/verifier dispatch, the exact adaptation between the proof's chain configuration and the guest's chain/schema output, production fork-rule selection, and the conformance-runner interface. The separate consensus-layer threshold k is also open but is not used to score the execution surface.",
"unresolved_questions": [
"Which concrete proof systems and ProofType values are supported, and how is each value bound to an exact guest program and verifier?",
"How is PublicInput.chain_config mapped to or checked against the execution guest's chain_id and schema_id result?",
"What fork-activation data is supplied to a production guest, and what exact timestamp/fork-selection failures must it return?",
"Is the stateless guest exercised through a new transition-tool mechanism or a standalone conformance runner, and what reusable expectations are required?",
"What value of k defines proof verification on the consensus side, noting that this does not affect the execution-layer score?"
]
}
},
"hegota:8077:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal expressly states that it does not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The wire-protocol announcement extension introduces no EVM gas-accounting rule.",
"score": 0,
"uncertainty_note": "No EVM gas surface is described anywhere in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "The only normative data change is to an eth peer-to-peer message."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode execution or ordering of state access relative to gas charging changes.",
"score": 0,
"uncertainty_note": "The proposal has no opcode-execution surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal states that EVM consensus rules are unchanged and no hard fork is required."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The announcement metadata does not alter blob-gas accounting.",
"score": 0,
"uncertainty_note": "Blob transactions are discussed only as a propagation-design alternative, not as a gas change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "The specification adds source and nonce arrays to a networking message."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-write charge, state-gas budget, reservoir, or spill rule changes.",
"score": 0,
"uncertainty_note": "The proposal's use of current chain state for filtering is non-normative and does not alter state gas.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal expressly leaves EVM consensus rules unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "There is no gas-refund behavior in the execution-client networking change.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "The existing 0x08 message gains two parallel arrays in the new eth protocol version."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "A mismatch between any announced tuple field and a fetched transaction becomes a protocol violation."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Message-specific encoding and invalid-announcement tests need a version-aware expected shape and mismatch cases, but the impact is confined to a minor subset of eth protocol tests.",
"score": 1,
"uncertainty_note": "The package contains no test inventory, so the exact number of pre-existing message tests is unknown.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Older clients and the previous protocol version remain usable while the new version is rolled out."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to the new announcement version are not required to assert a new fork-wide output.",
"score": 0,
"uncertainty_note": "New message-specific assertions belong to this EIP's tests, not to every pre-existing test.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification is limited to the eth NewPooledTransactionHashes message and its handling."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No state-transition-tool field or mechanism is added.",
"score": 0,
"uncertainty_note": "The proposal requires no hard fork and describes no block transition input.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "The added values use fixed-byte, scalar, and list forms in the existing message notation."
},
{
"locator": "Specification",
"source": "supporting/eip-7642.md",
"summary": "The eth/69 baseline already specifies peer messages with fixed-byte, scalar, and list encodings."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing wire-message encoding and assertion primitives suffice; no new reusable test abstraction is required by the text.",
"score": 0,
"uncertainty_note": "The package gives no test-framework implementation, but the specification introduces no novel expectation type.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "A received transaction's existing hash verification exposes a metadata mismatch after fetching."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Source and nonce are announced metadata; the proposal introduces or modifies no cryptographic mechanism.",
"score": 0,
"uncertainty_note": "An alternative involving a signed RBF version is explicitly not the proposed design.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "Each announcement is represented by five positionally associated arrays, including fixed-size source and variable-size nonce values."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Source and nonce remain unverifiable until fetch, and any tuple mismatch must be treated as a protocol violation."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple edge-prone mechanisms are present: cardinality and positional correlation across five arrays, value-size boundaries, and deferred match-versus-mismatch verification across the full tuple. Malformed cardinalities and per-field mismatch combinations produce an elevated case matrix.",
"score": 3,
"uncertainty_note": "The text does not define malformed-list handling, so the exact boundary matrix cannot yet be baselined.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The changed message announces pooled transaction metadata, not blocks or receipts."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation or client block-sync mechanism is modified.",
"score": 0,
"uncertainty_note": "Transaction fetching from the mempool is distinct from the rubric's block-syncing surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal extends a devp2p eth protocol message."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API endpoint, field, or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "The execution-layer surface is peer-to-peer networking only.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal makes no EVM consensus change and needs no hard fork."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "No contract code, address, state, or system action appears in the specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Normative changes are confined to an eth networking message and its handling."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "The proposed scheduling improvements are mempool behaviors, not system-contract effects.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal expressly leaves EVM consensus rules unchanged."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No EVM instruction is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal expressly leaves EVM consensus rules unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "The specification has no opcode surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The sole specified data change is to NewPooledTransactionHashes."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "No precompile address, input, output, or gas rule is described.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "EVM consensus rules remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas accounting is modified.",
"score": 0,
"uncertainty_note": "The proposal is isolated to peer announcement encoding and handling.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "The 0x08 interface encoding changes from three components in eth/69 to five components in eth/XX by adding source and nonce arrays."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The rubric's binary high anchor applies because an interface-level wire encoding is changed.",
"score": 3,
"uncertainty_note": "The numeric eth/XX version is unset, but the specified interface encoding change itself is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "Existing transaction announcements gain metadata while retaining the existing transaction-type vector."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "The proposal applies to announcements and explicitly does not restrict itself to one existing transaction category.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "A metadata mismatch is a peer-protocol violation discovered after the transaction hash is verified."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "EVM consensus rules remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Announcement validity and peer handling change, but transaction validity rules and intrinsic gas do not.",
"score": 0,
"uncertainty_note": "The protocol-violation rule must not be conflated with consensus transaction validity.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Source and nonce are added to a pooled-transaction announcement message."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "The message's transaction metadata is not block data.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The change rolls out through a new wire-protocol version and does not require a hard fork."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state or internal variable is modified at a fork-activation block.",
"score": 0,
"uncertainty_note": "Protocol-version negotiation replaces any fork-block activation surface.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale > Overhead",
"source": "eip.md",
"summary": "The proposal calls the added B_20 and variable-size field overhead significant and leaves quantitative details TBD."
},
{
"locator": "Rationale > Alternatives",
"source": "eip.md",
"summary": "Bandwidth depends on peer fanout, announcement redundancy, push-versus-pull selection, and optional detailed-announcement strategies."
},
{
"locator": "Specification > Changes to message handling",
"source": "eip.md",
"summary": "Implementations may revisit eager-push versus announcement selection because announcements become larger."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "End-to-end benefit and cost cannot be fully benchmarked in isolation: every detailed announcement is larger, while traffic and fetching outcomes interact with peer fanout, redundant announcements, scheduling, and the push/announcement threshold. The text itself characterizes the overhead as significant.",
"score": 3,
"uncertainty_note": "Quantitative overhead is explicitly TBD and receiver scheduling and sender thresholds are not mandated.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Recipients cannot verify source and nonce until fetching the transaction, must not trust them, and may treat a mismatch as a peer protocol violation."
},
{
"locator": "Specification > Changes to message handling",
"source": "eip.md",
"summary": "Receivers may use the unverified metadata for transaction-fetch scheduling decisions."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The new unverified metadata crosses into fetch scheduling and peer-violation handling, altering assumptions in a limited set of networking components and warranting targeted malformed-message and mismatch review.",
"score": 2,
"uncertainty_note": "The text says the protocol is not compromised, but it does not mandate the exact peer response or scheduling safeguards.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter and Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "The proposal remains Draft, names the new protocol eth/XX, and specifies five parallel vectors without malformed-cardinality rules."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "A tuple mismatch is called a protocol violation, but the resulting required peer behavior is not specified."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Localized wire-test answers remain unsettled: the concrete protocol version, acceptance or rejection of unequal parallel-list lengths, and mandatory handling of invalid tuples must be agreed before common positive and negative vectors can be baselined.",
"score": 2,
"uncertainty_note": "Positional correspondence and rejection of malformed inputs have an apparent intent, but the snapshot does not state the testable rules.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Specification > NewPooledTransactionHashes message changes",
"source": "eip.md",
"summary": "EIP-8077 requires EIP-7642 and defines its new message shape relative to the eth/69 baseline."
},
{
"locator": "Backwards Compatibility",
"source": "supporting/eip-7642.md",
"summary": "EIP-7642 establishes eth/69 as a versioned eth protocol that can coexist with eth/68."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7642
],
"rationale": "EIP-8077 has one limited dependency on the eth/69 protocol baseline and remains independently testable for most announcement behavior.",
"score": 1,
"uncertainty_note": "No additional direct EIP interaction is established by the sealed package.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8077,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8077:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The positional relationship among five arrays is implied by indexed notation but no malformed-length behavior is stated.",
"The source and nonce are explicitly unverified until fetch, while receiver scheduling based on them is intentionally left to implementations.",
"The overhead section contains a TBD and alternatives leave peer fanout and announcement strategy open.",
"The phrase \"can be treated as a node that violated the protocol\" does not define a mandatory peer-management action."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "fdbb52add5a5ff565826aa8e0af1210d28dad4fb1bd942337874cef41127a53a",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8077.md",
"git_blob_sha": "a1f03e910d91e3c174ee31a4baeadf95c9ac2714",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8077.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8077.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8077.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8077.yaml",
"sha256": "73527d012eb446a646c37bab9930be9f93dff60f5ae2c85d8b71219541c7dc87"
},
"supporting_documents": [
"supporting/eip-7642.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 15,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Draft execution-layer networking proposal that extends the eth protocol's NewPooledTransactionHashes announcement with transaction source and nonce. This assessment covers only execution-client peer-to-peer encoding and message handling; the snapshot expressly makes no EVM consensus or hard-fork change.",
"tier": "medium",
"title": "eth/XX - announce transactions with nonce",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 15,
"minimum": 11
},
"present": true,
"summary": "Material localized details are missing for malformed parallel-list validation, assignment of the concrete eth protocol version, quantitative announcement overhead, and mandatory handling of false metadata.",
"unresolved_questions": [
"Must all five announcement arrays have identical lengths, and what exact action follows a cardinality mismatch?",
"What concrete eth protocol version replaces eth/XX, and what positive and negative negotiation vectors apply?",
"What announcement-size, peer-fanout, and push-versus-announcement parameters bound the stated significant overhead?",
"Is disconnecting or otherwise penalizing a peer mandatory for a false source or nonce, or is the response implementation-defined?"
]
}
},
"hegota:8094:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal states that it does not change EVM consensus rules and does not require a hard fork."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "evm_gas_rule_changes",
"rationale": "The specified changes are confined to eth wire-protocol transaction and blob propagation; no EVM gas accounting rule is changed.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification changes Transactions and PooledTransactions carriage and adds two blob-pool messages, without specifying opcode execution behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state access or gas-charge ordering is modified.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / GetPooledBlobs and PooledBlobs",
"source": "eip.md",
"summary": "Blobs are addressed and transported by vhash through new peer messages; no blob-gas rule is specified."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP expressly states that it does not change EVM consensus rules."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "blob_gas_accounting_changes",
"rationale": "Although the proposal concerns blobs, it changes their mempool transport rather than blob gas accounting.",
"score": 0,
"uncertainty_note": "The unresolved blob wire format does not propose a blob-gas change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal states that it does not change EVM consensus rules and does not require a hard fork."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "state_gas_accounting_changes",
"rationale": "No state-writing cost, state-gas budget, reservoir, or spill rule is introduced or modified.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "All normative changes concern eth messages and blob-transaction forwarding."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "new_evm_gas_refund",
"rationale": "No EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Transactions (0x02) changes",
"source": "eip.md",
"summary": "Type-3 transactions are now to be sent without their sidecar."
},
{
"locator": "Specification / PooledTransactions (0x0a) changes",
"source": "eip.md",
"summary": "Type-3 pooled transactions are likewise to be sent without their sidecar."
},
{
"locator": "Specification / Other spec changes",
"source": "eip.md",
"summary": "The pre-existing blob propagation rule is replaced with sidecar-free sending, separate blob retrieval, and validation-gated forwarding."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing blob-mempool message and propagation tests need substantive reworking across several established paths, but the affected tests remain confined to the contrived category of type-3 peer propagation.",
"score": 2,
"uncertainty_note": "The package contains no permitted test inventory, so the exact size of the affected subset cannot be counted.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Other spec changes",
"source": "eip.md",
"summary": "Nodes must not forward blob transactions before receiving and validating all blobs."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A narrow class of pre-existing blob propagation tests gains an assertion that forwarding is withheld until complete blob receipt and validation; this is not a fork-wide invariant.",
"score": 1,
"uncertainty_note": "Some affected tests may instead be reworked directly, making the boundary between this anchor and the preceding anchor framework-dependent.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The change is an eth protocol version rollout and is explicitly not an EVM consensus or hard-fork change."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool input, output, field, or mechanism is required by the specified networking behavior.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / GetPooledBlobs and PooledBlobs",
"source": "eip.md",
"summary": "Two new request/response message schemas are introduced, including ordered responses that may omit unavailable items."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "new_test_framework_primitives",
"rationale": "Networking test support needs at least minor extension to represent and exchange the two messages and exercise partial responses, but the EIP does not establish a new reusable expectation or modifier abstraction.",
"score": 1,
"uncertainty_note": "No test-framework description is permitted in the package, and the unresolved response format could make the required extension either trivial or more specialized.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Should we use blob identifiers or a sidecar identifier?",
"source": "eip.md",
"summary": "The proposal selects the already-established blob vhash rather than introducing a new identifier."
},
{
"locator": "Specification / PooledBlobs",
"source": "eip.md",
"summary": "A possible proof-carrying alternative blob format is presented only as an optional unresolved note."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "cryptography",
"rationale": "The normative proposal reuses vhash checking and does not introduce or modify a cryptographic mechanism.",
"score": 0,
"uncertainty_note": "The optional alternative format mentions commitments and proofs but is not selected or specified sufficiently to score as an introduced mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / PooledBlobs",
"source": "eip.md",
"summary": "Responses must preserve request order but may skip unavailable blobs, omit vhashes, and may optionally add a bitmap or vhash list."
},
{
"locator": "Specification / Other spec changes",
"source": "eip.md",
"summary": "Forwarding is prohibited until all blobs have been received and validated."
},
{
"locator": "Rationale / Implementation options / Option 3 (selected)",
"source": "eip.md",
"summary": "A receiver conditionally requests blobs after a sidecar-free transaction and may already possess reusable blob content from a replacement."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms interact: partial ordered responses, absent blobs, local blob reuse, hash correspondence, complete-set validation, and forwarding gates. Testing omission subsets against availability and validation outcomes creates an elevated case count.",
"score": 3,
"uncertainty_note": "Request bounds, duplicate-vhash behavior, response correlation, and failure handling are not specified, so the exact case matrix is unresolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal addresses blob content in type-3 transaction sidecars for mempool redistribution."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The change is a new eth wire-protocol version, not a consensus-rule change."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism or block-sync behavior is modified.",
"score": 0,
"uncertainty_note": "The use of devp2p does not itself satisfy this anchor, which is specifically about block RLP validation requiring syncing.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "All specified interfaces are devp2p eth Transactions, PooledTransactions, GetPooledBlobs, and PooledBlobs messages."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "engine_api_changes",
"rationale": "No Engine API endpoint, field, or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal specifies only peer-to-peer mempool messages and propagation behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP states that it changes only the eth protocol and does not change EVM consensus rules."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "modified_system_contracts",
"rationale": "No existing system contract code, state, or behavior is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal explicitly does not change EVM consensus rules."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal's normative behavior is limited to peer messages and forwarding."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP states that it does not change EVM consensus rules and does not require a hard fork."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specified changes concern type-3 transaction sidecar carriage and new eth peer messages."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "modified_precompiles",
"rationale": "No precompile logic or gas accounting is modified.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / GetPooledBlobs",
"source": "eip.md",
"summary": "A new request interface is encoded as a request ID and list of 32-byte vhashes."
},
{
"locator": "Specification / PooledBlobs",
"source": "eip.md",
"summary": "A new response interface is encoded as a request ID and list of blobs, with optional alternative payload layouts still under consideration."
},
{
"locator": "Specification / Transactions and PooledTransactions changes",
"source": "eip.md",
"summary": "Existing type-3 transaction delivery in two eth messages is changed to omit sidecars."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "encoding_changes_rlp_ssz",
"rationale": "New wire-interface encodings are introduced and existing transaction-message payload carriage changes; the rubric assigns 3 whenever an interface-level encoding change is introduced.",
"score": 3,
"uncertainty_note": "The final response payload layout and message codes are unresolved, but every stated alternative still constitutes an interface encoding change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Transactions (0x02) changes",
"source": "eip.md",
"summary": "The proposal changes how the already-existing type-3 transaction is sent."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Other spec changes",
"source": "eip.md",
"summary": "Nodes must validate all separately received blobs before forwarding the blob transaction."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP expressly does not change EVM consensus rules."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The validation requirement gates peer forwarding but does not change transaction validity rules or intrinsic gas calculation, which are the scope of this anchor.",
"score": 0,
"uncertainty_note": "Blob verification behavior matters to networking tests but is not scored here as transaction validity.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal introduces only transaction-pool blob request and response fields."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "No uncertainty material to this anchor is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal requires a new eth protocol version, supports coexistence with older clients, and does not require a hard fork."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "new_fork_activation_mechanism",
"rationale": "No fork-activation block modifies state, internal variables, or similar execution-layer data.",
"score": 0,
"uncertainty_note": "The protocol-version rollout is not a fork-activation mechanism under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "Replacement transactions currently redistribute full blob content during fee volatility and network overload, amplifying traffic at the worst time."
},
{
"locator": "Rationale / Implementation options / Option 3 (selected)",
"source": "eip.md",
"summary": "Separate blob retrieval can add a round trip per hop, while pushing sidecar-free transactions and reusing known blobs is intended to offset latency and bandwidth."
},
{
"locator": "Specification / PooledBlobs",
"source": "eip.md",
"summary": "An optional compact blob representation is discussed specifically as a bandwidth and reconstruction-CPU tradeoff."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "performance_risks",
"rationale": "Performance depends on interacting peer, mempool, replacement, cache-availability, validation, latency, and bandwidth behavior, so it cannot be fully benchmarked in isolation and materially changes existing blob propagation performance.",
"score": 3,
"uncertainty_note": "Request sizing, cache retention, final blob encoding, and peer scheduling are unspecified, preventing a precise benchmark matrix.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / GetPooledBlobs and PooledBlobs",
"source": "eip.md",
"summary": "Peers can request transaction-pool blobs by vhash, and receivers must verify that returned blob hashes match requested vhashes."
},
{
"locator": "Specification / Other spec changes",
"source": "eip.md",
"summary": "Nodes are forbidden to forward a blob transaction until all blobs are received and validated."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The section is empty and supplies no threat model or mitigations beyond the normative validation gate."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "security_risks",
"rationale": "The new peer-request path and split transaction/blob lifecycle interact with a limited set of existing components—p2p handling, the transaction/blob pool, and blob verification—and warrant targeted adversarial review and fuzzing.",
"score": 2,
"uncertainty_note": "Request limits, malformed or duplicate requests, partial-response failure handling, resource accounting, and peer penalties are unspecified, so the risk could be higher or lower within the rubric.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / GetPooledBlobs and PooledBlobs",
"source": "eip.md",
"summary": "Both message codes remain TODO, while the blob payload format and response-correlation metadata are explicitly optional design choices."
},
{
"locator": "Specification / PooledBlobs",
"source": "eip.md",
"summary": "A response may skip unavailable blobs while preserving order and omitting vhashes, without fully defining how all request and response cases are correlated."
},
{
"locator": "Relation to other EIPs in draft state",
"source": "eip.md",
"summary": "Combination with sparse blobpool behavior depends on introduction order and is left for later as a TODO."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Multiple localized wire-protocol details must be agreed across clients before deterministic interoperability tests can be baselined; they do not make a previously unobservable EVM behavior consensus-critical.",
"score": 2,
"uncertainty_note": "The package has no permitted evidence about implementations, devnets, or discussion outcomes, so the assessment is limited to the visible draft text and its explicit TODOs.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter / requires",
"source": "eip.md",
"summary": "EIP-8094 declares EIP-7642 as a requirement."
},
{
"locator": "Specification and Backwards Compatibility",
"source": "supporting/eip-7642.md",
"summary": "EIP-7642 defines eth/69 message encodings and its version rollout, which is the protocol baseline EIP-8094 modifies."
},
{
"locator": "Specification / Other spec changes",
"source": "eip.md",
"summary": "The proposal explicitly replaces a blob-transaction propagation rule attributed to EIP-4844."
},
{
"locator": "Relation to other EIPs in draft state",
"source": "eip.md",
"summary": "The proposal can combine with EIP-8077 and interacts with EIP-8070 in an order-dependent way left for later."
}
],
"exceptional_score_justification": "Not applicable; the score is below 4.",
"id": "cross_eip_interactions",
"interacting_eips": [
7642,
4844,
8077,
8070
],
"rationale": "The proposal has strong interactions with four identified EIPs: it depends on 7642, changes 4844 propagation behavior, combines with 8077, and leaves order-dependent 8070 integration unresolved. Coordinated cross-EIP wire and propagation testing is required, but four interactions do not trigger the rubric's additional point for three EIPs beyond the first three.",
"score": 3,
"uncertainty_note": "The unresolved 8070 combination leaves the final coordinated test surface uncertain, but all four interactions are explicit in the package.",
"under_specified": true,
"unidentified_interactions": []
}
],
"eip": 8094,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8094:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The phrase requiring response order while allowing omissions and omitting identifiers does not fully specify request-to-response correlation for every constructible list.",
"The normative full-blob response is followed by optional, materially different encoding alternatives without selecting one.",
"A new protocol version is required for compatibility, but its version number and the new message codes are not assigned.",
"The Security Considerations section is empty despite adding a remotely triggerable blob-pool request path."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "c5a94b085a47477e1eef3b12c49f88f3ce1b4219137db8f476ad56c73a3c1347",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8094.md",
"git_blob_sha": "080068faf9d945c85f948ac9dddc9820a2b129c2",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8094.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8094.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8094.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8094.yaml",
"sha256": "56a2b9b1f1b9376589dc9baee1dac33ca426385564e2beb4c06a7bd466af6f74"
},
"supporting_documents": [
"supporting/eip-7642.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 20,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the draft EIP-8094 snapshot. The proposal changes devp2p eth blob-transaction mempool propagation by sending type-3 transactions without sidecars and adding vhash-addressed blob request and response messages; it explicitly makes no EVM consensus or hard-fork change.",
"tier": "medium",
"title": "eth/vhash - Blob-Aware Mempool",
"under_specification": {
"affected_criteria": [
"new_test_framework_primitives",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 22,
"minimum": 15
},
"present": true,
"summary": "The draft leaves message codes, final blob response encoding, partial-response correlation, request and failure bounds, security/resource controls, protocol version designation, and order-dependent integration with EIP-8070 unresolved. These are material to interoperable networking tests but do not alter the many zero-scored EVM and consensus anchors.",
"unresolved_questions": [
"Which devp2p message codes and eth protocol version identify GetPooledBlobs and PooledBlobs?",
"Is the response payload a list of full blobs, a compact proof-carrying representation, or another versioned form?",
"How are omitted items, duplicate vhashes, empty requests, and partial responses correlated and handled?",
"What request-size, resource-accounting, timeout, retry, and peer-penalty rules apply?",
"How does the forwarding gate account for blobs already held locally versus blobs returned by a peer?",
"What exact combined behavior applies with EIP-8070 for each order of introduction?"
]
}
},
"hegota:8115:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "low",
"published_total": 10,
"recomputed_tier": "low",
"recomputed_total": 10,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No charge, refund, or schedule changes: `gas_used`, receipts, and sender debits are byte-identical; only the credit's timing moves. Measured: zero gas-value flips in a full fill.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's internal access or charge order moves; the credit relocates at the block level, outside opcode execution.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The fee credit is not state-gas charged; rates, reservoir, and spill untouched.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Measured blast radius: 14 executions / 6 functions out of 65,709 — EIP-7928 fee-recipient balance-change pins (index and withdrawal-merge) plus one mid-block coinbase read; all updated mechanically behind one fork predicate, none parked.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "No new assertion lands on unrelated tests; the credit folds into BAL entries those tests already assert.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No wire fields, but both t8n modes need the end-of-block settlement step, and state-test mode needs a shared convention (credit after the single transaction) for fixtures to match across fillers.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "One identity-default fork predicate (`batched_priority_fees`) keeps fee-recipient expectations fork-correct; minor extension.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "One edge-prone surface: zero-fee and empty-block touch semantics (EIP-161 destruction of an empty fee recipient, BAL accessed-listing) plus fee-recipient-as-sender solvency boundaries; single mechanism, moderate case count.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "State-root/BAL-visible only; no payload shape change.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "`BALANCE`/`SELFBALANCE` semantics unchanged; only the state they observe mid-block differs.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The balance-at-execution rule is textually unchanged, but block validity flips for a fee recipient spending fees accrued earlier in the same block; no pre-existing validity tests flipped in the full fill.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Removes per-transaction coinbase writes — the EIP's stated purpose; nothing new to benchmark.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Self-contained fee-flow change; alters builder/MEV liquidity assumptions (fees spendable only in the next block) — application-layer and testable in isolation.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Two consensus-critical details are unspecified and need client agreement before fixtures can be baselined, both localized: the credit's EIP-7928 BAL representation (index; merge with a same-account withdrawal) and zero-fee touch semantics (EIP-161 destruction of an empty recipient; BAL accessed-listing).",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Modifies EIP-7928 BAL content (coordinated re-derivation of fee-recipient vectors) and interacts with EIP-4895 (credit ordering and merge), EIP-7708 (fee flows stay log-silent — a stated motivation), EIP-8037 (fee settlement path), and EIP-7799 (refers to 8115 parts). Limited in scope and not complex; five interacting EIPs, no +1 increment.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8115,
"fork": "hegota",
"id": "hegota:8115:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8115.yaml",
"sha256": "e43f51eb531399304b2431b797f92f1c7aaa29c6524f2a39e534467c9c54b3a8"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "39f6dc729d089e0c81279774cbf8f3e0c6731a4a",
"content_sha256": "5f31c7f4ff291f696709ab15cf636b28e5b2f94c5a7cad41936e5be874eca969",
"git_blob_sha": "2613a7f40549fff5318d15b4c82672f41d1ad3e7",
"immutable_url": "https://github.com/ethspecs/pm/blob/39f6dc729d089e0c81279774cbf8f3e0c6731a4a/complexity_assessments/EIPs/EIP-8115.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8115.md",
"pull_request": {
"draft": true,
"number": 126,
"title": "Add EIP-8115 complexity assessment",
"updated_at": "2026-08-24T09:58:13Z",
"url": "https://github.com/ethspecs/pm/pull/126"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 10,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "low",
"title": "Batch priority fees at end of block",
"under_specification": null
},
"hegota:8115:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "Per-transaction EIP-1559 priority-fee credits are replaced by one accumulated credit after transaction processing."
},
{
"locator": "Specification > reference implementation, World.validate_block transaction loop",
"source": "supporting/eip-1559.md",
"summary": "The existing mechanism credits block.author with gas_used multiplied by priority_fee_per_gas after each transaction."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal updates an existing gas-linked fee-accounting mechanism's settlement timing. It introduces no new gas meter and does not change gas consumed, effective gas price, or the sender's gas charge, so the existing-mechanism score of 1 applies.",
"score": 1,
"uncertainty_note": "The EIP gives no pseudocode, but the changed existing credit point is explicit and no gas-cost change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The credit is moved from transaction completion to a block-level point after all transactions."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The changed balance write occurs at transaction/block processing boundaries, not inside any opcode, and no opcode gas charge is reordered relative to an opcode state access.",
"score": 0,
"uncertainty_note": "The draft does not provide execution pseudocode, but its specified boundary is outside opcode execution.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The sole normative change concerns EIP-1559 priority-fee credit timing."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas mechanism or blob fee accounting is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob-related behavior appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The proposal changes when a balance credit is applied, without defining a state-gas cost, budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "A balance update is reordered, but the rubric's state-gas mechanisms for charging state writes are not changed.",
"score": 0,
"uncertainty_note": "The proposal is silent on state gas because it specifies no state-gas accounting change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > reference implementation, World.validate_block transaction loop",
"source": "supporting/eip-1559.md",
"summary": "Unused-gas refunds are paid to the signer before the existing priority-fee credit to the block author."
},
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "Only the priority-fee credit timing is changed."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No refund is added or modified; the proposal batches the recipient's fee credit after transaction-level gas use and refunds have been determined.",
"score": 0,
"uncertainty_note": "The EIP does not restate refund behavior, so the assessment treats the narrowly stated credit-timing change as exhaustive.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The fee recipient can no longer spend priority fees in the same block, and block-builder infrastructure and MEV liquidity may need updates."
},
{
"locator": "Rationale",
"source": "eip.md",
"summary": "A transaction can no longer become eligible after incremental priority-fee credits."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing multi-transaction tests in which the fee recipient spends fees credited by an earlier transaction must be reworked. Most tests retain the same end-of-block aggregate credit, making the affected set a narrow subset rather than a broad category.",
"score": 1,
"uncertainty_note": "The package provides no test inventory, and ambiguity about which fee-bearing transaction forms are batched makes the exact affected subset uncertain.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The proposal changes an internal state-transition ordering and adds no new block output or commitment."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests specifically exercising batching need balance assertions, but unrelated pre-existing tests do not gain a new produced field or invariant to assert in addition to their existing post-state checks.",
"score": 0,
"uncertainty_note": "The package does not describe the test harness; this score distinguishes changed expected state in the narrow affected tests from a new assertion required in every unrelated test.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The rule uses the existing block transactions, fee recipient, priority fees, and withdrawals ordering, with no new input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The batching accumulator is internal to block processing; the sealed proposal requires no transition-tool interface field or mechanism.",
"score": 0,
"uncertainty_note": "No transition-tool design is included, but nothing in the normative rule requires additional external data.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The behavior is a balance transition over an ordered list of ordinary block transactions followed by withdrawals."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Multi-transaction blocks and post-state balance checks can express the specified behavior; no new expectation type, modifier, or reusable framework abstraction is required by the text.",
"score": 0,
"uncertainty_note": "The package contains no test-framework inventory, so confidence is limited to what the proposal itself demands.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The normative rule only sums and credits priority fees at a different processing point."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic primitive, algorithm, proof, signature rule, or commitment is introduced or modified.",
"score": 0,
"uncertainty_note": "No cryptography-related behavior appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "Fees are accumulated across all transactions and credited at the exact boundary after transactions but before withdrawals."
},
{
"locator": "Specification > reference implementation, normalize_transaction and World.validate_block transaction loop",
"source": "supporting/eip-1559.md",
"summary": "Legacy, type-1, and type-2 transactions normalize to fee values; the credited amount depends on the priority-fee cap and actual gas used after refund."
},
{
"locator": "Rationale and Backwards Compatibility",
"source": "eip.md",
"summary": "Fee-recipient solvency during the block changes because incremental credits can no longer make its later transaction eligible."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Testing must cover accumulation and the new end-of-transactions boundary across transaction count/order, zero and nonzero effective tips, actual gas use/refund outcomes, the fee recipient's role and balance threshold, and the specified withdrawal boundary. These interacting dimensions create multiple boundary-prone behaviors, including a solvency matrix requiring an elevated case count.",
"score": 3,
"uncertainty_note": "The exact matrix is uncertain because the draft does not define the included transaction forms, accumulator arithmetic, or zero-credit account behavior.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The proposal changes state-processing order and defines no block RLP field or validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requiring client syncing is introduced.",
"score": 0,
"uncertainty_note": "The normative section contains no serialization change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "All data used by the rule already belongs to transaction, fee-recipient, and withdrawal processing; no Engine API directive or field is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The proposal introduces neither an Engine API field nor a new communication mechanism or endpoint.",
"score": 0,
"uncertainty_note": "No Engine API surface appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The fee credit is a protocol balance update and no contract address or code is defined."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "No system-contract mechanism appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The change targets priority-fee settlement to the block fee recipient and names no system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system-contract code, state, or system-contract-specific behavior is directly or indirectly modified by the specified rule.",
"score": 0,
"uncertainty_note": "The sealed sources identify no system contract interaction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The normative change is performed by block processing rather than an EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "No opcode allocation or semantics appear in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The proposal delays recipient credit without changing any instruction result."
},
{
"locator": "Specification, GASPRICE requirement",
"source": "supporting/eip-1559.md",
"summary": "EIP-1559 defines GASPRICE as effective_gas_price; EIP-8115 does not alter that requirement."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode's non-gas behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "The draft does not restate GASPRICE, but its narrowly scoped rule does not change the transaction's effective gas price.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The proposal specifies only protocol-level fee accumulation and crediting."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "No precompile address, input, output, or gas rule appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The normative change does not refer to precompile execution or charging."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "No precompile interaction appears in the sealed sources.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The proposal adds an execution-order rule and no transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, transaction, block, or interface-level encoding is changed.",
"score": 0,
"uncertainty_note": "The normative section defines no serialized object or field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification > Priority fee processing",
"source": "eip.md",
"summary": "The EIP changes processing of priority fees from existing fee-market transactions and defines no transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "Which existing fee-bearing transaction forms are covered is ambiguous, but none is newly created.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale",
"source": "eip.md",
"summary": "A transaction can no longer start underfunded and become eligible after incremental priority-fee credits."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The fee recipient can spend the fees only in the next block, changing block-builder liquidity requirements."
},
{
"locator": "Specification > reference implementation, World.validate_block transaction loop",
"source": "supporting/eip-1559.md",
"summary": "Transaction processing checks the signer's balance before executing and currently credits the block author after each transaction."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Delaying credits changes the validity outcome for a later transaction sent by the fee recipient when its pre-block balance is insufficient but earlier priority fees previously made it solvent. This affects existing cases but is localized and needs limited vector updates rather than test-infrastructure redesign.",
"score": 2,
"uncertainty_note": "The draft states the intended solvency effect but does not give exact validation pseudocode or define the scope across existing transaction forms.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The accumulator and final balance credit are processing behavior; no block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block-body or block-header field is introduced.",
"score": 0,
"uncertainty_note": "No block schema change appears in the proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "The EIP specifies a changed processing rule but no one-time state migration or existing internal-variable modification at activation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Applying the new rule does not require a state modification or irregular internal-variable update at the activation block; a per-block accumulator would be initialization, not modification of existing state.",
"score": 0,
"uncertainty_note": "The Draft contains no explicit activation clause, but it also prescribes no activation-block transition that meets this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, items 1 and 3",
"source": "eip.md",
"summary": "Per-transaction writes to the fee-recipient balance limit parallelization and create hundreds of micropayments."
},
{
"locator": "Rationale",
"source": "eip.md",
"summary": "Batched crediting is intended to improve parallel transaction execution."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The mechanism's purpose is to remove a block-wide shared balance write from every transaction. Its parallel-execution effect cannot be validated in isolation from block workloads and is intended to substantially change existing execution performance behavior, warranting broad workload benchmarking.",
"score": 3,
"uncertainty_note": "The package gives no quantitative target, workload model, or benchmark result, so the size and consistency of the performance effect remain uncertain.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Priority fee processing",
"source": "eip.md",
"summary": "Clients must compute a block-wide fee sum and apply exactly one balance credit at a consensus-critical point before withdrawals."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The timing change removes same-block spendability and changes liquidity requirements for block builders and MEV use cases."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The proposal asserts that there is no security impact but supplies no supporting analysis."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect accumulation, omission, duplication, or ordering would alter ETH balances or transaction solvency. The change is limited to fee settlement, transaction balance checks, and the withdrawal boundary, so targeted review and fuzzing are appropriate rather than an extensive multi-component security program.",
"score": 2,
"uncertainty_note": "The EIP's security section is conclusory, and missing arithmetic and transaction-scope details prevent high confidence.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Specification > Priority fee processing",
"source": "eip.md",
"summary": "The text says EIP-1559 priority fees from fee-market transactions are summed but gives no algorithm, numeric domain, or explicit enumeration of covered transaction forms."
},
{
"locator": "Specification > reference implementation, normalize_transaction and World.validate_block transaction loop",
"source": "supporting/eip-1559.md",
"summary": "The supporting EIP normalizes legacy, type-1, and type-2 transactions to priority-fee fields and calculates the per-transaction credit from actual gas used."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need localized agreement on which existing transactions contribute, the exact accumulated amount and arithmetic, and zero-credit/account-state behavior before boundary vectors can be baselined. The newly changed intermediate fee-recipient balance was already observable to later transactions, so the score-3 condition for previously unobservable behavior is not met.",
"score": 2,
"uncertainty_note": "Prohibited implementation, devnet, and discussion evidence is unavailable by contract; this score reflects only the material gaps in the sealed Draft text.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter, requires; Specification > Priority fee processing",
"source": "eip.md",
"summary": "EIP-8115 requires EIPs 1559 and 4895, modifies EIP-1559 priority-fee settlement, and fixes the batch credit before EIP-4895 withdrawals."
},
{
"locator": "Specification > State transition",
"source": "supporting/eip-4895.md",
"summary": "Withdrawals are processed after user-level transactions as unconditional balance increases."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
4895
],
"rationale": "The proposal directly modifies 1559 fee processing and requires coordinated ordering tests with 4895 withdrawals. These two dependencies require coordinated consideration but remain limited to balance-update sequencing, matching score 2.",
"score": 2,
"uncertainty_note": "The Motivation mentions unnumbered ETH balance-log proposals, but the package does not identify a normative dependency or an EIP number for them.",
"under_specified": false,
"unidentified_interactions": [
"Unnumbered proposals to emit logs on ETH transfers mentioned in the Motivation"
]
}
],
"eip": 8115,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8115:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The Abstract says fee-market transactions, while the normative sentence says EIP-1559 priority fees; the included existing transaction forms are not enumerated.",
"Summed up does not specify accumulator width, overflow handling, or whether zero-valued credit operations affect account state.",
"The required position before EIP-4895 withdrawals is explicit, but no executable state-transition pseudocode defines all fee contribution and failure cases."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "55ab16f6b3f9778ea5ce777dbbc67a95d627cda00c78f1de4922f36da79d4e23",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8115.md",
"git_blob_sha": "d4ea93f317983caff8e9030a8b1f83930c5a6346",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8115.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8115.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8115.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8115.yaml",
"sha256": "c6b738cfaf1593b8227bd7599bbcd72e3516fcae460f6abaa9fee129e3ae376d"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-4895.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 16,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the sealed Draft EIP-8115 proposal, limited to delaying and batching EIP-1559 priority-fee credits after all block transactions and before EIP-4895 withdrawals.",
"tier": "medium",
"title": "Batch priority fees at end of block",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"new_or_modified_transaction_validity_mechanisms",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 17,
"minimum": 11
},
"present": true,
"summary": "The one-paragraph normative rule fixes the principal processing boundary but omits a precise accumulation algorithm, covered transaction forms, arithmetic and zero-credit semantics, and activation detail. Those gaps materially affect boundary, regression, validity, performance, security, and consensus-baselining estimates.",
"unresolved_questions": [
"Does the batch include priority-fee amounts produced by legacy and type-1 transactions normalized under EIP-1559, or only type-2 fee-market transactions?",
"Is each contribution exactly actual gas used multiplied by the capped priority fee per gas, including reverted executions and transaction gas refunds?",
"What numeric domain and overflow behavior apply to the block-wide accumulator and the final beneficiary balance addition?",
"What state effect is required when the total credit is zero or the fee-recipient account does not otherwise exist?",
"What exact validity handling is required when a fee-recipient transaction would have been solvent only after an earlier incremental credit?",
"How and at what fork boundary is the new processing rule activated?"
]
}
},
"hegota:8116:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The proposal changes which already-computed gas quantity is stored in receipts; it specifies no EVM gas charging rule."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Receipt representation changes do not update or introduce an EVM gas-accounting mechanism.",
"score": 0,
"uncertainty_note": "The sealed specification contains no gas schedule, gas charge, or metering change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete specification is limited to receipt construction and JSON-RPC log indexing, with no opcode execution or state-access ordering rule."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's state-access position or gas-charge ordering is changed.",
"score": 0,
"uncertainty_note": "No state-accessing operation or opcode path is described in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The only gas-related change is storing individual transaction gasUsed rather than its cumulative receipt value."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal introduces no blob-gas accounting rule or mechanism.",
"score": 0,
"uncertainty_note": "Blob gas is not mentioned anywhere in the sealed EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Receipt value semantics and RPC log indexing are changed; state writes, state-gas rates, budgets, reservoirs, and spill behavior are not specified."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas cost or state-gas charging mechanism changes.",
"score": 0,
"uncertainty_note": "The sealed EIP contains no state-gas provisions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The receipt records per-transaction gasUsed, but no refund calculation or refund mechanism is introduced."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Changing the reported gas quantity does not create an EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "Refunds are not mentioned in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "All receipts emitted after activation must contain individual transaction gasUsed rather than cumulativeGasUsed."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Applications using verified gasUsed or cumulativeGasUsed values must adapt to the new on-chain semantics."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Every post-activation receipt changes its consensus value, so the broad set of existing vectors that commits to or verifies receipts must be re-derived rather than only a contrived corner category.",
"score": 3,
"uncertainty_note": "The EIP has no testing section or inventory of the existing corpus, so the exact number and categories of affected vectors are not package-evidenced.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "An existing cumulative receipt value is replaced by an individual value; the proposal does not add a separate receipt property or assertion."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing receipt expectations require changed values, scored as test rework above, but tests do not gain an additional invariant to assert.",
"score": 0,
"uncertainty_note": "The sealed EIP does not describe test assertions, but its specified operation is replacement rather than addition.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The EIP specifies on-chain receipt construction and JSON-RPC logIndex semantics but does not specify a transition-tool field or mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface modification can be established from the sealed package.",
"score": 0,
"uncertainty_note": "The draft does not state whether or how a transition tool exposes the replaced receipt field; this is recorded as material under-specification.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The change supplies deterministic per-transaction receipt and per-receipt log-index outputs without specifying any new test expectation type, modifier, or helper."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Value-level receipt and RPC expectations do not, on the sealed evidence, require a new framework abstraction.",
"score": 0,
"uncertainty_note": "The EIP contains no testing section, so this score is limited to the absence of any package-specified primitive requirement.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Receipt gas values and log indices are the only modified mechanisms; no cryptographic construction or function is introduced."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography-related testing is required by the proposal.",
"score": 0,
"uncertainty_note": "No cryptographic mechanism is mentioned in the sealed EIP.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "Receipt gas changes from a block-running sum to an individual transaction value at activation."
},
{
"locator": "Specification > JSON-RPC API",
"source": "eip.md",
"summary": "Each logIndex changes from a block-level sequence to its position within the individual receipt."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Two boundary-prone mechanisms require coverage: gas values across first and later receipts and log indices resetting across receipts, including receipts with differing log counts; neither demands an elevated combinatorial case set on the package evidence.",
"score": 2,
"uncertainty_note": "Exact boundary vectors are not enumerated, and the precise RPC method scope is not specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes receipt value semantics and an RPC index but defines no block RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new RLP validation mechanism requiring client syncing is introduced.",
"score": 0,
"uncertainty_note": "Receipt schema details are sparse, but the EIP does not state any block RLP validation change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > JSON-RPC API",
"source": "eip.md",
"summary": "The only API change named is JSON-RPC logs.logIndex semantics; no Engine API endpoint, field, or communication mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "A JSON-RPC semantic change is not evidence of an Engine API change.",
"score": 0,
"uncertainty_note": "The Engine API is not mentioned in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification contains only receipt construction and JSON-RPC changes and introduces no contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No contract address, code, state, or system action is described.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Neither receipt gas semantics nor receipt-relative RPC log indexing specifies a direct or indirect system-contract modification."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract code, state, or behavior is modified.",
"score": 0,
"uncertainty_note": "System contracts are not mentioned in the sealed EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete specification adds no EVM instruction and is confined to receipts and JSON-RPC output."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "Opcodes are not mentioned in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The proposal changes post-execution receipt data, not the result or behavior of any opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "No opcode-level change is present in the sealed EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No precompile address, input, output, gas rule, or execution behavior is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "Precompiles are not mentioned in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The receipt and RPC changes do not specify any precompile logic or gas-accounting modification."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "No precompile-related behavior is present in the sealed EIP.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The specified change is the meaning of the gas quantity tracked in receipts; no RLP, SSZ, JSON, field type, or serialization-format change is defined."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Changed receipt contents alone do not establish the rubric's transaction, block, or interface encoding-format change.",
"score": 0,
"uncertainty_note": "The draft does not explicitly say whether the existing receipt slot is reinterpreted or the receipt schema is replaced; this material ambiguity is recorded separately.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal changes on-chain receipt data for transactions and does not define a transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "Transaction types are not mentioned in the sealed EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The rule applies when constructing receipts after transaction execution and specifies no transaction admission, validity, or intrinsic-gas rule."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Receipt output semantics do not modify transaction validity mechanisms.",
"score": 0,
"uncertainty_note": "No validity predicate or intrinsic gas calculation is included in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The EIP changes receipt contents and JSON-RPC log indices but does not add a block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "Block and header schemas are not modified in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The new receipt semantics apply after activation, but no state, internal variable, migration, or activation-block action is specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "A fork-conditional rule without an activation-block mutation is not a new activation mechanism under this anchor.",
"score": 0,
"uncertainty_note": "The activation point is not supplied, but no activation-block mutation is proposed.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "Cumulative receipt fields are identified as inefficient for individual gas verification and as limiting parallelism because receipt contents are stateful across transactions."
},
{
"locator": "Rationale",
"source": "eip.md",
"summary": "Stateful cumulative gas and log-index components are replaced with per-transaction equivalents."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The intended benefit depends on block-level receipt verification and parallel construction behavior, so it is not fully measurable as an isolated scalar operation, while the affected surface remains limited to receipt production and consumption.",
"score": 2,
"uncertainty_note": "The EIP supplies no performance targets, workload model, or benchmark plan, so the magnitude of the limited impact is not quantified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "A deterministic receipt value changes for all post-activation receipts, but the mechanism is localized to selecting the individual transaction gas value."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The EIP states that there are no security considerations."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Correctness matters for consensus receipt construction, but the new rule is self-contained, directly testable, and does not specify a changed security invariant or interaction with multiple critical mechanisms.",
"score": 1,
"uncertainty_note": "The one-word security section provides no analysis of misimplementation or application risks.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Receipt construction",
"source": "eip.md",
"summary": "The draft states the new gas semantics but does not define the precise receipt field/schema, serialization treatment, or transition-interface representation."
},
{
"locator": "Specification > JSON-RPC API",
"source": "eip.md",
"summary": "The RPC rule changes logIndex within logs but does not enumerate affected methods or fully specify compatibility behavior of receipt gas fields."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need localized agreement on the exact receipt representation and RPC surface before consensus and API vectors can be baselined; the change does not make a previously unobservable execution behavior consensus-critical, so score 3 does not apply.",
"score": 2,
"uncertainty_note": "The intended semantic direction is clear, but several representation and interface details remain unresolved in the sealed draft.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The receipt and JSON-RPC rules cite no numbered EIP and state no dependency on, modification of, or conflict with another proposal."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "No package-grounded cross-EIP interaction can be identified without importing prohibited external knowledge.",
"score": 0,
"uncertainty_note": "Existing receipt and RPC mechanisms are affected, but the sealed package does not attribute either mechanism to an interacting EIP.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8116,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8116:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The singular normative on-chain rule does not spell out how the title's plural \"receipt fields\" maps to a serialized receipt schema.",
"The backward-compatibility discussion names both gasUsed and cumulativeGasUsed without normatively specifying their post-activation JSON-RPC exposure.",
"The logIndex rule says \"within logs\" but does not enumerate the RPC responses to which the new receipt-relative index applies."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "587ad8509b9df4473a75366a7361bb191b87941726f45cde79ff85ef7559fea5",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8116.md",
"git_blob_sha": "c1f453382a4fef890e5a097bace777299fa16343",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8116.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8116.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8116.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8116.yaml",
"sha256": "16f0427e1bf257ddfacbe701e69dfea7b0b8ef11ebdf6636ff06b0e9a125ccb8"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 10,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Draft execution-layer proposal in the sealed Hegota snapshot that changes every post-activation on-chain receipt from cumulativeGasUsed semantics to per-transaction gasUsed semantics and changes JSON-RPC logIndex from block-relative to receipt-relative.",
"tier": "low",
"title": "Replace cumulative receipt fields",
"under_specification": {
"affected_criteria": [
"transition_tool_interface_changes",
"encoding_changes_rlp_ssz",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 9
},
"present": true,
"summary": "The proposal clearly changes receipt gas and RPC log-index semantics, but it does not normatively define the resulting receipt schema/serialization, transition-tool representation, or the complete affected JSON-RPC surface. This is treated as one representation-and-interface gap rather than repeated across unrelated anchors.",
"unresolved_questions": [
"Is the existing cumulativeGasUsed receipt position and integer encoding retained with new semantics, or is a new receipt field/schema introduced?",
"Must a transition tool rename, replace, or add any receipt output field, and what is its fork-aware interface behavior?",
"Which JSON-RPC methods and gas fields, beyond logs.logIndex, retain old names or acquire changed semantics?"
]
}
},
"hegota:8131:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction floor; Specification > Charging",
"source": "eip.md",
"summary": "Defines a content-count-based tx_floor and uses it in transaction gas-limit validity and gas-used maximum calculations."
},
{
"locator": "Specification",
"source": "supporting/eip-7623.md",
"summary": "Defines the pre-existing calldata floor and the max-shaped transaction gas accounting that EIP-8131 says it preserves."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "evm_gas_rule_changes",
"rationale": "EIP-8131 updates the existing transaction floor by adding content categories and unifying the rate; it does not introduce a separate gas meter or replace the max-based accounting shape.",
"score": 1,
"uncertainty_note": "The score treats the proposal as an update to the EIP-7623 family of floor rules. The undefined scope of execution_gas_used is recorded separately as material under-specification.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative changes calculate a transaction-level floor from decoded transaction content and alter charging; no opcode execution path is changed."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state access, gas charge relative to an opcode state access, or recordable state-access ordering is modified.",
"score": 0,
"uncertainty_note": "No opcode-level state-access behavior is specified in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction floor; Specification > Charging",
"source": "eip.md",
"summary": "Counts 32 execution-payload bytes per blob versioned hash only in tx_floor."
},
{
"locator": "Specification > Gas accounting",
"source": "supporting/eip-4844.md",
"summary": "Defines blob gas as an independent gas type priced through GAS_PER_BLOB and excess_blob_gas; EIP-8131 does not modify those rules."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "blob_gas_accounting_changes",
"rationale": "Pricing blob versioned hashes in the ordinary transaction floor is not a change to the independent blob-gas accounting mechanism.",
"score": 0,
"uncertainty_note": "The sealed text never changes GAS_PER_BLOB, blob fees, blob-gas limits, or excess-blob-gas calculation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Specifies only transaction content-floor constants, a floor formula, and transaction charging rules."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "state_gas_accounting_changes",
"rationale": "No state-write gas cost, state-gas charging site, block state-gas budget, reservoir, or spill path is introduced or modified.",
"score": 0,
"uncertainty_note": "No state-gas mechanism appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Charging",
"source": "eip.md",
"summary": "Changes gas-limit validity and gasUsed via maximum operations without defining any refund-counter addition or refund mechanism."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "new_evm_gas_refund",
"rationale": "No new gas refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "The proposal contains no refund rule.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Reports changed floor binding and gas use across legacy, access-list, EIP-1559, blob, and set-code transactions, concentrated in floor-bound content-heavy cases."
},
{
"locator": "Specification > Charging",
"source": "eip.md",
"summary": "Existing transactions can become invalid at a prior gas limit or report a different gasUsed when the new floor wins."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing gas and transaction-validity vectors for several transaction types require expected-value changes, but the affected category is localized to floor-bound or near-floor content-heavy cases rather than a diverse majority of execution tests.",
"score": 2,
"uncertainty_note": "The package quantifies transaction impact but contains no inventory of pre-existing tests, so the exact affected-test count is not established.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction floor; Specification > Charging",
"source": "eip.md",
"summary": "Alters existing validity and gasUsed results but introduces no new receipt, header, state, or other output that unrelated tests must additionally assert."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Affected tests must revise gas expectations; they do not gain a separate new invariant or assertion produced by the EIP.",
"score": 0,
"uncertainty_note": "No additional test-visible output is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction floor",
"source": "eip.md",
"summary": "Computes the floor solely from transaction fields already present in the affected transaction formats."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool input or output field, fork-block flag, or new interface mechanism is specified.",
"score": 0,
"uncertainty_note": "Tool implementation is outside the package, but the normative inputs require no new block-level interface data.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Expresses cases using existing transaction forms, ordinary content counts, and numeric gas-floor expectations."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "new_test_framework_primitives",
"rationale": "Existing transaction construction and gas/validity expectations suffice; no new reusable expectation, modifier, or framework abstraction is required by the sealed text.",
"score": 0,
"uncertainty_note": "The package does not describe a concrete test framework, so this is based on the proposal's required test inputs and outputs only.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants; Specification > Transaction floor",
"source": "eip.md",
"summary": "Counts authorization tuples and blob versioned hashes without changing how either is created, signed, hashed, or verified."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "cryptography",
"rationale": "No cryptographic mechanism or cryptographic functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "Existing cryptographic fields are inputs only to integer counts.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction floor; Specification > Charging",
"source": "eip.md",
"summary": "Introduces zero-for-absent field handling, four independently countable content categories, a max(intrinsic, tx_floor) validity boundary, and a max(execution_gas_used, tx_floor) charging boundary."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Gives separate examples for empty content, calldata, access lists, authorization tuples, and blob versioned hashes."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "edge_boundary_conditions",
"rationale": "Multiple boundaries must be exercised across transaction types and mixtures of four content categories. In particular, equality and either side of both max operations create an elevated composition-by-threshold case matrix.",
"score": 3,
"uncertainty_note": "The undefined scope of execution_gas_used makes the exact gasUsed boundary uncertain, but does not remove the multiple boundary dimensions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Content-only, not full RLP; Specification",
"source": "eip.md",
"summary": "Explicitly avoids charging encoded envelope bytes and specifies no block or transaction RLP structural validation change."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requiring sync-client testing is introduced.",
"score": 0,
"uncertainty_note": "Transaction validity changes are scored separately from RLP validation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility; Security Considerations > Gas estimation",
"source": "eip.md",
"summary": "Calls for wallet and eth_estimateGas updates but specifies no Engine API endpoint, field, or execution/consensus communication change."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "engine_api_changes",
"rationale": "No Engine API field, mechanism, or endpoint is introduced.",
"score": 0,
"uncertainty_note": "eth_estimateGas is an RPC concern, not an Engine API change under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete normative mechanism consists of constants, a transaction-floor formula, and transaction charging rules; no contract is introduced."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No system-contract address, code, state, or action appears in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Applies transaction-level floor and charging changes without referring to existing system-contract code, state, or invocation behavior."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "modified_system_contracts",
"rationale": "No direct or indirect modification to a pre-existing system contract is specified.",
"score": 0,
"uncertainty_note": "No system-contract interaction is present in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Defines no opcode number, stack behavior, execution semantics, or opcode gas."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "The change occurs before or around transaction execution, not as an EVM instruction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Changes transaction-floor computation and charging only; no opcode result or behavior is mentioned."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "Transaction gas accounting is covered by its own anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No precompile address, input, output, gas schedule, or execution logic is defined."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "Existing blob hashes are merely counted and do not invoke a precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Contains no change to any precompile's logic or gas accounting."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "The proposal has no precompile execution surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Content-only, not full RLP",
"source": "eip.md",
"summary": "Deliberately prices selected content rather than encoded envelope and signature bytes; it does not alter their encoding."
},
{
"locator": "Specification > Transaction floor",
"source": "eip.md",
"summary": "Uses counts from existing decoded transaction fields without defining a new serialization."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding format is changed.",
"score": 0,
"uncertainty_note": "The use of a worst-case RLP byte constant for authorizations is accounting, not an RLP encoding change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction floor; Backwards Compatibility",
"source": "eip.md",
"summary": "Applies one rule to already-existing legacy and types 1 through 4; no new type identifier or payload format is defined."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "All affected transaction forms pre-exist in the sealed supporting documents.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Charging",
"source": "eip.md",
"summary": "Requires tx.gas to be at least the maximum of existing intrinsic gas and the new unified content floor while stating that intrinsic gas itself is unchanged."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Shows changed floor behavior across five existing transaction types and mandates updated gas estimation."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction types gain a modified gas-limit validity condition that affects floor-bound test cases. The arithmetic and available fields support limited vector updates without a necessary redesign of test infrastructure.",
"score": 2,
"uncertainty_note": "Whether the EIP-7981 access-list surcharge remains in intrinsic gas is not resolved by the sealed text and is recorded under under-specification.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Defines no block-body or header field and derives the floor entirely per transaction."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "The block gas limit is used only in rationale arithmetic, not modified structurally.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "States only that a hard fork is required and specifies no activation-block transition."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "new_fork_activation_mechanism",
"rationale": "No state, internal variable, or similar value is modified specially at the fork-activation block.",
"score": 0,
"uncertainty_note": "Activation scheduling is absent, but no special activation mechanism is needed by the rule.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Estimates aggregate network gas rising 3.56%, with large floor and binding changes concentrated in set-code and blob-carrying transactions."
},
{
"locator": "Security Considerations > Block-size bound",
"source": "eip.md",
"summary": "Makes worst-case per-block attacker-controlled content and network payload size a central claimed effect of the mechanism."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "performance_risks",
"rationale": "Per-transaction arithmetic is simple, but the performance effect depends on block composition, gas-limit use, and transaction-type mix, so it cannot be fully benchmarked in isolation. The package indicates limited aggregate impact alongside a material worst-case bandwidth change.",
"score": 2,
"uncertainty_note": "The sealed package supplies modeled/sample impacts but no implementation or benchmark evidence, which is prohibited from supplementation.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations > Block-size bound",
"source": "eip.md",
"summary": "The security argument relies on every content byte being covered by the floor to derive a hard maximum block-content bound."
},
{
"locator": "Specification > Set code transaction; Specification > Behavior",
"source": "supporting/eip-7702.md",
"summary": "Allows authorization chain_id values below 2**256 and charges every tuple, including tuples that fail behavior checks."
},
{
"locator": "Rationale > Per-auth term is a constant",
"source": "eip.md",
"summary": "Claims 108 bytes is the maximum authorization RLP size while budgeting only nine bytes for chain_id."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "security_risks",
"rationale": "The floor changes consensus-critical gas and validation across several existing transaction components and is intended to enforce a bandwidth security invariant. Targeted review and fuzzing are needed, particularly because the authorization-size premise does not cover the linked EIP-7702 field bound.",
"score": 2,
"uncertainty_note": "The 108-gas-accounting constant is normative and deterministic, but the package evidence does not support its claimed worst-case-byte rationale.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Charging",
"source": "eip.md",
"summary": "Sets tx.gasUsed to max(execution_gas_used, tx_floor) without defining execution_gas_used, while separately saying intrinsic gas is unchanged."
},
{
"locator": "Specification",
"source": "supporting/eip-7623.md",
"summary": "Defines execution_gas_used as EVM execution gas after refund and includes base, calldata, and creation costs separately in the prior gasUsed formula."
},
{
"locator": "Motivation; Specification > Charging",
"source": "eip.md",
"summary": "Says EIP-7981 is folded into the unified rule, yet also says intrinsic gas is unchanged, leaving the existing flat access-list surcharge treatment unresolved."
}
],
"exceptional_score_justification": "Not applicable; the score is within the defined anchors.",
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need localized agreement on which ordinary gas components are included in execution_gas_used and whether the EIP-7981 surcharge remains in intrinsic/normal gas before gasUsed and boundary vectors can be baselined. The ambiguity concerns already-observable gas accounting, so it does not meet the score-3 anchor.",
"score": 2,
"uncertainty_note": "No implementations, discussions, or later clarifications may be consulted; assessment is limited to the internally incomplete snapshot text.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Abstract; Motivation",
"source": "eip.md",
"summary": "Requires 2028, 4844, 7623, 7702, 7976, and 7981; replaces or extends the floor treatment of calldata, access lists, authorization tuples, and blob versioned hashes."
},
{
"locator": "Rationale > Content-only, not full RLP; Backwards Compatibility",
"source": "eip.md",
"summary": "Applies type-symmetric behavior to legacy, 2930, 1559, 4844, and 7702 transactions and explicitly relies on their existing content formats."
}
],
"exceptional_score_justification": "Score 4 is mechanically justified by the uncapped anchor: strong interdependence merits 3, and the eight identified EIPs supply one +1 group of three additional interactions beyond the first three.",
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
2028,
2930,
4844,
7623,
7702,
7976,
7981
],
"rationale": "Coordinated gas, validity, and boundary testing is required for 1559, 2028, 2930, 4844, 7623, 7702, 7976, and 7981. The proposal strongly combines or modifies several of their mechanisms, supporting base score 3; eight interacting EIPs contain at least one complete group of three beyond the first three, adding 1 under the uncapped rule.",
"score": 4,
"uncertainty_note": "Only package-grounded direct interactions are listed; transitive EIPs not needed to test EIP-8131's specified surface are excluded.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8131,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8131:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The Backwards Compatibility section defines a binding floor by comparison with intrinsic plus execution gas, but the normative Charging formula compares the floor only with the undefined execution_gas_used term.",
"EIP-8131 calls 108 bytes the worst-case EIP-7702 tuple RLP size using a nine-byte chain_id, while EIP-7702 permits chain_id below 2**256 and continues past invalid authorization tuples rather than invalidating the outer transaction.",
"The proposal claims automatic pricing of future variable-length fields, but supplies no generic content-byte definition or extension rule."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "a961c863da669afa48c50ce5800b1b1af50933c723a50a3da7563a60da70c223",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8131.md",
"git_blob_sha": "8710275f91d09d700cd16746748f9a4baef7c3d2",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8131.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8131.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8131.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8131.yaml",
"sha256": "48a2261f0e68707b8a19c4a659d7029fd87020caed433436e0d1b310e15ee32e"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-2028.md",
"supporting/eip-2930.md",
"supporting/eip-4844.md",
"supporting/eip-7623.md",
"supporting/eip-7702.md",
"supporting/eip-7976.md",
"supporting/eip-7981.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 18,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the Draft EIP-8131 snapshot. The proposal replaces or extends the existing transaction content-floor calculation so calldata, access-list entries, EIP-7702 authorization tuples, and EIP-4844 blob versioned hashes contribute at a nominal 64 gas per content byte.",
"tier": "medium",
"title": "Unified Transaction Content Floor",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"new_or_modified_transaction_validity_mechanisms",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 21,
"minimum": 17
},
"present": true,
"summary": "The charging rule does not define execution_gas_used, and its compact formula does not state how ordinary intrinsic components are combined with the new floor. In addition, saying that EIP-7981 is folded into the unified rule while keeping intrinsic gas unchanged leaves unclear whether its flat access-list data surcharge is retained, replaced, or double-counted. These are localized gas-accounting and validity questions. Separately, the 108-byte authorization constant is clear to implement but does not match the claimed maximum under the linked EIP-7702 field bounds.",
"unresolved_questions": [
"Does execution_gas_used in tx.gasUsed include TX_BASE, standard calldata and access-list intrinsic charges, creation charges, and EVM execution after refund, or only the last of those components?",
"Is EIP-7981's access_list_data_cost retained in intrinsic/ordinary gas after EIP-8131, or is it replaced by the access-list term in tx_floor?",
"How is AUTH_TUPLE_BYTES = 108 reconciled with EIP-7702 authorization chain_id values below 2**256 and tuples that remain transaction content even when an authorization fails its behavior checks?",
"What normative rule makes future variable-length transaction fields automatically contribute to tx_floor when the formula enumerates only the four current content categories?"
]
}
},
"hegota:8141:human:r1": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "high",
"published_total": 38,
"recomputed_tier": "high",
"recomputed_total": 38,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "New per-frame gas isolation (`gas_limit` allocated per frame, not carried forward across frames) and new opcode gas costs (TXPARAM/FRAMEPARAM/SIGPARAM = 2, FRAMEDATALOAD = 3, FRAMEDATACOPY = 3 + word copy + mem expansion, APPROVE = 0). New mechanism, but applies only to type 0x06 frames and does not modify legacy tx gas accounting.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Frame tx carries EIP-4844 blob fields (`max_fee_per_blob_gas`, `blob_versioned_hashes`) but reuses existing blob gas accounting unmodified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "New complex refund mechanism: post-execution refund of gas to a designated `payer` resolved at runtime, plus full refund of skipped frames in failed atomic batches. Multiple refund paths; forces rework of existing refund-flow test infrastructure.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "New tx type is self-contained; legacy/1559/blob/7702 tx flows unchanged. Only minor impact on pre-existing opcode tests (new opcodes APPROVE/TXPARAM/FRAMEPARAM/SIGPARAM/FRAMEDATALOAD/FRAMEDATACOPY are globally available in the EVM regardless of tx type, so their behavior must be defined when invoked from legacy txs).",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No new block-environment fields, header inputs. Frame txs flow through standard EIP-2718 typed-tx dispatch. The one interface-side change is the receipt output schema, which gains a new shape for type 0x06: `[cumulative_gas_used, payer, [frame_receipt, ...]]` with a top-level `payer` field (resolved at runtime).",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Introduces P256 as a tx-authentication primitive for the first time via a scheme dispatcher (0x0 = SECP256K1, 0x1 = P256). Verification is defined as the P256VERIFY cryptographic operation.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Exceeds defined anchors: combinatorial explosion across mechanisms rather than a single elevated-case mechanism. Frame modes × flags × atomic-batch state × signature schemes × APPROVE scope matrix × default-code branches; further compounded by atomic batching, and cross-frame access.",
"raw_score_cell": "4",
"score": 4,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Two new RLP validation mechanisms that affect syncing clients: (1) the type 0x06 tx-RLP envelope; (2) the corresponding new receipt-RLP shape (important for receipts root).",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No new or modified Engine API endpoints, fields, or communication mechanisms.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": "None",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "`EXPIRY_VERIFIER` at address `0x8141`, installed by clients at fork activation.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "None",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Exceeds defined anchors: six new opcodes in a single EIP (~2-3× typical precedent of 1-2). Frame introspection. Signature metadata access. Testing will involve interaction with legacy txs types as well.",
"raw_score_cell": "4",
"score": 4,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Behavior of some opcodes like `ORIGIN` changes under the new transaction type.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "None",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "None",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "All encodings remain RLP — no format migration.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "New tx type 0x06 (frame transaction).",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "New intrinsic gas formula (mixed per-frame + per-signature + sum-of-frame-limits + calldata over two separate RLP streams), upfront multi-signature validation, frame-level constraints (mode/value/flags/count), runtime payer-designation and sender-approval. Introduces a post execution validity check which is totally new to EELS. Requires extensive test-infrastructure rework (filler intrinsic-gas computation, multi-scheme signing helpers etc).",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "None",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Clients install `EXPIRY_VERIFIER` runtime code at address `0x8141` at fork activation — a state modification at the activation block.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Per-tx cost scales with frame count (≤64) and signature count, but is bounded and parameterizable. New opcodes individually benchmarkable. Main new concern is mempool DoS surface from validation-prefix work on rejected txs. This however is capped. Doesn't materially change existing performance baselines for legacy/1559/blob/7702 txs.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Interacts with multiple critical subsystems: tx authentication (new multi-sig + scheme based dispatch), mempool relay policy, the EOA-vs-contract invariant (EIP-3607 relaxation lets contracts execute under SENDER mode), and ORIGIN semantics. The EIP itself enumerates non-trivial attack vectors: timestamp-dependency attack, deploy-frame front-running, state-read amplification via explicit sender, cross-frame privacy leakage, paymaster griefing, and mempool DoS via invalid `tx.sender` probing. Requires extensive review and fuzzing across protocol and mempool layers.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Strong interaction with FOCIL: FOCIL relies on attesters performing lightweight static validity checks (nonce + balance) on inclusion-list transactions without executing them. Frame transactions break this assumption.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8141,
"fork": "hegota",
"id": "hegota:8141:human:r1",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8141.yaml",
"sha256": "a7d7b4d1325cd9b34d879667fb5e8c05741f4130045be69ce90a65989d000fb6"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"known_source_defects": [
"The checklist contains Engine API encoding changes but the template has no dedicated definition for that row."
],
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"branch": "main",
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"committed_at": "2026-08-11T15:30:34Z",
"content_sha256": "5ee8d6adab64a924d9f86f45cd35263d062fc1fc73723894c24d4f698f9c5cd3",
"git_blob_sha": "c00d071cd8754c2f35214dd5d5cf34d3c80f8ff6",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/complexity_assessments/EIPs/EIP-8141.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-8141.md",
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 38,
"scored": true,
"source": "human",
"status": "complete",
"summary": null,
"tier": "high",
"title": "Frame Transaction",
"under_specification": null
},
"hegota:8141:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Accounting",
"source": "eip.md",
"summary": "Defines a new intrinsic-cost formula, explicit per-frame execution and state pools, transaction settlement, calldata-floor handling, and separate block-accounting dimensions."
},
{
"locator": "Specification > Gas Accounting > Transaction settlement",
"source": "eip.md",
"summary": "Composes unused frame gas, the existing storage refund counter, the calldata floor, and payer settlement into new transaction-level formulas."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal introduces a broad gas-accounting mechanism and changes how existing refund, calldata-floor, warm/cold, and block-accounting mechanisms apply to the new transaction, requiring regression coverage of those existing mechanisms.",
"score": 3,
"uncertainty_note": "The scope is clear, although some fee-settlement details are separately recorded as under-specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction > Behavior",
"source": "eip.md",
"summary": "Requires the resolved target's warm/cold access charge before the balance check and dispatch, and places new-account state charging after the balance check but before frame code executes."
},
{
"locator": "Specification > APPROVE Instruction (0xaa) > Behavior",
"source": "eip.md",
"summary": "Places a conditional sender-creation state-gas charge immediately before nonce increment and approval effects."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "New frame-entry and APPROVE state-accessing operations have consensus-critical access and charge positions that must be tested, but the proposal does not reorder an existing class of state-accessing opcodes.",
"score": 2,
"uncertainty_note": "EIP-8037 opcode charge points are explicitly retained; the score is for the new frame-level and APPROVE ordering boundaries.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Accounting > Blob handling",
"source": "eip.md",
"summary": "Makes blobs optional for frame transactions, makes the dynamically chosen payer the blob-fee payer, applies the blob base fee directly, and counts frame-transaction blobs against existing fork limits."
},
{
"locator": "Specification > Gas accounting",
"source": "supporting/eip-4844.md",
"summary": "Defines the pre-existing independent blob-gas and sender-paid blob-fee mechanism that EIP-8141 extends to its new envelope."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "A new blob-capable transaction and payer rule are introduced without changing the existing blob transaction's mechanism, so new tests are needed while pre-existing blob behavior remains intact.",
"score": 2,
"uncertainty_note": "The general blob path is explicit; broader fee-settlement omissions are tracked under under-specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Accounting > Frame gas pools",
"source": "eip.md",
"summary": "Replaces the EIP-8037 reservoir inside frame transactions with independent per-frame execution and state pools that cannot borrow from one another."
},
{
"locator": "Specification > Gas Accounting > State-gas attribution and refills",
"source": "eip.md",
"summary": "Introduces frame ownership records, cross-frame receipt reductions, frame-local refill rules, and journaling across call, frame, and atomic batch rollback boundaries."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "This is a new state-gas charging and attribution mechanism, including a deliberate change to the execution/state spill relationship and extensive interactions with existing state-gas tests.",
"score": 3,
"uncertainty_note": "No uncertainty affects the anchor level; individual omitted settlement details are recorded separately.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Accounting > Transaction settlement",
"source": "eip.md",
"summary": "Retains the EIP-3529 transaction-scoped storage refund counter and distinguishes state-gas refills, which directly reverse state charges, from capped EVM refunds."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM refund mechanism is introduced; the complex state-gas refill and attribution behavior is scored under state gas accounting rather than duplicated here.",
"score": 0,
"uncertainty_note": "Unused-budget repayment and state-gas refills are not treated as new EVM gas-refund mechanisms under this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Changes ORIGIN only in frame transactions and requires new two-dimensional estimation behavior, while leaving ordinary transaction execution outside the new envelope unchanged."
},
{
"locator": "Specification > Introspection",
"source": "eip.md",
"summary": "Assigns formerly unavailable instruction bytes and specifies exceptional halts for those instructions outside frame transactions."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor subset of existing invalid-instruction, generic transaction, receipt, and fork-transition tests must be adjusted; most existing tests do not change unless exercised through the new transaction type.",
"score": 1,
"uncertainty_note": "No packaged test inventory is available, so the affected subset is inferred from the protocol deltas rather than measured.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction > Receipt Encoding",
"source": "eip.md",
"summary": "The new payer and per-frame receipt values exist only for frame transactions rather than becoming an output of every transaction or test."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The proposal does not require tests unrelated to frame transactions to add a new universal assertion.",
"score": 0,
"uncertainty_note": "Activation-state tests are specific to this EIP and therefore do not constitute a new invariant on unrelated pre-existing tests.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Frame Transaction > Payload Encoding",
"source": "eip.md",
"summary": "Adds multiple nested transaction inputs for frames, signatures, fees, execution/state limits, and optional blob hashes."
},
{
"locator": "Specification > Frame Transaction > Receipt Encoding",
"source": "eip.md",
"summary": "Adds a payer plus a variable list of per-frame status, two-dimensional gas usage, and logs, including later mutation of earlier state-gas usage."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Transition tooling needs multiple new input and output fields together with a new multi-frame execution/result mechanism, satisfying the highest ordinary anchor.",
"score": 3,
"uncertainty_note": "The EIP does not specify a concrete transition-tool mapping, so exact field placement is an implementation question recorded under under-specification.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Frame Transaction > Receipt Encoding",
"source": "eip.md",
"summary": "Tests must express and inspect ordered per-frame receipts whose state-gas values can be changed by later frames."
},
{
"locator": "Specification > Frame Transaction > Behavior",
"source": "eip.md",
"summary": "Tests must construct frame sequences, approval context, skipped frames, and atomic-group rollback outcomes not representable as ordinary single top-level calls."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Reusable transaction builders and per-frame receipt/rollback expectation primitives are required within this EIP's suite, but the package does not establish adoption by other EIP suites.",
"score": 2,
"uncertainty_note": "The package contains no test-framework design, so the exact primitive split is not specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction Signatures",
"source": "eip.md",
"summary": "Introduces protocol-handled SECP256K1 and P256 signature schemes alongside structurally checked ARBITRARY witnesses, each with distinct encodings and costs."
},
{
"locator": "Specification > Signature Validation",
"source": "eip.md",
"summary": "Specifies canonical scalar bounds, low-s rules, signer recovery or public key derivation, and P256 proof verification before frame execution."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Multiple well-known cryptographic verification mechanisms are added to transaction validity; no novel cryptosystem is defined by the package.",
"score": 2,
"uncertainty_note": "The P256VERIFY helper is referenced but not defined or linked to a numbered EIP in the package.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction > Constraints",
"source": "eip.md",
"summary": "Defines numerous numeric, length, count, mode/flag, target, batch, blob, signature, and aggregate-gas boundaries, including a 64-frame maximum."
},
{
"locator": "Specification > Gas Accounting > State-gas attribution and refills",
"source": "eip.md",
"summary": "Requires outcomes across success, revert, exceptional halt, later refill, call rollback, frame rollback, and atomic-batch rollback."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms combine multiplicatively, especially frame ordering, cold/warm state, delegated/default/precompile dispatch, two gas pools, approvals, and nested rollback modes; this requires an elevated test matrix.",
"score": 3,
"uncertainty_note": "Some unspecified cases may add vectors, but the documented cases already satisfy score 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction > Payload Encoding",
"source": "eip.md",
"summary": "Introduces a deeply nested RLP transaction payload with variable frame and signature lists."
},
{
"locator": "Specification > Frame Transaction > Receipt Encoding",
"source": "eip.md",
"summary": "Introduces a distinct nested receipt payload with payer and per-frame status, gas, and logs."
},
{
"locator": "Specification > Networking",
"source": "eip.md",
"summary": "Requires sync/network paths to distinguish plain and blob-wrapped frame transactions and to encode the new receipt form."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Syncing clients face multiple RLP validation mechanisms, including complex transaction and receipt payloads; at least one is complex.",
"score": 3,
"uncertainty_note": "The score concerns execution-client block and receipt processing, not the consensus-layer sidecar protocol.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Networking",
"source": "eip.md",
"summary": "Specifies execution-network Receipts, PooledTransactions, and BlockBodies behavior but no Engine API field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The frame transaction is carried within existing payload transaction bytes; the EIP introduces no Engine API fields, objects, or methods.",
"score": 0,
"uncertainty_note": "EIP-7843 Engine API changes in a supporting document belong to that EIP and are not assigned to EIP-8141.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Expiry Verifier Frame",
"source": "eip.md",
"summary": "Requires clients to install fixed runtime code at EXPIRY_VERIFIER on activation; the code only checks calldata against block timestamp and has no persistent writes or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "One non-stateful system contract is added and it triggers no new consensus request or other system action.",
"score": 1,
"uncertainty_note": "How installation interacts with pre-existing state at the address is separately under-specified, but the contract's normal behavior is stateless.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Expiry Verifier Frame",
"source": "eip.md",
"summary": "Defines a newly installed verifier rather than changing the code or state of any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified by the specified frame-transaction behavior.",
"score": 0,
"uncertainty_note": "Ordinary ability to call an existing contract from a frame is not itself a modification of that contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > APPROVE Instruction (0xaa)",
"source": "eip.md",
"summary": "Adds a three-operand instruction that exits a call frame, returns memory, and conditionally updates approval, payer, nonce, balance, and state gas."
},
{
"locator": "Specification > Introspection",
"source": "eip.md",
"summary": "Adds TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM, and SIGDATACOPY, including dynamically metered memory-copy instructions."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Seven instructions are introduced and several are complex due to dynamic data, memory, stack, state, or transaction-context behavior.",
"score": 3,
"uncertainty_note": "No uncertainty affects the count or complexity classification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction > Behavior",
"source": "eip.md",
"summary": "Changes ORIGIN in every call depth of a frame transaction to return the frame caller rather than the traditional transaction origin."
},
{
"locator": "Specification > Gas Accounting > Blob handling",
"source": "eip.md",
"summary": "Extends existing BLOBHASH behavior to return the frame transaction's blob hashes in every frame."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least ORIGIN has a non-gas behavioral modification for the new transaction context, which mechanically selects score 3.",
"score": 3,
"uncertainty_note": "The score does not duplicate gas-only changes, which are handled in the gas anchors.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Signature Validation",
"source": "eip.md",
"summary": "Uses ecrecover and P256VERIFY as existing helpers and explicitly discusses the related precompiles; it does not allocate a new precompile address."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "Protocol-level invocation of an existing verification primitive is scored under cryptography, not as a new precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Signature Validation",
"source": "eip.md",
"summary": "States only that out-of-EVM signature checks must not add their related precompiles to the block-level access list; no precompile logic or gas schedule is changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Existing precompiles are invoked without modification.",
"score": 0,
"uncertainty_note": "The access-list side effect is a transaction-processing rule rather than a change to precompile behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction > Payload Encoding",
"source": "eip.md",
"summary": "Defines a new transaction-level RLP layout containing nested frames, limits, signatures, fees, and blob hashes."
},
{
"locator": "Specification > Frame Transaction > Receipt Encoding",
"source": "eip.md",
"summary": "Defines a new receipt-level encoding with payer and nested frame receipts."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Transaction and receipt encoding changes mechanically select score 3.",
"score": 3,
"uncertainty_note": "This score concerns the existence of the encoding change; individual field representation ambiguities are recorded separately.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction",
"source": "eip.md",
"summary": "Introduces an EIP-2718 transaction with FRAME_TX_TYPE 0x06."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "A new transaction type mechanically selects score 3.",
"score": 3,
"uncertainty_note": "No uncertainty affects this binary anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Frame Transaction > Constraints",
"source": "eip.md",
"summary": "Adds extensive structural and aggregate validity rules for the outer payload, signatures, frames, modes, flags, blobs, and gas limits."
},
{
"locator": "Specification > Frame Transaction > Behavior",
"source": "eip.md",
"summary": "Makes nonce, signature validation, VERIFY success, sender approval, payer approval, and post-execution payer presence transaction-validity gates."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The new validity model is execution-dependent and broad enough to require extensive transaction-test and validation-infrastructure work.",
"score": 3,
"uncertainty_note": "Several missing fee and helper details add uncertainty but cannot lower the documented mechanism below score 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Accounting > Block-level gas accounting",
"source": "eip.md",
"summary": "Uses the block header gas_used, block gas limit, and EIP-8037 accounting without defining an additional block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced by EIP-8141.",
"score": 0,
"uncertainty_note": "Internal block-output counters are not header fields.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Expiry Verifier Frame",
"source": "eip.md",
"summary": "Requires clients to install prescribed runtime bytecode at address 0x8141 at activation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation modifies state by installing contract code, mechanically selecting score 3.",
"score": 3,
"uncertainty_note": "Collision and account-field handling at the destination are not specified, but the required state modification itself is explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Mempool",
"source": "eip.md",
"summary": "Requires signature validation, validation-prefix simulation, dependency tracking, payer reservation, replacement accounting, and selective re-simulation for public propagation."
},
{
"locator": "Security Considerations > Transaction Propagation",
"source": "eip.md",
"summary": "Identifies denial-of-service vectors from arbitrary EVM validation, shared-state invalidation, and explicit sender state-read amplification."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance cannot be validated in isolation because transaction admission, arbitrary validation execution, state dependency tracking, multi-frame journaling, payer exposure, and blob networking interact with core client paths and existing benchmarks.",
"score": 3,
"uncertainty_note": "The package provides no measurements, but it explicitly establishes the coupled mechanisms and DoS workload requiring validation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Documents propagation DoS, deploy front-running, sender-read amplification, signature malleability, cross-frame visibility, state-gas isolation, and over-broad execution approval hazards."
},
{
"locator": "Specification > APPROVE Instruction (0xaa) > Behavior",
"source": "eip.md",
"summary": "Moves authentication, sender authority, nonce consumption, fee escrow, and payer selection into contract-driven frame execution."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The proposal substantially alters security assumptions across transaction authentication, account authority, fee payment, mempool admission, networking, execution, and rollback, requiring extensive review and fuzzing.",
"score": 3,
"uncertainty_note": "Missing canonical-paymaster and helper details increase review uncertainty but do not change the score.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Gas Accounting > Transaction settlement",
"source": "eip.md",
"summary": "Uses effective_gas_price and payer max-cost collection without fully defining EIP-1559 fee validity, priority-fee disposition, and all payer balance/escrow steps in this transaction model."
},
{
"locator": "Specification > Mempool > Paymasters",
"source": "eip.md",
"summary": "Requires exact canonical-paymaster runtime matching and pending-withdrawal accounting without providing the canonical implementation, while separate passages disagree on whether non-canonical paymasters are eligible."
},
{
"locator": "Specification > Expiry Verifier Frame",
"source": "eip.md",
"summary": "Requires activation-time code installation without defining the result if the destination already has balance, nonce, code, or storage."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Several constructible fee, activation, cryptographic-helper, and public mempool cases need agreement before interoperable baselines can be written. They are material but are localized omissions in newly introduced mechanisms, rather than a formerly unobservable behavior newly exposed by the proposal.",
"score": 2,
"uncertainty_note": "The package contains no permitted implementation, devnet, or discussion evidence, so this score is based only on the Draft text's internal coverage.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter > requires",
"source": "eip.md",
"summary": "Declares thirteen required EIPs spanning fee markets, typed envelopes, intrinsic and state gas, refunds, sender validity, blobs, networking, calldata floors, delegation, transfer logs, block accounting, and the transaction execution cap."
},
{
"locator": "Specification > Frame Transaction > Cross-frame interactions",
"source": "eip.md",
"summary": "Directly composes warm/cold initialization, coinbase warming, delegation, rollback, and state-gas ownership behavior across frames."
},
{
"locator": "Specification > Mempool > Banned Opcodes",
"source": "eip.md",
"summary": "Adds coordinated public-mempool handling for SLOTNUM and SETDELEGATE and the broader validation-prefix opcode/state rules."
},
{
"locator": "Specification > Networking",
"source": "eip.md",
"summary": "Reuses typed-envelope and PeerDAS blob-wrapper rules for plain and blob-carrying frame transactions."
}
],
"exceptional_score_justification": "This is not a discretionary exceptional score; it is the rubric's uncapped cross-EIP formula applied mechanically to 23 identified interactions.",
"id": "cross_eip_interactions",
"interacting_eips": [
2,
1559,
2718,
2780,
2929,
3529,
3607,
3651,
4844,
6780,
7594,
7623,
7702,
7708,
7778,
7819,
7825,
7843,
7928,
7976,
7997,
8037,
8038
],
"rationale": "Strong coordinated coverage is required for EIPs 2, 1559, 2718, 2780, 2929, 3529, 3607, 3651, 4844, 6780, 7594, 7623, 7702, 7708, 7778, 7819, 7825, 7843, 7928, 7976, 7997, 8037, and 8038. With 23 identified EIPs, the uncapped rule gives base 3 plus floor((23 - 3) / 3) = 6, for score 9.",
"score": 9,
"uncertainty_note": "Mere motivational examples involving ERC-20 and ERC-4337, and inspiration from unavailable ERC-7562, were not counted because the specified protocol does not depend on their behavior.",
"under_specified": false,
"unidentified_interactions": [
"Existing P256VERIFY precompile semantics are used for protocol-level P256 signature validation, but the package identifies no corresponding EIP number."
]
}
],
"eip": 8141,
"evaluation_date": "2026-09-11",
"fork": "hegota",
"id": "hegota:8141:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The canonical-paymaster section says a paymaster transaction is eligible only for an exact canonical code match, while the immediately following non-canonical section defines an admission cap and balance checks for non-canonical paymasters.",
"compute_sig_hash is expressed by mutating signature bytes in tx rather than explicitly hashing a copy, leaving the lifetime of that mutation implicit.",
"Frame target nullability and several integer domains are constrained at a semantic level, but their exact RLP scalar/null representations are not exhaustively stated."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "68c512f08bb644372c42a654188ce953bc6c021dc0fc71a3a9059e594ffe364e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8141.md",
"git_blob_sha": "fb1336b35f49c730fa9e70bef8ebf2e2ca187228",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8141.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8141.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8141.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/extensions/sfi-cfi-2026-08-26/outputs/assessments/eip-8141.yaml",
"sha256": "2e9780ddf89bb0985c889bcc69a38b2c8cc162aca530fd0368448e0fe1ef5988"
},
"supporting_documents": [
"supporting/eip-20.md",
"supporting/eip-1559.md",
"supporting/eip-2718.md",
"supporting/eip-2780.md",
"supporting/eip-2929.md",
"supporting/eip-3529.md",
"supporting/eip-3607.md",
"supporting/eip-3651.md",
"supporting/eip-4337.md",
"supporting/eip-4844.md",
"supporting/eip-6780.md",
"supporting/eip-7594.md",
"supporting/eip-7623.md",
"supporting/eip-7702.md",
"supporting/eip-7708.md",
"supporting/eip-7778.md",
"supporting/eip-7819.md",
"supporting/eip-7825.md",
"supporting/eip-7843.md",
"supporting/eip-7976.md",
"supporting/eip-7997.md",
"supporting/eip-8037.md",
"supporting/eip-8038.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 60,
"scored": true,
"snapshot_id": "hegota-sfi-cfi-2026-08-26-ac450a4",
"snapshot_status": "CFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the Draft EIP-8141 text frozen at the 2026-08-26 Hegota snapshot. The assessed surface is the new typed frame transaction, its validation and per-frame execution model, gas payment and two-dimensional gas accounting, receipt and networking encodings, EVM instructions, activation-time expiry verifier, and public-mempool policy.",
"tier": "high",
"title": "Frame Transaction",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"cryptography",
"new_fork_activation_mechanism",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 61,
"minimum": 58
},
"present": true,
"summary": "The Draft specifies the central frame execution and gas mechanisms in substantial detail, but leaves material interoperability gaps in fee validation and settlement, the P256 verification dependency, activation-state handling, transition/test interfaces, and public-mempool paymaster rules. These gaps are recorded once here and are not multiplied across unrelated anchors.",
"unresolved_questions": [
"Which exact EIP-1559 validity checks, effective-gas-price calculation, priority-fee transfer, base-fee burn, and escrow order apply when payer and sender differ?",
"What happens at activation if EXPIRY_VERIFIER already has a balance, nonce, code, or storage, and which account fields must the irregular transition preserve or replace?",
"Which precise P256VERIFY primitive and failure semantics are consensus inputs to protocol-level P256 signature validation?",
"What is the canonical paymaster runtime code and delayed-withdrawal state layout, and are non-canonical paymasters admitted to the public mempool?",
"How are the nested transaction fields, mutable per-frame receipt values, and two-dimensional block outputs represented in transition-tool and test framework interfaces?"
]
}
},
"hegota:8146:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 19,
"recomputed_tier": "medium",
"recomputed_total": 19,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Every `blockchain_test_engine` fixture changes delivery shape: the BAL leaves the payload and arrives via a separate engine call, so the engine fixture format and its consumption flow are reworked. The engine format spans every test in the fork, so the rework crosses the entire fixture set.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Engine-fixture format version plus consume-engine sequencing machinery (notify-then-payload ordering, queueing, missing/mismatched-BAL cases) — permanent framework-level infrastructure exercised beyond this EIP.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple bounded mechanisms: BAL-before/after-payload ordering, payload queued awaiting BAL, missing BAL, commitment mismatch, duplicate delivery, the 8 MiB size bound.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "A new endpoint (`engine_notifyBlockAccessListV1`) plus a modified one (`engine_getPayloadV6` returns the BAL as a separate field); `engine_newPayloadV5` drops the BAL.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Prefetching and parallel post-state-root computation are MAY-behaviors, benchmarkable in isolation; the EIP's latency goals live on the CL side.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Availability/queueing surface (payloads parked awaiting a BAL, BALs stored by blockHash across reorgs) interacts with the block-delivery path; targeted review.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "EL-side semantics need agreement before consume tests can be baselined: queue timeout/eviction, behavior when the BAL never arrives, reorg handling of stored BALs; localized to the engine layer.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Structurally dependent on EIP-7732 (envelope, PTC) and EIP-7928 (moves its object); coordinated testing with EIP-7805 (the motivating FOCIL interaction) and EIP-8268 (encoding inside the sidecar). Strong interdependencies; no +1 increment (four interacting).",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8146,
"fork": "hegota",
"id": "hegota:8146:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8146.yaml",
"sha256": "019e2ddf991cde7c14fb39bc5116e6c34d5cf8c611a002244547b5c9d1c2838b"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "5963e7a7e1eb846a5dbce552d233255ca0583cba",
"content_sha256": "31857ce936b0b3f414e876919401927665d1ef61873fdb6ae34eb5007aad1141",
"git_blob_sha": "4f6d996a10d74987d39370741674c8ca3885ff39",
"immutable_url": "https://github.com/ethspecs/pm/blob/5963e7a7e1eb846a5dbce552d233255ca0583cba/complexity_assessments/EIPs/EIP-8146.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8146.md",
"pull_request": {
"draft": false,
"number": 106,
"title": "Add EIP-8146 complexity assessment",
"updated_at": "2026-08-17T15:24:38Z",
"url": "https://github.com/ethspecs/pm/pull/106"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 19,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "Block Access List Sidecars",
"under_specification": null
},
"hegota:8146:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The EL block-access-list construction and validation rules remain those of EIP-7928; this proposal changes delivery rather than EVM gas accounting."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas schedule or gas-accounting mechanism is added or modified on the execution layer.",
"score": 0,
"uncertainty_note": "The package specifies no gas-rule change; performance motivation for future gas-limit increases is not itself a gas-accounting change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "BAL construction and validation rules are explicitly left unchanged from EIP-7928."
},
{
"locator": "Specification > Gas Validation Before State Access",
"source": "supporting/eip-7928.md",
"summary": "The inherited proposal defines the opcode state-access and gas-validation ordering that determines BAL inclusion."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "EIP-8146 does not change inherited within-opcode access or gas-charge ordering; it only transports the resulting BAL separately.",
"score": 0,
"uncertainty_note": "No EIP-8146 text reopens or overrides the inherited opcode-ordering rules.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Engine API > engine_newPayloadV5",
"source": "eip.md",
"summary": "The existing payload call is described as unchanged apart from the BAL being delivered separately; no blob-gas rule is specified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas accounting mechanism or value is changed.",
"score": 0,
"uncertainty_note": "Consensus-side blob availability is mentioned only to distinguish it from BAL availability and is outside the scored EL surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution-layer change preserves EIP-7928 BAL construction and validation and introduces no state-writing gas budget or charge."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas charging site, rate, reservoir, budget, or spill interaction is introduced or modified.",
"score": 0,
"uncertainty_note": "Prefetching state is a performance operation, not a state-gas charge.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The proposal confines the EL change to BAL delivery and retains existing BAL validation rules."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "The package contains no refund-rule amendment attributable to EIP-8146.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Engine API",
"source": "eip.md",
"summary": "BAL and payload delivery are split, getPayload returns the BAL separately, and the new notify call must precede newPayload for the same block hash."
},
{
"locator": "Specification > Engine API",
"source": "supporting/eip-7928.md",
"summary": "The inherited BAL flow put blockAccessList in ExecutionPayloadV4 and had engine_newPayloadV5 validate that supplied field."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing Engine API tests for the EIP-7928 BAL path require considerable but category-local reworking to remove BAL delivery from newPayload, issue the notification first, and pair both calls by block hash.",
"score": 2,
"uncertainty_note": "The package seals no implementation or test inventory, so the affected test count is inferred only from the specified replacement of the BAL API flow.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Engine API",
"source": "eip.md",
"summary": "For a given blockHash, engine_notifyBlockAccessListV1 must be called before engine_newPayloadV5, and the EL may rely on BAL presence at payload delivery."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The broad class of post-fork Engine API payload tests gains a mechanical ordering-and-pairing invariant even when the test's subject is not sidecar propagation; this is broader than a contrived case but not every EL test.",
"score": 2,
"uncertainty_note": "The package does not define which test families exercise CL-to-EL delivery, so the precise breadth below all fork tests is uncertain.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "Execution semantics and BAL construction/validation are unchanged; the new transport is specified under the Engine API."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The EIP does not require a new transition-tool field or mechanism because its scored change is asynchronous Engine API delivery, not a state-transition input or output change.",
"score": 0,
"uncertainty_note": "No transition-tool section is provided, but no changed transition semantics establish a need to extend that interface.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Engine API > New engine_notifyBlockAccessListV1",
"source": "eip.md",
"summary": "A new two-parameter Engine API method delivers a BAL independently before payload submission."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "An Engine API test harness needs a minor extension to issue the new method and express the required before-newPayload sequence, while ordinary call/result assertions should otherwise suffice.",
"score": 1,
"uncertainty_note": "The sealed package contains no test-framework description, so whether this is merely a helper addition or a reusable new expectation primitive is unresolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Single Commitment, Shared Across Layers",
"source": "eip.md",
"summary": "The design reuses the EIP-7928 keccak256 commitment and explicitly avoids a second hashing scheme."
},
{
"locator": "Rationale > No Separate Signature",
"source": "eip.md",
"summary": "No separate sidecar signature or new signature scheme is introduced."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Existing Keccak-256 commitment verification is reused; no new cryptographic mechanism is added on the execution layer.",
"score": 0,
"uncertainty_note": "A new CL dependency on an existing Keccak implementation is not new cryptography and is outside the scored EL surface.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Engine API",
"source": "eip.md",
"summary": "BAL and payload are separate calls keyed by blockHash, with mandatory ordering and a best case in which the BAL precedes the payload."
},
{
"locator": "Specification > Fork Choice > Modified on_execution_payload_envelope",
"source": "eip.md",
"summary": "The envelope-first arrival case is cached and replayed only after the BAL is delivered, establishing an EL-facing ordering boundary."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone cases require testing: BAL/payload hash pairing, separate arrival timing, missing or mismatched notifications, and minimum or maximum BAL payloads. The EIP constrains the valid call order, limiting the combinatorial burden below the highest anchor.",
"score": 2,
"uncertainty_note": "Duplicate, conflicting, late, and orphaned notifications are not specified, so the final number of execution-client boundary cases is uncertain.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The EL block header commitment is unchanged from EIP-7928; the EIP changes propagation of the committed BAL rather than block RLP validation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new execution-block RLP validation mechanism requiring client block-sync testing is introduced.",
"score": 0,
"uncertainty_note": "CL sidecar req/resp and retention requirements are not scored as EL block syncing under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Engine API > engine_getPayloadV6",
"source": "eip.md",
"summary": "getPayload returns a separate blockAccessList field alongside the ExecutionPayload."
},
{
"locator": "Specification > Engine API > New engine_notifyBlockAccessListV1",
"source": "eip.md",
"summary": "A new endpoint takes blockAccessList and blockHash and triggers storage and prefetch work."
},
{
"locator": "Specification > Engine API > engine_newPayloadV5",
"source": "eip.md",
"summary": "newPayload no longer carries the BAL and must follow the matching notify call."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "Multiple Engine API fields are introduced or relocated across the get and notify paths, and a new endpoint is added, satisfying the score-3 anchor.",
"score": 3,
"uncertainty_note": "The exact JSON response and error schemas are omitted, but the endpoint and its multiple parameters plus the getPayload field are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution-layer change is limited to BAL delivery and validation."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "System-contract accesses recorded by the inherited BAL are not contracts added by EIP-8146.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "BAL construction and validation remain those of EIP-7928."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system-contract code, state, or behavior is modified.",
"score": 0,
"uncertainty_note": "Prefetching entries that may include system-contract state has no specified behavioral effect on those contracts.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The EIP retains existing execution and BAL validation rules."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No opcode-table or EVM-instruction change appears in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The proposal states that BAL construction and validation are unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode result or non-gas behavior is modified.",
"score": 0,
"uncertainty_note": "Inherited EIP-7928 observability rules are not changed by sidecar transport.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "Only BAL transport and early EL processing are specified."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "The package specifies no precompile address or call behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "Existing execution and BAL validation semantics are retained."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "Precompiles may be represented in a BAL under EIP-7928, but EIP-8146 does not change their behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Engine API",
"source": "eip.md",
"summary": "The BAL remains RLP-encoded bytes when returned by getPayload and delivered through notifyBlockAccessList."
},
{
"locator": "Rationale > Single Commitment, Shared Across Layers",
"source": "eip.md",
"summary": "The existing keccak256 of the RLP-encoded BAL is reused unchanged."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The execution-layer interface relocates an existing RLP byte sequence but does not switch or alter its encoding.",
"score": 0,
"uncertainty_note": "New and modified SSZ containers are consensus-layer work and are excluded by the execution-only assessment boundary.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The proposal changes BAL propagation, not transaction envelopes."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "FOCIL transaction filtering is a stated benefit, not a transaction-type change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "BAL construction and validation rules stay as specified in EIP-7928."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "EIP-8146 introduces no transaction validity or intrinsic-gas rule; it changes when auxiliary BAL data reaches the EL.",
"score": 0,
"uncertainty_note": "Its stated benefit to FOCIL builders filtering invalidated transactions does not impose a new EIP-8146 transaction-validity rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The execution block header block_access_list_hash field is explicitly unchanged from EIP-7928."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new execution block or execution header field is introduced.",
"score": 0,
"uncertainty_note": "The new field in the CL ExecutionPayloadBid is outside the execution-layer scoring boundary.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer",
"source": "eip.md",
"summary": "The EL header and BAL validation rules remain unchanged, with no activation block state mutation specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No execution state, pre-existing internal variable, or irregular transition is modified at fork activation.",
"score": 0,
"uncertainty_note": "Activation of a new RPC capability is not a state or internal-variable mutation under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "A roughly 70 KiB average and potentially large BAL is moved off the payload critical path to create an execution prefetch head start."
},
{
"locator": "Specification > Engine API > New engine_notifyBlockAccessListV1",
"source": "eip.md",
"summary": "On notification, the EL stores the BAL, warms state through prefetching, and may begin parallel post-state-root computation."
},
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The stated objective is shorter payload propagation and validation to make slot-time headroom available for gas-limit increases."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The mechanism deliberately changes performance on the payload-validation critical path and couples network arrival, Engine API scheduling, state-cache behavior, execution, and optional parallel root computation. It cannot be validated fully in isolation and substantially affects existing performance benchmarks, meeting score 3.",
"score": 3,
"uncertainty_note": "The package supplies size claims and sequencing but no benchmarks, and it leaves the optional precomputation strategy implementation-defined.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Engine API > New engine_notifyBlockAccessListV1",
"source": "eip.md",
"summary": "The EL stores and acts on BAL bytes before payload arrival by prefetching and optionally computing a post-state root."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The EIP identifies withholding, network overhead, and hashing up to the maximum BAL size, while retaining payload validation as the safety gate."
},
{
"locator": "Security Considerations > Early Rejection of Malicious BALs",
"source": "supporting/eip-7928.md",
"summary": "The inherited BAL design recognizes malicious declarations can force unnecessary I/O and defer rejection until execution advances."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Early action on builder-committed but not yet execution-validated BAL data touches the Engine cache, state I/O, and later payload validation, slightly altering resource-exhaustion and correct-pairing assumptions and warranting targeted review and fuzzing.",
"score": 2,
"uncertainty_note": "Notify-call input validation, cache bounds, eviction, duplicates, and errors are unspecified, preventing a firmer assessment of the risk envelope.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Engine API > New engine_notifyBlockAccessListV1",
"source": "eip.md",
"summary": "The method defines parameters and successful EL actions but no response, error, duplicate, conflict, malformed-input, or lifecycle behavior."
},
{
"locator": "Specification > Engine API > engine_getPayloadV6",
"source": "eip.md",
"summary": "The BAL is said to be a separate response field, but the exact response container and failure semantics are not specified."
},
{
"locator": "Specification > Engine API > engine_newPayloadV5",
"source": "eip.md",
"summary": "The EL must pair a previously delivered BAL by blockHash, but orphaned, repeated, or conflicting entries are not resolved in the text."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Multiple test-constructable details require client agreement before Engine API tests can be baselined. The gaps are material but localized to the new asynchronous delivery and cache protocol, matching score 2 rather than a protocol-wide re-baselining.",
"score": 2,
"uncertainty_note": "The EIP is Draft and the sealed package contains no permitted implementation, devnet, discussion-thread, or test evidence with which to resolve these gaps.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Preamble > requires",
"source": "eip.md",
"summary": "EIP-8146 explicitly requires EIPs 7732 and 7928."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "It modifies EIP-7732 payload and bid containers and changes propagation of EIP-7928 BALs."
},
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The early BAL is also designed to help EIP-7805 inclusion-list builders avoid transactions invalidated by the pending block."
},
{
"locator": "Specification > Execution Layer",
"source": "supporting/eip-7805.md",
"summary": "EIP-7805 performs post-payload validity checks for omitted inclusion-list transactions, the operation the early BAL is intended to assist."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7732,
7805,
7928
],
"rationale": "The proposal strongly composes EIP-7732's separated payload delivery with EIP-7928's BAL commitment and validation, requiring coordinated vectors for both, while also creating an explicit but more limited EIP-7805 interaction. Three interacting EIPs and two deep interdependencies justify score 3; no uncapped increment applies because there are not more than three.",
"score": 3,
"uncertainty_note": "The EIP-7805 benefit is motivational rather than a normative dependency, but it still calls for interaction testing where both mechanisms are enabled.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8146,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8146:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The claimed protocol-enforced one-second useful-work window does not align cleanly with the specified envelope-first case, which says the eventual EL head start is zero; this affects performance expectations but not the existence of the performance-testing burden.",
"EIP-7928 describes engine_newPayloadV5 as accepting an ExecutionPayloadV4 that contains blockAccessList, whereas EIP-8146 says engine_newPayloadV5 is unchanged yet does not carry the BAL. The intended replacement flow is evident, but the precise versioned interface definition is not provided.",
"CL validation hashes opaque BAL bytes and the EL begins work immediately, but the point at which malformed RLP is rejected before or during speculative EL work is not stated."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "6ae7e9e4ae78701183d38ac322c5d28f29691852371c1c390eec7b6c2bb2effd",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8146.md",
"git_blob_sha": "2b8ad5f28661fed292923ceb22a2f8ab09d0b523",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8146.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8146.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8146.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8146.yaml",
"sha256": "b4458238454c674a7f91804f4b5bc10a770b1c05ddcdc271f7b29b49d3c7fda6"
},
"supporting_documents": [
"supporting/eip-7732.md",
"supporting/eip-7805.md",
"supporting/eip-7928.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 20,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the draft EIP-8146 snapshot. The scored surface separates the EIP-7928 RLP-encoded block access list from payload delivery, adds early BAL delivery and block-hash pairing through the Engine API, and enables EL prefetching or optional post-state-root computation. CL sidecar gossip, PTC voting, fork choice, and SSZ-container work are boundary context and are not scored as execution-layer complexity.",
"tier": "medium",
"title": "Block Access List Sidecars",
"under_specification": {
"affected_criteria": [
"new_test_framework_primitives",
"edge_boundary_conditions",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 22,
"minimum": 17
},
"present": true,
"summary": "The new asynchronous Engine API protocol is materially under-specified. Its happy path and required notify-before-newPayload order are clear, but its response and error schemas, malformed input handling, duplicate or conflicting notifications, blockHash cache lifetime and eviction, and orphan/reorg behavior are not. These are one connected API-lifecycle gap and are not separately multiplied across unrelated EVM anchors.",
"unresolved_questions": [
"What result and error objects does engine_notifyBlockAccessListV1 return for success, malformed RLP, an unknown blockHash, or resource-limit failure?",
"How must the EL handle duplicate or conflicting BAL notifications for the same blockHash, including a notification after payload processing?",
"What cache bounds, retention, eviction, and reorg/orphan rules apply to BALs received for payloads that arrive late or never arrive?",
"What is the exact engine_getPayloadV6 response container after blockAccessList is removed from the ExecutionPayload, and how is that shape versioned?"
]
}
},
"hegota:8148:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "The new system call has a dedicated 30,000,000 gas limit; its gas is excluded from block gas accounting and block gas-limit checks, it transfers no value under EIP-1559 semantics, and it is exempt from the EIP-7825 transaction cap."
},
{
"locator": "Specification > Execution layer > Withdrawal Request Contract > System Call",
"source": "supporting/eip-7002.md",
"summary": "The sealed baseline already defines the same dedicated, block-excluded gas treatment for an existing request-predeploy system call."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "EIP-8148 extends an existing special system-call gas-accounting pattern to one new mandatory call. This updates the set of calls using the existing mechanism rather than creating a distinct gas-accounting mechanism.",
"score": 1,
"uncertainty_note": "The gas exclusions are explicit, but the rubric does not state whether another instance of an existing system-call pattern should be treated as a mechanism update or a new mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Bytecode",
"source": "eip.md",
"summary": "The proposal supplies bytecode for a new contract using existing EVM operations; it specifies no change to state access or gas-charge ordering inside an opcode."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Contract-level SLOAD and SSTORE sequencing is new program behavior, not a change to the consensus semantics or internal state-access ordering of any opcode.",
"score": 0,
"uncertainty_note": "No package evidence indicates an opcode-internal ordering change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants > Execution layer",
"source": "eip.md",
"summary": "The constants define request-queue, fee, and system-contract parameters and no blob gas parameter or blob gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The execution-layer proposal does not alter blob gas accounting.",
"score": 0,
"uncertainty_note": "No blob mechanism appears in any specified EIP-8148 execution path.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract",
"source": "eip.md",
"summary": "The contract performs ordinary EVM storage reads and writes for its queue, count, and excess value; it defines no StateGasCosts, state-byte rate, state budget, or spill path."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Persistent contract storage is introduced, but no state-gas accounting rule is changed.",
"score": 0,
"uncertainty_note": "No rubric-defined state-gas mechanism is specified in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Add Set Sweep Threshold Request",
"source": "eip.md",
"summary": "The call only requires msg.value to cover the dynamic request fee and specifies no EVM gas refund or modification to refund accounting."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The request fee is value paid to a contract, not an EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "No refund behavior is introduced by the execution-layer specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "Every execution block from FORK_BLOCK performs an additional stateful system call after all transactions, and missing code or call failure invalidates the block."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal states that it makes backwards-incompatible changes to block structure and block validation rules."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork block/state-transition cases across transaction, gas-boundary, invalid-block, and synchronization categories must incorporate the mandatory call, predeploy state, and request output, so a diverse major subset is reworked.",
"score": 3,
"uncertainty_note": "The package contains no test inventory, so the exact fraction of pre-existing vectors is uncertain even though the every-block transition is explicit.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request",
"source": "eip.md",
"summary": "Dequeued requests must be emitted as type 0x03 request data, with threshold encoded little-endian."
},
{
"locator": "Specification > Execution Layer > Block Header",
"source": "supporting/eip-7685.md",
"summary": "All non-empty request objects are ordered by request type and committed through requests_hash, while empty request data is excluded."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad set of post-fork request-aware vectors gains mechanical expected-output and commitment checks for type 0x03. The stable empty-request hash prevents this from forcing a new non-empty assertion in every test or re-deriving pre-fork vectors.",
"score": 2,
"uncertainty_note": "The sealed package does not describe the test harness, so whether all broad request assertions are already generic is not established.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract",
"source": "supporting/eip-7685.md",
"summary": "The existing general-purpose request bus abstracts request details so new request types do not require an execution block-structure update."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request",
"source": "eip.md",
"summary": "EIP-8148 adds one request type and opaque request data but specifies no transition-tool field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The existing EIP-7685 request mechanism can carry type 0x03 without a specified tool-interface change.",
"score": 0,
"uncertainty_note": "The EIP does not describe transition-tool integration explicitly.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale > Overview",
"source": "eip.md",
"summary": "The message format, queue, and rate limiting deliberately follow the existing EIP-7002 request mechanism."
},
{
"locator": "Specification > Execution layer > Withdrawal Request Contract",
"source": "supporting/eip-7002.md",
"summary": "The sealed supporting EIP already supplies the analogous add, fee-getter, queue, and system-process testing shape."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing request-contract and state-transition test primitives are sufficient for the analogous new type.",
"score": 0,
"uncertainty_note": "The package does not enumerate available framework helpers, but it specifies no novel expectation type or modifier.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer",
"source": "eip.md",
"summary": "The execution surface consists of fixed-width request fields, a stateful EVM contract, SSZ serialization, and a system call; it introduces no cryptographic primitive."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No new or modified cryptographic mechanism is part of EIP-8148's execution-layer behavior.",
"score": 0,
"uncertainty_note": "EIP-7685 hashing is an existing framework behavior, not introduced by EIP-8148.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract",
"source": "eip.md",
"summary": "The contract distinguishes exactly 56-byte input, zero-byte fee reads, and the system caller; it checks fee sufficiency and special call-value conditions."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "Queue processing spans empty, partially drained, and fully drained states, caps dequeue at 16, updates excess around a target of 2, handles the inhibitor, resets counts, and invalidates blocks on missing code or failure."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple independent boundary-prone mechanisms combine: calldata length and value, dynamic fee/inhibitor arithmetic, queue head-tail arithmetic and reset, the 16-request cap, endian packing, fork-first-call behavior, and fatal system-call outcomes. The cross-product requires an elevated case count.",
"score": 3,
"uncertainty_note": "Exact deployment artifacts are TBD, but the specified boundary set already meets score 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation",
"source": "supporting/eip-7685.md",
"summary": "The general request framework is designed so adding request types does not update the execution block structure."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request",
"source": "eip.md",
"summary": "EIP-8148 uses the existing request object and specifies no new block RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "The proposal changes block validity through request processing, but not the rubric-specific block RLP validation mechanism.",
"score": 0,
"uncertainty_note": "No RLP change is present in the sealed EIP-8148 execution specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution Layer > Requests",
"source": "supporting/eip-7685.md",
"summary": "The existing interface-level object carries a request-type byte plus opaque request data."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request",
"source": "eip.md",
"summary": "The proposal defines type 0x03 within that existing object and adds no Engine API endpoint or field."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No new Engine API field, endpoint, or communication mechanism is specified.",
"score": 0,
"uncertainty_note": "Engine API mechanics are not discussed in EIP-8148, so the zero rests on the sealed generic EIP-7685 carrier.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract",
"source": "eip.md",
"summary": "A new predeploy stores queue entries, queue pointers, per-block count, and excess, and emits dequeued requests for consensus-layer processing through a system call."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Exactly one new system contract is introduced, and it is both stateful and triggers a new execution-to-consensus request action.",
"score": 2,
"uncertainty_note": "The address and deployment transaction are TBD, but the contract's stateful role is unambiguous.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Constants > Execution layer",
"source": "eip.md",
"summary": "The proposal allocates a distinct new predeploy and distinct storage slots for its request mechanism; it does not alter the code or state layout of an existing predeploy."
},
{
"locator": "Specification > Execution Layer > Requests",
"source": "supporting/eip-7685.md",
"summary": "Different request types coexist as separate opaque request objects in the existing bus."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Adding an independent request producer does not directly or indirectly modify an existing system contract's behavior.",
"score": 0,
"uncertainty_note": "Cross-type request ordering changes the aggregate request list, but not the behavior of the pre-existing contracts themselves.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Bytecode",
"source": "eip.md",
"summary": "The supplied contract bytecode is composed of existing EVM instructions and assigns no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "EIP-8148 adds contract code, not an opcode.",
"score": 0,
"uncertainty_note": "No opcode addition is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Bytecode",
"source": "eip.md",
"summary": "The proposal uses CALLER, SLOAD, SSTORE, calldata, memory, and control-flow operations without redefining their results."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "System-call gas treatment is scored under gas rules and does not change an opcode result.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Deployment",
"source": "eip.md",
"summary": "The new component is explicitly deployed like a smart contract, not defined as a precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "The deployment details are incomplete but the component type is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer",
"source": "eip.md",
"summary": "The specified execution changes concern a new smart contract and system call and identify no existing precompile."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "No precompile interaction is specified in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request",
"source": "eip.md",
"summary": "A new fixed-field request containing Bytes20, Bytes48, and uint64 is introduced, with the threshold returned little-endian."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "The system call returns concatenated SSZ-serialized requests which become EIP-7685 block request data in exact dequeue order."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "A new SSZ-encoded request payload is introduced at the block/interface request layer, meeting the rubric's binary score-3 condition.",
"score": 3,
"uncertainty_note": "The outer EIP-7685 envelope is unchanged, but the new type's payload encoding is consensus-visible block/interface data.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Add Set Sweep Threshold Request",
"source": "eip.md",
"summary": "Users submit requests by calling the predeploy with calldata and value; no transaction envelope or type byte is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The request type is an EIP-7685 request type, not a new transaction type.",
"score": 0,
"uncertainty_note": "No transaction-format change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract",
"source": "eip.md",
"summary": "Invalid calldata or insufficient value causes contract execution to revert; no existing transaction's protocol validity or intrinsic gas is changed."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "The EIP-7825 exemption applies to the protocol system call, not to user transactions."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Contract-call success rules and system-call validity do not modify transaction validity or intrinsic gas calculation.",
"score": 0,
"uncertainty_note": "No txpool or transaction-envelope validation change appears in EIP-8148.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution Layer > Block Header",
"source": "supporting/eip-7685.md",
"summary": "The existing EIP-7685 framework already supplies requests_hash for request objects."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request",
"source": "eip.md",
"summary": "EIP-8148 adds a type within that request list and specifies no new execution block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new execution-layer block/header field is introduced by this EIP.",
"score": 0,
"uncertainty_note": "Consensus-layer container changes are outside the required execution-layer scoring scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Definitions",
"source": "eip.md",
"summary": "FORK_BLOCK is the first block after activation."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "Starting at FORK_BLOCK, the mandatory call updates queue state, converts the EXCESS_INHIBITOR path to ordinary excess state, and resets the per-block count."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The activation block performs a new mandatory state transition in the predeploy, satisfying the rubric's binary score-3 condition.",
"score": 3,
"uncertainty_note": "The exact predeploy address and deployment transaction are TBD, but the fork-block state-changing call is explicit.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "Every block executes a new gas-exempt system call with a dedicated 30,000,000 gas limit and invalidates the block if it fails."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Fee calculation",
"source": "eip.md",
"summary": "Fee computation uses a state-dependent fake-exponential loop, while dequeue processing is capped at 16 requests per block."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Contract paths can be benchmarked individually, but block-wide cost includes mandatory execution, state-dependent fee work, request serialization, and interaction with transaction-populated queue state. The dequeue cap bounds the expected impact, making it limited rather than substantial.",
"score": 2,
"uncertainty_note": "The package supplies no benchmark or bound on fake_exponential iterations under reachable excess values.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "Transaction-populated state feeds a mandatory gas-exempt system call; missing code, out-of-gas, or any call error makes the entire block invalid, and emitted bytes are committed as ordered cross-layer requests."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Fee-overpayment, system-call-failure, and empty-code risks are delegated to the analogous EIP-7002 analysis."
},
{
"locator": "Security Considerations > System Call failure",
"source": "supporting/eip-7002.md",
"summary": "An offending transaction can cause repeated invalid-block attempts through a failed system call, requiring producer or mempool mitigation."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism spans transaction execution, persistent queue/fee state, mandatory privileged execution, block validity, and EIP-7685 request commitments. Failure can affect chain liveness and cross-layer integrity, so multiple critical components need extensive review and fuzzing.",
"score": 3,
"uncertainty_note": "Consensus-layer authorization and threshold effects are excluded; score 3 is supported by execution-layer block-validity and liveness exposure alone.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants > Execution layer",
"source": "eip.md",
"summary": "SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS is explicitly TBD."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > Deployment",
"source": "eip.md",
"summary": "The deployment transaction JSON, sender, and resulting address are all TBD."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot baseline activation, call-target, empty-code, or deployment-state tests until the exact predeploy and deployment artifacts are agreed. The gap is material but localized, and it does not expose a previously unobservable legacy behavior.",
"score": 2,
"uncertainty_note": "The behavioral contract is otherwise detailed; remaining agreement is concentrated in deployment and activation identity.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter > requires",
"source": "eip.md",
"summary": "The proposal normatively requires EIP-7251 and EIP-7685."
},
{
"locator": "Specification > Execution layer > Set sweep threshold request contract > System Call",
"source": "eip.md",
"summary": "The new call is explicitly exempted from EIP-7825 and EIP-1559 behavior and aligns with EIP-7002 system-call behavior."
},
{
"locator": "Specification > Execution Layer > Block Header",
"source": "supporting/eip-7685.md",
"summary": "Requests from all types share ordered request hashing, requiring mixed type 0x01, 0x02, and 0x03 cases."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
7002,
7251,
7685,
7825
],
"rationale": "EIP-8148 strongly depends on 7251 for compounding-validator semantics and on 7685 for transport and commitment. It coexists with the 7002 and 7251 request predeploys and has explicit gas-semantic exceptions for 1559 and 7825. These five interactions span request ordering/hash, end-of-block execution, gas rules, and validator-request semantics, requiring coordinated cross-EIP tests. Five interacting EIPs do not reach the rubric's first +1 threshold, which starts at six.",
"score": 3,
"uncertainty_note": "EIP-7002 is partly a design analogue, but mixed request ordering and shared system-call processing make its interaction test-relevant.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8148,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8148:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The request prose says threshold is returned little-endian, while add-call input is big-endian and the pseudocode stores and slices the packed value without an explicit byte-to-uint conversion; the supplied bytecode appears intended to perform the output byte reversal, but the pseudocode notation is not independently explicit.",
"SYSTEM_TRANSACTION_GAS is named in the system-call text but not listed in the EIP-8148 constants table; its numeric value of 30,000,000 is nevertheless explicit."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "5c362a2591383d826734cde8d16a976b9d24d72d6b6bb3003fb3aa9955f0519b",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8148.md",
"git_blob_sha": "5de8327f93924bc6f8a7704cc3962416eea78fe6",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8148.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8148.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8148.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8148.yaml",
"sha256": "0ef82fc7342b01ca9aad9b9fdf876653f0899660ebabacfaa0345dba4e95a48a"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-7002.md",
"supporting/eip-7251.md",
"supporting/eip-7685.md",
"supporting/eip-7825.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 27,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Assessment of the sealed Draft EIP-8148 snapshot, limited to its execution-layer surface: the new EIP-7685 request type, stateful request predeploy, transaction-call paths, fee and queue processing, mandatory post-block system call, request encoding, and execution-block validity effects. Consensus-layer threshold storage, deposit interpretation, validator validation, and withdrawal processing are boundary context only and are not scored.",
"tier": "high",
"title": "Custom sweep threshold for validators",
"under_specification": {
"affected_criteria": [
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 27,
"minimum": 26
},
"present": true,
"summary": "The predeploy address and its synthetic deployment transaction, sender, and resulting address remain TBD. This is one localized deployment/activation gap: it blocks exact test baselines but is not counted again as added-contract, fork-activation, or security complexity.",
"unresolved_questions": [
"What exact value replaces SET_SWEEP_THRESHOLD_REQUEST_PREDEPLOY_ADDRESS?",
"What exact signed synthetic deployment transaction, sender, and address establish the required code and inhibitor storage before FORK_BLOCK?"
]
}
},
"hegota:8151:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "Every successful recovery adds either 100 gas for a warm recovered address or 2600 gas for a cold one, while failed recovery remains at 3000 gas."
},
{
"locator": "Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 defines the existing accessed-address warm/cold mechanism and its 100 and 2600 gas costs."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal updates ecRecover to use an existing EIP-2929 account-access gas mechanism; it does not introduce a new gas-accounting model.",
"score": 1,
"uncertainty_note": "The warm/cold amounts and success/failure split are explicit; exact out-of-gas sequencing is recorded separately as under-specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Modified ecRecover Behavior, steps 1-3",
"source": "eip.md",
"summary": "Recovery failure performs no state access, whereas successful recovery incurs warm/cold account cost and then checks the recovered account's raw code."
},
{
"locator": "Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "The inherited mechanism normally charges gas and updates accessed_addresses at the time of access, with scope reversion behavior."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "A new state-accessing operation is introduced within execution of calls to the precompile. Its position after successful recovery, and relative to dynamic charging and the code read, creates consensus-visible gas and access-set boundaries.",
"score": 2,
"uncertainty_note": "The text does not fully determine whether a recovered address becomes warm when the call cannot pay the added warm/cold charge.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative changes are confined to ecRecover behavior, account access, and execution-gas cost; no blob gas rule is specified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is added or changed.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "The only new charge is EIP-2929 execution gas for reading an account; the proposal specifies no state-writing gas or state-gas budget."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Reading raw code is an account access, not a state write, and no state gas mechanism or rate changes.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "The proposal defines base and warm/cold charges only and contains no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Successful recovery always gains an account-access charge, disallowed coded accounts now yield zero, and near-limit calls can become out-of-gas."
},
{
"locator": "Rationale > Returning 32 Zero Bytes",
"source": "eip.md",
"summary": "Existing deployed low-level staticcall wrappers and zero-result handling are explicitly considered because the changed precompile behavior reaches existing call patterns."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable subset of pre-existing ecRecover success and gas vectors needs post-fork variants, but the rework remains concentrated in the ecRecover call category rather than diverse execution behavior.",
"score": 2,
"uncertainty_note": "The sealed package contains no test inventory, so the size of the affected pre-existing subset cannot be counted directly.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "A cold recovered address must be added to accessed_addresses and is warm for later operations in the transaction."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing tests that successfully invoke ecRecover gain a narrow new transaction-access invariant even when their original logic is unrelated to EIP-8151.",
"score": 1,
"uncertainty_note": "The package does not describe which pre-existing harness outputs expose the ephemeral accessed-address set.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Account Code Check",
"source": "eip.md",
"summary": "The rule consumes existing transaction state, raw account code, and accessed_addresses; no transition-tool input or output field is defined."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Existing state-transition inputs suffice; no interface field or mechanism is added.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Cases are expressed with existing account code, call gas, recovery inputs, return bytes, and EIP-2929 access status; no new expectation or modifier abstraction is specified."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The package provides no requirement for a new test-framework primitive.",
"score": 0,
"uncertainty_note": "No test-framework design is included, so this zero reflects the absence of a demonstrated primitive requirement in the sealed evidence.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Modified ecRecover Behavior, step 1",
"source": "eip.md",
"summary": "ECDSA public-key recovery is performed as currently specified; only the recovered address's state eligibility and gas treatment change."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic algorithm or recovery functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Modified ecRecover Behavior and Account Code Check",
"source": "eip.md",
"summary": "Outcomes split across failed and successful recovery, absent or empty code, exactly 23-byte delegation code with the required prefix, and every other non-empty code value."
},
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "Successful cases split again by warm/cold status and exact gas sufficiency, while failed recovery does not access state."
},
{
"locator": "Specification",
"source": "supporting/eip-2929.md",
"summary": "Access status is transaction-wide and scope-sensitive, including reversion of accesses made inside a reverted scope."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms form an elevated matrix: recovery success, code shape, warm/cold status, call context and reversion, and gas just below, at, or above the required charge must be crossed rather than tested independently.",
"score": 3,
"uncertainty_note": "Exact gas-boundary warming behavior is unspecified, but the elevated case matrix exists under any resolution.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes execution of an existing precompile and defines no block RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block encoding or syncing validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No Engine API endpoint, field, or communication mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The Engine API is unchanged.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal modifies the pre-existing ecRecover precompile at address 0x01; it does not deploy a contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "All normative changes target precompile behavior and account reads; no system-contract code or state transition is described."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "Precompiles are assessed under their dedicated anchors.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal defines no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Modified ecRecover Behavior",
"source": "eip.md",
"summary": "The changed result and gas behavior are assigned to the ecRecover precompile, not to an opcode definition."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified as such.",
"score": 0,
"uncertainty_note": "Call-path ordering is scored separately from opcode-result modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "ecRecover at address 0x01 is explicitly an existing precompile being modified."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Modified ecRecover Behavior",
"source": "eip.md",
"summary": "The existing ecRecover precompile gains a state-dependent output rule, returning zero for recovered accounts with disallowed raw code."
},
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "The precompile also gains dynamic warm/cold gas, an account-code read, and mutation of accessed_addresses on cold successful recovery."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "This is a behavior modification to one now-complex precompile: its output, gas, state access, and transaction access status all depend on recovery and account state.",
"score": 3,
"uncertainty_note": "The exact access/gas boundary is open, but the specified modification is complex regardless of that resolution.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No transaction, block, interface, RLP, or SSZ encoding is changed."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal introduces no encoding change at a scored interface.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal changes precompile execution and defines no transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "EIP-7702 is a dependency, not a transaction type introduced by EIP-8151.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The compatibility changes are precompile return data and execution out-of-gas behavior; no transaction validity or intrinsic-gas rule is specified."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity mechanisms are not changed.",
"score": 0,
"uncertainty_note": "The proposal borrows EIP-3607's account-code restriction concept but does not alter EIP-3607 transaction validation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Modified ecRecover Behavior",
"source": "eip.md",
"summary": "The new rule starts at activation, but no state, internal variable, or irregular transition is initialized or modified at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation is an ordinary behavior switch without an activation-block mutation.",
"score": 0,
"uncertainty_note": "No material uncertainty in the package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Gas Cost",
"source": "eip.md",
"summary": "Every successful ECDSA recovery now performs a raw account-code read with transaction-context-dependent warm/cold status."
},
{
"locator": "Security Considerations > Cross-Domain / L2 Fault Proof Implications",
"source": "eip.md",
"summary": "The precompile ceases to be a pure function of its cryptographic inputs and depends on current state and transaction access status."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Database and cache effects cannot be fully measured as an isolated pure precompile benchmark, but the added work is limited to successful ecRecover calls and one recovered-account access per invocation.",
"score": 2,
"uncertainty_note": "The package gives gas pricing but no workload measurements for ecRecover frequency or code-read cost.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The change protects immutable signature-authorizing contracts from use of an old ECDSA key after an account migrates to non-delegation code."
},
{
"locator": "Security Considerations > Cross-Domain / L2 Fault Proof Implications",
"source": "eip.md",
"summary": "Making ecRecover state-dependent can make fault-proof or cross-domain re-execution incorrect when the execution contexts have different state."
},
{
"locator": "Security Considerations > Application-Level ECDSA Verification",
"source": "eip.md",
"summary": "Application-level recovery bypasses the new restriction, creating a security boundary between precompile and non-precompile verification."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The proposal substantially changes security assumptions across a critical authorization primitive, immutable contracts, account-code migration, and cross-domain proof systems, requiring extensive state- and context-aware review and fuzzing.",
"score": 3,
"uncertainty_note": "The EIP describes the affected security surfaces clearly, although the package contains no implementation or test evidence by design.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Modified ecRecover Behavior, step 3",
"source": "eip.md",
"summary": "The normative sequence says to consume the dynamic charge and then check raw code, but does not state the access-set result when the added charge cannot be paid."
},
{
"locator": "Reference Implementation",
"source": "eip.md",
"summary": "Gas calculation and permission checking are presented as separate functions and the shown ecRecover function does not compose the gas function, leaving exact boundary sequencing implicit."
},
{
"locator": "Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 makes charging and access-set update timing consensus-relevant, so the missing composition affects baselining at exact gas boundaries."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Client agreement is needed for a localized set of gas-sufficiency and warming cases before precise vectors can be baselined; the core return and account-code rules are otherwise explicit.",
"score": 2,
"uncertainty_note": "The intended ordering may be apparent to implementers, but it is not fully determined by the sealed normative text and pseudocode.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Abstract",
"source": "eip.md",
"summary": "EIP-8151 requires EIPs 2929, 3607, and 7702 and combines their account access, code restriction, and delegation-indicator rules."
},
{
"locator": "Motivation and Rationale > Protocol-Level Modification",
"source": "eip.md",
"summary": "Existing ERC-2612-style permit authorization is an explicit affected use case because immutable contracts automatically observe changed ecRecover results."
},
{
"locator": "Specification > Delegation indicator and Transaction origination",
"source": "supporting/eip-7702.md",
"summary": "EIP-7702 defines the exact 23-byte delegation form and the exception to EIP-3607 on which EIP-8151 relies."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2612,
2929,
3607,
7702
],
"rationale": "Coordinated vectors must cover EIP-2929 warm/cold accounting, EIP-3607 code restriction semantics, EIP-7702 raw delegation indicators, and changed EIP-2612-style authorization behavior. These are strong dependencies across multiple existing mechanisms, with four identified EIPs but no uncapped bonus beyond the base score.",
"score": 3,
"uncertainty_note": "EIP-2612's sealed supporting file is only a move notice, so its interaction is grounded in EIP-8151's own explicit permit discussion.",
"under_specified": false,
"unidentified_interactions": [
"Cross-domain and L2 fault-proof systems that re-execute the L1 ecRecover precompile in a context with different account state or access status."
]
}
],
"eip": 8151,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8151:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"Special consideration: recovery success or failure, warm or cold status, static or non-static call context, permitted or disallowed code, later reversion or success, and exact gas sufficiency create a multiplicative test matrix rather than independent additive cases.",
"The normative specification composes dynamic gas and raw-code permission, while the reference implementation presents them separately and omits an integrated gas call from its ecRecover function."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "9bf6c7143e5aaa026b85943d44ebb6eab6ec7404a75b467431bc27470af98162",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8151.md",
"git_blob_sha": "f893235a7ee6c0974c5c6bd5800c282d95092155",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8151.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8151.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8151.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8151.yaml",
"sha256": "cf4ed273e02a837cfc74a5eb66eb71f687ff5d183df740cc4cb9e73ebd8c452d"
},
"supporting_documents": [
"supporting/eip-2612.md",
"supporting/eip-2929.md",
"supporting/eip-3607.md",
"supporting/eip-7702.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 22,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the sealed Draft snapshot of EIP-8151. The proposal changes the existing ecRecover precompile so successful recovery performs an EIP-2929-priced raw-code account access and suppresses recovered addresses whose code is neither empty nor an EIP-7702 delegation indicator. Consensus-layer behavior is out of scope; no such surface is specified.",
"tier": "medium",
"title": "Account Code Restricted ecRecover",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 23,
"minimum": 21
},
"present": true,
"summary": "The proposal does not completely order recovery, gas sufficiency, accessed-address warming, and the raw-code read when a successful recovery has insufficient gas for the added EIP-2929 charge. The normative steps and split reference functions therefore do not fix the consensus-visible outcome at every gas boundary.",
"unresolved_questions": [
"If recovery succeeds but the call cannot pay the warm or cold surcharge, is recovered_address added to accessed_addresses before the call fails?",
"Is the raw-code read attempted only after the entire surcharge is confirmed available, and what access is recorded at each exact gas boundary?"
]
}
},
"hegota:8182:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Section 5, System Contract",
"source": "eip.md",
"summary": "The EIP limits its protocol change to installing a system contract and specifies ordinary contract execution without a new EVM gas-accounting rule."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Contract calls and proof verification consume existing EVM gas, but no gas schedule or accounting mechanism is created or changed.",
"score": 0,
"uncertainty_note": "Exact system-contract bytecode is pending, but that does not by itself specify a change to EVM gas accounting.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP introduces no opcode and says it does not modify existing contract semantics."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's state-access position or gas-charge ordering is changed.",
"score": 0,
"uncertainty_note": "The system contract performs state accesses as ordinary contract code; none is an opcode-ordering rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Section 5, System Contract",
"source": "eip.md",
"summary": "The specified change is a shielded-pool system contract and contains no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified.",
"score": 0,
"uncertainty_note": "EIP-4844 is cited only as an analogy for a setup ceremony, not as an accounting dependency.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Sections 5.2 and 5.4, State and Execution",
"source": "eip.md",
"summary": "The pool writes contract storage for trees, nullifiers, replay IDs, and policies, but the EIP specifies no state-gas budget, rate, charging site, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "New ordinary storage writes are not a change to the rubric's state-gas accounting mechanism.",
"score": 0,
"uncertainty_note": "Storage volume is considered under performance and security, not counted again as state-gas accounting.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Sections 5.4.1 and 5.4.2, transact and deposit",
"source": "eip.md",
"summary": "The execution procedures define validation, storage, proof checks, and transfers without any gas-refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "No refund-related specification gap is visible.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "Apart from the new system-contract installation, the EIP disclaims other protocol changes and says existing contracts and ERC-20 interfaces retain their semantics."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The snapshot provides no rule requiring pre-existing tests to be reworked; feature and activation tests are new EIP-specific coverage.",
"score": 0,
"uncertainty_note": "A contrived pre-existing test that assumes the fixed system address is empty could be affected, but the package gives no evidence of such a test population.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases; Backwards Compatibility",
"source": "eip.md",
"summary": "The listed assertions concern EIP-8182 calls and state, while the EIP states that existing contract semantics are unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to EIP-8182 are not specified to gain a new assertion.",
"score": 0,
"uncertainty_note": "Fork-activation allocation tests are about this EIP and therefore do not constitute a new invariant on unrelated tests.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Section 5.1, Deployment and Upgrade Model",
"source": "eip.md",
"summary": "Clients install a fixed-address account at the activation fork, but the EIP defines no new transition-tool input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Activation-block behavior changes, but no transition-tool interface field or interface mechanism is specified.",
"score": 0,
"uncertainty_note": "A transition tool must distinguish activation from later blocks; the package does not establish that this requires an interface extension rather than existing fork selection.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Required cases are expressed as calls, proofs, input ranges, state transitions, reverts, and boundary checks; the EIP does not require a new expectation or modifier abstraction."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The sealed text does not demonstrate that existing test primitives are insufficient, even though EIP-specific proof fixtures and helpers will be substantial.",
"score": 0,
"uncertainty_note": "The package contains no test-framework inventory, so framework-specific helper needs cannot be established from the snapshot.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Sections 3.3-3.4, Poseidon Hash and Merkle Tree Constructions",
"source": "eip.md",
"summary": "The EIP fixes a custom length-tagged Poseidon2 BN254 sponge and three Merkle-tree constructions with domain-separated commitment formulas."
},
{
"locator": "Sections 4, 5.5, and 8.1, split proofs and verification",
"source": "eip.md",
"summary": "A fork-managed Groth16 proof, permissionless auth proofs, embedded verification key, and two-value cross-proof coupling jointly enforce the spend relation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Multiple mechanisms are introduced, including a custom Poseidon2 sponge construction and a compound Groth16/auth-proof protocol with commitments, nullifiers, and Merkle membership. At least the composed relation and cross-proof binding are proposal-specific and demand dedicated vectors and adversarial testing.",
"score": 3,
"uncertainty_note": "The referenced Poseidon parameter/vector assets and finalized verification key are not available as scoring evidence, limiting artifact-level review without reducing the evident mechanism count.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Sections 5.2.1, 5.4, 8.2, 8.5, 8.10; Test Cases",
"source": "eip.md",
"summary": "The EIP defines block- and count-based root-history edges, two tree capacity boundaries, field/address/amount ranges, proof encodings, transfer/withdrawal branches, real/phantom inputs, real/dummy outputs, expiry, replay, rotation, and output-lock combinations."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "There are many independent boundary-prone mechanisms, and root aging, replay/expiry, output locking, token-call return shapes, and real/phantom or dummy combinations each require elevated case matrices.",
"score": 3,
"uncertainty_note": "Exact circuit and bytecode artifacts may reveal further edges; score 3 already matches the highest defined non-exceptional anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Sections 5.1 and 5.4",
"source": "eip.md",
"summary": "The execution-layer change is an installed account and contract-call behavior; no block RLP validation rule is introduced."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block-RLP syncing validation mechanism is specified.",
"score": 0,
"uncertainty_note": "Syncing must reproduce the fork state transition, but that is distinct from this anchor's block-RLP validation mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Section 5, System Contract",
"source": "eip.md",
"summary": "The EIP specifies a system-contract interface and no Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced.",
"score": 0,
"uncertainty_note": "No Engine API ambiguity is visible in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Sections 1 and 5.1-5.3, system-contract definition and state",
"source": "eip.md",
"summary": "One shielded-pool system contract is installed at a protocol-defined address and maintains commitment trees, histories, nullifiers, replay IDs, identity entries, and an auth-policy registry."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "The proposal adds a single stateful system contract, exactly matching score 2.",
"score": 2,
"uncertainty_note": "Its exact bytecode is pending, but its count and statefulness are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Section 5.1, Deployment and Upgrade Model",
"source": "eip.md",
"summary": "The EIP installs a new account and describes only possible future hard-fork replacement of that account's code."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is modified by this proposal.",
"score": 0,
"uncertainty_note": "A future replacement is not part of the assessed activation change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The EIP explicitly states that it introduces no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No ambiguity is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal confines the protocol change to the system contract and does not change existing contract semantics."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "No ambiguity is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Rationale, Groth16 BN254 Pool Proof System",
"source": "eip.md",
"summary": "The EIP explicitly adds no precompile; its verifier uses existing ECADD/ECMUL/ECPAIRING calls."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "Use of existing precompiles is an integration dependency, not an added precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Sections 5.5 and Rationale, Groth16 BN254 Pool Proof System",
"source": "eip.md",
"summary": "Existing elliptic-curve precompiles are called by the verifier, with no behavioral or gas-schedule modification specified."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "No modification is implied by ordinary calls to them.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Sections 5.3 and 5.5",
"source": "eip.md",
"summary": "The EIP defines Solidity ABI calls and a pool-proof byte string but no transaction, block, RLP/SSZ, or protocol-interface encoding transition."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Contract calldata and proof payload formats do not change the rubric's transaction/block/interface encodings.",
"score": 0,
"uncertainty_note": "No Engine API or block encoding is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The EIP explicitly states that it introduces no transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "No ambiguity is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Section 5.4, Execution",
"source": "eip.md",
"summary": "The proposal adds revert conditions inside calls to the pool contract but no validity or intrinsic-gas rule for existing transaction types."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Contract-level call validation is not a transaction validity mechanism under this anchor.",
"score": 0,
"uncertainty_note": "No transaction-envelope change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Section 5, System Contract",
"source": "eip.md",
"summary": "All new persistent data resides in the system contract; no block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "No ambiguity is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Section 5.1, Deployment and Upgrade Model",
"source": "eip.md",
"summary": "At activation, clients must install a system-contract account with exact code at the fixed shielded-pool address, and its storage persists across later fork replacements."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Installing code and an account as part of the activation state transition is a fork-block state modification, matching the score-3 anchor.",
"score": 3,
"uncertainty_note": "The exact bytecode is not yet pinned, but the required activation-time state modification is unambiguous.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Sections 5.2, 5.4, and 5.5; Security Considerations, State Growth",
"source": "eip.md",
"summary": "Each spend combines Groth16 verification over 19 public inputs, auth-verifier staticcall, multiple state-set writes, three tree insertions, payload hashing, and optional external asset transfer; pool state is append-only and not safely prunable."
},
{
"locator": "Rationale, Groth16 BN254 Pool Proof System",
"source": "eip.md",
"summary": "Verification gas is dominated by 19 scalar multiplications and a final pairing."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Core proof and tree operations can be benchmarked directly, but cumulative state growth, arbitrary auth-verifier code, ERC-20 behavior, payload sizes, and root-history throughput prevent complete isolation. The EIP adds a new path rather than broadly changing existing execution benchmarks, fitting score 2.",
"score": 2,
"uncertainty_note": "Final bytecode, verification key, and concrete circuit artifacts are pending, so exact execution cost and benchmark coverage are not baselinable.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Section 4, Architecture; Security Considerations",
"source": "eip.md",
"summary": "The pool circuit is the all-funds security boundary; the design also relies on a trusted setup, custom commitments/nullifiers, root histories, replay protection, user-selected auth verifiers, and exact asset-transfer handling."
},
{
"locator": "Sections 5.4 and 8, execution and circuit requirements",
"source": "eip.md",
"summary": "Security-critical checks span proof canonicality, field/address ranges, nullifier and intent uniqueness, cross-proof binding, value conservation, token consistency, authorization, external calls, and reentrancy."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches multiple critical components and custody invariants; an implementation error can compromise pool funds or authorization while other errors can cause replay, lockout, leakage, or denial of service. It requires extensive security review and fuzzing.",
"score": 3,
"uncertainty_note": "Risk is scoped to the execution-layer pool and its users as the EIP states; consensus-layer and out-of-scope network privacy are not scored.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Section 5.1 and 5.5, deployment and pool-proof verification",
"source": "eip.md",
"summary": "The exact system-contract bytecode and embedded verification key are not pinned; bytecode is to be finalized after a future trusted-setup ceremony."
},
{
"locator": "Sections 3.3 and 8, Poseidon assets and circuit requirements",
"source": "eip.md",
"summary": "Hash constants/vectors are delegated to referenced assets, while the pool circuit is specified as requirements rather than a sealed circuit/VK artifact in this package."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need coordinated agreement on the exact activation code, verification key, and circuit-derived artifacts before bytecode- and proof-level vectors can be baselined. The gaps are material but localized to the new pool artifact, fitting score 2 rather than re-baselining a newly observable pre-existing behavior.",
"score": 2,
"uncertainty_note": "The prose fixes many observable cases and provides extensive test requirements, so the remaining uncertainty is narrower than the overall feature surface but blocks an authoritative artifact-level baseline.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Sections 5.4.1-5.4.2, ERC-20 call semantics",
"source": "eip.md",
"summary": "EIP-8182 explicitly requires EIP-20 and defines deposit/withdrawal integration through balanceOf, transferFrom, and transfer, including strict return-data and balance-delta handling."
},
{
"locator": "Front matter and body",
"source": "supporting/eip-20.md",
"summary": "The sealed supporting snapshot identifies EIP-20 as the ERC dependency but contains only a move notice and no additional normative interface text."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
20
],
"rationale": "The pool depends on EIP-20 behavior and needs coordinated token-path tests, including nonstandard return shapes and explicitly incompatible fee or rebasing behavior, but the interaction is confined to asset ingress and egress. EIP-4844 is only a trusted-setup analogy in the EIP text and does not require coordinated EIP-4844 test cases.",
"score": 2,
"uncertainty_note": "The EIP-20 support file lacks its normative body, but EIP-8182 itself states the integration behavior needed for this complexity classification.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8182,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8182:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"Same-block auth-policy roots are intentionally not retained after later same-block mutations, so transaction ordering determines whether an intermediate root remains usable; the EIP recommends waiting a block but does not make that wallet behavior mandatory.",
"ERC-20 compatibility is deliberately narrower than the nominal interface: fee-on-transfer and rebasing behavior can fail or under-deliver, and the supporting EIP-20 snapshot contains no normative body for comparison.",
"Auth verifier proof formats and verification-key derivation are delegated to companion standards, while the pool contract accepts any user-registered verifier satisfying only the staticcall envelope."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "5fcacb0f71bec7f46b37edacc7060a2a0c03dc4538caa809453460ee2d0e809e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8182.md",
"git_blob_sha": "44856f004aa63ff2b115b96d76149f21fb2f842c",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8182.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8182.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8182.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8182.yaml",
"sha256": "f24a8e332688574c1cfd6f2600ab0f74df9e22cf9a2ee85be04996dcf269c4a3"
},
"supporting_documents": [
"supporting/eip-20.md",
"supporting/eip-4844.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 20,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the sealed EIP-8182 snapshot: the fork-installed shielded-pool system contract, its state and call paths, the Groth16/Poseidon2 pool-proof and auth-policy mechanisms, ETH/ERC-20 asset movement, and activation behavior. Wallet, mempool, note-delivery, and network-anonymity infrastructure identified as out of scope by the EIP is excluded.",
"tier": "medium",
"title": "Private ETH and ERC-20 Transfers",
"under_specification": {
"affected_criteria": [
"cryptography",
"performance_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 22,
"minimum": 19
},
"present": true,
"summary": "The activation artifact is not reproducible from the sealed evidence: the exact system-contract bytecode and Groth16 verification key await a trusted setup, the exact pool-circuit artifact is not included, and the referenced Poseidon parameter/vector assets are outside the assessment source list. This chiefly limits cryptographic vectors, performance baselines, and final cross-client artifact agreement without changing the clearly specified count of protocol surfaces.",
"unresolved_questions": [
"What exact system-contract bytecode and initial account state will all clients install at activation?",
"What finalized Groth16 circuit artifact, verification key, and trusted-setup transcript determine the embedded verifier?",
"Do the referenced Poseidon2 constants and vectors fully determine and test every sponge and Merkle-tree context described by the prose?",
"What measured execution and state-growth costs follow from the finalized bytecode, proof verifier, auth-verifier calls, and allowed payload sizes?"
]
}
},
"hegota:8188:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 18,
"recomputed_tier": "medium",
"recomputed_total": 18,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No execution gas rule changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state-access site moves and no gas charge moves relative to one.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No interaction with blob gas.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Literally the anchor-1 wording: two existing `STATE_BYTES_PER_*` rates are adjusted (`STATE_BYTES_PER_NEW_ACCOUNT` 120 → 125, `STATE_BYTES_PER_STORAGE_SET` 64 → 70) to keep EIP-8037's per-byte state-creation pricing matched to the real on-disk footprint.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No refund mechanism is introduced or affected.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Every fixture that writes state needs a new root and a per-account and per-slot `last_written_block` in its alloc, static corpus included. Not mechanical: the value depends on which block the write landed in. Spans state, blockchain, transition and benchmark fixtures.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "every test in the fork now asserts `last_written_block` on every account and slot it touched.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The t8n alloc changes shape on both sides: accounts gain a field, and the storage map goes from `slot -> value` to a pair. It must also record which of the two encodings a leaf is in, since `last_written_block = 0` fits both and they hash differently. Not 3 point since the block number is already in `env`.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "`Account` and `Storage` are framework primitives used by every test in every fork, and both need the field. Since nearly every write bumps it, spelling it out per entry is unworkable. The framework needs an inferred default with opt-in assertion, plus a primitive for the legacy-versus-new encoding. Permanent surface, used by every other EIP's tests.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography introduced or modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "(1) No-op `SSTORE` and slot deletion, where slot and account diverge, one is untouched or removed while the other bumps. (2) Same-block idempotence across transactions. (3) Touched-but-unchanged accounts: zero-value calls, EIP-161 empty accounts, a sender whose balance nets back.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-level RLP rule changes, so nothing new is validated on the block wire. One level down, the state trie holds legacy and new leaf encodings side by side, and which one a leaf is in cannot be recovered from a decoded alloc — only a client carrying its own state across the fork boundary exercises it. A client that re-encodes a legacy leaf it should have left alone gets a wrong state root, and t8n alone will not show it.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No new fields, endpoints or communication mechanisms.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contracts.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No modified system contracts",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcodes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No opcode being modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompiles.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Both state-trie leaf encodings change, with a permanently mixed legacy format alongside.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity rules and intrinsic gas calculation are unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header fields.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No rules activates",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The claimed benefit is the part that cannot be benchmarked in isolation: it is a per-client storage-layout property that only appears over long runs against a real backend, so validation belongs on a devnet with per-client measurements rather than in the test suite.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Targeted review and fuzzing of the encoding and revert paths, not an extensive cross-cutting review.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Unsettled: (1) BAL entry required for stamp-only changes? (2) Genesis encoding at fork activation? (3) Reverted writes: restore legacy encoding or leave zero? (4) Block number or timestamp basis?",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "**EIP-8037**: per-byte parameters must move together with this encoding. **EIP-7928** — the BAL question above, the one interaction that can cause outright divergence.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8188,
"fork": "hegota",
"id": "hegota:8188:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8188.yaml",
"sha256": "441883ccea629c9e77400f71f3e17b148e9ab3e8023e2523d5c5f46fc4053979"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "042096dd3debf88e51204bbf341c35c8527f6228",
"content_sha256": "f11bbf898d2ceaadf6ca86399b86c552a82fad4f3e929e2df130fc6899b5bfc8",
"git_blob_sha": "76dfe14f7dd1daa3c5b546b00f0f265c5e37e540",
"immutable_url": "https://github.com/ethspecs/pm/blob/042096dd3debf88e51204bbf341c35c8527f6228/complexity_assessments/EIPs/EIP-8188.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8188.md",
"pull_request": {
"draft": false,
"number": 125,
"title": "Add EIP-8188 complexity assessment",
"updated_at": "2026-08-24T06:59:51Z",
"url": "https://github.com/ethspecs/pm/pull/125"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 18,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "Last-Written Block for Accounts and Slots",
"under_specification": null
},
"hegota:8188:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal expressly says that the metadata introduces no gas changes."
},
{
"locator": "Motivation",
"source": "eip.md",
"summary": "Gas pricing based on the metadata is left to a separate proposal."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "EIP-8188 introduces no execution-gas accounting rule. Its state-gas parameter interaction is assessed only in the dedicated state-gas anchor.",
"score": 0,
"uncertainty_note": "The EIP-8037 parameter recommendation creates a scope tension, but it concerns state-gas rates rather than a separate EVM execution-gas rule.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block Update Rule",
"source": "eip.md",
"summary": "The text defines when metadata changes alongside mutations but does not move an existing state access or gas charge within any opcode."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal changes the state written by existing operations, not the ordering of a pre-existing state access or gas charge inside opcode execution.",
"score": 0,
"uncertainty_note": "The precise implementation sequence of the metadata write is not stated, but the rubric scores specified changes to access or charging order, and none is introduced here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The scope is account and storage-slot metadata and the text expressly says that it introduces no gas changes."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas mechanism or blob-gas rate is added or modified.",
"score": 0,
"uncertainty_note": "No blob behavior appears anywhere in the proposal specification.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Relation with state creation cost (EIP-8037)",
"source": "eip.md",
"summary": "The proposal says STATE_BYTES_PER_NEW_ACCOUNT should rise from 120 to 125 and STATE_BYTES_PER_STORAGE_SET should rise from 64 to 70."
},
{
"locator": "Specification / New parameters",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 defines the existing 120-byte account and 64-byte storage-slot state-gas rates that EIP-8188 proposes adjusting."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The stated SHOULD adjustments change two existing STATE_BYTES_PER_* rates, which matches score 1; no new charging site, budget, reservoir, or spill rule is introduced by EIP-8188 itself.",
"score": 1,
"uncertainty_note": "The Abstract says there are no gas changes and pricing is separate, while the Rationale normatively says the EIP-8037 rates SHOULD increase. Whether those adjustments are part of EIP-8188 is materially ambiguous.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Reverts",
"source": "eip.md",
"summary": "Rolled-back metadata is restored like ordinary state; no gas credit or refund rule is defined."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "State journaling on revert is not a gas-refund mechanism.",
"score": 0,
"uncertainty_note": "The proposal explicitly disclaims gas changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Update Rule",
"source": "eip.md",
"summary": "Storage changes, deletion, creation, balance transfers, nonce increments, account creation, SELFDESTRUCT, reads, and reverts all receive metadata rules."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Post-fork writes change trie-leaf encodings and state-root computation while untouched legacy entries retain their prior encoding."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A major and diverse set of existing execution tests must be reworked or re-derived because common account and storage mutations now produce different consensus state and roots, with fork, legacy, revert, and SELFDESTRUCT variants.",
"score": 3,
"uncertainty_note": "The sealed package contains no test inventory, so the exact number of affected vectors cannot be counted; the specified mutation surface is nevertheless broad.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Encoding Changes",
"source": "eip.md",
"summary": "Accounts and storage slots gain a consensus last_written_block value that is incorporated into their RLP and therefore into trie hashing."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Legacy entries default to zero and migrate only on a post-fork mutation; no tree transition occurs at activation."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of otherwise unrelated post-fork state-transition tests gains a mechanical metadata or resulting-state-root assertion. Score 3 is not used because untouched pre-fork state remains valid and is not globally re-derived.",
"score": 2,
"uncertainty_note": "The package does not describe the test harness or whether it asserts the field directly, through post-state objects, or only through the state root.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Encoding Changes",
"source": "eip.md",
"summary": "The state model adds metadata to both account objects and individual storage slots, with distinct legacy and post-fork representations."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition interface must be able to convey or emit the new account-level and slot-level metadata, amounting to multiple new fields or an equivalent state representation mechanism.",
"score": 2,
"uncertainty_note": "EIP-8188 specifies consensus RLP but no transition-tool schema, so the exact number and placement of interface fields are not determined by the package.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Encoding Changes",
"source": "eip.md",
"summary": "Tests need to represent and compare last_written_block on accounts and slots, including legacy entries that imply zero."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing account and storage expectation structures need at least a minor extension for the new metadata, but the package does not establish a new reusable expectation or modifier abstraction.",
"score": 1,
"uncertainty_note": "No test-framework design is present in the sealed sources; existing primitives could require either only fields or a new metadata-aware expectation.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The complete mechanism consists of RLP state metadata and mutation rules; no cryptographic primitive or cryptographic functionality is added or changed."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Trie hashing reflects changed bytes, but the cryptographic mechanism itself is unchanged.",
"score": 0,
"uncertainty_note": "No cryptographic testing surface is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Update Rule",
"source": "eip.md",
"summary": "The rules distinguish changed, deleted, no-op, and new slots; repeated writes; balance and nonce changes; reads; frame reverts; and multiple SELFDESTRUCT cases."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Post-fork execution permits a persistent mixture of legacy entries defaulting to zero and newly encoded entries after their first mutation."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms form an elevated cross-product: mutation kind, legacy versus new encoding, same-block repetition, success versus revert, and SELFDESTRUCT creation and beneficiary branches.",
"score": 3,
"uncertainty_note": "Some account-mutation cases are not exhaustively enumerated, increasing the boundary surface recorded under under-specification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The RLP changes apply to account and storage trie leaves and state-root computation; the proposal introduces no block-RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "The anchor is limited to block RLP validation, which EIP-8188 does not modify.",
"score": 0,
"uncertainty_note": "State synchronization may need mixed leaf decoding, but that is outside this anchor's block-RLP scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification changes only execution state encoding and mutation metadata; it defines no Engine API field, endpoint, or communication rule."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced.",
"score": 0,
"uncertainty_note": "None within the sealed proposal scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal adds state metadata and no contract deployment or system address."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None within the sealed proposal scope.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / Storage slot rules",
"source": "eip.md",
"summary": "Every qualifying SSTORE changes both slot metadata and containing-account metadata."
},
{
"locator": "Specification / System contracts and system transactions",
"source": "supporting/eip-8037.md",
"summary": "Existing system-call paths can write new storage slots through stateful system contracts."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "EIP-8188 does not change system-contract code, but stateful system contracts are indirectly subject to the new metadata and state-root effects when they write. The EIP requires no irregular activation transition.",
"score": 1,
"uncertainty_note": "EIP-8188 does not enumerate affected system contracts or special system-call semantics, so the extent of this indirect effect is not fixed in the package.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The update rules attach metadata to existing state operations and define no opcode number or new instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Storage slot rules",
"source": "eip.md",
"summary": "Existing SSTORE executions now update slot and account metadata for value changes, deletion, and creation."
},
{
"locator": "Specification / Account rules",
"source": "eip.md",
"summary": "Existing value-transfer, creation, and SELFDESTRUCT paths now produce additional consensus state effects."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least SSTORE and SELFDESTRUCT, plus value-bearing call and creation paths, have modified non-gas state behavior. The rubric permits only 0 or 3 for this anchor.",
"score": 3,
"uncertainty_note": "The exact exhaustive opcode set is not stated, but one modified existing opcode is sufficient for the permitted score of 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "No precompile address, input contract, or gas schedule is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Account rules",
"source": "eip.md",
"summary": "The proposal changes generic account metadata on balance mutation but defines no change to any precompile's logic or gas accounting."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Generic surrounding state-transition effects do not modify precompile logic or gas schedules.",
"score": 0,
"uncertainty_note": "A value transfer to an address is governed by generic account rules, not by a precompile modification in this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Encoding Changes",
"source": "eip.md",
"summary": "RLP changes are confined to account and storage-slot trie-leaf values, not transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Despite the substantial state RLP change, this rubric anchor is expressly limited to transaction, block, and interface encoding, none of which changes.",
"score": 0,
"uncertainty_note": "State-leaf encoding complexity is captured by affected tests, invariants, transition representation, edge cases, and performance rather than this narrow anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal defines no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal adds state metadata and expressly introduces no gas changes."
},
{
"locator": "Specification",
"source": "eip.md",
"summary": "No transaction-validity or intrinsic-gas rule is defined."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "State output changes do not alter transaction envelope validity or intrinsic-gas calculation. EIP-8037's own validity mechanisms are not changes introduced by EIP-8188.",
"score": 0,
"uncertainty_note": "The possible EIP-8037 byte-rate adjustment is a state-gas issue, not a transaction-validity rule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Update Rule",
"source": "eip.md",
"summary": "Existing block_number supplies metadata values; no new block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The proposal consumes an existing block number and adds no header field.",
"score": 0,
"uncertainty_note": "None.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "No tree transition occurs; legacy entries remain encoded as before and adopt the new encoding only upon their first post-fork mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state or existing internal value is modified at the activation block itself.",
"score": 0,
"uncertainty_note": "Implementations must activate new mutation rules, but initialization of a semantic field and lazy decoding are not an activation-block modification under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / How does extra metadata affect the state size?",
"source": "eip.md",
"summary": "The proposal estimates roughly 10.8 GB of raw overhead once all current state has been rewritten and says impact must be benchmarked across clients."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Every written account or slot grows, increasing data touched by writes and the size of state witnesses and proofs."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The mechanism affects pervasive existing write, trie-hashing, database, witness, and proof behavior and cannot be fully validated in isolation; its substantial cross-client storage and commit-path impact warrants score 3.",
"score": 3,
"uncertainty_note": "Client tiering optimizations are optional and unspecified, so only the mandatory metadata overhead and write-path effects are scored.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Added bytes increase state-resource usage and witness sizes; without matching EIP-8037 byte rates, new accounts and slots would be underpriced."
},
{
"locator": "Specification / Reads and Reverts",
"source": "eip.md",
"summary": "Consensus correctness requires reads not to mutate metadata and reverted frames to restore it exactly with accompanying state."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The metadata interacts with critical state-root, journaling, and state-pricing components, slightly altering their invariants and requiring targeted review and fuzzing. The text bounds DoS exposure by existing write rules, so score 3 is not used.",
"score": 2,
"uncertainty_note": "The security consequence of the ambiguous EIP-8037 parameter adjustment and omitted mutation cases cannot be fully resolved from the package.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter and Abstract",
"source": "eip.md",
"summary": "The proposal is Draft and makes previously unrecorded write-age information consensus metadata that changes the state root."
},
{
"locator": "Specification / Account rules",
"source": "eip.md",
"summary": "The enumerated account updates cover balance, nonce, storage, creation, and SELFDESTRUCT but do not state an exhaustive rule for every account-field mutation."
},
{
"locator": "Specification / Parameter changes",
"source": "supporting/eip-8037.md",
"summary": "The required EIP-8037 package text includes existing-account EOA delegation writes, a mutation class not resolved by EIP-8188's account-rule list."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously unobservable write timing becomes consensus-critical, while testable cases such as unlisted account-field mutations and no-net balance transfers are not fully reconciled with the general mutation rule. Different readings produce different leaf encodings and state roots, requiring cross-client agreement.",
"score": 3,
"uncertainty_note": "The allowed package contains no implementation, devnet, test, or discussion evidence with which to determine whether these Draft gaps already have a shared resolution.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Rationale / Relation with state creation cost (EIP-8037)",
"source": "eip.md",
"summary": "EIP-8188 requires EIP-8037 and proposes coordinated changes to two of its per-byte state-creation parameters."
},
{
"locator": "Specification / Account rules / SELFDESTRUCT",
"source": "eip.md",
"summary": "SELFDESTRUCT metadata behavior is explicitly branched according to EIP-6780."
},
{
"locator": "Rationale / Why do reads not update the block?",
"source": "eip.md",
"summary": "Read behavior is designed to preserve EIP-214 STATICCALL state immutability."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
214,
6780,
8037
],
"rationale": "EIPs 8037, 6780, and 214 require coordinated consideration for pricing, deletion and balance branches, and static-call invariants, but the interactions remain limited enough for mostly focused testing. Exactly three identified EIPs add no uncapped-row quantity bonus.",
"score": 2,
"uncertainty_note": "The proposal also anticipates an unnumbered future state-tiering pricing EIP; its design and test interaction cannot be assessed from this snapshot.",
"under_specified": true,
"unidentified_interactions": [
"A separate, unnumbered state-tiering gas-pricing proposal is expected to consume the last-written-block metadata."
]
}
],
"eip": 8188,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8188:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The Abstract's no-gas-change scope conflicts with the normative SHOULD and concrete EIP-8037 STATE_BYTES_PER_* replacements in the Rationale.",
"The general rule says metadata changes when state is mutated, but the account-rule enumeration omits some account-field mutation classes visible in the required supporting EIP and does not fully reconcile all no-net balance cases.",
"The rubric's encoding anchor covers only transaction, block, and interface encoding; EIP-8188's major account and storage trie-leaf RLP change therefore scores zero on that anchor and is represented in other anchors."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "dc2306ba2877472dc2f5d85ae4024adc8127a02a0388130f656afa6e815e807f",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8188.md",
"git_blob_sha": "34da619b6f806f5a422bfef6ef73caf029aa3dcc",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8188.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8188.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8188.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8188.yaml",
"sha256": "f3e2ad4e1f86cdf52b89c4048de739fb3ad1cf851bc3d3c8d1157ca9fbec5022"
},
"supporting_documents": [
"supporting/eip-214.md",
"supporting/eip-6780.md",
"supporting/eip-8037.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 26,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of Draft EIP-8188 at the sealed Hegotá PFI snapshot. The proposal adds consensus last-written-block metadata to account and storage-slot state encodings, updates it on state mutation with lazy legacy compatibility, and directly interacts with EIPs 214, 6780, and 8037. No implementation, test, devnet, discussion-thread, or post-snapshot evidence is included.",
"tier": "high",
"title": "Last-Written Block for Accounts and Slots",
"under_specification": {
"affected_criteria": [
"state_gas_accounting_changes",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"modified_system_contracts",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 29,
"minimum": 22
},
"present": true,
"summary": "Material gaps remain around whether EIP-8188 itself changes EIP-8037 state-gas rates, the exhaustive set of account mutations that update metadata, ordinary no-net balance transfers, mixed-encoding canonicalization, and the concrete transition-tool and test-framework representation. These gaps can change several anchor scores but do not erase the broad mandatory state-root impact.",
"unresolved_questions": [
"Are the EIP-8037 parameter changes normative changes in EIP-8188, despite the statements that this proposal introduces no gas changes and leaves pricing separate?",
"Must every mutation of an existing account field update last_written_block, including the EOA-delegation code write described by EIP-8037, or only the account-rule cases explicitly enumerated in EIP-8188?",
"Does an ordinary nonzero value transfer from an address to itself update account metadata even though there is no net balance change, and how does that align with the explicit SELFDESTRUCT self-beneficiary exception?",
"What canonical transition-tool and test-fixture representation distinguishes legacy implied-zero metadata from explicitly encoded zero metadata?",
"Do stateful system-call paths require any special metadata, rollback, or fixture handling beyond the generic account and storage rules?"
]
}
},
"hegota:8200:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 22,
"recomputed_tier": "medium",
"recomputed_total": 22,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No gas accounting mechanism changes: the precompile-specific price tables disappear with the precompiles, and the pricing shift is the \"Modified precompiles\" row's substance.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Measured: an EELS prototype flips 948 fixture executions across 40 functions — spread from byzantium through osaka plus the ported static suites, but all within one well-scoped category: tests that exercise the three retired precompiles. Every flip has been diagnosed (gas drift in both directions, invalid-input semantics, warm-set loss): none is unexplained.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing primitives suffice with minor extension: a fork precompile-list subtraction and code pre-allocation at the retired addresses.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Nothing cryptographically new enters consensus: three well-known functions are reimplemented, and vast existing vector sets make the reimplementations differentially provable; the proving burden itself is scored under \"Edge/boundary conditions\".",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The equivalence surface is the full input domain of three functions: lengths, invalid encodings, and gas boundaries. Measured: the prototype bytecode already diverges on one edge — BLAKE2f's final-block flag `0x02` is accepted where EIP-152 requires rejection — and invalid inputs revert with `Error(string)` where the precompiles return empty revert data.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Three stateless code deposits appear at the retired addresses, but nothing in the protocol ever invokes them as system actors; the deployment act is scored under \"New fork activation mechanism\" and their behavioral surface under \"Edge/boundary conditions\".",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "The behavior of three pre-existing precompiles changes: ordinary EVM pricing (measured: small-input MODEXP ~6.6×, `rounds`-priced BLAKE2f callers out-of-gas, and an inverse case where the EIP-7883 formula exceeds the transaction gas cap but the EVM version succeeds), different invalid-input returndata, and loss of EIP-2929 pre-warming at the retired addresses — the last unstated by the EIP and measured as 198 flipped executions.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Code is written to three addresses at the start of the activation block — a protocol-mandated install with no deploying transaction, implemented in the prototype through the spec's irregular-state-transition hook (the EIP-8141 expiry-verifier pattern: code only, nonce and balance preserved) plus a genesis pre-allocation for test fixtures.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Three pure functions, fully benchmarkable in isolation; gas now scales with actual work (large-input MODEXP prices itself out rather than underpricing compute), and the benchmark-suite re-derivation is test rework, not client performance risk.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Consensus-critical bytecode replaces natively audited implementations; an implementation error is a consensus split. The measured BLAKE2f flag divergence is this risk realized in the current candidate bytecode — differential fuzzing against the retired implementations is mandatory.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The consensus artifact itself is unspecified: the EIP ships without the deployment bytecode, with TODO gas tables and TODO test cases. The prototype pins the runtime artifacts from eth-act/evmification's own CI; an independent compile reproduced every executable byte but differed in the CBOR metadata trailer — precisely the divergence that becomes a consensus split unless the EIP pins the exact bytes by hash. Every revision of the eventual bytecode re-baselines the whole differential corpus.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Three coordination targets — EIP-7666 (the shared deployment mechanism), the EIP-7883/7823 MODEXP pricing cluster (whose suites flip mechanically), and EIP-2929 (warm-set membership) — each limited in scope; EIP-152 is the substance being replaced, not a cross-EIP axis.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8200,
"fork": "hegota",
"id": "hegota:8200:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8200.yaml",
"sha256": "e90d9cac6551202a496874592f4acac48e8bcfe59b803e2742fa3337e8de1ac6"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "6a3be712b937ad5d7ecfa7bf4f0afaf0ee25e922",
"content_sha256": "d41a30af85354e7c175da20effcb31f9fa8b7aa46553c377489f6a48d949688c",
"git_blob_sha": "f83f82beeccd929d5e20512c9f7d711f73e63260",
"immutable_url": "https://github.com/ethspecs/pm/blob/6a3be712b937ad5d7ecfa7bf4f0afaf0ee25e922/complexity_assessments/EIPs/EIP-8200.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8200.md",
"pull_request": {
"draft": true,
"number": 109,
"title": "Add EIP-8200 complexity assessment",
"updated_at": "2026-08-18T08:08:34Z",
"url": "https://github.com/ethspecs/pm/pull/109"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 22,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "medium",
"title": "EVMification",
"under_specification": null
},
"hegota:8200:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Costs",
"source": "eip.md",
"summary": "Calls to all three addresses change from precompile-specific formulas to the standard costs of the EVM opcodes executed by the deployed code."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal explicitly states that gas costs will differ and may affect contracts relying on precise gas calculations."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Three existing special gas schedules are replaced by the existing EVM execution-accounting mechanism. This updates gas accounting but does not introduce a new metering mechanism, matching score 1.",
"score": 1,
"uncertainty_note": "The exact deltas cannot be calculated because all three bytecodes and gas comparisons are absent, but that omission does not change the anchor class.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "The specified change installs code at three addresses and ends native precompile treatment; it states no change to the internal ordering of an opcode's state access and gas charging."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state-access or gas-charge ordering rule is modified. The fork-time code write is an activation transition, not an ordering change inside opcode execution.",
"score": 0,
"uncertainty_note": "The bytecode is unspecified, but the snapshot contains no normative rule that changes state-access ordering for an opcode.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Costs",
"source": "eip.md",
"summary": "The only gas change described is replacement of three precompile formulas by standard EVM execution costs; no blob-gas mechanism is mentioned."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting rule is introduced or modified.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "The proposal requires a fork-time code installation, but specifies no state-gas price, charging site, budget, reservoir, or execution-gas spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "A fork activation state change is present, but the rubric's state-gas accounting mechanisms are not changed.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Costs",
"source": "eip.md",
"summary": "The gas section changes charging to standard opcode costs and specifies no refund production or refund accounting."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Deployment; Specification > Gas Costs",
"source": "eip.md",
"summary": "Three precompiles change execution path and gas calculation at their existing addresses from the activation block onward."
},
{
"locator": "Security Considerations > Implementation correctness",
"source": "eip.md",
"summary": "The replacement bytecode must be tested against original valid outputs and original invalid-input handling."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing vectors for three distinct precompiles require new execution and gas baselines. The affected tests are considerable but localized to the contrived category of calls to these three addresses, matching score 2.",
"score": 2,
"uncertainty_note": "Test Cases is only a TODO, so the exact breadth of existing-test rework is not determined and could be broader once bytecode is supplied.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "At activation, code must exist at each of three listed addresses and the addresses must cease being treated as precompiles."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The new fork state gives activation-focused pre-existing tests a narrow new assertion at three addresses. The snapshot does not require every unrelated post-fork test to assert it.",
"score": 1,
"uncertainty_note": "The missing bytecodes and test plan leave the exact assertion strategy unspecified.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "The transition must act at the start of the fork activation block, but the EIP defines no transition-tool field or interface mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Fork-block awareness is required operationally, yet no modification or new field in the transition-tool interface is specified, so the documented interface-change score is 0.",
"score": 0,
"uncertainty_note": "The package does not explain how the transition tool learns that the block is the activation block; later specification could require fields or a new mechanism.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "The entire test-cases section is a TODO and requires no new framework primitive."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The snapshot identifies no expectation type, modifier, helper, or permanent framework abstraction, so score 0 is the package-grounded result.",
"score": 0,
"uncertainty_note": "Because the test plan and bytecodes are missing, whether existing primitives suffice is not established.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Motivation",
"source": "eip.md",
"summary": "The proposal replaces RIPEMD-160, modular exponentiation, and BLAKE2f with EVM implementations while preserving functionality."
},
{
"locator": "Specification",
"source": "supporting/eip-152.md",
"summary": "BLAKE2f is a cryptographic compression function with a precisely encoded state, message, counters, round count, and final-block flag."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Multiple well-known cryptographic mechanisms must be reimplemented and equivalence-tested in a new execution form. This matches the multiple well-known mechanisms at score 2; no novel cryptography is introduced.",
"score": 2,
"uncertainty_note": "The concrete EVM implementations are absent, so implementation-specific cryptographic testing details remain unknown.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Test Cases",
"source": "supporting/eip-152.md",
"summary": "BLAKE2f has an exact 213-byte input, a restricted final flag, a 32-bit rounds value, and vectors for short, long, invalid-flag, zero-round, and maximum-round inputs."
},
{
"locator": "Specification; Rationale > Analysis",
"source": "supporting/eip-7823.md",
"summary": "MODEXP has three independently encoded length fields, zero-length cases, and an 8192-bit bound whose violation consumes all gas."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Each bytecode must match all valid outputs, all invalid-input handling, and changed fixed-gas-call behavior."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Three distinct variable-input mechanisms expose multiple boundaries, and MODEXP length combinations plus BLAKE2f length, flag, and round boundaries require an elevated case set. This matches score 3.",
"score": 3,
"uncertainty_note": "Missing bytecode prevents enumerating implementation-created boundaries, but the inherited interface boundaries already satisfy score 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification changes fork-time account code and precompile dispatch; it introduces no block RLP field or RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification contains constants, deployment, and gas rules only and introduces no Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is specified.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants; Specification > Deployment",
"source": "eip.md",
"summary": "EVM code is installed at three fixed protocol addresses at fork activation."
},
{
"locator": "Rationale > Bytecode at precompile address vs. library contracts",
"source": "eip.md",
"summary": "The deployed artifacts are contracts at the existing addresses rather than library contracts at new user-selected addresses."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Three protocol-installed EVM contracts are added, satisfying the multiple system-contract condition for score 2. None is specified as stateful or as triggering a new system action.",
"score": 2,
"uncertainty_note": "The exact contract code is not yet specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "The addresses are existing precompiles, while the EVM contracts installed there are new; no pre-existing EVM system contract code or state is named."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The direct changes are accounted for as added system contracts and modified precompiles. The package identifies no pre-existing system contract that is modified.",
"score": 0,
"uncertainty_note": "The rubric does not define precompiles as system contracts, so this assessment treats the separately named precompile anchors as controlling.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Deployment; Specification > Gas Costs",
"source": "eip.md",
"summary": "The proposal deploys bytecode charged under existing standard EVM opcode costs and specifies no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "Calls keep the same target addresses and are required to preserve functionality; the described result difference is gas cost, which this anchor excludes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode result rule is modified or deprecated. The CALL-family dispatch reaches code instead of a precompile, but the target functionality is required to remain equivalent and gas changes are scored separately.",
"score": 0,
"uncertainty_note": "Exact equivalence cannot be checked until bytecode exists, but the normative proposal does not modify an opcode's result.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "Three addresses cease being treated as precompiles; no precompile is added."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The proposal removes native precompile treatment rather than adding a precompile.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Deployment; Specification > Gas Costs",
"source": "eip.md",
"summary": "RIPEMD-160, MODEXP, and BLAKE2f stop being precompiles and their three special gas schedules are replaced with bytecode execution costs."
},
{
"locator": "Security Considerations > Implementation correctness",
"source": "eip.md",
"summary": "Valid outputs and invalid-input behavior are intended to remain identical under the replacement implementation."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Multiple existing precompiles have their gas schedules modified, which is the explicit score-2 anchor. Functional behavior is specified as equivalent, so score 3 is not assigned on the sealed text.",
"score": 2,
"uncertainty_note": "Without bytecode or tests, it is unresolved whether observable behavior beyond gas will in fact differ for any edge input.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Bytecode at precompile address vs. library contracts",
"source": "eip.md",
"summary": "Existing callers retain the same addresses and interfaces; no transaction, block, or interface-level RLP or SSZ change is introduced."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding is changed.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The proposal specifies only fork-time deployment and changed call charging, with no new transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Costs; Backwards Compatibility",
"source": "eip.md",
"summary": "Gas changes apply during calls to the three addresses; no transaction validity rule or intrinsic gas calculation is changed."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Internal execution may run out of gas under a fixed-gas call, but transaction admission, validity, and intrinsic gas are unchanged.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The specification introduces no block body or block header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty is present in the package for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "At the start of the activation block, client state must be changed by setting code at each of three precompile addresses."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The rubric assigns score 3 when state is modified at the fork activation block. This proposal performs three explicit code-state modifications then.",
"score": 3,
"uncertainty_note": "The byte values are missing, but the requirement to modify state at activation is unambiguous.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation; Specification > Gas Costs",
"source": "eip.md",
"summary": "Three special native implementations become EVM execution; MODEXP is expected to cost more for large inputs and all gas comparisons remain TODOs."
},
{
"locator": "Rationale; Appendix - benchmarks",
"source": "supporting/eip-152.md",
"summary": "BLAKE2f was introduced as a native precompile because EVM word semantics are inefficient for it, and the supporting document records round-dependent native benchmarks."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance must be validated both for individual bytecodes and their effect on existing precompile workloads and client EVM execution. The impact is not fully established in isolation but is confined to three call targets on the package evidence, matching score 2.",
"score": 2,
"uncertainty_note": "No bytecode, impact analysis, or bytecode gas/performance comparison is present, so substantial performance impact cannot be excluded.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Fixed-gas callers may revert, and each replacement must be thoroughly tested and audited for every valid output and invalid-input behavior."
},
{
"locator": "Motivation",
"source": "eip.md",
"summary": "The proposal targets three special implementations whose cross-client maintenance is itself described as carrying consensus-bug risk."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The activation transition, ordinary EVM execution, gas behavior, and three existing cryptographic interfaces all interact. Incorrect equivalence can cause consensus divergence or user-contract failure, requiring extensive review, differential testing, and fuzzing across multiple critical components.",
"score": 3,
"uncertainty_note": "Exact bytecode is absent, so its concrete attack surface and audit findings cannot be assessed from the package.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Deployment",
"source": "eip.md",
"summary": "The exact consensus bytecode for all three addresses is explicitly not yet specified."
},
{
"locator": "Specification > Gas Costs; Test Cases",
"source": "eip.md",
"summary": "Each gas comparison and the complete test-cases section are TODOs, while gas is a function of the missing bytecode."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot derive the activation state, exact gas results, or executable edge behavior from the snapshot. Newly deployed code bytes and their behavior are consensus-critical and must be agreed before vectors can be baselined, matching score 3.",
"score": 3,
"uncertainty_note": "This score measures the snapshot's explicit incompleteness; no package evidence establishes implementations, devnets, or resolved questions.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Abstract; Rationale > Same mechanism as EIP-7666",
"source": "eip.md",
"summary": "EIP-8200 requires 152, 7666, 7823, and 7883, replaces behavior at three existing precompile addresses, and adopts the 7666 deployment mechanism."
},
{
"locator": "Specification",
"source": "supporting/eip-7823.md",
"summary": "The current MODEXP interface originates in 198 and its three input lengths are capped by 7823, including an all-gas error path above the bounds."
},
{
"locator": "Abstract; Specification; Test Cases",
"source": "supporting/eip-7883.md",
"summary": "EIP-7883 defines the current MODEXP gas formula and updated costs whose special pricing EIP-8200 replaces."
}
],
"exceptional_score_justification": "Six separately package-grounded interactions each require coordinated cases; under the uncapped formula, three interactions beyond the first three add one point to the score-3 anchor.",
"id": "cross_eip_interactions",
"interacting_eips": [
152,
198,
7666,
7823,
7883
],
"rationale": "Coordinated cases are required for 152, 198, 7666, 7823, and 7883, plus the package-described but unnumbered RIPEMD-160 precompile specification. These six interactions span deployment, legacy functional equivalence, input bounds, and gas baselines. The uncapped rule gives base score 3 plus 1 for the third additional interaction beyond the first three.",
"score": 4,
"uncertainty_note": "The package does not identify the EIP number defining the current RIPEMD-160 precompile, so that interaction is recorded separately rather than guessed.",
"under_specified": false,
"unidentified_interactions": [
"Current RIPEMD-160 precompile specification and gas schedule; its EIP number is not identified in the package."
]
}
],
"eip": 8200,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8200:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"Functional equivalence is stated as a goal but is not executable or byte-for-byte deterministic without the three missing bytecodes.",
"Standard EVM execution costs do not determine numeric gas results until exact opcode sequences and their input-dependent control flow are supplied.",
"Invalid-input equivalence is required by Security Considerations but is not normatively enumerated for the three replacements in EIP-8200.",
"The activation-block action is explicit, while its transition-tool signaling and test-fixture representation are not described."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "15d2e9e885d61c6fe3004754fb907b3c9d46ab5610863257ab0a5cd2cf33ed1c",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8200.md",
"git_blob_sha": "17c2158560442fcd6b28bbaa42435a5657e5e703",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8200.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8200.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8200.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8200.yaml",
"sha256": "7b1b91b5e99b87ff7184749f17ca68415d7aeb73d4103f12eaa522d18c489df0"
},
"supporting_documents": [
"supporting/eip-152.md",
"supporting/eip-7666.md",
"supporting/eip-7823.md",
"supporting/eip-7883.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 28,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the Draft EIP-8200 snapshot. The proposal installs unspecified EVM bytecode at the RIPEMD-160, MODEXP, and BLAKE2f precompile addresses at fork activation, stops native precompile treatment, and replaces their special gas formulas with standard EVM execution costs.",
"tier": "high",
"title": "EVMification",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"cryptography",
"modified_precompiles",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 36,
"minimum": 26
},
"present": true,
"summary": "Material consensus inputs are absent: none of the three deployment bytecodes is specified, all gas comparisons are TODOs, and Test Cases is entirely TODO. The omissions prevent exact activation state, gas baselines, executable edge semantics, performance bounds, and test infrastructure needs from being fixed.",
"unresolved_questions": [
"What exact byte sequence must be installed at each of the three addresses?",
"How does each bytecode normatively reproduce every valid output and every invalid-input failure mode of the replaced precompile?",
"What are the exact gas costs and compatibility effects across each input-size and fixed-forwarded-gas boundary?",
"What activation-block inputs or transition-tool interface, if any, are required to perform and verify the code installation?",
"Which existing tests must be reworked, which unrelated tests gain assertions, and which new framework primitives are required?"
]
}
},
"hegota:8205:human:r1": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "low",
"published_total": 5,
"recomputed_tier": "low",
"recomputed_total": 5,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_encoding_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8205,
"fork": "hegota",
"id": "hegota:8205:human:r1",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8205.yaml",
"sha256": "5c71d016532338a998a2f35257a99922dced8415897f4858ba214631c0a6a270"
},
"rubric": {
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"known_source_defects": [
"The checklist contains Engine API encoding changes but the template has no dedicated definition for that row."
],
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 1
},
"source_record": {
"commit": "7bdc9e9829d47ac2f7520f23e0692e099a51e95f",
"content_sha256": "fcab9b8af1fae3a1b15c3748b5e40b14189f2706b01e43cfe7a61e5a64d7ba6e",
"git_blob_sha": "0000ef39c9512689dd5f442c1c91d25a3db50923",
"immutable_url": "https://github.com/ethspecs/pm/blob/7bdc9e9829d47ac2f7520f23e0692e099a51e95f/complexity_assessments/EIPs/EIP-8205.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8205.md",
"pull_request": {
"draft": false,
"number": 73,
"title": "Add complexity assessments",
"updated_at": "2026-05-29T13:54:05Z",
"url": "https://github.com/ethspecs/pm/pull/73"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 1,
"score": 5,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "low",
"title": "Withdrawal credentials preregistration",
"under_specification": null
},
"hegota:8205:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract > System Call",
"source": "eip.md",
"summary": "The mandatory call has a dedicated 30,000,000 gas limit; assigned and consumed gas are excluded from block-gas checks, and EIP-1559 burn semantics do not apply."
},
{
"locator": "Specification > Execution layer > Withdrawal Request Contract > System Call",
"source": "supporting/eip-7002.md",
"summary": "The same dedicated, block-gas-excluded system-call accounting already exists for withdrawal requests."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal extends the established system-call gas-accounting pattern to one additional mandatory call. This updates where that existing mechanism applies, without changing opcode gas schedules or ordinary transaction gas accounting.",
"score": 1,
"uncertainty_note": "Runtime bytecode is TBD, but the consensus-critical gas treatment of the system call is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract",
"source": "eip.md",
"summary": "The execution change is a contract and post-block call; it does not alter any opcode's internal state-access or gas-charge sequence."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Contract SLOAD/SSTORE activity does not change where state is accessed inside an opcode, and the proposal adds or modifies no opcode ordering rule.",
"score": 0,
"uncertainty_note": "The missing contract bytecode affects implementation completeness, not the specified absence of opcode-internal ordering changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Configuration > Execution layer",
"source": "eip.md",
"summary": "Configuration defines preregistration request fees and queue parameters, with no blob-gas variable or rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The request fee is an independent contract fee; no blob-gas accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob-gas behavior is present in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract > Add Preregistration Request",
"source": "eip.md",
"summary": "Queue writes use ordinary SSTORE pseudocode and define no StateGasCosts, state-byte rate, state-gas budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Writing contract storage is not itself a change to the rubric's separate state-gas accounting mechanism.",
"score": 0,
"uncertainty_note": "Bytecode is missing, but the draft specifies no state-gas charging site or budget interaction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Fee overpayment",
"source": "eip.md",
"summary": "The system contract does not refund excess request-fee payment."
},
{
"locator": "Specification > Execution layer > Preregistration Request Contract",
"source": "eip.md",
"summary": "No EVM gas-refund mechanism is specified on any contract path."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal neither creates nor changes an EVM gas refund; its explicit no-refund rule concerns excess ETH request fees, not gas accounting.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "A new system contract and EIP-7685 request type make execution-layer block structure and validation backward-incompatible at the fork."
},
{
"locator": "Specification > Execution Layer > Block Header",
"source": "supporting/eip-7685.md",
"summary": "Block requests are ordered by request type, hashed, and committed through requests_hash; empty request data is excluded."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork tests around EIP-7685 request construction, request ordering, block validation, and fork allocations need a localized update. Empty request data remains commitment-neutral, so the evidence does not show broad reworking of unrelated execution tests.",
"score": 1,
"uncertainty_note": "The TBD address, type allocation, bytecode, and deployment prevent fixing the exact subset of existing fork and request tests that changes.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale > Removing empty requests in commitment",
"source": "supporting/eip-7685.md",
"summary": "Empty request elements are excluded so the empty requests hash is stable across forks."
},
{
"locator": "Specification > Execution layer > Preregistration Request Contract > System Call",
"source": "eip.md",
"summary": "Only dequeued preregistration records must newly appear in the existing EIP-7685 requests list."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests not exercising preregistration do not gain a new universally required assertion: an empty result leaves the existing request commitment stable.",
"score": 0,
"uncertainty_note": "Launcher or framework conventions for exposing empty per-type results are not specified, but no protocol-level new assertion is shown for every test.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration request operation",
"source": "eip.md",
"summary": "The new result is represented as an ordinary EIP-7685 request_type plus opaque request_data."
},
{
"locator": "Specification > Execution Layer > Requests",
"source": "supporting/eip-7685.md",
"summary": "The existing generic request object already carries a type byte and opaque byte array for proposal-specific formats."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The sealed text requires a new request value and state transition, but it identifies no new transition-tool field or interface mechanism beyond the existing generic EIP-7685 request list.",
"score": 0,
"uncertainty_note": "Transition-tool details are not specified, so an implementation could need interface work; the package does not establish a scoreable new field or mechanism.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Test vectors are TBD and no new framework abstraction is proposed."
},
{
"locator": "Specification > Execution layer > Preregistration Request Contract",
"source": "eip.md",
"summary": "The specified behaviors are contract calls, storage changes, logs, reverts, returned bytes, and block validity outcomes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Nothing in the package requires a new expectation type, modifier, or framework-level helper rather than ordinary execution and block tests.",
"score": 0,
"uncertainty_note": "Tests and the reference implementation are TBD, so later test design could reveal a primitive need that is not evidenced in this snapshot.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > BLS verification on CL only",
"source": "eip.md",
"summary": "BLS verification is deliberately performed only by the consensus layer; the execution system contract is only a rate-limited queue."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Under the execution-layer-only scope, no cryptographic mechanism is added or modified. Consensus-layer BLS verification is boundary context and is not scored here.",
"score": 0,
"uncertainty_note": "No execution-layer cryptographic operation is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract",
"source": "eip.md",
"summary": "Dispatch depends on system versus non-system caller, calldata lengths 0, 176, or other, attached value, fee sufficiency, and empty/non-empty system calldata."
},
{
"locator": "Specification > Execution layer > Preregistration Request Contract > System Call",
"source": "eip.md",
"summary": "Queue draining is capped at four, head/tail reset when empty, excess is updated across the target boundary, and the inhibitor has activation, disable, and re-enable behavior."
},
{
"locator": "Security Considerations > System call failure",
"source": "eip.md",
"summary": "A failed system call makes the block invalid."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Several independent boundary-prone mechanisms combine: dispatch and value matrices, exact fee/excess arithmetic, queue empty/partial/capped states, activation/inhibitor transitions, and fatal system-call outcomes. Fee growth and persistent queue indices require an elevated set of boundary cases.",
"score": 3,
"uncertainty_note": "Exact bytecode-level edge results remain unbaselineable until the runtime bytecode is supplied.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility > Execution layer",
"source": "eip.md",
"summary": "The execution change is a new system contract and EIP-7685 request type, not a new block RLP field or RLP validation rule."
},
{
"locator": "Specification > Execution Layer > Requests",
"source": "supporting/eip-7685.md",
"summary": "Request payloads are opaque bytes within the existing request bus."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Block validation changes, but the rubric specifically scores new block RLP validation mechanisms requiring sync tests; the proposal introduces none.",
"score": 0,
"uncertainty_note": "Request replay during sync still needs ordinary block-validation coverage, but it does not meet this row's RLP-specific anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration request operation",
"source": "eip.md",
"summary": "The draft defines an EIP-7685 request object and no Engine API field, endpoint, or communication mechanism."
},
{
"locator": "Engine API",
"source": "supporting/eip-7732.md",
"summary": "EIP-7732 states that no Engine API changes are needed."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No new Engine API field or endpoint is specified for preregistration; its bytes use the existing execution-request carriage.",
"score": 0,
"uncertainty_note": "The draft does not explain transition-tool or Engine serialization in detail, but absence of a specified new API surface limits this score to zero.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract",
"source": "eip.md",
"summary": "One new contract maintains fee, count, head, tail, and queue storage and emits/dequeues preregistration requests."
},
{
"locator": "Backwards Compatibility > Execution layer",
"source": "eip.md",
"summary": "The execution layer deploys a new system contract and introduces a new EIP-7685 request type."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Exactly one new system contract is introduced, and it is both stateful and the source of a new consensus-layer request action, matching score 2.",
"score": 2,
"uncertainty_note": "Address, bytecode, and deployment transaction are TBD, but the contract's stateful and request-triggering character is explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility > Execution layer",
"source": "eip.md",
"summary": "The execution change adds a new contract rather than modifying one."
},
{
"locator": "Security Considerations > Builder deposits",
"source": "eip.md",
"summary": "Builder requests use an independent request type and registry and are not consumed or authorized by preregistration."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system-contract code or state is changed, and the package specifies independent behavior rather than an indirect behavioral change to another predeploy.",
"score": 0,
"uncertainty_note": "Coexistence on EIP-7685 is scored under cross-EIP interactions, not as a modification of another system contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer",
"source": "eip.md",
"summary": "The execution-layer feature is a contract and request type; no opcode is added."
},
{
"locator": "Rationale > Deposit process for staking protocols",
"source": "eip.md",
"summary": "SLOTNUM is consumed from EIP-7843 by an application flow rather than added by EIP-8205."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced by this proposal.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer",
"source": "eip.md",
"summary": "No pre-existing opcode behavior or result is modified."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The system-contract mechanism uses existing EVM operations unchanged.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer",
"source": "eip.md",
"summary": "A stateful predeploy contract, not a precompile, is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer",
"source": "eip.md",
"summary": "The proposal specifies no change to precompile logic or gas schedules."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration request operation",
"source": "eip.md",
"summary": "A new block request encoding is defined as a type byte plus the flat concatenation of fixed 176-byte pubkey, credentials, and signature records."
},
{
"locator": "Specification > Execution Layer > Requests",
"source": "supporting/eip-7685.md",
"summary": "Each proposal-specific request_data encoding is carried inside the block's typed request object and committed by requests_hash."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal introduces a new fixed-width encoding at block/request-interface level. This binary rubric row assigns 3 whenever such an encoding change is introduced.",
"score": 3,
"uncertainty_note": "The request-type value is TBD, but the record layout and block-interface placement are explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract > Add Preregistration Request",
"source": "eip.md",
"summary": "Preregistrations are submitted by ordinary calls to a contract."
},
{
"locator": "Specification > Execution Layer > Requests",
"source": "supporting/eip-7685.md",
"summary": "An EIP-7685 request type is a block request object, not a transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The new request type does not introduce a transaction envelope type.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract",
"source": "eip.md",
"summary": "Invalid input lengths, insufficient fees, and value-bearing getters revert through contract execution; no transaction validity or intrinsic-gas rule changes."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The proposal adds contract-level success and revert conditions but leaves the validity rules and intrinsic gas of all transaction types unchanged.",
"score": 0,
"uncertainty_note": "No transaction-level validity change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility > Execution layer",
"source": "eip.md",
"summary": "The execution additions are a system contract and EIP-7685 request type."
},
{
"locator": "Specification > Execution Layer > Block Header",
"source": "supporting/eip-7685.md",
"summary": "EIP-7685 already supplies the requests_hash header commitment."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "EIP-8205 adds data under an existing request commitment and does not add a new block or header field of its own.",
"score": 0,
"uncertainty_note": "The TBD request-type allocation does not create a header field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract > System Call",
"source": "eip.md",
"summary": "Starting at FORK_BLOCK, every block performs the system call; the first call changes EXCESS_INHIBITOR to zero and resets per-block state."
},
{
"locator": "Specification > Execution layer > Preregistration Request Contract > Fee calculation",
"source": "eip.md",
"summary": "Requests revert while the inhibitor remains active before activation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation is not merely awareness of a new variable: the first mandatory system call changes predeploy storage from the inhibitor state to the enabled state. The rubric's binary state-modification anchor therefore scores 3.",
"score": 3,
"uncertainty_note": "The deterministic deployment transaction and exact pre-fork allocation are TBD, creating uncertainty about how the required inhibitor pre-state is materialized, not about the specified activation write.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Execution layer > Preregistration Request Contract > System Call",
"source": "eip.md",
"summary": "Every block executes a 30,000,000-gas-budget system call that reads and writes queue state and drains up to four 176-byte records."
},
{
"locator": "Security Considerations > DoS and state growth",
"source": "eip.md",
"summary": "Submissions can create sustained queue/state load; the fee reacts only in the following block and serves as an economic rate limiter."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Individual paths are benchmarkable, but end-to-end cost depends on ordinary transaction submissions, persistent storage, queue backlog, fee-loop state, and mandatory post-block execution. The drain cap limits the impact, fitting a limited interaction with existing block-performance behavior.",
"score": 2,
"uncertainty_note": "Runtime bytecode is TBD, so exact gas, worst-case fake-exponential iteration, and system-call headroom cannot be measured from the package.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations > DoS and state growth",
"source": "eip.md",
"summary": "Fee lag permits all same-block submissions to pay the old fee, while persistent spam grows request state and raises subsequent fees."
},
{
"locator": "Security Considerations > System call failure",
"source": "eip.md",
"summary": "Any system-call failure makes the block invalid."
},
{
"locator": "Security Considerations > Empty code failure",
"source": "eip.md",
"summary": "Missing predeploy code makes the block invalid."
},
{
"locator": "Security Considerations > Fee overpayment",
"source": "eip.md",
"summary": "Excess payment is retained rather than refunded."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The execution mechanism touches a limited set of critical components: a value-holding stateful queue, economic rate limiting, EIP-7685 block requests, and fatal block-validation paths. These require targeted review and fuzzing, but the package does not show a substantial alteration of several existing execution security invariants.",
"score": 2,
"uncertainty_note": "Missing bytecode and deployment artifacts prevent code-level review, and the execution-only scope excludes the larger consensus-layer deposit-enforcement security analysis.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Configuration > Execution layer",
"source": "eip.md",
"summary": "PREREGISTRATION_REQUEST_PREDEPLOY_ADDRESS and PREREGISTRATION_REQUEST_TYPE are TBD."
},
{
"locator": "Specification > Execution layer > Preregistration Request Contract > Bytecode",
"source": "eip.md",
"summary": "Runtime bytecode is TBD."
},
{
"locator": "Specification > Execution layer > Preregistration Request Contract > Deployment",
"source": "eip.md",
"summary": "The deterministic deployment transaction is TBD."
},
{
"locator": "Test Cases; Reference Implementation",
"source": "eip.md",
"summary": "Both test vectors and the reference implementation are TBD."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Exact type allocation, address, executable code, and deployment/pre-state are localized but consensus-critical details that clients need before block and fork tests can be baselined. The behavior is newly introduced rather than a previously unobservable existing behavior, so score 3 is not reached.",
"score": 2,
"uncertainty_note": "The pseudocode resolves most functional cases, but the missing artifacts are material and cannot be repaired from memory under the snapshot rules.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Specification; Rationale; Security Considerations",
"source": "eip.md",
"summary": "The draft explicitly connects its fee, system-call, request-bus, deposit, payload-timing, proof/deadline, and builder-separation behavior to EIPs 1559, 4788, 6110, 7002, 7251, 7685, 7732, 7843, and 8282."
},
{
"locator": "Specification > Execution Layer",
"source": "supporting/eip-7685.md",
"summary": "The shared request bus fixes cross-type ordering and requests_hash commitment rules for all request producers."
},
{
"locator": "Specification > Execution layer > Withdrawal Request Contract",
"source": "supporting/eip-7002.md",
"summary": "An existing fee-metered request predeploy shares the block request bus and mandatory post-block system-call pattern."
},
{
"locator": "Specification > Execution layer > Consolidation request contract",
"source": "supporting/eip-7251.md",
"summary": "A second existing predeploy shares the request bus, queue, fee, and system call pattern."
},
{
"locator": "Specification > Request queue and system call; Changes to EIP-7732",
"source": "supporting/eip-8282.md",
"summary": "Builder request types coexist on EIP-7685 and are specified as independent from validator deposit routing."
}
],
"exceptional_score_justification": "This is the rubric's intentionally uncapped formula, not a discretionary exceptional score: nine interacting EIPs yield 3 + floor((9 - 3) / 3) = 5.",
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
4788,
6110,
7002,
7251,
7685,
7732,
7843,
8282
],
"rationale": "Coordinated cases are needed for EIP-7685 encoding/order/commitment; EIP-1559 gas-burn exclusion and fee-derived behavior; coexistence with EIP-7002 and EIP-7251 request predeploys; EIP-6110 deposit request carriage; EIP-7732's delayed execution-request context; EIP-4788 proof consumption; EIP-7843 deadline checks; and EIP-8282 request-type/builder independence. That is nine identified interactions: base score 3, plus 2 for six additional EIPs beyond the first three. Consensus-only state-transition costs are excluded, but the execution request bus and application-facing proof/deadline boundaries remain coordinated execution-layer test axes.",
"score": 5,
"uncertainty_note": "EIPs 4788 and 7843 are exercised by the specified staking-protocol workflow rather than by the preregistration predeploy itself, while much of the 6110, 7732, and 8282 semantic interaction lies across the consensus boundary.",
"under_specified": true,
"unidentified_interactions": []
}
],
"eip": 8205,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8205:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"Request ordering is consensus-critical under EIP-7685, but EIP-8205 leaves its request-type value TBD.",
"Pseudocode defines intended contract behavior, while the consensus-critical runtime bytecode and deterministic deployment transaction remain TBD.",
"The proposal requires a first-call inhibitor reset at FORK_BLOCK but does not provide the deployment artifact that establishes the required pre-fork code and storage.",
"Tests and reference implementation are both TBD, so no package evidence shows that all execution edge cases or multi-request-type compositions are baselined."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "c6259cbcdd486f0354f852d92d1355d34f0332a02b7faef11f84440542cae9f0",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8205.md",
"git_blob_sha": "6c78772098b5203ffbe95a77660d826798309250",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8205.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8205.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8205.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8205.yaml",
"sha256": "6f296d32d27674d2b39a0af1f46a9f0ad5ae35acecdefff9b36b5c543e2f3124"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-4788.md",
"supporting/eip-6110.md",
"supporting/eip-7002.md",
"supporting/eip-7251.md",
"supporting/eip-7685.md",
"supporting/eip-7732.md",
"supporting/eip-7843.md",
"supporting/eip-8282.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 24,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the draft EIP-8205 surface: one new stateful EIP-7685 request predeploy, ordinary-call submission and fee-getter paths, a mandatory end-of-block system call, fixed-width request production, fork activation, and the resulting block-validity, performance, security, and cross-EIP testing effects. Consensus-layer preregistration storage, signature verification, expiry, and deposit enforcement are boundary context only and are not independently scored.",
"tier": "high",
"title": "Withdrawal credentials preregistration",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"added_system_contracts",
"encoding_changes_rlp_ssz",
"new_fork_activation_mechanism",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 31,
"minimum": 20
},
"present": true,
"summary": "The draft's execution pseudocode is substantial, but the predeploy address, request-type allocation, runtime bytecode, deterministic deployment transaction and pre-state, test vectors, and reference implementation are absent. These gaps prevent exact cross-client baselining and make interface, regression-test, performance, and security effort materially uncertain.",
"unresolved_questions": [
"What final predeploy address and EIP-7685 request-type byte are allocated, and therefore where does this type sort relative to every active request type?",
"What exact runtime bytecode, deployment transaction, deployment timing, and inhibitor-bearing pre-state implement the pseudocode at activation?",
"Does the existing generic transition-tool and execution-request interface carry the new type without fields or primitives not described in the draft?",
"What executable vectors baseline dispatch, fee arithmetic, queue boundaries, activation, system-call failure, and coexistence with other request types?"
]
}
},
"hegota:8237:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "The EL rule introduced is equality validation of partial_header_hash; no EVM gas rule is added or changed."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes block-level commitment validation, not EVM gas accounting.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "Verification computes a block-level hash from header, withdrawals, slot, and request data and does not alter opcode execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state access or gas-charge ordering is modified.",
"score": 0,
"uncertainty_note": "No opcode-level behavior is specified by this EIP.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Modified Containers > ExecutionPayload",
"source": "eip.md",
"summary": "Existing blob_gas_used and excess_blob_gas fields are shown unchanged while only partial_header_hash is added."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal introduces no blob gas accounting rule.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "The new operation is block commitment hashing and comparison, with no state-gas cost, budget, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-writing gas mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer",
"source": "eip.md",
"summary": "The complete EL specification adds payload/header commitment fields, validation, and an API lookup, but no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "There is no new EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Modified Containers",
"source": "eip.md",
"summary": "Every post-activation ExecutionPayload and execution header gains partial_header_hash, which is covered by block_hash."
},
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "EL block validation must independently recompute the new commitment and reject a mismatch."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "This is a new validation rule on every post-activation execution block. Existing payload/header construction, block-hash, valid-block, invalid-block, and sync patterns must be reworked to populate the field and satisfy or intentionally violate the commitment, making the affected test surface broad rather than a contrived subset.",
"score": 3,
"uncertainty_note": "The package does not enumerate test suites, but the mandatory field and validation apply uniformly to post-activation execution blocks.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "Each EL-validated block must satisfy block.partial_header_hash == expected over the specified block and request fields."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to EIP-8237 but constructing a post-activation execution block gain the same mechanically applied commitment invariant. The evidence does not require re-deriving pre-fork vectors, so the score remains below 3.",
"score": 2,
"uncertainty_note": "Whether individual harnesses expose this as an explicit assertion or implicit block-validity check is not specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Execution Layer > Modified Containers > ExecutionPayload",
"source": "eip.md",
"summary": "A single new partial_header_hash field is added to ExecutionPayload."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool processing the fork's payload shape needs one new input/output field.",
"score": 1,
"uncertainty_note": "The package does not define a transition-tool schema separately from ExecutionPayload.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Accumulator Definition",
"source": "eip.md",
"summary": "The proposal defines the expected value using SHA256, concatenation, and raw serialization without requiring a novel expectation or modifier abstraction."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The sealed proposal establishes test cases and data generation needs, but does not require a new framework-level primitive beyond ordinary hash calculation and equality checks.",
"score": 0,
"uncertainty_note": "No test-framework design is included in the package; absent such evidence, no framework primitive is scored.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > SHA256 Instead of Hash Tree Root",
"source": "eip.md",
"summary": "The new commitment explicitly uses plain SHA256, selected as a primitive both layers already have."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "One well-known cryptographic hash mechanism is newly used for the consensus-critical accumulator.",
"score": 1,
"uncertainty_note": "No novel cryptographic primitive or construction beyond the specified SHA256 commitment is evidenced.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Accumulator Definition",
"source": "eip.md",
"summary": "The hash preimage combines fixed-width values with variable lists of withdrawals and execution requests using raw concatenated serialization."
},
{
"locator": "Execution Engine API",
"source": "eip.md",
"summary": "After long range sync, divergence can occur at an unknown block and the new per-block lookup is intended to locate it."
},
{
"locator": "Rationale > Accumulator Pattern",
"source": "eip.md",
"summary": "The commitment chains across sequential blocks and permits deferred verification of an entire range."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Tests must cover empty and populated variable lists, serialization boundaries, correct and incorrect field components, parent-linked accumulator continuity, and divergence at different positions in a synced range. The variable-list and chain-position dimensions create an elevated case count.",
"score": 3,
"uncertainty_note": "Exact list serialization and divergence-search behavior are under-specified, increasing uncertainty about the final boundary matrix but not eliminating it.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "Independent CL/EL range sync and deferred cross-layer verification are the proposal's stated synchronization purpose."
},
{
"locator": "Execution Layer > Modified Containers > Header",
"source": "eip.md",
"summary": "The execution block header gains partial_header_hash and block_hash covers it."
},
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "Synced execution blocks must pass a multi-field accumulator validation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "The new header member and its consensus-critical multi-input validation form a single complex block-validation change that execution-client sync tests must exercise.",
"score": 2,
"uncertainty_note": "The EIP does not explicitly spell out the header's RLP position or sync importer behavior, so complexity between simple and complex validation remains plausible.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Engine API",
"source": "eip.md",
"summary": "The Execution Engine requires a new method that returns the accumulator for a supplied block_hash."
},
{
"locator": "Execution Layer > Modified Containers > ExecutionPayload",
"source": "eip.md",
"summary": "ExecutionPayload gains the partial_header_hash field."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "A new Engine API endpoint is explicitly required, meeting score 2; the package specifies only one new payload field, so the score-3 combination of multiple fields plus a new endpoint is not established.",
"score": 2,
"uncertainty_note": "The new method's name, request/response schema, versioning, error behavior, and historical-availability requirements are unspecified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer",
"source": "eip.md",
"summary": "The EL changes consist of container/header fields, accumulator validation, and an Engine API method; no system contract is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contract exists in the sealed proposal.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer",
"source": "eip.md",
"summary": "No pre-existing system contract code, state, call, or indirect behavior is modified by the specified EL mechanism."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal has no specified system-contract interaction.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer",
"source": "eip.md",
"summary": "The EL specification introduces no EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer",
"source": "eip.md",
"summary": "The block-level accumulator changes do not alter or deprecate any existing opcode behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode is modified.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > SHA256 Instead of Hash Tree Root",
"source": "eip.md",
"summary": "SHA256 is used by client validation as an existing primitive; the EIP does not add an EVM precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > SHA256 Instead of Hash Tree Root",
"source": "eip.md",
"summary": "The proposal selects SHA256 for client-side commitment calculation and specifies no precompile logic or gas-schedule modification."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Modified Containers",
"source": "eip.md",
"summary": "partial_header_hash is added to both ExecutionPayload and the execution block Header and is covered by block_hash."
},
{
"locator": "Accumulator Definition",
"source": "eip.md",
"summary": "Consensus-critical raw byte serialization is prescribed for uint64 values and list elements in the SHA256 preimage."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "A new field changes the encoded execution block header and payload/interface shape, satisfying the rubric's binary encoding-change anchor.",
"score": 3,
"uncertainty_note": "Exact field placement and complete raw serialization of composite list entries are not fully specified, but an encoding change is unambiguous.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Modified Containers > ExecutionPayload",
"source": "eip.md",
"summary": "The existing transactions list is shown unchanged; the added value is a payload/header field."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The proposal adds no transaction type.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "The new validity assertion applies to the block's partial_header_hash, not to transaction validity or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity rules and intrinsic-gas calculation are unchanged.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed execution-layer text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Modified Containers > Header",
"source": "eip.md",
"summary": "The EIP explicitly adds partial_header_hash to the execution layer block header and states that block_hash covers it."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The rubric assigns 3 whenever a new block or header field is introduced.",
"score": 3,
"uncertainty_note": "Field placement is under-specified, but introduction of the field is explicit.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The container changes require hard-fork activation, but no activation-block state mutation or pre-existing internal-variable modification is specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Requiring a hard fork is not itself the special activation mechanism scored by this row.",
"score": 0,
"uncertainty_note": "The EIP gives no activation procedure; no scored mutation may be inferred from that absence.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "EL validation adds one SHA256 computation over several fixed fields and the withdrawals and execution-requests lists for each block."
},
{
"locator": "Execution Engine API",
"source": "eip.md",
"summary": "The engine must support accumulator retrieval by block hash during divergence diagnosis after long range sync."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The per-block hash calculation and keyed lookup are new performance-sensitive operations, but their core costs can be benchmarked in isolation and the package does not establish substantial impact on existing EL benchmarks.",
"score": 1,
"uncertainty_note": "Historical retention and repeated lookup/search behavior are unspecified; a less isolated storage design could raise the score to 2.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution Layer > Modified Containers > Header",
"source": "eip.md",
"summary": "The new commitment becomes part of the execution block hash."
},
{
"locator": "Execution Layer > Execution Layer Verification",
"source": "eip.md",
"summary": "EL consensus validity depends on independently recomputing and matching the commitment across header fields, withdrawals, slot number, and execution requests."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The commitment is the cryptographic guarantee intended to detect inconsistency after deferred cross-layer verification."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect encoding, accumulation, request derivation, or validation can split EL block validity and undermine deferred inconsistency detection. The mechanism touches multiple critical components—header hashing, block validation, withdrawals, execution requests, and Engine API coordination—requiring broad security review and adversarial testing even though the EIP claims no new trust assumption.",
"score": 3,
"uncertainty_note": "The consensus-layer sync process itself is outside the scored surface; the score reflects only failure modes of the EL commitment and its cross-layer boundary.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Accumulator Definition",
"source": "eip.md",
"summary": "The new consensus-critical hash uses \"raw bytes serialization\" and concatenation, but composite execution-request encoding and complete domain/framing rules are not defined."
},
{
"locator": "Execution Layer > Modified Containers > Header",
"source": "eip.md",
"summary": "A header field is required without a concrete field-order or fork-aware encoding rule."
},
{
"locator": "Execution Engine API",
"source": "eip.md",
"summary": "A new method is required without a method name, version, schemas, error cases, or historical-availability semantics."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The exact bytes feeding a newly observable consensus-critical hash are not fully determined for constructible composite-list cases. Clients must agree on those bytes and revise baselines when the draft is completed; the missing API and header details add localized coordination needs but are not scored again as separate unspecified mechanisms.",
"score": 3,
"uncertainty_note": "No implementation, devnet, discussion, or amendment evidence is available or permitted; the score is based solely on the draft text's unresolved consensus-visible encoding.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter > requires",
"source": "eip.md",
"summary": "EIP-8237 explicitly requires EIP-7732."
},
{
"locator": "Abstract",
"source": "eip.md",
"summary": "It replaces the EIP-7732 ExecutionPayloadBid execution_requests_root design and adds the cross-layer commitment to the payload."
},
{
"locator": "Execution Layer > Modified Containers > ExecutionPayload",
"source": "eip.md",
"summary": "The new hash is added alongside EIP-7843 slot_number, which is also an explicit input to compute_partial_header_hash."
},
{
"locator": "Specification > Execution Layer",
"source": "supporting/eip-7732.md",
"summary": "EIP-7732 itself specified no EL changes, so EIP-8237 supplies a new EL surface tied to its payload separation design."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7732,
7843
],
"rationale": "EIP-8237 depends on and modifies the EIP-7732 payload-separation commitment and directly consumes the EIP-7843 slot_number in the new EL commitment; these require coordinated testing but remain limited to the commitment and payload/header boundary.",
"score": 2,
"uncertainty_note": "The package names no originating EIP for withdrawals or the ExecutionRequests type, so those package-grounded mechanism interactions are not assigned invented EIP numbers.",
"under_specified": false,
"unidentified_interactions": [
"Execution-requests mechanism whose values become inputs to the new EL-validated commitment.",
"Withdrawals mechanism whose list becomes an input to the new EL-validated commitment."
]
}
],
"eip": 8237,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8237:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The function is described as an accumulator that chains across blocks, while its explicit inputs contain parent_hash rather than a separately named prior accumulator; the intended indirect chain depends on parent_hash covering the prior header field.",
"\"Raw bytes serialization\" is precise for uint64 but incomplete for the composite list contents and does not state explicit framing or domain separation.",
"The required Engine API method is described only by purpose, not as a testable wire contract."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "192437824e82227014f4675cee81b4b24bcca7027406c321e6142838f22542af",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8237.md",
"git_blob_sha": "c0dc69ed3d9b7bdd009e1cfd9bea62fa48bc2f0c",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8237.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8237.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8237.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8237.yaml",
"sha256": "de10beacc3e51c772f03dda234b0d9a2d17766adffdd41f0d51d9d0f166b0afd"
},
"supporting_documents": [
"supporting/eip-7732.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 29,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of draft EIP-8237 at the sealed Hegota PFI snapshot. The scored surface adds a consensus-critical partial_header_hash to ExecutionPayload and the execution block header, requires independent EL computation and validation of that value, and requires a new Engine API lookup method; consensus-layer range-sync behavior is treated only as boundary context.",
"tier": "high",
"title": "Independent CL/EL Sync",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"encoding_changes_rlp_ssz",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 31,
"minimum": 25
},
"present": true,
"summary": "Material details are absent for the consensus-critical raw serialization of composite withdrawal/request data, the execution-header field ordering and fork-aware encoding, and the new Engine API method's concrete protocol and historical lookup semantics. These are recorded chiefly under the unspecified-behavior anchor rather than multiplied across unrelated rows.",
"unresolved_questions": [
"What is the complete, unambiguous byte encoding and framing for withdrawals and each ExecutionRequests component in the SHA256 preimage?",
"Where exactly is partial_header_hash placed in the execution header encoding, and how is the parent-to-activation-block boundary handled?",
"What are the new Engine API method's name, version, request/response types, error semantics, and historical data-availability requirements?",
"Is divergence localization a caller-driven sequence of per-block lookups, and what history must an EL retain to support it?"
]
}
},
"hegota:8250:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"The published total 20 differs from the cell sum 22; the cells are the primary record, so the cell sum is used."
],
"published_tier": "medium",
"published_total": 20,
"recomputed_tier": "medium",
"recomputed_total": 22,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Two additions to existing accounting: the nonce encodings priced as EIP-7623 calldata (intrinsic and floor), and the per-first-use keyed-nonce surcharge charged from the approving frame's gas. Measured impact on existing tests is small (eleven executions, all boundary cases).",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Measured: 11 of 541 EIP-8141 suite executions flip — exact-gas boundaries and the introspection probe — and all were updated fork-correctly rather than parked.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The transaction interface gains two fields (`nonceKeys`, `nonceSeq`) replacing the frame transaction's `nonce` across the loader and serialization paths.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The transaction model gains the keyed fields with legacy-aliasing defaults, the frame gas calculators gain an extra-charged-bytes term, and a nonce-encoding fork accessor keeps sibling tests fork-correct — reusable within the suite.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Structural key-set rules (bounds, strict ordering, the zero-key aliasing exception), the sequence-exhaustion bound, first-use versus reuse surcharges and their out-of-gas boundary, revert-immune consumption, and atomic-batch unroll persistence — several mechanisms, and the approval-atomicity surface needs an elevated case count.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "`NONCE_MANAGER` is a stateful system contract: the protocol writes its keyed slots while ordinary calls revert.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "`TXPARAM` changes semantics (`0x01` becomes the keyed sequence) and gains four indices, but the opcode ships in the same fork as its EIP-8141 substrate — no deployed behavior is modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The frame transaction payload changes (`nonce` becomes `nonce_keys`, `nonce_seq`), but the type never exists on mainnet without this EIP — the tooling cost is scored under the interface and framework rows.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Stateful validity becomes per-key sequence equality against protocol storage, plus structural key-set rules at decode time; existing validity tests need limited updates.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "`NONCE_MANAGER` is initialized at the activation boundary (code, nonce, storage rules for pre-existing accounts) — a state modification at the fork block.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Replay protection is redesigned: disjoint-key independence, nullifier-style spent-once atomicity through payment approval, and consumption that must survive reverts and batch rollback — application-facing security guarantees that need targeted adversarial tests.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The specification is unusually complete (ordered approval steps, journaling rules, overflow halts); the prototype needed no interpretation disputes, and the open mempool-concurrency amendment is non-consensus.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "A delta on EIP-8141 (full coordination with the frames suite, measured), the EIP-7623/7976 floor family (nonce bytes priced as calldata), and EIP-7825 (gas-cap boundaries flip) — coordinated but mechanical.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8250,
"fork": "hegota",
"id": "hegota:8250:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8250.yaml",
"sha256": "bbe6ad03936bd4c737cfaf7bd342bbee44eed18a62257d3081f86ddc2208b45f"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "b0886dc0692db6e860765458d757d36ca5156a8e",
"content_sha256": "09679e4e48025ecc7ecd2e2e86691591cef47feacec24fea7b20f31507cc47c3",
"git_blob_sha": "3dd95224ea1f64cc1740bc98d182c26bf6fe60f6",
"immutable_url": "https://github.com/ethspecs/pm/blob/b0886dc0692db6e860765458d757d36ca5156a8e/complexity_assessments/EIPs/EIP-8250.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8250.md",
"pull_request": {
"draft": true,
"number": 111,
"title": "Add EIP-8250 complexity assessment",
"updated_at": "2026-08-18T08:32:19Z",
"url": "https://github.com/ethspecs/pm/pull/111"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 22,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "medium",
"title": "Keyed Nonces for Frame Transactions",
"under_specification": null
},
"hegota:8250:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Nonce consumption, steps 1-5",
"source": "eip.md",
"summary": "A payment-scoped APPROVE reads every keyed slot, counts first uses, charges KEYED_NONCE_FIRST_USE_GAS per zero-valued slot, and makes the charge part of frame and transaction gas accounting."
},
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "RLP encodings of nonce_keys and nonce_seq are newly included in both standard gas-limit and calldata-token calculations inherited from the frame transaction."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This introduces a dynamic first-use execution-gas mechanism inside APPROVE and integrates it with existing frame gas-used, settlement, and unpaid-gas-refund calculations. Existing frame-transaction gas cases are affected, matching score 3.",
"score": 3,
"uncertainty_note": "The surcharge and its accounting destinations are explicit; the sealed package contains no executable test inventory with which to count affected vectors.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Nonce consumption, paragraphs before and after steps 1-5",
"source": "eip.md",
"summary": "APPROVE first performs all pre-existing exceptional checks and ordinary costs, then keyed reads, then the conditional surcharge, then nonce writes, and only then commits the remaining approval effects atomically."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The state-access and gas-charge order of one opcode, APPROVE, changes. Testing is multiplicative across legacy versus keyed domains, first versus subsequent use, key count, payment scope, gas boundaries, and success/revert/atomic-batch paths, but the rubric's score-1 anchor is the exact structural match because only one opcode's ordering changes.",
"score": 1,
"uncertainty_note": "The intra-APPROVE order is explicit. The separate question of recording these protocol accesses in a block-level access list is not specified and is recorded under under-specification rather than changing this score.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "The delta states that no payload field other than the nonce replacement changes and adds nonce bytes only to standard/calldata-token accounting."
},
{
"locator": "Specification > Frame Transaction > Blob handling",
"source": "supporting/eip-8141.md",
"summary": "The base frame transaction already defines optional blob handling and blob-gas accounting."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "EIP-8250 neither adds nor modifies a blob-gas mechanism; its added bytes are execution-calldata priced. Score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Nonce consumption, final two paragraphs",
"source": "eip.md",
"summary": "The first-use surcharge is deducted from the executing frame's gas and keyed writes are protocol bookkeeping explicitly excluded from ordinary SSTORE pricing."
},
{
"locator": "Specification > Frame Transaction > Gas Accounting",
"source": "supporting/eip-8141.md",
"summary": "The base proposal separately defines state gas as the durable-state dimension with per-frame state budgets and specific charge points."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Although keyed slots create persistent state, EIP-8250 prices that growth with execution gas and does not adjust StateGasCosts, a STATE_BYTES rate, a state-gas charge site, or the block state-gas budget. Under this anchor's narrow definition, the score is 0.",
"score": 0,
"uncertainty_note": "This score follows the rubric's distinction between a state-growth surcharge paid in execution gas and the named state-gas mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Nonce consumption",
"source": "eip.md",
"summary": "The surcharge is included in EIP-8141's existing unpaid-gas refund calculation; no refund counter, eligibility rule, or refund amount is introduced for keyed nonces."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Referencing an existing settlement refund does not create a new EVM gas refund mechanism. Score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload; Stateful validity; Nonce consumption; Transaction introspection",
"source": "eip.md",
"summary": "The delta changes every post-fork frame transaction's nonce fields and signing payload, replaces its stateful nonce check and payment-approval nonce effect, and changes transaction introspection."
},
{
"locator": "Specification > Activation; Mempool",
"source": "eip.md",
"summary": "It also invalidates pre-fork frame transactions at the boundary and changes frame-transaction identity, dependencies, and revalidation."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing EIP-8141 tests require broad reworking across encoding, signature hashes, validity, gas boundaries, APPROVE/revert behavior, activation, and mempool behavior. These are diverse test categories, so score 3 applies.",
"score": 3,
"uncertainty_note": "The breadth follows directly from the delta, though the package includes no pre-existing test catalog for a mechanical case count.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "The first post-fork block must initialize NONCE_MANAGER with fixed code, at least nonce 1, empty storage, and balance-preservation rules before any transaction executes."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of fork-transition and post-activation state assertions gains a mechanical invariant for the NONCE_MANAGER account even when a test does not send a keyed-nonce transaction. The text does not establish that literally every test vector and every pre-fork vector must be re-derived, so score 2 rather than 3 applies.",
"score": 2,
"uncertainty_note": "The package does not describe how the test corpus supplies or asserts fork-initialized system state.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "The existing nonce input is replaced by the two distinct transaction fields nonce_keys and nonce_seq."
},
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "NONCE_MANAGER initialization occurs only when the current timestamp is post-fork and the parent timestamp is pre-fork, before transaction execution, and must be reversible across reorgs."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool must represent multiple new transaction fields and must support a fork-boundary-only pre-transaction state transition whose selection depends on both current and parent timestamps. This matches the score-3 combination of multiple fields and a new mechanism.",
"score": 3,
"uncertainty_note": "No transition-tool interface is included, so the exact field names and whether existing environment inputs already expose parent timestamp are not package-evidenced.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction payload; Nonce state",
"source": "eip.md",
"summary": "Tests must construct a bounded list of nonce keys plus a sequence and inspect protocol-managed keyed storage derived from sender and key."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing transaction and state fixtures need minor extension for the two fields, key-list constraints, and derived storage slots. The package does not demonstrate a need for a new permanent expectation or modifier abstraction, so score 1 applies.",
"score": 1,
"uncertainty_note": "The sealed package contains no test-framework design or tests; the score is limited to the minimum extension directly required by the specified data model.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Nonce state; Transaction introspection",
"source": "eip.md",
"summary": "The proposal uses keccak256 for storage-slot derivation and for a canonical hash of the nonce-key set, while retaining EIP-8141's signature procedure after substituting the nonce fields."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Use of an existing hash function and a changed signed message does not introduce or modify a cryptographic mechanism. Score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload, decoder rejection list",
"source": "eip.md",
"summary": "Boundaries include one to sixteen keys, canonical integer encodings, 256- and 64-bit limits, strict ordering, and the singleton-only zero key."
},
{
"locator": "Specification > Stateful validity; Nonce consumption; Activation",
"source": "eip.md",
"summary": "Additional boundaries include overlapping sets in block order, sequence exhaustion, first-use gas thresholds, legacy nonce changes during a transaction, rollback persistence, and the exact fork boundary."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms require an elevated combinatorial set of cases, especially up to sixteen shared-sequence keys crossed with first/subsequent use, overlap, gas-left thresholds, approval scopes, and rollback outcomes. Score 3 applies.",
"score": 3,
"uncertainty_note": "The boundaries are explicit; the exact case count depends on the test framework, which is outside the sealed package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "At the fork, FRAME_TX_TYPE changes RLP schema and gains list shape, canonicality, range, strict-ordering, and zero-key decoding checks."
},
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Decoders must select the old or new frame payload rules based on the activation timestamp."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Sync validation must implement multiple related RLP checks and a timestamp-dependent schema for an existing transaction type. This is more than one simple validation but remains a localized payload change, matching score 2.",
"score": 2,
"uncertainty_note": "The payload's fee-field layout conflicts with sealed EIP-8141 and is recorded as under-specification; either resolution still requires these keyed-field validation mechanisms.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete execution-layer delta)",
"source": "eip.md",
"summary": "The proposal specifies transaction, state transition, introspection, activation, and mempool behavior but no Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "No Engine API surface is present in the allowlisted proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants; Nonce state; Activation",
"source": "eip.md",
"summary": "A new NONCE_MANAGER account with reverting runtime code is installed at activation, and its persistent storage holds every non-zero keyed nonce sequence."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "This is one new stateful system contract, which is the explicit score-2 anchor.",
"score": 2,
"uncertainty_note": "Its address remains subject to network-specific emptiness checks before fork-configuration finalization, but the contract's stateful role is clear.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "The only system-contract action defined is initialization of the new NONCE_MANAGER; the proposal defines no change to existing system-contract code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Modifying EIP-8141 opcode and transaction behavior is not a modification of a pre-existing system contract. Score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Nonce consumption; Transaction introspection",
"source": "eip.md",
"summary": "The proposal changes the existing EIP-8141 APPROVE and TXPARAM instructions but assigns no new opcode number."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Nonce consumption",
"source": "eip.md",
"summary": "Payment-scoped APPROVE replaces the legacy account-nonce increment with keyed reads, conditional gas, keyed or legacy consumption, and approval effects that survive later rollback."
},
{
"locator": "Specification > Transaction introspection",
"source": "eip.md",
"summary": "TXPARAM(0x01) changes meaning to nonce_seq and additional parameter results are assigned."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least APPROVE and TXPARAM have behavioral, non-gas result changes, so the rubric's binary score 3 applies.",
"score": 3,
"uncertainty_note": "TXPARAM(0x0C) conflicts with its sealed EIP-8141 assignment; that localized conflict is recorded under under-specification but does not change the fact that opcode behavior is modified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants; Nonce state",
"source": "eip.md",
"summary": "NONCE_MANAGER is specified as a stateful system contract with runtime bytecode and storage, not as a precompile; no precompile is added."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete execution-layer delta)",
"source": "eip.md",
"summary": "No precompile behavior or gas schedule is modified anywhere in the proposal."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified, so score 0 applies.",
"score": 0,
"uncertainty_note": "No precompile surface is present in the allowlisted proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "FRAME_TX_TYPE replaces one RLP nonce field with consecutive nonce_keys and nonce_seq fields, requires canonical integer encodings, and changes the signing payload accordingly."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "An encoding change at transaction level is introduced, which maps directly to the rubric's binary score 3.",
"score": 3,
"uncertainty_note": "The exact surrounding fee-field nesting conflicts with sealed EIP-8141; both readings still constitute the scored transaction-level encoding change.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Transaction payload",
"source": "eip.md",
"summary": "The proposal is explicitly a delta that changes the existing EIP-8141 FRAME_TX_TYPE payload rather than assigning another transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload, decoder rejection list",
"source": "eip.md",
"summary": "Static validity gains schema, non-empty/bounded-list, canonicality, integer-range, strict-order, and zero-key constraints."
},
{
"locator": "Specification > Stateful validity",
"source": "eip.md",
"summary": "Stateful validity replaces one sender-nonce equality with equality against every selected key's current sequence at the transaction's actual position in block execution order."
},
{
"locator": "Specification > Transaction payload, gas pricing definitions",
"source": "eip.md",
"summary": "The new nonce encodings also change intrinsic/floor quantities used by transaction gas-limit validity."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing frame-transaction validity tests require extensive redesign for list encoding, multiple state domains, overlap and ordering, sequence exhaustion, and changed intrinsic calculations. Score 3 applies.",
"score": 3,
"uncertainty_note": "The validity rules themselves are detailed; only the surrounding payload layout conflict is unresolved separately.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification (complete execution-layer delta)",
"source": "eip.md",
"summary": "Keyed nonce state is committed through the existing execution stateRoot; no new block or header field is defined."
},
{
"locator": "Rationale, paragraph beginning 'Keyed-nonce state lives'",
"source": "eip.md",
"summary": "The system-contract storage choice is expressly intended to retain the existing execution state commitment."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "No material uncertainty in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Before transactions in the first post-fork block, clients create or modify NONCE_MANAGER code and nonce while preserving balance according to pre-existing-account conditions, and must undo this on reorg."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The activation block performs an irregular state/account transition, which is the rubric's binary score-3 condition.",
"score": 3,
"uncertainty_note": "FORK_TIMESTAMP and the final network-safe address are configuration TBDs, but the activation mechanism and transition cases are specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Stateful validity; Nonce consumption; Mempool",
"source": "eip.md",
"summary": "A transaction can require reads and writes for up to sixteen derived storage slots, and pending transactions must be indexed and revalidated when any selected sequence changes."
},
{
"locator": "Security Considerations, paragraph beginning 'Each consumed'",
"source": "eip.md",
"summary": "Every first-used sender/key pair occupies a persistent slot; growth is bounded by a 20,000-gas surcharge per new key."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "State-database work, multi-key validity, persistent growth, and mempool dependency tracking interact with existing execution and propagation paths, so isolated microbenchmarks do not cover the full impact. The sixteen-key bound and gas-based growth bound keep the impact limited, matching score 2 rather than 3.",
"score": 2,
"uncertainty_note": "The package supplies bounds but no benchmark targets, client data structures, or measured workloads.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The proposal identifies authorization binding of the full key set, CREATE-address sensitivity to the legacy nonce, persistence through rollback, cancellation/replacement changes, permanent state growth, and sequence exhaustion."
},
{
"locator": "Specification > Nonce consumption; Mempool",
"source": "eip.md",
"summary": "Replay state is committed during payment approval outside frame and atomic-batch journals, while the public mempool gains multi-key dependency and revalidation rules."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Replay protection and authorization are critical invariants, and the new mechanism crosses transaction validity, opcode approval, state journaling, contract creation semantics, fee payment, and mempool replacement. These multiple critical interactions require extensive review and fuzzing, so score 3 applies.",
"score": 3,
"uncertainty_note": "The proposal documents the risk classes, but the sealed package contains no implementations, tests, or review outcomes, as required by the source restrictions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload, displayed post-replacement payload",
"source": "eip.md",
"summary": "EIP-8250 displays fee values as three top-level payload fields while stating that only nonce is replaced and no other field changes."
},
{
"locator": "Specification > Frame Transaction > Payload Encoding",
"source": "supporting/eip-8141.md",
"summary": "The sealed base payload instead contains one nested fees list, so the exact post-fork RLP schema cannot satisfy both texts."
},
{
"locator": "Specification > Transaction introspection, TXPARAM table",
"source": "eip.md",
"summary": "EIP-8250 assigns 0x0C to the pre-state legacy sender nonce and calls its new indices non-conflicting."
},
{
"locator": "Specification > Introspection > TXPARAM Instruction (0xb0), table",
"source": "supporting/eip-8141.md",
"summary": "The sealed base already assigns 0x0C to current-frame state_gas_left, creating a second direct result conflict."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need agreement on the localized payload layout and TXPARAM(0x0C) result before authoritative vectors can be baselined. These are concrete, localized conflicts rather than a newly observable class of previously unspecified behavior, matching score 2.",
"score": 2,
"uncertainty_note": "The conflicts are explicit in the sealed sources. The package contains no admissible amendment or precedence rule that resolves them.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter 'requires'; Specification > Transaction payload; Nonce consumption",
"source": "eip.md",
"summary": "EIP-8250 requires 7623 and 8141, changes EIP-8141 payload, validity, APPROVE, introspection, and mempool behavior, and integrates nonce bytes with calldata-floor accounting."
},
{
"locator": "Specification > Nonce consumption, final paragraph",
"source": "eip.md",
"summary": "Protocol keyed reads/writes are expressly excluded from EIP-2929 access warming and EIP-2200 SSTORE pricing."
},
{
"locator": "Specification",
"source": "supporting/eip-2200.md",
"summary": "EIP-2200 defines the ordinary SSTORE charging and refund machinery from which keyed protocol writes are excluded."
},
{
"locator": "Specification > Storage read changes; SSTORE changes",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 defines transaction access sets and warm/cold storage behavior that keyed protocol accesses must not affect."
},
{
"locator": "Specification",
"source": "supporting/eip-7623.md",
"summary": "EIP-7623 defines calldata-token floor pricing with which the new nonce encodings interact through the EIP-8141 accounting delta."
},
{
"locator": "Specification > APPROVE Instruction; Introspection; Mempool",
"source": "supporting/eip-8141.md",
"summary": "EIP-8141 supplies the existing mechanisms that EIP-8250 directly replaces or extends."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2200,
2929,
7623,
8141
],
"rationale": "Coordinated cases are required for EIPs 8141, 7623, 2929, and 2200: the frame-transaction delta is deep, calldata-floor behavior must include the new bytes, and ordinary SSTORE and warm/cold mechanisms must remain unaffected by protocol bookkeeping. Four interacting EIPs do not trigger the rubric's first +1 increment, which begins after six total interactions; the strong multi-EIP dependency therefore scores 3.",
"score": 3,
"uncertainty_note": "The EIP-4337 comparison is rationale-only and does not establish a protocol dependency requiring coordinated execution-layer vectors, so it is not counted.",
"under_specified": false,
"unidentified_interactions": [
"Legacy account-nonce changes caused by account deployment and CREATE or CREATE2 inside a frame interact with legacy-domain consumption and TXPARAM(0x0C); the package gives no EIP number for this interaction."
]
}
],
"eip": 8250,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8250:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"FORK_TIMESTAMP is TBD and NONCE_MANAGER must be reselected if code or storage exists on any intended activation network; these are deployment parameters, not additional scored behavior gaps.",
"The public mempool keeps one pending frame transaction per sender even though transaction identity becomes (sender, nonce_keys, nonce_seq); the text presents multi-pending keyed-aware policy only as a future possibility."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "23249d7f78b3f697b64719c6ac6b7deb605030a31f454368b61196732469e3cb",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8250.md",
"git_blob_sha": "b824d302c2c03881791bf4645cba15c578cbfa6d",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8250.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8250.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8250.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8250.yaml",
"sha256": "861523738ec73e2126c150716f8545c922efa25912bcf99105d632de130e192e"
},
"supporting_documents": [
"supporting/eip-2200.md",
"supporting/eip-2929.md",
"supporting/eip-4337.md",
"supporting/eip-7623.md",
"supporting/eip-8141.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 42,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the sealed Draft EIP-8250 delta to EIP-8141. The assessed surface comprises the frame-transaction payload and signature hash, keyed-nonce validity and protocol-managed state, payment-scoped APPROVE gas and persistence semantics, transaction introspection, fork activation, and execution-client mempool dependency handling.",
"tier": "high",
"title": "Keyed Nonces for Frame Transactions",
"under_specification": {
"affected_criteria": [
"state_access_ordering_within_opcode_execution",
"transition_tool_interface_changes",
"block_syncing_changes",
"modified_opcodes",
"encoding_changes_rlp_ssz",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 42,
"minimum": 42
},
"present": true,
"summary": "The sealed EIP-8250 delta conflicts with its sealed EIP-8141 base in two consensus-visible places: the surrounding RLP fee-field layout and the result assigned to TXPARAM(0x0C). The delta also does not state whether its protocol-managed keyed reads and writes are recordable in the rubric's block-level access list; it only excludes them from EIP-2929 transaction access sets. These issues require a package-authoritative resolution, but either resolution leaves the scored mechanisms and High tier unchanged.",
"unresolved_questions": [
"Does the post-fork RLP payload retain EIP-8141's nested fees list, or use the three top-level fee fields displayed by EIP-8250?",
"Does TXPARAM(0x0C) return the pre-state legacy sender nonce or the current frame's state_gas_left, and what index retains the displaced value?",
"Are protocol-managed NONCE_MANAGER reads and writes included in any block-level access-list recording, independently of their explicit exclusion from EIP-2929 warming sets?"
]
}
},
"hegota:8253:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The activation transition consumes no gas and produces no transaction."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The EIP introduces no EVM gas-accounting rule; its nonce writes are an irregular, gas-free activation transition.",
"score": 0,
"uncertainty_note": "No gas-accounting ambiguity is visible in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The nonce writes occur at block start, before system calls and transactions."
},
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Future creation is rejected by the existing EIP-684 nonce precondition."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's internal state-access or gas-charge ordering changes. The state is mutated before opcode execution, after which existing creation logic observes the new nonce.",
"score": 0,
"uncertainty_note": "The proposal specifies block-level ordering, not an opcode-level ordering change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The only prescribed mutation is setting targeted account nonces to 1 without gas."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal does not mention or modify blob gas accounting.",
"score": 0,
"uncertainty_note": "No blob-gas surface is present in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The nonce transition explicitly consumes no gas."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The EIP neither adjusts a state-gas rate nor adds a state-gas charging site; the one-time state write is unmetered.",
"score": 0,
"uncertainty_note": "No state-gas budget, rate, reservoir, or spill rule is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The transition consumes no gas and produces no transaction or receipt."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No refund behavior is present in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "At activation, every listed account acquires nonce 1 while its other fields remain unchanged."
},
{
"locator": "Test Cases > Nonce bump; Non-targeted accounts unaffected",
"source": "eip.md",
"summary": "Tests must distinguish listed accounts from accounts outside the fixed list."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A narrow subset of existing fork-transition or creation-collision vectors that include a targeted account must update expected post-state behavior; unrelated tests and non-targeted accounts are unchanged.",
"score": 1,
"uncertainty_note": "The package contains no inventory of pre-existing tests, so the affected subset is inferred only from the narrowly scoped state predicate and fixed list.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases > Nonce bump",
"source": "eip.md",
"summary": "A targeted account must have nonce 1 after the fork while balance, code, and storage remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing tests that cross activation with a targeted account gain a narrow additional post-state invariant for the nonce and preservation of other fields.",
"score": 1,
"uncertainty_note": "The sealed evidence does not establish whether any non-EIP-specific test already contains a targeted account at activation.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The mutation applies only at the start of the designated fork block."
},
{
"locator": "Specification > Mainnet account list",
"source": "eip.md",
"summary": "The transition consumes a fixed chain-specific account list with 28 Mainnet entries."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Transition tooling needs a fork-activation-only mechanism, including the applicable chain list, rather than merely processing ordinary per-block input. This is a new interface-level activation mechanism, even though the EIP does not prescribe multiple fields.",
"score": 2,
"uncertainty_note": "The EIP does not define the transition-tool interface or how the account list is supplied, so an implementation might encode activation and the list in fork configuration rather than add an explicit input field.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The change is an activation-block-only transition before normal block execution."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Coverage spans nonce preservation, creation collision, calls, non-targeted accounts, and conditional BAL output."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing state and call expectations appear sufficient, but the framework needs a minor activation-context extension or helper to apply and inspect a one-time pre-execution transition.",
"score": 1,
"uncertainty_note": "The package provides no test-framework description, so it is unclear whether an existing fork-transition primitive already suffices without extension.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Mainnet account list",
"source": "eip.md",
"summary": "Keccak hashes accompany addresses and slots as verification information, not as a new cryptographic mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No new or modified cryptographic mechanism is introduced.",
"score": 0,
"uncertainty_note": "The proposal uses existing hashes only as list provenance and BAL-related data.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Required cases distinguish targeted and non-targeted account shapes, CREATE and CREATE2 collision, CALL behavior, and conditional BAL correctness."
},
{
"locator": "Specification > State transition; Interaction with EIP-7928",
"source": "eip.md",
"summary": "The transition has an exact activation boundary before system calls and transactions, plus index-0 BAL ordering when EIP-7928 is active."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundaries require coverage: activation versus adjacent blocks, listed versus unlisted accounts, the three account-shape exclusions, CREATE/CREATE2/CALL outcomes, EIP-7928 active versus inactive, and ordering before four named pre-execution system-call mechanisms. The fixed 28-account batch and conditional BAL path elevate the case count.",
"score": 3,
"uncertainty_note": "Exact per-account vectors cannot be enumerated because the referenced list is not included in the package, but the multiplicity of specified boundaries is clear.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The proposal mutates account nonce state and introduces no block RLP rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-RLP validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "State-root changes alone do not constitute the block-RLP mechanism scored by this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Interaction with EIP-7928",
"source": "eip.md",
"summary": "The EIP specifies BAL content when EIP-7928 is active but no new Engine API field or method."
},
{
"locator": "Specification > Engine API",
"source": "supporting/eip-7928.md",
"summary": "EIP-7928 already defines the payload field and Engine API methods that carry BALs."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "EIP-8253 changes the contents of an existing conditional BAL mechanism; it adds no Engine API field, endpoint, or communication mechanism of its own.",
"score": 0,
"uncertainty_note": "No EIP-8253-specific Engine API change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The change directly updates listed accounts before any existing system-contract calls."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "The targeted accounts are state-transition inputs, not a newly deployed system contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The nonce bumps are ordered before, but do not modify, the system calls introduced by EIPs 2935, 4788, 7002, and 7251."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal establishes sequencing relative to existing system contracts but changes neither their code nor their state or behavior.",
"score": 0,
"uncertainty_note": "The package does not identify any targeted address as a system-contract address; no indirect behavioral effect is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal relies on existing CREATE and CREATE2 behavior under EIP-684."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "No opcode addition appears in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "CREATE and CREATE2 observe the newly nonzero nonce and reject under the unchanged EIP-684 rule."
},
{
"locator": "Specification",
"source": "supporting/eip-684.md",
"summary": "EIP-684 already rejects creation at a destination with a nonzero nonce."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The EIP changes pre-execution state, not opcode semantics. Different creation outcomes for targeted addresses follow from the existing nonce-collision rule.",
"score": 0,
"uncertainty_note": "The proposal explicitly frames EIP-684 as the unchanged rejection mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The only new operation is a direct account-nonce state transition."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "No precompile surface is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The transition changes only listed account nonces and preserves their other fields."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "No precompile interaction is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Interaction with EIP-7928",
"source": "eip.md",
"summary": "EIP-8253 populates existing AccountChanges and NonceChange fields when EIP-7928 is active."
},
{
"locator": "Specification > RLP Data Structures",
"source": "supporting/eip-7928.md",
"summary": "The BAL RLP structure already includes nonce_changes."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal supplies values to an already specified BAL encoding and does not change transaction, block, or interface encoding.",
"score": 0,
"uncertainty_note": "Updating an account's nonce changes encoded state data, not an encoding format covered by this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The transition produces no transaction, receipt, or log."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "The state mutation is explicitly outside transaction processing.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition; Test Cases > CREATE reverts",
"source": "eip.md",
"summary": "The activation changes state before transactions; a later creation attempt reverts during execution under EIP-684."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic-gas calculation changes. A creation transaction can execute and revert because of existing collision semantics, which is not a new transaction-validity mechanism.",
"score": 0,
"uncertainty_note": "The proposal specifies execution outcome, not transaction admission validity.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "The nonce bumps affect the post-state root but no new block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced.",
"score": 0,
"uncertainty_note": "A changed value for the existing state root is not a new header field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "At the start of the designated fork block, each listed account's nonce must be set to 1."
},
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal explicitly characterizes the change as an irregular state transition."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The EIP performs a consensus state modification at the activation block, which directly meets the binary score-3 anchor.",
"score": 3,
"uncertainty_note": "The exact designated fork identifier is not supplied, but the activation-only state mutation is unambiguous.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Irregular state transition vs. runtime check; Nonce bump vs. storage clear",
"source": "eip.md",
"summary": "The design replaces a perpetual runtime storage check with 28 one-time scalar nonce writes, avoiding the 129 storage-entry clearing alternative."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The bounded activation batch and state-root update warrant isolated validation, but the work is fixed and does not alter ongoing execution performance.",
"score": 1,
"uncertainty_note": "The missing account asset prevents package-local measurement, though the EIP states the batch size is 28.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations > List correctness",
"source": "eip.md",
"summary": "Both omissions and spurious entries are consensus-relevant, and multi-client plus external list verification is required before scheduling."
},
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "The nonce bump protects stored state from future CREATE or CREATE2 collision by relying on EIP-684 rejection."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The new mechanism touches a limited set of state accounts but changes a security-relevant creation invariant. A wrong list can either leave collision risk or mutate an unintended account, requiring targeted multi-client review and verification.",
"score": 2,
"uncertainty_note": "The referenced list and methodology are absent, so their reproducibility and validation complexity cannot be assessed from the package.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Mainnet account list",
"source": "eip.md",
"summary": "The normative 28-entry target set and its construction are delegated to referenced assets not present in the package."
},
{
"locator": "Specification > Application to non-Mainnet chains; Reference Implementation",
"source": "eip.md",
"summary": "Other chains must generate their own lists, while the published list must be byte-equal to a methodology output at the fork-block state."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The transition rule is clear once an account list is fixed, but the sealed proposal evidence does not determine the exact accounts or the complete construction procedure. That localized input must be agreed and baselined before exact state-root and per-account vectors can be written.",
"score": 2,
"uncertainty_note": "This scores the package-visible specification gap, not an assumption about implementations, devnets, or discussion status, which are prohibited evidence.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Abstract; Motivation",
"source": "eip.md",
"summary": "EIP-8253 depends on EIPs 161 and 684 and is offered as an alternative to the runtime storage check of EIP-7610."
},
{
"locator": "Specification > State transition",
"source": "eip.md",
"summary": "Activation must precede pre-execution system calls introduced by EIPs 2935, 4788, 7002, and 7251."
},
{
"locator": "Specification > Interaction with EIP-7928",
"source": "eip.md",
"summary": "When EIP-7928 is active, every nonce bump must be encoded at access index 0 and replay must reproduce the post-state root."
}
],
"exceptional_score_justification": "A score above 3 is justified by eight package-explicit interactions, each with its own dependency, alternative-rule, activation-order, or BAL-coordination surface; under the rubric, EIPs four through six add one point beyond the score-3 multiple-EIP anchor.",
"id": "cross_eip_interactions",
"interacting_eips": [
161,
684,
2935,
4788,
7002,
7251,
7610,
7928
],
"rationale": "Eight numbered EIPs require coordinated consideration: 161 and 684 define the historical and active creation invariants; 7610 is the alternative collision rule; 2935, 4788, 7002, and 7251 create four separate activation-order cases; and 7928 adds a conditional BAL and replay case. This exceeds the first three interacting EIPs by five, yielding one uncapped +1 increment.",
"score": 4,
"uncertainty_note": "EIP-7523 is cited only as design precedent and is excluded because the proposal does not depend on, modify, or conflict with it.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8253,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8253:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The EIP names a designated fork block but does not provide its block number, timestamp, or an explicit transition-tool activation signal.",
"The EIP requires byte equality with the methodology output while the methodology and target-list assets are outside the sealed evidence set."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "4a26740655d1843335233a41dee7bbad2fef148346a46494bb2abae5919c5264",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8253.md",
"git_blob_sha": "1c8c02121c7fdb8fc53a06491de530fd7b76ac60",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8253.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8253.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8253.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8253.yaml",
"sha256": "4f7d3be5b622ac0962d1dbe6d3b5b527aa8e5d3e5d131c80794567c28fc81c15"
},
"supporting_documents": [
"supporting/eip-161.md",
"supporting/eip-684.md",
"supporting/eip-2935.md",
"supporting/eip-4788.md",
"supporting/eip-7002.md",
"supporting/eip-7251.md",
"supporting/eip-7523.md",
"supporting/eip-7610.md",
"supporting/eip-7928.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 20,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Draft execution-layer EIP-8253 in the sealed Hegotá snapshot. It specifies a one-time fork-activation transition that sets the nonce to 1 for a fixed Mainnet list of 28 zero-nonce, empty-code, non-empty-storage accounts, preserves all other account fields, runs before system calls and transactions, consumes no gas, and conditionally records the changes in an EIP-7928 block-level access list. The referenced account-list and methodology assets are not present in the assessment package.",
"tier": "medium",
"title": "Bump nonce of zero-nonce storage accounts",
"under_specification": {
"affected_criteria": [
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 21,
"minimum": 19
},
"present": true,
"summary": "The fixed Mainnet account list and the methodology that normatively constructs and verifies it are referenced but absent from the sealed assessment sources. Consequently, the exact transition inputs, byte-equality check, and reproducible list verification cannot be assessed or turned into exact vectors package-locally.",
"unresolved_questions": [
"What are the exact 28 address entries and hashes in the normative Mainnet list?",
"What complete procedure and fork-state inputs determine byte-equality for that list?",
"How are non-Mainnet lists finalized and independently verified for their activation state?"
]
}
},
"hegota:8272:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [
"15 blank score cells are interpreted as zero only because the published total equals the sum of every nonblank cell."
],
"published_tier": "medium",
"published_total": 14,
"recomputed_tier": "medium",
"recomputed_total": 14,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Minimal changes to EIP-8141 gas rules, adding new rules to the data pricing of the roots included, and cost of the hashing required to get the entry hash/storage key.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The frame transaction now conditionally accesses the storage of `RECENT_ROOT_ADDRESS` before execution of any of the frames.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "New helpers required to construct the `recent_root_references` embedded in the transactions. Also to register them in the `RECENT_ROOT_ADDRESS` contract.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Elevated case counts. Window at both ends (`current_slot - slot` of 0, 1, 8191, 8192), index wraparound at `slot mod 8192`, the 16-reference (per-tx) cap, zero references (intrinsic gas 0, not the address cost), duplicate references (charged independently but deduplicated in access sets), last-write-wins within a slot. Calls to `RECENT_ROOT_ADDRESS`: writes rejected in static context and via `DELEGATECALL`/`CALLCODE`, calldata exactly 64 bytes with zero value. `RECENTROOTREFLOAD` opcode: `field > 2` and `index >= len` halts, with multiple combinations of different `recent_root_references` in each tx",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "A single new stateful system contract at `0x…8272`. One write operation (64-byte calldata, zero value), but no read operation is exposed. Lower score because it involves no novel testing methodologies.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "One simple new opcode: `RECENTROOTREFLOAD` (0xB5), constant 3 gas, two stack pops, one push, three valid `field` values. It reads only the signed envelope, never contract storage.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Although `recent_root_references` is inserted into the EIP-8141 transaction type, it's not an optional field and it's easy to add to the encoder.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Multiple new tx rejection schemes: window `1 <= current_slot - slot <= 8191`, and `RECENT_ROOT_ADDRESS[storage_key] == entry_hash`. One invalid reference invalidates the transaction and the containing block. Can be independently tested to EIP-8141 other rejection mechanisms.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": "explicit_zero_by_published_arithmetic",
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "EIP states that an irregular state transition is required, but this is complex and potentially it is not necessary: We probably can simply deploy using the well known system contract deployment methods used for previous forks. Worth pushing back on the deployment method as it is probably an outdated specification requirement.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Requires testing worst-case block filled with transactions consuming block limit using `MAX_RECENT_ROOT_REFERENCES`.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "No major underspecification identified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "**EIP-8141**: this EIP is a delta against it, altering its payload and signature hash; untestable without it. **EIP-7623**: calldata floor is affected. **EIP-7928**: testing is required to ensure that the BAL items are added at the appropriate spot. **EIP-7702**: a delegated EOA may be a source address.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8272,
"fork": "hegota",
"id": "hegota:8272:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8272.yaml",
"sha256": "ae44c7312e99739bcd16493d118b892732d0073551c36bde688cbd3058415e43"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "d54b36561f34f0f870426e6fd826a510035014c8",
"content_sha256": "9164c943cf8ab14ea92ca26794a2c54b07bfa38fd6ada199b48544c6576a1c4c",
"git_blob_sha": "81aae13863d54958fdf424a4d4f92ed97b92d7aa",
"immutable_url": "https://github.com/ethspecs/pm/blob/d54b36561f34f0f870426e6fd826a510035014c8/complexity_assessments/EIPs/EIP-8272.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8272.md",
"pull_request": {
"draft": false,
"number": 133,
"title": "Add EIP-8272 complexity assessment",
"updated_at": "2026-08-25T12:17:26Z",
"url": "https://github.com/ethspecs/pm/pull/133"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 14,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "medium",
"title": "Recent Roots for Frame Transactions",
"under_specification": null
},
"hegota:8272:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas accounting",
"source": "eip.md",
"summary": "Defines per-reference intrinsic gas and adds reference calldata cost, intrinsic gas, and calldata tokens to EIP-8141 gas quantities."
},
{
"locator": "Specification > Frame Transaction > Gas Accounting",
"source": "supporting/eip-8141.md",
"summary": "Defines the existing standard gas limit, calldata floor, max gas, and settlement quantities that EIP-8272 changes."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "A new per-reference intrinsic charge is introduced and is wired into the existing frame-transaction standard limit, calldata floor, token count, maximum gas, and settlement path. This changes existing gas vectors and therefore meets anchor 3.",
"score": 3,
"uncertainty_note": "RECENT_ROOT_CODE is TBD, so exact gas vectors for calls to the system contract cannot yet be baselined; the score follows from the fully specified transaction-level accounting changes.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Reference validity",
"source": "eip.md",
"summary": "Places recent-root storage checks after the nonce check and before frame execution, outside opcode execution."
},
{
"locator": "Specification > TXPARAM and RECENTROOTREFLOAD",
"source": "eip.md",
"summary": "States that RECENTROOTREFLOAD reads only signed-envelope fields and does not read recent-root contract storage."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal adds a transaction-level pre-execution state check, but it does not move a state access or gas charge within any opcode. The new opcode is envelope introspection without state access, so this anchor is zero.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor in the sealed text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "Inserts recent_root_references after blob_versioned_hashes and states that no other payload field is changed."
},
{
"locator": "Specification > Gas accounting",
"source": "eip.md",
"summary": "Changes execution/calldata gas quantities while leaving EIP-8141 max_gas, gas_used, and fee settlement definitions in place."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The blob hash field is only an insertion point in the payload. No blob gas price, limit, usage, or fee-accounting rule is changed.",
"score": 0,
"uncertainty_note": "No blob-gas behavior is left open by the proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Recent root contract",
"source": "eip.md",
"summary": "Specifies ordinary storage writes and says successful calls follow normal EVM execution and gas accounting."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Describes persistent state growth and leaves any future registration or first-write surcharge to a future version."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Recent-root writes use the already applicable state-write charging rules. This EIP neither adjusts a state-gas rate nor creates a new state-gas site, budget, reservoir, or spill mechanism.",
"score": 0,
"uncertainty_note": "The system-contract bytecode is TBD, but the normative text explicitly assigns its writes normal accounting rather than a new state-gas mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas accounting",
"source": "eip.md",
"summary": "Defines additive intrinsic and calldata charges without defining a refund counter change or refund condition."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "No material uncertainty for this anchor in the sealed text.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "Inserts a mandatory field into the existing frame-transaction payload and changes the canonical signing payload."
},
{
"locator": "Specification > Gas accounting",
"source": "eip.md",
"summary": "Changes gas quantities even when the new reference list is represented in an otherwise existing frame-transaction test."
},
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Changes the accepted payload and signature domain across the activation boundary and requires pre-fork transactions to be regenerated."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing frame-transaction encoding, signing, intrinsic-gas, fork-boundary, validation, and mempool cases require reworking. The affected cases span multiple diverse test categories rather than a contrived subset, meeting anchor 3.",
"score": 3,
"uncertainty_note": "The package contains no test inventory; breadth is derived from the proposal's normative changes to every post-activation frame-transaction envelope.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Requires the activation block to create or initialize RECENT_ROOT_ADDRESS before executing any transaction."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing activation-boundary state-transition cases gain a narrow new state invariant for the initialized recent-root account even when their transaction logic is unrelated. The invariant is confined to fork-boundary cases, so anchor 1 applies rather than a broad mechanical assertion.",
"score": 1,
"uncertainty_note": "The package does not describe how test vectors expose implicit activation state, so the score is limited to the clearly required narrow invariant.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Current slot",
"source": "eip.md",
"summary": "Requires clients to consume the existing EIP-7843 slotNumber field for block validation."
},
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Defines activation from block timestamp without specifying a new transition-tool input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The proposal changes encoded transaction data and consumes a prerequisite's slotNumber, but it does not specify any new transition-tool interface field or mechanism.",
"score": 0,
"uncertainty_note": "Transition-tool implementation details are absent from the package; no interface change may be inferred beyond the normative EIP text.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "Adds a bounded list of structured source_id, slot, and root tuples to an existing transaction envelope."
},
{
"locator": "Specification > TXPARAM and RECENTROOTREFLOAD",
"source": "eip.md",
"summary": "Adds transaction introspection surfaces with indexed field access and exceptional-halt cases."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing frame-transaction construction and expectation helpers need minor extension for the new tuple list and introspection results. The package does not establish a need for a new permanent framework-level abstraction.",
"score": 1,
"uncertainty_note": "The sealed sources specify protocol behavior, not the test framework's current primitive set, so only the minimal required extension is scored.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Root sources; Entry and storage keys",
"source": "eip.md",
"summary": "Defines domain-separated Keccak-256 derivations for source identifiers, committed entries, and storage keys."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Treats roots as opaque and assigns application proof binding outside the execution-layer consensus mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The protocol introduces new domain-separated hash constructions, but uses a single well-known existing Keccak-256 primitive. Application proof systems are not part of the execution-layer change, so anchor 1 applies.",
"score": 1,
"uncertainty_note": "Application-specific commitments are intentionally unspecified and are not counted as protocol cryptography.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Static validity; Reference validity",
"source": "eip.md",
"summary": "Defines list-length, tuple-shape, byte-length, uint64, slot-window, pre-state, duplicate, and invalid-block boundaries."
},
{
"locator": "Specification > Recent root contract",
"source": "eip.md",
"summary": "Defines exact calldata/value/static/delegated-call failure cases, modulo indexing, repeated writes, and last-write-wins behavior."
},
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Adds timestamp-boundary, pre-existing-account, and reorg-across-fork cases."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The feature combines multiple elevated test matrices: zero through sixteen references, uint64 and RLP limits, current/future/old slot boundaries, 8192-entry modulo wraparound, same-slot overwrite order, duplicates, warm-set deduplication, call modes, competing blocks, reorgs, and activation. At least the slot-window/ring-buffer and activation matrices require an elevated number of cases, meeting anchor 3.",
"score": 3,
"uncertainty_note": "Exact system-contract bytecode may add gas-boundary cases, but the specified cases already independently satisfy anchor 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload; Static validity",
"source": "eip.md",
"summary": "Limits the new RLP schema and decoder rejection rules to the existing frame transaction payload."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Blocks can become invalid through transaction reference checks, but the EIP introduces no block-RLP validation mechanism. Transaction RLP changes are scored under encoding and transaction validity instead.",
"score": 0,
"uncertainty_note": "No block-RLP change is specified in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Current slot",
"source": "eip.md",
"summary": "Consumes slotNumber from EIP-7843 and forbids deriving the slot from the timestamp."
},
{
"locator": "Specification > RPC changes > Engine API changes",
"source": "supporting/eip-7843.md",
"summary": "Assigns the slotNumber Engine API objects and methods to EIP-7843."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "EIP-8272 depends on an Engine API field introduced by EIP-7843 but adds no field, endpoint, or communication mechanism of its own. The dependency is captured under cross-EIP interactions.",
"score": 0,
"uncertainty_note": "No EIP-8272-specific Engine API delta is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root contract",
"source": "eip.md",
"summary": "Defines a contract at RECENT_ROOT_ADDRESS that accepts writes and stores entry hashes in persistent storage."
},
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Requires clients to create or initialize the account with code, nonce, and storage conditions at activation."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "One new stateful system contract is introduced. A single stateful system contract maps directly to anchor 2.",
"score": 2,
"uncertainty_note": "RECENT_ROOT_CODE is TBD, preventing exact code-level tests, but statefulness and the activation transition are unambiguous.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Installs the new recent-root contract only where the selected address has empty code and empty storage; no existing system contract is named."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The activation handling creates or installs the new EIP-8272 system contract. It does not directly or indirectly modify a pre-existing system contract.",
"score": 0,
"uncertainty_note": "No pre-existing system-contract dependency is identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > TXPARAM and RECENTROOTREFLOAD",
"source": "eip.md",
"summary": "Adds RECENTROOTREFLOAD at 0xB5 with two stack inputs, indexed structured envelope access, three selectable fields, and exceptional-halt bounds."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "Exactly one opcode is added, but it accesses a variable transaction data portion and has indexed/field bounds rather than being a no-data constant operation. It is therefore a single complex opcode under anchor 2.",
"score": 2,
"uncertainty_note": "The opcode has constant gas, but its data access makes it complex by the rubric definition.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > TXPARAM and RECENTROOTREFLOAD",
"source": "eip.md",
"summary": "Adds TXPARAM_RECENT_ROOT_REFERENCE_COUNT at index 0x0F to the existing EIP-8141 TXPARAM instruction."
},
{
"locator": "Specification > Introspection > TXPARAM Instruction",
"source": "supporting/eip-8141.md",
"summary": "Defines the pre-existing TXPARAM parameter mapping and exceptional behavior for undefined indices."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Adding a previously undefined successful TXPARAM index modifies the result behavior of an existing opcode, which maps to the rubric's binary score 3.",
"score": 3,
"uncertainty_note": "No gas change to TXPARAM is counted; the score is solely for its modified result behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants; Recent root contract; TXPARAM and RECENTROOTREFLOAD",
"source": "eip.md",
"summary": "Enumerates a system-contract address, contract behavior, and opcode changes, with no precompile addition."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced.",
"score": 0,
"uncertainty_note": "RECENT_ROOT_ADDRESS is expressly a system contract, not a precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root contract; TXPARAM and RECENTROOTREFLOAD",
"source": "eip.md",
"summary": "Defines the execution additions entirely as a system contract, transaction checks, and opcodes."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "No precompile is named by the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "Inserts recent_root_references into the RLP frame-transaction payload and canonical signing payload, with a new nested tuple encoding."
},
{
"locator": "Specification > Static validity",
"source": "eip.md",
"summary": "Adds decoder rejection rules for the new RLP list and element encodings."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The RLP encoding of an existing transaction type and its signing payload are changed, which maps to the rubric's binary score 3.",
"score": 3,
"uncertainty_note": "The position, shape, and canonical integer requirements are explicitly specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "Applies the new field to the pre-existing EIP-8141 FRAME_TX_TYPE payload and states that the frame layout is otherwise unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "EIP-8272 modifies FRAME_TX_TYPE; it does not allocate or introduce another transaction type.",
"score": 0,
"uncertainty_note": "No new transaction type identifier is defined.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Static validity",
"source": "eip.md",
"summary": "Adds structural decoder validity for the new field, tuple shape, lengths, canonical uint64 slots, and maximum count."
},
{
"locator": "Specification > Reference validity",
"source": "eip.md",
"summary": "Adds state-dependent, current-slot-dependent checks against transaction pre-state that invalidate the transaction and containing block on failure."
},
{
"locator": "Specification > Gas accounting",
"source": "eip.md",
"summary": "Modifies intrinsic gas and calldata-floor quantities used by frame transaction validity and settlement."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Frame-transaction validity gains both a redesigned RLP schema and a new bounded but stateful pre-execution validation phase tied to current slot, transaction pre-state, accessed sets, and intrinsic gas. Testing requires extensive structural, state, ordering, fork, and invalid-block coverage, meeting anchor 3.",
"score": 3,
"uncertainty_note": "RECENT_ROOT_CODE prevents final call-level vectors but does not reduce the breadth of the specified transaction validity changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Current slot",
"source": "eip.md",
"summary": "Requires the slotNumber field supplied by EIP-7843 rather than defining a new header field."
},
{
"locator": "Specification > RPC changes > Header extension",
"source": "supporting/eip-7843.md",
"summary": "Attributes the slotNumber header extension to EIP-7843."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "EIP-8272 consumes a prerequisite's header field and adds none of its own.",
"score": 0,
"uncertainty_note": "The dependency is scored under cross-EIP interactions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Requires a one-time parent-state transition before the first post-fork transaction to create or update RECENT_ROOT_ADDRESS, including nonce and code, with reorg undo/apply handling."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The activation block performs an irregular account state/code/nonce transition. The rubric assigns score 3 whenever state or internal variables are modified at activation.",
"score": 3,
"uncertainty_note": "FORK_TIMESTAMP and RECENT_ROOT_CODE are TBD, so the mechanism is clear but its concrete activation configuration and installed bytes are not final.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Reference validity; Bounded validation work",
"source": "eip.md",
"summary": "Adds up to sixteen pre-execution storage checks with two Keccak computations per reference and explicitly bounds the validation work."
},
{
"locator": "Specification > Public mempool handling",
"source": "eip.md",
"summary": "Requires indexing by reference and expiry plus rechecks on head change, slot advance, and relevant reorgs."
},
{
"locator": "Rationale > Implicit source creation; Security Considerations",
"source": "eip.md",
"summary": "Bounds each source's rolling storage but permits aggregate storage to grow linearly with newly written source identifiers."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Per-transaction work is bounded, yet realistic validation cannot be assessed solely in isolation because storage reads, warm sets, head-dependent validity, slot-driven expiry, reorg invalidation, transaction-pool indices, and unbounded aggregate source creation interact with existing critical paths. Those complex interactions meet anchor 3.",
"score": 3,
"uncertainty_note": "RECENT_ROOT_CODE and workload distributions are unspecified, so the exact performance magnitude remains uncertain even though validation is capped at sixteen references per transaction.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Reference validity; Public mempool handling",
"source": "eip.md",
"summary": "Makes transaction and block validity depend on recent system-contract state and requires recheck/eviction across head, slot, and reorg changes."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Identifies application tuple binding, last-write-wins roots, publication availability, cross-chain domain binding, and persistent-state-growth responsibilities."
},
{
"locator": "Specification > Transaction payload",
"source": "eip.md",
"summary": "Commits references through the canonical frame-transaction signature hash and forbids frames from changing the reference set."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism changes security assumptions across signed transaction data, state-backed validity, system-contract writes, application proof binding, mempool admission/eviction, reorg handling, and block validity. These are multiple critical components requiring extensive adversarial review and fuzzing, meeting anchor 3 on the execution-layer surface alone.",
"score": 3,
"uncertainty_note": "Application proof systems remain outside execution consensus, and exact system-contract bytecode is TBD; neither removes the specified critical execution-layer interactions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants",
"source": "eip.md",
"summary": "Sets FORK_TIMESTAMP and RECENT_ROOT_CODE to TBD."
},
{
"locator": "Specification > Recent root contract; Activation",
"source": "eip.md",
"summary": "Gives abstract call and initialization behavior but requires installation of the still-unspecified RECENT_ROOT_CODE under consensus rules."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot baseline exact system-contract execution, gas-boundary, code installation, or code-hash cases until the runtime code and fork value are agreed. The gap is material but localized to activation and the system contract realization, matching anchor 2 rather than a newly exposed broad class of previously unobservable behavior.",
"score": 2,
"uncertainty_note": "The abstract storage and reference-check algorithms are detailed; the open consensus artifact is principally the concrete contract code and activation value.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Specification > Current slot; Transaction payload; Gas accounting",
"source": "eip.md",
"summary": "Declares dependencies on EIPs 7623, 7843, and 8141, consuming slotNumber and modifying the EIP-8141 payload, signature, and EIP-7623-derived gas quantities."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Defines how an EIP-7702-delegated EOA may act as a root source while not modifying other EIP-7702 transaction behavior."
},
{
"locator": "Specification > Frame Transaction; Introspection",
"source": "supporting/eip-8141.md",
"summary": "Supplies the transaction type, gas model, TXPARAM opcode, and opcode space that EIP-8272 directly extends."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7623,
7702,
7843,
8141
],
"rationale": "Coordinated testing is required with EIP-8141's envelope, signing, gas, and introspection; EIP-7843's slot/header/Engine value; EIP-7623-derived calldata accounting; and EIP-7702 delegated source behavior. These are strong interdependencies across four identified EIPs. The base anchor is 3, and four interactions do not trigger the rubric's additional-EIP increment.",
"score": 3,
"uncertainty_note": "Only direct interactions grounded in the allowlisted package are counted; transitive dependencies of EIP-8141 are not inferred as additional axes.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8272,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8272:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"RECENT_ROOT_CODE is normative activation state but remains TBD even though the prose specifies its intended abstract behavior.",
"Transaction-pool current_slot and the near-expiry margin m are explicitly local policy, whereas block-validity current_slot comes from EIP-7843; tests must keep that policy/consensus boundary explicit."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "f9b4e2cadc2388453ad15937f9df66ad747eca22c660984e7b84fe0f1204c569",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8272.md",
"git_blob_sha": "1ff890ed8ce03be2cf25f7528c78733d35a3dfe3",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8272.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8272.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8272.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8272.yaml",
"sha256": "4bb84d6b442b367928a425deed421c8f9567106502ff239fbd33d70819e05067"
},
"supporting_documents": [
"supporting/eip-7623.md",
"supporting/eip-7702.md",
"supporting/eip-7843.md",
"supporting/eip-8141.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 39,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer-only assessment of the sealed Draft EIP-8272 delta to EIP-8141 frame transactions. The proposal adds declared recent-root references, state-backed pre-execution reference validation, a stateful recent-root system contract, intrinsic/calldata gas additions, transaction introspection, one new opcode, transaction-pool handling, and fork-boundary initialization. No consensus-layer complexity is scored; the execution layer consumes the EIP-7843 slotNumber value as specified in the package.",
"tier": "high",
"title": "Recent Roots for Frame Transactions",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"added_system_contracts",
"new_fork_activation_mechanism",
"performance_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 40,
"minimum": 35
},
"present": true,
"summary": "The draft fixes the abstract recent-root algorithms and transaction rules but leaves RECENT_ROOT_CODE and FORK_TIMESTAMP as TBD. Missing concrete code prevents authoritative call-path, code-hash, exact gas-boundary, and activation vectors; the timestamp is also needed to instantiate the fork boundary. This material gap is recorded once here and is not multiplied into unrelated anchors.",
"unresolved_questions": [
"What exact RECENT_ROOT_CODE byte sequence implements the specified direct call, calldata, value, static-context, DELEGATECALL, CALLCODE, storage, return-data, and revert behavior?",
"What exact execution-gas trace and boundary behavior follows from that concrete system-contract code under normal EVM accounting?",
"What FORK_TIMESTAMP is used to baseline the one-time state transition and reorg-across-activation cases?"
]
}
},
"hegota:8272:llm:r2:hegota-2026-09-16-90194cf-eip-8272-v2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root verifier frame",
"source": "eip.md",
"summary": "The frame consumes ordinary EVM gas, uses normal warm/cold access and EIP-8141 data pricing, and adds no special intrinsic gas, warming rule, or block-gas exemption."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal creates additional ordinary EVM work but does not introduce or update an EVM gas-accounting rule.",
"score": 0,
"uncertainty_note": "RECENT_ROOT_CODE is TBD, so exact gas-use vectors cannot yet be fixed, but the specified accounting mechanism remains the existing one.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Public mempool handling",
"source": "eip.md",
"summary": "Direct evaluation must reproduce EVM gas use and the same warm account and storage-key updates and rollbacks."
},
{
"locator": "Specification > Recent root verifier frame",
"source": "eip.md",
"summary": "Target access and storage reads follow normal warm and cold access rules."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's internal state-access or gas-charge order changes. The equivalence rule for an optional optimized evaluation preserves, rather than reorders, ordinary EVM access effects.",
"score": 0,
"uncertainty_note": "The missing canonical bytecode obscures its concrete trace, not the stated ordering rule for any opcode.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root verifier frame",
"source": "eip.md",
"summary": "The proposal reuses ordinary frame execution and adds no special gas accounting or block-gas exemption."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP does not change the EIP-8141 transaction payload and does not modify other transaction types."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas field, price, limit, accounting path, or existing blob test rule is changed.",
"score": 0,
"uncertainty_note": "No blob-gas ambiguity is visible in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Implicit source creation",
"source": "eip.md",
"summary": "Writes creating storage entries pay the ordinary state-growth cost."
},
{
"locator": "Specification > Recent root contract",
"source": "eip.md",
"summary": "All calls use ordinary EVM execution and gas accounting."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Recent-root writes consume state, but the proposal neither changes a state gas rate or budget nor introduces a new state-gas charging mechanism.",
"score": 0,
"uncertainty_note": "Exact code gas is unresolved, but the specification mandates existing state-growth charging.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root contract > Write operation",
"source": "eip.md",
"summary": "A successful write performs an ordinary storage assignment and returns no data or logs."
},
{
"locator": "Specification > Recent root contract",
"source": "eip.md",
"summary": "All calls use ordinary EVM execution and gas accounting."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal defines no new refund trigger, counter, or settlement rule.",
"score": 0,
"uncertainty_note": "No refund-related under-specification is identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Each of EIP-8141's four recognized validation-prefix shapes must be tested in four protocol-verifier configurations, while reversed and duplicate protocol verifiers must be rejected."
},
{
"locator": "Specification > Public mempool handling",
"source": "eip.md",
"summary": "Prefix matching must skip optional expiry and recent-root verifier frames, changing how the existing four EIP-8141 prefix shapes are classified."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable set of existing EIP-8141 public-mempool prefix tests must be reworked into a verifier-position matrix, but the impact is confined to that specialized frame-validation category rather than diverse execution tests.",
"score": 2,
"uncertainty_note": "The package does not quantify the pre-existing EIP-8141 test inventory, so the absolute number of affected vectors is unknown.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "The first active block must initialize the fixed account against parent state and is invalid unless the chosen address has empty code and storage."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Fork-transition tests not otherwise about EIP-8272 gain a narrow expected state condition for the installed account. Other changes mainly rework EIP-8141 tests rather than adding a universal assertion to every test.",
"score": 1,
"uncertainty_note": "How broadly the activation-account expectation is asserted by the test corpus is not specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Current slot",
"source": "eip.md",
"summary": "Execution clients obtain current_slot from EIP-7843's existing slotNumber field."
},
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The feature requires no change to the FrameTx envelope."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The proposal consumes an already-defined slotNumber and existing fork activation context; it specifies no new transition-tool input or output field.",
"score": 0,
"uncertainty_note": "The package does not describe a transition-tool binding, but no interface addition is required by the EIP text.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Tests need recent-root tuple construction, slot-age boundaries, verifier frame variants, activation transitions, direct-evaluation equivalence, and reorganization-driven eviction."
},
{
"locator": "Specification > Mempool > Revalidation",
"source": "supporting/eip-8141.md",
"summary": "EIP-8141 already defines dependency-based re-simulation and eviction after canonical-head changes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing FrameTx and mempool/revalidation concepts cover the behavior, but minor reusable helpers are needed for 72-byte tuples, recent-root frames, slot movement, and indexed dependency changes.",
"score": 1,
"uncertainty_note": "No test-framework implementation is package evidence, so whether helpers are merely extended or newly introduced cannot be confirmed.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Root sources; Specification > Entry and storage keys",
"source": "eip.md",
"summary": "Source identifiers, entry hashes, and storage keys use domain-separated keccak256 over fixed-length encodings."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Reuse of the existing keccak256 hash does not introduce or modify a cryptographic mechanism for purposes of this anchor.",
"score": 0,
"uncertainty_note": "Application-specific proofs and privacy commitments are explicitly outside the protocol's opaque bytes32-root semantics.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Required cases span one versus sixteen tuples, duplicates, malformed lengths, current/future slots, ages 8191 and 8192, exact gas boundaries, four prefix shapes and verifier orders, activation states, and reorgs."
},
{
"locator": "Specification > Validation operation",
"source": "eip.md",
"summary": "Validation combines strict age tests, modulo-8192 ring indexing, tuple hashing, storage equality, and all-tuples-must-pass behavior."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms compose, and the prefix-shape, tuple, gas, age, activation, and reorganization axes create an elevated case matrix.",
"score": 3,
"uncertainty_note": "RECENT_ROOT_CODE prevents final bytecode-level boundary vectors, but the specified boundary surface is already clear.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal changes neither the FrameTx envelope nor other transaction types."
},
{
"locator": "Specification > Current slot",
"source": "eip.md",
"summary": "current_slot is read from EIP-7843's existing header field."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Activation affects executed state, but EIP-8272 introduces no block RLP validation mechanism, which is the scope of this anchor.",
"score": 0,
"uncertainty_note": "No EIP-8272 block-encoding change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Current slot",
"source": "eip.md",
"summary": "EIP-8272 consumes slotNumber supplied under EIP-7843 and does not define a new Engine API field or endpoint."
},
{
"locator": "Specification > RPC changes > Engine API changes",
"source": "supporting/eip-7843.md",
"summary": "EIP-7843 is the package source that defines the slotNumber-bearing payload and attributes objects and associated Engine API methods."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The necessary Engine API surface belongs to the prerequisite; this proposal adds no further Engine API communication mechanism.",
"score": 0,
"uncertainty_note": "No incremental Engine API ambiguity is identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root contract",
"source": "eip.md",
"summary": "A fixed RECENT_ROOT_ADDRESS exposes write and validation operations and stores per-source ring-buffer entries."
},
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Clients install RECENT_ROOT_CODE at activation with nonce and storage conditions."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Exactly one protocol-installed system contract is added, and it is stateful because ordinary callers can write persistent recent-root entries.",
"score": 2,
"uncertainty_note": "The contract's canonical runtime bytes are TBD, but its stateful role and activation are explicit.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "The designated address must be absent or have empty code and storage before clients install the new recent-root code."
},
{
"locator": "Specification > Recent root verifier frame",
"source": "eip.md",
"summary": "The new frame targets RECENT_ROOT_ADDRESS."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Installing a new contract into an absent or empty account does not modify a pre-existing system contract, and no existing system contract is otherwise changed.",
"score": 0,
"uncertainty_note": "An already-existing empty account may have its nonce updated, but it is not a pre-existing system contract under the rubric's distinction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal explicitly requires no new opcode."
},
{
"locator": "Specification > Application introspection",
"source": "eip.md",
"summary": "Applications reuse EIP-8141 FRAMEPARAM, FRAMEDATALOAD, and FRAMEDATACOPY."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "No opcode-addition ambiguity is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root verifier frame",
"source": "eip.md",
"summary": "Target access, storage reads, and data pricing use existing rules."
},
{
"locator": "Specification > Public mempool handling",
"source": "eip.md",
"summary": "SLOTNUM and constrained SLOAD are newly permitted only by public-mempool trace policy while the canonical top-level frame executes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The proposal changes which existing opcodes a mempool policy admits in this narrowly recognized frame, but changes no existing opcode's execution result or semantics.",
"score": 0,
"uncertainty_note": "The distinction is between mempool-policy permission and opcode behavior; only the latter is scored here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Recent root contract; Specification > Activation",
"source": "eip.md",
"summary": "The feature is deployed as EVM runtime code at an account with nonce and storage, not as a precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "The missing runtime bytes do not change the specified account model.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Recent root contract",
"source": "eip.md",
"summary": "The design uses a newly installed ordinary contract and existing frame execution without mentioning any precompile behavior or gas change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "No precompile interaction requiring scoring is package-grounded.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Rationale > Canonical frame instead of an envelope field",
"source": "eip.md",
"summary": "The design reuses EIP-8141 transaction encoding and puts fixed-length tuples in existing frame data rather than adding an envelope field."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The EIP-8141 transaction payload and signature hash do not change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The tuple is an application-level encoding inside an existing data field; transaction, block, receipt, and interface RLP/SSZ encodings are unchanged.",
"score": 0,
"uncertainty_note": "No interface-level encoding change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "The feature uses EIP-8141 FrameTx without changing its envelope and does not modify other transaction types."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "No transaction-type ambiguity is present.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Recent root verifier frame",
"source": "eip.md",
"summary": "A failed verifier uses EIP-8141's existing rule that a reverting or exceptional VERIFY frame invalidates the transaction."
},
{
"locator": "Rationale > Fixed early position; Test Cases",
"source": "eip.md",
"summary": "The fixed position affects public-mempool eligibility, not block validity, and mempool rejection alone does not make a transaction invalid in a block."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "EIP-8272 adds a recognized mempool-policy species and contract predicates, but it does not alter FrameTx static validity rules or intrinsic gas; block validity continues to follow existing EIP-8141 VERIFY execution semantics.",
"score": 0,
"uncertainty_note": "Some harnesses may group public-mempool admission under transaction validation, but the EIP explicitly separates that policy from block validity, which controls this score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Current slot",
"source": "eip.md",
"summary": "The proposal reads the EIP-7843 slotNumber field."
},
{
"locator": "Specification > RPC changes > Header extension",
"source": "supporting/eip-7843.md",
"summary": "EIP-7843, rather than EIP-8272, defines the slotNumber header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No additional block or header field is introduced by this proposal.",
"score": 0,
"uncertainty_note": "The prerequisite field is fully attributable to EIP-7843.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Activation",
"source": "eip.md",
"summary": "Before transactions in the first active block, clients create or update RECENT_ROOT_ADDRESS, conditionally preserve balance and nonce, reject a nonempty-code/storage parent, run initialization only once, and undo or reapply it across activation reorgs."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The proposal mandates an irregular first-active-block state transition at a fixed address, directly satisfying the rubric's score-3 activation anchor.",
"score": 3,
"uncertainty_note": "RECENT_ROOT_CODE is still TBD, so the exact code value written by this otherwise explicit transition is unresolved.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Public mempool handling",
"source": "eip.md",
"summary": "Nodes must index storage and expiry dependencies, update them atomically on replacement, and selectively recheck transactions after slot changes, reorgs, storage changes, or code and activation changes."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Reorganizations or synchronized expiry may evict many transactions sharing a popular root, while dependency indexing is intended to avoid scanning unrelated transactions."
},
{
"locator": "Specification > Entry and storage keys",
"source": "eip.md",
"summary": "Persistent storage can grow by up to 8192 keys for each written source_id."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Although one validation call is bounded to sixteen tuples, end-to-end performance couples transaction-pool indexing, replacement, expiry, chain reorganization, direct-EVM equivalence, and unbounded numbers of root sources; that interaction cannot be fully benchmarked in isolation.",
"score": 3,
"uncertainty_note": "The package supplies bounds and mitigations but no workload or benchmark data, and canonical bytecode needed for exact per-frame measurements is TBD.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Public mempool handling",
"source": "eip.md",
"summary": "The proposal makes a narrow exception to shared-storage-read bans and requires exact code matching, bounded execution, dependency recording, atomic replacement, reorg-aware rechecks, and eviction."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The text identifies signature-binding requirements, last-write semantics, publication risk, cross-chain domain binding, persistent state growth, and mass eviction after reorg or expiry."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches critical state, EVM execution, account validation, and public transaction-pool invariants. Incorrect dependency tracking, optimized evaluation, reorg handling, or application binding can affect nodes and users, warranting extensive targeted and cross-component review and fuzzing.",
"score": 3,
"uncertainty_note": "The specified mitigations reduce exposure but do not eliminate the multi-component security review surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants",
"source": "eip.md",
"summary": "RECENT_ROOT_CODE is explicitly listed as TBD."
},
{
"locator": "Specification > Activation; Specification > Public mempool handling",
"source": "eip.md",
"summary": "Clients must install exactly RECENT_ROOT_CODE, compare runtime code against it for mempool admission, and make direct evaluation reproduce that code's exact gas use and warm-access effects."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The undefined canonical runtime bytes become consensus state at activation and determine exact execution gas and the mempool code-match gate. Clients cannot baseline activation state roots, code matching, or gas-equivalent execution until a previously nonexistent observable value is agreed.",
"score": 3,
"uncertainty_note": "Functional pseudocode is detailed, but it does not determine the canonical bytecode or its exact gas trace.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter requires; Specification",
"source": "eip.md",
"summary": "EIP-8272 requires 7843 and 8141, extends EIP-8141 frame and mempool semantics, sources current_slot from EIP-7843, and specifies EIP-7702 delegated-code storage-context behavior."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Testing explicitly composes EIP-8141 prefix shapes and gas limits with expiry and recent-root verifier frames, EIP-7843 slots, and delegated-code cases implied by the storage-context rule."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7702,
7843,
8141
],
"rationale": "There are three direct interacting EIPs: 8141 supplies the transaction, verifier, introspection, gas-budget, and mempool framework; 7843 supplies slotNumber and SLOTNUM; and 7702 affects delegated execution and storage context. Their coordinated behavior requires cross-EIP test coverage. With exactly three identified interactions, no uncapped bonus applies.",
"score": 3,
"uncertainty_note": "Transitive EIP-8141 dependencies are not counted because EIP-8272 does not directly modify them in the package evidence.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8272,
"evaluation_date": "2026-09-16",
"fork": "hegota",
"id": "hegota:8272:llm:r2:hegota-2026-09-16-90194cf-eip-8272-v2",
"mode": "prospective",
"notable_ambiguities": [
"RECENT_ROOT_CODE is undefined even though activation, public-mempool admission, and direct-evaluation equivalence all depend on its exact value.",
"The node-chosen near-expiry admission margin is deliberately local policy, so it affects interoperability expectations but not consensus scoring."
],
"provenance": {
"assessed_revision": {
"commit": "90194cfa32915fc8a4ba5b7eea783774c2182b7f",
"committed_at": "2026-09-16T00:38:19Z",
"content_sha256": "82419d7e5c094b03539e4c7d1da91f4a117cce7a95d147b8776f8e0c668471f1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8272.md",
"git_blob_sha": "274ce98c57ec285862f4d2ff48cd9f545c385f12",
"immutable_url": "https://github.com/ethereum/EIPs/blob/90194cfa32915fc8a4ba5b7eea783774c2182b7f/EIPS/eip-8272.md",
"information_cutoff_at": "2026-09-16T00:38:19Z",
"path": "EIPS/eip-8272.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8272.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/evaluations/hegota-2026-09-16-90194cf-eip-8272-v2/assessments/eip-8272.yaml",
"sha256": "7da45eca70de8bd281e94ef20f9f4bdd0a5e8aa7ba403b1d17d0cfdc01a18135"
},
"supporting_documents": [
"supporting/eip-7702.md",
"supporting/eip-7843.md",
"supporting/eip-8141.md"
]
},
"role": "reevaluation",
"rubric_revision": 2,
"score": 24,
"scored": true,
"snapshot_id": "hegota-2026-09-16-90194cf-eip-8272-v2",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of draft EIP-8272 at the sealed Hegotá snapshot. The proposal installs one stateful recent-root contract, defines canonical recent-root VERIFY frames for EIP-8141 frame transactions, extends public mempool admission and revalidation policy, and performs a first-active-block state transition. It reuses EIP-7843 slotNumber/SLOTNUM and existing EVM gas, state access, frame encoding, and transaction semantics.",
"tier": "high",
"title": "Recent Roots for Frame Transactions",
"under_specification": {
"affected_criteria": [
"added_system_contracts",
"performance_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 26,
"minimum": 23
},
"present": true,
"summary": "RECENT_ROOT_CODE is TBD. The proposal therefore lacks the exact code bytes that must be installed into consensus state and code-matched by mempool implementations, and it cannot yet fix bytecode-level gas, exceptional-halt, and optimized-evaluation equivalence vectors. This single gap is scored under unspecified behavior rather than being duplicated as independent penalties.",
"unresolved_questions": [
"What exact runtime bytes and code hash replace RECENT_ROOT_CODE?",
"What exact gas-use, exceptional-halt boundaries, and warm-access traces do those bytes establish for one through sixteen validation tuples and writes?",
"What bytecode-grounded reference vectors establish equivalence between EVM execution and optional direct evaluation?"
]
}
},
"hegota:8279:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 22,
"recomputed_tier": "medium",
"recomputed_total": 22,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "A new floor mechanism folded into `tx.gasUsed = max(execution_gas_used, floor_gas_used)`, extending the floor family that the eip7623/eip7976/eip7981 suites actively test. Measured: an EELS prototype flips 384 fixture executions across the eip7623/7976/2780/8037/7778/7934/7954 gas suites.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "One uniform new abort point sits before every recordable access, and its position had to be settled (an access that aborts on the floor check must not commit its bytes, or settlement exceeds the gas limit). Measured: no existing BAL vectors change at all, so the re-derivation that anchors a 3 never materializes.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The −32-byte meter refund for restored slots is deliberately distinct from the EIP-3529 gas refund and never touches the refund counter; a simple mechanism whose complexity is already scored under the gas-rule and ordering rows.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The floor rarely binds for typical transactions. Measured: 384 of ~61,800 fixture executions fail, but they collapse to 11 test functions, all in floor/gas-boundary suites — a considerable but contrived category, dominated (336) by the two calldata-floor `test_transaction_validity` functions whose exact-boundary transactions now abort.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The intrinsic/data-floor calculators already model the EIP-7623 floor family; they gain the per-authorization static seed term and byte-floor constants. Measured: the prototype suite needed only a small test-local scaffold helper beyond those extensions.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Nine runtime trigger rows x cold/warm x revert behavior x slot charge/refund toggling x the exact floor-binding boundary (`tx.gas == floor`) x the 7702 static seed — at least one mechanism with an elevated case count.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Validation becomes `tx.gas >= max(intrinsic, static_floor)` with the new per-auth BAL term; existing validity tests in the 8131/7981 family need limited updates.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The meter itself is cheap, but the EIP redefines worst-case block composition — the bloatnet/worst-case benchmark suites that target exactly these vectors must be re-derived.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A DoS-bound mechanism: an implementation error either reopens the 1.5 MB block-size bypass or aborts valid transactions; interacts with core gas metering; targeted review and fuzzing.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Two details are unwritten — the fit with EIP-8037's two gas dimensions, and whether an aborting access counts its bytes — but both have an obvious intended reading that held up in the prototype (the byte floor extends the calldata floor inside the existing settlement `max`; the aborted access never commits).",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Four coordination targets: EIP-7928 (the substrate being priced), the EIP-7623/7976/8131 calldata-floor chain (one mechanism), EIP-7702 (the static seed), and EIP-8037 (the gas-dimension split) — short of the six needed for an increment. EIP-2929 cold tracking and EIP-4758's trigger change are touchpoints, not coordinated test matrices.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8279,
"fork": "hegota",
"id": "hegota:8279:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8279.yaml",
"sha256": "ecdc047d8ba44b726ff1b462b75ed1685e2ad6073e3ba71f876e9c1d3192c0c0"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "9674b1fd589add3ab86713f95c4967de244c94e5",
"content_sha256": "a26230f73a4662f5baed3d53e904106fde38b00c09b1a7d1d8ae00ac7667241c",
"git_blob_sha": "7c3e42a49ad1a3f52742fa13e647909bd79b78ba",
"immutable_url": "https://github.com/ethspecs/pm/blob/9674b1fd589add3ab86713f95c4967de244c94e5/complexity_assessments/EIPs/EIP-8279.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8279.md",
"pull_request": {
"draft": true,
"number": 108,
"title": "Add EIP-8279 complexity assessment",
"updated_at": "2026-08-17T19:27:21Z",
"url": "https://github.com/ethspecs/pm/pull/108"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 22,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "medium",
"title": "Block Access List Byte Floor",
"under_specification": null
},
"hegota:8279:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Introduces per-transaction bal_data_bytes and floor_gas_used counters, extends the floor at runtime, and raises OutOfGasError when the new floor exceeds tx.gas."
},
{
"locator": "Specification > Final charge",
"source": "eip.md",
"summary": "Sets tx.gasUsed to the maximum of execution gas and the runtime floor."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "A new runtime gas-floor mechanism changes the existing EIP-7623/EIP-8131 charging shape, transaction OOG behavior, and final gas used across existing state-accessing operations, so existing gas tests are affected.",
"score": 3,
"uncertainty_note": "The SSTORE subtraction's revert handling is under-specified separately; it does not change that a broad new runtime gas mechanism exists.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Requires meter_bal_data before the matching BAL insertion or state mutation, with OOG aborting the operation before an unpaid BAL byte exists."
},
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Applies this placement rule to cold account and storage access, SSTORE, value-bearing CALL and SELFDESTRUCT, and CREATE/CREATE2 nonce, balance, and code changes."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The new consensus-visible floor check is inserted before BAL growth or state mutation for a whole class of state-accessing operations. Its OOG boundary therefore changes whether an access or change occurs across many opcodes.",
"score": 3,
"uncertainty_note": "Exact placement relative to every existing gas deduction is not enumerated, increasing implementation uncertainty without reducing the anchored breadth.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Static floor seed",
"source": "eip.md",
"summary": "Reuses EIP-8131 tx_floor as the static seed and adds BAL bytes per authorization; it specifies no blob-gas budget, price, or fee update."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Blob versioned hashes are already part of the inherited static transaction floor, but EIP-8279 makes no change to blob gas accounting itself.",
"score": 0,
"uncertainty_note": "No blob-gas mechanism is described in the proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Counter, not a reservation",
"source": "eip.md",
"summary": "States that execution gas accounting is untouched and the counters only determine the transaction floor and final retained gas."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal changes the ordinary transaction gas floor, not StateGasCosts, per-state-byte write rates, a block state-gas budget, or its spill path.",
"score": 0,
"uncertainty_note": "No state-gas construct defined by this anchor appears in the package.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Subtracts 32 bytes from bal_data_bytes when SSTORE returns a slot to its pre-transaction value and recomputes floor_gas_used."
},
{
"locator": "Rationale > Meter before; refund only when bytes leave the BAL",
"source": "eip.md",
"summary": "Defines the subtraction by EIP-7928's no-op-write rule and explicitly distinguishes it from the EIP-3529 SSTORE gas refund."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "This is a new state-dependent reduction of charged floor gas. It is narrower than the global refund counter but affects SSTORE/floor test outcomes and requires per-slot original/current-value tracking, satisfying score 2.",
"score": 2,
"uncertainty_note": "The package conflicts on whether a subtraction made inside a later-reverted frame is retained or undone; that material gap is recorded below.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Changes floor/OOG behavior for account and storage access, SSTORE state transitions, calls, selfdestructs, and contract creation/deployment."
},
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Requires cases for the calldata-plus-SLOAD boundary, cold SSTORE, net-zero and repeated writes, and reverted value-bearing calls."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing gas-boundary and state-transition tests across diverse opcode, revert, creation, delegation, and transaction-content categories require reworking for the runtime floor and its new OOG points.",
"score": 3,
"uncertainty_note": "The package provides no existing suite inventory, but the normative trigger table establishes broad impact independent of suite organization.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Declares both new counters internal and per-transaction, not signed, encoded, gossiped, or persisted."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The proposal changes expected execution and gas outcomes, which is counted as test rework above, but introduces no new persisted artifact that unrelated pre-existing tests must additionally assert.",
"score": 0,
"uncertainty_note": "The package does not describe harness-wide assertion policy; an internal counter alone does not establish a new assertion for every existing test.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Limits the added values to internal execution-environment counters and explicitly excludes signed, encoded, gossiped, and persisted fields."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No new transition-tool input or output field, and no interface mechanism, is specified.",
"score": 0,
"uncertainty_note": "Tool implementations must calculate the rule internally, but the package does not require an interface change.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases",
"source": "eip.md",
"summary": "Expresses tests as ordinary transactions and expected gas, metered-byte, BAL, and success/revert outcomes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The specified cases do not establish a need for a new expectation type, modifier, or permanent framework primitive.",
"score": 0,
"uncertainty_note": "The package contains no test-framework design, so only the absence of a demonstrated new primitive can be scored.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Constants",
"source": "eip.md",
"summary": "Defines only byte sizes and a per-byte gas rate for arithmetic metering."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The proposal introduces or modifies no cryptographic mechanism.",
"score": 0,
"uncertainty_note": "No cryptographic operation is in the proposal's scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Conditions metering on cold/warm access, zero/non-zero value, distinct accounts, CREATE collision/success/endowment, deployed-code length, and first/return/repeated SSTORE transitions."
},
{
"locator": "Security Considerations > Reverts",
"source": "eip.md",
"summary": "Gives different persistence rules for accessed keys and for balance, nonce, code, and storage-value changes across reverted frames."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple mechanisms have elevated boundary matrices: equality around tx.gas, static versus execution domination, access warmth, value and account identity, SSTORE history, nested reverts, creation paths, and code length.",
"score": 3,
"uncertainty_note": "One nested-revert/SSTORE boundary is unresolved and is recorded as under-specification; the remaining specified conditions already meet score 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Says the counters are not RLP-encoded, gossiped, or persisted and adds no block encoding rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism requiring client syncing is introduced.",
"score": 0,
"uncertainty_note": "EIP-7928 supplies the underlying BAL transport, but EIP-8279 does not modify that encoding surface.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Explicitly makes the two added counters internal and non-persisted; no Engine API field, version, endpoint, or communication mechanism is defined."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The proposal requires no Engine API change beyond its EIP-7928 baseline.",
"score": 0,
"uncertainty_note": "No Engine API section or new payload field appears in EIP-8279.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > System transactions and withdrawals",
"source": "eip.md",
"summary": "Refers only to existing EIP-2935, EIP-4788, EIP-7002, and EIP-7251 system contract calls and excludes them from the per-transaction floor."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No new system contract is introduced.",
"score": 0,
"uncertainty_note": "Existing system contracts are boundary cases, not additions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > System transactions and withdrawals",
"source": "eip.md",
"summary": "Leaves existing system-contract calls outside the new floor and continues to absorb their BAL bytes through EIP-7928's block-level buffer."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The exclusion does not change any existing system contract's code, state transition, or call behavior, directly or indirectly.",
"score": 0,
"uncertainty_note": "Their BAL-size interaction is counted under cross-EIP interactions.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Applies metering to an enumerated set of existing EVM operations."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "The metering hook is internal client logic, not an instruction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale > Counter, not a reservation",
"source": "eip.md",
"summary": "States that the mechanism does not deduct execution gas and that execution gas accounting is untouched; it only updates and checks the floor."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Existing operations acquire gas-floor hooks, but their non-gas results are not modified; this anchor explicitly excludes gas changes.",
"score": 0,
"uncertainty_note": "OOG reachability is scored under gas and ordering anchors.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Enumerates only existing opcode-triggered BAL contributions."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "Precompile creation is outside the specified mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Contains no precompile logic or precompile gas-schedule change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "Calls to accounts are covered generically; no precompile-specific change is stated.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Explicitly says neither counter is part of the signed transaction, RLP-encoded, gossiped, or persisted."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding changes are introduced.",
"score": 0,
"uncertainty_note": "The EIP-7928 BAL encoding is an inherited input, not changed here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Explicitly states that no new transaction field or type is introduced."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is added.",
"score": 0,
"uncertainty_note": "Existing transaction types receive the floor rule.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Static floor seed",
"source": "eip.md",
"summary": "Adds 51 BAL bytes per EIP-7702 authorization to the static floor."
},
{
"locator": "Specification > Final charge",
"source": "eip.md",
"summary": "Continues to require tx.gas at least max(intrinsic, static_floor), with the newly enlarged static floor, while runtime metering can fail execution."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The existing floor-validity rule is materially extended for authorization transactions and floor-dominated combinations. Existing cases need limited expected-validity updates, but no new transaction format or testing infrastructure is required.",
"score": 2,
"uncertainty_note": "Runtime floor OOG is execution failure rather than upfront transaction invalidity; this score is based on the explicit static-floor validity change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Data meter and floor accumulator",
"source": "eip.md",
"summary": "Makes the new values internal and non-persisted, with no block field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced by EIP-8279.",
"score": 0,
"uncertainty_note": "EIP-7928's BAL commitment is baseline behavior, not a new field here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Static floor seed",
"source": "eip.md",
"summary": "Initializes per-transaction counters at the start of each execution."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Requires a hard fork but specifies no activation-block state mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Per-transaction initialization is not a fork-activation state or internal- variable modification under this anchor.",
"score": 0,
"uncertainty_note": "The package gives no special activation-block procedure.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Adds counter updates and conditional per-slot tracking to every listed BAL- producing runtime operation, including variable-length deployed code."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Requires tracing gas estimation to meter runtime BAL bytes for cold accesses, value-bearing calls, and deployments."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The overhead is integrated with broad existing execution and BAL collection, so it cannot be fully benchmarked in isolation, but the package shows simple arithmetic/counter work and does not establish substantial benchmark impact.",
"score": 2,
"uncertainty_note": "No implementation benchmark of the metering overhead is packaged.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Block-size bound",
"source": "eip.md",
"summary": "Security depends on every transaction-contributed block byte being covered by floor_gas_used so the summed block bytes remain bounded by gas/64."
},
{
"locator": "Rationale > Per-auth coverage is static",
"source": "eip.md",
"summary": "Moves authorization BAL coverage to validation because runtime OOG during set_delegation would escape the EVM handler and could crash block processing."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Correctness spans consensus-critical gas, BAL accounting, opcode execution, revert semantics, authorization preprocessing, and block-size DoS bounds. Undercounting or inconsistent OOG placement can break the bound or split clients, requiring extensive review and fuzzing.",
"score": 3,
"uncertainty_note": "The unresolved nested-revert subtraction creates a concrete risk, but score 3 is also supported by the otherwise specified multi-component invariant.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations > Reverts",
"source": "eip.md",
"summary": "Says neither bal_data_bytes nor the floor is rewound for discarded entries and says storage-value bytes charged in later-reverted frames remain charged."
},
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Requires an immediate 32-byte subtraction whenever SSTORE returns a slot to its pre-transaction value."
},
{
"locator": "Rationale > Meter before; refund only when bytes leave the BAL",
"source": "eip.md",
"summary": "Describes the subtraction as firing only on an explicit return to the pre-transaction value on the committed path, without specifying deferral or journal restoration when the containing frame later reverts."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A constructible nested-frame sequence can charge a parent write, subtract in a child that restores the pre-transaction value, then revert the child so the parent write remains in the BAL. The text does not determine whether the subtraction must be undone, deferred, or retained. Agreement is required, but the gap is localized to SSTORE value-byte accounting across reverts.",
"score": 2,
"uncertainty_note": "The package contains no rule resolving this conflict; no external or later information was used.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter > requires",
"source": "eip.md",
"summary": "Explicitly requires EIPs 7623, 7702, 7928, 7976, 7981, and 8131."
},
{
"locator": "Specification > System transactions and withdrawals",
"source": "eip.md",
"summary": "Excludes EIP-2935, EIP-4788, EIP-7002, and EIP-7251 system calls and withdrawals from the per-transaction floor while relying on EIP-7928's buffer."
},
{
"locator": "Specification > Runtime data metering",
"source": "eip.md",
"summary": "Keys SSTORE byte subtraction to EIP-7928 BAL semantics rather than the EIP-3529 gas refund."
},
{
"locator": "Motivation",
"source": "eip.md",
"summary": "Inherits EIP-8131 coverage of EIP-4844 blob hashes and EIP-7702 authorizations while closing the runtime EIP-7928 BAL gap."
},
{
"locator": "Specification > Edge Cases (Normative) > EIP-4895",
"source": "supporting/eip-7928.md",
"summary": "Identifies protocol withdrawals as EIP-4895 balance changes in the BAL."
}
],
"exceptional_score_justification": "The rubric makes this row uncapped. Thirteen package-grounded interacting EIPs produce base 3 plus three increments for the nine complete additional- interaction positions beyond the first three; the remaining one does not form another group of three.",
"id": "cross_eip_interactions",
"interacting_eips": [
2935,
3529,
4788,
4844,
4895,
7002,
7251,
7623,
7702,
7928,
7976,
7981,
8131
],
"rationale": "The floor and its test matrix strongly depend on or coordinate with EIPs 2935, 3529, 4788, 4844, 4895, 7002, 7251, 7623, 7702, 7928, 7976, 7981, and 8131. The base score is 3; ten interactions beyond the first three yield three complete additional groups of three, adding 3 for a total of 6.",
"score": 6,
"uncertainty_note": "Only interactions identified in the sealed package are counted; indirect protocol ancestry is not expanded further.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8279,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8279:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The trigger table requires metering before BAL insertion or state mutation but does not enumerate each hook's exact position relative to all existing gas deductions and state reads; this matters at floor-OOG boundaries.",
"The phrase \"on the committed path\" is not backed by a specified mechanism for identifying commitment at the time an SSTORE returns to the pre-transaction value."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "90d09fbcdaddf1c892bd9e47d08ff4616aea7b9d0737377a9ee9bb4171272745",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8279.md",
"git_blob_sha": "43a44216d4d2daed998542b506b14ae5f368f557",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8279.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8279.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8279.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8279.yaml",
"sha256": "593c5f9f7de3f2ced51c30bdf1253cacdafa7d7f4e336a34ec4d0727622ea1e2"
},
"supporting_documents": [
"supporting/eip-2935.md",
"supporting/eip-3529.md",
"supporting/eip-4788.md",
"supporting/eip-4844.md",
"supporting/eip-7002.md",
"supporting/eip-7251.md",
"supporting/eip-7623.md",
"supporting/eip-7702.md",
"supporting/eip-7928.md",
"supporting/eip-7976.md",
"supporting/eip-7981.md",
"supporting/eip-8131.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 29,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the Draft EIP-8279 snapshot. The proposal extends the EIP-8131 transaction-content floor with per-transaction runtime metering of EIP-7928 BAL bytes, a static per-authorization BAL term, an SSTORE value-byte subtraction, runtime floor OOG checks, and a final max(execution_gas_used, floor_gas_used) charge. System calls and withdrawals remain outside the per-transaction floor and are left to EIP-7928's block-level item buffer.",
"tier": "high",
"title": "Block Access List Byte Floor",
"under_specification": {
"affected_criteria": [
"new_evm_gas_refund",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 30,
"minimum": 29
},
"present": true,
"summary": "The SSTORE value-byte subtraction is not fully specified across nested call reverts. The text requires an immediate subtraction when a slot returns to its pre-transaction value, says counter changes are not rewound for reverted frames, and also limits the subtraction to the committed path. If a parent writes O to X and a child restores X to O but later reverts, the surviving BAL contains X while a retained child subtraction would omit its 32 value bytes and violate the stated upper-bound invariant.",
"unresolved_questions": [
"When an SSTORE subtraction occurs in a child frame that later reverts while an earlier parent-frame write remains live, must the 32-byte subtraction be journaled and undone, deferred until frame commit, or retained?"
]
}
},
"hegota:8298:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameters; Specification > Gas Costs",
"source": "eip.md",
"summary": "SETCODEFROM introduces a 3000-gas base charge plus a source-dependent warm/cold account-access charge, yielding 3100 or 5600 under the stated EIP-2929 constants."
},
{
"locator": "Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "The existing transaction-wide accessed-address mechanism charges cold or warm costs and changes the cost of later account operations after an address is warmed."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This is a new dynamic opcode-gas rule, and executing it participates in the existing transaction-wide warmth mechanism, so it can change gas charged by later existing account-access operations. That reaches score 3 rather than a self-contained constant schedule.",
"score": 3,
"uncertainty_note": "The score assumes participation in accessed_addresses follows the cited active warm/cold mechanism; EIP-8298 does not fully order the base charge, account access, warming, and exceptional-context checks.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETCODEFROM; Specification > Gas Costs",
"source": "eip.md",
"summary": "The instruction reads live source.codeHash, validates source code, charges warm/cold source access, exceptionally halts in initcode or static context, and conditionally writes the current account's codeHash."
},
{
"locator": "Specification > Parameters; Specification > Storage read changes",
"source": "supporting/eip-2929.md",
"summary": "Account access both charges gas and updates the transaction-scoped accessed_addresses set at opcode execution time, with scope-reversion behavior defined for the set."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "A new state-accessing operation is introduced, and the position of its source access and warmth update relative to gas charging and exceptional-context checks must be settled. This matches the score-2 anchor for one new state-accessing operation.",
"score": 2,
"uncertainty_note": "The draft does not say whether static/initcode failure, insufficient gas, or a failed source-validity check occurs before or after the source is recordably accessed and warmed.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters; Specification > Gas Costs",
"source": "eip.md",
"summary": "The only specified charges are EVM base gas and warm/cold source-account access gas."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas counter, price, limit, or charging rule is introduced or modified.",
"score": 0,
"uncertainty_note": "No blob-related behavior appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Gas Costs",
"source": "eip.md",
"summary": "The proposal assigns zero cost to storing source bytecode because it already exists and defines the operation's charge entirely as a 3000 base plus source-account access."
},
{
"locator": "Specification > Multidimensional metering for state creation costs",
"source": "supporting/eip-8037.md",
"summary": "State gas is separately charged for state-creation operations, while other operations are charged to execution gas."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "SETCODEFROM reuses already-stored bytecode and introduces no state-gas rate, budget change, reservoir rule, or state-gas charging site. Its specified charge is execution gas.",
"score": 0,
"uncertainty_note": "The proposal does not explicitly use the state-gas vocabulary for its codeHash write, but its no-new-bytecode rationale and complete SETCODEFROM_GAS formula provide no package evidence for a state-gas change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas Costs; Specification > SETCODEFROM",
"source": "eip.md",
"summary": "Every attempt is charged the defined gas and failure returns zero or exceptionally halts; no refund counter operation is specified."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced. Reverting the code update is ordinary state reversion, not a gas refund.",
"score": 0,
"uncertainty_note": "No refund behavior is stated anywhere in the sealed EIP.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameters; Backwards Compatibility",
"source": "eip.md",
"summary": "The opcode value is TBD, and the hard-fork assignment changes the behavior of already deployed bytecode using the newly assigned instruction."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The affected pre-existing category is narrow: invalid/unassigned-opcode behavior at the eventual opcode byte and any deployed bytecode containing it. This is a minor subset rather than a broad rework.",
"score": 1,
"uncertainty_note": "Because the opcode byte remains TBD, the exact existing-test subset cannot yet be identified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "The new result and codeHash mutation occur only when the new instruction executes; the compatibility impact is limited to bytecode using that instruction."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to SETCODEFROM do not gain a mechanically required new assertion merely because the fork activates.",
"score": 0,
"uncertainty_note": "The Test Cases section is TODO, but no package text defines a fork-wide output or invariant for every pre-existing test.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETCODEFROM; Backwards Compatibility",
"source": "eip.md",
"summary": "The change is expressed as opcode execution over existing stack, account, codeHash, and gas state and requires a normal hard-fork activation."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool input or output field and no new interface mechanism is specified.",
"score": 0,
"uncertainty_note": "Implementations need opcode support, but that is not evidence of an interface-field change under this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > SETCODEFROM; Specification > Deployed Code Execution; Test Cases",
"source": "eip.md",
"summary": "The observable behaviors are stack success, account code changes, calls, exceptional halts, and reverts; the Test Cases section contains only TODO and requests no new testing abstraction."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The package does not establish a need for a new expectation type, modifier, or framework-level helper beyond composing opcode, call, state, and revert tests.",
"score": 0,
"uncertainty_note": "The absent test design limits confidence that existing helpers cover same-transaction code replacement ergonomically, but no required primitive is evidenced.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation; Specification > SETCODEFROM",
"source": "eip.md",
"summary": "Post-quantum migration is a use case, but the instruction itself takes an address and copies an existing live account codeHash without defining a cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified. Existing hash and ECDSA consequences are state-identity interactions, not new cryptography in this EIP.",
"score": 0,
"uncertainty_note": "The proposal's PQ motivation does not change the execution-layer mechanism scored here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETCODEFROM; Specification > Deployed Code Execution",
"source": "eip.md",
"summary": "Cases include low-160-bit address truncation, precompile/empty/invalid/valid sources, initcode and static exceptional halts, success versus zero return, frame or transaction revert, delegated versus direct execution, current-frame old code, and later/re-entrant execution of new code."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Implementations must separate currently executing code from later-visible account code, and re-entrant calls after success observe the update."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Several independent boundaries exist, and temporal visibility plus re-entrancy requires an elevated cross-product of context, source validity, warmth, gas boundary, success/revert, and delegated/direct cases.",
"score": 3,
"uncertainty_note": "The source-validity predicate is illustrative rather than exhaustive, so the final boundary set may be larger.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal adds an EVM instruction and describes account-state execution effects, with no block RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism requiring syncing tests is introduced.",
"score": 0,
"uncertainty_note": "No block-serialization surface appears in the package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "All normative changes are within EVM instruction execution and account state."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is added or modified.",
"score": 0,
"uncertainty_note": "No Engine API surface is described.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > SETCODEFROM",
"source": "eip.md",
"summary": "The proposal introduces an instruction usable by executing account code and does not deploy a protocol-owned contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "The factory and wallet templates are application examples, not added system contracts.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification; Rationale",
"source": "eip.md",
"summary": "SETCODEFROM is self-only for the current execution-environment account, and no existing system contract code, state, or invocation is named for modification."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "There is no direct or package-evidenced indirect modification to a pre-existing system contract.",
"score": 0,
"uncertainty_note": "Generic accounts could choose to execute the opcode, but the sealed package identifies no system-contract consumer.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters; Specification > SETCODEFROM; Specification > Gas Costs",
"source": "eip.md",
"summary": "One new opcode is defined with one input and one output, live account access, conditional account-state mutation, and dynamic warm/cold gas; its numeric value is TBD."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This is one complex opcode because its cost is dynamic and it performs state access and conditional state mutation.",
"score": 2,
"uncertainty_note": "The missing numeric assignment blocks final bytecode vectors but does not change the count or complex character of the opcode.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Deployed Code Execution",
"source": "eip.md",
"summary": "The current frame continues its already-loaded code and later code-executing operations use the updated account state; no existing opcode definition is rewritten."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Existing operations can observe state changed by SETCODEFROM, but their own behavior is not modified by the proposal.",
"score": 0,
"uncertainty_note": "Code-inspection cases need tests, but the package frames their changed results as consequences of the new state mutation rather than modified opcode semantics.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETCODEFROM",
"source": "eip.md",
"summary": "Precompile addresses are explicitly invalid source accounts; no new precompile address or function is defined."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "The source exclusion is an opcode validation branch, not a precompile addition.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETCODEFROM; Security Considerations",
"source": "eip.md",
"summary": "The instruction rejects precompile sources and merely mentions an optional companion ecRecover change in a separate EIP."
},
{
"locator": "Abstract; Specification > Modified ecRecover Behavior",
"source": "supporting/eip-8151.md",
"summary": "The ecRecover behavior change is specified by EIP-8151, not EIP-8298."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "EIP-8298 does not alter precompile logic or gas accounting.",
"score": 0,
"uncertainty_note": "Co-activation with the companion proposal is handled as a cross-EIP interaction, not attributed as an EIP-8298 precompile modification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > SETCODEFROM",
"source": "eip.md",
"summary": "The new input is an EVM stack item interpreted as a low-160-bit address, and no transaction, block, or interface encoding is defined."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, transaction, block, or interface encoding changes are introduced.",
"score": 0,
"uncertainty_note": "Assigning an opcode byte is EVM bytecode semantics, not an encoding change at the levels named by this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > SETCODEFROM",
"source": "eip.md",
"summary": "The feature is a runtime-only instruction and adds no transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "The instruction can execute within existing transaction execution, subject to its initcode prohibition.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > ECDSA Transaction Origination",
"source": "eip.md",
"summary": "After adoption, ECDSA origination and redelegation fail by application of the already-existing EIP-3607 and EIP-7702 code checks."
},
{
"locator": "Specification",
"source": "supporting/eip-3607.md",
"summary": "EIP-3607 already rejects a transaction whose sender has non-empty code."
},
{
"locator": "Specification > Set code transaction > Behavior; Specification > Transaction origination",
"source": "supporting/eip-7702.md",
"summary": "EIP-7702 already limits authorization processing and transaction origination according to empty, delegated, or regular account code."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "SETCODEFROM creates account state to which existing validity rules apply; it does not create or modify the validity mechanism or intrinsic gas calculation of a transaction type.",
"score": 0,
"uncertainty_note": "The consequence is security-critical and requires cross-EIP tests, but it is not itself a transaction-validity rule change under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative state consists of opcode parameters and account execution behavior; no block or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "No header surface appears in the sealed proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Activation is described as a hard fork that makes the new instruction available, without an activation-block state transition."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No account state, pre-existing internal variable, or similar value is modified specifically at the activation block.",
"score": 0,
"uncertainty_note": "Normal opcode-table activation is not an irregular fork-activation mechanism under this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Gas Costs; Rationale",
"source": "eip.md",
"summary": "Each attempt performs one live source-account read and one conditional current-account codeHash update; no source bytecode is stored, and the fixed charge is independent of source code size."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new read/write path needs isolated benchmarking, especially for cold versus warm access and journaling, but it is bounded and does not add bytecode copying or a size-dependent workload.",
"score": 1,
"uncertainty_note": "The package contains no benchmarks or performance-validation plan, so cache, journaling, and repeated-update costs are not quantified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The instruction can permanently change account behavior, changes code-identity and inspection semantics, permits delegated execution to update the authority account, disables protocol-level ECDSA origination, and creates re-entrant visibility of new code."
},
{
"locator": "Specification > Delegation indicator; Security Considerations > Storage management",
"source": "supporting/eip-7702.md",
"summary": "Delegated execution separates authority from loaded code, and changing account code is security-critical because storage and authority assumptions can collide across implementations."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism crosses critical account authority, code identity, delegated execution, storage compatibility, transaction origination, re-entrancy, and revert boundaries. Incorrect implementation or exposure can transfer control or strand an account, warranting extensive review and fuzzing.",
"score": 3,
"uncertainty_note": "The package is explicit about the risk classes, but the TODO tests and open source-validity predicate leave their final test matrix incomplete.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameters; Specification > SETCODEFROM; Test Cases",
"source": "eip.md",
"summary": "The opcode value is TBD, regular deployed-code validity is described with a non-exhaustive 'e.g.' rule, detailed state-access/check ordering is absent, and the test section is TODO."
},
{
"locator": "Specification > Deployed Code Execution; Security Considerations",
"source": "eip.md",
"summary": "The new, previously unavailable same-transaction code replacement makes current-frame versus later-call and code-inspection visibility consensus-observable."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Several constructible outcomes cannot yet be baselined, including bytecode selection, access-list/gas-boundary effects, and the complete source-validity predicate. Those gaps concern a newly observable code-identity transition and can require vectors to be re-derived as the draft is amended.",
"score": 3,
"uncertainty_note": "The sealed package provides Draft status but no permitted evidence about implementations, devnets, or discussion resolution; the score rests only on the visible normative gaps.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter > requires; Specification > Gas Costs; Specification > ECDSA Transaction Origination",
"source": "eip.md",
"summary": "The EIP requires 2200, 2929, 3607, and 7702 for gas comparison, warm/cold access, sender-code validity, delegated execution, and authorization-code restrictions."
},
{
"locator": "Specification > SETCODEFROM; Motivation",
"source": "eip.md",
"summary": "Source-code validity uses the 0xEF reservation associated with 3541/7702, and the deployment-economics use case explicitly targets state-creation pricing under 8037."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The proposal identifies coordinated behavior with 7702 delegation, contrasts 6913 without depending on it, and identifies 8151 as a companion for account-code-restricted ecRecover."
},
{
"locator": "Testing Anchors > State-access ordering within opcode execution",
"source": "rubric.md",
"summary": "A new state access must be coordinated with block-level access-list observability at gas boundaries."
},
{
"locator": "Specification > Pre-state and post-state gas validation; Rationale > Account-creation charging and EIP-7928",
"source": "supporting/eip-8037.md",
"summary": "The package identifies 7928 as the block-level access-list proposal that constrains recordable state-access timing."
}
],
"exceptional_score_justification": "The score of 4 is the rubric's mechanical uncapped result: eight identified interacting EIPs produce score 3 plus one increment for the first group of three additional interactions beyond the initial three.",
"id": "cross_eip_interactions",
"interacting_eips": [
2200,
2929,
3541,
3607,
7702,
7928,
8037,
8151
],
"rationale": "The coordinated set is 2200, 2929, 3541, 3607, 7702, 7928, 8037, and 8151. Gas/warmth, deployed-code validity, authority-account selection, sender and authorization validity, block-level access recording, state-growth pricing, and ecRecover behavior each need targeted combined cases. With eight interactions, the rubric gives base score 3 plus one increment for at least three additional interactions beyond the first three.",
"score": 4,
"uncertainty_note": "6913 is only a withdrawn comparison and 20 only an application example, so neither is counted. Additional active-fork code-validity rules are not exhaustively identified by the draft.",
"under_specified": true,
"unidentified_interactions": [
"Any additional active-fork deployed-code-validity rule encompassed by the phrase 'valid regular deployed code under the active fork'; EIP-8298 gives only an example and no complete numbered set."
]
}
],
"eip": 8298,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8298:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The access-ordering test space is multiplicative: cold/warm, static/non-static, initcode/deployed, delegated/direct, valid/invalid source, sufficient/insufficient gas, success/revert, and later direct/re-entrant observation can change the expected result or recorded access.",
"The 3000 base charge is justified by analogy to a warm nonzero-to-nonzero SSTORE, but it is a fixed SETCODEFROM rule rather than reuse of SSTORE net-metering or refund semantics.",
"The draft says regular code adoption disables ECDSA transaction origination permanently at protocol level, while application-level signature recovery remains possible unless the separately specified companion behavior is also adopted."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "177a518511561d0dbf01c988dc1669090599b49e77810b514d0fb910f2c61f91",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8298.md",
"git_blob_sha": "aa6440a0cced18795317ac74a4a414c42342c9da",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8298.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8298.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8298.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8298.yaml",
"sha256": "1b7eed2ca59d07494e967ad62898c916038efee182c0de83865df45a3e60e56a"
},
"supporting_documents": [
"supporting/eip-20.md",
"supporting/eip-2200.md",
"supporting/eip-2929.md",
"supporting/eip-3541.md",
"supporting/eip-3607.md",
"supporting/eip-6913.md",
"supporting/eip-7702.md",
"supporting/eip-8037.md",
"supporting/eip-8151.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 22,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the sealed Draft of EIP-8298: one runtime-only EVM instruction that adopts a live source account's code hash, charges a fixed base plus active warm/cold account-access gas, mutates the current execution-environment account with revert semantics, and makes the new code visible to later execution while the current frame continues its already-loaded code.",
"tier": "medium",
"title": "SETCODEFROM Code Reuse Instruction",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 23,
"minimum": 21
},
"present": true,
"summary": "Material under-specification remains in the opcode assignment, the exact source-access/gas/check ordering, and the exhaustive definition of valid regular deployed source code. These are recorded once here; their direct scoring consequences are confined to the listed criteria.",
"unresolved_questions": [
"What numeric value is SETCODEFROM_OPCODE?",
"In what exact order are stack/context checks, base-gas charging, source access and warming, source-code reads, validity checks, and the current-account write performed, especially at out-of-gas boundaries and in static or initcode execution?",
"What is the exhaustive active-fork predicate for valid regular deployed source code beyond the stated 0xEF example?",
"Are later EXTCODE* observations of the current account required to change immediately while CODESIZE and CODECOPY remain bound to the current frame's already-loaded code?"
]
}
},
"hegota:8304:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "high",
"published_total": 26,
"recomputed_tier": "high",
"recomputed_total": 26,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No opcode gas schedule or gas-calculation rule is modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No changes to State-access ordering within opcode execution",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Blob gas is not involved.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas cost changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Refunds are not involved.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Every test executed under the new fork must account for the additional index-root state transition.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Every post-fork block must generate and publish at least its single-block table root. Therefore, the expected post-state of every post-fork fixture depends on the index-contract update, regardless of the behavior the test was originally written to exercise.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The transition tool needs a new index-table construction mechanism. A level-0 table can be derived from the current block and its receipts, but publishing delayed higher-level tables requires prior index entries, historical blocks, or equivalent persistent context that is not available in an ordinary single-block transition input.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Permanent framework primitives are needed for entry extraction, canonical binary encoding, lexicographic sorting, SHA-256 hashing, SSZ merkleization, table merging, delayed publication, and ring-buffer addressing.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Adds SHA-256 entry hashing and SSZ merkleization, but both are mature mechanisms with abundant existing test resources.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Covers the fork boundary, genesis, the parent-block hash offset, table alignment, five table sizes, delay deadlines, ring-buffer wraparound, invalid/zero table size, zero root, empty blocks, topic count, duplicate values, lexicographic byte ordering, reorgs, and sync initialization. A large combinatorial test set is required.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation rule or synchronization protocol is modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No execution-payload field, Engine API endpoint changes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "One new stateful system contract is introduced. It receives a protocol-generated update every block and may receive multiple updates when several table levels become publishable at the same block.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcodes.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "LOG0–LOG4 and all other opcodes retain their existing execution semantics.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompiles.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompiles are modified.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal defines an internal encoding for index entries and uses SSZ for table commitments, but it does not alter transaction, receipt, block, header, or protocol-interface encoding.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity, intrinsic gas, and transaction encoding are all unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No header field is added;",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Fork activation requires deploying/initializing the new system-contract account. In addition, a table is only generated when the EIP was already active at its `first_block`, so each table level starts appearing progressively after the fork. Explicit fork-boundary state-transition tests are required.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Every block must build, encode, sort, and hash all transaction and log entries, and merge the 4/16/64/256-block tables before their deadlines. The cost interacts with tx count, log count, topics, reorgs, disk layout, and sync state, and cannot be fully validated by isolated microbenchmarks alone.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect entry generation, ordering, SSZ root, delay timing, or ring-buffer slot all produce a different state root and therefore consensus divergence.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The EIP is still Draft with no client implementations and no devnet. `INDEX_CONTRACT_ADDRESS` and the synthetic deployment transaction are TBD, and the `List[Hash32, entry_count]` SSZ type admits more than one reading that yields different Merkle roots. These points are localized and need client agreement before vectors can be baselined; reorg handling is likewise left to clients.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Explicitly depends on EIP-4788's system-call and deployment convention.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8304,
"fork": "hegota",
"id": "hegota:8304:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8304.yaml",
"sha256": "6d8524db8af64855b1b0bf48b9bd1ce5fd4844761ea8ee4163fbb067e934dd4e"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "ec861017c0006c353bdab4a9f3e910e40609495c",
"content_sha256": "8a57b185f6573a462a85f1154debe156f506b9eb0593351f47197792ebb95d10",
"git_blob_sha": "d4ccf1a464a005c07cb98694dc5303c61a9b8439",
"immutable_url": "https://github.com/ethspecs/pm/blob/ec861017c0006c353bdab4a9f3e910e40609495c/complexity_assessments/EIPs/EIP-8304.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8304.md",
"pull_request": {
"draft": false,
"number": 127,
"title": "Add EIP-8304 complexity assessment",
"updated_at": "2026-08-24T13:22:36Z",
"url": "https://github.com/ethspecs/pm/pull/127"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 26,
"scored": true,
"source": "human",
"status": "available_in_open_pr",
"summary": null,
"tier": "high",
"title": "Trustless log and transaction index",
"under_specification": null
},
"hegota:8304:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Each root update is a 30,000,000-gas system call that must complete, is excluded from the block gas limit, and does not apply EIP-1559 burn semantics."
},
{
"locator": "Specification > Gas costs",
"source": "eip.md",
"summary": "The proposal explicitly leaves LOG-operation gas costs unchanged."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal applies the existing gas-exempt system-operation convention to a new mandatory call, updating an existing accounting path without changing opcode prices or introducing a new metering mechanism.",
"score": 1,
"uncertainty_note": "The text is explicit about the system call and unchanged LOG costs, but does not separately classify this convention as an EVM gas-rule change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "The new root-write call occurs after processing all transactions."
},
{
"locator": "Specification > Gas costs",
"source": "eip.md",
"summary": "Existing LOG operations retain their gas cost."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The new work is a block-level post-transaction operation; no opcode's internal state-access point or gas-charge ordering is changed.",
"score": 0,
"uncertainty_note": "No opcode-internal ordering change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "The specified accounting exception concerns only the index-contract system call."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas rule, charge, budget, or field is introduced or modified.",
"score": 0,
"uncertainty_note": "The proposal contains no blob-gas behavior.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Index contract > set",
"source": "eip.md",
"summary": "Root updates use ordinary storage writes in the index contract."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "The proposal specifies only the system call's execution-gas treatment."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The stateful contract adds storage writes but defines no new state-gas rate, charging site, budget, reservoir, or execution-gas spill rule.",
"score": 0,
"uncertainty_note": "The draft does not state how its gas-exempt system operation relates to a separate state-gas regime; that omission is recorded as under-specification, not scored as an introduced mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas costs",
"source": "eip.md",
"summary": "The only gas-cost statement is that LOG costs need not increase."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is added or changed.",
"score": 0,
"uncertainty_note": "The proposal contains no refund behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Indexing rules",
"source": "eip.md",
"summary": "Every transaction, every log address/topic, and a delayed parent block hash contribute entries to the index."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Every active block generates a level-0 table and may generate delayed higher-level tables, with all resulting roots written to contract storage."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork block tests across transactions, empty blocks, logs, state roots, block hashes, and periodic boundaries must incorporate the mandatory index transition. This is a major, diverse regression surface.",
"score": 3,
"uncertainty_note": "The package does not expose the existing test corpus, so the exact count of reworked vectors is unknown; the mandatory behavior itself spans diverse test categories.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Every active block commits generated table roots into index-contract storage."
},
{
"locator": "Specification > Index tables > Table root hash calculation",
"source": "eip.md",
"summary": "Each expected root commits to the sorted encoded-entry list."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of post-fork tests gains a mechanically derived index-root and system-state expectation even when indexing is not the test's subject. The rule does not apply before activation, so the score stops below the every-vector anchor.",
"score": 2,
"uncertainty_note": "Test harnesses may assert this indirectly through the state root rather than as a dedicated field, but the new expected state is still mandatory.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Initializing after chain/state sync",
"source": "eip.md",
"summary": "A client can require the latest 319 blocks to construct a highest-level root for the first validated block after sync."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Higher-level outputs depend on delayed merging of earlier block ranges."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A single-block transition interface needs a new mechanism to supply or retain recent blocks and prior table material so it can derive periodic roots. That is more than one isolated scalar field, but the EIP does not prescribe the exact interface.",
"score": 2,
"uncertainty_note": "No transition-tool schema is included, so whether implementations use one history object, several fields, or externally prepared tables remains open.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Index tables",
"source": "eip.md",
"summary": "Tests must generate typed binary entries, sort them lexicographically, hash them, and construct fixed-depth SSZ-list roots."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Tests must also schedule immediate and delayed roots across five levels."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Reusable index-table construction, merge, and delayed-schedule expectations are new primitives needed throughout this EIP's tests, rather than ordinary test functions using only scalar expectations.",
"score": 2,
"uncertainty_note": "The sealed package contains no test-framework inventory, so permanence or reuse outside this EIP cannot be established.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Index tables > Table root hash calculation",
"source": "eip.md",
"summary": "The root is the SSZ-list root of SHA2-256 hashes of the binary encoded entries."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The proposal introduces one commitment construction composed of established SHA2-256 hashing and SSZ Merkleization; it is well known rather than novel.",
"score": 1,
"uncertainty_note": "The construction's missing fixed depth/list limit is a consensus-specification gap, but does not make the underlying cryptography novel.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Indexing rules",
"source": "eip.md",
"summary": "Block entries are delayed by one block, genesis has no block entry, and multi-block ranges use an offset block-hash interval."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Five levels have alignment and activation conditions, while higher levels use table-size-dependent delays."
},
{
"locator": "Specification > Index contract > get",
"source": "eip.md",
"summary": "Reads enforce calldata length, divisibility, initialization, validity, and ring-buffer overwrite conditions relative to the current block number."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Genesis, activation, empty tables, level alignment, delayed availability, five table sizes, and 1,024-slot wraparound create multiple interacting boundary mechanisms. The schedule-by-level and overwrite combinations require an elevated case count.",
"score": 3,
"uncertainty_note": "The missing SSZ depth/list limit prevents the exact empty and maximum-table boundary vectors from being baselined.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Initializing after chain/state sync",
"source": "eip.md",
"summary": "The EIP explicitly says the sync protocol need not be extended; tables can be regenerated from recent blocks, with up to 319 blocks required."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Regeneration adds local post-sync work, but no block-RLP validation mechanism or sync-protocol encoding is introduced, which is the scope of this anchor.",
"score": 0,
"uncertainty_note": "The 319-block retention/download requirement is a performance and initialization concern, not a scored RLP syncing change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Root generation and the contract call are specified as execution-client block processing."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is specified.",
"score": 0,
"uncertainty_note": "The package does not prescribe any Engine API exposure for the generated roots.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Index contract",
"source": "eip.md",
"summary": "A new index contract exposes get/set operations and stores root hashes in per-level ring-buffer slots."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "The protocol invokes the contract as SYSTEM_ADDRESS during block processing."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Exactly one new system contract is added, and it is stateful because mandatory block processing repeatedly writes its storage.",
"score": 2,
"uncertainty_note": "INDEX_CONTRACT_ADDRESS and the signed synthetic deployment transaction remain TBD, but the addition and statefulness are unambiguous.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "The proposal reuses EIP-4788's calling convention at its own index-contract address."
},
{
"locator": "Specification > Beacon roots contract",
"source": "supporting/eip-4788.md",
"summary": "EIP-4788's beacon-roots contract remains independently addressed and specified."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Reusing SYSTEM_ADDRESS and the system-call convention does not modify the code, state, or behavior of the pre-existing beacon-roots system contract.",
"score": 0,
"uncertainty_note": "No indirect behavioral change to a pre-existing system contract is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Index contract > Bytecode",
"source": "eip.md",
"summary": "The supplied contract is composed of existing EVM instructions."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is defined.",
"score": 0,
"uncertainty_note": "Contract bytecode is new code, not a new opcode.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Gas costs",
"source": "eip.md",
"summary": "Existing LOG operations retain their gas costs."
},
{
"locator": "Specification > Index contract > Bytecode",
"source": "eip.md",
"summary": "Existing opcodes are used without changing their semantics."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode result or non-gas behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "The index observes logs after execution but does not alter LOG semantics.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Index contract",
"source": "eip.md",
"summary": "The new callable facility is explicitly an EVM system contract with bytecode and storage."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "The system contract must not be classified as a precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Index contract",
"source": "eip.md",
"summary": "All new callable behavior is implemented by the index contract."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "The proposal contains no precompile behavior.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Roots are stored in contract state, and existing block-header bloom filters are unchanged."
},
{
"locator": "Specification > Index tables > Table root hash calculation",
"source": "eip.md",
"summary": "SSZ is used for the new off-header index-table commitment itself."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal defines a new internal index-table encoding but does not change transaction, block, header, or Engine-interface encoding. The anchor's enumerated protocol encoding surfaces therefore remain unchanged.",
"score": 0,
"uncertainty_note": "SSZ is newly used for table roots, but those tables are not transaction, block, or interface payloads under the rubric's stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Indexing rules",
"source": "eip.md",
"summary": "Existing transactions are indexed by their hashes and positions."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "Indexing transactions does not introduce a transaction envelope or type.",
"score": 0,
"uncertainty_note": "The proposal applies uniformly to transactions already present in blocks.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Indexing rules",
"source": "eip.md",
"summary": "Transaction hashes and receipt logs are consumed only after inclusion for index construction."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "The incompatibility is described as a block-validation-rule change, not a transaction-validity change."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No existing transaction's validity rules or intrinsic gas calculation changes; the proposal derives a post-execution commitment from already processed transactions.",
"score": 0,
"uncertainty_note": "Incorrect index processing can invalidate a block, but not an individual transaction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Roots are placed in system-contract storage and block-header bloom filters are unaffected."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is added; the new commitment is part of execution state.",
"score": 0,
"uncertainty_note": "The block state root changes indirectly, but its header field and encoding do not.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Index contract > Deployment",
"source": "eip.md",
"summary": "A synthetic deployment transaction is specified for the new system contract."
},
{
"locator": "Specification > EIP-161 handling",
"source": "eip.md",
"summary": "The deployed account has code and nonce 1 and is exempt from empty-account cleanup."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Tables are generated only when the EIP was active at the table's first block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation installs code and initializes an account nonce, an explicit irregular state modification at the fork boundary, and begins table scheduling from that boundary.",
"score": 3,
"uncertainty_note": "The exact address and signed deployment fields are TBD, so activation vectors cannot yet be finalized even though the required state modification is clear.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Index tables",
"source": "eip.md",
"summary": "Each block's transactions and every log address/topic produce variable-length entries that must be sorted, hashed, and Merkleized."
},
{
"locator": "Specification > Block processing",
"source": "eip.md",
"summary": "Five levels are maintained, and higher-level table merges must finish by table-size-dependent delayed block-processing deadlines."
},
{
"locator": "Specification > Initializing after chain/state sync",
"source": "eip.md",
"summary": "The worst first post-sync update requires data from 319 recent blocks."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Work scales with transaction and log content, interacts with receipt production, periodic multi-level merging, block deadlines, storage updates, and sync recovery. End-to-end and adversarial-content performance cannot be established by one isolated microbenchmark and can substantially affect validation behavior.",
"score": 3,
"uncertainty_note": "The EIP asserts low single-block cost and asynchronous larger merges but gives no processing bounds, benchmark results, or maximum entry/tree size.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "The hot system-contract storage branches are identified as susceptible to branch-poisoning attempts intended to slow state-root updates."
},
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The stored roots are intended to authenticate trustless log and transaction lookups."
},
{
"locator": "Specification > Indexing rules",
"source": "eip.md",
"summary": "Commitments combine block hashes, transaction hashes, and receipt logs."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Root correctness and update availability affect trustless proofs and consensus state, while hot storage creates a targeted resource-attack surface. The interactions are concentrated in index derivation and its system contract, so targeted review and fuzzing fit better than the broadest security anchor.",
"score": 2,
"uncertainty_note": "Missing commitment parameters and deployment constants prevent complete proof- soundness and adversarial-storage analysis at this snapshot.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters",
"source": "eip.md",
"summary": "INDEX_CONTRACT_ADDRESS is TBD."
},
{
"locator": "Specification > Index tables > Table root hash calculation",
"source": "eip.md",
"summary": "The text calls the tree fixed-depth but gives no depth or SSZ List limit, even though those parameters determine the root, including for empty tables."
},
{
"locator": "Specification > Index contract > Deployment",
"source": "eip.md",
"summary": "The signature values, transaction hash, sender, and resulting contract address of the synthetic deployment are all TBD."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously uncommitted transaction/log indexing becomes consensus-visible through contract storage and the block state root, yet root-defining SSZ parameters and activation deployment values are absent. Constructible blocks therefore lack a unique expected state until clients agree and the draft is amended.",
"score": 3,
"uncertainty_note": "No package evidence establishes implementations, devnet baselines, or resolutions for these gaps; prohibited external history was not consulted.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter; Specification > Block processing; Specification > EIP-161 handling",
"source": "eip.md",
"summary": "EIP-8304 requires 4788, reuses its system-operation convention, adopts 1559 burn exceptions, and applies 161 deployment-cleanup handling."
},
{
"locator": "Motivation > Synergy with ZKP batched pre-checks; Specification > Alternative index contracts",
"source": "eip.md",
"summary": "The proposal identifies interactions with frame transactions and ETH-transfer logs."
},
{
"locator": "Specification > ETH transfer logs",
"source": "supporting/eip-7708.md",
"summary": "EIP-7708 adds protocol-generated logs that become EIP-8304 index entries."
},
{
"locator": "Specification > Receipt Encoding",
"source": "supporting/eip-8141.md",
"summary": "Frame receipts define transaction logs as concatenated per-frame logs for block bloom and log indexing, requiring coordinated entry extraction."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
161,
1559,
4788,
7708,
8141
],
"rationale": "Coordinated vectors are required for EIPs 161, 1559, and 4788 around deployment and system-call semantics, and for EIPs 7708 and 8141 around newly generated logs and frame-receipt indexing. These span multiple strong interactions, but five identified EIPs do not trigger the rubric's first three-additional-EIP bonus.",
"score": 3,
"uncertainty_note": "The precise fork combination is outside the package; the score uses only the explicit and supporting-document interactions sealed here.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8304,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8304:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"`List[Hash32, entry_count]` uses the actual entry count where an SSZ list limit/root- defining constant is expected, while the prose separately says the tree has fixed depth.",
"Clients may directly write storage instead of executing the system call, but the equivalence requirements are stated only as a preference, not as explicit observable invariants.",
"The proposal says higher tables can be merged asynchronously while also making their roots mandatory at precise later blocks, without bounding intermediate work or retained artifacts."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "f38a23beb31f2552ac3e61e13f3bb31148e8a656ce240a0ae12e7b906816327d",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8304.md",
"git_blob_sha": "036b1a21f2ecd42baac6a826ec37fffd90cebfec",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8304.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8304.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8304.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8304.yaml",
"sha256": "b84aa652b0edbae85d8167ed83400b28f519436eaa704fa7e89c485d3aa6852a"
},
"supporting_documents": [
"supporting/eip-161.md",
"supporting/eip-1559.md",
"supporting/eip-4788.md",
"supporting/eip-7708.md",
"supporting/eip-8141.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 30,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the Draft EIP-8304 snapshot. The proposal derives SSZ/SHA2-256 index-table roots from every block's transactions, receipts, logs, and delayed parent block hash; periodically merges those tables across five levels; and writes the roots through a new stateful system contract. No consensus-layer behavior is scored.",
"tier": "high",
"title": "Trustless log and transaction index",
"under_specification": {
"affected_criteria": [
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"added_system_contracts",
"new_fork_activation_mechanism",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 33,
"minimum": 27
},
"present": true,
"summary": "Material consensus parameters are absent. The SSZ List limit/fixed tree depth needed to derive roots is not stated; the index-contract address and most fields of its synthetic deployment are TBD; and the transition/testing interface and bounded asynchronous merge obligations are not specified. These are recorded once here rather than being multiplied across otherwise unrelated zero-score anchors.",
"unresolved_questions": [
"What fixed binary-tree depth or SSZ List limit applies to table roots, and what exact root is expected for an empty table?",
"What are INDEX_CONTRACT_ADDRESS, the synthetic transaction's v/r/s/hash and sender, and the exact fork-activation deployment procedure, including genesis activation?",
"What historical blocks or prior table artifacts must a one-block transition tool accept and return so delayed higher-level roots are reproducible?",
"What deterministic resource/deadline requirements govern asynchronous merges, reorg recovery, and the first post-sync block at every table-level boundary?",
"How does the gas-exempt root-update operation interact with any separate state-gas accounting applied to its storage creation and overwrites?"
]
}
},
"hegota:8368:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 16,
"recomputed_tier": "medium",
"recomputed_total": 16,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Execution gas schedule untouched. The change is confined to state gas, scored on its own row. Measured: zero execution-gas flips outside state-charging paths.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No ordering changes, only the size of a charge.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The definitional anchor-1 case: `COST_PER_STATE_BYTE` is adjusted (1530 to a provisional 3060). Byte rates, charging sites, reservoir mechanics, and the spill path are untouched.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Measured blast radius: 1,614 executions / 314 functions of 65,756 collected, spanning ported static plus tangerine, byzantium, osaka, prague, and amsterdam suites. 300 files parked, 8 sibling suites re-derived to fork-correct budgets. Scored above anchor 3 because the impact recurs: the value is TBD, so every parked boundary and re-derived budget moves again when the final value lands.",
"raw_score_cell": "4",
"score": 4,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "No new assertion lands on unrelated tests.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The constant flows through the existing interface.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The EIP-8037 fork API (`cost_per_state_byte`) already exists; activation is one override.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Exact-fit and one-short OOG boundaries at every charging site, plus the funding-regime boundary (reservoir vs spill vs the block gas limit, which a max-size deposit now exceeds). Multiple prone surfaces, none with elevated case counts.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The system-transaction reservoir re-derives from the constant; contract code unchanged.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No result changes, only prices.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Intrinsic rules and the gas limit cap are unchanged; only charged amounts shift.",
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "No new mechanism, but the recalibrated value can only be validated against state-growth benchmarks, and the benchmark suite sits outside the measured blast radius (excluded from default fills) while its state-heavy compositions halve in per-block capacity.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A self-contained parameter change, validated in isolation. It doubles the economic cost of state creation, an economics shift rather than a mechanism risk.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Scored from the EIP's state at assessment time: the entire Specification section is TBD (reference limit, value, rationale, rounding rule), there are no client implementations, and it has never been on a devnet. Every amendment round re-baselines every fixture that creates state. The prototype's ceiling rounding reproduces the published 1530 at 150M, but nothing in the EIP confirms it.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "Directly modifies EIP-8037. Coordinated testing needed with EIP-7954 (a 2x CPSB puts a max-size deposit above ~201M gas, undeployable below that block limit), EIP-7825 (cap-funded state creation capacity halves to ~5.5 KiB per transaction), EIP-7702 (per-authorization state gas), EIP-7928 (BAL scenario budgets), and EIP-8038 (companion access-gas schedule). Six interacting EIPs: anchor 3 plus one increment.",
"raw_score_cell": "4",
"score": 4,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8368,
"fork": "hegota",
"id": "hegota:8368:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8368.yaml",
"sha256": "b1cc9217440acbd925af502216700423efbdf8761977feff55692ad2b29dec40"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "e47b8d0d35ef9a949f193f202564e32e128460cc",
"content_sha256": "8163ff2c35ea114f8526bb337db11d383351da6fce7e2b5f168d313041c3326c",
"git_blob_sha": "c5097f7fc61a6202a89e36d392d0d1b3dfe322aa",
"immutable_url": "https://github.com/ethspecs/pm/blob/e47b8d0d35ef9a949f193f202564e32e128460cc/complexity_assessments/EIPs/EIP-8368.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8368.md",
"pull_request": {
"draft": true,
"number": 129,
"title": "Add EIP-8368 complexity assessment",
"updated_at": "2026-08-24T13:45:56Z",
"url": "https://github.com/ethspecs/pm/pull/129"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 16,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "medium",
"title": "CPSB Recalibration for New Gas Limit",
"under_specification": null
},
"hegota:8368:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal changes only CPSB, the unit cost per new state byte, and says every other EIP-8037 parameter, mechanism, and semantic remains unchanged."
},
{
"locator": "Specification / Multidimensional metering for state creation costs",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 assigns state-creation costs using CPSB to the separate state-gas dimension, while other operation costs remain execution-gas."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The targeted parameter is a state-gas cost, not an EVM execution-gas accounting rule; no execution-gas accounting mechanism is changed.",
"score": 0,
"uncertainty_note": "The CPSB amount is missing, but its absence does not move the change into the execution-gas accounting dimension.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal expressly leaves all EIP-8037 mechanisms and semantics unchanged and changes only the CPSB value."
},
{
"locator": "Specification / Pre-state and post-state gas validation",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 already defines when state-gas is computed and deducted for state-accessing opcodes."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Replacing a multiplier does not move any state access or gas charge relative to an access, and EIP-8368 specifies no ordering change.",
"score": 0,
"uncertainty_note": "The replacement value is TBD, but no ordering question is left open.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal is limited to recalibrating the cost per state byte and contains no blob-gas provision."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas accounting rule or value is changed.",
"score": 0,
"uncertainty_note": "Nothing in the stated placeholder scope suggests a blob-gas change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "EIP-8368 will replace the CPSB value using the EIP-8037 methodology for a new reference block gas limit, but the new value is TBD."
},
{
"locator": "Specification / New parameters; Parameter changes",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 defines CPSB as 1530 and multiplies it by state-byte rates for storage, accounts, authorization data, and deployed code."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "This is precisely an adjustment to an existing state-gas cost parameter; it introduces neither a charging site nor a new state-gas mechanism.",
"score": 1,
"uncertainty_note": "The direction and amount of the adjustment cannot be tested until CPSB and the reference block gas limit are supplied.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Only CPSB changes; all EIP-8037 mechanisms and semantics remain unchanged."
},
{
"locator": "Specification / Transaction-level gas accounting (reservoir model)",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 already defines its state-gas refill behavior, including LIFO restoration when state creation is undone."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "A new EVM gas-refund mechanism is not introduced. Existing state-gas refill amounts may scale with CPSB, but their mechanism is unchanged.",
"score": 0,
"uncertainty_note": "The exact scaled refill amounts are unknown because CPSB is TBD.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "Existing CPSB-based behavior receives a new numerical value while all mechanisms and semantics remain fixed."
},
{
"locator": "Specification / Parameter changes",
"source": "supporting/eip-8037.md",
"summary": "CPSB appears in existing expected state-gas costs for CREATE, CREATE2, CALL, SELFDESTRUCT, SSTORE, and EOA delegation."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A localized subset of pre-existing gas tests must rebaseline CPSB-derived expected costs and out-of-gas points, but their test logic need not be redesigned.",
"score": 1,
"uncertainty_note": "The package does not quantify the replacement value or identify a test corpus, so the exact affected-test count cannot be established.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "The proposal changes a pre-existing parameter and explicitly preserves all other mechanisms and semantics."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Affected tests need different expected numbers, not an additional invariant or newly produced object to assert.",
"score": 0,
"uncertainty_note": "The absent CPSB value blocks numerical expectations but does not describe a new assertion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The only declared change is the existing CPSB protocol parameter; no transition-tool field or interface is specified."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The proposal requires no new transition-tool field or interface mechanism.",
"score": 0,
"uncertainty_note": "Tooling details are not discussed, but the stated scope supplies no interface payload that would require a new field.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "EIP-8368 is an existing-parameter recalibration with no new protocol mechanism or output type."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing gas-expectation and boundary-test primitives suffice for a numerical cost update.",
"score": 0,
"uncertainty_note": "No testing section is supplied, but no proposed behavior calls for a new framework abstraction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The scope is solely a state-byte gas-cost recalibration and contains no cryptographic mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic functionality is added or modified.",
"score": 0,
"uncertainty_note": "The missing parameter and rationale do not create a cryptography question.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The replacement CPSB value, which determines the amount charged per state byte, remains TBD."
},
{
"locator": "Specification / Parameter changes; Transaction-level gas accounting (reservoir model)",
"source": "supporting/eip-8037.md",
"summary": "CPSB-derived charges draw from the state reservoir and then gas_left, so their numerical value sets exact sufficiency and out-of-gas boundaries."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The recalibration shifts the existing exact-gas boundary for CPSB-sensitive state creation. This is one boundary-prone parameter change, not multiple new mechanisms.",
"score": 1,
"uncertainty_note": "Exact below-at-above boundary vectors cannot be derived until CPSB is fixed.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal changes only CPSB and introduces no block RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-encoding validation or syncing rule is changed.",
"score": 0,
"uncertainty_note": "No syncing surface is present in the declared scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal contains no Engine API field, endpoint, or communication mechanism and preserves EIP-8037 mechanisms."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced.",
"score": 0,
"uncertainty_note": "The placeholder omits the parameter value, not an Engine API design.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "EIP-8368 only recalibrates CPSB and does not introduce a contract or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "No added-contract surface appears in the proposal.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "CPSB changes while EIP-8037's mechanisms and semantics remain unchanged."
},
{
"locator": "Specification / System contracts and system transactions",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 derives the system-call gas limit and state-gas reservoir allocation from CPSB for existing per-block system calls."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Changing CPSB indirectly changes the derived gas allowance for existing system-contract calls, but it changes no system-contract code or state and leaves the call mechanism intact.",
"score": 1,
"uncertainty_note": "The evaluated system-call allowance cannot be calculated until CPSB is supplied, and EIP-8368 does not enumerate this derived consequence.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal declares only a CPSB value update and no new opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "The placeholder has no opcode-allocation question.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "EIP-8368 preserves all EIP-8037 mechanisms and semantics other than the CPSB parameter value."
},
{
"locator": "Specification / Parameter changes",
"source": "supporting/eip-8037.md",
"summary": "Several existing opcodes use CPSB-derived gas costs, but the target proposal changes only that gas parameter."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The rubric excludes gas-only changes from modified-opcode behavior, and no opcode result or non-gas behavior changes.",
"score": 0,
"uncertainty_note": "The unknown gas value affects opcode cost expectations, not this row's behavior criterion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "A CPSB parameter update is the entire declared change; no precompile is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "No precompile surface is present.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Only the state-byte cost parameter changes and all other EIP-8037 mechanisms and semantics remain fixed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile behavior or gas schedule is modified.",
"score": 0,
"uncertainty_note": "The missing CPSB value does not affect any stated precompile schedule.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "The proposal changes a gas parameter and specifies no transaction, block, or interface encoding change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface encoding is changed.",
"score": 0,
"uncertainty_note": "Encoding is outside the declared scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "EIP-8368 contains only a CPSB recalibration and defines no transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "The placeholder does not leave a transaction-type design open.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "EIP-8368 states that all EIP-8037 mechanisms and semantics other than CPSB remain unchanged."
},
{
"locator": "Specification / Transaction validation",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 places state-dependent charges at runtime and defines intrinsic gas as entirely execution-gas; CPSB is not a new validity-rule input."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The recalibration changes runtime state-gas amounts, not transaction validity rules or intrinsic-gas calculation.",
"score": 0,
"uncertainty_note": "Transactions may reach different runtime gas boundaries once CPSB is known, but that is not a validity-mechanism change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification",
"source": "eip.md",
"summary": "No block or header field is introduced by the CPSB value update."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The existing block/header structure is unchanged.",
"score": 0,
"uncertainty_note": "The unresolved numerical parameter does not imply a new field.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "The proposal describes a parameter update and inherited compatibility considerations, but no activation-block state transition or special internal-variable mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary activation of a revised protocol constant is not a new fork-activation mechanism; no fork-block-only modification is specified.",
"score": 0,
"uncertainty_note": "The placeholder does not specify activation details, so this assessment is limited to the absence of any special mechanism in the snapshot.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Motivation; Specification; Rationale",
"source": "eip.md",
"summary": "CPSB must be recalibrated because a higher block gas limit changes expected state growth, but the reference limit, value, and rationale are TBD."
},
{
"locator": "Rationale / Deriving the cost per state byte (CPSB)",
"source": "supporting/eip-8037.md",
"summary": "CPSB is derived from the reference gas limit, annual block count, average state-gas utilization, and a target annual state-growth rate."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The value cannot be validated in isolation from block utilization and resulting state growth, and it modifies existing resource-growth behavior. The change is nevertheless localized to one established parameter rather than a new interacting mechanism.",
"score": 2,
"uncertainty_note": "With no reference limit, CPSB, derivation, or rationale, the magnitude and benchmark impact cannot be determined and could support a different score.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Motivation; Security Considerations",
"source": "eip.md",
"summary": "The proposal aims to keep state growth on target as the block limit rises, while its security section is only 'Needs discussion.'"
},
{
"locator": "Security Considerations",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 identifies usability effects from state-creation pricing and resource-allocation concerns associated with its state-gas model."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Miscalibrating the common state-byte price can alter the resource assumptions across several state-creation paths and warrants targeted security and economic review, but EIP-8368 adds no new mechanism requiring an extensive multi-component redesign.",
"score": 2,
"uncertainty_note": "The target proposal supplies no security analysis and no value, so neither the direction nor materiality of its risks can be bounded from the package.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification; Rationale; Security Considerations",
"source": "eip.md",
"summary": "The proposal calls itself a placeholder and leaves the new reference block gas limit, CPSB value, rationale, and security discussion unresolved."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot baseline CPSB-derived gas results until the exact value is agreed. The missing decision is localized to an already observable gas parameter, so it does not meet the score-3 condition of making previously unobservable behavior consensus-critical.",
"score": 2,
"uncertainty_note": "The central consensus value is explicitly absent; the package gives no basis for choosing it.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter 'requires'; Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "EIP-8368 requires EIP-8037, modifies the CPSB parameter introduced there, and inherits its backwards-compatibility considerations."
},
{
"locator": "Specification / New parameters; Parameter changes",
"source": "supporting/eip-8037.md",
"summary": "EIP-8037 defines CPSB and applies it throughout its state-creation gas schedule."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
8037
],
"rationale": "EIP-8368 directly modifies EIP-8037's defining parameter, requiring coordinated expected-value testing, but the interaction is limited to that one parameter and one identified EIP.",
"score": 2,
"uncertainty_note": "The replacement value is missing, but the dependency and interaction scope are explicit.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8368,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8368:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The statement that all other parameters are unaffected is clear about formulas and semantics, but the proposal does not enumerate derived numerical values that necessarily change when CPSB changes.",
"'The same methodology as EIP-8037' does not state how an approximate derived ratio is converted into the final integer CPSB."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "5092c19d1dff03b1dc647ffff28653bf02eb224f4ad15ff9b42100b69d49b9c7",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8368.md",
"git_blob_sha": "7be62939881cce209a1a3948511ed9c65b433a37",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8368.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8368.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8368.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8368.yaml",
"sha256": "56984349a6fee16d9e338f79b84912c4f51812beb7db72dd92a7cea17fc675f2"
},
"supporting_documents": [
"supporting/eip-8037.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 12,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Execution-layer assessment of the Draft placeholder proposal to replace the CPSB value defined by EIP-8037 for a new, still-undetermined reference block gas limit. The snapshot explicitly leaves the reference limit, CPSB value, rationale, and security analysis unresolved while leaving EIP-8037's other parameters, mechanisms, and semantics unchanged.",
"tier": "medium",
"title": "CPSB Recalibration for New Gas Limit",
"under_specification": {
"affected_criteria": [
"state_gas_accounting_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"modified_system_contracts",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 15,
"minimum": 8
},
"present": true,
"summary": "EIP-8368 is explicitly a placeholder. It does not provide the new reference block gas limit, the re-derived CPSB integer, the calculation and rationale supporting that integer, or substantive security analysis. These omissions prevent exact gas vectors and quantitative performance or risk validation; they do not evidence any mechanism beyond the stated CPSB adjustment.",
"unresolved_questions": [
"What new reference block gas limit replaces the 150M reference?",
"What exact integer CPSB value results, including the intended rounding rule?",
"What derivation and empirical assumptions justify the selected value?",
"What security and economic effects follow from the selected magnitude?",
"Which CPSB-derived expected values, including the system-call gas allowance, are intended to be explicitly rebaselined?"
]
}
},
"hegota:8372:human:r2": {
"checklist": {
"invalid_score_rows": [],
"missing_rows": [],
"parser_notes": [],
"published_tier": "medium",
"published_total": 20,
"recomputed_tier": "medium",
"recomputed_total": 20,
"unresolved_blank_rows": []
},
"confidence": null,
"criteria": [
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The block-level rule changes: raw state gas answers to a scaled limit and is normalized before `gas_used = max(execution, normalized state)`. Measured: an EELS prototype (proportional contraction, `CPSB` 765 / scale 50) flips 796 fixture executions across the EIP-8037/7778/2780/8038 gas suites and the ported statics.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The block-level state-gas budget is modified (scaled to a share of the block gas limit) and `CPSB` recalibrates with it; the spill path and charging sites are untouched.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Measured: 796 executions across 155 functions spanning diverse categories — EIP-8037 header pins, capacity-bound scenarios, the 2780/7778/8038 gas suites, and 1530-era ported statics. Sixteen shared header sites were updated fork-correctly; the remainder re-derives when the real calibration constants are chosen, and the whole set re-baselines on every recalibration.",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing primitives extend: `block_state_gas_limit()` / `normalized_block_state_gas()` fork accessors (identity pre-EIP), and the framework's implicit transaction gas limit learns the scaled capacity bound.",
"raw_score_cell": "1",
"score": 1,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The scaled-capacity admission boundary, integer normalization rounding, and the dominant-dimension switchover are each boundary-prone, and the switchover needs an elevated case count: the `max(execution, normalized)` crossover must be pinned at equality and one raw unit either side, non-divisor scales collapse rounding ranges of raw values into one normalized value, mid-transaction reservoir-to-spill crossings move with the grant, and each boundary is observed twice (raw receipts, normalized header).",
"raw_score_cell": "3",
"score": 3,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "With a scale below 100, the EIP-8037 admission rule (`tx.gas <= state_gas_available`) silently caps every transaction's gas limit at the scaled share of the block gas limit — an unstated consequence, and the dominant blast-radius mechanism until tooling learns the bound (31,873 fixture executions in the prototype's first fill). Existing validity tests need limited, mechanical updates.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": null,
"raw_score_cell": "0",
"score": 0,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The arithmetic lands in a consensus observable: header `gas_used` is recomputed through the normalization fold, so a rounding or crossover divergence between clients is a chain split, warranting targeted review and fuzzing across the boundary ranges. Parameter miscalibration remains the economic failure mode, fixable only by a later fork — flagged by the EIP itself.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Two consensus-relevant behaviors are unstated in the EIP but localized: the sub-100-scale admission cap (needs the comparison re-anchored or the ceiling stated) and receipt gas totals staying raw while the header normalizes. Clients need agreement on both before vectors are baselined; the TBD constants are churn already counted under patterns.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
},
{
"blank_interpretation": null,
"confidence": null,
"evidence": [],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"rationale": "A delta on EIP-8037's block accounting, interacting with EIP-7825 (the admission-cap consequence, measured) and EIP-7778's block-accounting suites — limited, mechanical coordination.",
"raw_score_cell": "2",
"score": 2,
"uncertainty_note": null,
"under_specified": false
}
],
"eip": 8372,
"fork": "hegota",
"id": "hegota:8372:human:r2",
"mode": "prospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": null,
"assessor": {
"kind": "human",
"organization": "STEEL team",
"publication": "ethspecs/pm complexity_assessments"
},
"research_record": {
"path": "research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8372.yaml",
"sha256": "ac8d9777bb094fd93bd3b24a00bc0968c9783233f29e8527e355055de8104332"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"commit": "bcbc0c2a77e6866575f99aeb59889f52ae83361b",
"content_sha256": "163ca5d2a25abf1ed59783f3bde543d0f638b48ffeaba64c8761feadcfec8670",
"git_blob_sha": "c8fd40e285614b701e788be2f9a2f7e7208f2eaa",
"immutable_url": "https://github.com/ethspecs/pm/blob/bcbc0c2a77e6866575f99aeb59889f52ae83361b/complexity_assessments/EIPs/EIP-8372.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8372.md",
"pull_request": {
"draft": true,
"number": 110,
"title": "Add EIP-8372 complexity assessment",
"updated_at": "2026-08-24T17:03:24Z",
"url": "https://github.com/ethspecs/pm/pull/110"
},
"repository": "ethspecs/pm"
},
"supporting_documents": []
},
"role": "published_checklist",
"rubric_revision": 2,
"score": 20,
"scored": true,
"source": "human",
"status": "in_progress",
"summary": null,
"tier": "medium",
"title": "Normalized state gas limit",
"under_specification": null
},
"hegota:8372:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Replaces EIP-8037's block-level gas_used calculation with the maximum of execution gas and normalized raw state gas, with two associated validity checks."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "An existing gas-accounting mechanism is updated at block level. The change does not introduce another EVM transaction gas pool or replace the inherited reservoir mechanism, so the score matches an update rather than a new general EVM gas mechanism.",
"score": 1,
"uncertainty_note": "This row treats the block-level gas_used rule as EVM gas accounting while leaving the state-specific budget and normalization impact to the dedicated state-gas row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "States that the EIP-8037 reservoir model and transaction-level gas accounting remain unchanged; the stated changes concern post-activation constants, block limits, and normalized block accounting."
},
{
"locator": "Specification > Pre-state and post-state gas validation",
"source": "supporting/eip-8037.md",
"summary": "The inherited proposal defines where opcode-level state gas is charged; EIP-8372 supplies no replacement for those ordering rules."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's state access, gas-charge position relative to access, or definition of a recordable access is changed.",
"score": 0,
"uncertainty_note": "The new pre-transaction state-gas availability arithmetic does not move an access or charge within opcode execution.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "Defines the proposal solely as scaling and normalizing EIP-8037 state gas and explicitly introduces no transaction or block-header fields."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas counter, price, target, limit, or accounting rule is modified.",
"score": 0,
"uncertainty_note": "Blob accounting is outside the mechanisms specified by this proposal.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction validation",
"source": "eip.md",
"summary": "Scales the raw state-gas block limit relative to block_gas_limit and uses that scaled budget to compute state_gas_available."
},
{
"locator": "Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Normalizes raw block state-gas usage before the max comparison while retaining the raw state-gas counter and enforcing both raw and normalized limits."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The block-level state-gas budget is modified and a normalization is added. This is the rubric's score-2 case. The transaction reservoir and its spill path into execution gas are expressly retained, so score 3 is not warranted.",
"score": 2,
"uncertainty_note": "The exact numeric budget is unavailable because CPSB and STATE_GAS_LIMIT_SCALE are still TBD, but the kind of mechanism is clear.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Says transaction-level gas accounting, the EIP-8037 reservoir model, and receipt semantics remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal adds no refund or refill mechanism and does not modify the inherited refund rules.",
"score": 0,
"uncertainty_note": "Normalization is applied to block state-gas usage after inherited transaction accounting; it is not a gas refund.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Warns that non-implementing clients may disagree on transaction inclusion, block validity, or header gas_used and requires builders, clients, and estimators to adopt the new rules."
},
{
"locator": "Specification > Transaction validation; Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Changes both the state-gas availability calculation and expected block-level gas_used/validity outcomes."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A considerable but focused category of pre-existing EIP-8037 state-gas and block-validation tests must be reworked for the scaled budget and normalized gas_used. The impact is not a major, diverse rewrite across unrelated test categories.",
"score": 2,
"uncertainty_note": "The package contains no test inventory, so the breadth is inferred only from the specified consensus surfaces and backwards-compatibility statement.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Adds no output field; instead it changes how the existing gas_used value and existing state-gas limit validation are computed."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing affected tests must change expected values and validity outcomes, rather than mechanically add an assertion for a newly produced artifact to otherwise unchanged tests.",
"score": 0,
"uncertainty_note": "Implementations may expose intermediate normalized values for convenience, but the sealed proposal does not require tests to assert such an output.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "Introduces no transaction or header fields and retains transaction-level accounting and receipt semantics."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The transition behavior changes, but the proposal specifies no new field or mechanism that must cross the transition-tool interface.",
"score": 0,
"uncertainty_note": "Fork configuration must carry the selected constants in an implementation, but the package does not specify that as a transition-tool interface field.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Expresses the complete change as integer arithmetic over existing block environment/output counters and existing gas_used."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Ordinary transaction, block, gas-used, and validity expectations suffice; no new expectation type, modifier, or reusable framework primitive is required by the text.",
"score": 0,
"uncertainty_note": "The package provides no framework implementation, so this conclusion is limited to the specified inputs and outputs.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative changes consist only of positive integer parameters, multiplication, division, subtraction, comparison, and max operations."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic primitive, algorithm, proof, signature, hash, or associated validation behavior is introduced or modified.",
"score": 0,
"uncertainty_note": "The calibration method is economic arithmetic, not cryptography.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction validation; Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Uses floor division in both the scaled raw limit and inverse normalization, combines equality limits for raw and normalized counters, and selects the maximum of execution and normalized state gas."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Notes that proportional scaling preserves maximum state-byte capacity only approximately because of integer rounding."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Tests need multiple boundary families: floor-division remainders, exact-limit and one-over-limit raw state gas, exact normalized block limit, and the execution/state max crossover. Their interaction requires an elevated set of cases rather than isolated single boundaries.",
"score": 3,
"uncertainty_note": "Exact remainder locations cannot be instantiated until the two TBD constants are selected.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Explicitly adds no block-header field and changes the validity semantics of the existing gas_used field without changing its encoding."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation or encoding mechanism is introduced, so the rubric's syncing-specific anchor is not triggered.",
"score": 0,
"uncertainty_note": "Historical/block execution validation changes are scored elsewhere; they are not RLP changes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract",
"source": "eip.md",
"summary": "States that no new transaction or block-header fields are introduced, and the specification contains no Engine API directive or communication rule."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API endpoint, field, or communication mechanism is added or modified.",
"score": 0,
"uncertainty_note": "Builder behavior must reflect the new validity rules, but no Engine API transport change is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "The normative scope is limited to parameters, state-gas availability, and block gas accounting, with no contract deployment or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "Existing system-call implications of changing CPSB are considered under the modified-system-contract row.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification > Parameters",
"source": "eip.md",
"summary": "Replaces EIP-8037's CPSB with a new, currently TBD value."
},
{
"locator": "Specification > System contracts and system transactions",
"source": "supporting/eip-8037.md",
"summary": "Defines every inherited system call's gas limit and state-gas reservoir allocation using CPSB while leaving system calls outside block gas counters."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No system contract code or state is changed, but the CPSB update indirectly changes the gas allowance/reservoir formula for existing system calls. This is a minor indirect effect.",
"score": 1,
"uncertainty_note": "The magnitude is unknown until CPSB is selected, and EIP-8372 does not separately discuss system-call calibration.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Specifies only parameter and block/transaction accounting formula changes; no opcode table entry or instruction is added."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "The proposal reuses state-gas production defined by EIP-8037.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Retains the EIP-8037 reservoir and transaction-level gas accounting and describes the incompatibility as gas cost, inclusion, and block accounting changes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No opcode result or non-gas behavior is changed. Any effect of the new CPSB on state-creating opcodes is a gas change, which this anchor explicitly excludes.",
"score": 0,
"uncertainty_note": "Opcode-level state-gas sites remain those inherited from EIP-8037.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Contains no precompile address, input/output definition, or precompile gas rule."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None within the sealed proposal scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification",
"source": "eip.md",
"summary": "Limits all normative changes to state-gas parameters and block accounting, without identifying any precompile behavior or schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "The general block gas accounting applies to transactions that may call precompiles, but it does not modify a precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "Explicitly introduces no transaction or block-header fields and retains transaction formats and receipt semantics."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, header, receipt, or interface encoding is changed.",
"score": 0,
"uncertainty_note": "The meaning of existing header gas_used changes, not its encoding.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Backwards Compatibility",
"source": "eip.md",
"summary": "Explicitly adds no transaction field and says transaction formats remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "All existing transaction types are processed under the inherited EIP-8037 transaction model.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Transaction validation",
"source": "eip.md",
"summary": "Changes state_gas_available for transaction inclusion from the ordinary block gas limit to a separately scaled raw state-gas limit."
},
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "States that non-implementing clients may disagree on transaction inclusion after activation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction types receive a changed inclusion-validity check that affects existing state-gas cases. Updates are limited to expected arithmetic and boundary cases and require no transaction format or testing-infrastructure redesign, matching score 2.",
"score": 2,
"uncertainty_note": "This score treats the proposal's explicitly named pre-inclusion transaction validation as a validity mechanism; intrinsic gas itself is unchanged.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract; Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Explicitly says no new block-header field is introduced and continues to use the existing gas_used field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is added.",
"score": 0,
"uncertainty_note": "Raw and normalized state-gas values remain internal accounting values.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation; Rationale > Calibration methodology",
"source": "eip.md",
"summary": "Describes a one-time pre-activation selection of fixed constants that remain fixed after activation, rather than an activation-block state or internal-variable transition."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation selects protocol constants and begins applying new rules; it does not modify state or an existing internal variable at the activation block.",
"score": 0,
"uncertainty_note": "The constants are still TBD, but initializing or selecting constants is not the modification scored by this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation",
"source": "eip.md",
"summary": "Intends to let state gas and execution gas both approach their targets by changing which resource becomes the block bottleneck."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Requires stress-testing selected parameters across plausible demand elasticities and notes only approximate capacity invariance under rounding."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The arithmetic itself is isolated, but its workload impact depends on mixed block execution/state demand and therefore cannot be fully benchmarked in isolation. The existing benchmark impact is limited by proportional CPSB and state-limit scaling intended to preserve maximum byte capacity.",
"score": 2,
"uncertainty_note": "Missing parameter values prevent quantifying whether the selected calibration is contractionary or expansionary in raw state gas and realized mixed-block load.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility",
"source": "eip.md",
"summary": "Identifies consensus disagreement risks in transaction inclusion, block validity, and header gas_used if the rule is not implemented consistently."
},
{
"locator": "Security Considerations",
"source": "eip.md",
"summary": "Identifies parameter miscalibration as the primary risk, able to move the system between utilization failure modes and correctable only by another hardfork."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches a limited set of critical accounting and validation components and changes their invariants, requiring targeted review, boundary testing, and fuzzing. It does not introduce the broad multi-component security redesign required for score 3.",
"score": 2,
"uncertainty_note": "Risk magnitude cannot be fully assessed while both calibrated constants are TBD.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification > Parameters",
"source": "eip.md",
"summary": "Leaves both consensus constants CPSB and STATE_GAS_LIMIT_SCALE as TBD while only fixing the denominator and requiring positive integers."
},
{
"locator": "Specification > Transaction validation; Specification > Block-level gas accounting",
"source": "eip.md",
"summary": "Uses the missing constants in every new availability, normalization, and validity formula."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot baseline concrete consensus vectors until the two localized parameters are agreed. The formulas otherwise determine behavior, so this is localized agreement rather than newly observable unspecified semantics requiring repeated broad re-baselining.",
"score": 2,
"uncertainty_note": "The package contains no final values or normative constraint tying the two selected constants beyond positivity; the proportional relation appears in rationale/calibration methodology.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter; Abstract",
"source": "eip.md",
"summary": "Formally requires EIP-8037 and directly modifies its state-gas limit and block-level gas accounting."
},
{
"locator": "Rationale > Calibration methodology",
"source": "eip.md",
"summary": "Describes EIP-8075 as a dynamic analogue and EIP-7999 as a longer-term direction, rather than making either part of this proposal's fixed rules."
},
{
"locator": "Specification > Multidimensional metering for state creation costs; Specification > Block-level gas accounting",
"source": "supporting/eip-8037.md",
"summary": "Supplies the two-dimensional reservoir and raw block counters whose limits and final max computation EIP-8372 changes."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
8037
],
"rationale": "EIP-8372 depends on and modifies EIP-8037, so coordinated state-gas and block accounting tests are required. The interaction is deep but limited to one directly required EIP. EIPs 7999 and 8075 are contextual alternatives or analogues in the sealed text and are not counted as co-implemented interactions.",
"score": 2,
"uncertainty_note": "The assessment counts EIP-8037 as the direct interaction and does not separately multiply all of EIP-8037's inherited dependencies, whose rules EIP-8372 says remain unchanged.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 8372,
"evaluation_date": "2026-08-26",
"fork": "hegota",
"id": "hegota:8372:llm:r2",
"mode": "prospective",
"notable_ambiguities": [
"The normative parameter table leaves CPSB and STATE_GAS_LIMIT_SCALE TBD; a client cannot compute state_gas_available, normalized state gas, or gas_used for concrete post-activation blocks without them.",
"The calibration rationale defines STATE_GAS_LIMIT_SCALE from CPSB and a baseline, but the normative specification states only that the two parameters are positive integers and does not state the proportional relation as a constraint.",
"Integer division is fully specified, but the exact raw-limit and inverse- normalization rounding discontinuities depend on the missing scale."
],
"provenance": {
"assessed_revision": {
"commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"committed_at": "2026-08-25T11:56:58Z",
"content_sha256": "db7eae2b26e156041353154d196c5d6373f4b176e42ca4f76129d9f7603a5515",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-8372.md",
"git_blob_sha": "d5bd301b8036a5a9ca6bf5b65f723815c9f3c74e",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ac450a4ab2f37387385ee9c54b62f518d97e6cc9/EIPS/eip-8372.md",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"path": "EIPS/eip-8372.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-8372.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8372.yaml",
"sha256": "77b31821d04c76d592874631d5744e759a851cec67ca9f78b28f246e44a3a7a3"
},
"supporting_documents": [
"supporting/eip-7999.md",
"supporting/eip-8037.md",
"supporting/eip-8075.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 19,
"scored": true,
"snapshot_id": "hegota-pfi-2026-08-26-ac450a4",
"snapshot_status": "PFI",
"source": "llm",
"status": "complete",
"summary": "Draft execution-layer assessment of EIP-8372 as sealed in the Hegotá PFI snapshot. The proposal modifies EIP-8037 by selecting a new cost per state byte, scaling the raw block state-gas limit, and normalizing raw state-gas usage before comparing it with execution-gas usage for the existing header gas_used value. Transaction formats, block-header fields, the transaction reservoir, transaction-level accounting, and receipt semantics remain unchanged.",
"tier": "medium",
"title": "Normalized state gas limit",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 21,
"minimum": 18
},
"present": true,
"summary": "The state-gas price and raw-limit scale are both normative consensus inputs to every changed formula but remain TBD. The algorithms are specified, so the gap is localized, yet concrete validity vectors, rounding boundaries, workload magnitude, and calibration risk cannot be finalized. The rationale gives a proportional selection formula, but the normative parameter section requires only that both values be positive integers.",
"unresolved_questions": [
"What final positive integer value is selected for CPSB?",
"What final positive integer value is selected for STATE_GAS_LIMIT_SCALE?",
"Are the selected constants normatively required to preserve the proportional CPSB-to-limit-scale relation described in the calibration rationale?",
"What exact rounding-boundary vectors result from the final constants, and what mixed execution/state workloads are used to stress-test the calibration?"
]
}
},
"osaka:7594:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The specified changes concern erasure-coded blob columns, custody, sampling, and reconstruction; no EVM gas rule is introduced or changed."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "PeerDAS operates on consensus data availability and peer networking. It does not alter normal EVM gas accounting, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The proposal specifies column construction, custody, peer sampling, and reconstruction without specifying opcode execution or state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode gains or reorders a state access or gas charge, so there is no consensus-visible state-access ordering change under this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "EIP-7594 extends the data representation and availability protocol for EIP-4844 blobs but states no fee, gas-per-blob, target, or limit change."
},
{
"locator": "Gas accounting, lines 164-186",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already defines independent blob gas, its base-fee computation, and fee deduction; EIP-7594 supplies no modification to these rules."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal changes how blob data is distributed and checked, not how blob gas is calculated or charged. The existing mechanism is unchanged.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The complete high-level specification contains only blob data-extension and peer-availability mechanisms and introduces no state writes or state gas budget."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas charging site, rate, budget, reservoir, or execution-gas spill rule is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The proposal defines networking and data-availability behavior and no EVM fee-refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Consensus layer validation, lines 228-243",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844's existing consensus path requires blob availability, blob sidecar gossip and sync, and validator production of sidecars."
},
{
"locator": "A note on fork choice, lines 269-279",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "PeerDAS is intended to replace the Deneb is_data_available full-download call with column sampling and a new availability filter."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing EIP-4844 consensus tests for sidecar propagation, availability, and fork-choice behavior must be substantially reworked around columns and samples. This is a considerable but feature-bounded category, matching 2.",
"score": 2,
"uncertainty_note": "The packaged work-in-progress does not enumerate the exact pre-existing test inventory, so the boundary between a minor and considerable subset is judgmental.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "DataColumnSidecar, lines 86-98",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "The new sidecar binds a column and per-blob KZG proofs to commitments and a signed block header with an inclusion proof."
},
{
"locator": "Consensus layer validation, lines 228-243",
"source": "supporting/eip-4844.md",
"summary": "Pre-existing blob-aware consensus tests already check block-associated data availability and sidecar behavior."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The narrow category of existing blob-availability tests gains additional assertions that sampled columns, proofs, commitments, and headers agree. The requirement is not universal across fork tests, matching score 1.",
"score": 1,
"uncertainty_note": "Some affected tests may be wholly rewritten rather than retain their logic and add assertions, making a zero score also plausible.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-32",
"source": "eip.md",
"summary": "The EIP defines a beacon-node networking protocol and no execution state transition inputs or outputs."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Nothing in the specified change requires a field or mechanism in an execution transition-tool interface.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Helper functions, lines 100-196",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "The specification introduces deterministic custody selection, extended matrix computation and recovery, and construction of 128 column sidecars."
},
{
"locator": "Peer sampling through reconstruction, lines 239-259",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Tests must exercise per-slot peer queries, response failures, recovery, request fallback, and cross-seeding behavior."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Repeatable tests require new reusable fixtures and expectations for column generation/proofs, peer custody, sampling responses, and reconstruction. These are substantial primitives reusable within PeerDAS's own suite, but the package does not establish permanent cross-EIP framework adoption.",
"score": 2,
"uncertainty_note": "No test-framework design or test cases are supplied, so some cryptographic fixtures might instead be implemented as ordinary test-local helpers.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 24-30",
"source": "eip.md",
"summary": "PeerDAS adds one-dimensional erasure coding, divides extended blobs into cells, and authenticates those cells against blob KZG commitments."
},
{
"locator": "Extended-matrix and sidecar helpers, lines 131-196",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "The design invokes cell computation, per-cell KZG-proof construction, row recovery, and packaging proofs for every column sidecar."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "This materially extends the existing EIP-4844 KZG use to erasure-coded cells, proof generation, and recovery. As a single novel or limited-resource cryptographic construction at this work-in-progress stage, it matches 2.",
"score": 2,
"uncertainty_note": "The sealed document invokes but does not define the underlying cell-proof algorithms, leaving judgment over whether this is one modified mechanism or multiple mechanisms.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "get_custody_columns, lines 102-129",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Custody selection includes a maximum node-ID wrap, a custody-count bound, duplicate avoidance, subnet-to-column expansion, and deterministic order."
},
{
"locator": "Peer sampling and reconstruction, lines 239-259",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Sampling success, missing responses, the 50-percent reconstruction threshold, fallback requests, timing, and message aggregation all create boundary-sensitive behavior."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple mechanisms have boundaries, and reconstruction/sampling combines column counts, peer distributions, timeouts, failures, proof validity, and blob counts into an elevated test matrix. This meets score 3.",
"score": 3,
"uncertainty_note": "Exact timeout and message-aggregation boundaries are expressly unresolved, but their absence increases rather than removes the boundary-testing need.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Metadata and Specification, lines 7-11 and 24-32",
"source": "eip.md",
"summary": "The EIP is categorized as Networking and specifies column sidecars and sampling, not a block RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Although peer data transfer changes, the anchor is specifically for block RLP validation requiring syncing; no such mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-32",
"source": "eip.md",
"summary": "The proposal specifies beacon-node data-availability networking and no Engine API endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API directive changes are stated, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The specified design consists of off-EVM data coding, custody, gossip, peer requests, sampling, and reconstruction."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The PeerDAS mechanisms do not reference or change any system contract's code, state, or behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or indirect modification to a pre-existing system contract is specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "EIP-7594 defines only blob data-availability and peer-network mechanisms, with no EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The proposal does not specify EVM execution behavior or alter an existing instruction."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "Cell authentication and erasure coding are consensus-side PeerDAS operations; no EVM precompile address or callable interface is added."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The new cryptographic processing is not exposed as a new precompile.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Point evaluation precompile, lines 195-226",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already defines the point-evaluation precompile and its fixed behavior and cost."
},
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "EIP-7594 uses blob KZG commitments for cells but states no change to the EIP-4844 point-evaluation precompile."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "PeerDAS's consensus-side cell proofs do not modify precompile logic or gas.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Custom types and DataColumnSidecar, lines 54-98",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "The specification adds SSZ-equivalent DataColumn and ExtendedMatrix types and a DataColumnSidecar container carrying cells, proofs, commitments, a signed header, and an inclusion proof."
},
{
"locator": "Column gossip and peer sampling, lines 231-245",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "The new sidecars are exchanged on column gossip subnets and through a DataColumnSidecarsByRoot request interface."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "A new SSZ container and data types cross gossip and request/response interfaces, which is an interface-level encoding change. The rubric assigns a binary score of 3 when such a change is introduced.",
"score": 3,
"uncertainty_note": "The anchor's examples emphasize transaction, block, and Engine interfaces; this assessment treats the explicitly encoded consensus P2P interfaces as interfaces within its stated scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Metadata and Specification, lines 7-11 and 24-32",
"source": "eip.md",
"summary": "EIP-7594 requires EIP-4844 and extends its blobs, but does not define an additional transaction envelope or type number."
},
{
"locator": "Blob transaction, lines 97-117",
"source": "supporting/eip-4844.md",
"summary": "The blob transaction type is an existing EIP-4844 mechanism on which PeerDAS builds."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The dependency's blob transaction is not newly introduced by EIP-7594, so this criterion scores 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution layer validation, lines 244-289",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already defines blob-transaction fee, hash-version, count, and block blob-gas validity checks."
},
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "PeerDAS changes availability distribution and sampling but adds no transaction validity or intrinsic-gas rule."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The proposal does not modify the validity of an existing transaction type.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension, lines 119-162",
"source": "supporting/eip-4844.md",
"summary": "Blob gas fields are pre-existing EIP-4844 header extensions."
},
{
"locator": "DataColumnSidecar, lines 86-98",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "PeerDAS references an existing signed block header from a separate sidecar container and does not add a field to the header itself."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "New sidecar fields are not new block or header fields, so the binary anchor remains 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-32",
"source": "eip.md",
"summary": "The proposal states ongoing PeerDAS behavior but no activation-block state change or modification of an existing internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No fork-activation transition mechanism is specified. New constants and data types do not constitute modification under the anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Configuration, lines 63-85",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "The design fixes 128 columns, up to 768 cells, 32 gossip subnets, eight samples per slot, and a target of 70 peers."
},
{
"locator": "Sidecar construction, lines 167-196",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "For every block, clients compute cells and KZG proofs and construct a sidecar for every column across all blobs."
},
{
"locator": "Discovery through DAS providers, lines 215-267",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Runtime behavior couples peer discovery, gossip, per-slot requests, scoring, reconstruction, cross-seeding, and optional high-capacity peers."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "CPU, memory, bandwidth, latency, peer topology, and reconstruction load interact in live per-slot operation. These mechanisms cannot be fully benchmarked in isolation and substantially alter existing blob propagation performance, meeting score 3.",
"score": 3,
"uncertainty_note": "Timing and aggregation choices are unresolved, so exact benchmark cases are uncertain even though the need for system-level performance validation is clear.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Custody and peer discovery, lines 199-225",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Availability relies on public deterministic custody, advertised capacity, diverse peers, and discovery defenses against attack and centralization."
},
{
"locator": "Peer sampling through fork choice, lines 239-279",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Peer responsiveness, reconstruction, cross-seeding, and sample timing feed a data-availability filter whose choices affect reorgs and finality."
},
{
"locator": "Security Considerations, lines 46-48",
"source": "eip.md",
"summary": "The EIP's own security analysis is still marked as needing discussion."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect sampling, custody, discovery, proof, or fork-choice behavior can cause unavailable data to be accepted or available blocks to be rejected. The design changes assumptions across networking, cryptography, validators, and fork choice, requiring extensive review and adversarial testing.",
"score": 3,
"uncertainty_note": "The absent security analysis leaves attack parameters and mitigations unresolved, but the cross-component critical-chain exposure supports 3.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Reconstruction and cross-seeding, lines 247-259",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "The document leaves open when samples count as missing and whether sample messages are individual or aggregated, with anti-DoS and QoS unresolved."
},
{
"locator": "A note on fork choice, lines 269-279",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Fork choice is explicitly TBD, including sampling follow distance, timing, short-reorg acceptability, and confirmation effects."
},
{
"locator": "Subnet stability, lines 294-296",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md",
"summary": "Subnet rotation relative to the pruning period is identified as likely necessary but is not specified."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously local network observations such as sample success and timing are intended to determine consensus fork-choice eligibility. Because the WIP leaves those outcomes open, clients need repeated agreement and test re-baselining, matching score 3.",
"score": 3,
"uncertainty_note": "The package contains no implementation or devnet evidence, as required by the hindsight firewall; the score rests on explicit WIP and TBD passages.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Metadata, Motivation, and Specification, lines 11 and 18-32",
"source": "eip.md",
"summary": "EIP-7594 explicitly requires EIP-4844, extends its blobs and commitments, and changes how their availability is established."
},
{
"locator": "Consensus layer validation, lines 228-236",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844's sidecar design deliberately isolates is_data_available so that full download can later be replaced by data-availability sampling."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
4844
],
"rationale": "EIP-7594 has one strong dependency, EIP-4844, and coordinated tests must cover the changed blob sidecar, commitment, and availability path. That is a substantive but limited-scope interaction, matching score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
}
],
"eip": 7594,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7594:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The rubric's encoding anchor expressly includes interfaces; this assessment treats the new SSZ DataColumnSidecar on consensus gossip and request/response interfaces as an interface-level encoding change.",
"The work-in-progress does not distinguish which existing blob-availability tests are rewritten versus which retain their logic and gain new assertions.",
"The specification supplies reusable protocol helpers but no test design, so the score for new test-framework primitives depends on the unavoidable need to model multi-peer sampling and failure behavior."
],
"provenance": {
"assessed_revision": {
"commit": "4353b530c3701b22d7d2b46f940d8b6608d7aa8a",
"committed_at": "2024-06-17T16:19:19Z",
"content_sha256": "bf2501c16c94716b9d5c1bf1132792a0a39bb1417c89619458c79f8e9280913b",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7594.md",
"git_blob_sha": "3d9747d143e6886ba45d3b9a4d5f1a3a5f96449f",
"immutable_url": "https://github.com/ethereum/EIPs/blob/4353b530c3701b22d7d2b46f940d8b6608d7aa8a/EIPS/eip-7594.md",
"information_cutoff_at": "2024-09-27T18:42:32Z",
"path": "EIPS/eip-7594.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7594.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7594.yaml",
"sha256": "381fe4f9d8896e19ece7de2424ae2befa081042c5c387badcfdc11a068a85616"
},
"supporting_documents": [
"supporting/eip-4844.md",
"supporting/ethereum-consensus-specs--specs-_features-eip7594-das-core.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 24,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7594 proposed replacing universal blob-data download with PeerDAS, a consensus-networking protocol built on EIP-4844. It extended blobs into an erasure-coded column matrix, authenticated cells against blob KZG commitments, and assigned deterministic column custody to nodes. Nodes would discover diverse peers, gossip and request columns, sample availability each slot, and reconstruct data from at least half of the columns, while the precise fork-choice integration remained unfinished.",
"tier": "high",
"title": "PeerDAS - Peer Data Availability Sampling",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"new_test_framework_primitives",
"cryptography",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 24,
"minimum": 20
},
"present": true,
"summary": "Material consensus behavior remains unresolved: the fork-choice data- availability filter, sampling follow distance and timing, missing-sample thresholds, short-reorg treatment, request/message aggregation, anti-DoS and QoS rules, and subnet rotation are not fixed. These gaps chiefly affect how clients produce common outcomes and how regression and network tests must be structured; they are not repaired from later knowledge.",
"unresolved_questions": [
"At what slot or follow distance must successful sampling gate fork-choice eligibility, and how are temporary sampling failures and short reorgs treated?",
"When is a sample deemed missing, and when must a node request, reconstruct, or cross-seed a column?",
"Are samples requested and propagated individually or in aggregates, and what anti-DoS, rate-limit, and QoS rules are consensus-testable?",
"How and when do deterministic custody subnets rotate relative to the data pruning period?",
"Which new fixtures or expectations belong in the shared test framework as opposed to PeerDAS-local test helpers?"
]
}
},
"osaka:7642:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The specification changes only eth protocol message fields, and the EIP expressly states that it does not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Neither EVM execution nor any gas-accounting rule is changed, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64",
"source": "eip.md",
"summary": "The only specified operations remove fields from the Status and Receipts wire messages and reconstruct receipt blooms from logs."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode execution or ordering between a state access and a gas charge is modified, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The proposal is limited to networking-message encodings and disclaims an EVM consensus change."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas mechanism or value is introduced or updated, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The specified changes concern two eth wire messages and do not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal neither charges for state writes nor alters a state-gas budget, rate, reservoir, or spill path, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The EIP specifies only wire-message field removal and states that EVM consensus rules do not change."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM gas-refund mechanism is introduced, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 34-64",
"source": "eip.md",
"summary": "eth/69 changes the established field layouts of Status and Receipts, including both legacy and typed receipt encodings."
},
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The changed wire format is isolated behind a new protocol version while older clients may continue using eth/68."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing protocol tests for the two affected messages must use the eth/69 layouts, but this is a minor, narrow subset rather than a considerable or diverse share of pre-existing tests, matching score 1.",
"score": 1,
"uncertainty_note": "The package does not describe the breadth or organization of the existing networking test corpus.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 34-64",
"source": "eip.md",
"summary": "The proposal replaces the expected layouts of two versioned messages; it does not specify an additional result that unrelated tests must assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests of the affected message formats change their expectations, but pre-existing tests outside that scope gain no new invariant, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "No test-suite structure is included, but the EIP states no cross-cutting assertion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The EIP changes a versioned wire protocol, makes no EVM consensus change, and requires no hard fork."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A state-transition tool has no new field or mechanism to expose, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 34-64",
"source": "eip.md",
"summary": "The change consists of explicit old and new message schemas plus a deterministic bloom reconstruction from receipt logs."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The text gives no need for a new reusable expectation, modifier, or framework abstraction beyond ordinary encoding and decoding test cases, so existing primitives reasonably suffice.",
"score": 0,
"uncertainty_note": "The historical test framework is not part of the sealed package.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-18; Specification, lines 32-64",
"source": "eip.md",
"summary": "The proposal removes two networking fields and derives an existing bloom value from receipt logs; it introduces no cryptographic primitive."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is added or modified, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 34-64",
"source": "eip.md",
"summary": "Two message layouts change at the eth/68-to-eth/69 boundary, and receipt handling spans both legacy and typed forms while deriving blooms from possibly varying log lists."
},
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "Nodes may support both wire-protocol versions, creating a negotiated version boundary without a hard-fork boundary."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "There are multiple boundary-prone mechanisms: version-specific Status field counts and version- plus receipt-form-specific Receipts decoding and bloom reconstruction. None is shown to demand an elevated case explosion, so score 2 is the best-fitting anchor.",
"score": 2,
"uncertainty_note": "Malformed and mixed-version message handling is not specified, so the exact number of negative boundary cases is uncertain.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 22-27; Specification, lines 40-64",
"source": "eip.md",
"summary": "The EIP reduces data sent during sync by changing receipt-message encoding; it does not modify block RLP or block-validation encoding."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Although the Receipts message is used in syncing, the anchor specifically concerns block RLP validation. No such validation mechanism is introduced, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64",
"source": "eip.md",
"summary": "All changes are to the peer-to-peer eth Status and Receipts messages."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API endpoint, field, or communication mechanism is added or modified, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The proposal changes only wire-message fields and does not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The proposal is confined to eth wire-message representations and has no EVM consensus effect."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system contract code, state, or behavior is directly or indirectly modified, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The EIP is a wire-protocol version change and expressly leaves EVM consensus rules unchanged."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The proposal changes the eth protocol but not EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode behavior is modified or deprecated, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The specified scope is two networking messages with no EVM consensus change."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The proposal changes networking encodings only and leaves EVM consensus rules unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-64",
"source": "eip.md",
"summary": "eth/69 removes td from the Status field sequence and bloom from the receipt-data sequence used for both legacy and typed Receipts payloads."
},
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "The altered interface is deployed as a new eth wire-protocol version."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The ordered encoding of two peer interface messages changes. The rubric's binary encoding-change anchor assigns score 3 when an encoding change is introduced at an interface level.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-64",
"source": "eip.md",
"summary": "The Receipts grammar retains the existing distinction between legacy and typed receipts and merely omits bloom from their receipt data."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-64; Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "Only the network representation of receipts changes, and the EIP states that EVM consensus rules are unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic-gas calculation is added or modified, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-64",
"source": "eip.md",
"summary": "The Status schema retains existing blockhash and genesis elements while removing td, and the other change concerns receipt-message payloads."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "Rollout occurs through a new negotiated wire-protocol version; the EIP expressly requires no hard fork."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state or internal variable is modified at a fork-activation block, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 22-27",
"source": "eip.md",
"summary": "Existing sync behavior is said to regenerate, transmit, and verify about 530 GB of receipt blooms per syncing peer."
},
{
"locator": "Rationale, lines 73-74",
"source": "eip.md",
"summary": "The proposal shifts work by reducing serving-node CPU and at least 95 GiB of compressed bandwidth while requiring receivers to recompute blooms."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Validating the claimed effect requires end-to-end sync behavior, including serving CPU, receiver recomputation, compression, and network transfer; it cannot be fully benchmarked in isolation and substantially changes existing sync performance. This matches score 3.",
"score": 3,
"uncertainty_note": "The package contains estimates and qualitative CPU claims but no benchmark method or measurements with which to bound the validation work.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility, lines 76-80; Security Considerations, lines 82-84",
"source": "eip.md",
"summary": "The change is isolated behind eth/69, older peers may retain eth/68, no consensus rule changes, and the EIP records no security considerations."
},
{
"locator": "Specification, lines 40-64",
"source": "eip.md",
"summary": "Receivers deterministically reconstruct an omitted bloom from the logs in the received receipt."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect encoding, decoding, or reconstruction could disrupt eth/69 peer interoperability or syncing, but the mechanism is self-contained and does not alter a chain-consensus security invariant. That fits the isolated mechanism at score 1.",
"score": 1,
"uncertainty_note": "The proposal does not specify malformed-message handling, so availability implications cannot be completely assessed from the package.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 40-64",
"source": "eip.md",
"summary": "The happy-path eth/69 receipt shape and derivation of bloom from logs are stated, but receiver requirements and invalid or old-layout receipt handling are not expressly defined."
},
{
"locator": "Backwards Compatibility, lines 76-80",
"source": "eip.md",
"summary": "Multiple protocol versions may coexist, with old peers continuing to use eth/68."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A few negative-path and reconstruction-timing details remain unstated, but the obvious intended reading is to apply the specified schema for the negotiated version and derive the existing bloom value from logs. This fits score 1 rather than a detail requiring broad redesign.",
"score": 1,
"uncertainty_note": "The package contains no general eth protocol error-handling rules, implementation status, devnet record, or discussion record from which to determine whether those details were already shared assumptions.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter, lines 1-12",
"source": "eip.md",
"summary": "EIP-7642 explicitly requires EIP-5793."
},
{
"locator": "Specification, lines 26-36; Backwards Compatibility, lines 46-50",
"source": "supporting/eip-5793.md",
"summary": "EIP-5793 defines the eth/68 predecessor message change and its coexistence with eth/67, providing the version on which eth/69 builds."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
5793
],
"rationale": "The sole direct interaction is EIP-5793: EIP-7642 advances its eth/68 base protocol to eth/69. Coordinated version and regression cases are needed, but the interaction is limited and the two message changes can mostly be tested independently, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
}
],
"eip": 7642,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7642:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The manifest and output template title EIP-7642 as \"eth/69 - history expiry and simpler receipts,\" while the sealed EIP front matter titles it \"eth/69 - Drop pre-merge fields.\" The EIP number and sealed blob identity match, so the assessment follows the contents of that blob while preserving populated provenance.",
"The manifest labels the layer as execution, whereas the sealed EIP categorizes itself as Networking and specifies peer wire messages; the rubric is applied to that historical networking scope without changing the populated layer."
],
"provenance": {
"assessed_revision": {
"commit": "1632462ccf6dfb5d27b7e4bd2cacf0ac122ad4b2",
"committed_at": "2025-01-08T16:54:23Z",
"content_sha256": "3a81334713ccb1643370a4135d8bb91348851efd032ca3bcf1c20418f4354b48",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7642.md",
"git_blob_sha": "2a8835e5d926895fc0e0b77675bd4bcf846abb16",
"immutable_url": "https://github.com/ethereum/EIPs/blob/1632462ccf6dfb5d27b7e4bd2cacf0ac122ad4b2/EIPS/eip-7642.md",
"information_cutoff_at": "2025-02-21T16:21:57Z",
"path": "EIPS/eip-7642.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7642.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7642.yaml",
"sha256": "8262dd400f92f5c2bc82019cafd2708a2ce030f4c1820daa89c2c3ec5de3c1a9"
},
"supporting_documents": [
"supporting/eip-5793.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 12,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "EIP-7642 introduces eth/69 by removing the obsolete total-difficulty field from the Status message and omitting the bloom field from both legacy and typed receipts sent in the Receipts message. Receiving peers reconstruct a receipt bloom from its logs. The change is versioned so older peers can continue using eth/68, and the proposal expressly makes no EVM consensus change and requires no hard fork.",
"tier": "medium",
"title": "eth/69 - history expiry and simpler receipts",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 15,
"minimum": 11
},
"present": true,
"summary": "Localized under-specification remains around receiver behavior for malformed or mixed-version receipt encodings and whether or when bloom reconstruction is mandatory. The intended happy-path schema and derivation are nevertheless clear.",
"unresolved_questions": [
"Must an eth/69 receiver reject a receipt carrying the old bloom field, and what peer error or disconnect behavior applies?",
"Must the receiver reconstruct every bloom while decoding, before receipt verification or use, or only on demand?",
"Which malformed combinations of typed or legacy receipt payloads are valid enough to decode under eth/69?"
]
}
},
"osaka:7823:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 33-35",
"source": "eip.md",
"summary": "The proposal makes an over-limit length an error that consumes all gas."
},
{
"locator": "Specification, lines 21-35",
"source": "supporting/eip-198.md",
"summary": "The existing precompile uses a dynamic gas formula derived from the declared lengths and adjusted exponent length."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The all-gas failure rule updates gas treatment for an existing precompile, but it does not introduce a new general gas-accounting mechanism. This matches the score-1 anchor for updating an existing mechanism.",
"score": 1,
"uncertainty_note": "The draft does not specify the exact sequencing of the limit check relative to the existing gas calculation, but the stated all-gas outcome supports the primary score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "The only specified change is an input-length bound and failure rule for MODEXP; no state access or opcode-internal access ordering is described."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The precompile validation change neither accesses state nor moves a gas charge relative to a state access, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 26-35",
"source": "eip.md",
"summary": "The proposal is confined to bounding MODEXP input lengths and contains no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "The change concerns precompile input validation and an execution-gas failure outcome, not charging for state writes."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "There is no state-gas cost, charging site, budget, reservoir, or spill-path change, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 33-35",
"source": "eip.md",
"summary": "Invalid over-limit input consumes all gas; the proposal specifies no gas refund."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No refund mechanism is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 14-22",
"source": "eip.md",
"summary": "The proposal says MODEXP's unbounded input surface has produced numerous consensus bugs from specially crafted, impractically long inputs."
},
{
"locator": "Backwards Compatibility, lines 52-56",
"source": "eip.md",
"summary": "The draft explicitly calls the new bound backwards incompatible and says historical transactions require checking."
},
{
"locator": "Specification examples, lines 63-71",
"source": "supporting/eip-198.md",
"summary": "EIP-198 includes an extreme declared-modulus-length case under its previously unbounded parsing and gas rules."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing MODEXP vectors for oversized or specially crafted length fields must be reworked around the new validation outcome. This is a meaningful subset of that precompile's tests, but it is confined to the contrived class of over-limit inputs, matching the score-2 anchor.",
"score": 2,
"uncertainty_note": "The package contains no test inventory, so the exact fraction of pre-existing MODEXP vectors affected cannot be counted.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 33-35",
"source": "eip.md",
"summary": "The new result applies only when a MODEXP length field exceeds the limit."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to this EIP do not gain a universal or additional assertion; only tests of the changed MODEXP input class need different logic. The score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 26-35",
"source": "eip.md",
"summary": "The specification changes precompile execution behavior without adding any transition-tool input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Existing transition-tool interfaces suffice, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 33-35",
"source": "eip.md",
"summary": "Observable expectations are limited to a length threshold, precompile error, and all-gas consumption."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "These outcomes can be expressed with ordinary precompile call, error, and gas assertions; the proposal does not require a new reusable framework abstraction. The score-0 anchor applies.",
"score": 0,
"uncertainty_note": "The sealed package does not describe the test framework, but no novel expectation type is implied by the EIP text.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 28-35 and 39-44",
"source": "eip.md",
"summary": "The proposal bounds operand lengths while retaining ordinary RSA and elliptic-curve-sized use cases; it does not change modular exponentiation."
},
{
"locator": "Rationale, lines 96-100",
"source": "supporting/eip-198.md",
"summary": "EIP-198 already supplies the number-theoretic modular-exponentiation functionality and its exponent-pricing rationale."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No new cryptographic mechanism or algorithm is introduced, and the computation for allowed inputs is unchanged. Merely restricting the input domain does not trigger a positive cryptography anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "A single upper-bound rule is applied independently to the base, exponent, and modulus length fields, with a distinct over-limit failure result."
},
{
"locator": "Specification, lines 17-27",
"source": "supporting/eip-198.md",
"summary": "The three lengths govern variable input parsing, right-padding, output length, dynamic gas, and adjusted-exponent calculation."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The proposal introduces one threshold mechanism that needs exact-limit and just-over-limit cases for each of three fields. Although it sits atop variable-length parsing, it remains one localized boundary-prone mechanism, matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "The unspecified sequencing and error semantics may add coupled boundary cases; this is reflected in the under-specification range rather than in a higher primary score.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 26-35",
"source": "eip.md",
"summary": "The proposal modifies MODEXP execution and introduces no block or RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-RLP validation mechanism requiring client syncing is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 26-35",
"source": "eip.md",
"summary": "The complete normative change is local to MODEXP input handling and names no Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "There is no Engine API change, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 26-35",
"source": "eip.md",
"summary": "The EIP changes an existing precompile and does not introduce contract code or a new system address."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "The target is the MODEXP precompile at its existing address, not a pre-existing system contract's code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "A precompile behavior change is scored in the precompile criterion and does not directly or indirectly modify a system contract. The score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-16 and 28-35",
"source": "eip.md",
"summary": "The proposal modifies the existing MODEXP precompile and defines no new EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "The changed operation is a precompile call target rather than an opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "The EIP explicitly recaps and changes the already-existing EIP-198 precompile."
},
{
"locator": "Specification, lines 15-21",
"source": "supporting/eip-198.md",
"summary": "EIP-198 defines MODEXP at the existing address and its input format."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "EIP-7823 adds length validation and a new error/all-gas outcome to the existing MODEXP precompile."
},
{
"locator": "Specification, lines 17-27",
"source": "supporting/eip-198.md",
"summary": "EIP-198 previously accepted 32-byte length words without an upper bound and defined parsing, computation, output, and gas from them."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "This is a behavior modification to one existing complex, variable-input and dynamically priced precompile, which directly matches the score-2 anchor.",
"score": 2,
"uncertainty_note": "The exact error representation is unspecified, but the existence of a consensus-visible behavior modification is unambiguous.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-35",
"source": "eip.md",
"summary": "The existing MODEXP calldata layout is recapped unchanged; only permitted length values and their failure outcome change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "There is no transaction, block, or interface-level encoding change, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 26-35",
"source": "eip.md",
"summary": "The proposal changes execution of an existing precompile and defines no transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 33-35",
"source": "eip.md",
"summary": "Over-limit data changes the execution result of a precompile invocation; it does not make the containing transaction intrinsically invalid."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity rules and intrinsic gas calculations are not modified, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 26-35",
"source": "eip.md",
"summary": "The normative change contains no block body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 26-35 and 52-56",
"source": "eip.md",
"summary": "The EIP specifies a backwards-incompatible execution rule but no special activation-block state or internal-variable mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork-gated rule activation is not the special activation-block modification described by the positive anchor. The score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 14-22",
"source": "eip.md",
"summary": "The bound makes the testing surface finite; the draft notes that MODEXP's existing unbounded-input pricing is complex but does not propose changing that pricing."
},
{
"locator": "Specification, lines 33-35",
"source": "eip.md",
"summary": "The new mechanism is a direct comparison of three declared lengths with a fixed limit and an immediate failure path."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new early-rejection path should be performance-validated, but it is self-contained, benchmarkable in isolation, and leaves allowed-input computation unchanged. This matches the score-1 anchor.",
"score": 1,
"uncertainty_note": "The draft supplies no performance plan or benchmark data, so validation effort is inferred only from the specified mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 18-24",
"source": "eip.md",
"summary": "MODEXP is described as a source of numerous consensus bugs, especially for crafted impractical lengths and complex unbounded-input pricing."
},
{
"locator": "Backwards Compatibility and Security Considerations, lines 52-62",
"source": "eip.md",
"summary": "The draft calls the change backwards incompatible, asks for historical transaction analysis, and leaves security considerations for discussion."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The new check interacts with the existing precompile's parsing, dynamic gas, and failure behavior. A boundary or sequencing mismatch could create a consensus divergence, warranting targeted review and fuzzing of this limited component; this matches the score-2 anchor rather than an ecosystem-wide score 3.",
"score": 2,
"uncertainty_note": "The security section is unfinished, so the historical text does not resolve all compatibility and failure-propagation risks.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 33-35",
"source": "eip.md",
"summary": "The threshold and all-gas statement are explicit, but the text says only that execution stops and \"returns an error\" without defining the precise call result, return data, or check ordering."
},
{
"locator": "Backwards Compatibility and Security Considerations, lines 52-62",
"source": "eip.md",
"summary": "Both sections remain marked TODO; compatibility needs investigation and security still needs discussion."
},
{
"locator": "Specification, lines 17-27",
"source": "supporting/eip-198.md",
"summary": "EIP-198 defines successful parsing, gas, and output behavior but does not supply the new over-limit error semantics."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients can agree on the 1024-byte threshold, but tests still need a precise consensus interpretation of the localized new failure path and when it is selected. That requires agreement before baselining and matches score 2; it does not expose a broad, previously unobservable behavior of the score-3 kind.",
"score": 2,
"uncertainty_note": "General precompile-call conventions may make parts of \"returns an error\" obvious to implementers, but those conventions are not specified in the sealed sources.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Specification, lines 1-12 and 28-35",
"source": "eip.md",
"summary": "EIP-7823 formally requires EIP-198 and changes the accepted inputs and failure behavior of the precompile that EIP-198 defines."
},
{
"locator": "Specification, lines 15-35",
"source": "supporting/eip-198.md",
"summary": "EIP-198 defines MODEXP's input parsing, output, adjusted exponent, and dynamic gas formula that must be considered with the new bound."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
198
],
"rationale": "The proposal directly modifies EIP-198 and requires coordinated tests of its parsing and gas rules, although that interaction is limited to one EIP and one precompile. This matches the score-2 anchor. Interacting EIPs: 198.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
}
],
"eip": 7823,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7823:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The phrase \"returns an error\" does not specify the call success indicator or return data for an over-limit precompile invocation.",
"The draft does not state the order of the new limit check relative to the existing dynamic gas calculation and input parsing.",
"Backwards compatibility and security analysis are expressly incomplete at the selected revision."
],
"provenance": {
"assessed_revision": {
"commit": "b16c055363024c8c7e072c32e98c390d3ad6c33e",
"committed_at": "2024-11-26T17:33:25Z",
"content_sha256": "deefcee9cba6b82efa2dbf7e238ee30d589c8cd20bbf0d570f004611be18e410",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7823.md",
"git_blob_sha": "cf60d90b499bb8e2226c962ecebcf9a9a2618071",
"immutable_url": "https://github.com/ethereum/EIPs/blob/b16c055363024c8c7e072c32e98c390d3ad6c33e/EIPS/eip-7823.md",
"information_cutoff_at": "2025-01-23T23:05:03Z",
"path": "EIPS/eip-7823.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7823.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7823.yaml",
"sha256": "181572e1b0027009eda7be1a1f137d74291e132ce1638300486a0794a8ed541a"
},
"supporting_documents": [
"supporting/eip-198.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 13,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the selected draft revision, EIP-7823 modified the EIP-198 MODEXP precompile by limiting each of its three declared input lengths to 1024 bytes. An over-limit length was specified to stop the precompile, return an error, and consume all gas, while the existing pricing and allowed-input computation were otherwise left unchanged. The draft identified the change as backwards incompatible, but its compatibility and security discussions remained incomplete.",
"tier": "medium",
"title": "Set upper bounds for MODEXP",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 12
},
"present": true,
"summary": "The proposal fixes the numerical threshold and states that invalid input consumes all gas, but it does not define the precise consensus-visible form of the returned error or the ordering of the bound check relative to EIP-198's parsing and gas calculation. The unfinished compatibility and security sections also leave the consequences of that failure path unanalyzed. The missing behavior is localized to over-limit MODEXP calls.",
"unresolved_questions": [
"What exact precompile-call success flag and return-data result does \"returns an error\" require?",
"Is the length bound checked before the existing EIP-198 gas calculation and before any variable-length input is accessed?",
"Are all combinations of multiple over-limit length fields required to have exactly the same failure result and gas outcome?"
]
}
},
"osaka:7825:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cap and Changes to EVM Behavior, lines 31-47",
"source": "eip.md",
"summary": "The proposal adds a validity ceiling on the transaction's declared gasLimit; it does not alter an EVM gas charge, cost schedule, or accounting mechanism."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal adds a validity ceiling on the transaction's declared gasLimit; it does not alter an EVM gas charge, cost schedule, or accounting mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The specified checks occur at transaction-pool and block validation and do not move any state access or gas charge within opcode execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The specified checks occur at transaction-pool and block validation and do not move any state access or gas charge within opcode execution.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cap, lines 33-37",
"source": "eip.md",
"summary": "The cap concerns the ordinary transaction gasLimit and specifies no blob-gas accounting change."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The cap concerns the ordinary transaction gasLimit and specifies no blob-gas accounting change.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "No state-writing charge, state-gas budget, reservoir, or spill interaction is introduced or modified."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-writing charge, state-gas budget, reservoir, or spill interaction is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The proposal contains no gas-refund mechanism or refund-rule change."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal contains no gas-refund mechanism or refund-rule change.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Changes to EVM Behavior, lines 39-42",
"source": "eip.md",
"summary": "A minor subset of existing transaction and block-validity cases using gasLimit values above 30,000,000 changes from accepted to rejected. The EIP says values below the cap remain unaffected and expects only minimal practical impact."
},
{
"locator": "Backwards Compatibility, lines 61-63",
"source": "eip.md",
"summary": "A minor subset of existing transaction and block-validity cases using gasLimit values above 30,000,000 changes from accepted to rejected. The EIP says values below the cap remain unaffected and expects only minimal practical impact."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor subset of existing transaction and block-validity cases using gasLimit values above 30,000,000 changes from accepted to rejected. The EIP says values below the cap remain unaffected and expects only minimal practical impact.",
"score": 1,
"uncertainty_note": "The package contains no historical test inventory, so the exact number of pre-existing vectors above the cap is not established.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Changes to EVM Behavior, lines 39-42",
"source": "eip.md",
"summary": "The cap changes the expected validity of affected cases; it does not produce a new value or invariant that unrelated pre-existing tests must additionally assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The cap changes the expected validity of affected cases; it does not produce a new value or invariant that unrelated pre-existing tests must additionally assert.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Changes to EVM Behavior and Protocol Adjustment, lines 39-47",
"source": "eip.md",
"summary": "Validation uses the existing transaction gasLimit value and requires no new transition-tool field or interface mechanism."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Validation uses the existing transaction gasLimit value and requires no new transition-tool field or interface mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cap and Changes to EVM Behavior, lines 33-42",
"source": "eip.md",
"summary": "A scalar boundary check and invalid-transaction or invalid-block expectations can be expressed with ordinary test cases; the proposal identifies no need for new framework abstractions."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "A scalar boundary check and invalid-transaction or invalid-block expectations can be expressed with ordinary test cases; the proposal identifies no need for new framework abstractions.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The transaction gas-limit comparison introduces no cryptography."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The transaction gas-limit comparison introduces no cryptography.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cap, lines 33-37",
"source": "eip.md",
"summary": "The EIP introduces one sharp numeric boundary: 30,000,000 is permitted while a gasLimit greater than 30,000,000 is rejected, in both admission and block validation contexts."
},
{
"locator": "Changes to EVM Behavior, lines 39-42",
"source": "eip.md",
"summary": "The EIP introduces one sharp numeric boundary: 30,000,000 is permitted while a gasLimit greater than 30,000,000 is rejected, in both admission and block validation contexts."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The EIP introduces one sharp numeric boundary: 30,000,000 is permitted while a gasLimit greater than 30,000,000 is rejected, in both admission and block validation contexts.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Changes to EVM Behavior, lines 39-42",
"source": "eip.md",
"summary": "Block import or syncing gains one simple validation rule: reject a block when any contained transaction declares a gasLimit above the cap. The check uses an existing transaction field and does not change its encoding."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Block import or syncing gains one simple validation rule: reject a block when any contained transaction declares a gasLimit above the cap. The check uses an existing transaction field and does not change its encoding.",
"score": 1,
"uncertainty_note": "The EIP calls this block validation rather than specifically RLP validation, so the rubric's block-RLP boundary admits a score of 0 interpretation.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "No Engine API endpoint, field, or communication mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API endpoint, field, or communication mechanism is specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The validation cap introduces no system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "The validation cap introduces no system contract.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The proposal neither modifies a system contract nor describes an indirect behavioral effect on one."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal neither modifies a system contract nor describes an indirect behavioral effect on one.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "No opcode is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Changes to EVM Behavior, lines 39-42",
"source": "eip.md",
"summary": "Despite the heading, the described behavior changes only transaction and block validation; no pre-existing opcode result or behavior changes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Despite the heading, the described behavior changes only transaction and block validation; no pre-existing opcode result or behavior changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "No precompile is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "No precompile logic or gas schedule is modified."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cap and Protocol Adjustment, lines 33-47",
"source": "eip.md",
"summary": "The proposal constrains the value of the existing gasLimit field but does not alter transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal constrains the value of the existing gasLimit field but does not alter transaction, block, or interface encoding.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The cap applies a validation rule to transactions and does not define a new transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The cap applies a validation rule to transactions and does not define a new transaction type.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Cap and Changes to EVM Behavior, lines 33-42",
"source": "eip.md",
"summary": "This is a new validity rule for existing transactions: values above the cap are rejected at pool admission and make a containing block invalid. It changes affected existing cases but is a single comparison requiring limited vector updates rather than testing-infrastructure redesign."
},
{
"locator": "Backwards Compatibility, lines 61-63",
"source": "eip.md",
"summary": "This is a new validity rule for existing transactions: values above the cap are rejected at pool admission and make a containing block invalid. It changes affected existing cases but is a single comparison requiring limited vector updates rather than testing-infrastructure redesign."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "This is a new validity rule for existing transactions: values above the cap are rejected at pool admission and make a containing block invalid. It changes affected existing cases but is a single comparison requiring limited vector updates rather than testing-infrastructure redesign.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Protocol Adjustment, lines 44-47",
"source": "eip.md",
"summary": "The existing block gas limit remains independent of the transaction cap, and no new block or header field is added."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The existing block gas limit remains independent of the transaction cap, and no new block or header field is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 31-47",
"source": "eip.md",
"summary": "The proposal specifies no state or internal-variable modification at the fork activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The proposal specifies no state or internal-variable modification at the fork activation block.",
"score": 0,
"uncertainty_note": "The historical draft does not state its activation mechanics, but nothing in its described rule calls for the kind of activation-block mutation scored by this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 13-29",
"source": "eip.md",
"summary": "The new operation is a fixed scalar validation check and does not itself require performance validation. The stated performance effects are reduced worst-case transaction load and more predictable block verification, not a new performance mechanism or risk."
},
{
"locator": "Security Considerations, lines 65-69",
"source": "eip.md",
"summary": "The new operation is a fixed scalar validation check and does not itself require performance validation. The stated performance effects are reduced worst-case transaction load and more predictable block verification, not a new performance mechanism or risk."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new operation is a fixed scalar validation check and does not itself require performance validation. The stated performance effects are reduced worst-case transaction load and more predictable block verification, not a new performance mechanism or risk.",
"score": 0,
"uncertainty_note": "The text motivates the numerical cap with performance concerns but supplies no benchmark methodology for validating the selected value.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Changes to EVM Behavior, lines 39-42",
"source": "eip.md",
"summary": "The consensus-critical cap touches the limited components of transaction admission and block acceptance. An inconsistent comparison or application could cause acceptance divergence, so targeted boundary review and fuzzing are warranted, while the rule has no broad interaction with EVM execution."
},
{
"locator": "Security Considerations, lines 65-69",
"source": "eip.md",
"summary": "The consensus-critical cap touches the limited components of transaction admission and block acceptance. An inconsistent comparison or application could cause acceptance divergence, so targeted boundary review and fuzzing are warranted, while the rule has no broad interaction with EVM execution."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The consensus-critical cap touches the limited components of transaction admission and block acceptance. An inconsistent comparison or application could cause acceptance divergence, so targeted boundary review and fuzzing are warranted, while the rule has no broad interaction with EVM execution.",
"score": 2,
"uncertainty_note": "The EIP discusses intended DoS mitigation but does not analyze failure modes of inconsistent client enforcement.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract, lines 13-15",
"source": "eip.md",
"summary": "The concrete greater-than comparison determines the central block-consensus boundary, but the short draft leaves a few details implicit: whether every use of \"gas usage\" means declared gasLimit, the exhaustive transaction scope, and activation. These have an obvious intended reading rather than requiring a new consensus mechanism to be designed."
},
{
"locator": "Gas Cap and Changes to EVM Behavior, lines 33-42",
"source": "eip.md",
"summary": "The concrete greater-than comparison determines the central block-consensus boundary, but the short draft leaves a few details implicit: whether every use of \"gas usage\" means declared gasLimit, the exhaustive transaction scope, and activation. These have an obvious intended reading rather than requiring a new consensus mechanism to be designed."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The concrete greater-than comparison determines the central block-consensus boundary, but the short draft leaves a few details implicit: whether every use of \"gas usage\" means declared gasLimit, the exhaustive transaction scope, and activation. These have an obvious intended reading rather than requiring a new consensus mechanism to be designed.",
"score": 1,
"uncertainty_note": "The suggested error code is explicitly only an example and appears to concern local admission rather than the block-consensus result; it is not treated as an additional consensus ambiguity.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 31-58",
"source": "eip.md",
"summary": "The sealed historical text names no other EIP and specifies no dependency, modification, or conflict requiring coordinated cross-EIP testing."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The sealed historical text names no other EIP and specifies no dependency, modification, or conflict requiring coordinated cross-EIP testing.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
}
],
"eip": 7825,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7825:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The abstract describes a cap on gas usage, while the normative checks compare the declared gasLimit; the assessment follows the concrete gasLimit rule.",
"The phrase \"appropriate error code\" is followed by an example rather than a required code, leaving transaction-pool error reporting non-normative.",
"No explicit activation clause or exhaustive transaction-scope definition appears in the historical draft."
],
"provenance": {
"assessed_revision": {
"commit": "8096a3a13aa6bda755416d1199150f4165a36315",
"committed_at": "2024-12-02T17:16:34Z",
"content_sha256": "d8c7ec66e85f9ccaa5ce7c3a33058902e996df621ba179a4aa9d97ae4d543523",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7825.md",
"git_blob_sha": "47cbfed315988c0bd4d10002c110ae402504cd94",
"immutable_url": "https://github.com/ethereum/EIPs/blob/8096a3a13aa6bda755416d1199150f4165a36315/EIPS/eip-7825.md",
"information_cutoff_at": "2025-02-21T01:11:23Z",
"path": "EIPS/eip-7825.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7825.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7825.yaml",
"sha256": "989cded1e71cce6a504ff4cd2a52ebab8551d28f44c417bb1e6f1803bf733433"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 8,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this draft proposed a protocol-wide maximum declared transaction gasLimit of 30,000,000, independent of the block gas limit. A transaction above the cap would be excluded during transaction-pool validation, and a block containing one would be invalid before processing. The proposal did not change EVM gas prices or accounting, transaction encoding, opcodes, or block fields.",
"tier": "low",
"title": "Transaction Gas Limit Cap",
"under_specification": {
"affected_criteria": [
"block_syncing_changes",
"new_or_modified_transaction_validity_mechanisms",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 9,
"minimum": 7
},
"present": true,
"summary": "The central >30,000,000 block-validity predicate is testable as written, but the draft is not fully normative about fork activation, whether its broad wording covers every transaction form without exception, or whether references to gas usage are exclusively references to the declared gasLimit. Its proposed pool error code is only an example. These gaps are material to finalizing the test matrix but are localized and do not obscure the primary validity rule.",
"unresolved_questions": [
"What exact fork activation condition makes the new transaction and block rule effective?",
"Does \"any single transaction\" cover every transaction form carrying a gasLimit, with no protocol-level exceptions?",
"Are the abstract's references to maximum gas usage intended solely as checks of the sender-declared gasLimit, as the concrete validation clauses state?",
"Is any exact transaction-pool error code normative, or is only rejection required?"
]
}
},
"osaka:7883:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "The existing ModExp call cost is recalculated with changed constants and length-dependent branches."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This updates an existing EVM gas-accounting mechanism for one precompile, matching score 1; it does not introduce a separate gas mechanism.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-115",
"source": "eip.md",
"summary": "The EIP states that the underlying interface and arithmetic algorithms do not change."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The change is confined to pricing an existing precompile and specifies no state access or change in charging order relative to a state access, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-16",
"source": "eip.md",
"summary": "The stated scope is modification of the ModExp precompile pricing algorithm."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas rule or mechanism is introduced or modified, which is the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-45",
"source": "eip.md",
"summary": "The specification defines only execution-gas pricing for a call to the ModExp precompile."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal changes neither state-write gas rates nor a state-gas budget, charging site, reservoir, or spill path, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-45",
"source": "eip.md",
"summary": "The gas-cost function returns a charge with a minimum of 500 and specifies no refund path."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The EIP only increases charges and introduces no gas-refund mechanism, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-147",
"source": "eip.md",
"summary": "Existing ModExp vectors are reusable, but their expected pricing values are updated across the supplied table."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor, localized subset of pre-existing tests that assert ModExp gas or gas-boundary outcomes must be reworked, matching score 1. The EIP does not imply broad changes across diverse test categories.",
"score": 1,
"uncertainty_note": "The package does not enumerate every pre-existing test that embeds a ModExp gas allowance, but the affected rule remains limited to one precompile.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-117",
"source": "eip.md",
"summary": "Existing vectors are reused with changed expected prices rather than gaining an additional assertion."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing tests need updated gas expectations, not a new invariant that tests unrelated to this EIP must additionally assert, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-115",
"source": "eip.md",
"summary": "The EIP explicitly states that there are no changes to the underlying interface."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The repricing requires no new transition-tool field or interface mechanism, which is the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-117",
"source": "eip.md",
"summary": "Existing test vectors can be reused by substituting the updated pricing expectations."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Reusing existing vectors with new expected values requires no new framework abstraction, expectation type, modifier, or helper, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-115",
"source": "eip.md",
"summary": "The proposal changes neither the ModExp arithmetic algorithm nor its interface."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Although modular exponentiation is useful to cryptographic applications, this EIP introduces and modifies no cryptographic mechanism; it only reprices execution. The score-0 anchor therefore applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 27-45",
"source": "eip.md",
"summary": "The formula contains a 32-byte base-or-modulus branch, a 32-byte exponent branch, and a 500-gas floor."
},
{
"locator": "Changes, lines 50-103",
"source": "eip.md",
"summary": "The three changes separately alter the minimum-price boundary and the length-dependent behavior above 32 bytes."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms must be checked below, at, and above their thresholds, including the interaction with the minimum charge. The branches are simple closed-form rules and no single one requires an elevated case count, matching score 2 rather than score 3.",
"score": 2,
"uncertainty_note": "Combining base, modulus, and exponent dimensions expands the useful test matrix, but the EIP's unchanged interface and explicit formulas keep each boundary independently tractable.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-24",
"source": "eip.md",
"summary": "The proposal is limited to pricing calls to an existing precompile."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "It introduces no block RLP validation mechanism and therefore no syncing change, which is the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-115",
"source": "eip.md",
"summary": "The underlying interface is explicitly unchanged."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is added, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "The change applies to the already existing precompile at address 0x0000000000000000000000000000000000000005."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Repricing an existing precompile does not add a system contract, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Test Cases, lines 14-16 and 113-115",
"source": "eip.md",
"summary": "The EIP reprices a precompile while leaving its interface and arithmetic behavior unchanged."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "A precompile gas-schedule update is not a direct or indirect modification to a pre-existing system contract under this anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-24",
"source": "eip.md",
"summary": "The target is an existing precompile address rather than a new EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Test Cases, lines 14-16 and 113-115",
"source": "eip.md",
"summary": "Only a precompile pricing algorithm changes, with no change to the underlying arithmetic behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The proposal modifies no opcode result or behavior and does not deprecate an opcode. Gas-only changes would also be excluded by this anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-24",
"source": "eip.md",
"summary": "The proposal modifies pricing for the existing ModExp precompile at address 0x05."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Changes, lines 48-103",
"source": "eip.md",
"summary": "The minimum charge and two length-dependent terms in the existing ModExp gas schedule are increased."
},
{
"locator": "Test Cases, lines 113-115",
"source": "eip.md",
"summary": "The underlying interface and arithmetic are unchanged, isolating the modification to gas pricing."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Exactly one pre-existing precompile has its gas schedule modified without a behavior change, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 113-115",
"source": "eip.md",
"summary": "The underlying interface is unchanged; only pricing differs."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The EIP introduces no transaction-, block-, or interface-level encoding change, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-24",
"source": "eip.md",
"summary": "The complete stated scope is repricing calls to the existing ModExp precompile."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "The formula determines execution gas for a precompile call and does not define transaction validation or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Execution-time precompile charging does not change transaction validity rules or intrinsic gas calculation, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 14-24",
"source": "eip.md",
"summary": "The proposal changes only the pricing algorithm for an existing precompile call."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced, so the score-0 anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 22-45",
"source": "eip.md",
"summary": "Activation switches the gas-cost formula and specifies no one-time state or internal-variable mutation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary activation of a new pricing rule is not a fork-block state or internal-variable modification under this anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Rationale, lines 18-20 and 105-107",
"source": "eip.md",
"summary": "Benchmarking identified underpriced cases, and the new parameters target a cost no lower than EcRecover for worst-performing cases."
},
{
"locator": "Test Cases, lines 113-115",
"source": "eip.md",
"summary": "No arithmetic algorithm changes, so validation concerns the isolated relationship between input shapes, runtime, and price."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The modified pricing needs performance calibration, but ModExp can be benchmarked in isolation and its execution algorithm is unchanged. This matches score 1 rather than a benchmark interaction score.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 154-156",
"source": "eip.md",
"summary": "The EIP introduces no functionality and makes no operation cheaper; it identifies only the possibility of overpricing ModExp scenarios."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Because the change only raises gas charges and leaves functionality intact, the written proposal introduces no mechanism that compromises an existing security invariant. The score-0 anchor applies; overpricing is a usability and calibration concern captured under performance, not a new security interaction.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-45",
"source": "eip.md",
"summary": "Explicit branches define multiplication complexity, iteration count, and the final gas cost for the input lengths and exponent."
},
{
"locator": "Changes, lines 50-103",
"source": "eip.md",
"summary": "Each departure from EIP-2565 is identified by its exact replacement constant or formula branch."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The assessment-time text determines the changed gas result for constructible boundary cases and preserves the existing interface and arithmetic. No new detail needs client agreement before vectors can be baselined, so the score is 0.",
"score": 0,
"uncertainty_note": "The draft has no reference implementation, but absence of an implementation does not create an unresolved semantic case in the explicit pricing formula.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Abstract, lines 1-16",
"source": "eip.md",
"summary": "EIP-7883 requires EIP-2565 and explicitly modifies the ModExp pricing algorithm introduced by it."
},
{
"locator": "Specification, lines 22-40",
"source": "supporting/eip-2565.md",
"summary": "EIP-2565 supplies the baseline multiplication, iteration, and minimum-cost formula that EIP-7883 changes."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2565
],
"rationale": "The proposal directly modifies EIP-2565, requiring its pricing vectors and boundary expectations to be coordinated with the new formula. The interaction is limited to one existing precompile and one EIP, matching score 2 rather than a broad multi-EIP interdependency score. Interacting EIPs: EIP-2565.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
}
],
"eip": 7883,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7883:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "4a06cae0ed50c22c7507ba1b6cfd76ddbc48574b",
"committed_at": "2025-02-14T17:00:54Z",
"content_sha256": "ca87942f7dcba477b81ca31dab57f0dad4383e8a84c3995930dfbc7b651e1683",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7883.md",
"git_blob_sha": "8fdc33692f0971ae2a34098bf47fd9e7cdc689ce",
"immutable_url": "https://github.com/ethereum/EIPs/blob/4a06cae0ed50c22c7507ba1b6cfd76ddbc48574b/EIPS/eip-7883.md",
"information_cutoff_at": "2025-02-21T10:10:59Z",
"path": "EIPS/eip-7883.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7883.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7883.yaml",
"sha256": "18a4a325aba493cc2c223cdeea4ae7e606d8cdce5a8bf611af043be4c3f4d98d"
},
"supporting_documents": [
"supporting/eip-2565.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 8,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this draft changed only the gas-pricing algorithm for the existing ModExp precompile, building on EIP-2565. It raised the minimum charge from 200 to 500, doubled the exponent-length contribution above 32 bytes, and doubled multiplication complexity when the base or modulus exceeds 32 bytes. The interface and arithmetic algorithms remained unchanged, and existing vectors were to be reused with updated gas values.",
"tier": "low",
"title": "ModExp Gas Cost Increase",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 8,
"minimum": 8
},
"present": false,
"summary": "No material under-specification is present. The changed constants, threshold branches, and final minimum are explicit, while all unmodified interface and arithmetic behavior is inherited unchanged from EIP-2565.",
"unresolved_questions": []
}
},
"osaka:7892:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "BPO forks are restricted to the blob target, blob limit, and blob base-fee update fraction, implemented through the blob schedule."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes blob-specific parameters, not EVM execution-gas accounting, so it meets the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "The exhaustive BPO change set contains only three blob parameters and no opcode-execution or state-access rule."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Nothing moves a state access or a gas charge within opcode execution, so no state-access ordering change is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "A BPO fork may change the blob target, maximum blob count, and baseFeeUpdateFraction at scheduled timestamps."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The blob target and update fraction are parameters of the existing blob-gas pricing mechanism, and the blob limit constrains existing blob processing. This updates the existing mechanism without introducing a new accounting mechanism, matching score 1.",
"score": 1,
"uncertainty_note": "The actual values and schedules are not specified, but that does not change the kind of accounting mechanism affected.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "The permitted changes are exclusively blob-capacity and blob-fee parameters; no state-write cost or budget is introduced."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal does not alter state-gas costs, charging sites, budgets, reservoirs, or spill behavior and therefore meets the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "The defined mechanism changes only blob target, limit, and fee-update parameters and contains no refund rule."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Requirements, lines 42-48 and 83-90",
"source": "eip.md",
"summary": "Existing blob parameters may change at any number of new timestamped boundaries, and execution/consensus schedules must align, avoid conflicts, and carry equal maximum values."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Pre-existing blob-limit, excess-blob-gas, blob-fee, and fork-boundary tests must be reworked to select parameters from successive BPO schedule entries. This is a considerable but blob-confined category rather than a diverse majority of execution tests, matching score 2.",
"score": 2,
"uncertainty_note": "Concrete schedules are outside scope, so the exact number of affected vectors cannot be determined from this revision.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Requirements, lines 85-90",
"source": "eip.md",
"summary": "The new equality and alignment requirements concern the BPO configuration itself rather than outputs that every unrelated fork test must assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests specifically exercising BPO schedules need these checks, but the text does not make tests unrelated to the EIP additionally assert a new produced value. The zero anchor therefore applies.",
"score": 0,
"uncertainty_note": "The proposal does not specify a test-suite integration model, but it defines no universal per-test assertion.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Rationale, lines 48-81 and 98-100",
"source": "eip.md",
"summary": "Parameter schedules are placed in execution- and consensus-client configuration; no transition-tool request or response field is defined."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A client configuration extension is not, by itself, a transition-tool interface change. The historical text mandates no new transition-tool field or mechanism, so the best-supported score is 0.",
"score": 0,
"uncertainty_note": "How test transition tools receive or model arbitrary BPO schedules is not specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale, lines 98-100",
"source": "eip.md",
"summary": "External configuration is intended to let testing teams vary parameters, but the proposal defines no expectation, modifier, or helper primitive."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The EIP supplies configuration data rather than a new test-framework abstraction. On the available text, existing primitives can consume varied configurations, so score 0 is best supported.",
"score": 0,
"uncertainty_note": "The historical proposal contains no test-framework design, so a later need for a reusable schedule modifier cannot be excluded.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "The change set consists solely of numeric blob parameters and schedule entries, with no cryptographic construction or operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified by EIP-7892.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Requirements, lines 48-90",
"source": "eip.md",
"summary": "The schedule accepts an arbitrary number of timestamped changes, while execution timestamps must align to consensus epoch starts, schedules must not conflict, and maximum values must match across layers."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The mechanism introduces multiple boundary-prone dimensions: before/at/after each activation, successive entries, independent changes to three parameters, epoch/timestamp alignment, and cross-layer equality. The arbitrary number of entries makes the boundary matrix elevated rather than a small fixed set, satisfying score 3.",
"score": 3,
"uncertainty_note": "Invalid-schedule handling and concrete schedules are unspecified, so the exact case matrix remains open even though its elevated nature is clear.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-81",
"source": "eip.md",
"summary": "The proposal changes configured blob parameters at time/epoch boundaries and introduces no block RLP field or RLP decoding rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Although blob-count validation can vary by schedule, no new block RLP validation mechanism is introduced, which is the rubric's syncing trigger.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Specification, lines 19-29",
"source": "supporting/eip-7840.md",
"summary": "EIP-7840 places blob parameters in client configuration specifically to avoid a complex Engine API handshake."
},
{
"locator": "Specification, lines 48-81",
"source": "eip.md",
"summary": "EIP-7892 extends configuration schedules and adds consensus configuration, without specifying an Engine API field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The design intentionally uses configuration instead of Engine API communication, so no Engine API field, endpoint, or mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-81",
"source": "eip.md",
"summary": "The complete mechanism is expressed through blob parameters and client configuration and contains no contract deployment."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract, stateful or otherwise, is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-81",
"source": "eip.md",
"summary": "The parameter schedule has no specified direct or indirect system-contract action."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system-contract code, state, or behavior is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "The exhaustive set of permitted BPO changes contains only blob parameters and no new EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "Blob parameter changes do not specify any alteration to an existing opcode's result or behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "The proposal's allowed changes are confined to blob parameters and do not define a precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "No precompile logic or gas schedule appears among the permitted BPO parameter changes."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas accounting is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-81",
"source": "eip.md",
"summary": "New values are represented in node configuration schedules; no transaction, block, or interface serialization is changed."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Configuration syntax is not an RLP/SSZ transaction, block, or interface encoding change under this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-48",
"source": "eip.md",
"summary": "The EIP adjusts blob-related parameters but defines no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-90",
"source": "eip.md",
"summary": "The maximum applies to blobs per block and the normative requirements concern schedule consistency; no per-transaction validity or intrinsic-gas rule is stated."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "A scheduled block blob limit is not a change to transaction validity or intrinsic gas as defined by this anchor. The proposal specifies no such transaction-level mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-81",
"source": "eip.md",
"summary": "The new schedule entries live in execution and consensus node configuration rather than in a block or block header."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Requirements, lines 42-90",
"source": "eip.md",
"summary": "Existing blob parameters may switch at arbitrary execution timestamps and corresponding consensus epoch starts, with the two schedules required to align."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Each BPO activation modifies existing internal protocol parameters at its activation boundary. That directly satisfies the rubric's binary score-3 condition for modifying internal variables or similar at a fork activation block.",
"score": 3,
"uncertainty_note": "Concrete activation points are outside scope, but the activation mechanism and parameter modification are explicit.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 19-34",
"source": "eip.md",
"summary": "BPO forks are intended to increase saturated blob capacity, with increases chosen after observing mainnet performance and stability around new scaling technology such as EIP-7594."
},
{
"locator": "Specification, lines 24-30",
"source": "supporting/eip-7594.md",
"summary": "PeerDAS distributes cells from all blob rows through custody, gossip, peer sampling, and reconstruction every slot, tying blob volume to network work."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Raising blob target and limit affects block-wide data volume and existing networking/availability work, and the proposal itself relies on real-world observation rather than isolated benchmarking. The impact can be substantial and interacts with existing DA mechanisms, matching score 3.",
"score": 3,
"uncertainty_note": "The proposal deliberately omits actual parameter values, so the magnitude of any particular BPO fork cannot be quantified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Requirements, lines 85-90",
"source": "eip.md",
"summary": "Execution and consensus clients must share schedules, avoid conflicting forks, align timestamp and epoch boundaries, and agree on maximum blobs."
},
{
"locator": "Security Considerations, lines 109-115",
"source": "eip.md",
"summary": "The draft states that no security risks had been identified at the cutoff."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Despite the draft's conclusion, an incorrect or inconsistent implementation touches the limited but critical set of EL/CL schedule selection and blob-limit validation components and can make the layers or clients disagree at activation. This warrants targeted review and cross-client negative testing, matching score 2 rather than an extensive multi-component redesign.",
"score": 2,
"uncertainty_note": "Concrete capacity values and behavior for invalid configurations are absent, so their validator/network safety implications cannot be fully assessed.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Requirements, lines 83-90",
"source": "eip.md",
"summary": "Values and schedules are illustrative, while consistency, non-conflict, alignment, and equality are required without defining failure handling or what constitutes a conflict."
},
{
"locator": "Specification, lines 46-48",
"source": "supporting/eip-7840.md",
"summary": "Missing or incomplete blobSchedule configuration is expressly undefined, and clients are free to choose how to handle it."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need common baselines for missing/incomplete entries, invalid alignment, schedule conflicts, and mismatched layer values before negative and boundary tests can assert results. These gaps are localized to schedule configuration and activation, fitting score 2 rather than a pervasive new consensus-observability problem.",
"score": 2,
"uncertainty_note": "The sealed package contains no discussion-thread or implementation evidence showing whether these draft questions had converged by the cutoff.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter, Motivation, and Specification, lines 10 and 32-48",
"source": "eip.md",
"summary": "EIP-7892 requires and extends EIP-7840 and identifies EIP-7594 as the scaling technology motivating staged blob-capacity adjustment."
},
{
"locator": "Front matter and Specification, lines 11 and 24-30",
"source": "supporting/eip-7594.md",
"summary": "EIP-7594 itself builds on EIP-4844 blobs and applies per-blob-row networking and availability work, linking capacity changes to both mechanisms."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7840,
7594,
4844
],
"rationale": "Interacting EIPs are EIP-7840 (the schedule format directly extended), EIP-7594 (the DA/networking mechanism whose observed capacity informs BPO increases), and EIP-4844 (the underlying blob mechanism whose parameters are changed). Coordinated schedule, boundary, blob-accounting, and DA-capacity testing is required, but the interactions remain confined to the blob stack, matching score 2; there are no additional EIPs beyond the first three for an uncapped increment.",
"score": 2,
"uncertainty_note": "The proposal's direct normative dependency is only EIP-7840; its interaction with EIP-7594 and EIP-4844 is architectural and motivational rather than a new normative dependency.",
"under_specified": false
}
],
"eip": 7892,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7892:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The phrase that any of the three parameters MAY change does not specify whether unchanged fields must be repeated or inherited in each timestamp entry.",
"The repeated BPO_FORK consensus configuration example is illustrative rather than a complete schema, leaving uniqueness and malformed-entry behavior open.",
"The non-conflict requirement does not define conflict or resolution behavior.",
"Actual BPO values and dates are excluded, so this assessment covers the mechanism rather than the risk magnitude of a particular capacity increase."
],
"provenance": {
"assessed_revision": {
"commit": "216ebd2f32f876b09c24d3be9cb9c4ff6abbb46f",
"committed_at": "2025-03-24T16:26:03Z",
"content_sha256": "78546589d5cebf184aa6983758a8f5b2a71884a7e8ef2161f1313f0a80b779fc",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7892.md",
"git_blob_sha": "6076cad2adb6f6d35bcbbaf9d5fc327453f28f06",
"immutable_url": "https://github.com/ethereum/EIPs/blob/216ebd2f32f876b09c24d3be9cb9c4ff6abbb46f/EIPS/eip-7892.md",
"information_cutoff_at": "2025-03-25T15:44:57Z",
"path": "EIPS/eip-7892.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7892.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7892.yaml",
"sha256": "daec0686fe3e1da62f8dab6b66cb3dc1ff4d6408b432a9f9355b2dafbaa43cb5"
},
"supporting_documents": [
"supporting/eip-7594.md",
"supporting/eip-7840.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 18,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, draft informational EIP-7892 defined Blob Parameter Only hard forks as changes restricted to the blob target, blob limit, and blob base-fee update fraction. It extended EIP-7840's execution layer blobSchedule to arbitrary timestamp entries and added consensus-layer epoch/max-blob configuration, with cross-layer alignment, equality, and non-conflict requirements. Concrete parameter values and activation schedules were explicitly outside the proposal's scope, while the stated purpose was repeated capacity scaling after observing demand and network performance, including around EIP-7594.",
"tier": "medium",
"title": "Blob Parameter Only Hardforks",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 21,
"minimum": 13
},
"present": true,
"summary": "Concrete parameter values and activation schedules are intentionally out of scope, and the draft does not define parsing/selection and failure behavior for missing, incomplete, conflicting, misaligned, or cross-layer-mismatched schedules. It also does not say how transition tools or test frameworks represent an arbitrary sequence of BPO activations. These gaps chiefly vary the size and baseline of schedule-boundary, regression, performance, and security testing; they are not counted as separate high-complexity mechanisms.",
"unresolved_questions": [
"How must clients handle a missing or incomplete entry for a scheduled BPO activation, including omission of only one of the three parameters?",
"What precisely constitutes a conflict with another fork schedule, and must clients reject conflicting configuration or apply a deterministic precedence?",
"What behavior is required when execution and consensus schedules disagree on activation alignment or maximum blob count?",
"How are multiple consensus-layer BPO_FORK entries uniquely represented and selected at and around epoch boundaries?",
"Which concrete values and activation points define the test matrix for any actual BPO fork?"
]
}
},
"osaka:7910:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 38-50",
"source": "eip.md",
"summary": "The required change is a parameterless JSON-RPC reporting method; no EVM gas-charging rule is introduced or changed."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "evm_gas_rule_changes",
"rationale": "The proposal exposes configuration data and does not modify EVM gas accounting, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 38-50",
"source": "eip.md",
"summary": "The specification adds an RPC method and says nothing about opcode execution or the ordering of state access and gas charging."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode execution path or state-access ordering changes, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Fields in the Configuration Object, lines 80-82",
"source": "eip.md",
"summary": "The method reports three already-configured blob schedule parameters as JSON numbers."
},
{
"locator": "Blob Parameter Only Forks, lines 110-112",
"source": "eip.md",
"summary": "For reporting purposes, a BPO fork derives a configuration by inheriting its parent and updating blob schedule values."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "blob_gas_accounting_changes",
"rationale": "Reporting configured blob parameters and deriving a reportable BPO configuration do not alter blob-gas accounting rules. The zero anchor therefore applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Fields in the Configuration Object, lines 68-108",
"source": "eip.md",
"summary": "The reportable fields are activation time, blob schedule, chain ID, precompiles, and system-contract addresses; no state-gas charge or budget is defined."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "state_gas_accounting_changes",
"rationale": "The proposal introduces no state-gas costs, charging sites, budget, reservoir, or spill behavior, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Configuration RPC, lines 48-50",
"source": "eip.md",
"summary": "The sole new mechanism in this passage is a read-only, parameterless JSON-RPC method."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 146-150",
"source": "eip.md",
"summary": "The draft states that it does not alter previous behavior and relaxes compliance only for reported pre-Cancun configurations."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Testing the new reporting API can be done in EIP-specific cases; the proposal does not rework existing execution-validation tests. This matches the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 146-150",
"source": "eip.md",
"summary": "Existing behavior is explicitly left unchanged; compliance concerns the values returned by the new method."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The text does not require tests unrelated to EIP-7910 to assert an additional output or invariant. Dedicated RPC tests suffice, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Configuration RPC, lines 38-50",
"source": "eip.md",
"summary": "The interface addition is on the standard JSON-RPC port and is not a transition-tool input or output."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool field or mechanism is specified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 152-158 and 225-235",
"source": "eip.md",
"summary": "The supplied tests are ordinary JSON configuration fixtures and a conventional JSON-RPC request/response example."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "new_test_framework_primitives",
"rationale": "Existing fixture comparison and RPC request primitives are sufficient; the draft does not require a new framework-level expectation, modifier, or helper.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Converting a Fork Configuration to a Hash, lines 62-66",
"source": "eip.md",
"summary": "Canonical JSON is checksummed with CRC-32 for the configuration hash."
},
{
"locator": "CRC-32 as Hash Format, lines 142-144",
"source": "eip.md",
"summary": "The rationale treats CRC-32 as a convenience checksum rather than a security mechanism and notes its broad availability."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "cryptography",
"rationale": "CRC-32 is a non-cryptographic checksum, and EIP-7910 introduces or modifies no cryptographic mechanism. The zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Result Object Structure, lines 52-60",
"source": "eip.md",
"summary": "Current, next, and last configurations and their two identifiers vary with whether a future fork is configured, including null and next-equals-last cases."
},
{
"locator": "Specification and activationTime, lines 44-46 and 74-78",
"source": "eip.md",
"summary": "Values must track the most recent header and fork crossings, while genesis activation uses zero and unscheduled or unknown activation changes inclusion behavior."
},
{
"locator": "Blob Parameter Only Forks, lines 110-112",
"source": "eip.md",
"summary": "BPO configuration derivation can recursively inherit from another BPO parent before applying only blob-schedule updates."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "edge_boundary_conditions",
"rationale": "The method combines multiple boundary-prone mechanisms: before/at/after fork transitions, known versus absent future forks, current/next/last rotation, synchronized hashes and fork IDs, genesis and unknown activation values, and recursive BPO inheritance. Fork-transition cases must be crossed with the report's several correlated members, producing an elevated case matrix and matching the score-3 anchor.",
"score": 3,
"uncertainty_note": "Several boundary outcomes are themselves under-specified, so the exact test matrix cannot be fixed from the draft; a score of 2 is also plausible if these cases are treated as variations of one fork-selection mechanism.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Configuration RPC, lines 48-50",
"source": "eip.md",
"summary": "The change is an RPC query and does not introduce block RLP fields or block-validation rules."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism or sync behavior is changed, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 38-40",
"source": "eip.md",
"summary": "Standard JSON-RPC exposure is mandatory, while making the same method available through the Engine API is optional."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "engine_api_changes",
"rationale": "The proposal mandates no Engine API field, directive, or endpoint; optional routing of eth_config through that port is not a required Engine API interface change. The zero anchor is the best-supported primary score.",
"score": 0,
"uncertainty_note": "If optional exposure is interpreted as introducing an Engine API endpoint that must be tested whenever implemented, the score-2 new-endpoint anchor could apply.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "systemContracts, lines 100-108",
"source": "eip.md",
"summary": "The result object enumerates addresses of system contracts introduced elsewhere and asks future meta-EIPs to define reportable lists."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "added_system_contracts",
"rationale": "EIP-7910 reports existing system contracts but deploys no new system contract, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "systemContracts, lines 100-108",
"source": "eip.md",
"summary": "System contracts appear only as names and addresses in the RPC response; their code, state, and behavior are not changed."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "modified_system_contracts",
"rationale": "Merely reporting system-contract configuration has no direct or indirect effect on those contracts, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Configuration RPC, lines 13-15 and 48-50",
"source": "eip.md",
"summary": "The proposal is a node-configuration RPC interface and defines no EVM instruction."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "added_opcodes",
"rationale": "No opcode is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 146-150",
"source": "eip.md",
"summary": "Previous protocol behavior is unchanged; only reporting compliance is added for Cancun and later forks."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "modified_opcodes",
"rationale": "No existing opcode result or behavior is modified or deprecated, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "precompiles, lines 90-98",
"source": "eip.md",
"summary": "The RPC object enumerates precompiles already active in a fork, including examples for Cancun and Prague."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "added_precompiles",
"rationale": "Reporting the active set does not introduce a precompile, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "precompiles, lines 90-98",
"source": "eip.md",
"summary": "Precompiles are represented by address and agreed name; no precompile logic or gas schedule is changed."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "modified_precompiles",
"rationale": "The proposal modifies neither precompile behavior nor gas accounting, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Configuration RPC and Converting a Fork Configuration to a Hash, lines 48-50 and 62-66",
"source": "eip.md",
"summary": "The method uses the existing JSON-RPC transport and defines canonical JSON only as input to a new configuration checksum."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or existing interface encoding is changed. Defining the payload and checksum serialization of a new JSON-RPC method is not an RLP/SSZ or replacement interface encoding change, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "The rubric includes interface-level encoding, but this draft adds a new JSON payload rather than changing an existing interface's encoding.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Configuration RPC, lines 48-50",
"source": "eip.md",
"summary": "The only new wire-level request is a parameterless RPC method, not a transaction envelope."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 146-150",
"source": "eip.md",
"summary": "The proposal states that previous behavior is unchanged and scopes compliance to configuration reporting."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity and intrinsic gas calculations are untouched, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 38-46",
"source": "eip.md",
"summary": "The latest block header is only the reference point for fresh RPC values; no field is added to a block or header."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 44-46",
"source": "eip.md",
"summary": "Returned configuration must follow the most recent provided header, and any configuration cache must be purged when a fork boundary is crossed."
},
{
"locator": "Result Object Structure, lines 54-60",
"source": "eip.md",
"summary": "Crossing a configured fork changes which configurations and corresponding hashes and fork IDs occupy the current, next, and last positions."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "new_fork_activation_mechanism",
"rationale": "The draft expressly requires internal cached configuration state and the selected current/next/last view to change at a fork boundary. The rubric's binary score-3 anchor covers modification of internal variables or similar at activation, even though no consensus state is written.",
"score": 3,
"uncertainty_note": "The modification is operational RPC cache/view state rather than consensus state; if the anchor is intended only for protocol-transition state, a score of 0 would be plausible.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 348-352",
"source": "eip.md",
"summary": "The draft identifies resource-exhaustion risk and recommends caching configuration objects, rate limiting requests, and optionally imposing a minimum response interval."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "performance_risks",
"rationale": "Canonicalizing and checksumming configuration objects under RPC load warrants performance validation, but the endpoint can be benchmarked and rate-limited in isolation without altering existing execution performance. This matches the score-1 anchor.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 348-352",
"source": "eip.md",
"summary": "Identified risks are configuration exposure, dishonest responses, and RPC resource exhaustion, with local/authenticated access, cross-checking, caching, and rate limiting as mitigations."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "security_risks",
"rationale": "The new read-only endpoint has self-contained disclosure, trust, and availability risks that can be reviewed in isolation and does not change execution or chain security invariants. This matches the score-1 anchor.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Result Object Structure, lines 52-60",
"source": "eip.md",
"summary": "The text calls the response four members but names nine, and its null clauses do not unambiguously say which current, next, and last values and identifiers become null when no future fork is configured."
},
{
"locator": "Converting a Fork Configuration to a Hash and Fields in the Configuration Object, lines 62-82",
"source": "eip.md",
"summary": "Hash equality depends on an exact meta-EIP-derived field set, while activation omission and the required three-member blobSchedule leave constructible output cases open."
},
{
"locator": "Blob schedule configuration and Requirements, lines 50-55 and 119-124",
"source": "supporting/eip-7892.md",
"summary": "The linked BPO specification includes maxBlobsPerTx as a fourth blob parameter and makes it optional with a default, unlike EIP-7910's three-member blobSchedule description."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Cross-client fixtures cannot uniquely baseline several localized RPC cases: nullability and omission, the exact field set used for canonical hashes, and BPO inheritance when the linked specification has an additional optional field. These require client agreement, but they affect a reporting interface rather than making previously unobservable execution behavior consensus-critical, so the score-2 anchor applies rather than score 3.",
"score": 2,
"uncertainty_note": "Some readers may infer obvious intended behavior from the samples and linked standards, which would support score 1, but the exact hashed output still needs a common interpretation.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Result Object Structure, lines 58-60",
"source": "eip.md",
"summary": "Every reported current, next, and last configuration is paired with a FORK_HASH value defined by EIP-6122."
},
{
"locator": "Specification, lines 26-48",
"source": "supporting/eip-6122.md",
"summary": "EIP-6122 defines FORK_HASH from passed block-number and timestamp forks and specifies FORK_NEXT and ordering rules that must align with EIP-7910 outputs."
},
{
"locator": "Blob Parameter Only Forks, lines 110-112",
"source": "eip.md",
"summary": "EIP-7910 expressly adopts EIP-7892 BPO forks as reportable forks and recursively derives their configurations."
},
{
"locator": "Definition and Blob schedule configuration, lines 42-61",
"source": "supporting/eip-7892.md",
"summary": "EIP-7892 defines activation-time blob schedule changes that EIP-7910 must translate into current, next, and last configuration reports."
}
],
"exceptional_score_justification": "Not applicable.",
"id": "cross_eip_interactions",
"interacting_eips": [
6122,
7892
],
"rationale": "The method behaviorally depends on EIP-6122 fork identifiers and EIP-7892 BPO fork/configuration semantics. Coordinated boundary tests are required for both, but the interactions remain limited to deriving and reporting configuration, so the score-2 anchor applies.",
"score": 2,
"uncertainty_note": "EIP-2124 is mentioned only for incorporated CRC-32 rationale and is not counted as a separate behavioral interaction; unnamed defining EIPs for listed precompiles and system contracts are likewise not counted.",
"under_specified": true
}
],
"eip": 7910,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7910:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The result structure says it has four members of two types but specifies three groups of three named members.",
"Null handling is grammatically shared across current, next, and last values even though the triggering condition concerns the absence of a future fork.",
"EIP-7910 specifies a three-member blobsSchedule while linked EIP-7892 includes optional maxBlobsPerTx with a default.",
"The cache-purge requirement plainly modifies internal RPC state at a fork boundary, but the fork-activation rubric may have been designed primarily for consensus-transition state.",
"Optional Engine API exposure can be read either as simple routing of an eth_ method or as a new Engine API endpoint."
],
"provenance": {
"assessed_revision": {
"commit": "59c5b1739bc30ae056517d5c1bc1cfd6ebf0a30f",
"committed_at": "2025-07-09T17:40:29Z",
"content_sha256": "8b88d88cd3742f7cf28454c3e4dabb6ea540c8f46fdfa577cbfa72c149463612",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7910.md",
"git_blob_sha": "83d8bfb99c50b8ae0355e5f06dabfebe1d749909",
"immutable_url": "https://github.com/ethereum/EIPs/blob/59c5b1739bc30ae056517d5c1bc1cfd6ebf0a30f/EIPS/eip-7910.md",
"information_cutoff_at": "2025-07-10T14:25:07Z",
"path": "EIPS/eip-7910.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7910.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7910.yaml",
"sha256": "ee28e5ddea19efb0baef20906d2dc03c4cf2a361f556f7e2f963de181e3b4820"
},
"supporting_documents": [
"supporting/eip-6122.md",
"supporting/eip-7892.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 12,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7910 was a draft interface proposal requiring execution clients to expose a parameterless eth_config JSON-RPC method that reports current, next, and last fork configurations together with configuration hashes and EIP-6122 fork identifiers. The reported configuration covered activation time, blob-schedule parameters, chain ID, active precompiles, and system-contract addresses; configuration objects were to be canonically serialized and checksummed with CRC-32. The proposal also required fork-boundary freshness, delegated future field definitions to meta-EIPs, and defined recursive inheritance for EIP-7892 Blob Parameter Only forks.",
"tier": "medium",
"title": "eth_config JSON-RPC Method",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"engine_api_changes",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 14,
"minimum": 10
},
"present": true,
"summary": "Material under-specification is localized to the observable RPC contract. The draft does not uniquely determine null and omission behavior for all nine named result members, the exact canonical field set for configurations whose meta-EIP or linked BPO definition differs from EIP-7910's field list, or all head/fork transition cases that rotate current, next, and last values. Optional Engine API exposure is also named without a distinct conformance contract.",
"unresolved_questions": [
"Which current, next, and last configuration, hash, and fork-ID members are null when no future fork is configured or its activation time is unknown?",
"Does a BPO configuration include maxBlobsPerTx, and exactly how are optional/defaulted and recursively inherited fields included in the canonical hash input?",
"How do head regression or reorganization and multiple forks at one activation time affect current/next/last selection and cache invalidation?",
"Does optional Engine API exposure use an identical method and schema, and is it part of Engine API conformance testing when implemented?",
"Which precise CRC-32 convention and result representation apply to configuration hashes independently of the EIP-6122 fork ID?"
]
}
},
"osaka:7918:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Gas accounting, lines 164-167",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 defines blob gas as independent of normal gas."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 changes only the excess-blob-gas update calculation."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes the separate blob-gas fee mechanism, not EVM execution-gas charging, so the EVM gas-rule anchor is not triggered.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The normative change is header-derived fee arithmetic and contains no opcode execution or state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's state-access position or gas-charge ordering is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension and Gas accounting, lines 152-181",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already defines the excess-blob-gas update and derives the blob base fee from that value."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 adds a fee-parity branch that can omit subtraction of the target in the existing update."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "This is a direct update to EIP-4844's existing blob-gas accounting mechanism, matching score 1; it does not introduce a separate new blob-gas mechanism.",
"score": 1,
"uncertainty_note": "The accounting rule is structurally clear, but the undefined `TX_BASE_COST` prevents exact threshold vectors from being baselined.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The change updates excess blob gas and does not charge for writing state or alter a state-gas budget."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas cost, charging site, budget, reservoir, or spill path is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The new branch changes excess-blob-gas accumulation and specifies no refund behavior."
},
{
"locator": "Gas accounting, lines 184-186",
"source": "supporting/eip-4844.md",
"summary": "The pre-existing blob fee is burned and not refunded on transaction failure."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Execution layer validation, lines 244-253",
"source": "supporting/eip-4844.md",
"summary": "Existing block validation asserts that the header's excess blob gas equals the output of the update function."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The replacement update changes the expected value only when its new fee-parity condition is satisfied."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing EIP-4844 excess-blob-gas and block-header vectors in the execution-fee-led regime must be reworked, but this is a narrow subset of existing tests, matching score 1.",
"score": 1,
"uncertainty_note": "The undefined `TX_BASE_COST` leaves the exact subset of affected fee vectors unresolved and could make the affected subset larger.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution layer validation, lines 244-253",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already requires the excess-blob-gas header value to match the update function."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 changes that existing function's result rather than adding a new asserted output."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests may need revised expected values, but they gain no additional invariant or assertion, so this distinct anchor remains zero.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension, lines 152-160",
"source": "supporting/eip-4844.md",
"summary": "The pre-existing update accepts the parent header."
},
{
"locator": "Specification, lines 30-40",
"source": "eip.md",
"summary": "The modified function keeps the same parent-header interface and reads existing header fields."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No new transition-tool field or interface mechanism is required; the additional comparison is derivable from the already supplied parent header.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The feature is expressed as deterministic integer comparisons and returns over existing header inputs."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing value- and block-expectation primitives suffice; the text provides no need for a new framework abstraction, modifier, or expectation type.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The normative change consists solely of fee multiplication, comparison, addition, and subtraction."
},
{
"locator": "Cryptographic Helpers, lines 67-74",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844's KZG proof helpers are pre-existing context and are not referenced by the EIP-7918 change."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 30-40",
"source": "eip.md",
"summary": "The output depends both on the target-total boundary and on a strict greater-than fee-parity boundary."
},
{
"locator": "Delayed response during a quick rise in execution fees, lines 55-57",
"source": "eip.md",
"summary": "The proposal identifies a multi-block catch-up period when execution fees rise quickly."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Tests must cross below, at, and above the existing target-total boundary with below, equal, and above fee parity, including the different equality behavior of the strict comparison. These are multiple interacting boundary conditions but do not require an elevated case count beyond that compact matrix, matching score 2.",
"score": 2,
"uncertainty_note": "Exact parity inputs cannot be fixed until `TX_BASE_COST` is defined.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension, lines 119-160",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already defines the header fields and their RLP encoding."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 changes the value-calculation rule without adding an RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The specification changes a local header-derived calculation and defines no Engine API field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The complete normative change is a calculation branch and creates no contract or system action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The excess-blob-gas update does not read, write, or otherwise reference system-contract code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system contract is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 specifies only a change to `calc_excess_blob_gas()`."
},
{
"locator": "Opcode to get versioned hashes, lines 188-193",
"source": "supporting/eip-4844.md",
"summary": "The blob-related BLOBHASH opcode already belongs to EIP-4844 and is not changed by this proposal."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added by EIP-7918.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The normative code modifies a block-level accounting helper, not opcode behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 adds only a fee-parity branch and does not define a precompile."
},
{
"locator": "Point evaluation precompile, lines 195-223",
"source": "supporting/eip-4844.md",
"summary": "The blob point-evaluation precompile is pre-existing EIP-4844 functionality."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added by EIP-7918.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The change neither invokes nor alters precompile logic or gas accounting."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension, lines 119-150",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 already establishes the RLP header encoding containing the blob-gas fields."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 changes how one existing field value is computed, not how any data is encoded."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Blob transaction, lines 97-117",
"source": "supporting/eip-4844.md",
"summary": "The blob transaction type is pre-existing EIP-4844 functionality."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 introduces no transaction format or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Execution layer validation, lines 244-281",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 separately defines the existing block-header assertion and blob-transaction validity checks."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 changes the block's excess-blob-gas derivation and does not change transaction validity or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The changed consensus value is a block validity consequence, not a change to any transaction type's validity rules or intrinsic gas calculation.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Header extension, lines 119-162",
"source": "supporting/eip-4844.md",
"summary": "`blob_gas_used` and `excess_blob_gas` are fields already introduced by EIP-4844."
},
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "EIP-7918 only changes the derivation of the existing `excess_blob_gas` field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-40",
"source": "eip.md",
"summary": "The proposal defines the ongoing parent-derived rule and specifies no activation-block state or internal-variable mutation."
},
{
"locator": "Header extension, lines 152-162",
"source": "supporting/eip-4844.md",
"summary": "The parent blob-gas fields and their first-introduction initialization are pre-existing EIP-4844 behavior."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Switching to the new calculation at the fork does not itself modify state or an internal variable at the activation block, so the binary anchor is zero.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 30-40",
"source": "eip.md",
"summary": "The per-block update adds a comparison and a call to derive the parent blob base fee."
},
{
"locator": "Helpers and Gas accounting, lines 83-94 and 169-181",
"source": "supporting/eip-4844.md",
"summary": "Blob-base-fee derivation uses the existing iterative `fake_exponential()` helper."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The added per-block work is self-contained and can be benchmarked in isolation, with no stated broad effect on existing performance behavior, matching score 1.",
"score": 1,
"uncertainty_note": "The text supplies no performance measurements, although the computation is bounded to one existing helper invocation per update.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 18-22",
"source": "eip.md",
"summary": "The proposal addresses loss of the blob-price signal, fallback to a first-price auction, and spiky blob resource consumption."
},
{
"locator": "Specification and Security Considerations, lines 30-40 and 93-95",
"source": "eip.md",
"summary": "The rule couples execution and blob fee values, while the author reports no known security risks."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect threshold or update behavior could affect consensus on the header and the intended fee/resource-control mechanism. The change interacts with a limited set of critical existing components—the execution base fee and EIP-4844 blob accounting—so targeted security and economic review is warranted, matching score 2 rather than an extensive multi-component score.",
"score": 2,
"uncertainty_note": "The security section is brief and the undefined `TX_BASE_COST` leaves the exact economic threshold unresolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Specification, lines 1-11 and 28-40",
"source": "eip.md",
"summary": "The normative comparison uses `TX_BASE_COST`, but the EIP provides no value or definition for that symbol."
},
{
"locator": "Parameters, lines 38-56",
"source": "supporting/eip-4844.md",
"summary": "The required EIP defines the blob-gas constants used by the comparison but does not define `TX_BASE_COST`."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot baseline the fee-parity branch without agreeing on the numeric meaning of `TX_BASE_COST`. The gap is localized to one constant and does not expose previously unobservable behavior, matching score 2.",
"score": 2,
"uncertainty_note": "The phrase \"simple blob-carrying transaction\" suggests an intended interpretation, but the sealed text does not make that interpretation normative.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter and Specification, lines 1-11 and 28-40",
"source": "eip.md",
"summary": "EIP-7918 explicitly requires EIP-4844 and modifies its excess-blob-gas update."
},
{
"locator": "Abstract, lines 14-16",
"source": "eip.md",
"summary": "The new rule directly compares the blob base fee with `base_fee_per_gas`."
},
{
"locator": "Front matter and Gas accounting, lines 1-11 and 164-181",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 requires EIP-1559 and defines its blob gas as a separate targeting rule similar to EIP-1559."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
4844
],
"rationale": "The proposal modifies EIP-4844 and couples that blob-fee mechanism to the EIP-1559 execution base fee. Coordinated cross-market boundary tests are required, but the interaction is limited to the fee update calculation, matching score 2.",
"score": 2,
"uncertainty_note": "EIP-1559 is an indirect dependency through EIP-4844 and the existing `base_fee_per_gas` field, but the new comparison makes that interaction direct for testing purposes.",
"under_specified": false
}
],
"eip": 7918,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7918:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The preferred normative specification is distinguishable from the two explicitly labeled alternatives, but `TX_BASE_COST` is never defined.",
"The proposal notes delayed catch-up after a rapid execution-base-fee rise without specifying a separate bound; the normative recurrence nevertheless determines each block's result once its constants are defined."
],
"provenance": {
"assessed_revision": {
"commit": "d4a7453aacfc8dfcaf25cbafec3c1bff1b9e6680",
"committed_at": "2025-03-26T19:04:25Z",
"content_sha256": "eeca54feba9d22411496c6d0020ffe41b174d465361abfc6790e349ab14fbd8d",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7918.md",
"git_blob_sha": "bd5700342ad5e1b41f973cc46b569a9a639694ee",
"immutable_url": "https://github.com/ethereum/EIPs/blob/d4a7453aacfc8dfcaf25cbafec3c1bff1b9e6680/EIPS/eip-7918.md",
"information_cutoff_at": "2025-03-26T23:25:10Z",
"path": "EIPS/eip-7918.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7918.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7918.yaml",
"sha256": "c639c010d7f42a2b1ce9cf07380c30b18bccfbabb7a8cf921c1f876b9e7bec53"
},
"supporting_documents": [
"supporting/eip-4844.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 11,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this Draft EIP changed EIP-4844's parent-derived `calc_excess_blob_gas()` update. When the parent blob-gas total is at least the target and the execution cost represented by `TX_BASE_COST` exceeds the target blobs' blob fee, the update retains the full parent total instead of subtracting the blob-gas target. The stated goal was to keep the blob fee auction responsive rather than allowing the blob base fee to collapse while execution cost carries the price signal.",
"tier": "low",
"title": "Blob base fee bounded by execution cost",
"under_specification": {
"affected_criteria": [
"blob_gas_accounting_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 10
},
"present": true,
"summary": "The normative rule uses `TX_BASE_COST` without defining its value or exact composition. That omission prevents clients from agreeing on which side of the fee-parity branch a constructed block occupies, even though the rest of the update rule is localized and explicit.",
"unresolved_questions": [
"What exact numeric value and cost components does `TX_BASE_COST` denote for the normative fee-parity comparison?"
]
}
},
"osaka:7934:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Protocol Adjustment, lines 55-58",
"source": "eip.md",
"summary": "The new block-size limit is explicitly stated to apply independently of gas-related metrics."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal adds no EVM gas accounting rule, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block Size Cap and Changes to Protocol Behavior, lines 30-53",
"source": "eip.md",
"summary": "The specified operation measures the RLP encoding of a whole block and changes only block construction and validation."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode execution, state access, or gas-charge ordering is changed, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Protocol Adjustment, lines 55-58",
"source": "eip.md",
"summary": "The size check is independent of gas-related metrics, and no blob-gas rule is specified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "There is no blob gas accounting change, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Protocol Adjustment, lines 55-58",
"source": "eip.md",
"summary": "The proposal separates its block-byte limit from all gas-related metrics and specifies no state-write charge."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas cost, charging site, budget, reservoir, or spill rule is changed, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The complete specified change is a block-size validity comparison independent of gas metrics."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no gas-refund mechanism, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility, lines 66-68",
"source": "eip.md",
"summary": "Blocks above the new limit cease to be valid, so existing vectors containing such blocks would change outcome."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The new validation rule affects a narrow subset of pre-existing block tests: those with an RLP encoding above the cap. That fits the minor-subset anchor rather than broad test rework.",
"score": 1,
"uncertainty_note": "The sealed package does not enumerate historical test vectors, so the affected subset is inferred from the validity rule.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Changes to Protocol Behavior, lines 50-53",
"source": "eip.md",
"summary": "The EIP changes builder acceptance and node rejection behavior but defines no additional result or output for unrelated tests to assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Oversized vectors change validity and are counted under test-pattern rework; unrelated tests do not gain a new produced value to assert. This matches the zero anchor.",
"score": 0,
"uncertainty_note": "The EIP does not describe a test-suite representation, but no new assertion-bearing protocol output is specified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Protocol Adjustment, lines 55-58",
"source": "eip.md",
"summary": "Clients must add the size check during block validation and propagation; no transition-tool field or interface mechanism is introduced."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The rule consumes the already encoded block and requires no specified transition-tool interface modification, matching the zero anchor.",
"score": 0,
"uncertainty_note": "The EIP does not state how a transition tool would be used for this outer block-validation rule.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Block Size Cap, lines 30-48",
"source": "eip.md",
"summary": "The normative behavior is expressible as an RLP encoding length comparison against one constant."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Boundary blocks and expected validity can be expressed without a new expectation type, modifier, or permanent framework abstraction, matching the zero anchor.",
"score": 0,
"uncertainty_note": "A convenience helper for constructing exact-size blocks may be useful, but the EIP does not establish that a new framework primitive is required.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 28-58",
"source": "eip.md",
"summary": "The proposal consists solely of an RLP-encoded block-size cap and rejection rule."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism or cryptographic functionality is introduced or modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block Size Cap, lines 32-47",
"source": "eip.md",
"summary": "A block is invalid only when its RLP-encoded length is greater than the derived maximum, making equality and one byte over distinct outcomes."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The proposal introduces one boundary-prone mechanism, with tests needed below, exactly at, and above the byte limit. This matches score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block Size Cap and Protocol Adjustment, lines 30-47 and 55-58",
"source": "eip.md",
"summary": "The EIP adds one RLP block-length validity check that every client must apply during block validation and propagation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "This is a single simple block RLP validation mechanism requiring client agreement on block acceptance, exactly matching the score-1 anchor.",
"score": 1,
"uncertainty_note": "The draft's inconsistent constant names leave a minor specification ambiguity, addressed separately under under-specification.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Changes to Protocol Behavior and Protocol Adjustment, lines 50-58",
"source": "eip.md",
"summary": "The stated changes concern block creation, validation, and propagation, with no new API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is specified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The specification adds constants and a client-side block validity check, not contract code or state."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Changes to Protocol Behavior, lines 50-53",
"source": "eip.md",
"summary": "The behavioral change is confined to block construction and rejection based on encoded size."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal neither identifies nor directly or indirectly changes a pre-existing system contract, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The proposal specifies only a whole-block RLP length check and corresponding block rejection."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No EVM opcode is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Protocol Adjustment, lines 55-58",
"source": "eip.md",
"summary": "The rule is an independent block validation and propagation check rather than an EVM execution change."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The specified feature is a client block-size validation check and contains no callable EVM component."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The complete specified change is a whole-block size cap with no precompile logic or gas schedule changes."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block Size Cap, lines 30-47",
"source": "eip.md",
"summary": "The new rule measures the length produced by the existing RLP encoding of a block; it does not replace or modify that encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Using an existing encoding as the input to a validity limit is not an encoding-format change, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block Size Cap and Changes to Protocol Behavior, lines 30-53",
"source": "eip.md",
"summary": "The proposal constrains total encoded block size and adds no transaction envelope or transaction semantics."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block Size Cap and Protocol Adjustment, lines 30-36 and 55-58",
"source": "eip.md",
"summary": "Invalidity is defined for an oversized block as a whole and is explicitly independent of gas-related metrics."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The EIP does not change any transaction type's validity rules or intrinsic gas calculation, matching the zero anchor.",
"score": 0,
"uncertainty_note": "Transactions can contribute bytes to the block total, but their individual validity is unchanged.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block Size Cap, lines 30-47",
"source": "eip.md",
"summary": "The proposal introduces validation constants and computes size from the existing Block object without adding a block field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-58",
"source": "eip.md",
"summary": "The specification defines a standing validity check and does not prescribe an activation-block state or internal-variable modification."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No state, internal variable, or similar value is modified at a fork activation block, matching the zero anchor.",
"score": 0,
"uncertainty_note": "The historical draft does not specify fork scheduling, but that omission does not itself create an activation-state mechanism.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 19-26",
"source": "eip.md",
"summary": "The EIP is motivated by oversized blocks slowing propagation and block validation and by the resulting instability and denial-of-service exposure."
},
{
"locator": "Block Size Cap, lines 38-47",
"source": "eip.md",
"summary": "The introduced mechanism is a length check over the RLP encoding of one block."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The added size calculation and rejection path warrant performance validation, but the check is self-contained and can be benchmarked in isolation. This matches score 1.",
"score": 1,
"uncertainty_note": "The EIP does not specify whether clients must re-encode a block or may track encoded length, so implementation cost can vary.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 19-26",
"source": "eip.md",
"summary": "Oversized blocks are described as creating propagation failures, temporary forks, reorgs, fragmentation, and denial-of-service risks."
},
{
"locator": "Changes to Protocol Behavior and Protocol Adjustment, lines 50-58",
"source": "eip.md",
"summary": "Builders, validators, and propagation paths must consistently enforce the new consensus-validity boundary."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "An incorrect or inconsistent implementation can make clients disagree on block validity or allow the network attacks the cap is intended to prevent. The rule touches a limited set of critical block-handling components and calls for targeted boundary review or fuzzing, matching score 2 rather than the broad multi-component score 3.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Block Size Cap, lines 32-47",
"source": "eip.md",
"summary": "The prose defines MAX_BLOCK_SIZE and MARGIN, while the pseudocode instead uses SAFETY_MARGIN and an otherwise undefined GOSSIP_UPPER_LIMIT; it also types the measured value only as Block."
},
{
"locator": "Changes to Protocol Behavior and Protocol Adjustment, lines 50-58",
"source": "eip.md",
"summary": "The draft requires the limit during validation and propagation but does not further define whether enforcement measures received bytes or canonical re-encoding at each entry point."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A few localized drafting details are unresolved, but the numeric values, subtraction, strict greater-than comparison, and intended re-encoding operation make the intended rule apparent. This fits score 1.",
"score": 1,
"uncertainty_note": "Exact serialization scope, constant nomenclature, and enforcement point should be normalized before cross-client vectors are baselined.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale, lines 60-64",
"source": "eip.md",
"summary": "The cap is motivated by a consensus-layer gossip constraint, but the proposal names no EIP dependency, modification, or conflict."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "On the sealed evidence, the execution-block validity rule is independently testable and has no identified interaction with another EIP, matching the zero anchor.",
"score": 0,
"uncertainty_note": "The EIP refers generically to consensus-layer gossip behavior without identifying a numbered EIP.",
"under_specified": false
}
],
"eip": 7934,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7934:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The prose and pseudocode disagree on constant names, and GOSSIP_UPPER_LIMIT is undefined in the pseudocode.",
"The draft does not formally distinguish raw received RLP length from canonical re-encoding length at all enforcement paths."
],
"provenance": {
"assessed_revision": {
"commit": "040800a32544ba8819ce7b9feaad9c8bb4400f62",
"committed_at": "2025-05-06T12:39:57Z",
"content_sha256": "29c5f346e4a9e09f18e7ba5296b49fc0b250e913e2fa02870402d1ea76da5e77",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7934.md",
"git_blob_sha": "028e8657abdf9fa3f2159e639bccd2f66f88be1c",
"immutable_url": "https://github.com/ethereum/EIPs/blob/040800a32544ba8819ce7b9feaad9c8bb4400f62/EIPS/eip-7934.md",
"information_cutoff_at": "2025-05-09T21:56:48Z",
"path": "EIPS/eip-7934.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7934.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7934.yaml",
"sha256": "4e5bd09270a4f9675fc8a5854ed93e3b7aff25a773e20c0511458725c8d3d921"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 7,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the historical cutoff, EIP-7934 proposed a protocol-level upper bound of 10 MiB minus a 512 KiB safety margin on the RLP-encoded execution block. Block builders had to stay at or below that bound, while validating nodes had to reject blocks above it and apply the check during validation and propagation. The limit was explicitly independent of gas metrics and added no new encoding, transaction, header, or EVM feature.",
"tier": "low",
"title": "RLP Execution Block Size Limit",
"under_specification": {
"affected_criteria": [
"new_test_framework_primitives",
"block_syncing_changes",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 9,
"minimum": 7
},
"present": true,
"summary": "The draft's prose and pseudocode use inconsistent names for the 10 MiB upper limit and 512 KiB margin, and GOSSIP_UPPER_LIMIT is not defined in the code fragment. It also does not formally define the full Block serialization scope or whether each validation and propagation path measures received bytes or a canonical re-encoding. The intended 10 MiB minus 512 KiB, strict greater-than rule is nevertheless apparent.",
"unresolved_questions": [
"Is MAX_RLP_BLOCK_SIZE normatively 10,485,760 minus 524,288 bytes despite the pseudocode's undefined GOSSIP_UPPER_LIMIT name?",
"Does block size mean the canonical result of rlp.encode(Block), or the exact received byte sequence, and which execution-block components are included in Block?",
"At which validation and propagation entry points must the limit be enforced, and do exact-size test construction needs require a reusable test helper?"
]
}
},
"osaka:7935:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The only specified action is changing the block gas-limit value generated by each execution client's default configuration."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Changing a default block gas-limit value does not alter EVM instruction gas charges or introduce an EVM gas-accounting mechanism, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The specification changes only the default configured gas limit and says nothing about opcode execution or state-access sequencing."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's state-access position or gas-charge ordering is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The specified configuration update concerns the ordinary block gas limit; no blob-gas rule or parameter is specified."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting changes are introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The proposal changes a client default for the block gas limit and does not define a cost for writing state, a state-gas budget, or a spill path."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas accounting mechanism or rate is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The specification contains only a default gas-limit configuration change and defines no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 21-23; Security Considerations, lines 33-35",
"source": "eip.md",
"summary": "The EIP asks clients to change a generated default and proposes new multi-client, full-block operational testing; it does not introduce a new validation rule that reworks existing consensus tests."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The planned devnet campaign adds workload testing, but the proposal does not change existing test logic or validation patterns, matching score 0.",
"score": 0,
"uncertainty_note": "Client-specific tests of default configuration output may need a value update, but that is not a new validation mechanism under this anchor.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The configuration recommendation does not require unrelated tests to assert any newly produced protocol property."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing tests gain no new invariant to assert.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The specified change is confined to execution-client default configuration values; no transition-tool input or output is added."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or mechanism is required.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, lines 33-35",
"source": "eip.md",
"summary": "Testing is described in terms of devnets, synthetic full blocks, and monitoring network and node health, without specifying a new reusable test abstraction."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The described campaign can be expressed with existing workload generation and monitoring capabilities; no new framework primitive is required by the text.",
"score": 0,
"uncertainty_note": "The EIP does not describe the available framework, but it also specifies no novel expectation, modifier, or helper abstraction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The default gas-limit update contains no cryptographic mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, lines 33-37",
"source": "eip.md",
"summary": "The proposal requires full blocks, incremental gas-limit increases, and consideration of worst-case block size relative to the CL gossip limit."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Raising one block-capacity parameter creates a single boundary-prone mechanism: behavior near full blocks and resource limits must be exercised. That matches the score-1 anchor rather than multiple independently introduced mechanisms.",
"score": 1,
"uncertainty_note": "The unresolved target value determines how close testing comes to the cited size boundary.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The proposal updates the value generated in default configurations and does not alter block RLP validation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The only specified surface is execution-client default configuration; no Engine API endpoint, field, or communication mechanism is changed."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The specified configuration update deploys no contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "Changing the default configured block gas limit neither changes system contract code or state nor specifies an indirect system-contract effect."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is modified directly or indirectly.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The specification contains no opcode addition."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The default block gas-limit configuration update does not change the behavior of any existing opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The specified configuration update adds no precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The proposal does not change any precompile's logic or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "Updating a value in client-specific default configuration formats does not change transaction, block, or protocol-interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other protocol encoding change is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The client default update defines no transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 29-31",
"source": "eip.md",
"summary": "The EIP notes that larger transactions could interact with a separately proposed 30M transaction gas limit, but it defines no transaction validity or intrinsic-gas change of its own."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "A higher default block gas limit changes block capacity, not the validity rules or intrinsic gas of transactions, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 21-23",
"source": "eip.md",
"summary": "The proposal changes the default value generated for the gas limit; it does not introduce a new block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, lines 25-27",
"source": "eip.md",
"summary": "The new default is coordinated with a hard-fork release, but the EIP does not specify a state transition or internal-variable modification at the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Release coordination for a configuration default is not a fork-block state or internal-variable modification under this anchor.",
"score": 0,
"uncertainty_note": "The exact release timing is unresolved, but no activation-block mechanism is described.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 17-19; Security Considerations, lines 33-35",
"source": "eip.md",
"summary": "The authors expect client bugs at higher limits and require devnets covering all EL/CL client combinations, synthetic full blocks, node and network health monitoring, iterative fixes, and incremental increases."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The performance effect cannot be validated fully in isolation: it depends on sustained full blocks, heterogeneous clients, and network behavior, with an explicitly anticipated need to find and fix client bugs. This substantially affects existing execution and propagation performance and matches score 3.",
"score": 3,
"uncertainty_note": "The normative target is unresolved, so the magnitude of the load increase is not fixed even though the required system-wide validation is explicit.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, lines 33-37",
"source": "eip.md",
"summary": "Safety testing spans all EL/CL combinations, full synthetic blocks, network and node health, repeated patch-and-retest cycles, incremental increases, and worst-case block size relative to the CL gossip limit."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A substantially higher default block capacity stresses multiple critical components across execution, propagation, and consensus-client networking. The prescribed system-wide adversarial and health testing indicates security assumptions cannot be validated as a self-contained mechanism, matching score 3.",
"score": 3,
"uncertainty_note": "The exact target and objective safety thresholds are not normatively fixed, which limits precision about the severity of the risk.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 12-15; Specification, lines 21-23",
"source": "eip.md",
"summary": "The abstract contains a TODO and both the abstract and normative specification use XX0M rather than a concrete default value."
},
{
"locator": "Security Considerations, lines 33-35",
"source": "eip.md",
"summary": "The testing plan instead names 60M, leaving the normative placeholder and the tested candidate inconsistent in the assessment-time text."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients cannot baseline the required default-configuration result until they agree on the exact value. The gap is central but localized to the configured target and release coordination, so score 2 fits better than an obvious minor detail or a newly observable class of consensus behavior.",
"score": 2,
"uncertainty_note": "The 60M testing reference makes the intended value inferable, but it does not replace the unresolved value in the specification.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility, lines 29-31",
"source": "eip.md",
"summary": "The EIP says larger transactions admitted by the higher block limit could exceed a proposed 30M transaction gas limit and explicitly calls for the two EIPs' scheduling to be coordinated."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "This is one limited interaction with another proposal and primarily requires scheduling and compatibility coordination, while EIP-7935 can otherwise be tested independently. The historical text does not provide the other EIP's numeric identifier, so none can be truthfully recorded in interacting_eips.",
"score": 1,
"uncertainty_note": "The interacting proposal is described but not numbered, and the exact behavior when its transaction cap is active is not specified.",
"under_specified": true,
"unidentified_interactions": [
"The sealed proposal describes an interacting proposal but does not provide its EIP number."
]
}
],
"eip": 7935,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7935:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The manifest identifies the assignment as \"Set default gas limit to 60M,\" but the sealed EIP's title and specification retain XX0M; only its security section names 60M.",
"The backwards-compatibility section requires coordination with another EIP but gives no identifier that can be entered as a bare integer.",
"The proposal ties a client-default update to a hard-fork release without defining an activation-block consensus transition."
],
"provenance": {
"assessed_revision": {
"commit": "b4197cbb949c1aed8094ac33b2aa7c2260809a55",
"committed_at": "2025-05-08T13:56:16Z",
"content_sha256": "f3b99e814f33429fc7fae504117866be474062799eb0aa11563b5e385ea5991f",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7935.md",
"git_blob_sha": "09ab43dc269280309f3c34cd405ba25e151690ba",
"immutable_url": "https://github.com/ethereum/EIPs/blob/b4197cbb949c1aed8094ac33b2aa7c2260809a55/EIPS/eip-7935.md",
"information_cutoff_at": "2025-05-09T21:56:48Z",
"path": "EIPS/eip-7935.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7935.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7935.yaml",
"sha256": "59d13a25be382c38aa25d778d7c4c6bfff1f80a57457c98acab93b4f2bdf7744"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 10,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7935 was a draft informational proposal asking execution-layer clients to raise the gas limit produced by their default configurations for the Fusaka release. It introduced no new protocol feature or gas-accounting rule, but called for full-block, multi-client devnet testing and incremental increases to establish that the higher operational limit was safe. The normative target was still written as XX0M, while the security section discussed testing 60M.",
"tier": "low",
"title": "Set default gas limit to 60M",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 11,
"minimum": 7
},
"present": true,
"summary": "Material under-specification is present. The normative target remains XX0M even though 60M is discussed for safety testing; the affected default configurations and release timing are not enumerated; objective safety gates and the incremental increase procedure are not defined; and the interacting transaction-limit EIP is unnamed.",
"unresolved_questions": [
"Is the required default gas limit 60M, or another value represented by XX0M?",
"Which generated default configurations must change, and precisely when does the new default take effect relative to the fork release?",
"What workload duration, health thresholds, and pass/fail criteria establish that a candidate gas limit is safe, and what increments are required?",
"What is the numeric identifier of the proposed 30M transaction-gas-limit EIP, and what coordination beyond scheduling is required?"
]
}
},
"osaka:7939:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 41-44 and 111",
"source": "eip.md",
"summary": "The proposal adds CLZ and assigns it the fixed gas cost 3."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Adding a fixed entry to the EVM gas schedule updates the existing constant-cost accounting mechanism, matching anchor 1; it does not introduce dynamic or new gas-accounting machinery.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 41-44; Security Considerations, lines 183-185",
"source": "eip.md",
"summary": "CLZ only transforms one stack value and is expressly described as stateless."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The opcode performs no state access, so neither the position of a state access nor gas charging relative to one changes; this is anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Specification, lines 39-44 and 111",
"source": "eip.md",
"summary": "The entire change is a stack-word opcode with an ordinary fixed EVM gas cost."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob object, blob validation, or blob gas rule is introduced or modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 41-44 and 111; Security Considerations, lines 183-185",
"source": "eip.md",
"summary": "CLZ is a fixed-cost stateless stack operation and performs no state write."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal has no state-gas charging site, state-byte rate, budget, reservoir, or spill interaction, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, line 111",
"source": "eip.md",
"summary": "The proposal specifies only a gas charge of 3 for CLZ and no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, line 41; Backwards Compatibility, lines 135-137",
"source": "eip.md",
"summary": "Opcode byte 0x1e becomes CLZ even though the opcode was not previously present."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-activation invalid-opcode coverage that used byte 0x1e must change its expected behavior. That is a minor, narrowly targeted subset of pre-existing tests and matches anchor 1.",
"score": 1,
"uncertainty_note": "The EIP does not enumerate existing invalid-opcode tests, so the size of the affected subset is inferred from assigning a previously absent opcode byte.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 135-137; Test Cases, lines 139-180",
"source": "eip.md",
"summary": "The change is a newly available opcode with tests local to its own outputs."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to CLZ do not gain a new artifact or invariant to assert; the narrow invalid-opcode expectation change is a rework pattern, not an additional assertion. Anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 39-44 and 111",
"source": "eip.md",
"summary": "The specification adds only opcode semantics and a fixed gas cost."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool input or output field, endpoint, or fork-block awareness interface is required, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 139-180",
"source": "eip.md",
"summary": "The supplied tests are ordinary opcode sequences with a single expected stack word."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing opcode execution, stack-result, exceptional-stack, and gas test primitives suffice; no new expectation type, modifier, or helper abstraction is implied. This matches anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 21-31; Specification, lines 41-44",
"source": "eip.md",
"summary": "Cryptographic schemes are only listed as a possible user; CLZ itself counts bits."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Counting leading zero bits introduces no cryptographic primitive or modification. A possible cryptographic use case does not trigger the cryptography anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 43-79; Test Cases, lines 139-180",
"source": "eip.md",
"summary": "The result changes at leading-bit positions, zero has the special result 256, and the test vectors exercise zero and representative high and low boundaries."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "CLZ is one boundary-prone mechanism, principally around zero and each leading-bit transition. This matches anchor 1 rather than the multiple-mechanism anchors.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Specification, lines 39-44",
"source": "eip.md",
"summary": "The proposal only defines an EVM stack opcode and does not alter blocks."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP field or validation rule is introduced, so no client-syncing test mechanism changes and anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 39-44 and 111",
"source": "eip.md",
"summary": "The change is confined to opcode execution and its gas cost."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism changes; anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Specification, lines 39-44",
"source": "eip.md",
"summary": "EIP-7939 adds an opcode, not a contract or contract-mediated action."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 39-44; Security Considerations, lines 183-185",
"source": "eip.md",
"summary": "CLZ is a stateless stack operation with no system-contract action."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system-contract code, state, or behavior is directly or indirectly modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 41-44 and 111",
"source": "eip.md",
"summary": "One opcode, CLZ at 0x1e, pops one word, pushes one word, and has constant gas cost 3."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This is exactly one simple opcode with no data portion, no complex stack mechanics, and a constant gas cost, matching anchor 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, line 41; Backwards Compatibility, lines 135-137",
"source": "eip.md",
"summary": "CLZ is expressly introduced as a new opcode that was not present before."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode behavior is modified or deprecated, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Specification, line 41",
"source": "eip.md",
"summary": "The feature is an opcode at byte 0x1e, not a precompile address."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 39-44 and 111",
"source": "eip.md",
"summary": "Only new opcode semantics and that opcode's cost are specified."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile behavior or gas schedule is modified; anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 39-44",
"source": "eip.md",
"summary": "CLZ operates on an already-decoded EVM stack word and adds no external encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, RLP, SSZ, or interface encoding changes are introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Specification, lines 39-44",
"source": "eip.md",
"summary": "The proposal adds only an opcode and defines no transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 39-44 and 111",
"source": "eip.md",
"summary": "The specified rules concern execution of CLZ and its fixed execution gas only."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity and intrinsic-gas calculation are unchanged, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 13-15; Specification, lines 39-44",
"source": "eip.md",
"summary": "The proposal is limited to an execution opcode and specifies no block data."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 135-137; Security Considerations, lines 183-185",
"source": "eip.md",
"summary": "CLZ is merely absent before introduction and is stateless."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation requires no state transition or modification of an existing internal variable at the activation block, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale - Gas cost, lines 127-133; Security Considerations, lines 183-185",
"source": "eip.md",
"summary": "CLZ is benchmarked directly against ADD and is described as having low, worst-case constant compute, memory, and proving costs."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new execution mechanism warrants isolated benchmarking to substantiate its gas price, but it is self-contained and does not alter existing performance behavior. This matches anchor 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 183-185",
"source": "eip.md",
"summary": "The EIP describes CLZ as stateless with bounded low memory, compute, and proving cost, and concludes it is not exploitable for denial of service."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The new consensus operation must be implemented consistently, but its security surface is self-contained, independently testable, and does not alter existing state or stakeholder invariants. This matches anchor 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 41-111",
"source": "eip.md",
"summary": "The opcode byte, stack effect, result over a 256-bit word including zero, and gas cost are specified, with equivalent reference algorithms."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "For every possible EVM word, the specification determines the CLZ result and supplies the execution metadata needed for testing. No constructible case needs an additional cross-client semantic agreement, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 39-44; Backwards Compatibility, lines 135-137",
"source": "eip.md",
"summary": "CLZ is defined as a standalone new opcode; the proposal identifies no EIP dependency, modification, or conflict."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The opcode can be specified and tested independently and no interacting EIP is established by the historical text, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
}
],
"eip": 7939,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7939:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "c43098e67b8fd94c5166bd7a46ec53cafac04123",
"committed_at": "2025-06-09T10:17:58Z",
"content_sha256": "8f03612a4d1903cebe96bef61ffffb2a392a6301ee024a43f2adb8c18848ab5b",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7939.md",
"git_blob_sha": "1a4aed0bca3a74bc2caa37c16514098e3d072a8c",
"immutable_url": "https://github.com/ethereum/EIPs/blob/c43098e67b8fd94c5166bd7a46ec53cafac04123/EIPS/eip-7939.md",
"information_cutoff_at": "2025-07-02T17:49:36Z",
"path": "EIPS/eip-7939.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7939.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7939.yaml",
"sha256": "c87c3c2649da3926cb9b4ef3e5a12f989a7fd496455abb8f46fa434c4c348521"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 6,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7939 proposed one new execution-layer opcode, CLZ at byte 0x1e, that consumes one 256-bit stack word and returns its count of leading zero bits, with zero explicitly returning 256. The opcode is stateless, has no data portion or dynamic stack behavior, and has a fixed gas cost of 3; the proposal also supplied reference algorithms and representative boundary test cases.",
"tier": "low",
"title": "Count leading zeros (CLZ) opcode",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 6,
"minimum": 6
},
"present": false,
"summary": "No material behavioral under-specification is present. The opcode byte, stack effect, result for the complete 256-bit input domain including zero, and fixed gas cost are all determined by the historical proposal.",
"unresolved_questions": []
}
},
"osaka:7951:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Precompile and Gas Schedule, lines 33-35 and 157-167",
"source": "eip.md",
"summary": "The proposal assigns the new precompile a fixed cost of 3450 gas and requires invalid inputs and failed verification to consume the same amount as success."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This adds a gas-schedule entry using the existing fixed-cost precompile charging model. It updates an existing gas-accounting mechanism rather than introducing a new dynamic accounting mechanism, matching score 1.",
"score": 1,
"uncertainty_note": "The score treats addition to the fixed precompile cost schedule as an update to the existing mechanism, rather than as a wholly new gas mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and Signature Verification Algorithm, lines 33-35 and 112-147",
"source": "eip.md",
"summary": "The introduced operation reads only its call input and performs elliptic-curve verification; no state access or state-relative gas-charging step is specified."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state access, state-access recording, or ordering of a gas charge relative to state access changes, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and Gas Schedule, lines 33-35 and 157-167",
"source": "eip.md",
"summary": "The only gas rule specified is a fixed execution-gas cost for P256VERIFY; blobs and blob gas are not part of the operation."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "ABI and Gas Schedule, lines 83-167",
"source": "eip.md",
"summary": "The precompile consumes fixed execution gas for computation and specifies no state write, state-gas charge, budget, reservoir, or spill behavior."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas cost or state-gas charging mechanism changes, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Schedule, lines 157-167",
"source": "eip.md",
"summary": "The EIP defines a fixed charge and equal gas consumption for success and failure, without defining any refund condition."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility and Interface Compatibility, lines 192-206",
"source": "eip.md",
"summary": "The proposal preserves the RIP-7212 address, input, output, gas cost, and return interface, while stating that its security fixes change only edge cases that should previously have failed."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing cases aimed at the 0x100 address or the compatible RIP-7212 interface need only localized expected-result updates for the corrected edge cases. That is a minor subset of pre-existing tests, matching score 1.",
"score": 1,
"uncertainty_note": "The EIP does not enumerate the pre-existing execution test inventory; the score is limited to tests that exercise address 0x100 or reuse the stated compatible interface and edge cases.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases and Backwards Compatibility, lines 192-210",
"source": "eip.md",
"summary": "The text calls for implementation-specific verification vectors and localized compatibility behavior, but does not require unrelated pre-existing tests to assert any new fork-wide value or invariant."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing tests gain no additional universal assertion, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and ABI, lines 33-35 and 83-110",
"source": "eip.md",
"summary": "The complete external surface described is a precompile call input and output; no transition-tool field or invocation mechanism is specified."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or mechanism is required, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "ABI and Test Cases, lines 83-110 and 208-210",
"source": "eip.md",
"summary": "The feature is exercised through a fixed byte input and a success-or-empty byte output, and the EIP points to ordinary test vectors rather than a new kind of expectation or framework modifier."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing precompile-call, output, and gas-check primitives suffice for the stated interface, so no new test-framework abstraction is required, matching score 0.",
"score": 0,
"uncertainty_note": "The linked vector file was not an allowlisted package source, but its absence does not establish a need for a new framework primitive.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, Curve Parameters, and Cryptographic Security, lines 13-17, 37-53, and 216-220",
"source": "eip.md",
"summary": "The EIP introduces secp256r1 ECDSA verification, supplies standardized curve parameters, and describes the curve as standardized, extensively analyzed, and already widely deployed."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "It introduces one well-known cryptographic mechanism with substantial existing specification and testing resources, exactly matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Input Validation and Signature Verification Algorithm, lines 102-147",
"source": "eip.md",
"summary": "The operation separately checks exact length, r and s order bounds, coordinate field bounds, curve membership, public-key infinity, recovered-point infinity, and an x-coordinate comparison modulo n."
},
{
"locator": "Error Cases and Security Fixes, lines 149-177",
"source": "eip.md",
"summary": "The listed invalid-input classes include several numeric and elliptic-curve boundaries, while the rationale identifies rare infinity and x-coordinate-over- order cases whose mishandling can change verification results."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple independent boundary-prone mechanisms are present, and the recovered infinity and modular-reduction paths require specially constructed cryptographic cases in addition to ordinary adjacent-boundary vectors. This elevated case set matches score 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and ABI, lines 33-35 and 83-110",
"source": "eip.md",
"summary": "The proposal adds call-time verification behavior and contains no block RLP or block-validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and ABI, lines 33-35 and 83-110",
"source": "eip.md",
"summary": "The only introduced interface is the EVM-callable P256VERIFY input and output; no Engine API endpoint, field, or communication mechanism appears."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile, lines 33-35",
"source": "eip.md",
"summary": "The EIP explicitly introduces P256VERIFY as a precompile at address 0x100, not as deployed system-contract code or state."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "A precompile is scored under the dedicated precompile criterion; the proposal adds no system contract, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and Backwards Compatibility, lines 33-35 and 192-206",
"source": "eip.md",
"summary": "The proposal adds native precompile behavior and discusses caller interface compatibility, without changing any pre-existing system-contract code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or indirect system-contract modification is specified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile, lines 33-35",
"source": "eip.md",
"summary": "The new operation is assigned a precompile address and is not assigned an opcode byte or stack semantics."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and ABI, lines 33-35 and 83-110",
"source": "eip.md",
"summary": "P256VERIFY is reached as a precompile call, and the EIP does not alter the result semantics of CALL or any other pre-existing opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile, ABI Input, and Gas Schedule, lines 33-35, 85-93, and 157-167",
"source": "eip.md",
"summary": "The EIP adds one P256VERIFY precompile at address 0x100 with exactly 160 input bytes and a constant 3450-gas charge for both success and failure."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "One precompile with constant input length and constant gas cost is a simple precompile under the anchor, exactly matching score 1; cryptographic complexity is scored separately.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Precompile and Backwards Compatibility, lines 33-35 and 192-206",
"source": "eip.md",
"summary": "The text introduces a new precompile while preserving compatibility with the separately identified RIP-7212 interface; it does not change an already existing Ethereum precompile address, gas schedule, or behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Compatibility and corrected semantics relative to RIP-7212 do not modify a pre-existing precompile in this proposal's execution-layer scope, matching score 0.",
"score": 0,
"uncertainty_note": "The EIP describes behavioral security fixes relative to deployed Layer 2 RIP-7212 implementations, but frames P256VERIFY as newly introduced here.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Points and Encoding and ABI, lines 61-100",
"source": "eip.md",
"summary": "The EIP defines fixed byte encodings internal to the new precompile call but no transaction, block, Engine API, RLP, or SSZ encoding change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "A new precompile's byte ABI is not a transaction, block, or protocol-interface RLP/SSZ encoding migration, so the anchor remains score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and ABI, lines 33-35 and 83-100",
"source": "eip.md",
"summary": "The proposal adds functionality invoked through a precompile call and defines no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Input Validation and Gas Burning on Error, lines 102-110 and 165-167",
"source": "eip.md",
"summary": "Validation applies only inside P256VERIFY, and invalid precompile inputs return empty output rather than making the containing transaction intrinsically invalid."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic gas calculation changes, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile and ABI, lines 33-35 and 83-100",
"source": "eip.md",
"summary": "The proposal's data is supplied as precompile call input and no block-body or header field is defined."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Precompile, lines 33-35",
"source": "eip.md",
"summary": "The EIP defines availability of a new precompile address but specifies no activation-block state write, migration, or modification of an internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary activation of new execution behavior is not the state or internal-variable modification targeted by this anchor, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas Schedule and Gas Cost Justification, lines 157-163 and 188-190",
"source": "eip.md",
"summary": "The new verification operation has a fixed input and fixed cost, and the EIP justifies that cost using isolated benchmarking against ECRECOVER."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The introduced computation requires performance validation but can be benchmarked independently without changing existing performance behavior, exactly matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Fixes and Security Considerations, lines 171-177 and 216-228",
"source": "eip.md",
"summary": "The text identifies recovered-infinity and modular-comparison errors as capable of incorrect or non-deterministic verification, while characterizing the curve as standardized and documenting malleability and constant-time expectations."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect implementation could affect consensus or users, but the fixed-input verifier is self-contained, can be validated in isolation, and does not alter an existing protocol security invariant. This matches score 1.",
"score": 1,
"uncertainty_note": "The consensus-failure consequence makes the review important, but the EIP text does not specify interactions with multiple existing critical components that would support the higher anchors.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Fields and Groups, Scalar Encoding, and ABI Input, lines 55-59, 75-77, and 85-93",
"source": "eip.md",
"summary": "Field elements and scalars receive explicit big-endian integer encodings, but the 32-byte message hash h is listed separately and is then used as a scalar in the verification algorithm without an explicit byte-to-integer rule."
},
{
"locator": "Gas Burning on Error, lines 165-167",
"source": "eip.md",
"summary": "The EIP says the precompile must not revert under any circumstances while also assigning a fixed cost, leaving insufficient-gas behavior to the obvious existing precompile execution convention rather than stating an exception."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "These are a few localized specification gaps with obvious intended readings: interpret h consistently with the stated big-endian scalar convention and retain ordinary insufficient-gas call behavior. They therefore match score 1 rather than requiring broad re-baselining.",
"score": 1,
"uncertainty_note": "If the surrounding encoding and ordinary precompile gas conventions are deemed fully determinative, score 0 is plausible; if explicit client agreement is needed before vectors can be baselined, score 2 is plausible.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Backwards Compatibility, lines 25-27 and 192-206",
"source": "eip.md",
"summary": "EIP-7951 explicitly supersedes RIP-7212, preserves its address, byte interface, gas cost, and return values, and changes only two security-sensitive edge cases."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7212
],
"rationale": "The sole interaction is a limited compatibility relationship with proposal 7212. Interface and corrected-edge vectors need coordinated consideration, but the new precompile can otherwise be tested independently, matching score 1.",
"score": 1,
"uncertainty_note": "The referenced proposal is designated RIP-7212 rather than a mainline EIP, but it is the only numbered proposal with an explicit behavioral and interface coupling in the historical text.",
"under_specified": false
}
],
"eip": 7951,
"evaluation_date": "2026-08-21",
"fork": "osaka",
"id": "osaka:7951:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The byte-to-integer interpretation of message hash h is implied but not stated explicitly.",
"The unconditional no-revert wording does not explicitly distinguish insufficient supplied gas."
],
"provenance": {
"assessed_revision": {
"commit": "d386b29b5a31bd5cfd8d21bbf4e8a0c87734085e",
"committed_at": "2025-07-01T20:21:20Z",
"content_sha256": "4fca0c5daef344b79ec1d19297ecf6a36f41bf31e02a29038a05701948aeebed",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7951.md",
"git_blob_sha": "f4600e688beaeaf11fa6292ea3477e9ca3febe56",
"immutable_url": "https://github.com/ethereum/EIPs/blob/d386b29b5a31bd5cfd8d21bbf4e8a0c87734085e/EIPS/eip-7951.md",
"information_cutoff_at": "2025-07-02T17:49:36Z",
"path": "EIPS/eip-7951.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7951.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/osaka/eip-7951.yaml",
"sha256": "003238621a43b1cd0c1e7edf25cd4bc01e666c3f288a461891e269bcd8a3b52f"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 11,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this draft introduced P256VERIFY at address 0x100, accepting exactly 160 input bytes for secp256r1 ECDSA verification and charging a fixed 3450 gas. It specified the curve parameters, encodings, validation checks, verification algorithm, fixed success and failure outputs, and uniform gas consumption on invalid inputs. It aimed to retain RIP-7212 interface compatibility while correcting recovered-point-at-infinity and modular-comparison edge cases; it specified no transaction, block, state, Engine API, or opcode changes.",
"tier": "low",
"title": "Precompile for secp256r1 Curve Support",
"under_specification": {
"affected_criteria": [
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 12,
"minimum": 10
},
"present": true,
"summary": "The specification is materially complete for most constructible cases, but it does not expressly state how the 32-byte message hash becomes the integer used in scalar multiplication, and its absolute no-revert wording does not expressly carve out insufficient supplied gas. Both gaps are localized and have strong intended readings from the adjacent encoding and gas rules.",
"unresolved_questions": [
"Is message hash h decoded as an unsigned big-endian integer before scalar multiplication?",
"Does the no-revert requirement apply only after the fixed precompile gas cost has been supplied?"
]
}
},
"prague:2537:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-28",
"source": "eip.md",
"summary": "The proposal assigns fixed costs to six new precompiles and formula-based costs to three new precompiles."
},
{
"locator": "Gas schedule clarifications for the variable-length input, lines 271-310",
"source": "eip.md",
"summary": "Multiexponentiation and pairing receive new input-length-based gas functions with explicit floor-division behavior."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The EIP introduces new gas-cost functions for new precompiles, including dynamic accounting, without changing an existing gas mechanism. This matches anchor 2.",
"score": 2,
"uncertainty_note": "The two stated pairing gas formulas conflict, but both establish that a new dynamic gas rule is intended.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "The change consists of stateless curve-operation precompiles and describes no state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state access or gas-charge ordering relative to state access is changed, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "The proposal is limited to curve-operation precompiles and their execution-gas prices; it introduces no blob mechanism."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "All introduced operations compute cryptographic results and no operation writes state."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal adds no state write cost, state-gas budget, reservoir, or spill rule, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas burinig on error, lines 217-219",
"source": "eip.md",
"summary": "A failed call burns all gas supplied with CALL or STATICCALL; no refund is specified."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Proposed addresses table, lines 18-28 and 34-46",
"source": "eip.md",
"summary": "Fork activation introduces precompile behavior at nine specified addresses."
},
{
"locator": "Backwards Compatibility, lines 320-322",
"source": "eip.md",
"summary": "The EIP states that there are no backward-compatibility questions."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests that call one of the nine newly assigned addresses as an ordinary account can change at activation, but this is a narrow, address-specific subset. That limited reworking matches anchor 1.",
"score": 1,
"uncertainty_note": "The EIP asserts compatibility but does not inventory pre-existing tests using the assigned addresses.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 334-355",
"source": "eip.md",
"summary": "The listed assertions are properties and benchmarks for the new curve operations, not added assertions for unrelated tests."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Tests unrelated to this EIP gain no new invariant to assert, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "Activation and operation are defined within execution using fixed precompile addresses; no external transition-tool field is defined."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or mechanism is required by the proposal, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Test Cases, lines 334-355",
"source": "eip.md",
"summary": "Testing is expressed as ordinary operation properties and externally supplied benchmark vectors, with no new expectation or modifier abstraction specified."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The proposal establishes a large test-data space but does not require a new test-framework primitive, matching anchor 0.",
"score": 0,
"uncertainty_note": "The EIP does not describe the test framework, so this score assumes its stated properties can be represented by existing call and assertion primitives.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract, lines 18-32",
"source": "eip.md",
"summary": "Nine calls expose G1 and G2 arithmetic, multiexponentiation, pairing, and two field-to-curve mappings for BLS and SNARK verification."
},
{
"locator": "Specification and Test Cases, lines 54-84 and 334-351",
"source": "eip.md",
"summary": "The EIP fixes BLS12-381 parameters and supplies algebraic properties for testing group and pairing operations."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The proposal introduces multiple distinct cryptographic mechanisms—curve arithmetic, multiexponentiation, pairing, and mapping—on a fully parameterized named curve. They are presented as established mechanisms with property tests and reference implementations, matching anchor 2 rather than the novel-mechanism anchor.",
"score": 2,
"uncertainty_note": "The unavailable mapping document prevents assessing the mapping algorithm's completeness and resource base directly.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Fine points and encoding of base elements, lines 88-116",
"source": "eip.md",
"summary": "Inputs must cover modulus limits, zero-padding, Fp2 coefficient order, infinity encoding, unrestricted scalars, and rejection of empty variable-length input."
},
{
"locator": "Gas schedule, lines 245-310",
"source": "eip.md",
"summary": "Dynamic costs add pair-count floor division, invalid partial slices, a 128-entry discount boundary and cap, and zero-pair handling."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Several independent boundary-prone mechanisms are introduced, and the variable-length calls require an elevated matrix across lengths, partial slices, discount thresholds, validity, and gas. This matches anchor 3.",
"score": 3,
"uncertainty_note": "The absent mapping specification may contain additional edge cases beyond those scoreable here.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "The proposal adds execution precompiles and no block RLP field or validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "The change is wholly within execution precompile calls and defines no Engine API field or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API communication change is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Proposed addresses table, lines 18-28 and 34-46",
"source": "eip.md",
"summary": "The nine new address-bound mechanisms are explicitly precompiles, not deployed system contracts."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Precompiles do not constitute added system contracts under this anchor, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "The scope contains only new precompiles and does not identify any existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract code, state, or behavior is modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "Functionality is introduced through precompile addresses rather than new opcode assignments."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Gas burinig on error, lines 217-219",
"source": "eip.md",
"summary": "The new precompiles are invoked through existing CALL or STATICCALL behavior; the text does not change either opcode's result rules generally."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Adding new precompile targets does not modify or deprecate an existing opcode under this anchor, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Proposed addresses table, lines 18-28 and 34-46",
"source": "eip.md",
"summary": "Nine separately addressed precompiles are introduced for distinct G1, G2, pairing, and mapping operations."
},
{
"locator": "ABI for operations and Gas schedule, lines 118-215 and 245-310",
"source": "eip.md",
"summary": "The precompiles have multiple input and output shapes, and three accept variable-length input with dynamic gas."
}
],
"exceptional_score_justification": "Nine distinct precompiles, including three complex dynamic-input operations and two externally specified mappings, materially exceed the quantity and test-surface represented by the ordinary score-3 anchor.",
"id": "added_precompiles",
"rationale": "The EIP is well beyond the anchor-3 threshold of multiple precompiles with at least one complex member: it adds nine ABIs, three variable-length operations, two field encodings, and several different output and validation rules.",
"score": 4,
"uncertainty_note": "The field-to-curve behavior cannot be fully evaluated because its linked specification is absent.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Proposed addresses table, lines 34-50",
"source": "eip.md",
"summary": "New addresses are assigned for BLS12-381; the existing BN254 precompile is mentioned only as a security comparison."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas schedule is modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Fine points and encoding of base elements, lines 88-112",
"source": "eip.md",
"summary": "The only new encodings are call-data representations for field elements, points, infinity, and scalars."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "These precompile input ABIs do not change transaction, block, or protocol-interface RLP/SSZ encoding, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "The proposal adds callable precompiles and does not define a transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "ABI for operations, lines 118-215",
"source": "eip.md",
"summary": "Validation rules apply to precompile call data and curve inputs, not to transaction validity or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity and intrinsic-gas rules are unchanged, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-30",
"source": "eip.md",
"summary": "The proposal activates address-bound execution behavior without adding a block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 18-19",
"source": "eip.md",
"summary": "The nine precompiles become available when the block number reaches a placeholder activation value."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Activation enables new functionality but performs no state or existing internal-variable modification at the activation block, matching anchor 0.",
"score": 0,
"uncertainty_note": "The activation value is left as X, but that does not create the state-modification mechanism scored by this anchor.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "DDoS protection and Gas schedule, lines 221-249",
"source": "eip.md",
"summary": "Prices are tied to computational time and worst cases, and multiexponentiation pricing assumes a particular efficient algorithm."
},
{
"locator": "Benchmarking test cases, lines 353-355",
"source": "eip.md",
"summary": "The EIP calls for dedicated benchmark vectors for new implementations."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new cryptographic calls require benchmarking, but each precompile can be benchmarked in isolation and does not modify existing performance paths. This matches anchor 1.",
"score": 1,
"uncertainty_note": "The linked benchmark vectors and mapping algorithms are not in the sealed package, limiting validation of the pricing assumptions.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "ABI for pairing and Important notes, lines 182-197 and 324-332",
"source": "eip.md",
"summary": "Pairing inputs require curve and subgroup validation, and the EIP makes subgroup checks mandatory while recommending faster methods."
},
{
"locator": "Security Considerations, lines 364-368",
"source": "eip.md",
"summary": "The EIP identifies consensus implications of deviating from the specification and explicitly permits non-constant-time algorithms."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect cryptographic validation could create security or consensus risk, but the mechanisms are isolated behind new precompile calls and do not alter an existing protocol invariant. This matches anchor 1.",
"score": 1,
"uncertainty_note": "The missing mapping specification and contradictory pairing pricing prevent complete isolated review of all security and resource-exhaustion behavior.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Field to curve mapping, lines 30 and 330-332",
"source": "eip.md",
"summary": "The two mapping precompiles depend on algorithms and parameters contained only in a separately linked document."
},
{
"locator": "Pairing operation and Gas schedule clarifications for pairing, lines 259-261 and 295-310",
"source": "eip.md",
"summary": "The document specifies pairing cost once as 43000*k + 65000 and later as 23000*k + 115000."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Tests cannot baseline the mapping outputs from the packaged EIP alone, and clients must choose between incompatible normative pairing gas formulas. These material but localized issues require agreement before vectors can be authoritative, matching anchor 2.",
"score": 2,
"uncertainty_note": "The activation placeholder X is also unresolved, although fork configuration could supply it without changing operation semantics.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility and Reference Implementation, lines 320-322 and 357-362",
"source": "eip.md",
"summary": "The EIP states no backward-compatibility issue; EIP-1962 is mentioned only as a source-code basis for one implementation."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The protocol proposal neither depends on, modifies, nor conflicts with another numbered EIP. Reuse of EIP-1962 implementation code is not a protocol-level interaction, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "Existing BN254 and Blake2f precompiles are cited as comparisons or precedents, but the text specifies no dependency on or modification to them.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 2537,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:2537:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The EIP's main pairing-price section conflicts with its later gas-calculation pseudocode.",
"The normative field-to-curve content is outside the packaged historical text.",
"The text mandates an error for invalid inputs but does not explicitly define an output-data convention for failure.",
"EIP-1962 is named as an implementation code basis, not as a protocol dependency."
],
"provenance": {
"assessed_revision": {
"commit": "ef0a1320a0a1143abd2abb84093d511d0b0602b4",
"committed_at": "2023-06-22T22:51:34Z",
"content_sha256": "01f59dd7a868f2b8e5171a5fb70ad7101496279604c0c74b5f91dec64b4d46f6",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2537.md",
"git_blob_sha": "14b9858c8eb2107249db8821f3f39961fd9a65b8",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ef0a1320a0a1143abd2abb84093d511d0b0602b4/EIPS/eip-2537.md",
"information_cutoff_at": "2024-01-18",
"path": "EIPS/eip-2537.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-2537.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-2537.yaml",
"sha256": "85850ca607bd7530951cd4aaf870bfb96862d5e14ab1de281c9ca1aec90da14f"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 16,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-2537 proposed nine precompiles at addresses 0x0c through 0x14 for BLS12-381 G1/G2 addition, multiplication, multiexponentiation, pairing, and field-to-curve mapping. It specified field and point encodings, call ABIs, validation and error behavior, and fixed or input-length-dependent gas schedules. The mapping algorithms were delegated to a separately linked document that is not present in the sealed package, while two sections gave conflicting pairing gas formulas.",
"tier": "medium",
"title": "Precompile for BLS12-381 curve operations",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"cryptography",
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 20,
"minimum": 15
},
"present": true,
"summary": "The packaged EIP does not contain the algorithms and parameters needed to determine the outputs of its two mapping precompiles, instead referring to a separate document. It also gives two incompatible pairing gas formulas and leaves the activation block as X. The first two gaps require a normative resolution before complete cross-client vectors can be baselined.",
"unresolved_questions": [
"Which algorithm and parameter set normatively determines the outputs of BLS12_MAP_FP_TO_G1 and BLS12_MAP_FP2_TO_G2?",
"Is the pairing gas cost 43000*k + 65000 or 23000*k + 115000?",
"Which activation block replaces X?",
"Does invalid input return only call failure with all supplied gas burned, or is any output-data convention also required?"
]
}
},
"prague:2935:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The specification introduces a block-level storage write and changes the value returned by BLOCKHASH, but states no opcode gas-cost or gas-accounting rule."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas accounting change is specified, so the score follows the zero anchor; uncertainty about how the newly mentioned storage read participates in gas accounting is recorded separately as under-specification.",
"score": 0,
"uncertainty_note": "The text does not state whether the internal storage read changes BLOCKHASH gas charging.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 32-35",
"source": "eip.md",
"summary": "BLOCKHASH, previously described as history-accessing, is changed to obtain qualifying results through sload at the reserved address."
},
{
"locator": "State-access ordering within opcode execution, lines 27-40",
"source": "rubric.md",
"summary": "The anchor assigns one point when the state-access or gas-charge ordering of a single opcode changes."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "A single existing opcode acquires a state access, so its execution path and the position of that access relative to gas charging must be settled; this matches the single-opcode score-1 anchor.",
"score": 1,
"uncertainty_note": "The EIP specifies the returned value but not whether the read has ordinary SLOAD access-ordering or access-list side effects.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Simple Summary and Specification, lines 12-35",
"source": "eip.md",
"summary": "The proposal is confined to historical block-hash storage and BLOCKHASH behavior and introduces no blob mechanism."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting rule is introduced or modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "Although the proposal writes state, it defines no state-gas rate, budget, reservoir, charging site, or execution-gas spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "A state write alone does not trigger this anchor's separate state-gas-accounting category; no such accounting mechanism is specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The two specified operations contain no refund rule or refund-producing condition."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility, lines 45-47",
"source": "eip.md",
"summary": "BLOCKHASH gains a larger range while behavior in the previous 256-block range is intended to remain unchanged."
},
{
"locator": "Specification, lines 32-35",
"source": "eip.md",
"summary": "Only BLOCKHASH cases outside its former range and post-fork block processing receive changed behavior."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests that assume old BLOCKHASH results beyond 256 blocks form a narrow subset requiring changed expectations; most opcode behavior remains unchanged, fitting the minor-subset anchor.",
"score": 1,
"uncertainty_note": "The Test Cases section is TBD, so the exact inventory of affected existing vectors is not described.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 27-35",
"source": "eip.md",
"summary": "Every block after the fork boundary performs a pre-transaction write of the preceding block hash to the reserved address."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Every post-activation block produces an additional state update irrespective of its transactions, so carried-forward block/state tests must account for the history slot and resulting state in addition to their original subject; this is the universal fork-test invariant described by score 3.",
"score": 3,
"uncertainty_note": "The EIP does not provide tests or specify which fixture formats directly assert the resulting state.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 27-35",
"source": "eip.md",
"summary": "The operation uses block number and previous hash already named in block processing and defines no new external transition-tool field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface field or communication mechanism is specified, matching the zero anchor, even though the transition implementation must perform a new action.",
"score": 0,
"uncertainty_note": "The EIP does not discuss transition-tool inputs or whether fork-activation awareness would require an interface extension.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Test Cases, lines 25-35 and 49-51",
"source": "eip.md",
"summary": "The behavior is expressible as block processing, storage state, and opcode output, while the proposal requests no new test abstraction and leaves cases TBD."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The text establishes no need for a new expectation, modifier, or reusable framework primitive; existing block, state, and opcode assertions appear sufficient, so the zero anchor is best supported.",
"score": 0,
"uncertainty_note": "With test cases absent, a minor helper for the pre-transaction system write could later prove useful.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Simple Summary and Specification, lines 12-35",
"source": "eip.md",
"summary": "The EIP stores and retrieves existing block hashes but defines no hashing algorithm or other cryptographic mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Using already-produced block hashes as values does not introduce or modify cryptographic functionality, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 27-35",
"source": "eip.md",
"summary": "The rules contain a strict fork-block boundary, a second boundary 256 blocks later, and lower and upper bounds on the BLOCKHASH argument."
},
{
"locator": "Backwards Compatibility, lines 45-47",
"source": "eip.md",
"summary": "The old 256-block window must remain unchanged while the accessible range expands."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple off-by-one-prone boundaries interact: before/at/after activation, before/at/after the 256-block delay, and arguments below, at, within, or beyond the allowed interval. Their cross-product requires an elevated case set, matching score 3.",
"score": 3,
"uncertainty_note": "The exact FORK_BLKNUM value is TBD, but the relative boundaries are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The proposal changes block processing and an opcode but adds no block RLP field or RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block-RLP validation mechanism requiring sync testing is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "No Engine API endpoint, field, or communication mechanism appears in the specified changes."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The EIP introduces no Engine API change, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Simple Summary and Specification, lines 12-15 and 25-35",
"source": "eip.md",
"summary": "The proposal calls for a contract at a reserved address whose storage receives a new block-hash slot in every post-boundary block."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "This is one new stateful system contract/address, which directly matches the score-2 anchor for a single stateful system contract.",
"score": 2,
"uncertainty_note": "The text specifies storage at the address but does not define deployed code or account initialization details.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Simple Summary and Specification, lines 12-15 and 25-35",
"source": "eip.md",
"summary": "The history-storage address is introduced for this mechanism; no pre-existing system contract is named or altered."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal adds its own stateful system address rather than modifying a pre-existing system contract, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Simple Summary, lines 12-15",
"source": "eip.md",
"summary": "The proposal modifies the existing BLOCKHASH opcode and assigns no new opcode number."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-35",
"source": "eip.md",
"summary": "After the delay, BLOCKHASH returns stored hashes for a new argument range instead of applying its previous behavior."
},
{
"locator": "Backwards Compatibility, lines 45-47",
"source": "eip.md",
"summary": "The EIP explicitly states that the opcode's range is increased."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least one existing opcode has a non-gas behavioral change, which is the rubric's binary score-3 condition.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Simple Summary and Specification, lines 12-35",
"source": "eip.md",
"summary": "The proposal uses a protocol-managed storage address and modifies BLOCKHASH; it defines no callable precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Simple Summary and Specification, lines 12-35",
"source": "eip.md",
"summary": "No existing precompile or precompile gas schedule is named or changed."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The changes concern state storage and opcode lookup and introduce no transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other transaction/block/interface encoding change is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The proposal defines no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The pre-transaction history write and BLOCKHASH behavior add no transaction validity or intrinsic-gas condition."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No existing transaction validity rule or intrinsic gas calculation is modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The rule consumes the existing previous-block hash and block number and adds no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block/header field is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 27-35",
"source": "eip.md",
"summary": "At the first block satisfying block.number greater than FORK_BLKNUM, a new pre-transaction storage modification begins; the opcode transition follows 256 blocks later."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The feature's activation directly initiates a protocol-level state modification at the first active block, satisfying the score-3 anchor; this is not merely initialization of an internal variable.",
"score": 3,
"uncertainty_note": "The numeric fork parameter is TBD, and the strict-greater-than wording makes the named boundary one block earlier than the first write.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 57-59",
"source": "eip.md",
"summary": "The EIP estimates about 2.5 million additional storage slots per year and acknowledges state bloat, while characterizing it as small relative to existing state."
},
{
"locator": "Specification, lines 32-35",
"source": "eip.md",
"summary": "A state write occurs every block and qualifying BLOCKHASH executions perform a state read."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Cumulative state growth and a mandatory write on every block cannot be assessed wholly as an isolated opcode microbenchmark, but the proposal characterizes the impact as limited relative to existing state; this fits score 2.",
"score": 2,
"uncertainty_note": "No benchmarks or quantitative processing-cost analysis are supplied.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 16-23",
"source": "eip.md",
"summary": "The returned historical hashes are intended to support historical-data protocols and more secure light-client constructions."
},
{
"locator": "Specification and Security Considerations, lines 25-35 and 57-59",
"source": "eip.md",
"summary": "Correctness spans pre-transaction state mutation, stored block hashes, changed opcode results, and persistent state growth."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches a limited but consensus-critical set of components: block processing, state, and an opcode whose values may be consumed by contracts and light-client schemes. Targeted review and adversarial testing are warranted, matching score 2 rather than an extensive multi-component redesign.",
"score": 2,
"uncertainty_note": "The Security Considerations section discusses state growth but does not analyze incorrect or mutable history entries, reserved-address behavior, or opcode-read side effects.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 25-35",
"source": "eip.md",
"summary": "The EIP uses sstore and sload-like notation for protocol and opcode behavior without specifying gas charging, access-list effects, account initialization, or collision handling at the reserved address."
},
{
"locator": "Test Cases and Implementation, lines 49-55",
"source": "eip.md",
"summary": "Both test cases and implementation are explicitly TBD at this revision."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A formerly history-only opcode now performs a state-backed lookup whose gas/access side effects can be observed by constructed executions, yet those effects are not determined. This makes newly observable behavior consensus-critical and requires cross-client baselining, matching score 3.",
"score": 3,
"uncertainty_note": "It is unclear whether sload denotes an ordinary EVM-style access with warming and gas consequences or only an implementation-level raw state lookup; the system-address account semantics are also unstated.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, lines 36-43",
"source": "eip.md",
"summary": "The proposal identifies EIP-98 and EIP-210 as earlier similar designs and deliberately removes their tree structure and EVM-code approach."
},
{
"locator": "Security Considerations, lines 57-59",
"source": "eip.md",
"summary": "The mechanism is described as temporary because a future eth1/eth2 merge and built-in history accumulator would likely repurpose BLOCKHASH."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
98,
210
],
"rationale": "The relationship to two identified predecessor designs and an unidentified future history-accumulator transition is limited and non-critical to independent testing of this EIP, matching score 1 rather than a coordinated dependency score.",
"score": 1,
"uncertainty_note": "The future merge/history-accumulator interaction is described without an EIP number, so no number is inferred.",
"under_specified": false,
"unidentified_interactions": [
"Future eth1/eth2 merge use of a built-in history accumulator that would likely repurpose BLOCKHASH."
]
}
],
"eip": 2935,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:2935:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The EIP alternates between describing storage in a contract and using protocol-level sstore(address, key, value) notation without defining contract code or account setup.",
"The historical title says Save historical block hashes in state, while the sealed assignment metadata says Serve historical block hashes from state; the populated assignment provenance is preserved.",
"The opcode switch is delayed until block.number is greater than FORK_BLKNUM plus 256, whereas history storage starts after FORK_BLKNUM."
],
"provenance": {
"assessed_revision": {
"commit": "9e393a79d9937f579acbdcb234a67869259d5a96",
"committed_at": "2022-05-06T07:29:09Z",
"content_sha256": "bcdb09d0585aa779acea7ae0b5ba1050f5a14fc5890c7e58a172621ee6838847",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-2935.md",
"git_blob_sha": "bbe12f21b04e063460618376eff66d4807b480a2",
"immutable_url": "https://github.com/ethereum/EIPs/blob/9e393a79d9937f579acbdcb234a67869259d5a96/EIPS/eip-2935.md",
"information_cutoff_at": "2024-04-11",
"path": "EIPS/eip-2935.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-2935.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-2935.yaml",
"sha256": "a18299f4999544c066c18707b359a8def51e175d05e6962d36ad63bd757ff510"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 24,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "The proposal writes each preceding block hash into storage at a reserved address before transaction processing in every block after the configured fork boundary. After a further 256-block delay, it changes BLOCKHASH to return stored hashes for prior fork-era blocks while retaining zero outside the specified range. The proposal explicitly leaves its fork number, tests, and implementation unfinished at the assessment-time revision.",
"tier": "high",
"title": "Serve historical block hashes from state",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 28,
"minimum": 20
},
"present": true,
"summary": "The state-backed BLOCKHASH lookup does not define whether its internal read has ordinary SLOAD gas, warming, or access-ordering effects, and the protocol-level write does not define initialization or collision semantics for the reserved address. Tests and implementation are TBD, leaving the handling of these observable cases to cross-client agreement.",
"unresolved_questions": [
"Does BLOCKHASH's state-backed lookup incur storage-access gas or change address/slot warmness, and when is that access recorded relative to its gas charge?",
"What account creation, initialization, and collision rules apply to HISTORY_STORAGE_ADDRESS?",
"Is the block-level sstore an unmetered protocol action, and how must transition tooling represent or assert it?",
"Does FORK_BLKNUM denote the last inactive block or the nominal activation block, given the strict greater-than condition?"
]
}
},
"prague:6110:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations -- DoS vectors, lines 211-217",
"source": "eip.md",
"summary": "The proposal uses the deposit contract's existing gas costs only to bound deposit volume and explicitly describes them as current gas-pricing rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas-accounting rule is introduced or updated, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Block validity, lines 100-158",
"source": "eip.md",
"summary": "The new validity work occurs after block execution by examining receipts and logs; the passage changes no opcode-internal state-access or gas-charge order."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode execution ordering changes, so the anchor-0 definition applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Extended Containers -- ExecutionPayload, lines 73-97",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"summary": "Existing data-gas members carry over and the only marked EIP-6110 payload addition is deposit_receipts."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal adds no blob-gas rule or mechanism, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Execution Layer, lines 31-158",
"source": "eip.md",
"summary": "The execution-layer changes concern deposit encoding, block fields, trie commitment, and validity; they define no charge for writing state."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-gas cost, charging site, budget, reservoir, or spill rule changes, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Execution Layer, lines 31-158",
"source": "eip.md",
"summary": "The complete execution-layer mechanism contains no gas-refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new refund mechanism is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Block structure and Block validity, lines 75-158",
"source": "eip.md",
"summary": "Every post-fork block gains a body list and header commitment, plus rules checking the commitment and exact ordered equivalence with execution logs."
},
{
"locator": "Backwards Compatibility, lines 197-199",
"source": "eip.md",
"summary": "The EIP explicitly calls both the block-structure and block-validation changes backwards incompatible."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork block tests across transaction, execution, static, invalid-block, and sync categories must be reworked for the extended block and derived validity rules. That is the diverse, major impact described by anchor 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Block structure and Block validity, lines 75-158",
"source": "eip.md",
"summary": "Post-fork blocks must carry a deposits root matching the body list, and that list must match deposit-contract logs even when a test targets an unrelated behavior."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of post-fork tests gains mechanically applicable root and list assertions, which fits anchor 2. The EIP does not require pre-fork vectors to acquire the post-fork fields, so anchor 3 is not supported.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification -- Block structure, lines 75-98",
"source": "eip.md",
"summary": "The transition result now includes both an ordered deposits body list and its deposits_root header commitment."
},
{
"locator": "Specification -- Block validity, lines 143-155",
"source": "eip.md",
"summary": "The list is derived from execution receipts and therefore must be exposed or derived by block-transition testing."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Representing the new list and root, together with their derived-output relationship, requires multiple interface values or a new result mechanism, fitting anchor 2.",
"score": 2,
"uncertainty_note": "The package does not define a transition-tool API, so the exact number and direction of interface fields are not fixed.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification -- Block structure and Block validity, lines 90-155",
"source": "eip.md",
"summary": "Tests need reusable operations for computing the indexed trie root, parsing deposit-event data, and comparing the derived ordered list."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing block-test primitives need minor helper or expectation extensions for deposits and their commitment, fitting anchor 1; the text does not establish a permanent cross-EIP framework primitive.",
"score": 1,
"uncertainty_note": "No test-framework design is packaged, so whether these are helpers or new reusable expectation primitives is unresolved.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "New process_deposit_receipt, lines 218-233",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"summary": "Receipt processing forwards the existing public key and signature fields into apply_deposit rather than defining a new cryptographic operation."
},
{
"locator": "Security Considerations -- Consensus layer, lines 219-223",
"source": "eip.md",
"summary": "Signature verification is analyzed as the existing costly part of deposit processing, not as a newly introduced cryptographic mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The path invokes existing deposit signature validation and introduces no new cryptographic mechanism, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Modified process_operations and process_deposit_receipt, lines 189-233",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"summary": "Processing branches around an unset start-index sentinel, the former deposit index and count, exact per-block limits, zero-deposit behavior, and first-receipt initialization."
},
{
"locator": "Validator index invariant, lines 175-177",
"source": "eip.md",
"summary": "Reorganizations can assign different indices to the same validator public key on different branches."
},
{
"locator": "Security Considerations -- DoS vectors, lines 211-223",
"source": "eip.md",
"summary": "The EIP analyzes high-volume blocks and optimistic-sync limits reaching thousands of receipts and signature verifications."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Fork boundaries, empty and first-receipt cases, transition-index crossings, log ordering, reorganizations, and high-volume limits form multiple boundary mechanisms, with the transition and volume dimensions requiring an elevated case matrix. This matches anchor 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Deposit, Block structure, and Block validity, lines 53-158",
"source": "eip.md",
"summary": "The EIP adds RLP encodings for deposits and the extended block body, a new header field, root validation, and execution-log equivalence validation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Syncing clients face multiple new RLP/block validation mechanisms, including the complex requirement to execute the block and reproduce an ordered list from receipts. That satisfies anchor 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification -- Consensus layer, lines 160-168",
"source": "eip.md",
"summary": "ExecutionPayload is extended with one deposit_receipts field carrying the deposit-operation list between the execution and consensus layers."
},
{
"locator": "Modified process_execution_payload, lines 235-280",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"summary": "The consensus transition sends the extended payload through a NewPayloadRequest and caches a root of its deposit_receipts."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The package clearly adds one ExecutionPayload communication field, supporting the single-field anchor 1.",
"score": 1,
"uncertainty_note": "Engine method versions, JSON encoding, and whether the field appears in more than one endpoint are not specified in the package.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Configuration, lines 41-47",
"source": "eip.md",
"summary": "The proposal configures the already existing deposit contract address and does not deploy a new contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification -- Configuration and Block validity, lines 41-47 and 114-155",
"source": "eip.md",
"summary": "The existing deposit contract's logs become the mandatory source of a new consensus-critical block-body list, without changing the contract code."
},
{
"locator": "Rationale -- Filtering events only by DEPOSIT_CONTRACT_ADDRESS, lines 193-195",
"source": "eip.md",
"summary": "Validity relies on the existing contract emitting no events other than its deposit event."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "Although contract code and state are untouched, the EIP gives the existing deposit contract a major indirect effect on execution-block validity and cross-layer processing. This fits anchor 2's major-indirect-effect case.",
"score": 2,
"uncertainty_note": "The rubric does not define whether the pre-existing deposit contract is classified as a system contract for this row.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Execution Layer, lines 31-158",
"source": "eip.md",
"summary": "The execution-layer specification adds block data and validation rules but defines no opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Execution Layer, lines 31-158",
"source": "eip.md",
"summary": "No existing opcode behavior is mentioned or changed by the block-level deposit mechanism."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Execution Layer, lines 31-158",
"source": "eip.md",
"summary": "The execution-layer additions contain no new precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Execution Layer, lines 31-158",
"source": "eip.md",
"summary": "The proposal changes no precompile behavior or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Deposit and Block structure, lines 53-98",
"source": "eip.md",
"summary": "The EIP normatively defines deposit RLP and appends an RLP list to the block body plus deposits_root to the header."
},
{
"locator": "Containers, lines 56-172",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"summary": "Consensus containers gain DepositReceipt, an ExecutionPayload list, an ExecutionPayloadHeader root, and a BeaconState field."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "A block-level RLP encoding change is explicit, so the binary anchor mandates score 3; the corresponding SSZ container extensions reinforce the interface impact.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Block validity, lines 13-17 and 114-155",
"source": "eip.md",
"summary": "Existing deposit transactions emit logs from which block-level operations are derived; no new transaction envelope or type is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The proposal introduces no transaction type, matching anchor 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Block validity, lines 100-158",
"source": "eip.md",
"summary": "The new rules invalidate blocks when their root or deposit list is wrong; they do not invalidate or change intrinsic gas for individual transactions."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "This is a block-validity change, not a transaction-validity or intrinsic-gas change, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification -- Block structure, lines 75-98",
"source": "eip.md",
"summary": "Post-fork block bodies gain a deposits list and block headers gain the new deposits_root field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The presence of a new block-body and header field triggers the binary anchor-3 definition.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Fork to EIP-6110 -- Upgrading the state, lines 67-145",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-fork.md",
"summary": "At the fork epoch an irregular state change rebuilds the payload header, updates the Fork object, and initializes deposit_receipts_start_index."
},
{
"locator": "Specification -- Definitions and Block structure, lines 49-51 and 75-90",
"source": "eip.md",
"summary": "The execution block format switches at the first block whose timestamp reaches the fork timestamp."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The consensus fork explicitly modifies state and internal variables at activation, which is the anchor-3 condition.",
"score": 3,
"uncertainty_note": "The concrete fork timestamp and epoch were TBD, but the specified activation state transition is unambiguous.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations -- DoS vectors, lines 211-223",
"source": "eip.md",
"summary": "Worst-case analysis spans block gas, thousands of deposits, BLS signature verification time, and an optimistic-sync case of 8,192 deposits and about eight seconds of processing."
},
{
"locator": "Rationale -- Not limiting the size of deposit operations list, lines 189-191",
"source": "eip.md",
"summary": "The execution-layer deposit list has no explicit protocol count limit and instead relies on the economics and gas cost of deposit creation."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance cannot be assessed solely in isolation because receipt extraction affects execution validation while signature processing affects consensus and optimistic sync, with behavior coupled to gas limits and payload size. These substantial cross-component interactions satisfy anchor 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator index invariant and Eth1Data poll deprecation, lines 175-181",
"source": "eip.md",
"summary": "The mechanism breaks reorg resilience of validator-index caches and transitions away from the former deposit polling path."
},
{
"locator": "Security Considerations -- Optimistic sync and Weak subjectivity period, lines 225-235",
"source": "eip.md",
"summary": "Optimistic nodes may apply finalized fake receipts under the honest-majority model, and the larger deposit throughput changes an input to weak subjectivity calculations."
},
{
"locator": "Specification -- Block validity, lines 100-158",
"source": "eip.md",
"summary": "Execution clients become responsible for consensus-critical equivalence between block data and deposit-contract receipt logs."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The change couples critical execution validation, consensus validator-registry updates, reorganization handling, optimistic sync, and weak-subjectivity assumptions. That multi-component security impact requires extensive review and fuzzing and matches anchor 3.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification -- Block validity, lines 114-155",
"source": "eip.md",
"summary": "The consensus-critical event decoder is only a function signature followed by pass, and the illustrative trie construction leaves exact indexed-key handling implicit."
},
{
"locator": "Configuration and Fork trigger, lines 25-32 and 58-65",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-fork.md",
"summary": "The configuration is declared non-definitive and the fork trigger remains TBD, with a testing-only epoch assumption."
},
{
"locator": "Introduction, lines 31-36",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"summary": "The detailed consensus specification identifies itself as under active development."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Exact malformed-event decoding, trie construction at unusual cases, and cross-layer interface behavior require agreement before complete invalid-case vectors can be baselined, but the gaps are localized around the new deposit path. This fits anchor 2 rather than the broad re-baselining case in anchor 3.",
"score": 2,
"uncertainty_note": "Existing deposit-contract behavior may make some malformed-event cases unreachable on the intended network, but the package does not specify that reachability as a validity precondition.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 21-29",
"source": "eip.md",
"summary": "The new path removes Eth1Data voting and eliminates the requirement for deposit-contract snapshots defined by EIP-4881."
},
{
"locator": "Abstract and Specification, lines 13-38",
"source": "supporting/eip-4881.md",
"summary": "EIP-4881 standardizes the compressed deposit-tree snapshot and Beacon Node API endpoint that EIP-6110 makes unnecessary after its transition."
},
{
"locator": "Introduction and Modified process_operations, lines 31-36 and 189-216",
"source": "supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"summary": "The feature extends the Deneb specification and coordinates the former deposit mechanism with receipt processing until a start-index boundary."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
4881
],
"rationale": "EIP-6110 changes the role of EIP-4881 and requires coordinated transition tests with the prior deposit path and inherited fork payload, but the interactions remain concentrated in deposit processing. This fits anchor 2.",
"score": 2,
"uncertainty_note": "Only EIP-4881 is numbered in the package; the EIP numbers, if any, associated with the named Deneb baseline and former deposit mechanism are not supplied.",
"under_specified": false,
"unidentified_interactions": [
"The packaged consensus specification extends Deneb and modifies its ExecutionPayload, ExecutionPayloadHeader, and block processing, but supplies no EIP number for that baseline.",
"The proposal coordinates with and eventually disables the former Eth1Data deposit mechanism, whose EIP number is not identified in the package."
]
}
],
"eip": 6110,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:6110:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The EIP calls the execution-block items deposits while the consensus documents call them deposit receipts and commit to them with an SSZ payload-header root; the cross-layer mapping is clear in intent but not specified as an Engine API schema.",
"The rubric classification of the pre-existing deposit contract as a system contract materially affects the modified-system-contracts row.",
"One added ExecutionPayload member may traverse multiple Engine endpoints, but the package documents the field rather than endpoint-specific changes."
],
"provenance": {
"assessed_revision": {
"commit": "46d979f9020c57db15373cb075b5cf456a0c2f12",
"committed_at": "2023-10-12T10:07:31Z",
"content_sha256": "0e5d1899fdef881e0fe6b4ea010a94241f233eb062acc7a151b67198afa2db50",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6110.md",
"git_blob_sha": "d4226f1ea4c81b300229335a6220c59b9dadbb31",
"immutable_url": "https://github.com/ethereum/EIPs/blob/46d979f9020c57db15373cb075b5cf456a0c2f12/EIPS/eip-6110.md",
"information_cutoff_at": "2024-01-18",
"path": "EIPS/eip-6110.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-6110.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-6110.yaml",
"sha256": "219ce37205270689c10294090ee84b8609c4f2ebb20392964a35a23ea247e030"
},
"supporting_documents": [
"supporting/eip-4881.md",
"supporting/ethereum-consensus-specs--specs-_features-eip6110-beacon-chain.md",
"supporting/ethereum-consensus-specs--specs-_features-eip6110-validator.md",
"supporting/ethereum-consensus-specs--specs-_features-eip6110-fork.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 36,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-6110 appended an ordered list of validator deposit operations to each post-fork execution block and added a header trie root committing to that list; the list was required to equal deposits parsed from deposit-contract logs produced by the block. It also extended the consensus ExecutionPayload and BeaconState, processed the new receipts while winding down the former Eth1Data deposit path, and made validator indices branch-dependent. The packaged fork document specified an irregular consensus-state upgrade, while several activation and interface details remained work in progress.",
"tier": "high",
"title": "Supply validator deposits on chain",
"under_specification": {
"affected_criteria": [
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 40,
"minimum": 32
},
"present": true,
"summary": "Material gaps remain in the exact decoding and failure behavior for deposit event data, indexed-trie construction details in the illustrative helper, transition-tool and Engine API surface shape, and final fork configuration. The supporting consensus and fork documents also identify themselves as active-development or work-in-progress material.",
"unresolved_questions": [
"What exact byte-layout checks and failure result apply when parsing a log from DEPOSIT_CONTRACT_ADDRESS into the five deposit fields?",
"What exact key/object encoding does compute_trie_root_from_indexed_data use at all list sizes and boundary indices?",
"Which transition-tool and Engine API endpoints expose deposit_receipts and deposits_root, and in what encoded form?",
"What final timestamp/epoch coordination activates the execution and consensus changes together?"
]
}
},
"prague:7002:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Validator Exit precompile / Gas cost, lines 150-154",
"source": "eip.md",
"summary": "The proposal introduces metering for a new native precompile, but leaves its gas cost TBD pending an estimate of the native computation cost."
},
{
"locator": "Rationale / Utilizing CALL to return excess payment, lines 326-334",
"source": "eip.md",
"summary": "The selected refund path uses a 2300-gas nested CALL specifically so that the precompile can have fixed rather than dynamic gas accounting."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This is a new gas-charged EVM execution mechanism, but it is confined to calls to a previously unused precompile address and therefore does not, as written, alter existing gas-accounting mechanisms or their tests. That matches score 2; the actual amount and final fixed-versus-dynamic rule are not yet specified.",
"score": 2,
"uncertainty_note": "The precompile gas cost is explicitly TBD, so a finalized dynamic schedule or interaction with existing CALL charging could move this score.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Validator Exit precompile / trigger_exit pseudocode, lines 79-125",
"source": "eip.md",
"summary": "A CALL to the new precompile performs fee validation, several state reads and writes, queue insertion, and then a nested value-returning CALL in a specified high-level sequence."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal adds a new state-accessing operation behind CALL, and the positions of its state accesses, failure points, gas charging, and nested CALL must be settled and tested. It does not rewrite ordering for an existing class of opcodes, so score 2 is the applicable anchor rather than score 3.",
"score": 2,
"uncertainty_note": "The gas charge point and revert behavior around the state writes and excess payment are not fully specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Exit fee update rule, lines 350-359",
"source": "eip.md",
"summary": "The described exponential rule computes an exit fee from excess exits; it does not modify blob-gas usage, targets, reservoirs, or charging."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or changed. The isolated use of the phrase \"blob gas price\" in the parameter discussion does not change the formulas, variables, or surrounding specification from exit-fee accounting.",
"score": 0,
"uncertainty_note": "Line 359 says \"blob gas price,\" but in context this appears to be an unresolved drafting error rather than a specified blob-gas change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator Exit precompile / queue helpers, lines 108-147",
"source": "eip.md",
"summary": "The new precompile uses ordinary SLOAD/SSTORE-style state operations and a precompile gas cost, without defining a separate state-gas budget, reservoir, rate, or spill path."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Persistent writes are introduced, but the rubric scores a distinct state-gas accounting regime rather than the mere fact of writing state. None is specified.",
"score": 0,
"uncertainty_note": "The ordinary EVM/precompile gas cost is TBD, but no text suggests a separate state-gas mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator Exit precompile / return_excess_payment, lines 121-125",
"source": "eip.md",
"summary": "Excess ETH paid above the exit fee is sent back through a value-bearing CALL; no unused-gas refund or refund counter is created."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "Returning excess fee payment in ETH is a value transfer, not a new EVM gas-refund mechanism, so the gas-refund anchor is not triggered.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block structure and Block validity, lines 156-226",
"source": "eip.md",
"summary": "Every post-fork block gains an RLP body list and header commitment, and validity additionally depends on the post-transaction contents of persistent precompile state and strict FIFO ordering."
},
{
"locator": "Backwards Compatibility, lines 367-369",
"source": "eip.md",
"summary": "The proposal explicitly characterizes its block-structure and block-validation changes as backwards incompatible."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing post-fork block, state-transition, malformed-block, and syncing tests must be reworked across diverse categories to construct or validate the new body, header, queue-derived operations, and end-of-block transition. This is the major, diverse impact described by score 3.",
"score": 3,
"uncertainty_note": "Exact test-suite breadth is not enumerated in the proposal, but the mandatory per-block schema and validity changes make the broad impact direct.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block validity, lines 181-226",
"source": "eip.md",
"summary": "Valid post-fork blocks must commit to the body exits and must contain exactly the queue-head exits, in order, after transaction execution and before the per-block precompile update."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of otherwise unrelated post-fork tests gains mechanical exits-root and queue-equivalence assertions. The text does not require pre-fork vectors to be re-derived, so score 2 fits better than the score-3 anchor.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Block structure and Block processing, lines 156-179 and 228-280",
"source": "eip.md",
"summary": "A transition must consume or produce the new exits body list and exits root and perform a new post-transaction, end-of-block queue and fee-state update."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Representing queue-derived block outputs plus a new end-of-block processing phase requires a new transition-tool mechanism and associated fields, matching score 2. The historical text does not define the concrete tool interface.",
"score": 2,
"uncertainty_note": "No transition-tool API is specified, so the exact number and direction of fields depend on how the block-building and block-validation modes expose exits.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Block validity and Per-block precompile storage calculations, lines 181-280",
"source": "eip.md",
"summary": "Tests must express queue-derived block-body expectations and observe a mandatory transition phase that occurs after transactions and validity checks."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The new queue/body equivalence expectation and end-of-block modifier are reusable primitives needed throughout this EIP's suite, beyond merely writing isolated precompile calls. The package does not establish reuse by other EIPs, so score 2 rather than score 3 is appropriate.",
"score": 2,
"uncertainty_note": "Existing framework capabilities are not described; sufficiently generic block and storage expectations could reduce the needed extension to score 1.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Exit operation and Block structure, lines 61-73 and 171-179",
"source": "eip.md",
"summary": "Exit data is RLP encoded and committed with the existing indexed-data trie-root construction; the validator public key is carried as opaque bytes."
},
{
"locator": "Consensus layer sketch, lines 283-292",
"source": "eip.md",
"summary": "The sketch adds exit processing but specifies no new signature, proof system, hash function, or other cryptographic primitive."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "The proposal uses existing encoding and trie commitment machinery and introduces no cryptographic mechanism to implement or test.",
"score": 0,
"uncertainty_note": "The consensus-layer validation rules are incomplete, but the selected text does not specify any cryptographic verification.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator Exit precompile, lines 77-147",
"source": "eip.md",
"summary": "Call behavior has boundaries for 48-byte input, insufficient/exact/excess fee, excess-return success, queue indices, integer arithmetic, and termination of the fake-exponential loop."
},
{
"locator": "Block validity and queue update, lines 195-224 and 254-279",
"source": "eip.md",
"summary": "Dequeue behavior depends on empty, below-limit, exactly-limit, and above-limit queue sizes, preserves FIFO order, conditionally resets pointers, and updates excess around the target threshold."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple independent mechanisms have boundary-rich state spaces, and the combination of value transfer/revert behavior, persistent FIFO transitions, capped per-block output, exponential integer math, and fork ordering requires an elevated case count. This meets score 3.",
"score": 3,
"uncertainty_note": "Several boundary outcomes are themselves under-specified, increasing test-design uncertainty without changing the primary score.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block structure, lines 156-179",
"source": "eip.md",
"summary": "The post-fork RLP block body is extended by an exits list and the header by an exits_root committing to that list."
},
{
"locator": "Block validity, lines 181-226",
"source": "eip.md",
"summary": "Sync validation must verify both the commitment and a state-dependent ordered equivalence between the body exits and the persistent queue after transactions."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "The proposal adds multiple block-RLP/schema validations, including the complex state- and ordering-dependent queue equivalence rule, so the score-3 syncing anchor applies.",
"score": 3,
"uncertainty_note": "The illustrative queue-extraction pseudocode is internally inconsistent, but the normative requirement for the complex validation is clear.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Consensus layer sketch, lines 283-292",
"source": "eip.md",
"summary": "ExecutionLayerExit values are specified to appear in ExecutionPayload as a bounded SSZ list."
},
{
"locator": "Rationale / Exits inside of the block, lines 361-365",
"source": "eip.md",
"summary": "The exits must be embedded in the shared execution-payload data structure so consensus processing does not require a synchronous execution-layer call."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The historical design implies one new payload field carrying the exits list across the execution/consensus interface. With no endpoint or additional API fields specified, the conservative score-1 anchor is best supported.",
"score": 1,
"uncertainty_note": "The Engine API is not named and endpoint coverage is absent; carrying the payload field through multiple directives could raise this to score 2.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Stateful precompile rationale, lines 13-17 and 296-306",
"source": "eip.md",
"summary": "The proposal adds one unprecedented stateful precompile whose address holds an unbounded queue and fee state and whose output triggers consensus-layer exits."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "A single protocol-reserved contract-like address is both stateful and the source of a new cross-layer system action. That is exactly the score-2 single-system- contract anchor.",
"score": 2,
"uncertainty_note": "The proposal calls the mechanism a precompile rather than a system contract, but it explicitly assigns protocol-owned code semantics and persistent state to one address.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Stateful precompile rationale, lines 13-17 and 296-304",
"source": "eip.md",
"summary": "The mechanism is introduced at a new configurable precompile address; the text does not alter the code or state of any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "All specified contract-like behavior belongs to the newly added precompile, so no pre-existing system contract is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "The address is TBD, but the proposal consistently describes the precompile as new.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator Exit precompile and Stateful precompile rationale, lines 75-86 and 296-304",
"source": "eip.md",
"summary": "The selected design exposes behavior at a precompile address through CALL; an opcode is mentioned only as an unselected alternative design."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added by the selected proposal.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator Exit precompile, lines 75-86",
"source": "eip.md",
"summary": "Existing CALL dispatches to a newly allocated precompile address, but no existing opcode's general result semantics are redefined or deprecated."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Adding a precompile reachable through CALL is scored under added precompiles; it does not constitute a modification of the CALL opcode itself under this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Validator Exit precompile, lines 13-17 and 75-86",
"source": "eip.md",
"summary": "Exactly one new precompile is added, with one fixed-length 48-byte input and a call flow that queues an exit and returns excess payment."
},
{
"locator": "Gas cost and Utilizing CALL rationale, lines 150-154 and 326-334",
"source": "eip.md",
"summary": "The exact gas cost is TBD, while the selected 2300-gas stipend is intended to permit a fixed rather than dynamic precompile cost."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The defined shape is one precompile with constant input length and an intended fixed gas charge, matching score 1. Its statefulness and system action are scored separately under added system contracts.",
"score": 1,
"uncertainty_note": "Because the gas schedule is TBD and the exponential calculation has variable work, a finalized dynamic gas cost would make this a score-2 complex precompile.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Stateful precompile rationale, lines 13-17 and 296-304",
"source": "eip.md",
"summary": "The EIP introduces a new precompile and compares alternative placements; it does not alter any existing precompile's gas schedule or behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Exit operation and Block structure, lines 61-73 and 156-179",
"source": "eip.md",
"summary": "The proposal defines RLP for each exit and extends the RLP block body with an exits list and the block header with its trie-root commitment."
},
{
"locator": "Consensus layer sketch, lines 283-292",
"source": "eip.md",
"summary": "The execution payload gains an SSZ List of ExecutionLayerExit operations."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Explicit RLP changes at the block level and an SSZ interface/payload addition trigger the rubric's binary score-3 encoding anchor.",
"score": 3,
"uncertainty_note": "The consensus-layer SSZ container details are only sketched, but the block-level RLP change independently fixes the score at 3.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator Exit precompile, lines 75-86",
"source": "eip.md",
"summary": "Users trigger exits by sending an ordinary CALL with value and a 48-byte input; no transaction envelope or transaction type is introduced."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The proposal adds a call target and a block operation, not a transaction type.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Validator Exit precompile / check_exit_fee, lines 79-106",
"source": "eip.md",
"summary": "Insufficient exit payment makes execution of the precompile call fail; the text does not change transaction-envelope validity or intrinsic gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Exit-fee validation is execution behavior inside a call, not a transaction validity rule, and no existing transaction type is otherwise modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Block structure, lines 156-179",
"source": "eip.md",
"summary": "Beginning at the fork block, the block body gains an exits list and the header gains a new exits_root field committing to that list."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The explicit new header field triggers the rubric's binary score-3 anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Definitions and Per-block precompile storage calculations, lines 53-57 and 228-280",
"source": "eip.md",
"summary": "The fork is activated by timestamp, after which the same queue and fee update is run at the end of every block; no one-time migration or pre-existing state mutation is specified for the activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Recognizing a new precompile and initializing its new zero-valued variables does not meet this anchor's requirement for a special modification of state or an internal variable at activation.",
"score": 0,
"uncertainty_note": "The precompile address is TBD and collision handling is absent, but no activation migration is specified in the historical text.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Stateful precompile rationale, lines 296-306",
"source": "eip.md",
"summary": "The proposal acknowledges that the in-state message queue contains an unbounded amount of state and may face client-specific engineering constraints."
},
{
"locator": "Exit message queue rationale, lines 316-324",
"source": "eip.md",
"summary": "Calls may arrive far faster than the maximum 16 exits dequeued per block, while the cap is intended to bound block-size and consensus-processing load."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Persistent backlog growth, stateful native execution, and mandatory per-block queue processing require integrated performance validation, but the emitted list and dequeue work are explicitly capped. This is a limited-impact, not fully isolated mechanism matching score 2.",
"score": 2,
"uncertainty_note": "The gas cost and behavior under very large fee/queue state are unresolved, so the actual computation and storage-growth impact could be greater.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rate limiting using exit fee, lines 336-344",
"source": "eip.md",
"summary": "The mechanism is explicitly designed against cheap queue-filling griefing and combines an economic fee response with cross-layer exit delivery."
},
{
"locator": "Security Considerations / Impact on existing custody relationships, lines 371-380",
"source": "eip.md",
"summary": "Enabling withdrawal credentials to exit changes a validator-ownership capability on which existing custody relationships or products might rely."
},
{
"locator": "Validator Exit precompile, lines 79-125",
"source": "eip.md",
"summary": "A call mutates persistent queue state and performs a nested value-returning CALL, making failure, re-entry, and atomicity behavior security-relevant."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The feature crosses authorization of validator funds, consensus exit processing, execution-layer value transfer, persistent queue state, block validity, and an anti-griefing fee market. These multiple critical-component interactions require extensive security review and fuzzing, meeting score 3.",
"score": 3,
"uncertainty_note": "The incomplete consensus validation and CALL/revert semantics make the precise vulnerability surface uncertain, but not the breadth of security impact.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Constants, Configuration, and Gas cost, lines 31-51 and 150-154",
"source": "eip.md",
"summary": "The fork timestamp, precompile address, and precompile gas cost are all TBD."
},
{
"locator": "trigger_exit and return_excess_payment pseudocode, lines 93-125",
"source": "eip.md",
"summary": "trigger_exit calls return_excess_payment with one argument although its definition requires fee and source address, leaving the refund recipient and precise failure/rollback semantics unresolved."
},
{
"locator": "Block validity queue extraction, lines 195-224",
"source": "eip.md",
"summary": "Queue insertion uses three slots per exit, while extraction advances by two and repeatedly reads the same slot in malformed pseudocode, so constructible block validity cases do not have a determinate algorithmic answer."
},
{
"locator": "Consensus layer sketch, lines 283-292",
"source": "eip.md",
"summary": "Consensus processing is only a sketch and says invalid exit requests can fail validation without invalidating the block, without specifying the full checks or outcomes."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Previously nonexistent stateful-precompile, queue, refund, and cross-layer exit behaviors become consensus-visible, yet several constructible cases and even the block queue-decoding algorithm lack a single answer. Cross-client agreement and repeated test re-baselining would be required, meeting score 3.",
"score": 3,
"uncertainty_note": "The historical text is too incomplete to enumerate every unresolved call mode, malformed input, rollback, queue, and consensus-validation outcome.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Stateful precompile and Rate limiting rationales, lines 302-306 and 336-357",
"source": "eip.md",
"summary": "The exit fee deliberately reuses an EIP-1559-style self-correcting fee pattern, while keeping its own state inside the new precompile."
},
{
"locator": "Abstract and Specification, lines 16-24 and 152-195",
"source": "supporting/eip-1559.md",
"summary": "EIP-1559 defines the referenced block-to-block fee adjustment pattern based on prior usage relative to a target."
},
{
"locator": "Rate limiting using exit fee, lines 340-344",
"source": "eip.md",
"summary": "The alternative proof-based design would require EIP-4788, but the selected economic design explicitly avoids that dependency and its cross-layer proof complexity."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
1559
],
"rationale": "The selected design has a limited, non-critical interaction with EIP-1559 by adapting its fee-adjustment pattern, and can test its exit-fee state independently. EIP-4788 is an explicitly rejected alternative rather than a dependency. This supports score 1.",
"score": 1,
"uncertainty_note": "The consensus sketch also names existing voluntary-exit and deposit processing without identifying corresponding EIP numbers or defining the exact coupling.",
"under_specified": true,
"unidentified_interactions": [
"Existing consensus-layer voluntary-exit and deposit processing is referenced by name, but the package identifies no EIP number for either interaction."
]
}
],
"eip": 7002,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7002:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The sealed historical EIP header calls the feature \"Execution layer triggerable exits,\" while the package/template provenance title says \"Execution layer triggerable withdrawals\"; the assessment preserves the populated package title and evaluates the sealed exit mechanism.",
"The exit-fee rationale calls one parameter the maximum downward rate of the \"blob gas price,\" although every surrounding formula and variable concerns exits.",
"The historical EIP simultaneously specifies three storage slots per queued exit during insertion and two-slot stepping with repeated slot reads during validation.",
"EIP-4788 is linked and discussed, but only as a dependency of an explicitly unselected alternative; it is therefore not listed as an interacting EIP."
],
"provenance": {
"assessed_revision": {
"commit": "28cbb0162f998530fd423c0062d9954de6d4a5c4",
"committed_at": "2023-06-29T14:13:35Z",
"content_sha256": "acf1880b41862acbba6868d443cc56ac39d42d8c3295a45220f86743e304d2b8",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7002.md",
"git_blob_sha": "d3249f63881b96461ed0276d2b7bf027fe686764",
"immutable_url": "https://github.com/ethereum/EIPs/blob/28cbb0162f998530fd423c0062d9954de6d4a5c4/EIPS/eip-7002.md",
"information_cutoff_at": "2024-01-18",
"path": "EIPS/eip-7002.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7002.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7002.yaml",
"sha256": "7b9aac068cf4f1e8e5168078333cdc527098d256054f2110131fb545e9aaa82d"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-4788.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 38,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the selected revision, EIP-7002 proposed a new stateful, value-accepting precompile through which an execution-layer withdrawal credential could queue a validator exit. The execution layer would maintain a persistent FIFO queue and an EIP-1559-style dynamic exit fee, append up to 16 queued exits and an exits-root commitment to each block, and update the queue and fee state after block execution. The consensus-layer portion was only a sketch: exits would be carried in the ExecutionPayload and processed with voluntary-exit-like rules whose validation failures would not invalidate the block.",
"tier": "high",
"title": "Execution layer triggerable withdrawals",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"engine_api_changes",
"added_precompiles",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 44,
"minimum": 33
},
"present": true,
"summary": "Material consensus behavior is unresolved: core constants and gas charging are TBD; the refund-call signature and recipient are inconsistent; queue insertion and validation use contradictory layouts; malformed input, call-mode, rollback, and re-entry outcomes are not fully defined; concrete Engine API/tool interfaces are absent; and the consensus-layer rules are only a sketch. These gaps directly drive the unspecified-behavior score and lower confidence in several interface, gas, framework, precompile, and performance scores without being counted as separate primary complexity in every affected row.",
"unresolved_questions": [
"What is the precompile address, gas schedule, and exact behavior for malformed input and non-CALL call modes?",
"Which address receives excess payment, and do nested-call failure or re-entry revert every preceding queue and counter write atomically?",
"What is the canonical three-slot queue decoding algorithm, including integer bounds, cleared entries, and pointer behavior under long-lived backlog?",
"What exact consensus-layer eligibility, withdrawal-credential authorization, duplicate/already-exited handling, and state-transition rules apply?",
"Which ExecutionPayload and Engine API fields and versions carry exits, and which transition-tool inputs or outputs represent them?",
"Does the final precompile gas rule remain fixed despite state-dependent fake-exponential work, or become dynamic?"
]
}
},
"prague:7251:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly states that it requires no changes to the execution layer."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas accounting rule is introduced or updated, satisfying the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly excludes execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "With no opcode or execution-layer change, it does not alter state-access or gas-charge ordering inside any opcode, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly states that it requires no execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is described, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly states that it requires no execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Consensus validator balances and churn are not the rubric's state-gas mechanism, and no state-gas cost, rate, budget, or spill rule is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly excludes execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM refund mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Consensus layer change sketch, lines 49-68",
"source": "eip.md",
"summary": "The sketch changes consensus constants and BeaconState fields, activation eligibility, deposit handling, activation and exit churn, registry processing, aggregation selection, weak-subjectivity computation, withdrawal credentials, and withdrawal eligibility."
},
{
"locator": "Backwards Compatibility, lines 86-88",
"source": "eip.md",
"summary": "The proposal declares backward-incompatible changes to the consensus block-validation rule set requiring a hard fork."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The changes span diverse existing consensus-test categories rather than a contrived subset, so a major body of pre-existing tests would need reworking under the score-3 anchor.",
"score": 3,
"uncertainty_note": "The document is only a change sketch, so the exact affected-test count cannot be derived.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Consensus layer change sketch, lines 49-68",
"source": "eip.md",
"summary": "The proposal lists changes to existing transition logic and new EIP-specific state and helpers, but does not require tests unrelated to this EIP to assert an additional common output."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The stated effects rework tests of the changed mechanisms; they do not establish a new assertion that pre-existing tests retain their old logic and must additionally check, so score 0 is best supported.",
"score": 0,
"uncertainty_note": "The unspecified BeaconState fields might eventually have implied mechanically added assertions, but this revision does not define them.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal says it requires no execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No field or mechanism for the execution state-transition tool interface is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Consensus layer change sketch, lines 49-68",
"source": "eip.md",
"summary": "The sketch identifies protocol containers, state fields, helpers, and modified functions, but specifies no new testing expectations, modifiers, helpers, or framework abstractions."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The historical text does not establish a need beyond ordinary protocol test construction, so the existing-primitives score-0 anchor is the best-supported assessment.",
"score": 0,
"uncertainty_note": "Detailed operations for consolidation and custom ceilings are absent, so their eventual test-harness needs cannot be determined.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations — Aggregator selection, lines 98-100",
"source": "eip.md",
"summary": "The existing VRF lottery remains the selection basis; the proposal changes selection to account for validator weight."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Changing the weight used by an existing selection lottery does not introduce or modify a cryptographic mechanism itself, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Constants and defining features, lines 25-45",
"source": "eip.md",
"summary": "The proposal introduces distinct 32 ETH activation and 2048 ETH effective-balance bounds, consolidation, custom partial-withdrawal ceilings, execution-triggered partial withdrawals, and a debated slashing change."
},
{
"locator": "Specification — Consensus layer change sketch, lines 49-68",
"source": "eip.md",
"summary": "It adds pending-deposit processing, balance-rate-limited activation and exit queues, a new credential prefix, and full, partial, and excess-balance withdrawal checks."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple interacting threshold, queue, credential, consolidation, and withdrawal mechanisms create a multiplicative set of boundary cases, including exact balance limits and competing validator lifecycle states; this meets score 3.",
"score": 3,
"uncertainty_note": "The precise boundary semantics are not fully specified, which is scored separately as under-specification.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The assigned EIP explicitly requires no execution-layer change."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "It introduces no execution block RLP-validation mechanism requiring client syncing, so score 0 applies.",
"score": 0,
"uncertainty_note": "EIP-7002 has separate block-structure changes; those are treated as a cross-EIP dependency rather than direct EIP-7251 scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The assigned EIP explicitly requires no execution-layer change."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is specified, matching score 0.",
"score": 0,
"uncertainty_note": "Any interface work belonging to the EIP-7002 dependency is not a direct EIP-7251 change.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal states that EIP-7251 requires no execution-layer changes."
},
{
"locator": "Specification — Defining features, lines 41-45",
"source": "eip.md",
"summary": "Execution-layer partial withdrawals are assigned to EIP-7002 rather than specified as a new EIP-7251 system contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "EIP-7251 directly adds no system contract, so score 0 applies; the separate EIP-7002 mechanism is captured under cross-EIP interactions.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly requires no execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system-contract code, state, or behavior is directly or indirectly modified by the assigned EIP, matching score 0.",
"score": 0,
"uncertainty_note": "The interaction with EIP-7002 is scored separately and is not described as modification of a pre-existing deployed system contract.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly excludes execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, satisfying score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly excludes execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is changed or deprecated, satisfying score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "EIP-7251 states that it requires no execution-layer changes."
},
{
"locator": "Abstract, lines 13-17",
"source": "supporting/eip-7002.md",
"summary": "The stateful precompile is introduced by the separately identified EIP-7002 dependency."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The assigned EIP adds no precompile of its own; attributing the dependency's precompile here would double-count the cross-EIP interaction, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly excludes execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile logic or gas schedule is modified by EIP-7251, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Consensus layer change sketch, lines 49-51",
"source": "eip.md",
"summary": "The proposal creates a PendingDeposit container and adds deposit- and exit-rate-limiting fields to BeaconState."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Adding a consensus container and BeaconState fields changes the consensus-layer SSZ schema, which is an encoding change and therefore triggers the rubric's binary score-3 anchor.",
"score": 3,
"uncertainty_note": "The revision does not define the container fields or enumerate the exact BeaconState additions.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal states that it requires no execution-layer changes."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "The proposal explicitly states that no execution-layer changes are required."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "It does not change transaction validity or intrinsic gas calculation, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Execution layer, lines 33-35",
"source": "eip.md",
"summary": "EIP-7251 directly requires no execution-layer changes."
},
{
"locator": "Specification — Consensus layer change sketch, lines 49-68",
"source": "eip.md",
"summary": "The listed direct consensus changes concern BeaconState and processing helpers, not a new block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new EIP-7251 block or header field is specified, so the binary zero anchor applies.",
"score": 0,
"uncertainty_note": "The EIP-7002 dependency has its own block fields, which are accounted for as an interaction rather than a direct EIP-7251 field.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility, lines 86-88",
"source": "eip.md",
"summary": "The changes require a hard fork, but the document does not specify a one-time state or existing-variable modification at the activation block."
},
{
"locator": "Specification — Consensus layer change sketch, lines 49-51",
"source": "eip.md",
"summary": "The sketch adds constants, a new container, and new BeaconState fields without defining an activation-time migration."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Requiring fork activation is not itself the rubric trigger; absent a specified one-time modification of existing state or variables at activation, score 0 is best supported.",
"score": 0,
"uncertainty_note": "The revision does not explain initialization or migration of the new BeaconState fields or treatment of existing validators at activation.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 19-21",
"source": "eip.md",
"summary": "The proposal aims to change validator-set size and thereby P2P message volume, BLS aggregation work, BeaconState memory, and beacon-node operation."
},
{
"locator": "Security Considerations — Proposer selection probability, lines 102-104",
"source": "eip.md",
"summary": "The text expects lower selection probabilities to make next-proposer-index calculation slightly slower."
},
{
"locator": "Security Considerations — Churn invariants, lines 110-112",
"source": "eip.md",
"summary": "Activation, exit churn, and balance top-ups move to active-weight-based handling and shared queue constraints."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Network, aggregation, state-memory, proposer-selection, and queue behavior interact with existing validator workloads and cannot be validated fully in isolation; the breadth and interaction with existing benchmarks meet score 3.",
"score": 3,
"uncertainty_note": "The text gives expected directions but no benchmark design or quantitative performance bounds.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations, lines 90-112",
"source": "eip.md",
"summary": "The proposal analyzes committee takeover, weight-aware aggregator selection, proposer and sync-committee selection, and activation and exit churn invariants."
},
{
"locator": "Specification — Defining features, lines 41-45",
"source": "eip.md",
"summary": "The scope also includes consolidation, custom partial withdrawals, and a still-discussed removal of the initial slashing penalty."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "If implemented incorrectly, the mechanisms touch multiple critical consensus and validator-fund components—committee selection, aggregation, churn, withdrawals, and slashing—so they require broad security review and meet score 3 despite the proposal's intended preservation of security.",
"score": 3,
"uncertainty_note": "The slashing change remained unsettled, and the security section asserts limited impact without fully specifying the mechanisms.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Defining features and change sketch, lines 39-68",
"source": "eip.md",
"summary": "The revision labels its function list a sketch and does not define consolidation mechanics, custom-ceiling representation and updates, the PendingDeposit fields, the new BeaconState fields, or complete transition pseudocode."
},
{
"locator": "Specification — Defining features, lines 43-45",
"source": "eip.md",
"summary": "Execution-triggered partial withdrawals are delegated to EIP-7002, while removal of the initial slashing penalty is explicitly still in discussion."
},
{
"locator": "Consensus layer, lines 282-291",
"source": "supporting/eip-7002.md",
"summary": "The packaged EIP-7002 revision only sketches execution-triggered exits and does not specify the partial-withdrawal behavior expected by EIP-7251."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Multiple consensus answers must be agreed before deterministic vectors can be written, but the package does not establish the score-3 condition of a previously unobservable behavior newly becoming consensus-critical; score 2 is therefore the closest anchor.",
"score": 2,
"uncertainty_note": "The omissions are broad rather than cleanly localized, while the rubric's score-3 trigger is not clearly demonstrated.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter, lines 1-12",
"source": "eip.md",
"summary": "The proposal formally requires EIP-7002."
},
{
"locator": "Specification and Rationale — EIP-7002 partial withdrawals, lines 41-45 and 81-82",
"source": "eip.md",
"summary": "EIP-7251 relies on EIP-7002 for execution-layer messages that trigger partial withdrawals from variable-balance validators."
},
{
"locator": "Consensus layer, lines 282-291",
"source": "supporting/eip-7002.md",
"summary": "The dependency crosses layers through operations carried in ExecutionPayload and consensus processing, while this packaged revision describes exits rather than the partial-withdrawal extension EIP-7251 expects."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
7002
],
"rationale": "The direct EIP-7002 dependency requires coordinated execution/consensus testing and interface agreement, but only one identified interaction is in scope, fitting score 2 rather than the multiple-EIP score-3 anchor.",
"score": 2,
"uncertainty_note": "The sealed EIP-7002 revision does not yet contain the partial-withdrawal behavior attributed to it by EIP-7251.",
"under_specified": true,
"unidentified_interactions": []
}
],
"eip": 7251,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7251:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"EIP-7251 says it makes no execution-layer changes yet makes execution-triggered partial withdrawals a defining feature supplied by EIP-7002; direct execution changes were scored zero and the dependency was scored under cross-EIP interactions.",
"The packaged EIP-7002 revision specifies execution-triggered exits, not the partial-withdrawal amount and validation semantics that EIP-7251 expects.",
"Removal of the initial slashing penalty is listed as a defining feature but marked still in discussion, so it was treated as unresolved scope rather than a settled rule.",
"The rubric's encoding anchor was applied to the added PendingDeposit container and BeaconState fields as a consensus-layer SSZ schema change, although the draft omits their exact definitions."
],
"provenance": {
"assessed_revision": {
"commit": "faccff3ac9a150d53d5ee90f768d053d7b82dad3",
"committed_at": "2024-01-31T02:41:25Z",
"content_sha256": "15387221cbc1b092bae75ab6dd75c509129de14cde9fcf30b79a048569ee793d",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7251.md",
"git_blob_sha": "3c63ca90e98bff9f60f53c828e6ad3bc0371e974",
"immutable_url": "https://github.com/ethereum/EIPs/blob/faccff3ac9a150d53d5ee90f768d053d7b82dad3/EIPS/eip-7251.md",
"information_cutoff_at": "2024-03-21",
"path": "EIPS/eip-7251.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7251.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7251.yaml",
"sha256": "3a590fe2c294c601bb98f7e58f420f6643d46ab2ff8e7cde2801236269986dd1"
},
"supporting_documents": [
"supporting/eip-7002.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 19,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the cutoff, this draft proposed raising MAX_EFFECTIVE_BALANCE to 2048 ETH while retaining a 32 ETH activation minimum, with variable-balance validators and compounding withdrawal credentials. Its consensus-layer sketch also proposed validator consolidation, configurable partial-withdrawal ceilings, balance-weighted deposit and exit churn, pending balance deposits, weight-aware aggregator selection, and related withdrawal changes; removal of the initial slashing penalty remained under discussion. It stated that EIP-7251 itself required no execution-layer changes, while depending on EIP-7002 for execution-triggered partial withdrawals.",
"tier": "medium",
"title": "Increase the MAX_EFFECTIVE_BALANCE",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"new_test_framework_primitives",
"edge_boundary_conditions",
"encoding_changes_rlp_ssz",
"new_fork_activation_mechanism",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 25,
"minimum": 15
},
"present": true,
"summary": "Material consensus behavior is unresolved: the document is a change sketch without complete data types or transition rules for consolidation, custom withdrawal ceilings, pending deposits, balance-weighted churn, and activation. The proposed slashing change remains in discussion, and the packaged EIP-7002 revision specifies execution-triggered exits rather than the partial withdrawals EIP-7251 assigns to it.",
"unresolved_questions": [
"What exact messages, authorization rules, state transitions, and queue rules perform validator consolidation?",
"How is a validator's custom effective-balance or partial-withdrawal ceiling represented, authorized, updated, and bounded?",
"What are the complete PendingDeposit and BeaconState field definitions, and what are the ordering and failure semantics of pending-deposit processing?",
"How are balance-based activation and exit churn computed at boundaries and when deposits, withdrawals, exits, and consolidations compete?",
"What activation-time initialization or migration applies to new fields and existing validators?",
"Is the initial slashing penalty removed, and if so what replacement rule applies?",
"How does EIP-7002 carry and validate a partial-withdrawal amount when its packaged revision only defines full exit requests?"
]
}
},
"prague:7623:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-65",
"source": "eip.md",
"summary": "The draft defines calldata tokens and replaces the prior additive transaction gas formula with a maximum between the existing-cost branch and a new 12-gas-per-token total-cost floor."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The maximum is a new transaction gas-accounting mechanism, not merely a constant substitution. It competes with the existing calldata, execution, and creation cost calculation and therefore changes existing gas outcomes and vectors, matching anchor 3.",
"score": 3,
"uncertainty_note": "The floor's charging phase is not specified, but the introduction and effect of the new gas rule are explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 38-65",
"source": "eip.md",
"summary": "The only specified change is a transaction-level gas-used formula based on calldata, execution gas, and creation cost; it does not move a state access or an opcode-local gas charge."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode execution path or state-access ordering is changed, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Specification, lines 22-27 and 30-65",
"source": "eip.md",
"summary": "Blobs motivate the calldata repricing, but the specified calculation contains no blob-gas term and changes only transaction calldata gas."
},
{
"locator": "Gas accounting, lines 164-186",
"source": "supporting/eip-4844.md",
"summary": "The linked blob proposal defines blob gas as independent of normal gas; the EIP-7623 formula does not alter that mechanism."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "A motivation involving blobs is not a blob gas-accounting modification. The proposal neither adjusts nor introduces blob gas, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 38-65",
"source": "eip.md",
"summary": "The new formula concerns calldata tokens and total transaction gas and defines no charge for writing state, state-byte rate, or block state-gas budget."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas mechanism described by this anchor is present, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 42-65",
"source": "eip.md",
"summary": "The proposal specifies a revised gas-used total but does not introduce a new refund operation or refund counter mechanism."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "A possible effect on ordinary unused-gas settlement is not itself a new EVM gas refund mechanism; anchor 0 is the best-supported score.",
"score": 0,
"uncertainty_note": "The draft does not say how the floor is reconciled with unused gas, an omission assessed under the cross-client under-specification criterion.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Rationale, lines 53-65 and 69-76",
"source": "eip.md",
"summary": "Existing transactions switch to the higher floor when weighted calldata is large relative to EVM and creation gas, while computation-heavy transactions remain on the former-cost branch."
},
{
"locator": "Backwards Compatibility, lines 79-83",
"source": "eip.md",
"summary": "The draft expressly characterizes the change as a backwards-incompatible gas repricing requiring a network upgrade."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing gas, receipt, balance, and block-gas expectations for the bounded low-computation/high-calldata category must be reworked. This is a considerable but category-specific subset rather than a major diverse subset, matching anchor 2.",
"score": 2,
"uncertainty_note": "The exact affected set depends on unresolved treatment of gas limits, refunds, access lists, and transaction types.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 38-65",
"source": "eip.md",
"summary": "The floor changes the expected value of existing transaction gas used but introduces no additional output, field, or independently asserted property."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A changed gas-used expectation reworks affected tests; it does not make tests unrelated to this EIP assert a new invariant. Anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "All inputs to the new calculation are existing transaction or execution properties, and the draft adds no transition-tool input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The rule can be exercised through existing transaction and expected-result data, so no transition-tool interface change is required and anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 32-65",
"source": "eip.md",
"summary": "The feature is expressed using ordinary calldata contents, contract-creation status, execution gas, and expected gas used."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing transaction construction and gas expectation primitives suffice; specialized cases and calculation helpers do not amount to a new framework primitive. Anchor 0 applies.",
"score": 0,
"uncertainty_note": "The draft provides no testing section, but nothing in the specified surface establishes a need for a new reusable expectation or modifier abstraction.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 32-65",
"source": "eip.md",
"summary": "The specification consists of integer calldata-token arithmetic and a maximum operation and introduces no cryptographic method."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography is introduced or modified, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 38-65",
"source": "eip.md",
"summary": "The new mechanism selects the maximum of a normal-cost branch and a calldata floor, with weighted zero/nonzero bytes and a contract-creation term affecting the crossover."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The introduced floor has one central branch boundary that requires below, equal, and above-threshold cases across its input dimensions. This is a single boundary-prone mechanism and matches anchor 1.",
"score": 1,
"uncertainty_note": "If floor enforcement changes out-of-gas or refund sequencing, the boundary matrix could be materially larger than the draft establishes.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "The proposal changes transaction gas accounting and specifies no block RLP field or RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No new block RLP validation mechanism requiring sync tests is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "The specification adds only an internal transaction gas calculation and no Engine API directive, field, or endpoint."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API surface changes are required, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "The gas-floor specification deploys or designates no contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "The draft changes a general transaction gas formula and names no system contract code, state, or system action."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or package-established indirect system-contract modification is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "The proposal defines a transaction accounting formula and no opcode number or instruction semantics."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-65",
"source": "eip.md",
"summary": "EVM execution gas is only an input to the transaction-level maximum; no existing opcode's result or non-gas behavior is changed."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The rubric excludes gas-only effects from modified-opcode scoring, and the proposal specifies no opcode behavior change. Anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "No precompile address, input, output, or execution rule is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-65",
"source": "eip.md",
"summary": "The transaction-wide floor does not change the logic or gas schedule of any named precompile."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "A transaction-level total that can encompass execution of a precompile is not a modification to that precompile's own logic or schedule. Anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "The proposal changes a gas-used calculation without changing transaction, block, or interface serialization."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface encoding change is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 30-65 and 79-83",
"source": "eip.md",
"summary": "The draft reprices transactions through a general gas formula and defines no type identifier or new transaction envelope."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification, lines 42-65",
"source": "eip.md",
"summary": "The draft replaces the formula for transaction gas used with a higher calldata-sensitive floor that can exceed the former total for an otherwise unchanged transaction."
},
{
"locator": "Backwards Compatibility, lines 79-83",
"source": "eip.md",
"summary": "The change is explicitly a backwards-incompatible gas repricing requiring a scheduled network upgrade."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "The new floor changes gas-limit and intrinsic/gas-used expectations for existing transaction cases and therefore their validity or execution boundary, but it appears expressible through limited vector updates without new testing infrastructure. Anchor 2 is the best-supported fit.",
"score": 2,
"uncertainty_note": "The draft does not state whether the floor is an up-front intrinsic requirement, a post-execution charge, or how a floor above the supplied gas limit is handled.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-65",
"source": "eip.md",
"summary": "The revised transaction gas calculation introduces no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is added, so anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 79-83",
"source": "eip.md",
"summary": "The draft requires a scheduled network upgrade but specifies no activation- block state mutation or modification of an existing internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Selecting a new rule at an ordinary scheduled fork is not the state or internal- variable modification scored by this anchor. Anchor 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 15-19 and 22-27",
"source": "eip.md",
"summary": "The proposal is intended to reduce maximum block size and its variance and to mitigate the gap between average and maximum block size as blob usage grows."
},
{
"locator": "Rationale, lines 69-76",
"source": "eip.md",
"summary": "The draft predicts a reduction of the maximum possible block size to roughly 0.6 MB and says this would create room for a higher gas limit or more blobs."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Validating the intended block-level effect requires composed block workloads, not just timing the arithmetic in isolation. The direct change is bounded and load-reducing, but it materially changes worst-case block-size benchmarks, so anchor 2 is appropriate.",
"score": 2,
"uncertainty_note": "The package supplies predicted sizes but no benchmark methodology, and an actual gas-limit or blob-count increase is outside this proposal's specified change.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 53-65 and 79-83",
"source": "eip.md",
"summary": "A consensus gas-used value is changed through a new floor, and the draft calls the repricing backwards incompatible."
},
{
"locator": "Security Considerations, lines 85-87",
"source": "eip.md",
"summary": "The draft reports no raised security concern because the maximum possible block size is reduced."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism touches the limited but critical set of transaction charging, gas-limit enforcement, receipts/block gas totals, and user fee settlement. Divergent or incorrect implementation could affect consensus or charges, which warrants targeted review and fuzzing and matches anchor 2, despite the intended reduction in network load.",
"score": 2,
"uncertainty_note": "The security section addresses block size but not the consequences of the unspecified charging and failure semantics.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-65",
"source": "eip.md",
"summary": "The draft gives an incomplete pseudocode expression for final transaction gas used but does not define the charging point, gas-limit failure behavior, refund basis, or treatment of other intrinsic charges."
},
{
"locator": "Specification, lines 42-50",
"source": "supporting/eip-1559.md",
"summary": "The linked transaction specification's intrinsic cost includes access-list address and storage-key charges in addition to base and calldata costs, terms absent from EIP-7623's replacement formula."
},
{
"locator": "Blob transaction and Gas accounting, lines 97-117 and 164-186",
"source": "supporting/eip-4844.md",
"summary": "Blob transactions retain ordinary data and access-list semantics while also paying independent blob gas, leaving their precise treatment by the general EIP-7623 wording unstated."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Constructible transactions with access lists, different gas limits, refunds, contract creation, or blob envelopes can produce different answers depending on how the draft's floor is integrated. Agreement is needed before vectors can be baselined, but the missing decisions are localized to transaction gas accounting rather than newly observable prior behavior, matching anchor 2.",
"score": 2,
"uncertainty_note": "The intended arithmetic crossover is clear; the material uncertainty is its integration into existing transaction execution and settlement.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 22-27",
"source": "eip.md",
"summary": "The rationale expressly relates the change to EIP-1559's block gas limit, EIP-2028's nonzero-calldata cost, and EIP-4844's blob data-availability path."
},
{
"locator": "Specification and Rationale, lines 40-65 and 69-76",
"source": "eip.md",
"summary": "The calculation incorporates an existing contract-creation initcode word cost without identifying its EIP and is intended to alter calldata/block-size behavior alongside blobs."
},
{
"locator": "Blob transaction and Gas accounting, lines 97-117 and 164-186",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 blob transactions carry ordinary transaction data while blob gas is independent, requiring coordinated cases for the two accounting systems."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
1559,
2028,
4844
],
"rationale": "The proposal modifies EIP-2028-era calldata pricing and requires coordinated consideration of EIP-1559 transaction gas semantics and EIP-4844 blob transactions/block capacity. These are multiple but narrowly scoped accounting interactions, fitting anchor 2 rather than strong, redesign-level interdependence.",
"score": 2,
"uncertainty_note": "The draft does not explicitly enumerate applicable transaction types, and it does not identify the EIP that supplied InitCodeWordGas.",
"under_specified": true,
"unidentified_interactions": [
"The contract-creation branch incorporates an existing InitCodeWordGas and words(calldata) mechanism, but the package does not identify that mechanism's EIP number."
]
}
],
"eip": 7623,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7623:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The replacement pseudocode opens a brace after tx.gasUsed and never closes the expression, while capitalization differs from the preceding tx.gasused example.",
"The formula describes gas used rather than explicitly defining intrinsic gas, remaining gas, out-of-gas behavior, or refund settlement.",
"Access-list intrinsic costs documented by the packaged EIP-1559 revision are absent from the replacement formula.",
"The phrase \"transactions primarily using Ethereum for data availability\" is implemented only indirectly through the cost crossover and is not a separately defined transaction classification."
],
"provenance": {
"assessed_revision": {
"commit": "fd4ec86e3b165ba99edf9c9e174c2f9ed78eeb3b",
"committed_at": "2024-04-03T06:16:54Z",
"content_sha256": "ba2bb398013d77c9752ad8b892f80605a777454e8bbf7cb6e11acf7d5595a496",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7623.md",
"git_blob_sha": "cdce5e7966dba53e9e384dfcb7f71d1af66b32e4",
"immutable_url": "https://github.com/ethereum/EIPs/blob/fd4ec86e3b165ba99edf9c9e174c2f9ed78eeb3b/EIPS/eip-7623.md",
"information_cutoff_at": "2024-04-11",
"path": "EIPS/eip-7623.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7623.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7623.yaml",
"sha256": "64416c928a68f36ca6401f7b2965312a84a8c8829300e863b43de6a94975e756"
},
"supporting_documents": [
"supporting/eip-1559.md",
"supporting/eip-4844.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 16,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7623 was a draft execution-layer proposal that retained the existing weighted calldata-token calculation but added a transaction total-cost floor of 12 gas per token. The normal branch combined calldata, EVM execution, and contract-creation costs, so the floor would mainly raise the effective nonzero-calldata cost for low-computation data-availability transactions while leaving sufficiently computation-heavy transactions on the existing branch. Its stated purpose was to reduce maximum block size and make room for more blobs, and it required a scheduled network upgrade.",
"tier": "medium",
"title": "Increase calldata cost",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"new_or_modified_transaction_validity_mechanisms",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 22,
"minimum": 11
},
"present": true,
"summary": "The draft establishes the numerical calldata floor but not its consensus-critical integration into transaction gas-limit checking, execution failure, unused-gas settlement, access-list and other intrinsic charges, receipts/block gas totals, or all existing transaction envelopes. The pseudocode is also syntactically incomplete, although the intended maximum is readable.",
"unresolved_questions": [
"Is the total-cost floor an up-front intrinsic-gas requirement, a post-execution adjustment to gas used, or another charging phase?",
"What happens when execution fits within the transaction gas limit under the normal branch but the floor exceeds that limit?",
"Does evm_gas_used mean gas before or after EVM refund accounting, and how does the floor affect the sender's unused-gas refund and fee settlement?",
"Where do access-list charges and any other type-specific intrinsic costs enter relative to the maximum?",
"Does the rule apply identically to legacy, EIP-1559, and EIP-4844 transaction envelopes, including blob transactions that also pay independent blob gas?",
"What complete normative expression was intended by the unclosed pseudocode, and which existing EIP defines the referenced InitCodeWordGas interaction?"
]
}
},
"prague:7642:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The proposal says it changes the eth wire protocol and does not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas accounting rule is introduced or updated, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-87",
"source": "eip.md",
"summary": "All normative changes concern eth protocol message layouts and notification timing, not opcode execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal neither changes an opcode nor reorders gas charging and state access within opcode execution, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The EIP is scoped to an eth protocol version and explicitly leaves EVM consensus rules unchanged."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob-gas accounting mechanism is mentioned or modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The EIP changes only the eth wire protocol and requires no hard fork."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "There is no state-writing gas cost, state-gas budget, reservoir, or spill path change, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-87",
"source": "eip.md",
"summary": "The specification only changes three eth wire-protocol message surfaces."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM gas-refund mechanism is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 50-87",
"source": "eip.md",
"summary": "eth/69 changes the existing Status and Receipts layouts and adds BlockRangeUpdate."
},
{
"locator": "Backwards Compatibility, lines 123-128",
"source": "eip.md",
"summary": "The new wire-protocol version can coexist with eth/68, so older-version behavior remains available."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests for the affected handshake and receipt-message paths need a limited version-specific update, but the separate eth/69 version leaves the broader and older-version test corpus intact. This fits the minor-subset anchor.",
"score": 1,
"uncertainty_note": "The package does not describe the organization or sharing of pre-existing eth protocol tests.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 48-87",
"source": "eip.md",
"summary": "The proposal defines changed and new eth/69 messages but does not prescribe a new assertion for tests unrelated to those messages."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Nothing in the text requires pre-existing tests outside this EIP's protocol surfaces to assert a new produced value, matching the zero anchor.",
"score": 0,
"uncertainty_note": "No historical test-suite inventory is included, but the proposal itself mandates no cross-cutting assertion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The change is a versioned eth wire-protocol update and explicitly requires no hard fork."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The proposal adds no transition-tool field or mechanism, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 48-87",
"source": "eip.md",
"summary": "The specification can be expressed as message encoding, decoding, and notification behavior without defining a novel testing abstraction."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "The text establishes no need for a new framework-level expectation, modifier, or helper; ordinary protocol-message tests suffice, matching the zero anchor.",
"score": 0,
"uncertainty_note": "The package contains no description of the historical network test framework.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 15-20",
"source": "eip.md",
"summary": "The proposal is limited to advertised history ranges, handshake simplification, and receipt-field removal."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic primitive or cryptographic functionality is introduced or modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Status message changes, lines 50-58",
"source": "eip.md",
"summary": "The versioned Status layout adds earliest and latest block endpoints and a latest-block hash while removing and moving prior fields."
},
{
"locator": "Specification / Receipts message changes, lines 60-77",
"source": "eip.md",
"summary": "Receipt transfer must cover typed and legacy receipt forms, status or post-state values, and variable log lists in a new flat layout."
},
{
"locator": "Specification / BlockRangeUpdate message, lines 79-87",
"source": "eip.md",
"summary": "Range updates carry two endpoints and a hash and are rate-limited to at most once per 32 blocks."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple mechanisms are boundary-prone: range endpoints and their hash, protocol-version-specific layouts, receipt variants, and update cadence. The text does not establish that any one mechanism needs the elevated case count required for score 3, so the multiple-mechanism score-2 anchor fits.",
"score": 2,
"uncertainty_note": "Range validity, empty or discontinuous availability, endpoint inclusion, and exact notification triggers are not specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 50-87",
"source": "eip.md",
"summary": "The EIP changes Status and Receipts wire encodings and adds a range notification, but does not change block RLP validation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Although the messages are intended to improve syncing, the rubric anchor is specifically for block-RLP validation mechanisms requiring client syncing; no such validation change is introduced. The zero anchor therefore applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 15-20",
"source": "eip.md",
"summary": "The affected interface is the eth peer-to-peer protocol rather than the Engine API."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API endpoint, field, or communication mechanism changes, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The EIP changes a wire-protocol version and explicitly does not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-87",
"source": "eip.md",
"summary": "The specification is confined to peer message layouts and sending behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system contract's code, state, or behavior is directly or indirectly modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The proposal states that it does not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The proposal states that it does not change EVM consensus rules."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-87",
"source": "eip.md",
"summary": "Every specified addition is an eth wire-protocol message or field."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "The proposal is a non-consensus wire-protocol version change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile logic or gas schedule is modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Status message changes, lines 50-58",
"source": "eip.md",
"summary": "eth/69 changes the ordered encoding of the Status interface, adding and removing fields and moving the block hash."
},
{
"locator": "Specification / Receipts message changes, lines 60-77",
"source": "eip.md",
"summary": "eth/69 replaces legacy and typed receipt transfer encodings with one flat receipt list that omits bloom."
},
{
"locator": "Specification / BlockRangeUpdate message, lines 79-83",
"source": "eip.md",
"summary": "A new encoded eth protocol message with range endpoints and a block hash is introduced."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal directly changes encodings at the peer interface level, which triggers the rubric's binary score-3 anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Receipts message changes, lines 60-77",
"source": "eip.md",
"summary": "Existing receipt forms are represented with a tx-type element, but no new transaction type is defined."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "Carrying the type of an existing transaction in a receipt message does not introduce a transaction type, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-87",
"source": "eip.md",
"summary": "The normative changes concern peer message encoding and range notification, not transaction acceptance or intrinsic gas."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "No transaction validity rule or intrinsic-gas calculation is added or modified, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Status message changes, lines 50-58",
"source": "eip.md",
"summary": "earliestBlock, latestBlock, and latestBlockHash are fields of the eth Status message, not fields of a block or block header."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The new interface fields do not alter the block or header schema, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 123-130",
"source": "eip.md",
"summary": "eth/69 is rolled out as a coexisting wire-protocol version and the EIP requires no hard fork."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "There is no activation-block state or internal-variable modification, matching the zero anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation / Removing Bloom in Receipts, lines 32-40",
"source": "eip.md",
"summary": "Existing receipt serving is described as regenerating and transferring roughly 530 GB of bloom data per sync."
},
{
"locator": "Rationale / Receipts changes, lines 108-121",
"source": "eip.md",
"summary": "The new encoding shifts bloom recomputation to the receiver while substantially reducing serving CPU and sync bandwidth."
},
{
"locator": "Motivation and Specification / BlockRangeUpdate, lines 42-46 and 79-87",
"source": "eip.md",
"summary": "Peers can alter fetching based on advertised history, while update traffic is limited to once per 32 blocks."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Validation spans serving-node regeneration, wire transfer, receiving-node reconstruction and verification, and range-aware peer fetching, so it cannot be fully benchmarked in isolation. The proposal itself describes a very large effect on existing sync bandwidth and CPU behavior, satisfying the score-3 anchor.",
"score": 3,
"uncertainty_note": "The EIP does not mandate a particular range-aware fetching policy or provide benchmark results for the new end-to-end path.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Receipts changes, lines 108-121",
"source": "eip.md",
"summary": "Receiving nodes must reconstruct omitted bloom data to fully verify the receipt hash under the new wire representation."
},
{
"locator": "Motivation and Specification / BlockRangeUpdate, lines 42-46 and 79-87",
"source": "eip.md",
"summary": "Untrusted peer range announcements can influence sync-status detection and fetching behavior."
},
{
"locator": "Security Considerations, lines 132-134",
"source": "eip.md",
"summary": "The EIP records no explicit security considerations."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrect parsing, bloom reconstruction, hash verification, or handling of inconsistent range announcements could affect sync correctness or resource use. These risks touch a limited set of existing networking and receipt verification components and call for targeted negative testing or fuzzing, fitting score 2 rather than an extensive multi-component review.",
"score": 2,
"uncertainty_note": "The text says there are no security considerations and does not specify validation or peer-penalty behavior for malformed or inconsistent announcements.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Status message changes, lines 50-58",
"source": "eip.md",
"summary": "Range endpoints and a corresponding hash are added without normative validity, inclusion, or consistency rules."
},
{
"locator": "Specification / Receipts message changes, lines 60-77",
"source": "eip.md",
"summary": "A new flat receipt form is given, but detailed field validity and receiver behavior are not stated."
},
{
"locator": "Specification / BlockRangeUpdate message, lines 79-87",
"source": "eip.md",
"summary": "Clients should send on range updates, need not send for every block, and must remain below a once-per-epoch rate, leaving exact trigger and timing behavior open."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Tests for malformed or inconsistent ranges, endpoint/hash relationships, receipt-field handling, and notification timing require localized agreement on outcomes that the text does not determine. The gaps are material but do not make a previously unobservable consensus behavior critical, so score 2 fits.",
"score": 2,
"uncertainty_note": "It is unclear which open details are deliberately implementation-defined rather than intended to be interoperable protocol requirements.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Motivation, lines 1-12 and 24-30",
"source": "eip.md",
"summary": "EIP-7642 explicitly requires EIP-5793 and identifies withdrawn EIP-7542 as an earlier proposal for the history-range idea."
},
{
"locator": "Backwards Compatibility, lines 46-50",
"source": "supporting/eip-5793.md",
"summary": "EIP-5793 defines eth/68 as a coexisting wire-protocol version, the baseline immediately preceding eth/69."
},
{
"locator": "Front matter and Backwards Compatibility, lines 1-11 and 48-52",
"source": "supporting/eip-7542.md",
"summary": "The withdrawn eth/70 proposal declares EIP-7642 as a requirement and describes version coexistence with eth/69 and earlier versions."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
5793,
7542
],
"rationale": "The EIP has limited protocol-version interactions with EIP-5793's eth/68 baseline and the withdrawn, dependent EIP-7542 proposal. Version negotiation and coexistence deserve coordinated consideration, but eth/69 remains independently testable for the most part, fitting score 1.",
"score": 1,
"uncertainty_note": "EIP-7542 was withdrawn, so its interaction is documentary and version-lineage related rather than an active simultaneous deployment dependency.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7642,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7642:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The specification does not state whether advertised block ranges are inclusive, contiguous, or permitted to be empty.",
"The exact correspondence and validation between latestBlock and latestBlockHash is unstated.",
"The requirement to notify whenever a range changes is qualified by discretionary per-block updates and a once-per-epoch ceiling without a deterministic trigger rule.",
"The receipt layout is concise but does not specify all malformed-field and version-mismatch outcomes needed for a common negative-test baseline."
],
"provenance": {
"assessed_revision": {
"commit": "0ddb8e9192410753ad4896b9b96510ebb2f4f6d8",
"committed_at": "2025-04-17T21:24:29Z",
"content_sha256": "b7d3002fa0a4a89d0702c6f5c18509aee6b3f3add78f67958cd533ff65e9db28",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7642.md",
"git_blob_sha": "47bcbab8ac70589110feb04d8a8ed5d7778213eb",
"immutable_url": "https://github.com/ethereum/EIPs/blob/0ddb8e9192410753ad4896b9b96510ebb2f4f6d8/EIPS/eip-7642.md",
"information_cutoff_at": "2025-04-17T21:24:29Z",
"path": "EIPS/eip-7642.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7642.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7642.yaml",
"sha256": "4cdb5b15f5f2e18e958f2eb77138083232221a685cb75ef7b08955c764cac2a4"
},
"supporting_documents": [
"supporting/eip-5793.md",
"supporting/eip-7542.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 14,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the recorded cutoff, EIP-7642 introduced eth/69 by changing the eth wire-protocol Status message to advertise a node's available block range, replacing receipt transfer with a flat encoding that omits the bloom, and adding a BlockRangeUpdate notification. It also removed total difficulty from the handshake and moved the latest block hash, while retaining eth/68 as the backward-compatible alternative. The proposal explicitly did not change EVM consensus rules or require a hard fork.",
"tier": "medium",
"title": "eth/69 - history expiry and simpler receipts",
"under_specification": {
"affected_criteria": [
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low",
"medium"
],
"plausible_total_range": {
"maximum": 15,
"minimum": 11
},
"present": true,
"summary": "The proposal does not fully define the semantics and validity of advertised range endpoints and their hash, handling of malformed or discontinuous ranges, precise BlockRangeUpdate triggers, detailed receipt-field validity, or receiver and peer-management behavior. These gaps are localized to wire interoperability and integrated sync behavior rather than EVM consensus.",
"unresolved_questions": [
"Are earliestBlock and latestBlock inclusive, and must available history be contiguous?",
"What relationship must latestBlockHash have to latestBlock, and how should a peer handle inconsistent announcements?",
"How are an empty available range, invalid endpoint ordering, and values beyond the peer's known chain represented and handled?",
"Which range changes require BlockRangeUpdate, and what exact timing satisfies both the update recommendation and once-per-epoch limit?",
"What validation, disconnect, or penalty behavior applies to malformed receipts and range messages?"
]
}
},
"prague:7685:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "The normative changes define request data, block-body RLP, a header trie root, and consensus-layer extensibility, without defining gas accounting."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No EVM gas rule or accounting mechanism is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Request source and validity, lines 96-115",
"source": "eip.md",
"summary": "System-contract calls, storage retrieval, and event parsing are expressly recommendations rather than normative changes to opcode execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The proposal changes neither an opcode's state-access position nor gas-charge ordering relative to state access, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "The specification contains request and block-structure rules but no blob gas rules or changes."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting mechanism is introduced or modified, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Request source and validity, lines 98-115",
"source": "eip.md",
"summary": "The text discusses possible contract storage and events as non-normative request sources and specifies no state-writing charge or budget."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas cost, charging site, budget, reservoir, or spill mechanism is changed, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "The normative request framework contains no gas-refund rule."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new EVM gas-refund mechanism is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block structure and Block Header, lines 50-80",
"source": "eip.md",
"summary": "Every block under the proposal gains a variable request list in its RLP body and a new header commitment derived from that list."
},
{
"locator": "Specification / Request, lines 41-48",
"source": "eip.md",
"summary": "The full request list must additionally satisfy ascending cross-type ordering."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Mandatory body and header changes plus ordering and commitment validation require a major, diverse subset of existing post-activation block-construction, serialization, import, and invalid-block tests to be reworked, meeting the score-3 anchor.",
"score": 3,
"uncertainty_note": "The sealed package contains no test inventory; the breadth is inferred from both additions being mandatory for every block governed by the proposal.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Block Header, lines 65-80",
"source": "eip.md",
"summary": "A block's new requests_root must equal the indexed trie root of the request list in its body."
},
{
"locator": "Rationale / Ordering, lines 117-126",
"source": "eip.md",
"summary": "Ascending type order is selected so all requests committed by the root can be found in the block."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "A broad category of existing block tests must mechanically assert request-list ordering and body-to-header commitment consistency, meeting score 2. The text does not establish the score-3 requirement that pre-fork vectors be re-derived.",
"score": 2,
"uncertainty_note": "Activation and treatment of existing multi-fork vectors are not specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract, lines 13-18",
"source": "eip.md",
"summary": "The framework adds one request-information field to the execution block header and one to the body."
},
{
"locator": "Specification / Request and Block Header, lines 34-80",
"source": "eip.md",
"summary": "Producing the fields requires typed request collection, ordering, and indexed-trie-root computation."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool must represent multiple new block values and support the new request-production and commitment mechanism, which is the score-3 combination of multiple fields and a new mechanism.",
"score": 3,
"uncertainty_note": "The EIP does not define a transition-tool schema or say whether the body list and derived root are separate tool outputs.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / Block structure and Block Header, lines 50-80",
"source": "eip.md",
"summary": "Tests need to represent a request list and its new header commitment."
},
{
"locator": "Test Cases, lines 140-142",
"source": "eip.md",
"summary": "The historical draft supplies no test cases or proposed framework helpers."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing block expectation structures need minor extension for the two new values, meeting score 1; the draft does not establish a reusable new expectation or modifier primitive needed for score 2.",
"score": 1,
"uncertainty_note": "Concrete request generation and validation are deferred, so the eventual need for request-specific framework primitives cannot be determined from this EIP.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block Header, lines 67-80",
"source": "eip.md",
"summary": "The request commitment reuses a Merkle-Patricia trie construction described as equivalent to the existing transaction trie root."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Reusing the existing transaction-trie commitment pattern does not introduce a new cryptographic mechanism, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Request, lines 34-48",
"source": "eip.md",
"summary": "Requests combine a type with opaque bytes and lists may contain repeated and differing types subject to cross-type ordering."
},
{
"locator": "Specification / Block Header, lines 67-80",
"source": "eip.md",
"summary": "Variable request lists are indexed into a trie whose root must match the header."
},
{
"locator": "Rationale / Intra-type, lines 128-134",
"source": "eip.md",
"summary": "Ordering within equal types is explicitly delegated to each request type."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Empty and non-empty lists, opaque-data lengths, repeated and multiple types, ordering permutations, and correct or incorrect roots create multiple boundary mechanisms with an elevated combination count, meeting score 3.",
"score": 3,
"uncertainty_note": "Type width, malformed and unknown-type handling, size limits, and empty-list semantics are not fully stated, so exact boundary vectors cannot be baselined.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block structure, lines 50-63",
"source": "eip.md",
"summary": "Block-body RLP is extended with a nested variable list of opaque requests."
},
{
"locator": "Specification / Block Header, lines 65-80",
"source": "eip.md",
"summary": "The header gains a fixed-width requests_root whose validity depends on the body list's indexed trie root."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Sync/import validation gains multiple RLP changes, including the complex variable body-list and header-commitment relationship, satisfying score 3.",
"score": 3,
"uncertainty_note": "Exact malformed-input rules are not supplied, but the mandatory body and header validation surfaces are explicit.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Abstract, lines 15-18",
"source": "eip.md",
"summary": "New execution header and body request fields are intended to expose request information to the consensus layer."
},
{
"locator": "Specification / Consensus Layer, lines 83-86",
"source": "eip.md",
"summary": "Consensus-layer proposals must extend beacon-chain types to include the new execution-layer request."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "Communicating the new body list and header commitment across the EL/CL boundary entails multiple request-related interface fields, aligning with score 2.",
"score": 2,
"uncertainty_note": "The EIP never names Engine API endpoints, versions, field placement, or whether both values are transported independently.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Request source and validity, lines 98-110",
"source": "eip.md",
"summary": "Designated system contracts are presented only as an author recommendation, while the EIP makes no strict requirement for request origin."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "The proposal itself introduces no system contract, matching the score-0 anchor; possible contracts belong to future request-source designs.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Request source and validity, lines 98-110",
"source": "eip.md",
"summary": "The only system-contract discussion is a non-normative possible source for future requests, with no pre-existing contract identified or changed."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system-contract code, state, or behavior is modified directly or indirectly by the specified framework, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "The complete specification defines block-level request data and no opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "The specification changes block request representation and does not alter any pre-existing opcode's behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode is modified or deprecated, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "No precompile is included among the request, block-body, header, or consensus-layer changes."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No new precompile is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "The normative changes contain no precompile logic or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block structure, lines 50-63",
"source": "eip.md",
"summary": "The RLP-encoded block body is extended by appending a list of requests."
},
{
"locator": "Specification / Block Header, lines 65-80",
"source": "eip.md",
"summary": "The encoded block header is extended with a new 32-byte requests_root."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal explicitly changes encoding at the block body and header levels, triggering the rubric's binary score-3 anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Request, lines 32-48",
"source": "eip.md",
"summary": "The new typed objects are requests, represented independently from transactions."
},
{
"locator": "Rationale / Request source and validity, lines 98-105",
"source": "eip.md",
"summary": "Transactions are only a recommended possible source of requests, not a new transaction envelope or type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Request source and validity, lines 98-115",
"source": "eip.md",
"summary": "The EIP imposes no strict request-source rule; transaction calls are only a recommendation, and the discussed validity is request validity split across layers."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity and intrinsic-gas rules are not changed, matching the score-0 anchor.",
"score": 0,
"uncertainty_note": "Request validity is materially underspecified, but it is distinct from the rubric's transaction-validity criterion.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Block structure and Block Header, lines 50-80",
"source": "eip.md",
"summary": "The block body gains a request-list field and the header gains the 32-byte requests_root field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "At least one new block or header field is explicitly introduced, triggering the rubric's binary score-3 anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-86",
"source": "eip.md",
"summary": "The specification defines ongoing block-format and request rules but no activation-block state mutation or special internal-variable modification."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "No special fork-activation state or internal-variable modification is specified, matching score 0.",
"score": 0,
"uncertainty_note": "Activation semantics are omitted, but omission does not establish the special activation-block mutation required by the score-3 anchor.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Request and Block Header, lines 34-80",
"source": "eip.md",
"summary": "Blocks carry a variable list of opaque request bytes that must be ordered, RLP-encoded, indexed into a trie, and committed in the header."
},
{
"locator": "Abstract, lines 15-18",
"source": "eip.md",
"summary": "The request information crosses execution block production and consensus-layer processing."
},
{
"locator": "Rationale / Request source and validity, lines 98-110",
"source": "eip.md",
"summary": "Source and rate-limiting approaches are left to future designers rather than bounded by this EIP."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The variable data path spans execution-derived collection, block construction, trie computation, validation, propagation, and CL consumption. Its integrated impact and interactions with existing block processing cannot be fully benchmarked in isolation, meeting score 3.",
"score": 3,
"uncertainty_note": "No size, count, or rate limit is defined, and concrete request types are absent, so workload magnitude is unresolved.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 13-26",
"source": "eip.md",
"summary": "Contract-triggered execution-layer requests are exposed for consensus-layer processing of validator-related administrative behavior."
},
{
"locator": "Rationale / Request source and validity, lines 96-115",
"source": "eip.md",
"summary": "Request origin and validation are non-normative, with possible validation split between system contracts on the EL and further checks on the CL."
},
{
"locator": "Security Considerations, lines 144-146",
"source": "eip.md",
"summary": "The historical security section is unresolved and states that discussion is needed."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The mechanism connects contract execution, block commitments, EL validation, and consensus-layer actions, all security-critical components, while altering their trust and validation boundaries. This supports score 3 and extensive security review and fuzzing.",
"score": 3,
"uncertainty_note": "Concrete actions and their validation are deferred, preventing a complete threat model at this revision.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Consensus Layer, lines 83-86",
"source": "eip.md",
"summary": "Each future proposal may independently choose how beacon-chain types include its execution-layer request."
},
{
"locator": "Rationale / Request source and validity, lines 96-115",
"source": "eip.md",
"summary": "The EIP deliberately imposes no strict rule for where requests originate or when and how they are validated."
},
{
"locator": "Rationale / Intra-type; Test Cases; Security Considerations, lines 128-146",
"source": "eip.md",
"summary": "Intra-type ordering is delegated, while test cases and security analysis are still TODO or unresolved."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Request production and validation behavior that was not previously part of a block commitment becomes consensus-visible through requests_root, yet the draft leaves multiple constructible cases unresolved. Clients and request-specific proposals must agree before vectors can be baselined, meeting score 3.",
"score": 3,
"uncertainty_note": "It is unclear which gaps are intentionally outside the generic framework and which were expected to become normative within this EIP, but either reading requires cross-client coordination before end-to-end testing.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Request, lines 41-48",
"source": "eip.md",
"summary": "Each request type must define its own intra-type ordering."
},
{
"locator": "Specification / Consensus Layer, lines 83-86",
"source": "eip.md",
"summary": "Each proposal may define its own beacon-chain type extension for its execution-layer request."
},
{
"locator": "Rationale / Request source and validity, lines 98-115",
"source": "eip.md",
"summary": "Future protocol designers must supply request source and cross-layer validity rules that integrate with the generic bus."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The framework depends on request-specific proposals for production, ordering, validation, and CL representation, so coordinated testing is required, but the generic interaction surface is limited enough for score 2. The package names no interacting EIP, so no number is inferred.",
"score": 2,
"uncertainty_note": "The number and identity of request-type proposals present at the cutoff are not stated, preventing assessment of stronger multi-EIP interdependency or the uncapped surcharge.",
"under_specified": true,
"unidentified_interactions": [
"Request-type-specific proposals that define intra-type ordering, request source and validity, and beacon-chain type extensions; no EIP numbers are identified in the package."
]
}
],
"eip": 7685,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7685:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The request_type representation is not given an explicit width or registry, even though examples use single-byte values and cross-type ordering is normative.",
"The text says requests_root commits to the body list but does not separately spell out malformed-list, unknown-type, mismatch, or empty-list validation.",
"The EL-to-CL exposure is an objective of the proposal, while its Engine API and beacon-chain representation are not specified.",
"The proposal is Draft, its test cases are TODO, and its security considerations state that discussion is needed at the cutoff."
],
"provenance": {
"assessed_revision": {
"commit": "e2a66831fcc5984f478513ce298607e178c364e8",
"committed_at": "2024-04-18T22:38:06Z",
"content_sha256": "83e2e6c4341af7260fbab8a716ec8c74d450679c377e6c9650a11f95d351ef29",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7685.md",
"git_blob_sha": "428e1902581ffcae80420d2527045228a2a818da",
"immutable_url": "https://github.com/ethereum/EIPs/blob/e2a66831fcc5984f478513ce298607e178c364e8/EIPS/eip-7685.md",
"information_cutoff_at": "2024-04-25",
"path": "EIPS/eip-7685.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7685.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7685.yaml",
"sha256": "6557e9d12cb96721fc18338c8430ced53500874169ab77a9bd583e9fbaa20e91"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 34,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this draft defined a generic container for execution-layer requests intended for consensus-layer processing. It appended an ordered list of typed opaque requests to the RLP block body and added a 32-byte header commitment computed as an indexed Merkle-Patricia trie root. Concrete request provenance and validity, intra-type ordering, and consensus-layer type extensions were left to request-specific proposals.",
"tier": "high",
"title": "General purpose execution layer requests",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"new_fork_activation_mechanism",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 37,
"minimum": 22
},
"present": true,
"summary": "The draft deliberately defers normative request provenance and validity, intra-type ordering, and consensus-layer type extensions to request-specific proposals. It also leaves Engine API transport, malformed or unknown request handling, size and rate limits, activation semantics, tests, and security analysis unstated, preventing a complete generic cross-client baseline.",
"unresolved_questions": [
"What exact request sources are consensus-valid, and how is completeness of the body request list validated against execution?",
"What is the width and valid range of request_type, and how are empty, malformed, duplicate-type, or unknown-type request items handled?",
"What intra-type ordering is required for each request type, and which proposal owns that rule?",
"Which Engine API fields or endpoints transport requests and their commitment, and which consensus-layer types carry them?",
"What request count, byte-size, or rate limits apply, and how do those limits interact with block validity and performance?",
"What activation, empty-list, and pre-fork compatibility rules govern the new body and header fields?"
]
}
},
"prague:7691:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 28-42",
"source": "eip.md",
"summary": "The complete change set consists of blob-count, blob-gas, and blob-base-fee parameters; it does not change normal EVM execution-gas accounting."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal changes the separate blob-gas mechanism, not an EVM gas accounting rule, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 28-42",
"source": "eip.md",
"summary": "The specification only replaces cross-layer blob parameters and defines no opcode execution or state-access sequence."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode's state-access position or gas-charge ordering is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 32-42",
"source": "eip.md",
"summary": "The execution layer replaces the existing blob-gas maximum, target, and base-fee update fraction at the fork."
},
{
"locator": "Specification / Gas accounting, lines 164-184",
"source": "supporting/eip-4844.md",
"summary": "EIP-4844 defines the pre-existing independent blob-gas accounting and base-fee mechanism whose constants EIP-7691 updates."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "This is a direct update to an existing blob-gas accounting mechanism, matching score 1 rather than introducing a new mechanism.",
"score": 1,
"uncertainty_note": "The new execution constants are not consistently given fork-specific names, but their replacement role is explicit.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 28-42",
"source": "eip.md",
"summary": "The parameter changes concern blobs and their fee market, with no state-write gas cost, state-gas budget, or reservoir change."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state gas accounting rule is introduced or adjusted.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 28-42",
"source": "eip.md",
"summary": "The specification contains only blob capacity and base-fee parameters and defines no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 32-42",
"source": "eip.md",
"summary": "Existing maximum, target, and update-fraction values become fork-dependent and are replaced by new values."
},
{
"locator": "Specification / Execution layer validation, lines 244-287",
"source": "supporting/eip-4844.md",
"summary": "Existing blob tests cover excess-blob-gas calculation, blob fee validity, total blob gas against the maximum, and the header total, all of which use the changed parameters."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor, focused subset of pre-existing EIP-4844 validation and fee tests must be made fork-aware or re-baselined, matching score 1.",
"score": 1,
"uncertainty_note": "The package does not enumerate the historical test inventory, so the affected subset size is inferred from the specified validation paths.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 28-42",
"source": "eip.md",
"summary": "The proposal replaces values used by existing blob rules and does not require unrelated tests to assert a newly produced property."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Affected blob tests change their parameterized expectations; pre-existing tests do not gain a separate new invariant.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "No transition-tool input or output field, endpoint, or new communication mechanism is specified; only fork-selected protocol constants change."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "Existing fork selection must choose different constants, but the text requires no transition-tool interface modification.",
"score": 0,
"uncertainty_note": "The proposal does not discuss transition-tool configuration, so this score assumes existing fork-selection inputs suffice.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Parameters, lines 32-42",
"source": "eip.md",
"summary": "The feature is expressed as replacement numeric parameters applied at an existing fork boundary, with no novel expectation type or testing abstraction described."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Parameterized boundary and fee tests can use existing primitives.",
"score": 0,
"uncertainty_note": "Test-framework details are not included in the package, but the specified behavior does not imply a new primitive.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 32-42",
"source": "eip.md",
"summary": "EIP-7691 changes blob quantity and fee constants but specifies no cryptographic algorithm, proof rule, commitment format, or verification behavior."
},
{
"locator": "Specification / Cryptographic Helpers, lines 67-74",
"source": "supporting/eip-4844.md",
"summary": "KZG verification is part of the already-existing EIP-4844 blob mechanism rather than a mechanism introduced or modified by EIP-7691."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "More blobs can increase the amount of existing cryptographic work, which is a performance issue, but no cryptographic functionality changes under this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Update Fraction, lines 52-64",
"source": "eip.md",
"summary": "The new 2:3 target-to-maximum ratio makes empty and full blocks affect the base fee asymmetrically, and the selected fraction is a compromise between the two response boundaries."
},
{
"locator": "Security Considerations / Stability Around Fork Epoch, lines 78-80",
"source": "eip.md",
"summary": "The proposal explicitly identifies the limit change at the fork transition as a point requiring increased monitoring."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Tests must cover multiple related boundaries: pre/post-fork selection, the 9-blob maximum, target crossings, empty/full blocks, and excess-blob-gas flooring; none requires an exceptional test-case explosion, so score 2 applies.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Parameters, lines 28-42",
"source": "eip.md",
"summary": "The proposal changes accepted blob totals through constants but does not alter block or header RLP structure or introduce an RLP validation mechanism."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "A fork-dependent block-validity threshold alone is not the rubric's block-RLP syncing change.",
"score": 0,
"uncertainty_note": "Sync tests may include larger valid blocks, but no new RLP validation rule is specified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The complete normative specification introduces no Engine API field, directive, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "Existing payload structures carry the same information at higher permitted blob counts, so no Engine API anchor is triggered.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "Only protocol constants are defined; no address, bytecode, state, or system action for a new contract appears."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The blob parameter replacements neither name nor alter any pre-existing system contract code, state, or behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No direct or specified indirect system-contract modification is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The normative change consists only of five blob-related constants and adds no EVM instruction."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "No pre-existing opcode behavior is mentioned or changed by the parameter replacements."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No opcode result or non-gas behavior is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The specification contains no new precompile address or execution logic."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "Neither precompile logic nor a precompile gas schedule is among the changed constants."
},
{
"locator": "Specification / Point evaluation precompile, lines 195-226",
"source": "supporting/eip-4844.md",
"summary": "The linked EIP's existing point-evaluation precompile has fixed logic and gas cost that EIP-7691 does not alter."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "Increased blob capacity does not itself modify the existing point-evaluation precompile.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Parameters, lines 28-42",
"source": "eip.md",
"summary": "No transaction, block, header, or interface encoding changes are specified; only bounds and a fee parameter change."
},
{
"locator": "Specification / Header extension, lines 119-162",
"source": "supporting/eip-4844.md",
"summary": "The blob-related header fields and their RLP positions already exist under EIP-4844 and are not extended by EIP-7691."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The same encodings continue to be used, so the binary encoding-change anchor is zero.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The proposal changes parameters for existing blobs and defines no transaction envelope or transaction type identifier."
},
{
"locator": "Specification / Blob transaction, lines 97-117",
"source": "supporting/eip-4844.md",
"summary": "The blob transaction type is pre-existing EIP-4844 functionality and its format is not changed by EIP-7691."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Parameters, lines 32-42",
"source": "eip.md",
"summary": "The execution-layer blob-gas target, maximum, and base-fee update fraction used by existing blob validation become fork-dependent."
},
{
"locator": "Specification / Execution layer validation, lines 260-287",
"source": "supporting/eip-4844.md",
"summary": "Existing blob transactions are checked against the computed blob base fee, while aggregate blob gas is checked against the maximum that EIP-7691 raises."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing validation formulas remain intact, but their fork-selected thresholds and fee outcome change; this is a minor adjustment matching score 1.",
"score": 1,
"uncertainty_note": "The maximum is formally a block-level aggregate check rather than per-transaction validity, while the fee threshold affects blob-transaction acceptance indirectly through the changed base-fee computation.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 28-42",
"source": "eip.md",
"summary": "The proposal does not add a block or header field."
},
{
"locator": "Specification / Header extension, lines 119-162",
"source": "supporting/eip-4844.md",
"summary": "The blob_gas_used and excess_blob_gas fields are existing EIP-4844 fields whose values continue to be governed by the same header structure."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "Existing fields carry the results of the updated accounting, so no new-field anchor is triggered.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 40-42",
"source": "eip.md",
"summary": "At the Pectra fork boundary, consensus clients replace the old blob count values and execution clients replace the old maximum, target, and update fraction."
},
{
"locator": "Backwards Compatibility, lines 66-70",
"source": "eip.md",
"summary": "Cancun/Deneb retain the prior values, while Prague/Electra activate the replacement parameter set."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Existing internal protocol parameters are modified specifically at the activation boundary, which directly matches the rubric's score-3 binary anchor.",
"score": 3,
"uncertainty_note": "The text mixes an epoch-named activation variable with timestamp wording for the execution layer and is inconsistent in suffixing the replacement execution constants.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 19-25",
"source": "eip.md",
"summary": "The prior limits were chosen cautiously because mainnet peer-to-peer behavior is hard to predict, and the increase is conditioned on big-block/blob tests, monitoring, bandwidth savings, and concern for solo stakers."
},
{
"locator": "Specification / Consensus layer validation, lines 228-243",
"source": "supporting/eip-4844.md",
"summary": "Every consensus node participates in blob availability, sidecar propagation and sync, while validators produce and publish the data affected by the higher limit."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The higher sustained and peak blob load cannot be validated solely in an isolated component and substantially affects existing networking, propagation, availability, sync, and validation benchmarks, matching score 3.",
"score": 3,
"uncertainty_note": "The proposal gives chosen limits and qualitative test needs but no packaged benchmark results.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Security Considerations / Network Impacts, lines 72-80",
"source": "eip.md",
"summary": "The proposal requires mainnet and testnet big-block/blob tests to establish that the higher limit does not harm network health and calls for extra monitoring around activation."
},
{
"locator": "Motivation, lines 19-25",
"source": "eip.md",
"summary": "Unpredictable peer-to-peer behavior, reorganization rate, bandwidth, and solo-staker impact are explicit considerations in selecting the increase."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Raising an existing data-availability limit alters networking and validator resource assumptions and warrants targeted cross-layer security validation, but it does not introduce a new cryptographic or broadly invasive mechanism; score 2 is the best fit.",
"score": 2,
"uncertainty_note": "The EIP characterizes the change as contained, while the package supplies no quantitative boundary at which network degradation becomes security-critical.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 32-42",
"source": "eip.md",
"summary": "The intended replacement values are explicit, but the execution activation is described as starting at a PECTRA_FORK_EPOCH timestamp and two replacement execution constants reuse their old unsuffixed names."
},
{
"locator": "Backwards Compatibility, lines 66-70",
"source": "eip.md",
"summary": "The compatibility text clarifies the intended fork split, although it again uses the same MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK names on both sides of the fork."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "These are a few localized specification ambiguities with an obvious intended reading—synchronized fork-scoped replacement of the listed constants—so score 1 applies.",
"score": 1,
"uncertainty_note": "Exact execution-layer activation terminology and constant naming should be normalized before cross-client vectors are baselined.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 23-25",
"source": "eip.md",
"summary": "EIP-7623 is identified as creating block-size headroom for the blob increase, while EIP-7594 is the longer-term PeerDAS path that this short-term increase precedes."
},
{
"locator": "Rationale / Update Fraction, lines 52-64",
"source": "eip.md",
"summary": "The proposal changes target/maximum assumptions and fee responsiveness inherited from EIP-4844."
},
{
"locator": "Metadata and Specification, lines 1-12 and 24-32",
"source": "supporting/eip-7594.md",
"summary": "EIP-7594 explicitly requires EIP-4844 and extends its blobs into a different data-availability design, grounding the limited successor interaction described by EIP-7691."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
4844,
7594,
7623
],
"rationale": "EIP-7691 directly modifies EIP-4844 and requires coordinated consideration with the explicitly identified calldata-headroom and PeerDAS proposals, but the interactions are limited and do not demand extensive redesign; score 2 applies.",
"score": 2,
"uncertainty_note": "EIP-7594 is described as a future successor rather than a co-activated dependency, so its interaction is weaker than the EIP-4844 and EIP-7623 relationships.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 7691,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7691:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The execution-layer activation wording combines PECTRA_FORK_EPOCH with timestamp semantics, while the compatibility section refers to the Prague fork.",
"The replacement execution maximum and target reuse their old constant names even though the prose says the old values are replaced at activation.",
"A local-builder maximum-blob flag is mentioned only as an approach that could be considered and is not part of the normative specification."
],
"provenance": {
"assessed_revision": {
"commit": "1da6c754956341416a1672cf1f0f3b80a97c213d",
"committed_at": "2024-12-18T19:05:43Z",
"content_sha256": "bc0b382748c69fb2fbe5d39b7b9a3f3bfe82560b12fb39691c39efca61b63a5e",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7691.md",
"git_blob_sha": "61b85e933b138a5362db07d0f80c634e47b2c3a2",
"immutable_url": "https://github.com/ethereum/EIPs/blob/1da6c754956341416a1672cf1f0f3b80a97c213d/EIPS/eip-7691.md",
"information_cutoff_at": "2024-12-18T19:48:12Z",
"path": "EIPS/eip-7691.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7691.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7691.yaml",
"sha256": "5b2628e57d07d4014af46599fb3a16f2966b9d142673c1c62df57b6af6937572"
},
"supporting_documents": [
"supporting/eip-4844.md",
"supporting/eip-7594.md",
"supporting/eip-7623.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 16,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-7691 raised the consensus-layer blob target and maximum from the EIP-4844 values to 6 and 9 blobs per block and raised the corresponding execution-layer blob-gas target and maximum. It also selected a new blob-base-fee update fraction to account for the asymmetric distance from the new target to empty and full blocks. All replacements were specified to activate with the Electra/Prague fork, without adding a transaction format, header field, opcode, precompile, or cryptographic mechanism.",
"tier": "medium",
"title": "Blob throughput increase",
"under_specification": {
"affected_criteria": [
"blob_gas_accounting_changes",
"new_fork_activation_mechanism",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium"
],
"plausible_total_range": {
"maximum": 17,
"minimum": 15
},
"present": true,
"summary": "The normative values and intended fork split are clear, but the execution-layer activation phrase combines an epoch identifier with timestamp semantics and the new maximum/target constants reuse the old names. These are localized rather than design-wide gaps, and the evident intended behavior is to select all new values together at the Prague/Electra boundary.",
"unresolved_questions": [
"What exact execution-layer fork signal is intended by \"starting at PECTRA_FORK_EPOCH timestamp,\" and how is it aligned with the consensus-layer epoch boundary?",
"Are MAX_BLOB_GAS_PER_BLOCK and TARGET_BLOB_GAS_PER_BLOCK intended to be explicitly fork-scoped constants despite retaining their pre-fork names?"
]
}
},
"prague:7702:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 42-52",
"source": "eip.md",
"summary": "The new transaction inherits EIP-2930 intrinsic gas and adds per-byte gas for each code blob plus a 5000-gas base charge for every authorization entry."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This is a new intrinsic-gas mechanism scoped to the new transaction type. It composes with existing intrinsic accounting without changing pre-existing transaction types, matching score 2.",
"score": 2,
"uncertainty_note": "Malformed-entry, arithmetic-overflow, and non-code authorization-byte charging rules are not fully specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 54-61",
"source": "eip.md",
"summary": "Code checking, installation, and warming occur during transaction setup, while clearing occurs at transaction end."
},
{
"locator": "Rationale, lines 82-85",
"source": "eip.md",
"summary": "The proposal explicitly states that it does not add opcodes."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The change is at transaction boundaries, not inside an opcode's execution, so no opcode-level state-access or gas-charge ordering changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 44-63",
"source": "eip.md",
"summary": "The transaction fields and costs concern execution gas, access lists, authorizations, and account code; no blob field or blob-gas rule appears."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal contains no blob gas accounting change.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 52-61",
"source": "eip.md",
"summary": "Only intrinsic execution-gas charges are specified; temporary code mutation has no separate state-gas budget, rate, reservoir, or spill rule."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Temporary account-code writes do not by themselves introduce the state-gas accounting mechanism defined by this criterion.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-61",
"source": "eip.md",
"summary": "The proposal specifies positive intrinsic charges and setup/cleanup but no refund-counter update or refund condition."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 44-63",
"source": "eip.md",
"summary": "All new processing is gated on a newly introduced typed transaction, leaving specified behavior of pre-existing transaction types unchanged."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A new feature test family is required, but the historical text does not establish a rule forcing pre-existing tests to be reworked.",
"score": 0,
"uncertainty_note": "Incomplete failure and cleanup semantics could later expose broader regressions, but they are not established at the cutoff.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility, lines 89-91",
"source": "eip.md",
"summary": "A balance invariant is broken with consequences for mempools and inclusion lists, but no new output is prescribed for every unrelated existing test."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "The invariant break needs targeted regression tests, not a new mechanically applicable assertion on tests that are not about this EIP.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 44-61",
"source": "eip.md",
"summary": "A new typed transaction carries nested contract_code, y_parity, r, and s fields and triggers per-entry recovery, validation, mutation, warming, and cleanup."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool needs multiple new nested fields and a new authorization-array processing mechanism, matching score 3.",
"score": 3,
"uncertainty_note": "The concrete transition-tool schema and whether it accepts decoded entries or raw typed bytes are not specified.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 46-61",
"source": "eip.md",
"summary": "Tests must construct and sign a nested authorization transaction and observe account code during execution and after cleanup."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Reusable transaction builders/signers and temporary-code expectations are needed within this EIP's suite, matching score 2; permanent use by other EIPs is not established.",
"score": 2,
"uncertainty_note": "No test design shows the exact boundary between existing helper extensions and wholly new primitives.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 54-59",
"source": "eip.md",
"summary": "Each authorization uses ecrecover over a keccak hash of MAGIC and contract_code with y_parity, r, and s."
},
{
"locator": "Specification, lines 36-38 and 51-53",
"source": "supporting/eip-2930.md",
"summary": "The inherited transaction family already uses secp256k1 signatures represented by y parity, r, and s."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "This is another use of well-known, protocol-used keccak and secp256k1 recovery, not a novel cryptographic primitive, matching score 1.",
"score": 1,
"uncertainty_note": "Signature canonicality and invalid-recovery rules for authorizations are omitted.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 48-63",
"source": "eip.md",
"summary": "A variable-length array is processed in order with recovery, an empty-code check, code mutation, warming, cleanup, and signer/origin separation."
},
{
"locator": "Backwards Compatibility and Security Considerations, lines 89-95",
"source": "eip.md",
"summary": "Temporary authority can reduce a non-origin account's balance and users must be careful about arbitrary code they sign."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Empty/malformed arrays, invalid signatures, pre-existing code, repeated signers, gas thresholds, success/revert, cleanup, and address aliasing combine into an elevated stateful test matrix, matching score 3.",
"score": 3,
"uncertainty_note": "Several boundary outcomes first require consensus interpretation because the draft does not define them.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 44-50",
"source": "eip.md",
"summary": "The proposal defines a new EIP-2718 RLP TransactionPayload."
},
{
"locator": "Specification, lines 28-34",
"source": "supporting/eip-2718.md",
"summary": "The existing typed envelope already permits TransactionType plus an opaque payload inside the established transaction trie."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Sync clients must recognize the type, but no block-level RLP validation mechanism changes; EIP-2718 already makes typed payloads opaque at that layer.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 33-63",
"source": "eip.md",
"summary": "The specification covers transaction parameters, payload, cost, and execution processing, with no Engine API endpoint or field."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or communication mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 44-63",
"source": "eip.md",
"summary": "User-supplied code is installed temporarily on signer accounts; no protocol system contract is deployed or designated."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 54-61",
"source": "eip.md",
"summary": "Mutation applies to recovered signer accounts whose code must be empty, not to pre-existing system-contract code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No system contract is directly or indirectly modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale, lines 82-85",
"source": "eip.md",
"summary": "The proposal explicitly states that it does not add opcodes."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 54-61 and 67-74",
"source": "eip.md",
"summary": "Account code changes at transaction boundaries and ordinary calls execute that code; no existing opcode's result semantics are redefined."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "Opcodes observe changed state, but their own behavior is not modified, so this is not an opcode modification under the criterion.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 54-59",
"source": "eip.md",
"summary": "Setup invokes existing ecrecover functionality but defines no new precompile address or behavior."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 54-59",
"source": "eip.md",
"summary": "Signer recovery uses ecrecover without changing its logic or gas schedule."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 44-50",
"source": "eip.md",
"summary": "A transaction-level RLP payload is introduced with a nested array of contract_code and signature components."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The rubric assigns score 3 for any transaction-level encoding change; this new RLP schema directly meets the anchor.",
"score": 3,
"uncertainty_note": "Receipt encoding and detailed nested-array RLP validity constraints are omitted.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 37-50",
"source": "eip.md",
"summary": "TX_TYPE is declared and a new EIP-2718 transaction with that type and a new payload is explicitly introduced."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The rubric assigns score 3 for introduction of a new transaction type.",
"score": 3,
"uncertainty_note": "The numerical TX_TYPE value remains TBD at the cutoff.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 46-59",
"source": "eip.md",
"summary": "The transaction adds nested RLP authorization entries, intrinsic-gas rules, signer recovery, an empty-code precondition, and ordered setup actions."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Per-entry signatures, account-state preconditions, variable-length structural validity, and costs require extensive combinations and new typed-transaction support, matching score 3.",
"score": 3,
"uncertainty_note": "Authorization failure outcome, outer signature preimage, and receipt definition are not specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 44-63",
"source": "eip.md",
"summary": "All newly defined fields belong to the transaction payload."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 37-44",
"source": "eip.md",
"summary": "A fork block gates the new type, but no one-time state or internal-variable mutation at activation is specified."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary fork gating is not an activation-block transition under the anchor.",
"score": 0,
"uncertainty_note": "The fork block remains TBD, but that does not alter the score.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 48-61",
"source": "eip.md",
"summary": "Each of multiple variable-size entries requires hashing, recovery, account-code lookup, installation, warming, eventual removal, and ordinary EVM execution."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Temporary code interacts with account/code caching, state snapshots, access warming, arbitrary execution, and cleanup, so end-to-end impact cannot be fully benchmarked in isolation and has complex existing interactions, matching score 3.",
"score": 3,
"uncertainty_note": "No performance analysis, explicit code-size limit, authorization-count limit beyond gas, or caching guidance is included.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility and Security Considerations, lines 89-95",
"source": "eip.md",
"summary": "A balance invariant is broken, mempools and inclusion lists are affected, shared EIP-3074 risks apply, and users are warned about code they sign."
},
{
"locator": "Security Considerations, lines 326-350",
"source": "supporting/eip-3074.md",
"summary": "Shared risks include replay protection, authorization of call properties, near-complete EOA compromise, tx.origin assumptions, and relayer griefing."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Arbitrary temporary EOA code and separated origin/authority roles alter critical account, balance, execution, mempool, relayer, and application assumptions, requiring extensive review and fuzzing, matching score 3.",
"score": 3,
"uncertainty_note": "The sparse section imports EIP-3074 concerns without specifying which mitigations or signature-domain protections this design adopts.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 37-63",
"source": "eip.md",
"summary": "Constants are TBD and the terse loop omits failure, atomicity, duplicate-entry, outer-signature, receipt, and exceptional-cleanup rules."
},
{
"locator": "Backwards Compatibility, lines 89-91",
"source": "eip.md",
"summary": "Temporary authority makes a previously relied-upon balance invariant observably false for mempool and inclusion-list behavior."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Temporary EOA code becomes consensus-observable while constructible failure and lifecycle outcomes remain unanswered. Clients must agree before vectors can be baselined, matching score 3.",
"score": 3,
"uncertainty_note": "No packaged test cases or more detailed specification resolves these questions at the cutoff.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Front matter and Specification, lines 11 and 44-59",
"source": "eip.md",
"summary": "EIPs 2718, 2929, and 2930 supply the envelope, cost basis, access list, and signer warming."
},
{
"locator": "Abstract, Motivation, and Rationale, lines 16, 26-31, and 67-87",
"source": "eip.md",
"summary": "The proposal replaces EIP-3074 workflows, claims EIP-4337 wallet and EntryPoint compatibility, and describes EIP-5003 as a direct extension."
},
{
"locator": "Specification, lines 49-107",
"source": "supporting/eip-2930.md",
"summary": "EIP-2930 supplies typed RLP, signature, intrinsic access-list charges, and warm access-set handling inherited by the proposal."
}
],
"exceptional_score_justification": "This row is uncapped. Six interacting EIPs yield score 4 under the explicit +1-for-every-three-additional-EIPs formula.",
"id": "cross_eip_interactions",
"interacting_eips": [
2718,
2929,
2930,
3074,
4337,
5003
],
"rationale": "EIPs 2718, 2929, and 2930 are strong protocol dependencies needing coordinated transaction, gas, and warm-access tests. EIPs 3074, 4337, and 5003 add workflow, security, integration, and migration axes. Six interactions give base 3 plus one point for the first three beyond the initial three.",
"score": 4,
"uncertainty_note": "Relationships with 3074, 4337, and 5003 lack full conformance boundaries or test plans.",
"under_specified": false,
"unidentified_interactions": [
"Backwards Compatibility says the broken balance invariant affects inclusion-list proposals but gives no EIP number.",
"Rationale mentions compatibility considerations around RIP-7560, which is not identified as an EIP in the sealed package."
]
}
],
"eip": 7702,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7702:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"MAGIC, TX_TYPE, and the fork block remain TBD; this prevents executable vectors but is separate from the more consequential missing behavioral rules.",
"The intrinsic-cost sentence calls code bytes calldata bytes and does not say how remaining encoded authorization-signature bytes are charged.",
"The empty-code verification has no failure mode, so a two-entry duplicate-signer vector has no determined outcome.",
"End-of-transaction code clearing does not define restoration semantics after execution changes or destroys a signer account."
],
"provenance": {
"assessed_revision": {
"commit": "ad9ecb077cac50baf02350ac5d34efc87fdcdbdf",
"committed_at": "2024-05-09T20:47:43Z",
"content_sha256": "ed08fdd82ff96de1912bddcd30e44e7ab32500bba439cebc6219e4ce634f405d",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md",
"git_blob_sha": "8534301caff92e1185bfcc9d0020877d09d356b9",
"immutable_url": "https://github.com/ethereum/EIPs/blob/ad9ecb077cac50baf02350ac5d34efc87fdcdbdf/EIPS/eip-7702.md",
"information_cutoff_at": "2024-05-23",
"path": "EIPS/eip-7702.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7702.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7702.yaml",
"sha256": "b2d810a2047dc55c4d7563c232a58ad716c7cc8bc34a6f0f9fa9ec3aff027860"
},
"supporting_documents": [
"supporting/eip-20.md",
"supporting/eip-2718.md",
"supporting/eip-2929.md",
"supporting/eip-2930.md",
"supporting/eip-3074.md",
"supporting/eip-4337.md",
"supporting/eip-5003.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 33,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "The historical draft introduces a new EIP-2718 typed transaction, derived from EIP-2930, that carries an array of contract-code blobs and ECDSA authorization tuples. Before transaction execution, the client recovers each signer, requires that signer to have empty code, temporarily installs the authorized code, and warms the signer under EIP-2929; after execution, it clears each signer's code. The transaction origin may differ from every code signer, enabling EOA batching, sponsorship, and privilege de-escalation without adding opcodes.",
"tier": "high",
"title": "Set Code for EOAs",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"cryptography",
"edge_boundary_conditions",
"encoding_changes_rlp_ssz",
"new_or_modified_transaction_validity_mechanisms",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 36,
"minimum": 26
},
"present": true,
"summary": "The draft gives a high-level transaction shape and setup/cleanup loop but leaves transaction validity, authorization failure and atomicity, duplicate ordering, signature domain/canonicality, outer signing, receipt encoding, code limits, and exceptional cleanup unresolved. Distinct client choices would change accepted transactions, gas, observable code, or final state.",
"unresolved_questions": [
"What payload does the outer signature cover, and what receipt payload and typed signature-domain rules apply?",
"Does failed recovery, non-empty signer code, malformed signature data, or a malformed entry invalidate the transaction, skip the entry, or do something else, and are earlier mutations rolled back?",
"How are duplicate signers ordered after the first entry makes code non-empty, and are repeated or empty code blobs valid?",
"What code-size, code-format, entry-count, and intrinsic-gas overflow rules constrain the authorization list?",
"How is temporary code restored after top-level failure, nested reverts, SELFDESTRUCT, CREATE/CREATE2 collisions, or other signer-account changes?",
"Is omission of value intentional zero-value semantics, and which typed-transaction validity rules are inherited beyond intrinsic cost?",
"Do the code read and write affect warming or incur gas before step 4 explicitly adds the signer to accessed_addresses?"
]
}
},
"prague:7840:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-43",
"source": "eip.md",
"summary": "The proposal's specified change is a per-fork target/max blob-count object in client configuration files with fallback lookup behavior."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The configuration schema does not change EVM execution-gas accounting, so the zero anchor applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The specification only defines a configuration object and fork-value fallback; it specifies no opcode execution path or state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode state-access or gas-charge ordering is changed.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Motivation, lines 13-22",
"source": "eip.md",
"summary": "The proposal makes target and maximum blob counts per block dynamically adjustable by fork through execution-client configuration."
},
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The schedule supplies different Cancun and Prague target/max values and defines how the effective values are inherited or defaulted."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "Moving existing blob target/max parameters to a per-fork schedule updates the existing blob-accounting configuration mechanism but does not introduce a new accounting mechanism.",
"score": 1,
"uncertainty_note": "The text does not precisely identify which blob-accounting calculations consume each value or whether the displayed numbers are normative.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-43",
"source": "eip.md",
"summary": "The only configured quantities are per-block target and maximum blob counts."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-write gas cost, state-gas charging site, budget, reservoir, or spill behavior is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The specification is limited to blobSchedule configuration fields and their fallback values."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Backwards Compatibility, lines 24-43 and 55-57",
"source": "eip.md",
"summary": "The new behavior is a configuration lookup rule, and the proposal reports no backward-compatibility issue or new protocol validation rule."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The text does not establish that pre-existing execution tests must be reworked; the schedule and fallback can be covered by focused new configuration cases.",
"score": 0,
"uncertainty_note": "The EIP does not say whether existing test configurations embed these client configuration files.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-43",
"source": "eip.md",
"summary": "The proposal defines a client-configuration field and resolution rule, without requiring unrelated tests to assert a new output."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "No new assertion is imposed on tests that are not about this configuration feature.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-43",
"source": "eip.md",
"summary": "The named interface is the execution-client configuration file; no transition-tool request or response field is specified."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A client configuration object is not, on the available text, a modification to the transition-tool interface.",
"score": 0,
"uncertainty_note": "The proposal does not discuss whether transition tools consume the same configuration schema.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The behavior consists of parsing a JSON-shaped schedule and selecting an explicit, inherited, or zero value."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "These cases can be expressed with ordinary inputs and expected values; no new expectation, modifier, or reusable framework primitive is required by the text.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The schedule contains only fork keys and integer target/max blob counts."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism or cryptographic functionality is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 42-43",
"source": "eip.md",
"summary": "A missing current-fork entry inherits the last specified fork value, while absence of any prior value yields zero for both fields."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The proposal introduces one boundary-prone schedule-resolution mechanism with explicit-entry, prior-entry, and no-prior-entry cases.",
"score": 1,
"uncertainty_note": "Ordering and malformed or partial-entry behavior are not specified and are tracked as under-specification rather than additional primary mechanisms.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The change affects client configuration and does not define block RLP fields or block RLP validation."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No RLP validation mechanism requiring client syncing is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Rationale, lines 20-22 and 47-53",
"source": "eip.md",
"summary": "The configuration approach is expressly chosen to avoid passing the values through an Engine API handshake every block."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "The proposal adds neither an Engine API field nor a new Engine API communication mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-43",
"source": "eip.md",
"summary": "The entire specified addition is an execution-client configuration object."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-43",
"source": "eip.md",
"summary": "The proposal only changes how blob target/max values are represented and resolved in client configuration."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No existing system-contract code, state, or behavior is directly or indirectly modified by the specified mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The specification contains a configuration schema and no EVM instruction definition."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The specification contains no change to the result or behavior of an existing opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The configuration-only specification defines no callable precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "No precompile logic or gas schedule appears in the specified change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile behavior or gas accounting is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-40",
"source": "eip.md",
"summary": "The proposal adds a JSON-shaped client configuration object, not an encoding change to transactions, blocks, or protocol interfaces."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Adding configuration fields does not switch or modify transaction, block, or Engine API encoding under this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-43",
"source": "eip.md",
"summary": "The proposal is solely about a blob parameter schedule in client configuration files."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The text defines no transaction validity rule or intrinsic-gas calculation."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Per-block blob target/max configuration does not, as specified, add or modify transaction validity.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The only new fields are target and max nested in a client configuration object."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "The proposal adds no block or block-header field.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 29-43",
"source": "eip.md",
"summary": "The example gives different Cancun and Prague target/max values, and effective values are selected for the current fork with inheritance from the last configured fork."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The effective target and maximum are fork-indexed internal configuration values that can change when the current fork changes, matching the binary anchor for internal-variable modification at activation.",
"score": 3,
"uncertainty_note": "The text describes lookup by current fork rather than an explicit activation-block mutation, so an implementation could derive values on demand.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification and Rationale, lines 24-53",
"source": "eip.md",
"summary": "The new operation is configuration lookup, proposed in place of transmitting values over the Engine API every block."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The schedule lookup itself introduces no mechanism that requires performance validation under the anchor.",
"score": 0,
"uncertainty_note": "The proposal does not specify whether the illustrated higher blob limits are normative, so their broader performance effect is not attributed to this configuration EIP.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale and Security Considerations, lines 47-53 and 59-61",
"source": "eip.md",
"summary": "The only concrete consumer described is blobGasUsedRatio reporting in eth_feeHistory, and the proposal identifies no security considerations."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The specified configuration and fallback mechanism does not establish a new security-sensitive invariant or chain-security mechanism.",
"score": 0,
"uncertainty_note": "Other execution-client activities needing these values are mentioned but not enumerated, limiting certainty about the impact of inconsistent configuration.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 24-43",
"source": "eip.md",
"summary": "The schema gives example entries and two fallback outcomes but no types, ranges, malformed-entry handling, fork ordering rule, or statement that the displayed values are normative."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Clients need localized agreement on configuration parsing and schedule-resolution cases before common tests can be baselined, matching score 2 rather than a pervasive previously unobservable consensus behavior.",
"score": 2,
"uncertainty_note": "It is unclear which schema conventions are inherited from an existing client-configuration standard because none is identified in the package.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Rationale, lines 20-22 and 47-53",
"source": "eip.md",
"summary": "The schedule supports changing existing blob target/max values and supplies them to execution-layer activities including eth_feeHistory, while avoiding an Engine API handshake."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The proposal has limited interactions with existing blob-parameter behavior and an RPC consumer but remains independently testable as configuration resolution; the package supplies no interacting EIP number.",
"score": 1,
"uncertainty_note": "The interacting mechanisms are described by function rather than by EIP number, and consumers beyond the single example are unspecified.",
"under_specified": false,
"unidentified_interactions": [
"Existing blob target/maximum behavior and its execution-layer consumers, including eth_feeHistory; the package identifies no EIP number."
]
}
],
"eip": 7840,
"evaluation_date": "2026-08-25",
"fork": "prague",
"id": "prague:7840:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The specification presents a concrete schedule inside a shape example but does not say whether those numeric values are required.",
"The phrase \"last specified fork value\" does not define fork ordering or behavior for unrecognized keys.",
"The EIP says execution clients need the values for various activities but identifies only one concrete RPC consumer."
],
"provenance": {
"assessed_revision": {
"commit": "da129d42627c959498c3c17836e2814add9b647d",
"committed_at": "2025-01-15T16:24:59Z",
"content_sha256": "97223c1382fcf2bce0e280b5da30a477211499bde0c413946428bfc73d506486",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7840.md",
"git_blob_sha": "473e81a92a5bc1156718da1934580f974f69c22a",
"immutable_url": "https://github.com/ethereum/EIPs/blob/da129d42627c959498c3c17836e2814add9b647d/EIPS/eip-7840.md",
"information_cutoff_at": "2025-01-15T16:25:43Z",
"path": "EIPS/eip-7840.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-7840.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/prague/eip-7840.yaml",
"sha256": "4e2e5bec56c26ab89eee8b09af96f8e0ec2fde897fa19cf05bc4e4bca4dcf9a2"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 8,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this informational proposal extended execution-client configuration files with a blobSchedule object mapping forks to target and maximum blob counts. It defined inheritance from the most recently specified fork and a zero-value default when no prior entry exists, motivated by execution-layer consumers such as eth_feeHistory while avoiding a per-block Engine API handshake. It did not specify changes to block or transaction encoding, EVM operations, or contracts.",
"tier": "low",
"title": "Add blob schedule to EL config files",
"under_specification": {
"affected_criteria": [
"blob_gas_accounting_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"new_fork_activation_mechanism",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 10,
"minimum": 3
},
"present": true,
"summary": "The EIP defines the high-level schedule shape and two fallback outcomes but omits normative field types and ranges, malformed or partial-entry behavior, the ordering used to identify the last fork, whether its displayed values are normative, and the full set of consumers. These gaps are localized to configuration interpretation and do not justify projecting unspecified protocol mechanisms into other anchors.",
"unresolved_questions": [
"Are the Cancun and Prague target/max values normative or merely an example of the object shape?",
"What ordering determines the last specified fork, especially for unknown, duplicate, or out-of-order fork keys?",
"What field types and ranges are valid, and how are missing, partial, malformed, or negative entries handled?",
"Which execution-client activities beyond eth_feeHistory consume target and max, and which consequences must agree across clients?"
]
}
},
"shanghai:3651:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The initial accessed-address set is extended with the address returned by COINBASE."
},
{
"locator": "Specification - Storage read changes, lines 60-65",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 charges account-targeting operations differently according to whether the target is already in accessed_addresses."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "Adding COINBASE to the initially warm set updates the existing EIP-2929 warm/cold gas-accounting mechanism. It does not create a separate gas mechanism, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The change occurs when the transaction access set is initialized, not within execution of an opcode."
},
{
"locator": "Specification - Storage read changes, lines 60-71",
"source": "supporting/eip-2929.md",
"summary": "The inherited rule continues to charge gas and update the map at opcode execution time; EIP-3651 does not alter that ordering."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "Only the initial membership of accessed_addresses changes. No state access or gas charge is moved relative to an access inside any opcode, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 16-25",
"source": "eip.md",
"summary": "The proposal is limited to warming COINBASE through accessed-address initialization and specifies no blob-gas rule."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The sole normative change initializes an account address as warm; it does not charge for writing state."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal changes execution-gas treatment of an account access, not any state-writing gas cost, budget, reservoir, or spill rule. Score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The complete specification only adds COINBASE to accessed_addresses and defines no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No gas-refund mechanism is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Specification, lines 19-25",
"source": "eip.md",
"summary": "Access to COINBASE changes from initially cold to initially warm under the EIP-2929 access-list framework."
},
{
"locator": "Specification - Storage read changes, lines 60-65",
"source": "supporting/eip-2929.md",
"summary": "Existing tests of account-targeting operations distinguish cold cost from warm cost using accessed_addresses membership."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Pre-existing warm/cold gas tests whose target is the block coinbase require updated expected gas or out-of-gas outcomes. That is a narrow subset of the EIP-2929 test space, matching score 1.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The proposal changes an internal transaction-scoped set initialization but specifies no new test-visible output that unrelated tests must additionally assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Relevant gas expectations may change, but pre-existing tests are not required to gain an additional invariant or assertion. Score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The rule uses the address already returned by COINBASE and adds no input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The proposal requires no new transition-tool field or interface mechanism; it only changes how an existing execution-context value initializes an internal set. Score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 16-25",
"source": "eip.md",
"summary": "The feature combines an existing block-context address, transaction access set, and warm/cold gas behavior without specifying a new testing abstraction."
},
{
"locator": "Test Cases, lines 132-145",
"source": "supporting/eip-2929.md",
"summary": "The inherited warm/cold mechanism is testable through ordinary account-access opcodes, repetitions, reverts, and gas outcomes."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing execution and gas-expectation primitives suffice to target the coinbase address and observe the changed charge. No new expectation, modifier, or framework-level primitive is required, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The specified access-set initialization contains no cryptographic operation or primitive."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptography is introduced or modified, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Specification, lines 19-25",
"source": "eip.md",
"summary": "The proposal moves COINBASE from the initially cold case to the initially warm case."
},
{
"locator": "Parameters and Storage read changes, lines 38-65",
"source": "supporting/eip-2929.md",
"summary": "The inherited mechanism has distinct cold and warm charges of 2600 and 100 gas for account-targeting operations."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "A single boundary-prone mechanism changes: execution at gas thresholds between the cold and warm charges now succeeds for operations targeting COINBASE. This is one localized class of gas-boundary cases, matching score 1 rather than multiple independent mechanisms.",
"score": 1,
"uncertainty_note": "The EIP does not enumerate boundary tests; the score treats the warm/cold gas threshold as the single introduced boundary mechanism.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The complete normative change concerns transaction execution and defines no block RLP validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation or syncing mechanism changes, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The specification adds no field, endpoint, or communication mechanism and is confined to transaction access-set initialization."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or endpoint is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The proposal only changes initialization of accessed_addresses and introduces no contract."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 24-31",
"source": "eip.md",
"summary": "The proposal changes COINBASE address warmth because the recipient is already loaded; it specifies no direct or indirect change to system-contract code or state."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is modified or affected, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "COINBASE is referenced as an existing opcode whose returned address initializes the access set; no opcode is introduced."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No new opcode is added, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 16-25",
"source": "eip.md",
"summary": "The returned value and behavior of COINBASE are unchanged; only the initial warm status of that address changes."
},
{
"locator": "Specification - Storage read changes, lines 60-65",
"source": "supporting/eip-2929.md",
"summary": "The resulting differences for account-targeting opcodes are gas-cost differences under the existing warm/cold rule."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No opcode result or non-gas behavior is modified. The affected account operations only receive a different existing gas branch, which this anchor explicitly excludes, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The complete specification adds an address to a transaction-scoped set and introduces no precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The rule names only the COINBASE-returned address and changes no precompile logic or gas schedule."
},
{
"locator": "Specification - transaction initialization, lines 51-55",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 already initializes all precompile addresses as warm; EIP-3651 leaves that rule intact."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile behavior or gas schedule is modified, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The normative change is internal execution initialization and specifies no transaction, block, or interface encoding."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, or other interface-level encoding changes are introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The rule applies at the start of transaction execution without defining a new transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The proposal changes execution-time accessed-address initialization and states no validity or intrinsic-gas rule."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity and intrinsic gas calculation are unchanged. Different execution gas outcomes do not trigger this validity-specific anchor, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 24-31",
"source": "eip.md",
"summary": "The proposal consumes the existing COINBASE address during transaction initialization and introduces no block or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or header field is introduced, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The specified initialization occurs at the start of transaction execution, not as a state or internal-variable modification on the fork-activation block."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "The fork applies an ordinary per-transaction rule and requires no special activation-block transition. Score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Abstract and Rationale, lines 16-17 and 27-31",
"source": "eip.md",
"summary": "The proposal aligns warm treatment with the stated actual read cost and explains that COINBASE is already loaded to receive rewards and fees."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Adding one already-available address to an existing initialization set introduces no new workload and, on the proposal's stated rationale, does not underprice an additional account load. No distinct performance validation mechanism is indicated, so score 0 applies.",
"score": 0,
"uncertainty_note": "The package provides rationale rather than benchmark data, but it specifies no new processing path whose performance must be validated.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The consensus gas outcome is changed through one localized addition to accessed_addresses initialization."
},
{
"locator": "Security Considerations, lines 36-37",
"source": "eip.md",
"summary": "The proposal reports no known security considerations."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Incorrectly applying the new initial membership would produce divergent gas and out-of-gas outcomes, but the rule is self-contained and can be validated in isolation without changing a broader security invariant. This matches the localized score-1 anchor.",
"score": 1,
"uncertainty_note": "The EIP states that no security considerations are known; the nonzero score reflects only the implementation-sensitive consensus gas rule, not an identified exploit class.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The proposal explicitly identifies the initialization time, the accessed_addresses set, and the value to add as the address returned by COINBASE."
},
{
"locator": "Specification - transaction initialization and Storage read changes, lines 47-65",
"source": "supporting/eip-2929.md",
"summary": "The required EIP defines the transaction scope, initialization semantics, membership check, charge, and update behavior of accessed_addresses."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Read together with its explicit dependency, the EIP determines the warm/cold result for constructible cases without requiring a new cross-client choice. Score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Motivation, lines 1-10 and 19-22",
"source": "eip.md",
"summary": "EIP-3651 explicitly requires EIP-2929 and identifies its access-list framework as the source of COINBASE's initially cold status."
},
{
"locator": "Specification, lines 24-25",
"source": "eip.md",
"summary": "The proposal directly modifies the initialization of accessed_addresses defined by EIP-2929."
},
{
"locator": "Specification - transaction initialization and Storage read changes, lines 47-65",
"source": "supporting/eip-2929.md",
"summary": "EIP-2929 defines the set being modified and uses its membership to select gas charges for several account-targeting opcode families."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2929
],
"rationale": "EIP-3651 directly depends on and modifies EIP-2929's transaction-scoped access-set mechanism. Coordinated regression testing of that mechanism and its account-access gas branches is required, but the interaction is limited to one set-initialization rule, matching score 2.",
"score": 2,
"uncertainty_note": "None identified.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 3651,
"evaluation_date": "2026-08-25",
"fork": "shanghai",
"id": "shanghai:3651:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [],
"provenance": {
"assessed_revision": {
"commit": "a6dfa1ed7bc16ed04252245af575997029a22295",
"committed_at": "2022-01-30T01:15:44Z",
"content_sha256": "1795497b5d0c25515b9781aebaaaeb83275e31385c6ea1625f2902e923f0ab03",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3651.md",
"git_blob_sha": "9b18c45611034e618c8c830db01470c3ea0530cc",
"immutable_url": "https://github.com/ethereum/EIPs/blob/a6dfa1ed7bc16ed04252245af575997029a22295/EIPS/eip-3651.md",
"information_cutoff_at": "2022-03-04",
"path": "EIPS/eip-3651.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-3651.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/shanghai/eip-3651.yaml",
"sha256": "d811e6872aa90498aadeb2b079fccdb0d3a6836acb1b81a3c72c0663d63c443b"
},
"supporting_documents": [
"supporting/eip-2929.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 6,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "EIP-3651 changes the EIP-2929 transaction access-set initialization so that the address returned by COINBASE starts warm. This changes the gas charged by the existing warm/cold account-access rules when an operation targets that address, while introducing no new opcode, transaction type, field, or persistent state transition.",
"tier": "low",
"title": "Warm COINBASE",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 6,
"minimum": 6
},
"present": false,
"summary": "No material under-specification is present. EIP-3651 identifies the exact EIP-2929 set to change, when to initialize it, and the address to add; the required EIP supplies the inherited warm/cold behavior.",
"unresolved_questions": []
}
},
"shanghai:3855:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale/Gas cost, lines 34-42",
"source": "eip.md",
"summary": "PUSH0 is assigned a constant cost of 2 gas, explicitly identified with the existing verylow cost class."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The gas schedule gains one opcode entry, but it reuses the existing constant-cost verylow mechanism; this is an update to existing gas accounting rather than a new mechanism.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The new instruction only performs a stack push and specifies no state access."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "PUSH0 neither accesses state nor changes gas charging relative to a state access, so no opcode state-access ordering changes.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The proposal specifies only an EVM opcode's execution-gas cost and contains no blob-gas mechanism."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "PUSH0 changes only the EVM stack and has no state write or state-gas charge."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The proposal has no state-gas cost, charging site, budget, reservoir, or spill-path change.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The instruction has a fixed 2-gas charge and the specification defines no refund behavior."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility and Test Cases, lines 48-56",
"source": "eip.md",
"summary": "Byte 0x5f becomes an executable opcode, changing behavior for existing code containing it; the proposal supplies success and stack-overflow cases for the new behavior."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "A minor, localized subset of pre-existing invalid-opcode or bytecode-execution cases involving 0x5f must be updated across the activation boundary.",
"score": 1,
"uncertainty_note": "The package does not enumerate the pre-existing test corpus, so the affected subset is inferred from the specified change in 0x5f behavior.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Test Cases, lines 34-36 and 52-56",
"source": "eip.md",
"summary": "The specified outputs and stack-limit checks apply to tests of PUSH0 itself, not as an additional assertion on unrelated tests."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing tests unrelated to PUSH0 gain no new invariant to assert.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "Activation and behavior are expressed entirely as an opcode rule, with no new transition-tool input or output field."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "The change requires no transition-tool interface modification or new field.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 52-56",
"source": "eip.md",
"summary": "The proposed cases are ordinary raw-bytecode execution and stack-result or abort checks."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing execution, stack, and exceptional-halt test primitives suffice; no new framework abstraction is required.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "PUSH0 places a fixed zero value on the stack and performs no cryptographic operation."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 52-56",
"source": "eip.md",
"summary": "The test cases explicitly distinguish 1024 successful pushes from a 1025th push that aborts for stack overflow."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The new opcode exposes one clear boundary-prone mechanism at the EVM stack-depth limit.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The proposal changes EVM instruction execution only and specifies no block RLP field or validation rule."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism requiring syncing tests is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The complete specified change is an EVM opcode and includes no Engine API field, endpoint, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API change is required.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 34-36",
"source": "eip.md",
"summary": "The proposal introduces an instruction, not a contract or reserved-address mechanism."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "PUSH0's specified behavior is confined to a stack operation and does not identify or alter any system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract is directly or indirectly modified by the specified mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "One opcode at 0x5f is added; it has no immediate data, pops nothing, pushes one constant value, and has constant gas cost."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "This exactly matches one new simple opcode with no data portion, simple stack mechanics, and constant gas.",
"score": 1,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 48-50",
"source": "eip.md",
"summary": "The document characterizes 0x5f as a new opcode that did not previously exist, rather than a modification of an existing opcode."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No pre-existing opcode's behavior is modified or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract and Specification, lines 13-15 and 34-36",
"source": "eip.md",
"summary": "The proposal adds an EVM instruction at an opcode byte and does not define a precompile."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The specified opcode has no connection to precompile logic or precompile gas accounting."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The proposal assigns an EVM bytecode opcode but makes no transaction, block, RLP, SSZ, or interface encoding change."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "Opcode-byte assignment is outside this anchor's transaction, block, and interface encoding scope.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Metadata and Specification, lines 7-10 and 34-36",
"source": "eip.md",
"summary": "This Core proposal defines an EVM opcode and contains no transaction envelope or transaction type."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "The only validity-like condition is opcode availability after the fork; no transaction validity or intrinsic-gas rule is specified."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Existing transaction validity mechanisms and intrinsic gas calculation are unchanged.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "Fork activation gates an opcode behavior and introduces no block-body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No new block or block-header field is introduced.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 34-36",
"source": "eip.md",
"summary": "PUSH0 becomes available at the ordinary HF boundary, with no state transition or existing internal-variable modification specified at activation."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Standard fork gating of a new opcode is not a new activation mechanism and requires no activation-block state or internal-variable modification.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification and Rationale, lines 34-46",
"source": "eip.md",
"summary": "PUSH0 is a constant stack operation with no immediate data and may share the contiguous PUSH implementation."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The proposal introduces no mechanism whose performance needs validation beyond the isolated constant-time opcode behavior.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Backwards Compatibility and Security Considerations, lines 48-60",
"source": "eip.md",
"summary": "Existing code containing 0x5f can change behavior, but the opcode is self-contained and its lack of immediate bytes leaves jump-destination analysis unaffected."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "The consensus behavior change has a limited implementation and compatibility risk, but it is self-contained, isolatable, and does not introduce complex security interactions.",
"score": 1,
"uncertainty_note": "The document reports no known security impact; the nonzero score reflects the explicit deployed-code behavior change if the opcode is implemented or activated incorrectly.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, Test Cases, and Security Considerations, lines 34-36, 52-60",
"source": "eip.md",
"summary": "The opcode byte, activation condition, immediate-data length, stack inputs and output, gas cost, overflow outcome, and jump-destination treatment are specified."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The historical text determines the constructible PUSH0 behaviors using ordinary EVM execution rules; no localized detail requires new cross-client agreement.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 25-32",
"source": "eip.md",
"summary": "PUSH0 is intended to reduce reliance on context-sensitive zero-producing opcodes, and the proposal identifies EIP-2733's possible RETURNDATASIZE behavior change as an example."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
2733
],
"rationale": "The relationship to EIP-2733 is explicit but limited and non-critical; PUSH0 can be specified and tested independently.",
"score": 1,
"uncertainty_note": "EIP-2733 is cited as motivation rather than as a dependency, so the interaction does not warrant coordinated-mechanism complexity above score 1.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 3855,
"evaluation_date": "2026-08-25",
"fork": "shanghai",
"id": "shanghai:3855:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The proposal cites EIP-2733 as motivation rather than as a dependency; this assessment records the explicit relationship as a limited, non-critical cross-EIP interaction."
],
"provenance": {
"assessed_revision": {
"commit": "6caab461df3025fde8437603dec64a7dffd36809",
"committed_at": "2021-09-22T22:15:14Z",
"content_sha256": "f89cc30713d2dbd961e673d20632d48b051b3444f495bbc01ef4f84e1ca4137c",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3855.md",
"git_blob_sha": "e86efc6e1316f530735b04a86e30cec96b3de73f",
"immutable_url": "https://github.com/ethereum/EIPs/blob/6caab461df3025fde8437603dec64a7dffd36809/EIPS/eip-3855.md",
"information_cutoff_at": "2022-02-04",
"path": "EIPS/eip-3855.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-3855.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/shanghai/eip-3855.yaml",
"sha256": "8ff8b9cbf29951ed976c5a8f6b97c9470f7ea1845ea588f8c786132006ad3c76"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 6,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the recorded cutoff, EIP-3855 proposed activating a single new EVM opcode, PUSH0 (0x5f), at the fork boundary. The opcode has no immediate data, pops no stack items, pushes the value zero, and costs 2 gas under the existing verylow cost class. The proposal aimed to reduce bytecode size and reliance on context-sensitive zero-producing instructions, while noting that deployed code containing the formerly unavailable opcode could change behavior.",
"tier": "low",
"title": "PUSH0 instruction",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 6,
"minimum": 6
},
"present": false,
"summary": "No material under-specification is present in the historical proposal for the simple opcode behavior.",
"unresolved_questions": []
}
},
"shanghai:3860:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Parameters and Rules, lines 42-58",
"source": "eip.md",
"summary": "The proposal defines a new per-word initcode cost, adds it to creation- transaction intrinsic gas, and charges it to CREATE and CREATE2 before address calculation and initcode execution."
},
{
"locator": "Specification, lines 11-15",
"source": "supporting/eip-1014.md",
"summary": "CREATE2 already has a per-word hashcost deducted with its existing creation charges, so the proposed initcode charge changes an established dynamic-gas path."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "This is a new gas-accounting mechanism applied through existing transaction intrinsic-gas and opcode-gas mechanisms, including the pre-existing CREATE2 hashcost path. It therefore affects existing mechanisms and their tests, matching score 3.",
"score": 3,
"uncertainty_note": "The exact charge ordering for an over-limit CREATE or CREATE2 is not fully explicit, but that does not change the anchor level.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "Both CREATE and CREATE2 receive a new charge that must be deducted before calculation of the resulting contract address and before execution of the initcode."
},
{
"locator": "Specification, lines 13-15",
"source": "supporting/eip-1014.md",
"summary": "CREATE2's existing hashcost is deducted before evaluation of its resulting address and initcode, identifying the existing execution point with which the new charge is combined."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "The new up-front charge changes the gas-boundary path before address-derived state work for two state-affecting opcodes. This is a multiple-opcode ordering consequence, but it does not redefine recordable access or a broad opcode class, matching score 2.",
"score": 2,
"uncertainty_note": "The proposal fixes the new charge relative to address calculation and initcode execution, but does not completely order the oversize check, memory expansion, base creation charge, and CREATE2 hashcost against one another.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-20; Specification, lines 40-58",
"source": "eip.md",
"summary": "The only gas introduced is an initcode word charge for contract-creation transactions and CREATE-family opcodes; no blob resource or blob-gas rule appears in the proposal."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas accounting is introduced or modified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "The proposal changes execution and intrinsic gas for initcode length; it defines no separate cost for bytes written to state, state-gas budget, or spill mechanism."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "The new charge is EVM execution gas, not state gas, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Parameters and Rules, lines 42-58",
"source": "eip.md",
"summary": "The rules only add an initcode charge and size limit and contain no refund or mechanism for returning gas."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No EVM gas-refund mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "Existing creation transactions gain both a validity limit and higher intrinsic gas, while existing CREATE and CREATE2 executions gain a size failure and an additional dynamic charge."
},
{
"locator": "Test Cases, lines 111-118",
"source": "eip.md",
"summary": "The requested cases span creation transactions and both creation opcodes at gas and maximum-size boundaries."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "Existing tests across the focused contract-creation category must be reworked for changed gas and failure outcomes. The affected category is considerable but bounded rather than a diverse major share of all tests, matching score 2.",
"score": 2,
"uncertainty_note": "The package does not enumerate the pre-existing test corpus, so the precise proportion of tests requiring updates is uncertain.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 111-118",
"source": "eip.md",
"summary": "The proposal calls for targeted tests of gas sufficiency and initcode-size boundaries, not an additional output or property for unrelated tests to assert."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Existing creation tests may need changed expectations, which is scored in the preceding criterion, but unrelated pre-existing tests gain no new invariant; score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-58",
"source": "eip.md",
"summary": "All parameters and rules are derived from transaction data, opcode inputs, and fixed constants; the proposal specifies no transition-tool field or external input."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool interface change is required, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Test Cases, lines 111-118",
"source": "eip.md",
"summary": "The proposed cases use ordinary creation transactions, CREATE and CREATE2, selectable gas limits, and byte-length boundaries."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "These cases can be expressed using ordinary transaction, opcode, gas, and byte-array test capabilities; no new framework abstraction is indicated, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale — Gas cost per word, lines 73-77",
"source": "eip.md",
"summary": "The new cost is made compatible with CREATE2's existing hashcost by adding 2 to that established per-word charge; no hash function or cryptographic result is changed."
},
{
"locator": "Specification, lines 11-21",
"source": "supporting/eip-1014.md",
"summary": "EIP-1014 supplies the existing CREATE2 address-hashing mechanism and its hashcost, which EIP-3860 leaves intact."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Reusing an existing hashing-cost shape does not introduce or modify a cryptographic mechanism, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Parameters and Rules, lines 42-58",
"source": "eip.md",
"summary": "The charge rounds initcode length up by 32-byte words, the size cap is a strict greater-than check, intrinsic gas can make a transaction invalid, and opcode oversize failure has a different zero-result outcome."
},
{
"locator": "Test Cases, lines 111-118",
"source": "eip.md",
"summary": "The proposed matrix explicitly crosses sufficient and insufficient gas with exact-limit and limit-plus-one lengths over a creation transaction, CREATE, and CREATE2."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple independent boundaries—word rounding, maximum size, gas sufficiency, and transaction-versus-opcode failure—combine across three creation paths. The resulting cross-product requires an elevated case count, matching score 3.",
"score": 3,
"uncertainty_note": "Gas consumption for the over-limit opcode path is not completely ordered, so some expected outcomes cannot be fixed from the text alone.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "A creation transaction can become invalid because of initcode length or intrinsic gas, but the proposal introduces no block or transaction RLP validation format."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Consensus transaction validity changes do not by themselves constitute the new block-RLP validation mechanism required by this anchor, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-58",
"source": "eip.md",
"summary": "The complete rule set concerns EVM contract creation and transaction intrinsic gas and specifies no engine endpoint, field, or communication mechanism."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field or endpoint is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 14-20; Specification, lines 40-58",
"source": "eip.md",
"summary": "The proposal consists of an initcode cap and gas rules and deploys no protocol-owned contract or contract code."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is added, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "The rules directly modify generic contract-creation transactions and EVM opcodes, without identifying or altering any pre-existing system contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No system contract code, state, or behavior is modified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "The proposal applies new rules to the already named CREATE and CREATE2 instructions and assigns no new opcode value."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "CREATE and CREATE2 newly push zero when their initcode length exceeds the maximum, in addition to receiving a gas change."
},
{
"locator": "Rationale — How to report initcode limit violation?, lines 93-95",
"source": "eip.md",
"summary": "The zero-result behavior was deliberately chosen as a creation-instruction error outcome instead of exceptional abort."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "At least two pre-existing opcodes gain a non-gas behavioral failure condition. The rubric's binary modified-opcode anchor therefore requires score 3.",
"score": 3,
"uncertainty_note": "The gas consumed before the new zero result is not fully ordered, but the behavioral modification itself is explicit.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-58",
"source": "eip.md",
"summary": "The proposal defines fixed constants and rules for transactions, CREATE, and CREATE2 and introduces no callable precompile address or function."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is added, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-58",
"source": "eip.md",
"summary": "All specified changes concern initcode processing by transactions and creation opcodes; no precompile logic or gas schedule is mentioned."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No existing precompile is modified, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "Existing transaction data is reinterpreted for size and intrinsic gas, but its encoding and all block and interface encodings remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No RLP, SSZ, transaction, block, or interface encoding changes, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "The proposal changes rules for an existing create transaction and does not define a new typed transaction envelope or transaction category."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No new transaction type is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification — Rules, lines 53-56",
"source": "eip.md",
"summary": "A creation transaction is newly invalid above the initcode-size cap, and its intrinsic gas formula newly includes the rounded initcode charge so insufficient gas also makes it invalid."
},
{
"locator": "Test Cases, lines 111-118",
"source": "eip.md",
"summary": "The requested transaction cases exercise both intrinsic-gas sufficiency and exact size-limit validity boundaries."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Two existing creation-transaction validity calculations change and existing cases need updated boundary expectations, but the changes are localized and require no test-infrastructure redesign. This matches score 2.",
"score": 2,
"uncertainty_note": "The backwards-compatibility wording about some over-limit transactions being includable is not explicit about whether it means call transactions that invoke a creation opcode rather than creation transactions themselves.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 40-58",
"source": "eip.md",
"summary": "The proposal's constants and rules use existing transaction and opcode data and define no new block-body or header field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or block-header field is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 97-101",
"source": "eip.md",
"summary": "The proposal requires a network upgrade because consensus rules change, but it specifies no activation-block state mutation, migration, or modification of an internal variable."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Ordinary activation of new rules is not the activation-block mutation required by this anchor, so score 0 applies.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 22-38",
"source": "eip.md",
"summary": "Jump-destination analysis scales linearly with initcode length, was unmetered and unbounded, and could be amplified through programmatically generated initcode in CREATE and CREATE2."
},
{
"locator": "Rationale — Gas cost constant and size limit, lines 62-83",
"source": "eip.md",
"summary": "The gas constant is selected from differing implementation worst-case benchmarks, while the size bound is intended to make worst-case estimation tractable."
},
{
"locator": "Security Considerations, lines 103-109",
"source": "eip.md",
"summary": "The proposal estimates a block-level workload of roughly 1.3 GB of analyzed initcode under the then-current gas limit and a substantial added gas cost after the change."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "Performance validation must cover implementation-specific analysis costs and end-to-end repeated creation workloads, so it is not fully captured by a single isolated arithmetic benchmark. The impact remains confined to contract creation rather than broad execution, matching score 2.",
"score": 2,
"uncertainty_note": "The package reports benchmark results but does not define a normative performance-validation matrix across implementations and workload shapes.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 22-38",
"source": "eip.md",
"summary": "The proposal responds to an unmetered, unbounded linear analysis cost and notes that cheap generated initcode had enabled malicious constructions."
},
{
"locator": "Security Considerations, lines 103-109",
"source": "eip.md",
"summary": "The change is expected to harden clients against analysis attacks, but it creates previously absent failure modes for layer-2 factory patterns and multi-level deployment hierarchies."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "Correctness affects a limited set of critical creation paths and changes both resource-exhaustion assumptions and failure behavior for dependent factory designs. This calls for targeted security review and fuzzing, matching score 2 rather than a broad multi-component score 3.",
"score": 2,
"uncertainty_note": "The historical text states that the authors did not know whether affected multi-level factory contracts existed, so the practical exposure was uncertain at the cutoff.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification — Rules, lines 53-58",
"source": "eip.md",
"summary": "The rules separately state that oversized CREATE or CREATE2 returns zero and that the new charge is deducted before address calculation and execution, without ordering those two rules against all pre-existing charges."
},
{
"locator": "Rationale — How to report initcode limit violation?, lines 93-95",
"source": "eip.md",
"summary": "The rationale fixes zero as the failure result and distinguishes it from exceptional-abort conditions, but does not specify the gas already consumed on that path."
},
{
"locator": "Specification, lines 13-15",
"source": "supporting/eip-1014.md",
"summary": "The prior CREATE2 rule orders hashcost with memory expansion and base creation gas, exposing an unresolved interaction with the new oversize check and initcode charge."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "A test can observe whether an oversized opcode call first pays the new per-word cost and the pre-existing memory, base, and CREATE2 hash costs, or instead returns zero after an earlier size check. Agreement is needed, but the gap is localized to creation-opcode failure ordering, matching score 2.",
"score": 2,
"uncertainty_note": "The numbered order and normal gas-check conventions may suggest an intended reading, but the historical text does not make that reading normative.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Front matter and Abstract, lines 1-20; Specification, lines 42-51",
"source": "eip.md",
"summary": "EIP-3860 formally requires and extends EIP-170, deriving its maximum initcode size from EIP-170's maximum deployed-code size."
},
{
"locator": "Parameters and Specification, lines 14-25",
"source": "supporting/eip-170.md",
"summary": "EIP-170 defines MAX_CODE_SIZE and the existing over-limit deployed-code failure that supplies the proposal's base constant and related creation boundary."
},
{
"locator": "Rationale — Gas cost per word, lines 73-77",
"source": "eip.md",
"summary": "The new cost is explicitly combined with EIP-1014's CREATE2 hashcost, changing CREATE2's post-activation per-word total from 6 to 8."
},
{
"locator": "Specification, lines 11-15",
"source": "supporting/eip-1014.md",
"summary": "EIP-1014 defines CREATE2 and the existing per-word hashcost and deduction point with which the new mechanism must coordinate."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
170,
1014
],
"rationale": "The proposal depends directly on EIP-170's limit and modifies the gas path established by EIP-1014 for CREATE2. Coordinated boundary and gas-order tests are required for these two limited interactions, matching score 2.",
"score": 2,
"uncertainty_note": "EIP-3670 is mentioned only as a possible future beneficiary of an extendable cost system, not as a dependency or modified mechanism, so it is not counted.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 3860,
"evaluation_date": "2026-08-25",
"fork": "shanghai",
"id": "shanghai:3860:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The opcode oversize-result rule and the opcode gas-charge rule do not specify a complete failure-path ordering.",
"The backwards-compatibility phrase about over-limit transactions remaining includable is ambiguous unless read as referring to call transactions that execute CREATE or CREATE2."
],
"provenance": {
"assessed_revision": {
"commit": "d38a4add0cfd890f5b44a9491a29399cd1e4a52d",
"committed_at": "2022-02-03T17:32:59Z",
"content_sha256": "4dd3935265d7d837c3bb86bb69df6e3e0853f491c3b2a9d58d57d65314bc9d6f",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-3860.md",
"git_blob_sha": "7acc1955a89afd39d24ae4a90b519fce22bb67e2",
"immutable_url": "https://github.com/ethereum/EIPs/blob/d38a4add0cfd890f5b44a9491a29399cd1e4a52d/EIPS/eip-3860.md",
"information_cutoff_at": "2022-02-04",
"path": "EIPS/eip-3860.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-3860.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/shanghai/eip-3860.yaml",
"sha256": "020762521910d1ce54f14ac69d1a135e10f99b59273cc7fbb158f6c552d10ee4"
},
"supporting_documents": [
"supporting/eip-170.md",
"supporting/eip-1014.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 23,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-3860 extended EIP-170 with a 49,152-byte maximum for initcode supplied by creation transactions, CREATE, and CREATE2. It also charged 2 gas per 32-byte initcode word through transaction intrinsic gas and through an extra opcode charge taken before address calculation and initcode execution. Oversized creation transactions became invalid, while an oversized CREATE or CREATE2 returned zero; the stated purpose was to meter linear jump-destination analysis and bound its resource exposure.",
"tier": "high",
"title": "Limit and meter initcode",
"under_specification": {
"affected_criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"edge_boundary_conditions",
"new_or_modified_transaction_validity_mechanisms",
"unspecified_behavior_requiring_cross_client_consensus"
],
"plausible_tiers": [
"medium",
"high"
],
"plausible_total_range": {
"maximum": 23,
"minimum": 21
},
"present": true,
"summary": "The proposal does not fully order an oversized CREATE or CREATE2 size check against the new initcode charge and the pre-existing memory-expansion, base creation, and CREATE2 hash charges. It also leaves the backwards-compatibility reference to includable over-limit transactions insufficiently explicit about whether those are call transactions that reach an opcode rather than creation transactions prohibited by the new validity rule.",
"unresolved_questions": [
"On an over-limit CREATE or CREATE2, which of the new initcode charge, memory-expansion gas, base creation gas, and CREATE2 hashcost is deducted before zero is pushed?",
"Does the backwards-compatibility statement about includable over-limit transactions refer only to non-creation transactions whose execution invokes CREATE or CREATE2?"
]
}
},
"shanghai:4895:llm:r2": {
"confidence": "medium",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "Withdrawals perform unconditional balance increases after transactions and explicitly have no associated gas costs."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "The proposal neither adjusts an existing EVM gas rule nor introduces a new gas-accounting mechanism; declaring the out-of-EVM operation gas-free is not itself a new EVM gas rule under this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "Balance writes occur as block-level withdrawal processing after user transactions, not within opcode execution."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No opcode is added or changed, and no state access or gas charge is reordered inside an opcode. The separately specified block-level processing order is outside the scope of this narrowly defined anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 30-97",
"source": "eip.md",
"summary": "The complete mechanism concerns withdrawal encoding, block commitment, validation, and balance updates, with no blob-gas mechanism."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "No blob gas rule or accounting mechanism is introduced or modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "The proposal directly increases balances and states that the operation has no associated gas costs."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "Although the operation writes account state, it introduces no state-gas cost, state-gas charging site, budget, reservoir, or spill rule covered by this anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State transition, lines 89-95",
"source": "eip.md",
"summary": "The only specified value transfer is a gas-free unconditional balance increase; no refund behavior is defined."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "The proposal introduces no EVM gas-refund mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / New field and commitment, lines 50-84",
"source": "eip.md",
"summary": "Every post-fork block gains a withdrawals body field and header commitment, and block validity gains a root-equality check."
},
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "Block execution gains a post-transaction phase that can change account balances without gas or failure."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "The block-body and header schemas, block-validity path, and state-transition path all change. Consequently a major and diverse set of existing post-fork block tests and fixtures must be reworked to construct and validate the new fields, including tests whose main subject is unrelated to withdrawals.",
"score": 3,
"uncertainty_note": "The draft does not say how an empty withdrawal list is represented, so the exact amount of mechanical reworking cannot be fixed from the text alone.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Commitment and block validity, lines 65-85",
"source": "eip.md",
"summary": "Each post-fork header must commit to its withdrawals list, and clients must assert that the header root equals the root computed from the body list."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Every post-fork block test gains a withdrawals-root consistency invariant regardless of what the test otherwise exercises. Fork-sensitive fixtures also have to distinguish the new post-fork header/body shape from the pre-fork shape, matching the broadest anchor.",
"score": 3,
"uncertainty_note": "Empty-list and field-presence semantics are not stated, and the unresolved receipts commitment could add another universal invariant.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / System-level operation and new field, lines 40-54",
"source": "eip.md",
"summary": "A new list of structured withdrawals, whose values are supplied by the consensus layer, becomes block input to execution processing."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "A transition tool needs at least one new structured block input for the withdrawals list. On the text available, that is best supported as a single new field rather than a fully specified new interface mechanism.",
"score": 1,
"uncertainty_note": "The draft gives no transition-tool or consensus/execution interface schema; separate inputs or outputs for the commitment or any future receipts could raise the score.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation and Specification, lines 24-28 and 38-76",
"source": "eip.md",
"summary": "The EIP deliberately creates a new system-level object domain plus block-list and trie-commitment structures separate from transactions."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Tests need reusable withdrawal-object construction and expectations for its body list, commitment, and unconditional state effect. Those are new primitives reusable across this EIP's suite, while the package does not establish adoption by other EIPs' tests.",
"score": 2,
"uncertainty_note": "No test design is included, and existing generic block-field and trie helpers might reduce the required extension to a minor one.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Commitment to withdrawals, lines 65-76",
"source": "eip.md",
"summary": "The commitment reuses the existing transactions-root construction with an indexed Merkle-Patricia trie."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "Reusing an existing commitment construction introduces no new or modified cryptographic mechanism.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / System-level operation, lines 40-48",
"source": "eip.md",
"summary": "Withdrawal fields have distinct uint64, 20-byte, and 256-bit domains, with a monotonically increasing index and RLP serialization."
},
{
"locator": "Specification / Commitment, validity, and transition, lines 65-95",
"source": "eip.md",
"summary": "The proposal adds indexed-trie commitment validation, a strict after-transactions processing boundary, and unconditional balance updates."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "Multiple boundary-prone mechanisms combine: typed RLP values and list sizes, index progression and trie position, commitment mismatch, fork and processing order, and balance updates at account/value extremes. Their combinations require an elevated case matrix rather than a few isolated edge tests.",
"score": 3,
"uncertainty_note": "Empty lists, duplicate or discontinuous indices, balance overflow, recipient account creation, and the exact consensus-layer list bound are not resolved in the draft.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Encoding and block validity, lines 48-85",
"source": "eip.md",
"summary": "Blocks gain an RLP list of RLP withdrawal objects, a header root, and validation that recomputes an indexed-trie commitment."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "Syncing clients must parse and validate multiple new block RLP structures and their commitment. These are multiple validation changes, but the trie-root construction intentionally reuses the existing transactions-root pattern, so the package does not establish a complex novel validation mechanism.",
"score": 2,
"uncertainty_note": "The unresolved possibility of receipts and another commitment could expand the syncing changes.",
"under_specified": true
},
{
"confidence": "low",
"evidence": [
{
"locator": "Specification / System-level operation, lines 40-46",
"source": "eip.md",
"summary": "The execution block receives a new withdrawals list whose three values are explicitly supplied from the consensus layer."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "Supplying one new structured withdrawals list from consensus to execution implies at least one new payload/interface field. The text supports that limited consequence, but it neither names Engine API directives nor specifies multiple fields or a new endpoint.",
"score": 1,
"uncertainty_note": "The cross-layer transport is wholly unspecified; the eventual interface could require multiple fields or a new mechanism, and that cannot be inferred from later designs.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Rationale, lines 24-28 and 101-105",
"source": "eip.md",
"summary": "The proposal chooses a new block-level operation rather than the cited user-space contract alternative or generic EVM execution."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "Calling the operation system-level does not introduce a system contract; no contract code, address, or state is specified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "Withdrawals directly update recipient account balances and do not invoke or alter a contract."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "No pre-existing system contract code, state, or behavior is modified directly or indirectly.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Rationale / Why not a new transaction type, lines 101-105",
"source": "eip.md",
"summary": "The new object is deliberately processed outside generic EVM execution."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "The proposal defines no new EVM opcode.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "The only execution change is a block-level post-transaction balance update with no EVM execution specified."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "No existing opcode's result or behavior is changed or deprecated.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / System-level operation and transition, lines 38-48 and 87-95",
"source": "eip.md",
"summary": "The feature is a block-level object and direct state transition; no callable precompile is defined."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "The proposal introduces no precompile.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "Withdrawal processing is specified as a direct balance update, with no reference to precompile logic or gas accounting."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No pre-existing precompile logic or gas schedule is modified.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Withdrawal and block encoding, lines 40-62",
"source": "eip.md",
"summary": "A withdrawal has a new RLP schema, and the execution block gains a new field encoded as an RLP list of those objects."
},
{
"locator": "Specification / Commitment, lines 65-76",
"source": "eip.md",
"summary": "The execution header gains a new field containing the trie-root commitment to the newly encoded block data."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "The proposal changes block-body and header encoding by adding new RLP objects and fields. Any transaction-, block-, or interface-level encoding change maps directly to score 3 under this binary anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation and Rationale, lines 26-28 and 101-105",
"source": "eip.md",
"summary": "The EIP explicitly separates withdrawals from user transactions as a new system-level operation object."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "The proposal intentionally does not introduce a transaction type.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / System-level operation and state transition, lines 40-48 and 87-95",
"source": "eip.md",
"summary": "Withdrawals occupy a separate domain from transactions and are processed only after user transactions have already been applied."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Block validation gains a withdrawal-root rule, but no existing transaction type's validity rules or intrinsic gas calculation changes. That block-level rule is scored in the block and invariant anchors instead.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / New field and commitment, lines 50-76",
"source": "eip.md",
"summary": "The execution block gains a withdrawals field and the execution header gains a withdrawals-root field."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "A new block field and a new header field directly trigger score 3 under this binary anchor.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification / Constants and activation, lines 32-36",
"source": "eip.md",
"summary": "The extensions begin at a still-TBD timestamp, with no activation-block-only state or internal-variable mutation specified."
},
{
"locator": "Specification / State transition, lines 87-95",
"source": "eip.md",
"summary": "Balance updates are ordinary per-block withdrawal processing after activation rather than a one-time fork transition."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "Timestamp gating alone is not a new activation mechanism under this anchor, and the proposal specifies no irregular state or internal-variable modification at the activation block.",
"score": 0,
"uncertainty_note": "The activation timestamp value is TBD, but that does not change the mechanism score.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Rationale / Why no gas costs, lines 107-110",
"source": "eip.md",
"summary": "The consensus layer is said to enforce a small bound on withdrawal count, making execution-layer operational costs negligible in the broader block."
},
{
"locator": "Specification / Commitment and transition, lines 65-95",
"source": "eip.md",
"summary": "The work consists of computing a list trie root and applying one balance update per withdrawal."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "The new root computation and bounded sequence of balance writes merit performance validation, but both can be benchmarked in isolation and the text asserts a small consensus-enforced bound. This fits the localized score-1 anchor.",
"score": 1,
"uncertainty_note": "The actual maximum withdrawal count and its enforcement rule are not specified.",
"under_specified": true
},
{
"confidence": "high",
"evidence": [
{
"locator": "Security Considerations, lines 122-125",
"source": "eip.md",
"summary": "Correct consensus-layer validation is critical to ETH withdrawal soundness, and the cross-layer ETH transfer has no current EVM analog and demands very high scrutiny."
},
{
"locator": "Specification / Commitment, validity, and transition, lines 65-95",
"source": "eip.md",
"summary": "Security spans body/header commitment validation and unconditional execution-state balance increases based on consensus-supplied data."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A fault can create incorrect ETH balances and crosses multiple critical components: consensus validation, execution block validation, commitment construction, and account state. The proposal itself calls for very high scrutiny, supporting extensive cross-component security review and fuzzing.",
"score": 3,
"uncertainty_note": "The unspecified cross-layer interface and validation details broaden, rather than eliminate, the review risk.",
"under_specified": false
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Specification / Constants and system-level operation, lines 32-48",
"source": "eip.md",
"summary": "The activation timestamp is TBD, and the text gives field types and a monotonic index without complete list-level validity semantics."
},
{
"locator": "Specification / Block validity and state transition, lines 79-97",
"source": "eip.md",
"summary": "Only root equality and unconditional balance increase are specified, followed by an explicit unresolved question about logs, receipts, and a receipts commitment."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "The draft leaves consensus-observable choices unresolved, most notably whether withdrawals create logs and receipts and add another commitment. It also omits constructible-case rules for empty or malformed lists, index progression, and unconditional balance-update extremes. Clients would have to agree and re-baseline block and state-transition vectors as those choices were amended, matching score 3.",
"score": 3,
"uncertainty_note": "No packaged implementation, devnet, test cases, or discussion record is available, so the assessment cannot establish whether any intended readings had already converged outside the sealed proposal.",
"under_specified": true
},
{
"confidence": "medium",
"evidence": [
{
"locator": "Motivation, lines 21-28",
"source": "eip.md",
"summary": "The proposal contrasts its system operation with the EIP-4788-plus-contract pull design and the prior EIP-4863 transaction-based push design."
},
{
"locator": "Motivation, lines 19-24",
"source": "supporting/eip-4788.md",
"summary": "EIP-4788 states that exposing beacon state roots supports and is required for a different validator-withdrawal route."
},
{
"locator": "Specification, lines 26-56",
"source": "supporting/eip-4863.md",
"summary": "EIP-4863 specifies the same push-withdrawal objective as a special transaction type with ordering and balance-update semantics."
},
{
"locator": "Specification and Security Considerations, lines 40-46 and 122-125",
"source": "eip.md",
"summary": "Withdrawal data and its validation originate at the consensus layer, creating an essential cross-layer dependency whose EIP number is not identified."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [
4788,
4863
],
"rationale": "EIP-4895 is independently testable from the two numbered alternative designs, but it supersedes or conflicts with their withdrawal paths and therefore needs limited comparative coverage. More importantly, correct execution behavior depends on coordinated consensus-layer production and validation of the withdrawal list; that dependency is material but bounded in scope, fitting score 2 rather than an extensive multi-EIP score 3.",
"score": 2,
"uncertainty_note": "The package identifies no EIP number for the required consensus-layer withdrawal scheduling and validation change, so it cannot be added to the numbered list or assessed in greater detail.",
"under_specified": true,
"unidentified_interactions": [
"Consensus-layer withdrawal scheduling, bounding, data supply, and validation required by the execution-layer operation; no EIP number is identified in the package."
]
}
],
"eip": 4895,
"evaluation_date": "2026-08-25",
"fork": "shanghai",
"id": "shanghai:4895:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The term monotonically increasing does not state the validation scope or whether gaps are permitted.",
"The phrase assuming the block is well-formatted leaves malformed withdrawal-list validation outside the stated root check.",
"Unconditional and MUST not fail does not define arithmetic-limit or absent-account behavior.",
"The package establishes a consensus-layer dependency but identifies no EIP number for that change."
],
"provenance": {
"assessed_revision": {
"commit": "1ce607ac37433c566f9ee5ecad817693da1fcd3f",
"committed_at": "2022-03-11T12:28:57Z",
"content_sha256": "34436435c8cd7099db27223f7219fd85190f1648805caebebc4e00ad60c287c1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-4895.md",
"git_blob_sha": "20168103d6823834989fd5d37c090ff7c559d64d",
"immutable_url": "https://github.com/ethereum/EIPs/blob/1ce607ac37433c566f9ee5ecad817693da1fcd3f/EIPS/eip-4895.md",
"information_cutoff_at": "2022-03-11T12:28:57Z",
"path": "EIPS/eip-4895.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-4895.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/shanghai/eip-4895.yaml",
"sha256": "7a696963b4104d1b4587b1210af9c44ff07fbff30175b329cdf415c488c578c9"
},
"supporting_documents": [
"supporting/eip-4788.md",
"supporting/eip-4863.md"
]
},
"role": "primary",
"rubric_revision": 2,
"score": 30,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, this draft proposed a new system-level withdrawal object, distinct from transactions, carrying a consensus-layer-supplied index, recipient, and amount. Post-fork execution blocks would gain an RLP-encoded withdrawals list and a header withdrawals root built like the transactions root; execution clients would validate the commitment and, after all user transactions, apply every withdrawal as an unconditional, gas-free balance increase. The draft left the fork timestamp and whether to add logs, receipts, and a receipts commitment unresolved, while assuming consensus-layer validation and a small bound on withdrawal volume.",
"tier": "high",
"title": "Beacon chain push withdrawals as operations",
"under_specification": {
"affected_criteria": [
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"performance_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"plausible_tiers": [
"high"
],
"plausible_total_range": {
"maximum": 35,
"minimum": 24
},
"present": true,
"summary": "Material consensus behavior remains open in this draft. The explicit logs and receipts TODO could add observable execution outputs and another commitment; the consensus/execution transport, empty-list and field-presence behavior, index validity, list bound, and extreme balance-update semantics are also not specified sufficiently to baseline every constructible test.",
"unresolved_questions": [
"Do withdrawals produce logs or receipts, and if so what are their schemas and commitment rules?",
"Through what consensus/execution interface are withdrawals and any related commitments supplied and validated?",
"Is the withdrawals field mandatory when empty, and what is the required empty-list root at and after activation?",
"What list-level validity rules apply to withdrawal indices, including duplicates, gaps, and ordering across or within blocks?",
"What exact maximum list size is consensus-enforced, and how is violation represented or rejected at the execution layer?",
"How must unconditional balance increases behave at numeric limits and for previously absent recipient accounts?"
]
}
},
"shanghai:6049:llm:r2": {
"confidence": "high",
"criteria": [
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The proposal changes only opcode documentation and expressly says no client changes apply."
}
],
"exceptional_score_justification": null,
"id": "evm_gas_rule_changes",
"rationale": "No gas schedule or gas-accounting mechanism is changed, satisfying the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "Only non-normative documentation is updated; opcode execution in clients is unchanged."
}
],
"exceptional_score_justification": null,
"id": "state_access_ordering_within_opcode_execution",
"rationale": "No state access or gas-charge position within SELFDESTRUCT or any other opcode changes, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The only specified action is a documentation warning, with no client change."
}
],
"exceptional_score_justification": null,
"id": "blob_gas_accounting_changes",
"rationale": "The proposal introduces no blob-gas rule or mechanism, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The proposal is limited to non-normative documentation and requires no client change."
}
],
"exceptional_score_justification": null,
"id": "state_gas_accounting_changes",
"rationale": "No state-writing charge, rate, budget, reservoir, or spill rule changes, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The EIP changes documentation only and makes no change to client execution."
}
],
"exceptional_score_justification": null,
"id": "new_evm_gas_refund",
"rationale": "No new gas-refund mechanism is introduced, satisfying the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The EIP says its update is to non-normative Yellow Paper text and that no client changes apply."
}
],
"exceptional_score_justification": null,
"id": "patterns_affecting_pre_existing_tests",
"rationale": "With no executable or validation rule changed, no pre-existing protocol tests require reworking; the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "Documentation gains a warning, while client behavior and protocol outputs remain unchanged."
}
],
"exceptional_score_justification": null,
"id": "new_invariant_on_pre_existing_tests",
"rationale": "Pre-existing tests gain no new protocol invariant to assert, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The proposal expressly requires no client changes because it updates non-normative text only."
}
],
"exceptional_score_justification": null,
"id": "transition_tool_interface_changes",
"rationale": "No transition-tool field or interface mechanism is required, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The proposal has only a documentation effect and no client-level behavior to test."
}
],
"exceptional_score_justification": null,
"id": "new_test_framework_primitives",
"rationale": "Existing test primitives suffice because no protocol test suite is introduced; the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 12-14; Specification, lines 20-22",
"source": "eip.md",
"summary": "The EIP deprecates SELFDESTRUCT through a documentation warning and specifies no other mechanism."
}
],
"exceptional_score_justification": null,
"id": "cryptography",
"rationale": "No cryptographic functionality is introduced or modified, satisfying score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The specified change is solely a warning in documentation, not a behavior change."
}
],
"exceptional_score_justification": null,
"id": "edge_boundary_conditions",
"rationale": "The proposal introduces no executable mechanism with edge or boundary conditions, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "No client changes apply because the EIP updates non-normative text only."
}
],
"exceptional_score_justification": null,
"id": "block_syncing_changes",
"rationale": "No block RLP validation mechanism is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The EIP updates opcode documentation and specifies no client or interface modification."
}
],
"exceptional_score_justification": null,
"id": "engine_api_changes",
"rationale": "No Engine API field, endpoint, or communication mechanism is introduced, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22",
"source": "eip.md",
"summary": "The complete specified action is an update to SELFDESTRUCT documentation."
}
],
"exceptional_score_justification": null,
"id": "added_system_contracts",
"rationale": "No system contract is introduced, satisfying the score-0 anchor.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "Only opcode documentation changes, and no client change applies."
}
],
"exceptional_score_justification": null,
"id": "modified_system_contracts",
"rationale": "The proposal neither directly nor indirectly modifies a pre-existing system contract, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 12-14",
"source": "eip.md",
"summary": "The proposal concerns deprecation of the already existing SELFDESTRUCT opcode."
}
],
"exceptional_score_justification": null,
"id": "added_opcodes",
"rationale": "No opcode is added; naming and deprecating an existing opcode satisfies the score-0 anchor for additions.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Title and description, lines 2-4; Abstract, lines 12-14",
"source": "eip.md",
"summary": "The proposal explicitly deprecates the existing SELFDESTRUCT opcode and warns against its use."
},
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The deprecation is implemented as a non-normative documentation warning and does not change client behavior."
}
],
"exceptional_score_justification": null,
"id": "modified_opcodes",
"rationale": "The score-3 anchor explicitly applies when a pre-existing opcode is deprecated; SELFDESTRUCT is deprecated here even though its current behavior is unchanged.",
"score": 3,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22",
"source": "eip.md",
"summary": "The only specified action is updating documentation for SELFDESTRUCT."
}
],
"exceptional_score_justification": null,
"id": "added_precompiles",
"rationale": "No precompile is introduced, satisfying score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The proposal changes SELFDESTRUCT documentation only and makes no client change."
}
],
"exceptional_score_justification": null,
"id": "modified_precompiles",
"rationale": "No precompile behavior or gas schedule is modified, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The EIP specifies only non-normative opcode-documentation changes."
}
],
"exceptional_score_justification": null,
"id": "encoding_changes_rlp_ssz",
"rationale": "No transaction, block, or interface encoding changes, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22",
"source": "eip.md",
"summary": "The proposal is confined to a warning in SELFDESTRUCT documentation."
}
],
"exceptional_score_justification": null,
"id": "new_transaction_types",
"rationale": "No transaction type is introduced, satisfying score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "Only documentation is updated, and clients require no change."
}
],
"exceptional_score_justification": null,
"id": "new_or_modified_transaction_validity_mechanisms",
"rationale": "Transaction validity rules and intrinsic gas calculations are unchanged, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22",
"source": "eip.md",
"summary": "The only specified action is updating documentation for an opcode."
}
],
"exceptional_score_justification": null,
"id": "new_block_header_fields",
"rationale": "No block or header field is introduced, matching score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The EIP applies no client change and only updates non-normative text."
}
],
"exceptional_score_justification": null,
"id": "new_fork_activation_mechanism",
"rationale": "It requires no activation-block state or internal-variable modification, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "Documentation is updated without any client or execution-behavior change."
}
],
"exceptional_score_justification": null,
"id": "performance_risks",
"rationale": "No runtime mechanism requiring performance validation is introduced or modified, satisfying score 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Backwards Compatibility, lines 30-32; Security Considerations, lines 34-36",
"source": "eip.md",
"summary": "The EIP specifies no client change and records no security considerations."
}
],
"exceptional_score_justification": null,
"id": "security_risks",
"rationale": "A documentation warning introduces no executable mechanism that could compromise stakeholders if implemented incorrectly, so the score is 0.",
"score": 0,
"uncertainty_note": "None identified.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Abstract, lines 12-14; Specification, lines 20-22; Backwards Compatibility, lines 30-32",
"source": "eip.md",
"summary": "The EIP limits its present action to a documentation warning; a possible breaking behavior change is future work and current clients do not change."
}
],
"exceptional_score_justification": null,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"rationale": "Within this EIP's assessment-time scope, no constructible protocol case needs a newly agreed answer, so the score is 0.",
"score": 0,
"uncertainty_note": "The future SELFDESTRUCT behavior is deliberately unresolved but is outside this proposal's normative scope.",
"under_specified": false
},
{
"confidence": "high",
"evidence": [
{
"locator": "Motivation, lines 16-18; Specification, lines 20-22",
"source": "eip.md",
"summary": "The text mentions ongoing discussion of a future SELFDESTRUCT change but specifies only a documentation warning and identifies no other EIP dependency, modification, or conflict."
}
],
"exceptional_score_justification": null,
"id": "cross_eip_interactions",
"interacting_eips": [],
"rationale": "The deprecation is self-contained and the package establishes no interaction with another EIP, satisfying score 0.",
"score": 0,
"uncertainty_note": "No numbered or otherwise concrete interacting proposal is identified in the package.",
"under_specified": false,
"unidentified_interactions": []
}
],
"eip": 6049,
"evaluation_date": "2026-08-25",
"fork": "shanghai",
"id": "shanghai:6049:llm:r2",
"mode": "retrospective",
"notable_ambiguities": [
"The Modified opcodes anchor assigns score 3 to deprecation explicitly, although this EIP operationalizes deprecation solely through non-normative documentation and makes no current opcode-behavior or client change."
],
"provenance": {
"assessed_revision": {
"commit": "7c8e7e6eb5f80a091998479eb57dbfea8386e8f3",
"committed_at": "2022-12-20T18:17:44Z",
"content_sha256": "1309a340428600c18e624153225fe47e437c64f637e472b0d36cffb6c5c466b1",
"current_revision_url": "https://github.com/ethereum/EIPs/blob/master/EIPS/eip-6049.md",
"git_blob_sha": "f0159cb299c91d911702a269ef694da22cbbd0de",
"immutable_url": "https://github.com/ethereum/EIPs/blob/7c8e7e6eb5f80a091998479eb57dbfea8386e8f3/EIPS/eip-6049.md",
"information_cutoff_at": "2023-01-19",
"path": "EIPS/eip-6049.md",
"repository": "ethereum/EIPs",
"revision_history_url": "https://github.com/ethereum/EIPs/commits/master/EIPS/eip-6049.md"
},
"assessor": {
"isolation_method": "bubblewrap_one_eip_capsule_v1",
"kind": "llm",
"model": "gpt-5.6-sol",
"reasoning_effort": "xhigh"
},
"rubric": {
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm",
"revision": 2
},
"source_record": {
"kind": "research_record",
"path": "research/tasks/05-retrospective-complexity-assignment/outputs/fork-eips/shanghai/eip-6049.yaml",
"sha256": "908033e8bf2f77a4d9b1f083dfc9f86c3c8a673a608838f306d6d4666887a92a"
},
"supporting_documents": []
},
"role": "primary",
"rubric_revision": 2,
"score": 3,
"scored": true,
"snapshot_id": null,
"snapshot_status": null,
"source": "llm",
"status": "complete",
"summary": "At the information cutoff, EIP-6049 deprecated the existing SELFDESTRUCT opcode by directing its documentation to warn against use and to flag a possible future breaking change. It made no client or current opcode-behavior change; the possible future change remained outside this proposal's scope.",
"tier": "low",
"title": "Deprecate SELFDESTRUCT",
"under_specification": {
"affected_criteria": [],
"plausible_tiers": [
"low"
],
"plausible_total_range": {
"maximum": 3,
"minimum": 3
},
"present": false,
"summary": "No material consensus under-specification is present in the assessed scope. The text deliberately leaves a possible future SELFDESTRUCT behavior change unresolved, but this EIP specifies only a non-normative warning and no client behavior to baseline.",
"unresolved_questions": []
}
}
},
"charts": {
"fork-milestones-amsterdam": "generated/charts/fork-milestones-amsterdam.json",
"fork-milestones-cancun": "generated/charts/fork-milestones-cancun.json",
"fork-milestones-osaka": "generated/charts/fork-milestones-osaka.json",
"fork-milestones-prague": "generated/charts/fork-milestones-prague.json",
"fork-milestones-shanghai": "generated/charts/fork-milestones-shanghai.json",
"fork-shipping": "generated/charts/fork-shipping.json",
"fork-shipping-hardest-eip": "generated/charts/fork-shipping-hardest-eip.json",
"fork-shipping-high-tier": "generated/charts/fork-shipping-high-tier.json",
"predicted-observed-eip-interactions": "generated/charts/predicted-observed-eip-interactions.json",
"predicted-observed-specification-rework": "generated/charts/predicted-observed-specification-rework.json",
"timeline-amsterdam": "generated/charts/timeline-amsterdam.json",
"timeline-cancun": "generated/charts/timeline-cancun.json",
"timeline-osaka": "generated/charts/timeline-osaka.json",
"timeline-prague": "generated/charts/timeline-prague.json",
"timeline-shanghai": "generated/charts/timeline-shanghai.json"
},
"comparisons": {
"amsterdam:2780:r1": {
"absolute_delta": 7,
"agreement_counts": {
"exact": 20,
"major": 3,
"minor": 1
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "possible_exposure",
"human_timing_exposure_rationale": "The rationale discusses existing EIP-7702 tests needing updates, indicating awareness of a concrete test corpus but not a completed implementation of EIP-2780.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "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 specification that overrides EIP-2929's 'all tx addresses are warm' rule (per-type charges for tx.sender and tx.to, precompiles warm, access-list override), plus a 'Monetary Context' motivation section (PR #10595, 'Add context'). | Clarifications with normative effect (PR #10598): CALL_VALUE_COST = 2,000 applies to all value-carrying calls regardless of prior account updates (2300-gas stipend safety); EIP-7702 senders must not trigger a disk code-load for classification; new-account surcharge component table restated; test vectors 7-14 added (warmth/access-list interplay, 7702 cases, precompile transfers, self-transfer, internal CALL repricing, Perfnet stress, SELFDESTRUCT); SELFDESTRUCT/EIP-6780 security note; throughput/payload/basefee levers section.",
"primary_llm_total": 25,
"template_match": "exact"
},
"delta": 7,
"eip": 2780,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:2780:human:r1",
"human_tier": "medium",
"human_total": 13,
"id": "amsterdam:2780:r1",
"largest_disagreements": [
"security_risks",
"cross_eip_interactions",
"performance_risks",
"blob_gas_accounting_changes"
],
"llm_assessment_id": "amsterdam:2780:llm:r1",
"llm_tier": "high",
"llm_total": 20,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "evm_gas_rule_changes",
"llm": 3
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "security_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:7610:r1": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 17,
"major": 5,
"minor": 2
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "possible_exposure",
"human_timing_exposure_rationale": "The assessment cites a Magicians observation and possible EELS work, but describes the implementation as prospective.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "Substantive intervening revisions: Adds an explicit EIP-7702 non-interference statement to the Specification (PR #10734): 'This EIP will not affect EIP-7702, since the authority's nonce is always incremented after an authorization is applied, which conflicts with the condition required for contract deployment.' Simultaneously deletes the Rationale sentence 'As one of the core tenets of smart contracts is that its code will not change...'.",
"primary_llm_total": 9,
"template_match": "exact"
},
"delta": 3,
"eip": 7610,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7610:human:r1",
"human_tier": "low",
"human_total": 7,
"id": "amsterdam:7610:r1",
"largest_disagreements": [
"modified_opcodes",
"transition_tool_interface_changes",
"new_or_modified_transaction_validity_mechanisms",
"security_risks",
"cross_eip_interactions"
],
"llm_assessment_id": "amsterdam:7610:llm:r1",
"llm_tier": "medium",
"llm_total": 10,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "edge_boundary_conditions",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "performance_risks",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:7708:r1": {
"absolute_delta": 4,
"agreement_counts": {
"exact": 17,
"major": 3,
"minor": 4
},
"confounds": {
"clean_comparison": true,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [],
"human_timing_exposure": "high_exposure",
"human_timing_exposure_rationale": "The rationale describes the then-current execution-specs test-framework handling of transition-tool logs and a required enhancement.",
"input_alignment": "exact_blob",
"input_alignment_summary": "The human-time and approved Task 04 EIP commits resolve to the same Git blob.",
"primary_llm_total": 19,
"template_match": "exact"
},
"delta": 4,
"eip": 7708,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7708:human:r1",
"human_tier": "low",
"human_total": 9,
"id": "amsterdam:7708:r1",
"largest_disagreements": [
"modified_system_contracts",
"modified_opcodes",
"security_risks",
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes"
],
"llm_assessment_id": "amsterdam:7708:llm:r1",
"llm_tier": "medium",
"llm_total": 13,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "cross_eip_interactions",
"llm": 1
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:7778:r1": {
"absolute_delta": 2,
"agreement_counts": {
"exact": 16,
"major": 3,
"minor": 5
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "low_exposure",
"human_timing_exposure_rationale": "The assessment uses proposal-level reasoning about refunds and block gas limits without identifying an implementation, devnet, or completed test effort.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "Substantive intervening revisions: Adds a note to the user gas-cost rule: because receipts store the post-refund gas_used value, validating block gas limits from receipts requires tracking refunds during transaction execution and adding them back to each transaction's gas_used when computing cumulative block gas usage.",
"primary_llm_total": 13,
"template_match": "exact"
},
"delta": -2,
"eip": 7778,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7778:human:r1",
"human_tier": "medium",
"human_total": 10,
"id": "amsterdam:7778:r1",
"largest_disagreements": [
"modified_opcodes",
"evm_gas_rule_changes",
"security_risks",
"edge_boundary_conditions",
"block_syncing_changes"
],
"llm_assessment_id": "amsterdam:7778:llm:r1",
"llm_tier": "low",
"llm_total": 8,
"rows": [
{
"agreement": "major",
"delta": -2,
"human": 3,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 1
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "block_syncing_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": -3,
"human": 3,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "performance_risks",
"llm": 1
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "cross_eip_interactions",
"llm": 1
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:7843:r1": {
"absolute_delta": 10,
"agreement_counts": {
"exact": 17,
"major": 2,
"minor": 5
},
"confounds": {
"clean_comparison": true,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [],
"human_timing_exposure": "low_exposure",
"human_timing_exposure_rationale": "The assessment describes required future interface fields and does not identify implementation or test outcomes.",
"input_alignment": "no_substantive_drift",
"input_alignment_summary": "Every intervening EIP revision is classified non-substantive by Task 01.",
"primary_llm_total": 23,
"template_match": "exact"
},
"delta": 10,
"eip": 7843,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7843:human:r1",
"human_tier": "low",
"human_total": 7,
"id": "amsterdam:7843:r1",
"largest_disagreements": [
"encoding_changes_rlp_ssz",
"security_risks",
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"block_syncing_changes"
],
"llm_assessment_id": "amsterdam:7843:llm:r1",
"llm_tier": "medium",
"llm_total": 17,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "transition_tool_interface_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 1
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "block_syncing_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "engine_api_changes",
"llm": 1
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "added_opcodes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "new_block_header_fields",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "performance_risks",
"llm": 1
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cross_eip_interactions",
"llm": 0
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:7928:r1": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 19,
"major": 3,
"minor": 2
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "high_exposure",
"human_timing_exposure_rationale": "The assessment explicitly relies on implementation files, permanent framework additions, benchmarks, planned and completed tests, spec churn, and bugs found by tests.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "Substantive intervening revisions: Renames header field bal_hash->block_access_list_hash, specifies system-contract changes use tx_index = len(transactions) + 1, adds the rule that EIP-2930 access-list entries MUST NOT be auto-included, and extends the example. | Code changes now also track EIP-7702 delegation indicators. | Fixes system-contract tx_index from len(transactions) + 1 to len(transactions) throughout text, example and pseudocode. | Splits system-contract handling into pre-execution (tx_index = len(transactions)) and post-execution (len(transactions) + 1) phases, adds the explicit EIP-4895 reference for withdrawal recipients, restricts recipient balance recording to value > 0, and rebuilds the example with lexicographic ordering. | Switches BAL encoding from SSZ to RLP, introduces BlockAccessIndex (0 = pre-execution, 1..n = transactions, n+1 = post-execution), widens Balance to uint256, adds Engine API validation flow, and fixes the eip-7792.md link typo to eip-7702.md. | Fixes the block-hash system-contract address in the example from 0x...0001 to the actual EIP-2935 address 0x0000F90827F1C53a10cb7A02335B175320002935. | Restructures the Specification into dedicated sections (Scope and Inclusion, Ordering and Determinism, BlockAccessIndex Assignment, Recording Semantics, Edge Cases (Normative), Engine API); adds the Engine API statement that the EL provides both block_access_list and block_access_list_hash in the ExecutionPayload; updates description frontmatter and size figure (~45 KiB). | Specifies empty-BAL encoding: header hash is keccak256(rlp.encode([])) and the body field is the empty RLP list 0xc0; converts bullets to hyphen style. | Expands the exceptional-halts rule (accessed addresses of reverted calls MUST be included; reads appear in storage_reads) and downgrades validation-by-comparison from MUST (per EIP-2929) to MAY, dropping that EIP-2929 reference. | Splits SENDALL from SELFDESTRUCT and defines the in-transaction selfdestruct canonical signal (nonce 0, empty code, zero balance at that index). | Reverses the previous selfdestruct signal: destroyed-in-transaction accounts are included without balance/nonce/code changes; touched storage keys become storage_reads. | Adds a precompiled-contracts edge case: precompiles MUST be included when accessed, with a balance change if they receive value. | Expands the MUST-include list (opcode targets, reverting calls, failed CREATE targets, senders/recipients, coinbase, selfdestruct beneficiaries, system contracts, withdrawal recipients, precompiles), adds the no-op-write pre-value check note, and adds an EIP-7702 delegations edge case. | In-transaction selfdestruct: if the account had a positive pre-transaction balance, the balance change to zero MUST be recorded. | Restricts EIP-7702 tracking to successful delegations and rewrites authority/delegation-target inclusion rules (empty change set on invalid-nonce failure; target only when actually loaded). | Adds the unaltered-balance rule (post == pre MUST NOT be recorded), extends balance recording to CALL/CALLCODE senders and recipients and CREATE/CREATE2 recipients, and conditions failed-authorization inclusion on accessed_addresses per EIP-2929. | Specifies Engine API structures and methods: ExecutionPayloadV4 with blockAccessList, engine_newPayloadV5, engine_getPayloadV6; CL computes the SSZ hash_tree_root. | Rewrites the ordering rules per-field (accounts, storage_changes, storage_reads, balance/nonce/code_changes ordered by block access index). | Deletes the MAX_* constants block entirely (MAX_TXS, MAX_SLOTS, MAX_ACCOUNTS, MAX_CODE_SIZE, MAX_CODE_CHANGES) and adds the zero-value block-reward recipient rule. | Refines the zero-value block-reward wording: no balance change and no read-only inclusion; include with a balance change only when the reward is positive. | Adds the COINBASE / fee-recipient edge case (include on any state change; exclude in empty blocks; include as a read when the reward is zero) and normalizes Coinbase->COINBASE. | Type aliases: Address bytes->bytes20, StorageKey/StorageValue bytes->bytes32, CodeData->Bytecode; balance recording text uint128->uint256. | Changes StorageKey and StorageValue from bytes32 to uint256. | Adds the rule that call-operation targets are included only if gas checks (memory expansion, access cost, transfer cost) pass before state access. | SYSTEM_ADDRESS (0xffff...fffe) MUST NOT be included unless it experiences state access itself. | Adds inclusion of deployed contract addresses from calls with initcode to empty addresses (e.g., calling 0x0 with initcode). | Removes the BAL from the EL block body (stored separately, transmitted in the ExecutionPayload), specifies the block-processing flow, adds engine_getBALsByHashV1/engine_getBALsByRangeV1 retrieval methods and a retention requirement, and updates the abstract (parallel state-root computation) and size figure (~70 KiB). | Despite the 'fix linter issues' subject, changes the BAL retention requirement from 'until the last finalized checkpoint' to 'the weak subjectivity period (=3533 epochs)' (plus formatting fixes). | Rewrites the EIP-7702 delegation edge case: authority included on successful set/update/clear; inclusion on failed authorization depends on whether the authority was loaded; delegation target included only when loaded as an execution target. | Adds that spurious entries MAY be detected by validating BAL indices, which MUST never exceed len(transactions) + 1; fixes typos. | COINBASE included if the block contains transactions or withdrawals; withdrawal recipients included regardless of the withdrawal amount. | Replaces engine_getBALsByHashV1/RangeV1 with engine_getPayloadBodiesByHashV2/RangeV2 returning ExecutionPayloadBodyV2 (blockAccessList null for pre-Amsterdam or pruned blocks). | Adds the 'Gas Validation Before State Access' section: pre-/post-state validation phases, a per-opcode pre-state gas table anchored to EIP-2929 constants, EIP-7702 delegation resolution rules and the SSTORE stipend check. | CREATE/CREATE2 targets included only 'if the target account is accessed'; COINBASE inclusion narrowed to withdrawals to the COINBASE address; storage_read->storage_reads naming and wording fixes. | Adds the Block Access List Size Constraint: bal_items * ITEM_COST <= available_gas + system_allowance, with constants from EIP-7002 and EIP-7251. | Adds the 'Early Rejection of Malicious BALs' security consideration: clients SHOULD enforce G_remaining >= R_remaining * 2000 at transaction boundaries against phantom storage reads. | Simplifies the size cap to bal_items <= block_gas_limit // ITEM_COST with ITEM_COST = 2000, justified via the EIP-7981 cold-SLOAD floor; specifies EIP-7002/7251 queue-data slots appearing as storage_reads. | Adds uniqueness constraints: unique addresses, storage keys at most once per list, no key in both storage_changes and storage_reads, unique block_access_index per change list. | Adds an implementation note: the BAL need not enter the state transition function; implementations MAY validate a virtual BAL hash against the header (execution-specs approach). | Fixes contradictory fee-recipient rules: removes the COINBASE bullet from the MUST-include list; COINBASE now follows the same inclusion rules as any account; zero-value block rewards no longer force inclusion. | Widens BlockAccessIndex uint16->uint64 and specifies CL-side storage: BAL as an SSZ ExecutionPayload field, prunable to its hash_tree_root. | Adjusts BlockAccessIndex from uint64 to uint32.",
"primary_llm_total": 40,
"template_match": "exact"
},
"delta": -3,
"eip": 7928,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7928:human:r1",
"human_tier": "high",
"human_total": 29,
"id": "amsterdam:7928:r1",
"largest_disagreements": [
"evm_gas_rule_changes",
"engine_api_changes",
"encoding_changes_rlp_ssz",
"patterns_affecting_pre_existing_tests",
"modified_system_contracts"
],
"llm_assessment_id": "amsterdam:7928:llm:r1",
"llm_tier": "high",
"llm_total": 26,
"rows": [
{
"agreement": "major",
"delta": -3,
"human": 3,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "transition_tool_interface_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "block_syncing_changes",
"llm": 2
},
{
"agreement": "major",
"delta": -3,
"human": 3,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "modified_system_contracts",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "new_block_header_fields",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "security_risks",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 1,
"tier_agreement": true
},
"amsterdam:7976:r1": {
"absolute_delta": 7,
"agreement_counts": {
"exact": 19,
"major": 4,
"minor": 1
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"divergent_or_unknown_historical_template"
],
"human_timing_exposure": "high_exposure",
"human_timing_exposure_rationale": "The assessment says generators were already prepared and refers to work completed during EIP-7623 testing and existing static tests.",
"input_alignment": "no_substantive_drift",
"input_alignment_summary": "Every intervening EIP revision is classified non-substantive by Task 01.",
"primary_llm_total": 10,
"template_match": "divergent"
},
"delta": 7,
"eip": 7976,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7976:human:r1",
"human_tier": "low",
"human_total": 5,
"id": "amsterdam:7976:r1",
"largest_disagreements": [
"edge_boundary_conditions",
"performance_risks",
"security_risks",
"cross_eip_interactions",
"patterns_affecting_pre_existing_tests"
],
"llm_assessment_id": "amsterdam:7976:llm:r1",
"llm_tier": "medium",
"llm_total": 12,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:7981:r1": {
"absolute_delta": 5,
"agreement_counts": {
"exact": 18,
"major": 3,
"minor": 3
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "high_exposure",
"human_timing_exposure_rationale": "The assessment reasons from an existing intrinsic-gas calculator interface used by many access-list tests.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "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 leaving a non-negligible data footprint' framing); 'Maximum Block Size Impact' is renamed 'Access List Size Impact' and recomputed at a 60M gas limit (1012 KB -> 604 KB); a new 'Maximum Block Size Impact' section states the Snappy-compressed maximum falls from 2.71 MiB to 2.13 MiB. The description acquires the typo 'footpring'.",
"primary_llm_total": 11,
"template_match": "exact"
},
"delta": 5,
"eip": 7981,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7981:human:r1",
"human_tier": "low",
"human_total": 6,
"id": "amsterdam:7981:r1",
"largest_disagreements": [
"performance_risks",
"security_risks",
"cross_eip_interactions",
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests"
],
"llm_assessment_id": "amsterdam:7981:llm:r1",
"llm_tier": "medium",
"llm_total": 11,
"rows": [
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:7997:r1": {
"absolute_delta": 8,
"agreement_counts": {
"exact": 16,
"major": 4,
"minor": 4
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "low_exposure",
"human_timing_exposure_rationale": "The assessment is grounded in proposal mechanisms and a disclosed security concern, with no implementation, devnet, or test-outcome evidence.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "Substantive intervening revisions: Rewrites the Abstract and two Motivation paragraphs, and - the substantive part - adds a prose normative specification of the factory's behaviour ahead of the bytecode: when called, the account invokes CREATE2 (linking EIP-1014) with salt = first 32 bytes of input, init code = the remaining input and value = the call's value; the call reverts with empty return data if input is shorter than 32 bytes; if CREATE2 outputs 0 the call reverts with the creation frame's return data. The bytecode is retained and is now described as implementing that specification. | Changes the single parameter FACTORY_ADDRESS from 0x0B to 0x12 (and the matching Rationale text, now 'the next lowest address after currently accepted precompiles'), and adds a Backwards Compatibility section requiring that FACTORY_ADDRESS not be used by other precompiles or predeploys on a chain, with the constant chosen to minimise that risk.",
"primary_llm_total": 14,
"template_match": "exact"
},
"delta": 8,
"eip": 7997,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:7997:human:r1",
"human_tier": "low",
"human_total": 5,
"id": "amsterdam:7997:r1",
"largest_disagreements": [
"transition_tool_interface_changes",
"edge_boundary_conditions",
"new_fork_activation_mechanism",
"cross_eip_interactions",
"patterns_affecting_pre_existing_tests"
],
"llm_assessment_id": "amsterdam:7997:llm:r1",
"llm_tier": "medium",
"llm_total": 13,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "added_system_contracts",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "new_fork_activation_mechanism",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "performance_risks",
"llm": 1
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "security_risks",
"llm": 1
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:8024:r1": {
"absolute_delta": 5,
"agreement_counts": {
"exact": 20,
"major": 1,
"minor": 3
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift",
"divergent_or_unknown_historical_template"
],
"human_timing_exposure": "low_exposure",
"human_timing_exposure_rationale": "The client-performance comment is hypothetical and the assessment identifies no visible implementation, devnet, or completed test evidence.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "Substantive intervening revisions: Shifts the EXCHANGE operand encoding down by one so the assembly operands match the intended SWAP-like indexing. decode_pair returns (q + 1, r + 1) / (r + 1, 29 - q) instead of (q + 2, r + 2) / (r + 2, 30 - q), and encode_pair's assertion and arithmetic change from '2 <= n <= 14 and n < m <= 30 and n + m <= 32' with the m <= 17 branch to '1 <= n <= 13 and n < m <= 29 and n + m <= 30' with the m <= 16 branch. A Rationale paragraph is added explaining that the operands look off by one because EXCHANGE n m operates on stack depths n + 1 and m + 1, chosen so that EXCHANGE n m is equivalent to SWAP{n} SWAP{m} SWAP{n}. Two disassembly test cases are renumbered accordingly (e812 becomes EXCHANGE 2 3, e8d0 becomes EXCHANGE 1 19).",
"primary_llm_total": 13,
"template_match": "divergent"
},
"delta": 5,
"eip": 8024,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:8024:human:r1",
"human_tier": "low",
"human_total": 6,
"id": "amsterdam:8024:r1",
"largest_disagreements": [
"security_risks",
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions"
],
"llm_assessment_id": "amsterdam:8024:llm:r1",
"llm_tier": "medium",
"llm_total": 11,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "added_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "performance_risks",
"llm": 1
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cross_eip_interactions",
"llm": 0
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"amsterdam:8037:r1": {
"absolute_delta": 7,
"agreement_counts": {
"exact": 17,
"major": 5,
"minor": 2
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "high_exposure",
"human_timing_exposure_rationale": "The assessment links the execution-specs static-test tree and describes rework of existing Python tests.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "Substantive intervening revisions: Defines success-vs-failure gas accounting for contract deployment: GAS_NEW_ACCOUNT, GAS_CODE_DEPOSIT*L and HASH_COST(L) are charged only on the success path, with explicit total-gas formulas and check ordering; removes the duplicated-code deposit-exemption sentence from the abstract; reformats the parameter table. | Changes GAS_NEW_ACCOUNT's affected operations to CALL*, removes GAS_SELF_DESTRUCT_NEW_ACCOUNT (replaced by GAS_NEW_ACCOUNT), and corrects the deployment cost example accordingly.",
"primary_llm_total": 35,
"template_match": "exact"
},
"delta": -7,
"eip": 8037,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:8037:human:r1",
"human_tier": "high",
"human_total": 28,
"id": "amsterdam:8037:r1",
"largest_disagreements": [
"patterns_affecting_pre_existing_tests",
"evm_gas_rule_changes",
"performance_risks",
"security_risks",
"new_evm_gas_refund"
],
"llm_assessment_id": "amsterdam:8037:llm:r1",
"llm_tier": "high",
"llm_total": 21,
"rows": [
{
"agreement": "major",
"delta": -5,
"human": 8,
"id": "evm_gas_rule_changes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": -6,
"human": 9,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 4,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "security_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 1,
"tier_agreement": true
},
"amsterdam:8038:r1": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 19,
"major": 3,
"minor": 2
},
"confounds": {
"clean_comparison": false,
"cross_rubric_warning": "A and B use different row inventories, nominal maxima, and thresholds; A-minus-B is descriptive rubric sensitivity, not a like-for-like scale estimate.",
"failed_conditions": [
"substantive_or_unknown_eip_input_drift"
],
"human_timing_exposure": "possible_exposure",
"human_timing_exposure_rationale": "The assessment notes that benchmark numbers were not yet available, showing fork-development awareness without reporting completed implementation outcomes.",
"input_alignment": "substantive_drift",
"input_alignment_summary": "Substantive intervening revisions: Retitles the EIP to 'State-access gas cost update' (PR #10582); renames GAS_STORAGE_UPDATE to GAS_COLD_STORAGE_WRITE and GAS_COLD_SLOAD to GAS_COLD_STORAGE_ACCESS; expands the repricing scope to GAS_STORAGE_CLEAR_REFUND, ACCESS_LIST_STORAGE_KEY_COST, and ACCESS_LIST_ADDRESS_COST; updates the discussions-to link.",
"primary_llm_total": 17,
"template_match": "exact"
},
"delta": -3,
"eip": 8038,
"fork": "amsterdam",
"human_assessment_id": "amsterdam:8038:human:r1",
"human_tier": "high",
"human_total": 20,
"id": "amsterdam:8038:r1",
"largest_disagreements": [
"new_fork_activation_mechanism",
"evm_gas_rule_changes",
"new_or_modified_transaction_validity_mechanisms",
"new_evm_gas_refund",
"security_risks"
],
"llm_assessment_id": "amsterdam:8038:llm:r1",
"llm_tier": "medium",
"llm_total": 17,
"rows": [
{
"agreement": "major",
"delta": -2,
"human": 3,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_encoding_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "security_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 1,
"tier_agreement": false
},
"hegota:2488:r2": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 24,
"major": 1,
"minor": 3
},
"confounds": null,
"delta": -3,
"eip": 2488,
"fork": "hegota",
"human_assessment_id": "hegota:2488:human:r2",
"human_tier": "medium",
"human_total": 13,
"id": "hegota:2488:r2",
"largest_disagreements": [
"patterns_affecting_pre_existing_tests",
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"security_risks"
],
"llm_assessment_id": "hegota:2488:llm:r2",
"llm_tier": "low",
"llm_total": 10,
"rows": [
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "performance_risks",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "security_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "cross_eip_interactions",
"llm": 1
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:3298:r2": {
"absolute_delta": 6,
"agreement_counts": {
"exact": 22,
"major": 3,
"minor": 3
},
"confounds": null,
"delta": 6,
"eip": 3298,
"fork": "hegota",
"human_assessment_id": "hegota:3298:human:r2",
"human_tier": "low",
"human_total": 6,
"id": "hegota:3298:r2",
"largest_disagreements": [
"cross_eip_interactions",
"edge_boundary_conditions",
"security_risks",
"patterns_affecting_pre_existing_tests",
"modified_system_contracts"
],
"llm_assessment_id": "hegota:3298:llm:r2",
"llm_tier": "medium",
"llm_total": 12,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "performance_risks",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "security_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 1,
"id": "cross_eip_interactions",
"llm": 4
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:4758:r2": {
"absolute_delta": 6,
"agreement_counts": {
"exact": 23,
"major": 1,
"minor": 4
},
"confounds": null,
"delta": 6,
"eip": 4758,
"fork": "hegota",
"human_assessment_id": "hegota:4758:human:r2",
"human_tier": "low",
"human_total": 8,
"id": "hegota:4758:r2",
"largest_disagreements": [
"security_risks",
"evm_gas_rule_changes",
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"llm_assessment_id": "hegota:4758:llm:r2",
"llm_tier": "medium",
"llm_total": 14,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "performance_risks",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "security_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:5920:r2": {
"absolute_delta": 2,
"agreement_counts": {
"exact": 22,
"major": 2,
"minor": 4
},
"confounds": null,
"delta": 2,
"eip": 5920,
"fork": "hegota",
"human_assessment_id": "hegota:5920:human:r2",
"human_tier": "medium",
"human_total": 14,
"id": "hegota:5920:r2",
"largest_disagreements": [
"evm_gas_rule_changes",
"state_gas_accounting_changes",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"performance_risks"
],
"llm_assessment_id": "hegota:5920:llm:r2",
"llm_tier": "medium",
"llm_total": 16,
"rows": [
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "state_access_ordering_within_opcode_execution",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "added_opcodes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "performance_risks",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "security_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7645:r2": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 23,
"major": 2,
"minor": 3
},
"confounds": null,
"delta": 3,
"eip": 7645,
"fork": "hegota",
"human_assessment_id": "hegota:7645:human:r2",
"human_tier": "low",
"human_total": 8,
"id": "hegota:7645:r2",
"largest_disagreements": [
"modified_opcodes",
"cross_eip_interactions",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions",
"unspecified_behavior_requiring_cross_client_consensus"
],
"llm_assessment_id": "hegota:7645:llm:r2",
"llm_tier": "low",
"llm_total": 11,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "performance_risks",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "security_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7666:r2": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 22,
"major": 1,
"minor": 5
},
"confounds": null,
"delta": 3,
"eip": 7666,
"fork": "hegota",
"human_assessment_id": "hegota:7666:human:r2",
"human_tier": "medium",
"human_total": 12,
"id": "hegota:7666:r2",
"largest_disagreements": [
"new_invariant_on_pre_existing_tests",
"evm_gas_rule_changes",
"new_test_framework_primitives",
"edge_boundary_conditions",
"performance_risks"
],
"llm_assessment_id": "hegota:7666:llm:r2",
"llm_tier": "medium",
"llm_total": 15,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "added_system_contracts",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "modified_precompiles",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "new_fork_activation_mechanism",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "performance_risks",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "security_risks",
"llm": 1
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "cross_eip_interactions",
"llm": 1
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7668:r2": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 19,
"major": 3,
"minor": 6
},
"confounds": null,
"delta": 3,
"eip": 7668,
"fork": "hegota",
"human_assessment_id": "hegota:7668:human:r2",
"human_tier": "low",
"human_total": 7,
"id": "hegota:7668:r2",
"largest_disagreements": [
"encoding_changes_rlp_ssz",
"new_invariant_on_pre_existing_tests",
"new_test_framework_primitives",
"patterns_affecting_pre_existing_tests",
"edge_boundary_conditions"
],
"llm_assessment_id": "hegota:7668:llm:r2",
"llm_tier": "low",
"llm_total": 10,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "edge_boundary_conditions",
"llm": 1
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "block_syncing_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "performance_risks",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "security_risks",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "cross_eip_interactions",
"llm": 0
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7709:r2": {
"absolute_delta": 3,
"agreement_counts": {
"exact": 20,
"major": 1,
"minor": 7
},
"confounds": null,
"delta": 3,
"eip": 7709,
"fork": "hegota",
"human_assessment_id": "hegota:7709:human:r2",
"human_tier": "medium",
"human_total": 17,
"id": "hegota:7709:r2",
"largest_disagreements": [
"modified_opcodes",
"state_access_ordering_within_opcode_execution",
"patterns_affecting_pre_existing_tests",
"new_test_framework_primitives",
"edge_boundary_conditions"
],
"llm_assessment_id": "hegota:7709:llm:r2",
"llm_tier": "medium",
"llm_total": 20,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "state_access_ordering_within_opcode_execution",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "new_invariant_on_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "modified_system_contracts",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "security_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7819:r2": {
"absolute_delta": 1,
"agreement_counts": {
"exact": 24,
"major": 1,
"minor": 3
},
"confounds": null,
"delta": -1,
"eip": 7819,
"fork": "hegota",
"human_assessment_id": "hegota:7819:human:r2",
"human_tier": "medium",
"human_total": 22,
"id": "hegota:7819:r2",
"largest_disagreements": [
"state_gas_accounting_changes",
"new_evm_gas_refund",
"new_test_framework_primitives",
"security_risks"
],
"llm_assessment_id": "hegota:7819:llm:r2",
"llm_tier": "medium",
"llm_total": 21,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "evm_gas_rule_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "state_access_ordering_within_opcode_execution",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "new_evm_gas_refund",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "added_opcodes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "performance_risks",
"llm": 1
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "security_risks",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7862:r2": {
"absolute_delta": 5,
"agreement_counts": {
"exact": 21,
"major": 4,
"minor": 3
},
"confounds": null,
"delta": -5,
"eip": 7862,
"fork": "hegota",
"human_assessment_id": "hegota:7862:human:r2",
"human_tier": "medium",
"human_total": 19,
"id": "hegota:7862:r2",
"largest_disagreements": [
"new_invariant_on_pre_existing_tests",
"new_test_framework_primitives",
"transition_tool_interface_changes",
"security_risks",
"edge_boundary_conditions"
],
"llm_assessment_id": "hegota:7862:llm:r2",
"llm_tier": "medium",
"llm_total": 14,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "major",
"delta": -3,
"human": 3,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -3,
"human": 3,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "block_syncing_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "security_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "cross_eip_interactions",
"llm": 1
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7906:r2": {
"absolute_delta": 5,
"agreement_counts": {
"exact": 22,
"major": 3,
"minor": 3
},
"confounds": null,
"delta": 5,
"eip": 7906,
"fork": "hegota",
"human_assessment_id": "hegota:7906:human:r2",
"human_tier": "high",
"human_total": 23,
"id": "hegota:7906:r2",
"largest_disagreements": [
"evm_gas_rule_changes",
"patterns_affecting_pre_existing_tests",
"new_test_framework_primitives",
"performance_risks",
"security_risks"
],
"llm_assessment_id": "hegota:7906:llm:r2",
"llm_tier": "high",
"llm_total": 28,
"rows": [
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "evm_gas_rule_changes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "state_access_ordering_within_opcode_execution",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "added_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "security_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 4,
"id": "cross_eip_interactions",
"llm": 4
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:7923:r2": {
"absolute_delta": 8,
"agreement_counts": {
"exact": 22,
"major": 5,
"minor": 1
},
"confounds": null,
"delta": 8,
"eip": 7923,
"fork": "hegota",
"human_assessment_id": "hegota:7923:human:r2",
"human_tier": "medium",
"human_total": 15,
"id": "hegota:7923:r2",
"largest_disagreements": [
"new_test_framework_primitives",
"modified_opcodes",
"unspecified_behavior_requiring_cross_client_consensus",
"security_risks",
"cross_eip_interactions"
],
"llm_assessment_id": "hegota:7923:llm:r2",
"llm_tier": "high",
"llm_total": 23,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "evm_gas_rule_changes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -3,
"human": 3,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "security_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:8115:r2": {
"absolute_delta": 6,
"agreement_counts": {
"exact": 21,
"major": 2,
"minor": 5
},
"confounds": null,
"delta": 6,
"eip": 8115,
"fork": "hegota",
"human_assessment_id": "hegota:8115:human:r2",
"human_tier": "low",
"human_total": 10,
"id": "hegota:8115:r2",
"largest_disagreements": [
"performance_risks",
"edge_boundary_conditions",
"evm_gas_rule_changes",
"transition_tool_interface_changes",
"new_test_framework_primitives"
],
"llm_assessment_id": "hegota:8115:llm:r2",
"llm_tier": "medium",
"llm_total": 16,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "security_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:8146:r2": {
"absolute_delta": 1,
"agreement_counts": {
"exact": 24,
"major": 3,
"minor": 1
},
"confounds": null,
"delta": 1,
"eip": 8146,
"fork": "hegota",
"human_assessment_id": "hegota:8146:human:r2",
"human_tier": "medium",
"human_total": 19,
"id": "hegota:8146:r2",
"largest_disagreements": [
"new_invariant_on_pre_existing_tests",
"new_test_framework_primitives",
"performance_risks",
"patterns_affecting_pre_existing_tests"
],
"llm_assessment_id": "hegota:8146:llm:r2",
"llm_tier": "medium",
"llm_total": 20,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 3,
"id": "new_test_framework_primitives",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "engine_api_changes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "security_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:8188:r2": {
"absolute_delta": 8,
"agreement_counts": {
"exact": 18,
"major": 4,
"minor": 6
},
"confounds": null,
"delta": 8,
"eip": 8188,
"fork": "hegota",
"human_assessment_id": "hegota:8188:human:r2",
"human_tier": "medium",
"human_total": 18,
"id": "hegota:8188:r2",
"largest_disagreements": [
"modified_opcodes",
"encoding_changes_rlp_ssz",
"patterns_affecting_pre_existing_tests",
"unspecified_behavior_requiring_cross_client_consensus",
"edge_boundary_conditions"
],
"llm_assessment_id": "hegota:8188:llm:r2",
"llm_tier": "high",
"llm_total": 26,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "state_gas_accounting_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "new_invariant_on_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "transition_tool_interface_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "modified_system_contracts",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "major",
"delta": -3,
"human": 3,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "security_risks",
"llm": 2
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:8200:r2": {
"absolute_delta": 6,
"agreement_counts": {
"exact": 19,
"major": 1,
"minor": 8
},
"confounds": null,
"delta": 6,
"eip": 8200,
"fork": "hegota",
"human_assessment_id": "hegota:8200:human:r2",
"human_tier": "medium",
"human_total": 22,
"id": "hegota:8200:r2",
"largest_disagreements": [
"cross_eip_interactions",
"evm_gas_rule_changes",
"new_invariant_on_pre_existing_tests",
"new_test_framework_primitives",
"cryptography"
],
"llm_assessment_id": "hegota:8200:llm:r2",
"llm_tier": "high",
"llm_total": 28,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "cryptography",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "added_system_contracts",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "modified_precompiles",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "new_fork_activation_mechanism",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "security_risks",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 2,
"id": "cross_eip_interactions",
"llm": 4
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:8250:r2": {
"absolute_delta": 20,
"agreement_counts": {
"exact": 14,
"major": 6,
"minor": 8
},
"confounds": null,
"delta": 20,
"eip": 8250,
"fork": "hegota",
"human_assessment_id": "hegota:8250:human:r2",
"human_tier": "medium",
"human_total": 22,
"id": "hegota:8250:r2",
"largest_disagreements": [
"modified_opcodes",
"encoding_changes_rlp_ssz",
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"block_syncing_changes"
],
"llm_assessment_id": "hegota:8250:llm:r2",
"llm_tier": "high",
"llm_total": 42,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "evm_gas_rule_changes",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "transition_tool_interface_changes",
"llm": 3
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "new_test_framework_primitives",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "block_syncing_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "added_system_contracts",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "modified_opcodes",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "new_fork_activation_mechanism",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "security_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:8272:r2": {
"absolute_delta": 10,
"agreement_counts": {
"exact": 16,
"major": 6,
"minor": 6
},
"confounds": null,
"delta": 10,
"eip": 8272,
"fork": "hegota",
"human_assessment_id": "hegota:8272:human:r2",
"human_tier": "medium",
"human_total": 14,
"id": "hegota:8272:r2",
"largest_disagreements": [
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"patterns_affecting_pre_existing_tests",
"new_or_modified_transaction_validity_mechanisms",
"new_fork_activation_mechanism"
],
"llm_assessment_id": "hegota:8272:llm:r2:hegota-2026-09-16-90194cf-eip-8272-v2",
"llm_tier": "high",
"llm_total": 24,
"rows": [
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "added_system_contracts",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "major",
"delta": -2,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "new_fork_activation_mechanism",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "security_risks",
"llm": 3
},
{
"agreement": "major",
"delta": 3,
"human": 0,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:8279:r2": {
"absolute_delta": 7,
"agreement_counts": {
"exact": 21,
"major": 1,
"minor": 6
},
"confounds": null,
"delta": 7,
"eip": 8279,
"fork": "hegota",
"human_assessment_id": "hegota:8279:human:r2",
"human_tier": "medium",
"human_total": 22,
"id": "hegota:8279:r2",
"largest_disagreements": [
"cross_eip_interactions",
"state_access_ordering_within_opcode_execution",
"new_evm_gas_refund",
"patterns_affecting_pre_existing_tests",
"new_test_framework_primitives"
],
"llm_assessment_id": "hegota:8279:llm:r2",
"llm_tier": "high",
"llm_total": 29,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "evm_gas_rule_changes",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "state_access_ordering_within_opcode_execution",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "new_evm_gas_refund",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "security_risks",
"llm": 3
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "major",
"delta": 3,
"human": 3,
"id": "cross_eip_interactions",
"llm": 6
}
],
"rubric_revision": 2,
"tier_agreement": false
},
"hegota:8304:r2": {
"absolute_delta": 4,
"agreement_counts": {
"exact": 22,
"major": 2,
"minor": 4
},
"confounds": null,
"delta": 4,
"eip": 8304,
"fork": "hegota",
"human_assessment_id": "hegota:8304:human:r2",
"human_tier": "high",
"human_total": 26,
"id": "hegota:8304:r2",
"largest_disagreements": [
"patterns_affecting_pre_existing_tests",
"cross_eip_interactions",
"evm_gas_rule_changes",
"new_invariant_on_pre_existing_tests",
"new_test_framework_primitives"
],
"llm_assessment_id": "hegota:8304:llm:r2",
"llm_tier": "high",
"llm_total": 30,
"rows": [
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "patterns_affecting_pre_existing_tests",
"llm": 3
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "new_invariant_on_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "transition_tool_interface_changes",
"llm": 2
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "new_test_framework_primitives",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "cryptography",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "added_system_contracts",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_system_contracts",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "new_fork_activation_mechanism",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "performance_risks",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "security_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 3
},
{
"agreement": "major",
"delta": 2,
"human": 1,
"id": "cross_eip_interactions",
"llm": 3
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:8368:r2": {
"absolute_delta": 4,
"agreement_counts": {
"exact": 21,
"major": 2,
"minor": 5
},
"confounds": null,
"delta": -4,
"eip": 8368,
"fork": "hegota",
"human_assessment_id": "hegota:8368:human:r2",
"human_tier": "medium",
"human_total": 16,
"id": "hegota:8368:r2",
"largest_disagreements": [
"patterns_affecting_pre_existing_tests",
"cross_eip_interactions",
"edge_boundary_conditions",
"modified_system_contracts",
"performance_risks"
],
"llm_assessment_id": "hegota:8368:llm:r2",
"llm_tier": "medium",
"llm_total": 12,
"rows": [
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "evm_gas_rule_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 1,
"id": "state_gas_accounting_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "major",
"delta": -3,
"human": 4,
"id": "patterns_affecting_pre_existing_tests",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 2,
"id": "edge_boundary_conditions",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "modified_system_contracts",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": 1,
"human": 1,
"id": "security_risks",
"llm": 2
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "major",
"delta": -2,
"human": 4,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": true
},
"hegota:8372:r2": {
"absolute_delta": 1,
"agreement_counts": {
"exact": 23,
"major": 2,
"minor": 3
},
"confounds": null,
"delta": -1,
"eip": 8372,
"fork": "hegota",
"human_assessment_id": "hegota:8372:human:r2",
"human_tier": "medium",
"human_total": 20,
"id": "hegota:8372:r2",
"largest_disagreements": [
"evm_gas_rule_changes",
"performance_risks",
"patterns_affecting_pre_existing_tests",
"new_test_framework_primitives",
"modified_system_contracts"
],
"llm_assessment_id": "hegota:8372:llm:r2",
"llm_tier": "medium",
"llm_total": 19,
"rows": [
{
"agreement": "major",
"delta": -2,
"human": 3,
"id": "evm_gas_rule_changes",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "state_access_ordering_within_opcode_execution",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "blob_gas_accounting_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "state_gas_accounting_changes",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_evm_gas_refund",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 3,
"id": "patterns_affecting_pre_existing_tests",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_invariant_on_pre_existing_tests",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "transition_tool_interface_changes",
"llm": 0
},
{
"agreement": "minor",
"delta": -1,
"human": 1,
"id": "new_test_framework_primitives",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "cryptography",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 3,
"id": "edge_boundary_conditions",
"llm": 3
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "block_syncing_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "engine_api_changes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_system_contracts",
"llm": 0
},
{
"agreement": "minor",
"delta": 1,
"human": 0,
"id": "modified_system_contracts",
"llm": 1
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_opcodes",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "added_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "modified_precompiles",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "encoding_changes_rlp_ssz",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_transaction_types",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_block_header_fields",
"llm": 0
},
{
"agreement": "exact",
"delta": 0,
"human": 0,
"id": "new_fork_activation_mechanism",
"llm": 0
},
{
"agreement": "major",
"delta": 2,
"human": 0,
"id": "performance_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "security_risks",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"llm": 2
},
{
"agreement": "exact",
"delta": 0,
"human": 2,
"id": "cross_eip_interactions",
"llm": 2
}
],
"rubric_revision": 2,
"tier_agreement": true
}
},
"criteria": [
{
"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."
},
"definition_present": true,
"id": "evm_gas_rule_changes",
"label": "EVM Gas rule changes",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "New EVM gas accounting rules",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "state_access_ordering_within_opcode_execution",
"label": "State-access ordering within opcode execution",
"notes": [
"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."
],
"rubric_revisions": [
2
],
"short_definition": "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.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "blob_gas_accounting_changes",
"label": "Blob gas accounting changes",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "New Blob gas accounting rules which potentially affect pre-existing tests",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "state_gas_accounting_changes",
"label": "State gas accounting changes",
"notes": [
"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."
],
"rubric_revisions": [
2
],
"short_definition": "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.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "new_evm_gas_refund",
"label": "New EVM gas refund",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "New gas-refund mechanism",
"uncapped": false
},
{
"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.)."
},
"definition_present": true,
"id": "patterns_affecting_pre_existing_tests",
"label": "Patterns affecting pre-existing tests",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Implements a new validation mechanism or rule that translates in reworking pre-existing tests",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "new_invariant_on_pre_existing_tests",
"label": "New invariant on pre-existing tests",
"notes": [
"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."
],
"rubric_revisions": [
2
],
"short_definition": "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.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "transition_tool_interface_changes",
"label": "Transition-tool interface changes",
"notes": [
"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."
],
"rubric_revisions": [
1,
2
],
"short_definition": "Modifies or adds new fields to the transition tool interface.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "new_test_framework_primitives",
"label": "New test-framework primitives",
"notes": [],
"rubric_revisions": [
2
],
"short_definition": "Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "cryptography",
"label": "Cryptography",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "edge_boundary_conditions",
"label": "Edge/boundary conditions",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Feature contains edge/boundary conditions.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "block_syncing_changes",
"label": "Block syncing changes",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Modifies block RLP validation mechanisms that require test client syncing.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "engine_api_changes",
"label": "Engine API changes",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces new fields to the Engine API directives",
"uncapped": false
},
{
"anchors": {},
"definition_present": false,
"id": "engine_api_encoding_changes",
"label": "Engine API encoding changes",
"notes": [],
"rubric_revisions": [
1
],
"short_definition": "Engine API encoding changes (the revision-1 template defines no anchor text for this row).",
"uncapped": false
},
{
"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)."
},
"definition_present": true,
"id": "added_system_contracts",
"label": "Added system contracts",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces new system contract, stateful or not",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "modified_system_contracts",
"label": "Modified system contracts",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Modifies pre-existing system contracts",
"uncapped": false
},
{
"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)."
},
"definition_present": true,
"id": "added_opcodes",
"label": "Added opcodes",
"notes": [
"Cryptography opcodes are not considered complex by default. Refer to the \"Cryptography\" section for a separate assessment."
],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces new opcodes",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "modified_opcodes",
"label": "Modified opcodes",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Modifies pre-existing opcodes",
"uncapped": false
},
{
"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)."
},
"definition_present": true,
"id": "added_precompiles",
"label": "Added precompiles",
"notes": [
"Cryptography precompiles are not considered complex by default. Refer to the \"Cryptography\" for a separate assessment."
],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces new precompiles",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "modified_precompiles",
"label": "Modified precompiles",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Modifies pre-existing precompiles logic or gas-accounting",
"uncapped": false
},
{
"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)."
},
"definition_present": true,
"id": "encoding_changes_rlp_ssz",
"label": "Encoding changes (RLP/SSZ)",
"notes": [
"\"Interfaces level\" includes the Engine API. Score an Engine API encoding change (e.g. JSON -> SSZ) here."
],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces encoding changes at the transaction/block/interfaces level",
"uncapped": false
},
{
"anchors": {
"0": "No new transaction types are introduced.",
"3": "A new transaction type is introduced."
},
"definition_present": true,
"id": "new_transaction_types",
"label": "New transaction types",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces a new transaction type",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "new_or_modified_transaction_validity_mechanisms",
"label": "New or modified transaction validity mechanisms",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Creates new or modifies pre-existing transaction types' validation mechanisms",
"uncapped": false
},
{
"anchors": {
"0": "No new block or header fields are introduced.",
"3": "A new block or header field is introduced."
},
"definition_present": true,
"id": "new_block_header_fields",
"label": "New block / header fields",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces new block or block header fields",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "new_fork_activation_mechanism",
"label": "New fork activation mechanism",
"notes": [
"Initialization of new internal variable is not considered a modification."
],
"rubric_revisions": [
1,
2
],
"short_definition": "Modifies state, internal variables, or similar, at the fork activation block",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "performance_risks",
"label": "Performance risks",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces or modifies mechanisms and requires performance validation.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "security_risks",
"label": "Security risks",
"notes": [],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"label": "Unspecified behavior requiring cross-client consensus",
"notes": [
"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."
],
"rubric_revisions": [
2
],
"short_definition": "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.",
"uncapped": false
},
{
"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."
},
"definition_present": true,
"id": "cross_eip_interactions",
"label": "Cross-EIP interactions",
"notes": [
"+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."
],
"rubric_revisions": [
1,
2
],
"short_definition": "Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.",
"uncapped": true
}
],
"eips": [
{
"default_fork": "cancun",
"eip": 1153,
"forks": [
"cancun"
],
"occurrences": [
{
"assessment_ids": [
"cancun:1153:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "cancun:1153:llm:r2",
"eip": 1153,
"fork": "cancun",
"fork_name": "Cancun / Dencun",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "cancun:1153",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2022-12-07T18:16:53Z",
"assessment_id": "cancun:1153:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2022-12-08",
"score": 15,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Transient storage opcodes"
}
],
"route": "eips/1153/",
"title": "Transient storage opcodes"
},
{
"default_fork": "hegota",
"eip": 2488,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:2488:llm:r2",
"hegota:2488:human:r2"
],
"comparison_ids": [
"hegota:2488:r2"
],
"default_assessment_id": "hegota:2488:llm:r2",
"eip": 2488,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:2488:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 13,
"source_record": {
"commit": "db669a2c21a168ced78bd4de56db3870f1ac0c58",
"content_sha256": "66c8591d137a8d41fff1dd0af5d8f822d8ef11f418c9261f648e8045125397c1",
"git_blob_sha": "a62792dae10fa120cbde67976efd7739e642da8c",
"immutable_url": "https://github.com/ethspecs/pm/blob/db669a2c21a168ced78bd4de56db3870f1ac0c58/complexity_assessments/EIPs/EIP-2488.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-2488.md",
"pull_request": {
"draft": false,
"number": 114,
"title": "Add EIP-2488 complexity assessment",
"updated_at": "2026-08-18T16:56:16Z",
"url": "https://github.com/ethspecs/pm/pull/114"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:2488",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:2488:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 10,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Deprecate the CALLCODE opcode"
}
],
"route": "eips/2488/",
"title": "Deprecate the CALLCODE opcode"
},
{
"default_fork": "prague",
"eip": 2537,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:2537:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:2537:llm:r2",
"eip": 2537,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:2537",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2023-06-22T22:51:34Z",
"assessment_id": "prague:2537:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-01-18",
"score": 16,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Precompile for BLS12-381 curve operations"
}
],
"route": "eips/2537/",
"title": "Precompile for BLS12-381 curve operations"
},
{
"default_fork": "amsterdam",
"eip": 2780,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:2780:llm:r2",
"amsterdam:2780:llm:r1",
"amsterdam:2780:human:r1"
],
"comparison_ids": [
"amsterdam:2780:r1"
],
"default_assessment_id": "amsterdam:2780:llm:r2",
"eip": 2780,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:2780:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 13,
"source_record": {
"commit": "d49a44fe77adadea547a939e4e473a949e7b5a99",
"committed_at": "2025-11-05T23:48:51Z",
"content_sha256": "057e21adfca9f56416c7d699ed21b1d91d2a0cd7fd646028ddad62919696e144",
"git_blob_sha": "e31e27bde7d154975dae24f29929e540c88f014a",
"immutable_url": "https://github.com/ethspecs/pm/blob/d49a44fe77adadea547a939e4e473a949e7b5a99/complexity_assessments/EIPs/EIP-2780.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-2780.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "medium"
},
"id": "amsterdam:2780",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-09-08T06:11:31Z",
"assessment_id": "amsterdam:2780:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-09-12T13:12:54Z",
"score": 25,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Resource-based intrinsic transaction gas"
}
],
"route": "eips/2780/",
"title": "Resource-based intrinsic transaction gas"
},
{
"default_fork": "prague",
"eip": 2935,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:2935:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:2935:llm:r2",
"eip": 2935,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:2935",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2022-05-06T07:29:09Z",
"assessment_id": "prague:2935:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-04-11",
"score": 24,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Serve historical block hashes from state"
}
],
"route": "eips/2935/",
"title": "Serve historical block hashes from state"
},
{
"default_fork": "hegota",
"eip": 3298,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:3298:llm:r2",
"hegota:3298:human:r2"
],
"comparison_ids": [
"hegota:3298:r2"
],
"default_assessment_id": "hegota:3298:llm:r2",
"eip": 3298,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:3298:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 6,
"source_record": {
"commit": "6672c60213099cd1726af93a556963767229ff5a",
"content_sha256": "75b5454cd77c5fc531a4ce4a35b03a574d2b133b0c3fde8fc9224f58dac5aceb",
"git_blob_sha": "760dabfde14231bcf4259f938d35a44a23c9df60",
"immutable_url": "https://github.com/ethspecs/pm/blob/6672c60213099cd1726af93a556963767229ff5a/complexity_assessments/EIPs/EIP-3298.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-3298.md",
"pull_request": {
"draft": false,
"number": 115,
"title": "Add EIP-3298 complexity assessment",
"updated_at": "2026-08-18T20:29:53Z",
"url": "https://github.com/ethspecs/pm/pull/115"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "low"
},
"id": "hegota:3298",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:3298:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 12,
"status": "complete",
"tier": "medium",
"under_specified": false
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Remove storage-clear refund and refund cap"
}
],
"route": "eips/3298/",
"title": "Remove storage-clear refund and refund cap"
},
{
"default_fork": "shanghai",
"eip": 3651,
"forks": [
"shanghai"
],
"occurrences": [
{
"assessment_ids": [
"shanghai:3651:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "shanghai:3651:llm:r2",
"eip": 3651,
"fork": "shanghai",
"fork_name": "Shanghai / Shapella",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "shanghai:3651",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2022-01-30T01:15:44Z",
"assessment_id": "shanghai:3651:llm:r2",
"confidence": "high",
"information_cutoff_at": "2022-03-04",
"score": 6,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Warm COINBASE"
}
],
"route": "eips/3651/",
"title": "Warm COINBASE"
},
{
"default_fork": "shanghai",
"eip": 3855,
"forks": [
"shanghai"
],
"occurrences": [
{
"assessment_ids": [
"shanghai:3855:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "shanghai:3855:llm:r2",
"eip": 3855,
"fork": "shanghai",
"fork_name": "Shanghai / Shapella",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "shanghai:3855",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2021-09-22T22:15:14Z",
"assessment_id": "shanghai:3855:llm:r2",
"confidence": "high",
"information_cutoff_at": "2022-02-04",
"score": 6,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "PUSH0 instruction"
}
],
"route": "eips/3855/",
"title": "PUSH0 instruction"
},
{
"default_fork": "shanghai",
"eip": 3860,
"forks": [
"shanghai"
],
"occurrences": [
{
"assessment_ids": [
"shanghai:3860:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "shanghai:3860:llm:r2",
"eip": 3860,
"fork": "shanghai",
"fork_name": "Shanghai / Shapella",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "shanghai:3860",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2022-02-03T17:32:59Z",
"assessment_id": "shanghai:3860:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2022-02-04",
"score": 23,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Limit and meter initcode"
}
],
"route": "eips/3860/",
"title": "Limit and meter initcode"
},
{
"default_fork": "hegota",
"eip": 4758,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:4758:llm:r2",
"hegota:4758:human:r2"
],
"comparison_ids": [
"hegota:4758:r2"
],
"default_assessment_id": "hegota:4758:llm:r2",
"eip": 4758,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:4758:human:r2",
"note": null,
"other_candidates": [
{
"availability": "open_pull_request",
"duplicates_preferred_scores": false,
"immutable_url": "https://github.com/ethspecs/pm/blob/7bdc9e9829d47ac2f7520f23e0692e099a51e95f/complexity_assessments/EIPs/EIP-4758.md",
"parse_state": "complete",
"pull_request": {
"draft": false,
"number": 73,
"title": "Add complexity assessments",
"url": "https://github.com/ethspecs/pm/pull/73"
},
"recomputed_total": 4,
"rubric_revision": 1
}
],
"rubric_revision": 2,
"score": 8,
"source_record": {
"commit": "87fbde51cd4dbe50f3f594e55217384549fce93e",
"content_sha256": "5a0bbd26d962cccf9e3fa8b8eb4e9f7292be6048e07caf4194fc978f5cddba09",
"git_blob_sha": "524925b9204846028697c832304f63a3d591c8b6",
"immutable_url": "https://github.com/ethspecs/pm/blob/87fbde51cd4dbe50f3f594e55217384549fce93e/complexity_assessments/EIPs/EIP-4758.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-4758.md",
"pull_request": {
"draft": false,
"number": 105,
"title": "Add EIP-4758 complexity assessment",
"updated_at": "2026-08-17T13:21:13Z",
"url": "https://github.com/ethspecs/pm/pull/105"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "low"
},
"id": "hegota:4758",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:4758:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 14,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Deactivate SELFDESTRUCT"
}
],
"route": "eips/4758/",
"title": "Deactivate SELFDESTRUCT"
},
{
"default_fork": "cancun",
"eip": 4788,
"forks": [
"cancun"
],
"occurrences": [
{
"assessment_ids": [
"cancun:4788:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "cancun:4788:llm:r2",
"eip": 4788,
"fork": "cancun",
"fork_name": "Cancun / Dencun",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "cancun:4788",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2023-04-13T13:59:33Z",
"assessment_id": "cancun:4788:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2023-04-27",
"score": 38,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Beacon block root in the EVM"
}
],
"route": "eips/4788/",
"title": "Beacon block root in the EVM"
},
{
"default_fork": "cancun",
"eip": 4844,
"forks": [
"cancun"
],
"occurrences": [
{
"assessment_ids": [
"cancun:4844:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "cancun:4844:llm:r2",
"eip": 4844,
"fork": "cancun",
"fork_name": "Cancun / Dencun",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "cancun:4844",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2022-12-05T12:02:25Z",
"assessment_id": "cancun:4844:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2022-12-08",
"score": 48,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Shard Blob Transactions"
}
],
"route": "eips/4844/",
"title": "Shard Blob Transactions"
},
{
"default_fork": "shanghai",
"eip": 4895,
"forks": [
"shanghai"
],
"occurrences": [
{
"assessment_ids": [
"shanghai:4895:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "shanghai:4895:llm:r2",
"eip": 4895,
"fork": "shanghai",
"fork_name": "Shanghai / Shapella",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "shanghai:4895",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2022-03-11T12:28:57Z",
"assessment_id": "shanghai:4895:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2022-03-11T12:28:57Z",
"score": 30,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Beacon chain push withdrawals as operations"
}
],
"route": "eips/4895/",
"title": "Beacon chain push withdrawals as operations"
},
{
"default_fork": "cancun",
"eip": 5656,
"forks": [
"cancun"
],
"occurrences": [
{
"assessment_ids": [
"cancun:5656:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "cancun:5656:llm:r2",
"eip": 5656,
"fork": "cancun",
"fork_name": "Cancun / Dencun",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "cancun:5656",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2023-05-11T19:30:56Z",
"assessment_id": "cancun:5656:llm:r2",
"confidence": "high",
"information_cutoff_at": "2023-05-25",
"score": 9,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "MCOPY - Memory copying instruction"
}
],
"route": "eips/5656/",
"title": "MCOPY - Memory copying instruction"
},
{
"default_fork": "hegota",
"eip": 5920,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:5920:llm:r2",
"hegota:5920:human:r2"
],
"comparison_ids": [
"hegota:5920:r2"
],
"default_assessment_id": "hegota:5920:llm:r2",
"eip": 5920,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:5920:human:r2",
"note": null,
"other_candidates": [
{
"availability": "merged",
"duplicates_preferred_scores": false,
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/complexity_assessments/EIPs/EIP-5920.md",
"parse_state": "complete",
"pull_request": null,
"recomputed_total": 8,
"rubric_revision": 1
},
{
"availability": "open_draft_pull_request",
"duplicates_preferred_scores": true,
"immutable_url": "https://github.com/ethspecs/pm/blob/0330c11ba99afc90e7c1afba6bcb0237bcf7d4d5/complexity_assessments/EIPs/EIP-5920.md",
"parse_state": "complete",
"pull_request": {
"draft": true,
"number": 122,
"title": "Rename checklist \"anchors\" to \"criteria\"",
"url": "https://github.com/ethspecs/pm/pull/122"
},
"recomputed_total": 8,
"rubric_revision": 1
}
],
"rubric_revision": 2,
"score": 14,
"source_record": {
"commit": "c2b40ca1b8b4529ecee5bc90581e7e76a4b47a68",
"content_sha256": "6f9c855fe336e454e7e2e51c906e84698060f662d85e595a7c964d47ebe82324",
"git_blob_sha": "ff44f79881510d7940b6804fdc710672b49608cc",
"immutable_url": "https://github.com/ethspecs/pm/blob/c2b40ca1b8b4529ecee5bc90581e7e76a4b47a68/complexity_assessments/EIPs/EIP-5920.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-5920.md",
"pull_request": {
"draft": false,
"number": 116,
"title": "Update EIP-5920 complexity assessment to checklist revision 2",
"updated_at": "2026-08-18T21:00:22Z",
"url": "https://github.com/ethspecs/pm/pull/116"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:5920",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:5920:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 16,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "PAY opcode"
}
],
"route": "eips/5920/",
"title": "PAY opcode"
},
{
"default_fork": "shanghai",
"eip": 6049,
"forks": [
"shanghai"
],
"occurrences": [
{
"assessment_ids": [
"shanghai:6049:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "shanghai:6049:llm:r2",
"eip": 6049,
"fork": "shanghai",
"fork_name": "Shanghai / Shapella",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "shanghai:6049",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2022-12-20T18:17:44Z",
"assessment_id": "shanghai:6049:llm:r2",
"confidence": "high",
"information_cutoff_at": "2023-01-19",
"score": 3,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "Deprecate SELFDESTRUCT"
}
],
"route": "eips/6049/",
"title": "Deprecate SELFDESTRUCT"
},
{
"default_fork": "prague",
"eip": 6110,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:6110:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:6110:llm:r2",
"eip": 6110,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:6110",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2023-10-12T10:07:31Z",
"assessment_id": "prague:6110:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-01-18",
"score": 36,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Supply validator deposits on chain"
}
],
"route": "eips/6110/",
"title": "Supply validator deposits on chain"
},
{
"default_fork": "cancun",
"eip": 6780,
"forks": [
"cancun"
],
"occurrences": [
{
"assessment_ids": [
"cancun:6780:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "cancun:6780:llm:r2",
"eip": 6780,
"fork": "cancun",
"fork_name": "Cancun / Dencun",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "cancun:6780",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2023-03-28T20:27:21Z",
"assessment_id": "cancun:6780:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2023-03-30",
"score": 16,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "SELFDESTRUCT only in same transaction"
}
],
"route": "eips/6780/",
"title": "SELFDESTRUCT only in same transaction"
},
{
"default_fork": "prague",
"eip": 7002,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:7002:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7002:llm:r2",
"eip": 7002,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7002",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2023-06-29T14:13:35Z",
"assessment_id": "prague:7002:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-01-18",
"score": 38,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Execution layer triggerable withdrawals"
}
],
"route": "eips/7002/",
"title": "Execution layer triggerable withdrawals"
},
{
"default_fork": "prague",
"eip": 7251,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:7251:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7251:llm:r2",
"eip": 7251,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7251",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2024-01-31T02:41:25Z",
"assessment_id": "prague:7251:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-03-21",
"score": 19,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Increase the MAX_EFFECTIVE_BALANCE"
}
],
"route": "eips/7251/",
"title": "Increase the MAX_EFFECTIVE_BALANCE"
},
{
"default_fork": "cancun",
"eip": 7516,
"forks": [
"cancun"
],
"occurrences": [
{
"assessment_ids": [
"cancun:7516:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "cancun:7516:llm:r2",
"eip": 7516,
"fork": "cancun",
"fork_name": "Cancun / Dencun",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "cancun:7516",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2023-09-13T16:46:42Z",
"assessment_id": "cancun:7516:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2023-09-14",
"score": 9,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "BLOBBASEFEE opcode"
}
],
"route": "eips/7516/",
"title": "BLOBBASEFEE opcode"
},
{
"default_fork": "osaka",
"eip": 7594,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7594:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7594:llm:r2",
"eip": 7594,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7594",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2024-06-17T16:19:19Z",
"assessment_id": "osaka:7594:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-09-27T18:42:32Z",
"score": 24,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "PeerDAS - Peer Data Availability Sampling"
}
],
"route": "eips/7594/",
"title": "PeerDAS - Peer Data Availability Sampling"
},
{
"default_fork": "amsterdam",
"eip": 7610,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7610:llm:r2",
"amsterdam:7610:llm:r1",
"amsterdam:7610:human:r1"
],
"comparison_ids": [
"amsterdam:7610:r1"
],
"default_assessment_id": "amsterdam:7610:llm:r2",
"eip": 7610,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7610:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 7,
"source_record": {
"commit": "0a80baf1747d4fe9f0ee65446e3f70d06b01a8ba",
"committed_at": "2026-01-09T11:28:09Z",
"content_sha256": "ebca2ea04f8fbfff2242022fa5680acc97716c71c80111a621b9dd4def51608a",
"git_blob_sha": "d9250b95ed69fe6a0662e55d941cb375f3b00270",
"immutable_url": "https://github.com/ethspecs/pm/blob/0a80baf1747d4fe9f0ee65446e3f70d06b01a8ba/complexity_assessments/EIPs/EIP-7610.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7610.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "low"
},
"id": "amsterdam:7610",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2024-11-07T08:14:40Z",
"assessment_id": "amsterdam:7610:llm:r2",
"confidence": "high",
"information_cutoff_at": "2025-09-24T14:40:52Z",
"score": 9,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Revert creation in case of non-empty storage"
}
],
"route": "eips/7610/",
"title": "Revert creation in case of non-empty storage"
},
{
"default_fork": "prague",
"eip": 7623,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:7623:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7623:llm:r2",
"eip": 7623,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7623",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2024-04-03T06:16:54Z",
"assessment_id": "prague:7623:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-04-11",
"score": 16,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Increase calldata cost"
}
],
"route": "eips/7623/",
"title": "Increase calldata cost"
},
{
"default_fork": "osaka",
"eip": 7642,
"forks": [
"prague",
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"prague:7642:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7642:llm:r2",
"eip": 7642,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7642",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-04-17T21:24:29Z",
"assessment_id": "prague:7642:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-04-17T21:24:29Z",
"score": 14,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "eth/69 - history expiry and simpler receipts"
},
{
"assessment_ids": [
"osaka:7642:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7642:llm:r2",
"eip": 7642,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7642",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-01-08T16:54:23Z",
"assessment_id": "osaka:7642:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-02-21T16:21:57Z",
"score": 12,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "eth/69 - history expiry and simpler receipts"
}
],
"route": "eips/7642/",
"title": "eth/69 - history expiry and simpler receipts"
},
{
"default_fork": "hegota",
"eip": 7645,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7645:llm:r2",
"hegota:7645:human:r2"
],
"comparison_ids": [
"hegota:7645:r2"
],
"default_assessment_id": "hegota:7645:llm:r2",
"eip": 7645,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7645:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 8,
"source_record": {
"commit": "2f541d3e66f737d089c3a3e89707988637af2948",
"content_sha256": "ea15e0e024f426a7ef02284d2c13239f19716fdf6c56f3110182fa358016ffae",
"git_blob_sha": "3e6403a4b06ef577fecd83e870f54f48ae721187",
"immutable_url": "https://github.com/ethspecs/pm/blob/2f541d3e66f737d089c3a3e89707988637af2948/complexity_assessments/EIPs/EIP-7645.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7645.md",
"pull_request": {
"draft": false,
"number": 113,
"title": "Add EIP-7645 complexity assessment",
"updated_at": "2026-08-18T16:39:57Z",
"url": "https://github.com/ethspecs/pm/pull/113"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "low"
},
"id": "hegota:7645",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7645:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 11,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Alias ORIGIN to SENDER"
}
],
"route": "eips/7645/",
"title": "Alias ORIGIN to SENDER"
},
{
"default_fork": "hegota",
"eip": 7666,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7666:llm:r2",
"hegota:7666:human:r2"
],
"comparison_ids": [
"hegota:7666:r2"
],
"default_assessment_id": "hegota:7666:llm:r2",
"eip": 7666,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7666:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 12,
"source_record": {
"commit": "4a25f38a8f36442fdb10dcae447a51a85f82c7e8",
"content_sha256": "28cc3069dff9b777a277374637afd8c47c3c75b35f6c83ac8bc922888f9c8d44",
"git_blob_sha": "7e1838587c5e474282b381c5a899eab09fd3b0d3",
"immutable_url": "https://github.com/ethspecs/pm/blob/4a25f38a8f36442fdb10dcae447a51a85f82c7e8/complexity_assessments/EIPs/EIP-7666.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-7666.md",
"pull_request": {
"draft": true,
"number": 112,
"title": "Add EIP-7666 complexity assessment",
"updated_at": "2026-08-18T08:55:08Z",
"url": "https://github.com/ethspecs/pm/pull/112"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "medium"
},
"id": "hegota:7666",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7666:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 15,
"status": "complete",
"tier": "medium",
"under_specified": false
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "EVM-ify the identity precompile"
}
],
"route": "eips/7666/",
"title": "EVM-ify the identity precompile"
},
{
"default_fork": "hegota",
"eip": 7668,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7668:llm:r2",
"hegota:7668:human:r2"
],
"comparison_ids": [
"hegota:7668:r2"
],
"default_assessment_id": "hegota:7668:llm:r2",
"eip": 7668,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7668:human:r2",
"note": null,
"other_candidates": [
{
"availability": "merged",
"duplicates_preferred_scores": false,
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/complexity_assessments/EIPs/EIP-7668.md",
"parse_state": "complete",
"pull_request": null,
"recomputed_total": 2,
"rubric_revision": 1
},
{
"availability": "open_draft_pull_request",
"duplicates_preferred_scores": true,
"immutable_url": "https://github.com/ethspecs/pm/blob/0330c11ba99afc90e7c1afba6bcb0237bcf7d4d5/complexity_assessments/EIPs/EIP-7668.md",
"parse_state": "complete",
"pull_request": {
"draft": true,
"number": 122,
"title": "Rename checklist \"anchors\" to \"criteria\"",
"url": "https://github.com/ethspecs/pm/pull/122"
},
"recomputed_total": 2,
"rubric_revision": 1
}
],
"rubric_revision": 2,
"score": 7,
"source_record": {
"commit": "0125045895b5e3dab780afbf490a8d68c06abd1b",
"content_sha256": "6020f3af4efa29a99ef65eedfdd58b003ccb2ddfdc119db2763794d2cf0b3d89",
"git_blob_sha": "e0cc4d5614e274e0df403c26343be0a27f89461c",
"immutable_url": "https://github.com/ethspecs/pm/blob/0125045895b5e3dab780afbf490a8d68c06abd1b/complexity_assessments/EIPs/EIP-7668.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7668.md",
"pull_request": {
"draft": false,
"number": 118,
"title": "Update EIP-7668 complexity assessment to checklist revision 2",
"updated_at": "2026-08-18T23:06:30Z",
"url": "https://github.com/ethspecs/pm/pull/118"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "low"
},
"id": "hegota:7668",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7668:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 10,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Remove bloom filters"
}
],
"route": "eips/7668/",
"title": "Remove bloom filters"
},
{
"default_fork": "prague",
"eip": 7685,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:7685:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7685:llm:r2",
"eip": 7685,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7685",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2024-04-18T22:38:06Z",
"assessment_id": "prague:7685:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-04-25",
"score": 34,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "General purpose execution layer requests"
}
],
"route": "eips/7685/",
"title": "General purpose execution layer requests"
},
{
"default_fork": "prague",
"eip": 7691,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:7691:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7691:llm:r2",
"eip": 7691,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7691",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2024-12-18T19:05:43Z",
"assessment_id": "prague:7691:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-12-18T19:48:12Z",
"score": 16,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "Blob throughput increase"
}
],
"route": "eips/7691/",
"title": "Blob throughput increase"
},
{
"default_fork": "prague",
"eip": 7702,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:7702:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7702:llm:r2",
"eip": 7702,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7702",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2024-05-09T20:47:43Z",
"assessment_id": "prague:7702:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2024-05-23",
"score": 33,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Set Code for EOAs"
}
],
"route": "eips/7702/",
"title": "Set Code for EOAs"
},
{
"default_fork": "amsterdam",
"eip": 7708,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7708:llm:r2",
"amsterdam:7708:llm:r1",
"amsterdam:7708:human:r1"
],
"comparison_ids": [
"amsterdam:7708:r1"
],
"default_assessment_id": "amsterdam:7708:llm:r2",
"eip": 7708,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7708:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 9,
"source_record": {
"commit": "72a1fc653db7587eb37bd80eaf82f3e8e45727e3",
"committed_at": "2025-11-05T22:50:54Z",
"content_sha256": "a2652b18c2cf7fd9d197536f80880e0e448db66bf1e16170be0f6ddc54d35b41",
"git_blob_sha": "092e5bab2aa5317d14ff6832cc3b0371db773c3f",
"immutable_url": "https://github.com/ethspecs/pm/blob/72a1fc653db7587eb37bd80eaf82f3e8e45727e3/complexity_assessments/EIPs/EIP-7708.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7708.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "low"
},
"id": "amsterdam:7708",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-04-13T00:47:51Z",
"assessment_id": "amsterdam:7708:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-10-22T20:52:23Z",
"score": 19,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "ETH transfers emit a log"
}
],
"route": "eips/7708/",
"title": "ETH transfers emit a log"
},
{
"default_fork": "hegota",
"eip": 7709,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7709:llm:r2",
"hegota:7709:human:r2"
],
"comparison_ids": [
"hegota:7709:r2"
],
"default_assessment_id": "hegota:7709:llm:r2",
"eip": 7709,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7709:human:r2",
"note": null,
"other_candidates": [
{
"availability": "open_pull_request",
"duplicates_preferred_scores": false,
"immutable_url": "https://github.com/ethspecs/pm/blob/7bdc9e9829d47ac2f7520f23e0692e099a51e95f/complexity_assessments/EIPs/EIP-7709.md",
"parse_state": "complete",
"pull_request": {
"draft": false,
"number": 73,
"title": "Add complexity assessments",
"url": "https://github.com/ethspecs/pm/pull/73"
},
"recomputed_total": 4,
"rubric_revision": 1
}
],
"rubric_revision": 2,
"score": 17,
"source_record": {
"commit": "e75fc8b75e247b545d095a86de2ab939270c20e4",
"content_sha256": "5a2a2b3c930846de46187e053a0f5f748633a73fc0fceee56518a045cf53056d",
"git_blob_sha": "f9b1c0170d522549e86f70a5dcb5af5da821208c",
"immutable_url": "https://github.com/ethspecs/pm/blob/e75fc8b75e247b545d095a86de2ab939270c20e4/complexity_assessments/EIPs/EIP-7709.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7709.md",
"pull_request": {
"draft": false,
"number": 120,
"title": "Add EIP-7709 complexity assessment",
"updated_at": "2026-08-24T12:41:48Z",
"url": "https://github.com/ethspecs/pm/pull/120"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:7709",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7709:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 20,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Read BLOCKHASH from Storage and Update Cost"
}
],
"route": "eips/7709/",
"title": "Read BLOCKHASH from Storage and Update Cost"
},
{
"default_fork": "hegota",
"eip": 7716,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [],
"comparison_ids": [],
"default_assessment_id": null,
"eip": 7716,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:7716",
"layers": [
"consensus"
],
"llm": {
"assessed_revision_at": null,
"assessment_id": null,
"confidence": null,
"exclusion_kind": "consensus_only",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"rationale": "Changes Beacon State attestation-penalty accounting only and defines no execution-layer behavior.",
"score": null,
"status": "not_applicable",
"tier": null,
"under_specified": null
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Anti-correlation attestation penalties"
}
],
"route": "eips/7716/",
"title": "Anti-correlation attestation penalties"
},
{
"default_fork": "amsterdam",
"eip": 7778,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7778:llm:r2",
"amsterdam:7778:llm:r1",
"amsterdam:7778:human:r1"
],
"comparison_ids": [
"amsterdam:7778:r1"
],
"default_assessment_id": "amsterdam:7778:llm:r2",
"eip": 7778,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7778:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 10,
"source_record": {
"commit": "099b684c84c0a9f08578715a1c78369f1c51d1e6",
"committed_at": "2025-12-19T05:24:08Z",
"content_sha256": "d3c6080a3fba6143b2b007d51f3b34cbac824ef9d080ac5db9304390db172946",
"git_blob_sha": "459b3510b04d23cb099ecb5f1379a7b183eb407a",
"immutable_url": "https://github.com/ethspecs/pm/blob/099b684c84c0a9f08578715a1c78369f1c51d1e6/complexity_assessments/EIPs/EIP-7778.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7778.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "medium"
},
"id": "amsterdam:7778",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-09-03T08:03:05Z",
"assessment_id": "amsterdam:7778:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-09-03T20:52:20Z",
"score": 13,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Block Gas Accounting without Refunds"
}
],
"route": "eips/7778/",
"title": "Block Gas Accounting without Refunds"
},
{
"default_fork": "hegota",
"eip": 7805,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7805:llm:r2",
"hegota:7805:human:r1"
],
"comparison_ids": [],
"default_assessment_id": "hegota:7805:llm:r2",
"eip": 7805,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7805:human:r1",
"note": null,
"other_candidates": [
{
"availability": "open_draft_pull_request",
"duplicates_preferred_scores": true,
"immutable_url": "https://github.com/ethspecs/pm/blob/0330c11ba99afc90e7c1afba6bcb0237bcf7d4d5/complexity_assessments/EIPs/EIP-7805.md",
"parse_state": "complete",
"pull_request": {
"draft": true,
"number": 122,
"title": "Rename checklist \"anchors\" to \"criteria\"",
"url": "https://github.com/ethspecs/pm/pull/122"
},
"recomputed_total": 15,
"rubric_revision": 1
}
],
"rubric_revision": 1,
"score": 15,
"source_record": {
"branch": "main",
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"committed_at": "2026-01-12T14:16:48Z",
"content_sha256": "ed018ce5a7fc1f7d3439207f74e4964d1144c687cf881b17f307fa0dd20b2a3a",
"git_blob_sha": "b452b3c506b855dc72f2731ab8d832df71fe5b54",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/complexity_assessments/EIPs/EIP-7805.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7805.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "medium"
},
"id": "hegota:7805",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7805:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 20,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "SFI",
"title": "Fork-choice enforced Inclusion Lists (FOCIL)"
}
],
"route": "eips/7805/",
"title": "Fork-choice enforced Inclusion Lists (FOCIL)"
},
{
"default_fork": "hegota",
"eip": 7807,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7807:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:7807:llm:r2",
"eip": 7807,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:7807",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7807:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 34,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "SSZ execution blocks"
}
],
"route": "eips/7807/",
"title": "SSZ execution blocks"
},
{
"default_fork": "hegota",
"eip": 7819,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7819:llm:r2",
"hegota:7819:human:r2"
],
"comparison_ids": [
"hegota:7819:r2"
],
"default_assessment_id": "hegota:7819:llm:r2",
"eip": 7819,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7819:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 22,
"source_record": {
"commit": "664f62e0e0ac2db5426796bd76ffca420e491bf0",
"content_sha256": "7202736865a996ab705d8ecaecaed8b635aeba4422add03ea74bb18e48e5646b",
"git_blob_sha": "a34cb992641aba1c4db15cd39466d50ad056d359",
"immutable_url": "https://github.com/ethspecs/pm/blob/664f62e0e0ac2db5426796bd76ffca420e491bf0/complexity_assessments/EIPs/EIP-7819.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-7819.md",
"pull_request": {
"draft": true,
"number": 128,
"title": "Add EIP-7819 complexity assessment",
"updated_at": "2026-08-24T13:25:20Z",
"url": "https://github.com/ethspecs/pm/pull/128"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "medium"
},
"id": "hegota:7819",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7819:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 21,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "SETDELEGATE instruction"
}
],
"route": "eips/7819/",
"title": "SETDELEGATE instruction"
},
{
"default_fork": "osaka",
"eip": 7823,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7823:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7823:llm:r2",
"eip": 7823,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7823",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2024-11-26T17:33:25Z",
"assessment_id": "osaka:7823:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-01-23T23:05:03Z",
"score": 13,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Set upper bounds for MODEXP"
}
],
"route": "eips/7823/",
"title": "Set upper bounds for MODEXP"
},
{
"default_fork": "osaka",
"eip": 7825,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7825:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7825:llm:r2",
"eip": 7825,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7825",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2024-12-02T17:16:34Z",
"assessment_id": "osaka:7825:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-02-21T01:11:23Z",
"score": 8,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Transaction Gas Limit Cap"
}
],
"route": "eips/7825/",
"title": "Transaction Gas Limit Cap"
},
{
"default_fork": "prague",
"eip": 7840,
"forks": [
"prague"
],
"occurrences": [
{
"assessment_ids": [
"prague:7840:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "prague:7840:llm:r2",
"eip": 7840,
"fork": "prague",
"fork_name": "Prague / Pectra",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "prague:7840",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-01-15T16:24:59Z",
"assessment_id": "prague:7840:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-01-15T16:25:43Z",
"score": 8,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "Add blob schedule to EL config files"
}
],
"route": "eips/7840/",
"title": "Add blob schedule to EL config files"
},
{
"default_fork": "amsterdam",
"eip": 7843,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7843:llm:r2",
"amsterdam:7843:llm:r1",
"amsterdam:7843:human:r1"
],
"comparison_ids": [
"amsterdam:7843:r1"
],
"default_assessment_id": "amsterdam:7843:llm:r2",
"eip": 7843,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7843:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 7,
"source_record": {
"commit": "6b2c7cd0b1d59eda05cad78bdf4c2674250c5d47",
"committed_at": "2025-11-07T21:05:37Z",
"content_sha256": "5f036b6626bc7cb2b6d6c19d0604473df2cfef517f3160ebe3bc1939b9f3e638",
"git_blob_sha": "1bb42233b4bcd5d5ba3b5ad93e637096504cc488",
"immutable_url": "https://github.com/ethspecs/pm/blob/6b2c7cd0b1d59eda05cad78bdf4c2674250c5d47/complexity_assessments/EIPs/EIP-7843.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7843.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "low"
},
"id": "amsterdam:7843",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-05-20T16:23:34Z",
"assessment_id": "amsterdam:7843:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-06-09T07:29:29Z",
"score": 23,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "SLOTNUM opcode"
}
],
"route": "eips/7843/",
"title": "SLOTNUM opcode"
},
{
"default_fork": "hegota",
"eip": 7851,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7851:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:7851:llm:r2",
"eip": 7851,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:7851",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7851:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 23,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Code-Controlled EOA Delegation"
}
],
"route": "eips/7851/",
"title": "Code-Controlled EOA Delegation"
},
{
"default_fork": "hegota",
"eip": 7862,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7862:llm:r2",
"hegota:7862:human:r2"
],
"comparison_ids": [
"hegota:7862:r2"
],
"default_assessment_id": "hegota:7862:llm:r2",
"eip": 7862,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7862:human:r2",
"note": null,
"other_candidates": [
{
"availability": "open_pull_request",
"duplicates_preferred_scores": false,
"immutable_url": "https://github.com/ethspecs/pm/blob/042096dd3debf88e51204bbf341c35c8527f6228/complexity_assessments/EIPs/EIP-7862.md",
"parse_state": "complete",
"pull_request": {
"draft": false,
"number": 125,
"title": "Add EIP-8188 complexity assessment",
"url": "https://github.com/ethspecs/pm/pull/125"
},
"recomputed_total": 19,
"rubric_revision": 2
}
],
"rubric_revision": 2,
"score": 19,
"source_record": {
"commit": "1dc6a162915c5d1dba92ba64efa8d8bef9981bcb",
"content_sha256": "40f8fb876f968f42545bcde3f802e5f9eb45989df8a8ee720c2bcdf9fed3025c",
"git_blob_sha": "440aa59d0d7596a119a93e1c99fbd48a6cc174ed",
"immutable_url": "https://github.com/ethspecs/pm/blob/1dc6a162915c5d1dba92ba64efa8d8bef9981bcb/complexity_assessments/EIPs/EIP-7862.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7862.md",
"pull_request": {
"draft": false,
"number": 124,
"title": "Add EIP-7862 complexity assessment",
"updated_at": "2026-08-24T06:38:06Z",
"url": "https://github.com/ethspecs/pm/pull/124"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:7862",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7862:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 14,
"status": "complete",
"tier": "medium",
"under_specified": false
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Delayed State Root"
}
],
"route": "eips/7862/",
"title": "Delayed State Root"
},
{
"default_fork": "osaka",
"eip": 7883,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7883:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7883:llm:r2",
"eip": 7883,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7883",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-02-14T17:00:54Z",
"assessment_id": "osaka:7883:llm:r2",
"confidence": "high",
"information_cutoff_at": "2025-02-21T10:10:59Z",
"score": 8,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "ModExp Gas Cost Increase"
}
],
"route": "eips/7883/",
"title": "ModExp Gas Cost Increase"
},
{
"default_fork": "osaka",
"eip": 7892,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7892:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7892:llm:r2",
"eip": 7892,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7892",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2025-03-24T16:26:03Z",
"assessment_id": "osaka:7892:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-03-25T15:44:57Z",
"score": 18,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Blob Parameter Only Hardforks"
}
],
"route": "eips/7892/",
"title": "Blob Parameter Only Hardforks"
},
{
"default_fork": "hegota",
"eip": 7906,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7906:llm:r2",
"hegota:7906:human:r2"
],
"comparison_ids": [
"hegota:7906:r2"
],
"default_assessment_id": "hegota:7906:llm:r2",
"eip": 7906,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7906:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 23,
"source_record": {
"commit": "18cfcab5e295ad9e544c8bf8b57f998defaa7b31",
"content_sha256": "34e1b22f395fbbc4059ecfad790448556206aedd716763d5e6aa31a806fdabd1",
"git_blob_sha": "e2bc9d7fc5c9666952f06054ddb3a82f0fa4f15d",
"immutable_url": "https://github.com/ethspecs/pm/blob/18cfcab5e295ad9e544c8bf8b57f998defaa7b31/complexity_assessments/EIPs/EIP-7906.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7906.md",
"pull_request": {
"draft": false,
"number": 132,
"title": "Add EIP-7906 complexity assessment",
"updated_at": "2026-08-24T18:46:05Z",
"url": "https://github.com/ethspecs/pm/pull/132"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "high"
},
"id": "hegota:7906",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7906:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 28,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Transaction Assertions via State Diff Opcode"
}
],
"route": "eips/7906/",
"title": "Transaction Assertions via State Diff Opcode"
},
{
"default_fork": "osaka",
"eip": 7910,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7910:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7910:llm:r2",
"eip": 7910,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7910",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-07-09T17:40:29Z",
"assessment_id": "osaka:7910:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-07-10T14:25:07Z",
"score": 12,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "eth_config JSON-RPC Method"
}
],
"route": "eips/7910/",
"title": "eth_config JSON-RPC Method"
},
{
"default_fork": "osaka",
"eip": 7918,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7918:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7918:llm:r2",
"eip": 7918,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7918",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-03-26T19:04:25Z",
"assessment_id": "osaka:7918:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-03-26T23:25:10Z",
"score": 11,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Blob base fee bounded by execution cost"
}
],
"route": "eips/7918/",
"title": "Blob base fee bounded by execution cost"
},
{
"default_fork": "hegota",
"eip": 7923,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7923:llm:r2",
"hegota:7923:human:r2"
],
"comparison_ids": [
"hegota:7923:r2"
],
"default_assessment_id": "hegota:7923:llm:r2",
"eip": 7923,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:7923:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 15,
"source_record": {
"commit": "5f85492e085509e32602538d721e23fc11be6323",
"content_sha256": "e6260a5df1ebe00699afa03d1d74c7ec8e7837742cbaa37f9531e81e3a14f0ec",
"git_blob_sha": "77392502f74959d36064a9446a01a6b56f33e13b",
"immutable_url": "https://github.com/ethspecs/pm/blob/5f85492e085509e32602538d721e23fc11be6323/complexity_assessments/EIPs/EIP-7923.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-7923.md",
"pull_request": {
"draft": false,
"number": 134,
"title": "Add EIP-7923 complexity assessment",
"updated_at": "2026-08-25T00:42:59Z",
"url": "https://github.com/ethspecs/pm/pull/134"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:7923",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7923:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 23,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Linear, Page-Based Memory Costing"
}
],
"route": "eips/7923/",
"title": "Linear, Page-Based Memory Costing"
},
{
"default_fork": "amsterdam",
"eip": 7928,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7928:llm:r2",
"amsterdam:7928:llm:r1",
"amsterdam:7928:human:r1"
],
"comparison_ids": [
"amsterdam:7928:r1"
],
"default_assessment_id": "amsterdam:7928:llm:r2",
"eip": 7928,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7928:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 29,
"source_record": {
"commit": "6d744f3a809a69182166c8c76e793ac2fcb34bd4",
"committed_at": "2026-05-12T20:24:34Z",
"content_sha256": "a8d3e39c4aa0e201274d762d033c008dafdf25c68341e5c8e4b5fa0c6001eafc",
"git_blob_sha": "509dfc6013eeb510ca1cb4e53a2fd08f06284da4",
"immutable_url": "https://github.com/ethspecs/pm/blob/6d744f3a809a69182166c8c76e793ac2fcb34bd4/complexity_assessments/EIPs/EIP-7928.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7928.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "high"
},
"id": "amsterdam:7928",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-07-31T13:42:40Z",
"assessment_id": "amsterdam:7928:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-07-31T16:00:14Z",
"score": 40,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Block-Level Access Lists"
}
],
"route": "eips/7928/",
"title": "Block-Level Access Lists"
},
{
"default_fork": "osaka",
"eip": 7934,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7934:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7934:llm:r2",
"eip": 7934,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7934",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-05-06T12:39:57Z",
"assessment_id": "osaka:7934:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-05-09T21:56:48Z",
"score": 7,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "RLP Execution Block Size Limit"
}
],
"route": "eips/7934/",
"title": "RLP Execution Block Size Limit"
},
{
"default_fork": "osaka",
"eip": 7935,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7935:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7935:llm:r2",
"eip": 7935,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7935",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-05-08T13:56:16Z",
"assessment_id": "osaka:7935:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-05-09T21:56:48Z",
"score": 10,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "Set default gas limit to 60M"
}
],
"route": "eips/7935/",
"title": "Set default gas limit to 60M"
},
{
"default_fork": "osaka",
"eip": 7939,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7939:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7939:llm:r2",
"eip": 7939,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7939",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-06-09T10:17:58Z",
"assessment_id": "osaka:7939:llm:r2",
"confidence": "high",
"information_cutoff_at": "2025-07-02T17:49:36Z",
"score": 6,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "Count leading zeros (CLZ) opcode"
}
],
"route": "eips/7939/",
"title": "Count leading zeros (CLZ) opcode"
},
{
"default_fork": "osaka",
"eip": 7951,
"forks": [
"osaka"
],
"occurrences": [
{
"assessment_ids": [
"osaka:7951:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "osaka:7951:llm:r2",
"eip": 7951,
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"human": {
"assessment_id": null,
"note": "Human complexity assessments were not produced for this fork; only the LLM assessment exists.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "osaka:7951",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-07-01T20:21:20Z",
"assessment_id": "osaka:7951:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-07-02T17:49:36Z",
"score": 11,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Precompile for secp256r1 Curve Support"
}
],
"route": "eips/7951/",
"title": "Precompile for secp256r1 Curve Support"
},
{
"default_fork": "amsterdam",
"eip": 7954,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7954:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "amsterdam:7954:llm:r2",
"eip": 7954,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": null,
"note": "The STEEL team did not publish a human checklist for this EIP in the Amsterdam assessment round.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "amsterdam:7954",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-01-18T00:29:01Z",
"assessment_id": "amsterdam:7954:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-01-20T14:22:47Z",
"score": 14,
"status": "complete",
"tier": "medium",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Increase Maximum Contract Size"
}
],
"route": "eips/7954/",
"title": "Increase Maximum Contract Size"
},
{
"default_fork": "amsterdam",
"eip": 7976,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7976:llm:r2",
"amsterdam:7976:llm:r1",
"amsterdam:7976:human:r1"
],
"comparison_ids": [
"amsterdam:7976:r1"
],
"default_assessment_id": "amsterdam:7976:llm:r2",
"eip": 7976,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7976:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 5,
"source_record": {
"commit": "ce4d90eda1388dde9e23e42f804a82830779a8ef",
"committed_at": "2025-11-06T14:00:18Z",
"content_sha256": "221b4016db2b1153cb5dcb7b38ccc8a443afaf1da1d0eca85d454bb51a72a532",
"git_blob_sha": "d3e6776fa94c999bf4b0b2254e9ee7f716282612",
"immutable_url": "https://github.com/ethspecs/pm/blob/ce4d90eda1388dde9e23e42f804a82830779a8ef/complexity_assessments/EIPs/EIP-7976.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7976.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "low"
},
"id": "amsterdam:7976",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-09-03T08:10:21Z",
"assessment_id": "amsterdam:7976:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-09-03T20:52:20Z",
"score": 10,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Increase Calldata Floor Cost"
}
],
"route": "eips/7976/",
"title": "Increase Calldata Floor Cost"
},
{
"default_fork": "hegota",
"eip": 7979,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:7979:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:7979:llm:r2",
"eip": 7979,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:7979",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:7979:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 16,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Call and Return Opcodes for the EVM"
}
],
"route": "eips/7979/",
"title": "Call and Return Opcodes for the EVM"
},
{
"default_fork": "amsterdam",
"eip": 7981,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7981:llm:r2",
"amsterdam:7981:llm:r1",
"amsterdam:7981:human:r1"
],
"comparison_ids": [
"amsterdam:7981:r1"
],
"default_assessment_id": "amsterdam:7981:llm:r2",
"eip": 7981,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7981:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 6,
"source_record": {
"commit": "eb0d24aec552ce5ec5eca689a37f0eb47fe75203",
"committed_at": "2025-12-04T14:04:31Z",
"content_sha256": "7bbd980c0a0423ade93ee051919982ec873b52febccaf301db09308172d19442",
"git_blob_sha": "69f777a90c07f0797f6c625f7642820e76b78811",
"immutable_url": "https://github.com/ethspecs/pm/blob/eb0d24aec552ce5ec5eca689a37f0eb47fe75203/complexity_assessments/EIPs/EIP-7981.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7981.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "low"
},
"id": "amsterdam:7981",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-08-24T10:46:57Z",
"assessment_id": "amsterdam:7981:llm:r2",
"confidence": "high",
"information_cutoff_at": "2025-08-26T21:52:26Z",
"score": 11,
"status": "complete",
"tier": "low",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Increase Access List Cost"
}
],
"route": "eips/7981/",
"title": "Increase Access List Cost"
},
{
"default_fork": "amsterdam",
"eip": 7997,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:7997:llm:r2",
"amsterdam:7997:llm:r1",
"amsterdam:7997:human:r1"
],
"comparison_ids": [
"amsterdam:7997:r1"
],
"default_assessment_id": "amsterdam:7997:llm:r2",
"eip": 7997,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:7997:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 5,
"source_record": {
"commit": "676285451c6aac875ab7d0422bd17060b33552e2",
"committed_at": "2026-01-07T14:34:21Z",
"content_sha256": "bf037d2949856757d224cb32ac8ff67b261210cb70958bfbaf7c902c59857bd2",
"git_blob_sha": "0b3e3f469875edf56c7c6afac5d9acf8c1ab0c22",
"immutable_url": "https://github.com/ethspecs/pm/blob/676285451c6aac875ab7d0422bd17060b33552e2/complexity_assessments/EIPs/EIP-7997.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-7997.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "low"
},
"id": "amsterdam:7997",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-08-19T16:32:51Z",
"assessment_id": "amsterdam:7997:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-08-21T13:34:18Z",
"score": 14,
"status": "complete",
"tier": "medium",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Deterministic Factory Contract"
}
],
"route": "eips/7997/",
"title": "Deterministic Factory Contract"
},
{
"default_fork": "hegota",
"eip": 8015,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [],
"comparison_ids": [],
"default_assessment_id": null,
"eip": 8015,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8015",
"layers": [
"consensus"
],
"llm": {
"assessed_revision_at": null,
"assessment_id": null,
"confidence": null,
"exclusion_kind": "consensus_only",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"rationale": "Removes deposit and eth1data fields from consensus BeaconBlockBody and BeaconState containers only.",
"score": null,
"status": "not_applicable",
"tier": null,
"under_specified": null
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Remove `deposit` and `eth1data` fields"
}
],
"route": "eips/8015/",
"title": "Remove `deposit` and `eth1data` fields"
},
{
"default_fork": "amsterdam",
"eip": 8024,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:8024:llm:r2",
"amsterdam:8024:llm:r1",
"amsterdam:8024:human:r1"
],
"comparison_ids": [
"amsterdam:8024:r1"
],
"default_assessment_id": "amsterdam:8024:llm:r2",
"eip": 8024,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:8024:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 6,
"source_record": {
"commit": "e4f314d97a66349444ae7e562a13f6120a8b509c",
"committed_at": "2025-11-05T23:27:24Z",
"content_sha256": "b5a8ce9a96384bd02be21fd97e2752a102bcb9749be675b139089a86c257c528",
"git_blob_sha": "466f9a56d9f575e733f0aecbae0e7a49d8a51d47",
"immutable_url": "https://github.com/ethspecs/pm/blob/e4f314d97a66349444ae7e562a13f6120a8b509c/complexity_assessments/EIPs/eip8024.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/eip8024.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "low"
},
"id": "amsterdam:8024",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-09-17T17:24:56Z",
"assessment_id": "amsterdam:8024:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-10-29T02:00:31Z",
"score": 13,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "Backward compatible SWAPN, DUPN, EXCHANGE"
}
],
"route": "eips/8024/",
"title": "Backward compatible SWAPN, DUPN, EXCHANGE"
},
{
"default_fork": "hegota",
"eip": 8025,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8025:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8025:llm:r2",
"eip": 8025,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8025",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8025:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 21,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Optional Execution Proofs"
}
],
"route": "eips/8025/",
"title": "Optional Execution Proofs"
},
{
"default_fork": "amsterdam",
"eip": 8037,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:8037:llm:r2",
"amsterdam:8037:llm:r1",
"amsterdam:8037:human:r1"
],
"comparison_ids": [
"amsterdam:8037:r1"
],
"default_assessment_id": "amsterdam:8037:llm:r2",
"eip": 8037,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:8037:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 28,
"source_record": {
"commit": "eb0d24aec552ce5ec5eca689a37f0eb47fe75203",
"committed_at": "2025-12-04T14:04:31Z",
"content_sha256": "f37704066caeca7e1e6f0275dcabc9430781fbd3bd640bf222d9683a2b2eed52",
"git_blob_sha": "55fd5115c92d96f4d16d3be69dd87e04ce037ba0",
"immutable_url": "https://github.com/ethspecs/pm/blob/eb0d24aec552ce5ec5eca689a37f0eb47fe75203/complexity_assessments/EIPs/EIP-8037.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-8037.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "high"
},
"id": "amsterdam:8037",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-10-07T21:20:16Z",
"assessment_id": "amsterdam:8037:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-10-16T08:11:36Z",
"score": 35,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "State Creation Gas Cost Increase"
}
],
"route": "eips/8037/",
"title": "State Creation Gas Cost Increase"
},
{
"default_fork": "amsterdam",
"eip": 8038,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:8038:llm:r2",
"amsterdam:8038:llm:r1",
"amsterdam:8038:human:r1"
],
"comparison_ids": [
"amsterdam:8038:r1"
],
"default_assessment_id": "amsterdam:8038:llm:r2",
"eip": 8038,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": "amsterdam:8038:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 20,
"source_record": {
"commit": "3b1cc8521093ce2a7381a3da8341cf33a2452fad",
"committed_at": "2025-11-07T22:10:24Z",
"content_sha256": "cf9187ccf3b63b985d4e67a1c5d9bf48aa050d0ef0a1eb4b841ba99e89fb858a",
"git_blob_sha": "284c3213221ab59979604cc37e7cd83258c56889",
"immutable_url": "https://github.com/ethspecs/pm/blob/3b1cc8521093ce2a7381a3da8341cf33a2452fad/complexity_assessments/EIPs/EIP-8038.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-8038.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "high"
},
"id": "amsterdam:8038",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2025-10-08T11:34:45Z",
"assessment_id": "amsterdam:8038:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2025-10-16T08:11:36Z",
"score": 17,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "included_at_cutoff",
"snapshot_status": null,
"title": "State-access gas cost update"
}
],
"route": "eips/8038/",
"title": "State-access gas cost update"
},
{
"default_fork": "hegota",
"eip": 8077,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8077:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8077:llm:r2",
"eip": 8077,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8077",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8077:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 15,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "eth/XX - announce transactions with nonce"
}
],
"route": "eips/8077/",
"title": "eth/XX - announce transactions with nonce"
},
{
"default_fork": "hegota",
"eip": 8094,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8094:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8094:llm:r2",
"eip": 8094,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8094",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8094:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 20,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "eth/vhash - Blob-Aware Mempool"
}
],
"route": "eips/8094/",
"title": "eth/vhash - Blob-Aware Mempool"
},
{
"default_fork": "hegota",
"eip": 8115,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8115:llm:r2",
"hegota:8115:human:r2"
],
"comparison_ids": [
"hegota:8115:r2"
],
"default_assessment_id": "hegota:8115:llm:r2",
"eip": 8115,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8115:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 10,
"source_record": {
"commit": "39f6dc729d089e0c81279774cbf8f3e0c6731a4a",
"content_sha256": "5f31c7f4ff291f696709ab15cf636b28e5b2f94c5a7cad41936e5be874eca969",
"git_blob_sha": "2613a7f40549fff5318d15b4c82672f41d1ad3e7",
"immutable_url": "https://github.com/ethspecs/pm/blob/39f6dc729d089e0c81279774cbf8f3e0c6731a4a/complexity_assessments/EIPs/EIP-8115.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8115.md",
"pull_request": {
"draft": true,
"number": 126,
"title": "Add EIP-8115 complexity assessment",
"updated_at": "2026-08-24T09:58:13Z",
"url": "https://github.com/ethspecs/pm/pull/126"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "low"
},
"id": "hegota:8115",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8115:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 16,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Batch priority fees at end of block"
}
],
"route": "eips/8115/",
"title": "Batch priority fees at end of block"
},
{
"default_fork": "hegota",
"eip": 8116,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8116:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8116:llm:r2",
"eip": 8116,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8116",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8116:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 10,
"status": "complete",
"tier": "low",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Replace cumulative receipt fields"
}
],
"route": "eips/8116/",
"title": "Replace cumulative receipt fields"
},
{
"default_fork": "hegota",
"eip": 8131,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8131:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8131:llm:r2",
"eip": 8131,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8131",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8131:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 18,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Unified Transaction Content Floor"
}
],
"route": "eips/8131/",
"title": "Unified Transaction Content Floor"
},
{
"default_fork": "hegota",
"eip": 8141,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8141:llm:r2",
"hegota:8141:human:r1"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8141:llm:r2",
"eip": 8141,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8141:human:r1",
"note": null,
"other_candidates": [
{
"availability": "open_draft_pull_request",
"duplicates_preferred_scores": true,
"immutable_url": "https://github.com/ethspecs/pm/blob/0330c11ba99afc90e7c1afba6bcb0237bcf7d4d5/complexity_assessments/EIPs/EIP-8141.md",
"parse_state": "complete",
"pull_request": {
"draft": true,
"number": 122,
"title": "Rename checklist \"anchors\" to \"criteria\"",
"url": "https://github.com/ethspecs/pm/pull/122"
},
"recomputed_total": 38,
"rubric_revision": 1
}
],
"rubric_revision": 1,
"score": 38,
"source_record": {
"branch": "main",
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"committed_at": "2026-08-11T15:30:34Z",
"content_sha256": "5ee8d6adab64a924d9f86f45cd35263d062fc1fc73723894c24d4f698f9c5cd3",
"git_blob_sha": "c00d071cd8754c2f35214dd5d5cf34d3c80f8ff6",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/complexity_assessments/EIPs/EIP-8141.md",
"kind": "merged",
"path": "complexity_assessments/EIPs/EIP-8141.md",
"repository": "ethspecs/pm"
},
"status": "complete",
"tier": "high"
},
"id": "hegota:8141",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8141:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 60,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "CFI",
"title": "Frame Transaction"
}
],
"route": "eips/8141/",
"title": "Frame Transaction"
},
{
"default_fork": "hegota",
"eip": 8146,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8146:llm:r2",
"hegota:8146:human:r2"
],
"comparison_ids": [
"hegota:8146:r2"
],
"default_assessment_id": "hegota:8146:llm:r2",
"eip": 8146,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8146:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 19,
"source_record": {
"commit": "5963e7a7e1eb846a5dbce552d233255ca0583cba",
"content_sha256": "31857ce936b0b3f414e876919401927665d1ef61873fdb6ae34eb5007aad1141",
"git_blob_sha": "4f6d996a10d74987d39370741674c8ca3885ff39",
"immutable_url": "https://github.com/ethspecs/pm/blob/5963e7a7e1eb846a5dbce552d233255ca0583cba/complexity_assessments/EIPs/EIP-8146.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8146.md",
"pull_request": {
"draft": false,
"number": 106,
"title": "Add EIP-8146 complexity assessment",
"updated_at": "2026-08-17T15:24:38Z",
"url": "https://github.com/ethspecs/pm/pull/106"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:8146",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8146:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 20,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Block Access List Sidecars"
}
],
"route": "eips/8146/",
"title": "Block Access List Sidecars"
},
{
"default_fork": "hegota",
"eip": 8148,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8148:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8148:llm:r2",
"eip": 8148,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8148",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8148:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 27,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Custom sweep threshold for validators"
}
],
"route": "eips/8148/",
"title": "Custom sweep threshold for validators"
},
{
"default_fork": "hegota",
"eip": 8151,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8151:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8151:llm:r2",
"eip": 8151,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8151",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8151:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 22,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Account Code Restricted ecRecover"
}
],
"route": "eips/8151/",
"title": "Account Code Restricted ecRecover"
},
{
"default_fork": "hegota",
"eip": 8163,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [],
"comparison_ids": [],
"default_assessment_id": null,
"eip": 8163,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8163",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": null,
"assessment_id": null,
"confidence": null,
"exclusion_kind": "explicit_owner_exclusion",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"rationale": "Reserves an EVM opcode value but requires no current L1 execution-client behavior change; the project owner explicitly excluded it from evaluation.",
"score": null,
"status": "not_applicable",
"tier": null,
"under_specified": null
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Reserve `EXTENSION (0xae)` opcode"
}
],
"route": "eips/8163/",
"title": "Reserve `EXTENSION (0xae)` opcode"
},
{
"default_fork": "hegota",
"eip": 8173,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [],
"comparison_ids": [],
"default_assessment_id": null,
"eip": 8173,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8173",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": null,
"assessment_id": null,
"confidence": null,
"exclusion_kind": "explicit_owner_exclusion",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"rationale": "Defines an informational execution-layer control-flow model but no protocol or client behavior change; the project owner explicitly excluded it from evaluation.",
"score": null,
"status": "not_applicable",
"tier": null,
"under_specified": null
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Foundations of EVM Control Flow"
}
],
"route": "eips/8173/",
"title": "Foundations of EVM Control Flow"
},
{
"default_fork": "hegota",
"eip": 8182,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8182:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8182:llm:r2",
"eip": 8182,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8182",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8182:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 20,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Private ETH and ERC-20 Transfers"
}
],
"route": "eips/8182/",
"title": "Private ETH and ERC-20 Transfers"
},
{
"default_fork": "hegota",
"eip": 8188,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8188:llm:r2",
"hegota:8188:human:r2"
],
"comparison_ids": [
"hegota:8188:r2"
],
"default_assessment_id": "hegota:8188:llm:r2",
"eip": 8188,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8188:human:r2",
"note": null,
"other_candidates": [
{
"availability": "open_pull_request",
"duplicates_preferred_scores": false,
"immutable_url": "https://github.com/ethspecs/pm/blob/7bdc9e9829d47ac2f7520f23e0692e099a51e95f/complexity_assessments/EIPs/EIP-8188.md",
"parse_state": "complete",
"pull_request": {
"draft": false,
"number": 73,
"title": "Add complexity assessments",
"url": "https://github.com/ethspecs/pm/pull/73"
},
"recomputed_total": 10,
"rubric_revision": 1
}
],
"rubric_revision": 2,
"score": 18,
"source_record": {
"commit": "042096dd3debf88e51204bbf341c35c8527f6228",
"content_sha256": "f11bbf898d2ceaadf6ca86399b86c552a82fad4f3e929e2df130fc6899b5bfc8",
"git_blob_sha": "76dfe14f7dd1daa3c5b546b00f0f265c5e37e540",
"immutable_url": "https://github.com/ethspecs/pm/blob/042096dd3debf88e51204bbf341c35c8527f6228/complexity_assessments/EIPs/EIP-8188.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8188.md",
"pull_request": {
"draft": false,
"number": 125,
"title": "Add EIP-8188 complexity assessment",
"updated_at": "2026-08-24T06:59:51Z",
"url": "https://github.com/ethspecs/pm/pull/125"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:8188",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8188:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 26,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Last-Written Block for Accounts and Slots"
}
],
"route": "eips/8188/",
"title": "Last-Written Block for Accounts and Slots"
},
{
"default_fork": "hegota",
"eip": 8200,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8200:llm:r2",
"hegota:8200:human:r2"
],
"comparison_ids": [
"hegota:8200:r2"
],
"default_assessment_id": "hegota:8200:llm:r2",
"eip": 8200,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8200:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 22,
"source_record": {
"commit": "6a3be712b937ad5d7ecfa7bf4f0afaf0ee25e922",
"content_sha256": "d41a30af85354e7c175da20effcb31f9fa8b7aa46553c377489f6a48d949688c",
"git_blob_sha": "f83f82beeccd929d5e20512c9f7d711f73e63260",
"immutable_url": "https://github.com/ethspecs/pm/blob/6a3be712b937ad5d7ecfa7bf4f0afaf0ee25e922/complexity_assessments/EIPs/EIP-8200.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8200.md",
"pull_request": {
"draft": true,
"number": 109,
"title": "Add EIP-8200 complexity assessment",
"updated_at": "2026-08-18T08:08:34Z",
"url": "https://github.com/ethspecs/pm/pull/109"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "medium"
},
"id": "hegota:8200",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8200:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 28,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "EVMification"
}
],
"route": "eips/8200/",
"title": "EVMification"
},
{
"default_fork": "hegota",
"eip": 8205,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8205:llm:r2",
"hegota:8205:human:r1"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8205:llm:r2",
"eip": 8205,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8205:human:r1",
"note": null,
"other_candidates": [],
"rubric_revision": 1,
"score": 5,
"source_record": {
"commit": "7bdc9e9829d47ac2f7520f23e0692e099a51e95f",
"content_sha256": "fcab9b8af1fae3a1b15c3748b5e40b14189f2706b01e43cfe7a61e5a64d7ba6e",
"git_blob_sha": "0000ef39c9512689dd5f442c1c91d25a3db50923",
"immutable_url": "https://github.com/ethspecs/pm/blob/7bdc9e9829d47ac2f7520f23e0692e099a51e95f/complexity_assessments/EIPs/EIP-8205.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8205.md",
"pull_request": {
"draft": false,
"number": 73,
"title": "Add complexity assessments",
"updated_at": "2026-05-29T13:54:05Z",
"url": "https://github.com/ethspecs/pm/pull/73"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "low"
},
"id": "hegota:8205",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8205:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 24,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Withdrawal credentials preregistration"
}
],
"route": "eips/8205/",
"title": "Withdrawal credentials preregistration"
},
{
"default_fork": "hegota",
"eip": 8237,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8237:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8237:llm:r2",
"eip": 8237,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8237",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8237:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 29,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Independent CL/EL Sync"
}
],
"route": "eips/8237/",
"title": "Independent CL/EL Sync"
},
{
"default_fork": "hegota",
"eip": 8243,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [],
"comparison_ids": [],
"default_assessment_id": null,
"eip": 8243,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8243",
"layers": [
"consensus"
],
"llm": {
"assessed_revision_at": null,
"assessment_id": null,
"confidence": null,
"exclusion_kind": "consensus_only",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"rationale": "Changes consensus attestation containers, production, validation, aggregation, and gossip only.",
"score": null,
"status": "not_applicable",
"tier": null,
"under_specified": null
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Batching Attestations at Source"
}
],
"route": "eips/8243/",
"title": "Batching Attestations at Source"
},
{
"default_fork": "amsterdam",
"eip": 8246,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:8246:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "amsterdam:8246:llm:r2",
"eip": 8246,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": null,
"note": "The STEEL team did not publish a human checklist for this EIP in the Amsterdam assessment round.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "amsterdam:8246",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-05-06T12:59:06Z",
"assessment_id": "amsterdam:8246:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-05-06T12:59:06Z",
"score": 12,
"status": "complete",
"tier": "medium",
"under_specified": false
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "Remove SELFDESTRUCT Burn"
}
],
"route": "eips/8246/",
"title": "Remove SELFDESTRUCT Burn"
},
{
"default_fork": "hegota",
"eip": 8250,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8250:llm:r2",
"hegota:8250:human:r2"
],
"comparison_ids": [
"hegota:8250:r2"
],
"default_assessment_id": "hegota:8250:llm:r2",
"eip": 8250,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8250:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 22,
"source_record": {
"commit": "b0886dc0692db6e860765458d757d36ca5156a8e",
"content_sha256": "09679e4e48025ecc7ecd2e2e86691591cef47feacec24fea7b20f31507cc47c3",
"git_blob_sha": "3dd95224ea1f64cc1740bc98d182c26bf6fe60f6",
"immutable_url": "https://github.com/ethspecs/pm/blob/b0886dc0692db6e860765458d757d36ca5156a8e/complexity_assessments/EIPs/EIP-8250.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8250.md",
"pull_request": {
"draft": true,
"number": 111,
"title": "Add EIP-8250 complexity assessment",
"updated_at": "2026-08-18T08:32:19Z",
"url": "https://github.com/ethspecs/pm/pull/111"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "medium"
},
"id": "hegota:8250",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8250:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 42,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Keyed Nonces for Frame Transactions"
}
],
"route": "eips/8250/",
"title": "Keyed Nonces for Frame Transactions"
},
{
"default_fork": "hegota",
"eip": 8253,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8253:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8253:llm:r2",
"eip": 8253,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8253",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8253:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 20,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Bump nonce of zero-nonce storage accounts"
}
],
"route": "eips/8253/",
"title": "Bump nonce of zero-nonce storage accounts"
},
{
"default_fork": "hegota",
"eip": 8272,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8272:llm:r2",
"hegota:8272:llm:r2:hegota-2026-09-16-90194cf-eip-8272-v2",
"hegota:8272:human:r2"
],
"comparison_ids": [
"hegota:8272:r2"
],
"default_assessment_id": "hegota:8272:llm:r2",
"eip": 8272,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8272:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 14,
"source_record": {
"commit": "d54b36561f34f0f870426e6fd826a510035014c8",
"content_sha256": "9164c943cf8ab14ea92ca26794a2c54b07bfa38fd6ada199b48544c6576a1c4c",
"git_blob_sha": "81aae13863d54958fdf424a4d4f92ed97b92d7aa",
"immutable_url": "https://github.com/ethspecs/pm/blob/d54b36561f34f0f870426e6fd826a510035014c8/complexity_assessments/EIPs/EIP-8272.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8272.md",
"pull_request": {
"draft": false,
"number": 133,
"title": "Add EIP-8272 complexity assessment",
"updated_at": "2026-08-25T12:17:26Z",
"url": "https://github.com/ethspecs/pm/pull/133"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "medium"
},
"id": "hegota:8272",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8272:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 39,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Recent Roots for Frame Transactions"
}
],
"route": "eips/8272/",
"title": "Recent Roots for Frame Transactions"
},
{
"default_fork": "hegota",
"eip": 8279,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8279:llm:r2",
"hegota:8279:human:r2"
],
"comparison_ids": [
"hegota:8279:r2"
],
"default_assessment_id": "hegota:8279:llm:r2",
"eip": 8279,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8279:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 22,
"source_record": {
"commit": "9674b1fd589add3ab86713f95c4967de244c94e5",
"content_sha256": "a26230f73a4662f5baed3d53e904106fde38b00c09b1a7d1d8ae00ac7667241c",
"git_blob_sha": "7c3e42a49ad1a3f52742fa13e647909bd79b78ba",
"immutable_url": "https://github.com/ethspecs/pm/blob/9674b1fd589add3ab86713f95c4967de244c94e5/complexity_assessments/EIPs/EIP-8279.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8279.md",
"pull_request": {
"draft": true,
"number": 108,
"title": "Add EIP-8279 complexity assessment",
"updated_at": "2026-08-17T19:27:21Z",
"url": "https://github.com/ethspecs/pm/pull/108"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "medium"
},
"id": "hegota:8279",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8279:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 29,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Block Access List Byte Floor"
}
],
"route": "eips/8279/",
"title": "Block Access List Byte Floor"
},
{
"default_fork": "amsterdam",
"eip": 8282,
"forks": [
"amsterdam"
],
"occurrences": [
{
"assessment_ids": [
"amsterdam:8282:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "amsterdam:8282:llm:r2",
"eip": 8282,
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"human": {
"assessment_id": null,
"note": "The STEEL team did not publish a human checklist for this EIP in the Amsterdam assessment round.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "amsterdam:8282",
"layers": [
"execution",
"consensus"
],
"llm": {
"assessed_revision_at": "2026-07-08T12:46:18Z",
"assessment_id": "amsterdam:8282:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-07-13T07:12:57Z",
"score": 32,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "retrospective",
"scope_timing": "added_after_cutoff",
"snapshot_status": null,
"title": "Builder Execution Requests"
}
],
"route": "eips/8282/",
"title": "Builder Execution Requests"
},
{
"default_fork": "hegota",
"eip": 8298,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8298:llm:r2"
],
"comparison_ids": [],
"default_assessment_id": "hegota:8298:llm:r2",
"eip": 8298,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8298",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8298:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 22,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "SETCODEFROM Code Reuse Instruction"
}
],
"route": "eips/8298/",
"title": "SETCODEFROM Code Reuse Instruction"
},
{
"default_fork": "hegota",
"eip": 8304,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8304:llm:r2",
"hegota:8304:human:r2"
],
"comparison_ids": [
"hegota:8304:r2"
],
"default_assessment_id": "hegota:8304:llm:r2",
"eip": 8304,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8304:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 26,
"source_record": {
"commit": "ec861017c0006c353bdab4a9f3e910e40609495c",
"content_sha256": "8a57b185f6573a462a85f1154debe156f506b9eb0593351f47197792ebb95d10",
"git_blob_sha": "d4ccf1a464a005c07cb98694dc5303c61a9b8439",
"immutable_url": "https://github.com/ethspecs/pm/blob/ec861017c0006c353bdab4a9f3e910e40609495c/complexity_assessments/EIPs/EIP-8304.md",
"kind": "open_pull_request",
"path": "complexity_assessments/EIPs/EIP-8304.md",
"pull_request": {
"draft": false,
"number": 127,
"title": "Add EIP-8304 complexity assessment",
"updated_at": "2026-08-24T13:22:36Z",
"url": "https://github.com/ethspecs/pm/pull/127"
},
"repository": "ethspecs/pm"
},
"status": "available_in_open_pr",
"tier": "high"
},
"id": "hegota:8304",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8304:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 30,
"status": "complete",
"tier": "high",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Trustless log and transaction index"
}
],
"route": "eips/8304/",
"title": "Trustless log and transaction index"
},
{
"default_fork": "hegota",
"eip": 8333,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [],
"comparison_ids": [],
"default_assessment_id": null,
"eip": 8333,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8333",
"layers": [
"consensus"
],
"llm": {
"assessed_revision_at": null,
"assessment_id": null,
"confidence": null,
"exclusion_kind": "consensus_only",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"rationale": "Explicitly makes no execution-layer change and modifies consensus checkpoint selection and fork choice.",
"score": null,
"status": "not_applicable",
"tier": null,
"under_specified": null
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Align Checkpoint with Epoch Boundary Block"
}
],
"route": "eips/8333/",
"title": "Align Checkpoint with Epoch Boundary Block"
},
{
"default_fork": "hegota",
"eip": 8363,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [],
"comparison_ids": [],
"default_assessment_id": null,
"eip": 8363,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": null,
"note": "No STEEL checklist existed on the ethspecs/pm default branch or in any open pull request at the snapshot.",
"other_candidates": [],
"rubric_revision": null,
"score": null,
"source_record": null,
"status": "not_available",
"tier": null
},
"id": "hegota:8363",
"layers": [
"consensus"
],
"llm": {
"assessed_revision_at": null,
"assessment_id": null,
"confidence": null,
"exclusion_kind": "consensus_only",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"rationale": "Changes consensus validator issuance, reward, and burn accounting and explicitly requires no execution-layer changes.",
"score": null,
"status": "not_applicable",
"tier": null,
"under_specified": null
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Tapered Issuance Burn"
}
],
"route": "eips/8363/",
"title": "Tapered Issuance Burn"
},
{
"default_fork": "hegota",
"eip": 8368,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8368:llm:r2",
"hegota:8368:human:r2"
],
"comparison_ids": [
"hegota:8368:r2"
],
"default_assessment_id": "hegota:8368:llm:r2",
"eip": 8368,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8368:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 16,
"source_record": {
"commit": "e47b8d0d35ef9a949f193f202564e32e128460cc",
"content_sha256": "8163ff2c35ea114f8526bb337db11d383351da6fce7e2b5f168d313041c3326c",
"git_blob_sha": "c5097f7fc61a6202a89e36d392d0d1b3dfe322aa",
"immutable_url": "https://github.com/ethspecs/pm/blob/e47b8d0d35ef9a949f193f202564e32e128460cc/complexity_assessments/EIPs/EIP-8368.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8368.md",
"pull_request": {
"draft": true,
"number": 129,
"title": "Add EIP-8368 complexity assessment",
"updated_at": "2026-08-24T13:45:56Z",
"url": "https://github.com/ethspecs/pm/pull/129"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "medium"
},
"id": "hegota:8368",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8368:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 12,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "CPSB Recalibration for New Gas Limit"
}
],
"route": "eips/8368/",
"title": "CPSB Recalibration for New Gas Limit"
},
{
"default_fork": "hegota",
"eip": 8372,
"forks": [
"hegota"
],
"occurrences": [
{
"assessment_ids": [
"hegota:8372:llm:r2",
"hegota:8372:human:r2"
],
"comparison_ids": [
"hegota:8372:r2"
],
"default_assessment_id": "hegota:8372:llm:r2",
"eip": 8372,
"fork": "hegota",
"fork_name": "Hegotá",
"human": {
"assessment_id": "hegota:8372:human:r2",
"note": null,
"other_candidates": [],
"rubric_revision": 2,
"score": 20,
"source_record": {
"commit": "bcbc0c2a77e6866575f99aeb59889f52ae83361b",
"content_sha256": "163ca5d2a25abf1ed59783f3bde543d0f638b48ffeaba64c8761feadcfec8670",
"git_blob_sha": "c8fd40e285614b701e788be2f9a2f7e7208f2eaa",
"immutable_url": "https://github.com/ethspecs/pm/blob/bcbc0c2a77e6866575f99aeb59889f52ae83361b/complexity_assessments/EIPs/EIP-8372.md",
"kind": "open_draft_pull_request",
"path": "complexity_assessments/EIPs/EIP-8372.md",
"pull_request": {
"draft": true,
"number": 110,
"title": "Add EIP-8372 complexity assessment",
"updated_at": "2026-08-24T17:03:24Z",
"url": "https://github.com/ethspecs/pm/pull/110"
},
"repository": "ethspecs/pm"
},
"status": "in_progress",
"tier": "medium"
},
"id": "hegota:8372",
"layers": [
"execution"
],
"llm": {
"assessed_revision_at": "2026-08-25T11:56:58Z",
"assessment_id": "hegota:8372:llm:r2",
"confidence": "medium",
"information_cutoff_at": "2026-08-25T11:56:58Z",
"score": 19,
"status": "complete",
"tier": "medium",
"under_specified": true
},
"mode": "prospective",
"scope_timing": null,
"snapshot_status": "PFI",
"title": "Normalized state gas limit"
}
],
"route": "eips/8372/",
"title": "Normalized state gas limit"
}
],
"fork_shipping": {
"definition": "Calendar days from the fork's first devnet running at least two independent EL implementations to mainnet activation.",
"rows": [
{
"at_cutoff_eips": 4,
"final_scope_score_sum": 68,
"first_multi_el_devnet": "withdrawals-devnet-0",
"first_multi_el_devnet_at": "2022-12-09",
"fork": "shanghai",
"fork_name": "Shanghai / Shapella",
"fork_short": "Shanghai",
"hardest_eip": "EIP-4895",
"high_tier_score_sum": 53,
"late_addition_eips": 1,
"late_addition_score_sum": 3,
"mainnet_at": "2023-04-12",
"max_score": 30,
"projected": false,
"shipping_days": 124,
"total_score": 65
},
{
"at_cutoff_eips": 5,
"final_scope_score_sum": 135,
"first_multi_el_devnet": "dencun-devnet-4",
"first_multi_el_devnet_at": "2023-01-23",
"fork": "cancun",
"fork_name": "Cancun / Dencun",
"fork_short": "Cancun",
"hardest_eip": "EIP-4844",
"high_tier_score_sum": 86,
"late_addition_eips": 1,
"late_addition_score_sum": 9,
"mainnet_at": "2024-03-13",
"max_score": 48,
"projected": false,
"shipping_days": 415,
"total_score": 126
},
{
"at_cutoff_eips": 8,
"final_scope_score_sum": 254,
"first_multi_el_devnet": "pectra-devnet-0",
"first_multi_el_devnet_at": "2024-05-17",
"fork": "prague",
"fork_name": "Prague / Pectra",
"fork_short": "Prague",
"hardest_eip": "EIP-7002",
"high_tier_score_sum": 165,
"late_addition_eips": 3,
"late_addition_score_sum": 38,
"mainnet_at": "2025-05-07",
"max_score": 38,
"projected": false,
"shipping_days": 355,
"total_score": 216
},
{
"at_cutoff_eips": 8,
"final_scope_score_sum": 140,
"first_multi_el_devnet": "fusaka-devnet-0",
"first_multi_el_devnet_at": "2025-05-26",
"fork": "osaka",
"fork_name": "Osaka / Fusaka",
"fork_short": "Osaka",
"hardest_eip": "EIP-7594",
"high_tier_score_sum": 24,
"late_addition_eips": 4,
"late_addition_score_sum": 35,
"mainnet_at": "2025-12-03",
"max_score": 24,
"projected": false,
"shipping_days": 191,
"total_score": 105
},
{
"at_cutoff_eips": 13,
"final_scope_score_sum": 287,
"first_multi_el_devnet": "bal-devnet-0",
"first_multi_el_devnet_at": "2025-11-04",
"fork": "amsterdam",
"fork_name": "Amsterdam / Glamsterdam",
"fork_short": "Amsterdam",
"hardest_eip": "EIP-7928",
"high_tier_score_sum": 123,
"late_addition_eips": 2,
"late_addition_score_sum": 44,
"mainnet_at": "2026-12-15",
"max_score": 40,
"projected": true,
"shipping_days": 405,
"total_score": 243
}
]
},
"forks": [
{
"at_cutoff_count": 4,
"at_cutoff_score_sum": 65,
"composition": {
"added_after_cutoff": {
"assessment_count": 1,
"criteria": [
{
"eip_count": 0,
"id": "evm_gas_rule_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 0
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 0,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 0
},
{
"eip_count": 0,
"id": "transition_tool_interface_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_test_framework_primitives",
"score_sum": 0
},
{
"eip_count": 0,
"id": "cryptography",
"score_sum": 0
},
{
"eip_count": 0,
"id": "edge_boundary_conditions",
"score_sum": 0
},
{
"eip_count": 0,
"id": "block_syncing_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "engine_api_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_opcodes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "modified_opcodes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "encoding_changes_rlp_ssz",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_block_header_fields",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_fork_activation_mechanism",
"score_sum": 0
},
{
"eip_count": 0,
"id": "performance_risks",
"score_sum": 0
},
{
"eip_count": 0,
"id": "security_risks",
"score_sum": 0
},
{
"eip_count": 0,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 0
},
{
"eip_count": 0,
"id": "cross_eip_interactions",
"score_sum": 0
}
],
"rubric_revision": 2,
"score_sum": 3
},
"at_cutoff": {
"assessment_count": 4,
"criteria": [
{
"eip_count": 3,
"id": "evm_gas_rule_changes",
"score_sum": 5
},
{
"eip_count": 1,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 2
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 4,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 7
},
{
"eip_count": 1,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 3
},
{
"eip_count": 1,
"id": "transition_tool_interface_changes",
"score_sum": 1
},
{
"eip_count": 1,
"id": "new_test_framework_primitives",
"score_sum": 2
},
{
"eip_count": 0,
"id": "cryptography",
"score_sum": 0
},
{
"eip_count": 4,
"id": "edge_boundary_conditions",
"score_sum": 8
},
{
"eip_count": 1,
"id": "block_syncing_changes",
"score_sum": 2
},
{
"eip_count": 1,
"id": "engine_api_changes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_opcodes",
"score_sum": 1
},
{
"eip_count": 1,
"id": "modified_opcodes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 1,
"id": "encoding_changes_rlp_ssz",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 2
},
{
"eip_count": 1,
"id": "new_block_header_fields",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_fork_activation_mechanism",
"score_sum": 0
},
{
"eip_count": 2,
"id": "performance_risks",
"score_sum": 3
},
{
"eip_count": 4,
"id": "security_risks",
"score_sum": 7
},
{
"eip_count": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 5
},
{
"eip_count": 4,
"id": "cross_eip_interactions",
"score_sum": 7
}
],
"rubric_revision": 2,
"score_sum": 65
},
"final_scope": {
"assessment_count": 5,
"criteria": [
{
"eip_count": 3,
"id": "evm_gas_rule_changes",
"score_sum": 5
},
{
"eip_count": 1,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 2
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 4,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 7
},
{
"eip_count": 1,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 3
},
{
"eip_count": 1,
"id": "transition_tool_interface_changes",
"score_sum": 1
},
{
"eip_count": 1,
"id": "new_test_framework_primitives",
"score_sum": 2
},
{
"eip_count": 0,
"id": "cryptography",
"score_sum": 0
},
{
"eip_count": 4,
"id": "edge_boundary_conditions",
"score_sum": 8
},
{
"eip_count": 1,
"id": "block_syncing_changes",
"score_sum": 2
},
{
"eip_count": 1,
"id": "engine_api_changes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_opcodes",
"score_sum": 1
},
{
"eip_count": 2,
"id": "modified_opcodes",
"score_sum": 6
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 1,
"id": "encoding_changes_rlp_ssz",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 2
},
{
"eip_count": 1,
"id": "new_block_header_fields",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_fork_activation_mechanism",
"score_sum": 0
},
{
"eip_count": 2,
"id": "performance_risks",
"score_sum": 3
},
{
"eip_count": 4,
"id": "security_risks",
"score_sum": 7
},
{
"eip_count": 2,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 5
},
{
"eip_count": 4,
"id": "cross_eip_interactions",
"score_sum": 7
}
],
"rubric_revision": 2,
"score_sum": 68
}
},
"eip_count": 5,
"final_scope_score_sum": 68,
"fork": "shanghai",
"human_coverage": {
"comparable_count": 0,
"scored_count": 0,
"status_counts": {
"available_in_open_pr": 0,
"complete": 0,
"in_progress": 0,
"incomplete": 0,
"not_applicable": 0,
"not_available": 5
}
},
"late_addition_count": 1,
"late_addition_score_sum": 3,
"mode": "retrospective",
"name": "Shanghai / Shapella",
"not_applicable_count": 0,
"score_sum": 65,
"scored_count": 5,
"short_name": "Shanghai"
},
{
"at_cutoff_count": 5,
"at_cutoff_score_sum": 126,
"composition": {
"added_after_cutoff": {
"assessment_count": 1,
"criteria": [
{
"eip_count": 1,
"id": "evm_gas_rule_changes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 0
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 1,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 1
},
{
"eip_count": 0,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 0
},
{
"eip_count": 0,
"id": "transition_tool_interface_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_test_framework_primitives",
"score_sum": 0
},
{
"eip_count": 0,
"id": "cryptography",
"score_sum": 0
},
{
"eip_count": 1,
"id": "edge_boundary_conditions",
"score_sum": 1
},
{
"eip_count": 0,
"id": "block_syncing_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "engine_api_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_opcodes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "modified_opcodes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "encoding_changes_rlp_ssz",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_block_header_fields",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_fork_activation_mechanism",
"score_sum": 0
},
{
"eip_count": 0,
"id": "performance_risks",
"score_sum": 0
},
{
"eip_count": 1,
"id": "security_risks",
"score_sum": 1
},
{
"eip_count": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 2
},
{
"eip_count": 1,
"id": "cross_eip_interactions",
"score_sum": 2
}
],
"rubric_revision": 2,
"score_sum": 9
},
"at_cutoff": {
"assessment_count": 5,
"criteria": [
{
"eip_count": 4,
"id": "evm_gas_rule_changes",
"score_sum": 6
},
{
"eip_count": 1,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 2
},
{
"eip_count": 1,
"id": "blob_gas_accounting_changes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 5,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 9
},
{
"eip_count": 2,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 4
},
{
"eip_count": 2,
"id": "transition_tool_interface_changes",
"score_sum": 4
},
{
"eip_count": 2,
"id": "new_test_framework_primitives",
"score_sum": 3
},
{
"eip_count": 2,
"id": "cryptography",
"score_sum": 4
},
{
"eip_count": 5,
"id": "edge_boundary_conditions",
"score_sum": 15
},
{
"eip_count": 2,
"id": "block_syncing_changes",
"score_sum": 3
},
{
"eip_count": 2,
"id": "engine_api_changes",
"score_sum": 2
},
{
"eip_count": 1,
"id": "added_system_contracts",
"score_sum": 2
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 4,
"id": "added_opcodes",
"score_sum": 6
},
{
"eip_count": 1,
"id": "modified_opcodes",
"score_sum": 3
},
{
"eip_count": 1,
"id": "added_precompiles",
"score_sum": 1
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 2,
"id": "encoding_changes_rlp_ssz",
"score_sum": 6
},
{
"eip_count": 1,
"id": "new_transaction_types",
"score_sum": 3
},
{
"eip_count": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 3
},
{
"eip_count": 2,
"id": "new_block_header_fields",
"score_sum": 6
},
{
"eip_count": 1,
"id": "new_fork_activation_mechanism",
"score_sum": 3
},
{
"eip_count": 5,
"id": "performance_risks",
"score_sum": 10
},
{
"eip_count": 5,
"id": "security_risks",
"score_sum": 11
},
{
"eip_count": 4,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 9
},
{
"eip_count": 4,
"id": "cross_eip_interactions",
"score_sum": 8
}
],
"rubric_revision": 2,
"score_sum": 126
},
"final_scope": {
"assessment_count": 6,
"criteria": [
{
"eip_count": 5,
"id": "evm_gas_rule_changes",
"score_sum": 7
},
{
"eip_count": 1,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 2
},
{
"eip_count": 1,
"id": "blob_gas_accounting_changes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 6,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 10
},
{
"eip_count": 2,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 4
},
{
"eip_count": 2,
"id": "transition_tool_interface_changes",
"score_sum": 4
},
{
"eip_count": 2,
"id": "new_test_framework_primitives",
"score_sum": 3
},
{
"eip_count": 2,
"id": "cryptography",
"score_sum": 4
},
{
"eip_count": 6,
"id": "edge_boundary_conditions",
"score_sum": 16
},
{
"eip_count": 2,
"id": "block_syncing_changes",
"score_sum": 3
},
{
"eip_count": 2,
"id": "engine_api_changes",
"score_sum": 2
},
{
"eip_count": 1,
"id": "added_system_contracts",
"score_sum": 2
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 5,
"id": "added_opcodes",
"score_sum": 7
},
{
"eip_count": 1,
"id": "modified_opcodes",
"score_sum": 3
},
{
"eip_count": 1,
"id": "added_precompiles",
"score_sum": 1
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 2,
"id": "encoding_changes_rlp_ssz",
"score_sum": 6
},
{
"eip_count": 1,
"id": "new_transaction_types",
"score_sum": 3
},
{
"eip_count": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 3
},
{
"eip_count": 2,
"id": "new_block_header_fields",
"score_sum": 6
},
{
"eip_count": 1,
"id": "new_fork_activation_mechanism",
"score_sum": 3
},
{
"eip_count": 5,
"id": "performance_risks",
"score_sum": 10
},
{
"eip_count": 6,
"id": "security_risks",
"score_sum": 12
},
{
"eip_count": 5,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 11
},
{
"eip_count": 5,
"id": "cross_eip_interactions",
"score_sum": 10
}
],
"rubric_revision": 2,
"score_sum": 135
}
},
"eip_count": 6,
"final_scope_score_sum": 135,
"fork": "cancun",
"human_coverage": {
"comparable_count": 0,
"scored_count": 0,
"status_counts": {
"available_in_open_pr": 0,
"complete": 0,
"in_progress": 0,
"incomplete": 0,
"not_applicable": 0,
"not_available": 6
}
},
"late_addition_count": 1,
"late_addition_score_sum": 9,
"mode": "retrospective",
"name": "Cancun / Dencun",
"not_applicable_count": 0,
"score_sum": 126,
"scored_count": 6,
"short_name": "Cancun"
},
{
"at_cutoff_count": 8,
"at_cutoff_score_sum": 216,
"composition": {
"added_after_cutoff": {
"assessment_count": 3,
"criteria": [
{
"eip_count": 0,
"id": "evm_gas_rule_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 0
},
{
"eip_count": 2,
"id": "blob_gas_accounting_changes",
"score_sum": 2
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 2,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 2
},
{
"eip_count": 0,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 0
},
{
"eip_count": 0,
"id": "transition_tool_interface_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_test_framework_primitives",
"score_sum": 0
},
{
"eip_count": 0,
"id": "cryptography",
"score_sum": 0
},
{
"eip_count": 3,
"id": "edge_boundary_conditions",
"score_sum": 5
},
{
"eip_count": 0,
"id": "block_syncing_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "engine_api_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_opcodes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_opcodes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 1,
"id": "encoding_changes_rlp_ssz",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 1
},
{
"eip_count": 0,
"id": "new_block_header_fields",
"score_sum": 0
},
{
"eip_count": 2,
"id": "new_fork_activation_mechanism",
"score_sum": 6
},
{
"eip_count": 2,
"id": "performance_risks",
"score_sum": 6
},
{
"eip_count": 2,
"id": "security_risks",
"score_sum": 4
},
{
"eip_count": 3,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 5
},
{
"eip_count": 3,
"id": "cross_eip_interactions",
"score_sum": 4
}
],
"rubric_revision": 2,
"score_sum": 38
},
"at_cutoff": {
"assessment_count": 8,
"criteria": [
{
"eip_count": 4,
"id": "evm_gas_rule_changes",
"score_sum": 9
},
{
"eip_count": 2,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 3
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 7,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 16
},
{
"eip_count": 4,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 9
},
{
"eip_count": 4,
"id": "transition_tool_interface_changes",
"score_sum": 10
},
{
"eip_count": 4,
"id": "new_test_framework_primitives",
"score_sum": 6
},
{
"eip_count": 2,
"id": "cryptography",
"score_sum": 3
},
{
"eip_count": 8,
"id": "edge_boundary_conditions",
"score_sum": 22
},
{
"eip_count": 3,
"id": "block_syncing_changes",
"score_sum": 9
},
{
"eip_count": 3,
"id": "engine_api_changes",
"score_sum": 4
},
{
"eip_count": 2,
"id": "added_system_contracts",
"score_sum": 4
},
{
"eip_count": 1,
"id": "modified_system_contracts",
"score_sum": 2
},
{
"eip_count": 0,
"id": "added_opcodes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "modified_opcodes",
"score_sum": 3
},
{
"eip_count": 2,
"id": "added_precompiles",
"score_sum": 5
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 5,
"id": "encoding_changes_rlp_ssz",
"score_sum": 15
},
{
"eip_count": 1,
"id": "new_transaction_types",
"score_sum": 3
},
{
"eip_count": 2,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 5
},
{
"eip_count": 3,
"id": "new_block_header_fields",
"score_sum": 9
},
{
"eip_count": 2,
"id": "new_fork_activation_mechanism",
"score_sum": 6
},
{
"eip_count": 8,
"id": "performance_risks",
"score_sum": 19
},
{
"eip_count": 8,
"id": "security_risks",
"score_sum": 20
},
{
"eip_count": 8,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 20
},
{
"eip_count": 7,
"id": "cross_eip_interactions",
"score_sum": 14
}
],
"rubric_revision": 2,
"score_sum": 216
},
"final_scope": {
"assessment_count": 11,
"criteria": [
{
"eip_count": 4,
"id": "evm_gas_rule_changes",
"score_sum": 9
},
{
"eip_count": 2,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 3
},
{
"eip_count": 2,
"id": "blob_gas_accounting_changes",
"score_sum": 2
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 9,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 18
},
{
"eip_count": 4,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 9
},
{
"eip_count": 4,
"id": "transition_tool_interface_changes",
"score_sum": 10
},
{
"eip_count": 4,
"id": "new_test_framework_primitives",
"score_sum": 6
},
{
"eip_count": 2,
"id": "cryptography",
"score_sum": 3
},
{
"eip_count": 11,
"id": "edge_boundary_conditions",
"score_sum": 27
},
{
"eip_count": 3,
"id": "block_syncing_changes",
"score_sum": 9
},
{
"eip_count": 3,
"id": "engine_api_changes",
"score_sum": 4
},
{
"eip_count": 2,
"id": "added_system_contracts",
"score_sum": 4
},
{
"eip_count": 1,
"id": "modified_system_contracts",
"score_sum": 2
},
{
"eip_count": 0,
"id": "added_opcodes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "modified_opcodes",
"score_sum": 3
},
{
"eip_count": 2,
"id": "added_precompiles",
"score_sum": 5
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 6,
"id": "encoding_changes_rlp_ssz",
"score_sum": 18
},
{
"eip_count": 1,
"id": "new_transaction_types",
"score_sum": 3
},
{
"eip_count": 3,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 6
},
{
"eip_count": 3,
"id": "new_block_header_fields",
"score_sum": 9
},
{
"eip_count": 4,
"id": "new_fork_activation_mechanism",
"score_sum": 12
},
{
"eip_count": 10,
"id": "performance_risks",
"score_sum": 25
},
{
"eip_count": 10,
"id": "security_risks",
"score_sum": 24
},
{
"eip_count": 11,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 25
},
{
"eip_count": 10,
"id": "cross_eip_interactions",
"score_sum": 18
}
],
"rubric_revision": 2,
"score_sum": 254
}
},
"eip_count": 11,
"final_scope_score_sum": 254,
"fork": "prague",
"human_coverage": {
"comparable_count": 0,
"scored_count": 0,
"status_counts": {
"available_in_open_pr": 0,
"complete": 0,
"in_progress": 0,
"incomplete": 0,
"not_applicable": 0,
"not_available": 11
}
},
"late_addition_count": 3,
"late_addition_score_sum": 38,
"mode": "retrospective",
"name": "Prague / Pectra",
"not_applicable_count": 0,
"score_sum": 216,
"scored_count": 11,
"short_name": "Prague"
},
{
"at_cutoff_count": 8,
"at_cutoff_score_sum": 105,
"composition": {
"added_after_cutoff": {
"assessment_count": 4,
"criteria": [
{
"eip_count": 1,
"id": "evm_gas_rule_changes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 0
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 2,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 2
},
{
"eip_count": 0,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 0
},
{
"eip_count": 0,
"id": "transition_tool_interface_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_test_framework_primitives",
"score_sum": 0
},
{
"eip_count": 0,
"id": "cryptography",
"score_sum": 0
},
{
"eip_count": 4,
"id": "edge_boundary_conditions",
"score_sum": 6
},
{
"eip_count": 1,
"id": "block_syncing_changes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "engine_api_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_opcodes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "modified_opcodes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "encoding_changes_rlp_ssz",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_block_header_fields",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_fork_activation_mechanism",
"score_sum": 3
},
{
"eip_count": 4,
"id": "performance_risks",
"score_sum": 6
},
{
"eip_count": 4,
"id": "security_risks",
"score_sum": 7
},
{
"eip_count": 3,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 5
},
{
"eip_count": 2,
"id": "cross_eip_interactions",
"score_sum": 3
}
],
"rubric_revision": 2,
"score_sum": 35
},
"at_cutoff": {
"assessment_count": 8,
"criteria": [
{
"eip_count": 3,
"id": "evm_gas_rule_changes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 0
},
{
"eip_count": 2,
"id": "blob_gas_accounting_changes",
"score_sum": 2
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 8,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 11
},
{
"eip_count": 1,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 1
},
{
"eip_count": 0,
"id": "transition_tool_interface_changes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_test_framework_primitives",
"score_sum": 2
},
{
"eip_count": 2,
"id": "cryptography",
"score_sum": 3
},
{
"eip_count": 8,
"id": "edge_boundary_conditions",
"score_sum": 17
},
{
"eip_count": 1,
"id": "block_syncing_changes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "engine_api_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_opcodes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_opcodes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_precompiles",
"score_sum": 1
},
{
"eip_count": 2,
"id": "modified_precompiles",
"score_sum": 3
},
{
"eip_count": 2,
"id": "encoding_changes_rlp_ssz",
"score_sum": 6
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 2
},
{
"eip_count": 0,
"id": "new_block_header_fields",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_fork_activation_mechanism",
"score_sum": 3
},
{
"eip_count": 7,
"id": "performance_risks",
"score_sum": 13
},
{
"eip_count": 7,
"id": "security_risks",
"score_sum": 13
},
{
"eip_count": 7,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 12
},
{
"eip_count": 7,
"id": "cross_eip_interactions",
"score_sum": 12
}
],
"rubric_revision": 2,
"score_sum": 105
},
"final_scope": {
"assessment_count": 12,
"criteria": [
{
"eip_count": 4,
"id": "evm_gas_rule_changes",
"score_sum": 4
},
{
"eip_count": 0,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 0
},
{
"eip_count": 2,
"id": "blob_gas_accounting_changes",
"score_sum": 2
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 10,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 13
},
{
"eip_count": 1,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 1
},
{
"eip_count": 0,
"id": "transition_tool_interface_changes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_test_framework_primitives",
"score_sum": 2
},
{
"eip_count": 2,
"id": "cryptography",
"score_sum": 3
},
{
"eip_count": 12,
"id": "edge_boundary_conditions",
"score_sum": 23
},
{
"eip_count": 2,
"id": "block_syncing_changes",
"score_sum": 2
},
{
"eip_count": 0,
"id": "engine_api_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "added_system_contracts",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_system_contracts",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_opcodes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "modified_opcodes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_precompiles",
"score_sum": 1
},
{
"eip_count": 2,
"id": "modified_precompiles",
"score_sum": 3
},
{
"eip_count": 2,
"id": "encoding_changes_rlp_ssz",
"score_sum": 6
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 2
},
{
"eip_count": 0,
"id": "new_block_header_fields",
"score_sum": 0
},
{
"eip_count": 2,
"id": "new_fork_activation_mechanism",
"score_sum": 6
},
{
"eip_count": 11,
"id": "performance_risks",
"score_sum": 19
},
{
"eip_count": 11,
"id": "security_risks",
"score_sum": 20
},
{
"eip_count": 10,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 17
},
{
"eip_count": 9,
"id": "cross_eip_interactions",
"score_sum": 15
}
],
"rubric_revision": 2,
"score_sum": 140
}
},
"eip_count": 12,
"final_scope_score_sum": 140,
"fork": "osaka",
"human_coverage": {
"comparable_count": 0,
"scored_count": 0,
"status_counts": {
"available_in_open_pr": 0,
"complete": 0,
"in_progress": 0,
"incomplete": 0,
"not_applicable": 0,
"not_available": 12
}
},
"late_addition_count": 4,
"late_addition_score_sum": 35,
"mode": "retrospective",
"name": "Osaka / Fusaka",
"not_applicable_count": 0,
"score_sum": 105,
"scored_count": 12,
"short_name": "Osaka"
},
{
"at_cutoff_count": 13,
"at_cutoff_score_sum": 243,
"composition": {
"added_after_cutoff": {
"assessment_count": 2,
"criteria": [
{
"eip_count": 1,
"id": "evm_gas_rule_changes",
"score_sum": 1
},
{
"eip_count": 0,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 0
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "state_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 2,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 4
},
{
"eip_count": 1,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 1
},
{
"eip_count": 0,
"id": "transition_tool_interface_changes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_test_framework_primitives",
"score_sum": 1
},
{
"eip_count": 1,
"id": "cryptography",
"score_sum": 1
},
{
"eip_count": 2,
"id": "edge_boundary_conditions",
"score_sum": 6
},
{
"eip_count": 0,
"id": "block_syncing_changes",
"score_sum": 0
},
{
"eip_count": 0,
"id": "engine_api_changes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "added_system_contracts",
"score_sum": 3
},
{
"eip_count": 1,
"id": "modified_system_contracts",
"score_sum": 2
},
{
"eip_count": 0,
"id": "added_opcodes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "modified_opcodes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 1,
"id": "encoding_changes_rlp_ssz",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 0
},
{
"eip_count": 0,
"id": "new_block_header_fields",
"score_sum": 0
},
{
"eip_count": 1,
"id": "new_fork_activation_mechanism",
"score_sum": 3
},
{
"eip_count": 1,
"id": "performance_risks",
"score_sum": 3
},
{
"eip_count": 2,
"id": "security_risks",
"score_sum": 5
},
{
"eip_count": 1,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 2
},
{
"eip_count": 2,
"id": "cross_eip_interactions",
"score_sum": 6
}
],
"rubric_revision": 2,
"score_sum": 44
},
"at_cutoff": {
"assessment_count": 13,
"criteria": [
{
"eip_count": 8,
"id": "evm_gas_rule_changes",
"score_sum": 13
},
{
"eip_count": 1,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 2
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "state_gas_accounting_changes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 13,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 27
},
{
"eip_count": 5,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 10
},
{
"eip_count": 4,
"id": "transition_tool_interface_changes",
"score_sum": 7
},
{
"eip_count": 3,
"id": "new_test_framework_primitives",
"score_sum": 6
},
{
"eip_count": 1,
"id": "cryptography",
"score_sum": 1
},
{
"eip_count": 13,
"id": "edge_boundary_conditions",
"score_sum": 28
},
{
"eip_count": 2,
"id": "block_syncing_changes",
"score_sum": 4
},
{
"eip_count": 2,
"id": "engine_api_changes",
"score_sum": 3
},
{
"eip_count": 1,
"id": "added_system_contracts",
"score_sum": 2
},
{
"eip_count": 1,
"id": "modified_system_contracts",
"score_sum": 2
},
{
"eip_count": 2,
"id": "added_opcodes",
"score_sum": 4
},
{
"eip_count": 3,
"id": "modified_opcodes",
"score_sum": 9
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 2,
"id": "encoding_changes_rlp_ssz",
"score_sum": 6
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 5,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 11
},
{
"eip_count": 2,
"id": "new_block_header_fields",
"score_sum": 6
},
{
"eip_count": 1,
"id": "new_fork_activation_mechanism",
"score_sum": 3
},
{
"eip_count": 11,
"id": "performance_risks",
"score_sum": 23
},
{
"eip_count": 12,
"id": "security_risks",
"score_sum": 26
},
{
"eip_count": 9,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 19
},
{
"eip_count": 11,
"id": "cross_eip_interactions",
"score_sum": 28
}
],
"rubric_revision": 2,
"score_sum": 243
},
"final_scope": {
"assessment_count": 15,
"criteria": [
{
"eip_count": 9,
"id": "evm_gas_rule_changes",
"score_sum": 14
},
{
"eip_count": 1,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 2
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 1,
"id": "state_gas_accounting_changes",
"score_sum": 3
},
{
"eip_count": 0,
"id": "new_evm_gas_refund",
"score_sum": 0
},
{
"eip_count": 15,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 31
},
{
"eip_count": 6,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 11
},
{
"eip_count": 4,
"id": "transition_tool_interface_changes",
"score_sum": 7
},
{
"eip_count": 4,
"id": "new_test_framework_primitives",
"score_sum": 7
},
{
"eip_count": 2,
"id": "cryptography",
"score_sum": 2
},
{
"eip_count": 15,
"id": "edge_boundary_conditions",
"score_sum": 34
},
{
"eip_count": 2,
"id": "block_syncing_changes",
"score_sum": 4
},
{
"eip_count": 2,
"id": "engine_api_changes",
"score_sum": 3
},
{
"eip_count": 2,
"id": "added_system_contracts",
"score_sum": 5
},
{
"eip_count": 2,
"id": "modified_system_contracts",
"score_sum": 4
},
{
"eip_count": 2,
"id": "added_opcodes",
"score_sum": 4
},
{
"eip_count": 4,
"id": "modified_opcodes",
"score_sum": 12
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 0,
"id": "modified_precompiles",
"score_sum": 0
},
{
"eip_count": 3,
"id": "encoding_changes_rlp_ssz",
"score_sum": 9
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 5,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 11
},
{
"eip_count": 2,
"id": "new_block_header_fields",
"score_sum": 6
},
{
"eip_count": 2,
"id": "new_fork_activation_mechanism",
"score_sum": 6
},
{
"eip_count": 12,
"id": "performance_risks",
"score_sum": 26
},
{
"eip_count": 14,
"id": "security_risks",
"score_sum": 31
},
{
"eip_count": 10,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 21
},
{
"eip_count": 13,
"id": "cross_eip_interactions",
"score_sum": 34
}
],
"rubric_revision": 2,
"score_sum": 287
}
},
"eip_count": 15,
"final_scope_score_sum": 287,
"fork": "amsterdam",
"human_coverage": {
"comparable_count": 12,
"scored_count": 12,
"status_counts": {
"available_in_open_pr": 0,
"complete": 12,
"in_progress": 0,
"incomplete": 0,
"not_applicable": 0,
"not_available": 3
}
},
"late_addition_count": 2,
"late_addition_score_sum": 44,
"mode": "retrospective",
"name": "Amsterdam / Glamsterdam",
"not_applicable_count": 0,
"score_sum": 243,
"scored_count": 15,
"short_name": "Amsterdam"
},
{
"at_cutoff_count": null,
"at_cutoff_score_sum": null,
"composition": {
"all_scored": {
"assessment_count": 39,
"criteria": [
{
"eip_count": 23,
"id": "evm_gas_rule_changes",
"score_sum": 39
},
{
"eip_count": 10,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 19
},
{
"eip_count": 1,
"id": "blob_gas_accounting_changes",
"score_sum": 2
},
{
"eip_count": 4,
"id": "state_gas_accounting_changes",
"score_sum": 7
},
{
"eip_count": 2,
"id": "new_evm_gas_refund",
"score_sum": 4
},
{
"eip_count": 37,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 69
},
{
"eip_count": 14,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 22
},
{
"eip_count": 7,
"id": "transition_tool_interface_changes",
"score_sum": 15
},
{
"eip_count": 11,
"id": "new_test_framework_primitives",
"score_sum": 16
},
{
"eip_count": 8,
"id": "cryptography",
"score_sum": 13
},
{
"eip_count": 39,
"id": "edge_boundary_conditions",
"score_sum": 106
},
{
"eip_count": 6,
"id": "block_syncing_changes",
"score_sum": 12
},
{
"eip_count": 4,
"id": "engine_api_changes",
"score_sum": 9
},
{
"eip_count": 9,
"id": "added_system_contracts",
"score_sum": 16
},
{
"eip_count": 4,
"id": "modified_system_contracts",
"score_sum": 4
},
{
"eip_count": 8,
"id": "added_opcodes",
"score_sum": 18
},
{
"eip_count": 12,
"id": "modified_opcodes",
"score_sum": 36
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 3,
"id": "modified_precompiles",
"score_sum": 7
},
{
"eip_count": 11,
"id": "encoding_changes_rlp_ssz",
"score_sum": 33
},
{
"eip_count": 1,
"id": "new_transaction_types",
"score_sum": 3
},
{
"eip_count": 9,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 21
},
{
"eip_count": 2,
"id": "new_block_header_fields",
"score_sum": 6
},
{
"eip_count": 10,
"id": "new_fork_activation_mechanism",
"score_sum": 30
},
{
"eip_count": 34,
"id": "performance_risks",
"score_sum": 75
},
{
"eip_count": 38,
"id": "security_risks",
"score_sum": 93
},
{
"eip_count": 34,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 76
},
{
"eip_count": 36,
"id": "cross_eip_interactions",
"score_sum": 105
}
],
"rubric_revision": 2,
"score_sum": 856
},
"pfi_only": {
"assessment_count": 37,
"criteria": [
{
"eip_count": 22,
"id": "evm_gas_rule_changes",
"score_sum": 36
},
{
"eip_count": 9,
"id": "state_access_ordering_within_opcode_execution",
"score_sum": 17
},
{
"eip_count": 0,
"id": "blob_gas_accounting_changes",
"score_sum": 0
},
{
"eip_count": 3,
"id": "state_gas_accounting_changes",
"score_sum": 4
},
{
"eip_count": 2,
"id": "new_evm_gas_refund",
"score_sum": 4
},
{
"eip_count": 35,
"id": "patterns_affecting_pre_existing_tests",
"score_sum": 67
},
{
"eip_count": 14,
"id": "new_invariant_on_pre_existing_tests",
"score_sum": 22
},
{
"eip_count": 5,
"id": "transition_tool_interface_changes",
"score_sum": 10
},
{
"eip_count": 9,
"id": "new_test_framework_primitives",
"score_sum": 13
},
{
"eip_count": 7,
"id": "cryptography",
"score_sum": 11
},
{
"eip_count": 37,
"id": "edge_boundary_conditions",
"score_sum": 100
},
{
"eip_count": 5,
"id": "block_syncing_changes",
"score_sum": 9
},
{
"eip_count": 3,
"id": "engine_api_changes",
"score_sum": 6
},
{
"eip_count": 8,
"id": "added_system_contracts",
"score_sum": 15
},
{
"eip_count": 4,
"id": "modified_system_contracts",
"score_sum": 4
},
{
"eip_count": 7,
"id": "added_opcodes",
"score_sum": 15
},
{
"eip_count": 11,
"id": "modified_opcodes",
"score_sum": 33
},
{
"eip_count": 0,
"id": "added_precompiles",
"score_sum": 0
},
{
"eip_count": 3,
"id": "modified_precompiles",
"score_sum": 7
},
{
"eip_count": 10,
"id": "encoding_changes_rlp_ssz",
"score_sum": 30
},
{
"eip_count": 0,
"id": "new_transaction_types",
"score_sum": 0
},
{
"eip_count": 8,
"id": "new_or_modified_transaction_validity_mechanisms",
"score_sum": 18
},
{
"eip_count": 2,
"id": "new_block_header_fields",
"score_sum": 6
},
{
"eip_count": 9,
"id": "new_fork_activation_mechanism",
"score_sum": 27
},
{
"eip_count": 32,
"id": "performance_risks",
"score_sum": 69
},
{
"eip_count": 36,
"id": "security_risks",
"score_sum": 87
},
{
"eip_count": 32,
"id": "unspecified_behavior_requiring_cross_client_consensus",
"score_sum": 71
},
{
"eip_count": 34,
"id": "cross_eip_interactions",
"score_sum": 95
}
],
"rubric_revision": 2,
"score_sum": 776
}
},
"eip_count": 46,
"final_scope_score_sum": 856,
"fork": "hegota",
"human_coverage": {
"comparable_count": 22,
"scored_count": 25,
"status_counts": {
"available_in_open_pr": 15,
"complete": 2,
"in_progress": 8,
"incomplete": 0,
"not_applicable": 0,
"not_available": 21
}
},
"late_addition_count": null,
"late_addition_score_sum": null,
"mode": "prospective",
"name": "Hegotá",
"not_applicable_count": 7,
"score_sum": 856,
"scored_count": 39,
"short_name": "Hegotá"
}
],
"hegota": {
"captured_on": "2026-08-26",
"caveats": [
"The original PFI-only result remains 776 across 37 scored EIPs and is not rewritten by this combined view.",
"EIP-7805 was SFI and EIP-8141 was CFI, rather than PFI, at the frozen 2026-08-26 snapshot.",
"Scores cover execution-layer and execution-client networking surfaces only; EIP-7805 consensus-layer work is not scored.",
"Proposal splitting and cross-EIP interactions can overlap complexity, so score sums are not additive implementation-effort estimates.",
"No post-snapshot proposal text, implementation evidence, outcomes, or later fork decisions were available to assessors."
],
"confidence_distribution": {
"high": 0,
"low": 0,
"medium": 39
},
"human_snapshot": {
"captured_at": "2026-09-13T16:58:26Z",
"open_pull_requests": [
{
"draft": false,
"eips": [
4758,
7709,
8188,
8205
],
"number": 73,
"title": "Add complexity assessments",
"updated_at": "2026-05-29T13:54:05Z",
"url": "https://github.com/ethspecs/pm/pull/73"
},
{
"draft": false,
"eips": [
4758
],
"number": 105,
"title": "Add EIP-4758 complexity assessment",
"updated_at": "2026-08-17T13:21:13Z",
"url": "https://github.com/ethspecs/pm/pull/105"
},
{
"draft": false,
"eips": [
8146
],
"number": 106,
"title": "Add EIP-8146 complexity assessment",
"updated_at": "2026-08-17T15:24:38Z",
"url": "https://github.com/ethspecs/pm/pull/106"
},
{
"draft": true,
"eips": [
8279
],
"number": 108,
"title": "Add EIP-8279 complexity assessment",
"updated_at": "2026-08-17T19:27:21Z",
"url": "https://github.com/ethspecs/pm/pull/108"
},
{
"draft": true,
"eips": [
8200
],
"number": 109,
"title": "Add EIP-8200 complexity assessment",
"updated_at": "2026-08-18T08:08:34Z",
"url": "https://github.com/ethspecs/pm/pull/109"
},
{
"draft": true,
"eips": [
8372
],
"number": 110,
"title": "Add EIP-8372 complexity assessment",
"updated_at": "2026-08-24T17:03:24Z",
"url": "https://github.com/ethspecs/pm/pull/110"
},
{
"draft": true,
"eips": [
8250
],
"number": 111,
"title": "Add EIP-8250 complexity assessment",
"updated_at": "2026-08-18T08:32:19Z",
"url": "https://github.com/ethspecs/pm/pull/111"
},
{
"draft": true,
"eips": [
7666
],
"number": 112,
"title": "Add EIP-7666 complexity assessment",
"updated_at": "2026-08-18T08:55:08Z",
"url": "https://github.com/ethspecs/pm/pull/112"
},
{
"draft": false,
"eips": [
7645
],
"number": 113,
"title": "Add EIP-7645 complexity assessment",
"updated_at": "2026-08-18T16:39:57Z",
"url": "https://github.com/ethspecs/pm/pull/113"
},
{
"draft": false,
"eips": [
2488
],
"number": 114,
"title": "Add EIP-2488 complexity assessment",
"updated_at": "2026-08-18T16:56:16Z",
"url": "https://github.com/ethspecs/pm/pull/114"
},
{
"draft": false,
"eips": [
3298
],
"number": 115,
"title": "Add EIP-3298 complexity assessment",
"updated_at": "2026-08-18T20:29:53Z",
"url": "https://github.com/ethspecs/pm/pull/115"
},
{
"draft": false,
"eips": [
5920
],
"number": 116,
"title": "Update EIP-5920 complexity assessment to checklist revision 2",
"updated_at": "2026-08-18T21:00:22Z",
"url": "https://github.com/ethspecs/pm/pull/116"
},
{
"draft": false,
"eips": [
7668
],
"number": 118,
"title": "Update EIP-7668 complexity assessment to checklist revision 2",
"updated_at": "2026-08-18T23:06:30Z",
"url": "https://github.com/ethspecs/pm/pull/118"
},
{
"draft": false,
"eips": [
7709
],
"number": 120,
"title": "Add EIP-7709 complexity assessment",
"updated_at": "2026-08-24T12:41:48Z",
"url": "https://github.com/ethspecs/pm/pull/120"
},
{
"draft": true,
"eips": [
5920,
7668,
7805,
8141
],
"number": 122,
"title": "Rename checklist \"anchors\" to \"criteria\"",
"updated_at": "2026-08-20T09:54:08Z",
"url": "https://github.com/ethspecs/pm/pull/122"
},
{
"draft": false,
"eips": [
7862
],
"number": 124,
"title": "Add EIP-7862 complexity assessment",
"updated_at": "2026-08-24T06:38:06Z",
"url": "https://github.com/ethspecs/pm/pull/124"
},
{
"draft": false,
"eips": [
7862,
8188
],
"number": 125,
"title": "Add EIP-8188 complexity assessment",
"updated_at": "2026-08-24T06:59:51Z",
"url": "https://github.com/ethspecs/pm/pull/125"
},
{
"draft": true,
"eips": [
8115
],
"number": 126,
"title": "Add EIP-8115 complexity assessment",
"updated_at": "2026-08-24T09:58:13Z",
"url": "https://github.com/ethspecs/pm/pull/126"
},
{
"draft": false,
"eips": [
8304
],
"number": 127,
"title": "Add EIP-8304 complexity assessment",
"updated_at": "2026-08-24T13:22:36Z",
"url": "https://github.com/ethspecs/pm/pull/127"
},
{
"draft": true,
"eips": [
7819
],
"number": 128,
"title": "Add EIP-7819 complexity assessment",
"updated_at": "2026-08-24T13:25:20Z",
"url": "https://github.com/ethspecs/pm/pull/128"
},
{
"draft": true,
"eips": [
8368
],
"number": 129,
"title": "Add EIP-8368 complexity assessment",
"updated_at": "2026-08-24T13:45:56Z",
"url": "https://github.com/ethspecs/pm/pull/129"
},
{
"draft": false,
"eips": [
7906
],
"number": 132,
"title": "Add EIP-7906 complexity assessment",
"updated_at": "2026-08-24T18:46:05Z",
"url": "https://github.com/ethspecs/pm/pull/132"
},
{
"draft": false,
"eips": [
8272
],
"number": 133,
"title": "Add EIP-8272 complexity assessment",
"updated_at": "2026-08-25T12:17:26Z",
"url": "https://github.com/ethspecs/pm/pull/133"
},
{
"draft": false,
"eips": [
7923
],
"number": 134,
"title": "Add EIP-7923 complexity assessment",
"updated_at": "2026-08-25T00:42:59Z",
"url": "https://github.com/ethspecs/pm/pull/134"
}
],
"population": 46,
"snapshot_id": "hegota-human-2026-09-13-3d8c012",
"status_counts": {
"available_in_open_pr": 15,
"complete": 2,
"in_progress": 8,
"incomplete": 0,
"not_available": 21
},
"upstream": {
"assessment_directory": "complexity_assessments/EIPs",
"default_branch": "main",
"head_commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"head_committed_at": "2026-08-14T22:29:26Z",
"license": "CC0-1.0",
"repository": "ethspecs/pm"
}
},
"information_cutoff_at": "2026-08-25T11:56:58Z",
"not_applicable": 7,
"pfi_score_sum": 776,
"pfi_scored": 37,
"score_sum": 856,
"scored": 39,
"sfi_cfi_score_sum": 80,
"sfi_cfi_scored": 2,
"snapshot_id": "hegota-candidates-2026-08-26-ac450a4",
"source_commit": "ac450a4ab2f37387385ee9c54b62f518d97e6cc9",
"tier_distribution": {
"high": 14,
"low": 4,
"medium": 21
},
"total_entries": 46,
"under_specification_distribution": {
"absent": 3,
"present": 36
}
},
"human_llm": {
"criteria": [
{
"exact_count": 5,
"human_higher_count": 5,
"id": "evm_gas_rule_changes",
"llm_higher_count": 2,
"mean_absolute_delta": 1.25,
"mean_delta": -0.9167,
"nonzero_count": 9
},
{
"exact_count": 11,
"human_higher_count": 1,
"id": "blob_gas_accounting_changes",
"llm_higher_count": 0,
"mean_absolute_delta": 0.0833,
"mean_delta": -0.0833,
"nonzero_count": 1
},
{
"exact_count": 10,
"human_higher_count": 2,
"id": "new_evm_gas_refund",
"llm_higher_count": 0,
"mean_absolute_delta": 0.25,
"mean_delta": -0.25,
"nonzero_count": 2
},
{
"exact_count": 3,
"human_higher_count": 4,
"id": "patterns_affecting_pre_existing_tests",
"llm_higher_count": 5,
"mean_absolute_delta": 1.1667,
"mean_delta": -0.3333,
"nonzero_count": 12
},
{
"exact_count": 9,
"human_higher_count": 2,
"id": "transition_tool_interface_changes",
"llm_higher_count": 1,
"mean_absolute_delta": 0.4167,
"mean_delta": -0.0833,
"nonzero_count": 5
},
{
"exact_count": 12,
"human_higher_count": 0,
"id": "cryptography",
"llm_higher_count": 0,
"mean_absolute_delta": 0,
"mean_delta": 0,
"nonzero_count": 0
},
{
"exact_count": 6,
"human_higher_count": 1,
"id": "edge_boundary_conditions",
"llm_higher_count": 5,
"mean_absolute_delta": 0.6667,
"mean_delta": 0.5,
"nonzero_count": 12
},
{
"exact_count": 10,
"human_higher_count": 0,
"id": "block_syncing_changes",
"llm_higher_count": 2,
"mean_absolute_delta": 0.1667,
"mean_delta": 0.1667,
"nonzero_count": 3
},
{
"exact_count": 11,
"human_higher_count": 1,
"id": "engine_api_changes",
"llm_higher_count": 0,
"mean_absolute_delta": 0.25,
"mean_delta": -0.25,
"nonzero_count": 2
},
{
"exact_count": 11,
"human_higher_count": 0,
"id": "engine_api_encoding_changes",
"llm_higher_count": 1,
"mean_absolute_delta": 0.0833,
"mean_delta": 0.0833,
"nonzero_count": 1
},
{
"exact_count": 11,
"human_higher_count": 1,
"id": "added_system_contracts",
"llm_higher_count": 0,
"mean_absolute_delta": 0.0833,
"mean_delta": -0.0833,
"nonzero_count": 1
},
{
"exact_count": 10,
"human_higher_count": 2,
"id": "modified_system_contracts",
"llm_higher_count": 0,
"mean_absolute_delta": 0.25,
"mean_delta": -0.25,
"nonzero_count": 2
},
{
"exact_count": 12,
"human_higher_count": 0,
"id": "added_opcodes",
"llm_higher_count": 0,
"mean_absolute_delta": 0,
"mean_delta": 0,
"nonzero_count": 2
},
{
"exact_count": 9,
"human_higher_count": 1,
"id": "modified_opcodes",
"llm_higher_count": 2,
"mean_absolute_delta": 0.6667,
"mean_delta": 0.1667,
"nonzero_count": 3
},
{
"exact_count": 12,
"human_higher_count": 0,
"id": "added_precompiles",
"llm_higher_count": 0,
"mean_absolute_delta": 0,
"mean_delta": 0,
"nonzero_count": 0
},
{
"exact_count": 12,
"human_higher_count": 0,
"id": "modified_precompiles",
"llm_higher_count": 0,
"mean_absolute_delta": 0,
"mean_delta": 0,
"nonzero_count": 0
},
{
"exact_count": 10,
"human_higher_count": 0,
"id": "encoding_changes_rlp_ssz",
"llm_higher_count": 2,
"mean_absolute_delta": 0.5,
"mean_delta": 0.5,
"nonzero_count": 2
},
{
"exact_count": 12,
"human_higher_count": 0,
"id": "new_transaction_types",
"llm_higher_count": 0,
"mean_absolute_delta": 0,
"mean_delta": 0,
"nonzero_count": 0
},
{
"exact_count": 7,
"human_higher_count": 4,
"id": "new_or_modified_transaction_validity_mechanisms",
"llm_higher_count": 1,
"mean_absolute_delta": 0.5833,
"mean_delta": -0.4167,
"nonzero_count": 7
},
{
"exact_count": 12,
"human_higher_count": 0,
"id": "new_block_header_fields",
"llm_higher_count": 0,
"mean_absolute_delta": 0,
"mean_delta": 0,
"nonzero_count": 2
},
{
"exact_count": 10,
"human_higher_count": 0,
"id": "new_fork_activation_mechanism",
"llm_higher_count": 2,
"mean_absolute_delta": 0.4167,
"mean_delta": 0.4167,
"nonzero_count": 2
},
{
"exact_count": 5,
"human_higher_count": 0,
"id": "performance_risks",
"llm_higher_count": 7,
"mean_absolute_delta": 1,
"mean_delta": 1,
"nonzero_count": 11
},
{
"exact_count": 1,
"human_higher_count": 2,
"id": "security_risks",
"llm_higher_count": 9,
"mean_absolute_delta": 1.8333,
"mean_delta": 1.5,
"nonzero_count": 12
},
{
"exact_count": 4,
"human_higher_count": 0,
"id": "cross_eip_interactions",
"llm_higher_count": 8,
"mean_absolute_delta": 1.1667,
"mean_delta": 1.1667,
"nonzero_count": 10
}
],
"fork": "amsterdam",
"rows": [
{
"clean": false,
"comparison_id": "amsterdam:7928:r1",
"delta": -3,
"eip": 7928,
"human_assessment_id": "amsterdam:7928:human:r1",
"human_tier": "high",
"human_timing_exposure": "high_exposure",
"human_total": 29,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:7928:llm:r1",
"llm_tier": "high",
"llm_total": 26,
"primary_llm_assessment_id": "amsterdam:7928:llm:r2",
"primary_llm_total": 40,
"tier_agreement": true,
"title": "Block-Level Access Lists"
},
{
"clean": false,
"comparison_id": "amsterdam:8037:r1",
"delta": -7,
"eip": 8037,
"human_assessment_id": "amsterdam:8037:human:r1",
"human_tier": "high",
"human_timing_exposure": "high_exposure",
"human_total": 28,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:8037:llm:r1",
"llm_tier": "high",
"llm_total": 21,
"primary_llm_assessment_id": "amsterdam:8037:llm:r2",
"primary_llm_total": 35,
"tier_agreement": true,
"title": "State Creation Gas Cost Increase"
},
{
"clean": false,
"comparison_id": "amsterdam:8038:r1",
"delta": -3,
"eip": 8038,
"human_assessment_id": "amsterdam:8038:human:r1",
"human_tier": "high",
"human_timing_exposure": "possible_exposure",
"human_total": 20,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:8038:llm:r1",
"llm_tier": "medium",
"llm_total": 17,
"primary_llm_assessment_id": "amsterdam:8038:llm:r2",
"primary_llm_total": 17,
"tier_agreement": false,
"title": "State-access gas cost update"
},
{
"clean": false,
"comparison_id": "amsterdam:2780:r1",
"delta": 7,
"eip": 2780,
"human_assessment_id": "amsterdam:2780:human:r1",
"human_tier": "medium",
"human_timing_exposure": "possible_exposure",
"human_total": 13,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:2780:llm:r1",
"llm_tier": "high",
"llm_total": 20,
"primary_llm_assessment_id": "amsterdam:2780:llm:r2",
"primary_llm_total": 25,
"tier_agreement": false,
"title": "Resource-based intrinsic transaction gas"
},
{
"clean": false,
"comparison_id": "amsterdam:7778:r1",
"delta": -2,
"eip": 7778,
"human_assessment_id": "amsterdam:7778:human:r1",
"human_tier": "medium",
"human_timing_exposure": "low_exposure",
"human_total": 10,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:7778:llm:r1",
"llm_tier": "low",
"llm_total": 8,
"primary_llm_assessment_id": "amsterdam:7778:llm:r2",
"primary_llm_total": 13,
"tier_agreement": false,
"title": "Block Gas Accounting without Refunds"
},
{
"clean": true,
"comparison_id": "amsterdam:7708:r1",
"delta": 4,
"eip": 7708,
"human_assessment_id": "amsterdam:7708:human:r1",
"human_tier": "low",
"human_timing_exposure": "high_exposure",
"human_total": 9,
"input_alignment": "exact_blob",
"llm_assessment_id": "amsterdam:7708:llm:r1",
"llm_tier": "medium",
"llm_total": 13,
"primary_llm_assessment_id": "amsterdam:7708:llm:r2",
"primary_llm_total": 19,
"tier_agreement": false,
"title": "ETH transfers emit a log"
},
{
"clean": false,
"comparison_id": "amsterdam:7610:r1",
"delta": 3,
"eip": 7610,
"human_assessment_id": "amsterdam:7610:human:r1",
"human_tier": "low",
"human_timing_exposure": "possible_exposure",
"human_total": 7,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:7610:llm:r1",
"llm_tier": "medium",
"llm_total": 10,
"primary_llm_assessment_id": "amsterdam:7610:llm:r2",
"primary_llm_total": 9,
"tier_agreement": false,
"title": "Revert creation in case of non-empty storage"
},
{
"clean": true,
"comparison_id": "amsterdam:7843:r1",
"delta": 10,
"eip": 7843,
"human_assessment_id": "amsterdam:7843:human:r1",
"human_tier": "low",
"human_timing_exposure": "low_exposure",
"human_total": 7,
"input_alignment": "no_substantive_drift",
"llm_assessment_id": "amsterdam:7843:llm:r1",
"llm_tier": "medium",
"llm_total": 17,
"primary_llm_assessment_id": "amsterdam:7843:llm:r2",
"primary_llm_total": 23,
"tier_agreement": false,
"title": "SLOTNUM opcode"
},
{
"clean": false,
"comparison_id": "amsterdam:7981:r1",
"delta": 5,
"eip": 7981,
"human_assessment_id": "amsterdam:7981:human:r1",
"human_tier": "low",
"human_timing_exposure": "high_exposure",
"human_total": 6,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:7981:llm:r1",
"llm_tier": "medium",
"llm_total": 11,
"primary_llm_assessment_id": "amsterdam:7981:llm:r2",
"primary_llm_total": 11,
"tier_agreement": false,
"title": "Increase Access List Cost"
},
{
"clean": false,
"comparison_id": "amsterdam:8024:r1",
"delta": 5,
"eip": 8024,
"human_assessment_id": "amsterdam:8024:human:r1",
"human_tier": "low",
"human_timing_exposure": "low_exposure",
"human_total": 6,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:8024:llm:r1",
"llm_tier": "medium",
"llm_total": 11,
"primary_llm_assessment_id": "amsterdam:8024:llm:r2",
"primary_llm_total": 13,
"tier_agreement": false,
"title": "Backward compatible SWAPN, DUPN, EXCHANGE"
},
{
"clean": false,
"comparison_id": "amsterdam:7976:r1",
"delta": 7,
"eip": 7976,
"human_assessment_id": "amsterdam:7976:human:r1",
"human_tier": "low",
"human_timing_exposure": "high_exposure",
"human_total": 5,
"input_alignment": "no_substantive_drift",
"llm_assessment_id": "amsterdam:7976:llm:r1",
"llm_tier": "medium",
"llm_total": 12,
"primary_llm_assessment_id": "amsterdam:7976:llm:r2",
"primary_llm_total": 10,
"tier_agreement": false,
"title": "Increase Calldata Floor Cost"
},
{
"clean": false,
"comparison_id": "amsterdam:7997:r1",
"delta": 8,
"eip": 7997,
"human_assessment_id": "amsterdam:7997:human:r1",
"human_tier": "low",
"human_timing_exposure": "low_exposure",
"human_total": 5,
"input_alignment": "substantive_drift",
"llm_assessment_id": "amsterdam:7997:llm:r1",
"llm_tier": "medium",
"llm_total": 13,
"primary_llm_assessment_id": "amsterdam:7997:llm:r2",
"primary_llm_total": 14,
"tier_agreement": false,
"title": "Deterministic Factory Contract"
}
],
"rubric_revision": 1,
"summary": {
"clean_count": 2,
"comparison_count": 12,
"equal_total_count": 0,
"human_higher_count": 4,
"llm_higher_count": 8,
"mean_absolute_delta": 5.3333,
"mean_signed_delta": 2.8333,
"median_absolute_delta": 5.0,
"tier_agreement_count": 2
}
},
"release_state": "public",
"rubrics": {
"1": {
"criteria": [
"evm_gas_rule_changes",
"blob_gas_accounting_changes",
"new_evm_gas_refund",
"patterns_affecting_pre_existing_tests",
"transition_tool_interface_changes",
"cryptography",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"engine_api_encoding_changes",
"added_system_contracts",
"modified_system_contracts",
"added_opcodes",
"modified_opcodes",
"added_precompiles",
"modified_precompiles",
"encoding_changes_rlp_ssz",
"new_transaction_types",
"new_or_modified_transaction_validity_mechanisms",
"new_block_header_fields",
"new_fork_activation_mechanism",
"performance_risks",
"security_risks",
"cross_eip_interactions"
],
"criterion_count": 24,
"nominal_maximum": 72,
"revision": 1,
"source": {
"checklist_revision": 1,
"commit": "d936bcb34963cb5eec015dada2e4188e49fc14d5",
"immutable_url": "https://github.com/ethspecs/pm/blob/d936bcb34963cb5eec015dada2e4188e49fc14d5/Templates/EIP-Complexity-Assessment.md",
"known_source_defects": [
"The checklist contains Engine API encoding changes but the template has no dedicated definition for that row."
],
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm"
},
"tier_thresholds": {
"high": {
"maximum": null,
"minimum": 20
},
"low": {
"maximum": 9,
"minimum": 0
},
"medium": {
"maximum": 19,
"minimum": 10
}
}
},
"2": {
"criteria": [
"evm_gas_rule_changes",
"state_access_ordering_within_opcode_execution",
"blob_gas_accounting_changes",
"state_gas_accounting_changes",
"new_evm_gas_refund",
"patterns_affecting_pre_existing_tests",
"new_invariant_on_pre_existing_tests",
"transition_tool_interface_changes",
"new_test_framework_primitives",
"cryptography",
"edge_boundary_conditions",
"block_syncing_changes",
"engine_api_changes",
"added_system_contracts",
"modified_system_contracts",
"added_opcodes",
"modified_opcodes",
"added_precompiles",
"modified_precompiles",
"encoding_changes_rlp_ssz",
"new_transaction_types",
"new_or_modified_transaction_validity_mechanisms",
"new_block_header_fields",
"new_fork_activation_mechanism",
"performance_risks",
"security_risks",
"unspecified_behavior_requiring_cross_client_consensus",
"cross_eip_interactions"
],
"criterion_count": 28,
"nominal_maximum": 84,
"revision": 2,
"source": {
"checklist_revision": 2,
"commit": "3d8c0128c5543dd3146341ef395aa344e4abea30",
"immutable_url": "https://github.com/ethspecs/pm/blob/3d8c0128c5543dd3146341ef395aa344e4abea30/Templates/EIP-Complexity-Assessment.md",
"path": "Templates/EIP-Complexity-Assessment.md",
"repository": "ethspecs/pm"
},
"tier_thresholds": {
"high": {
"maximum": null,
"minimum": 23
},
"low": {
"maximum": 11,
"minimum": 0
},
"medium": {
"maximum": 22,
"minimum": 12
}
}
}
},
"schema_version": "2.1.0"
}