EIP complexity assessment

EIP-8188: Last-Written Block for Accounts and Slots

Assessed in Hegotá. The score describes the EIP text available at the snapshot, not the EIP as it stands today.

ProspectiveHegotáSnapshot 2026-08-25PFI at snapshotLayers: execution

LLM Completescore 26

Human Available in open PRscore 18 · Checklist revision 2· ethspecs/pm #125

Other checklist versions (1)

Pull request #73 · Checklist revision 1 · total 10

LLM · Checklist revision 22026-08-26 · Original snapshot · 26 Human · Checklist revision 2Available in open PR · 18 CompareHuman vs LLM · same checklist revision

Evaluated on: 2026-08-26 · Spec revision: 2026-08-25 · ac450a4ab2 · Inclusion status at snapshot: PFI

Scope at the cutoff. 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.

26HighHigh

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: Yes — 7 criteria affected
Plausible range: 22–29 (Medium–High)
Snapshot: 2026-08-25 · EIP revision ac450a4ab2 (2026-08-25)

Score bands · Checklist revision 2

Low <12
Medium 12–22
High ≥23

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

Complexity profile

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

Under-specified at assessment cutoff: Yes

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

Why: Material 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.

Plausible total

22–29
recorded score 26 · plausible tiers Medium, High

Affected criteria (7)

Modified system contracts (1)
State gas accounting changes (1)
Transition-tool interface changes (2)
New test-framework primitives (1)
Security risks (2)
Cross-EIP interactions (2)
Unspecified behavior requiring cross-client consensus (3)

Unresolved questions at the cutoff (5)

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?

Notable ambiguities noted by the assessor (3)

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.

Criterion breakdown

EIP-8188 Hegotá: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Modified opcodes	3	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.	eip.md · Specification / Storage slot rules Existing SSTORE executions now update slot and account metadata for value changes, deletion, and creation. eip.md · Specification / Account rules Existing value-transfer, creation, and SELFDESTRUCT paths now produce additional consensus state effects. Confidence: High Uncertainty: The exact exhaustive opcode set is not stated, but one modified existing opcode is sufficient for the permitted score of 3.
Patterns affecting pre-existing tests	3	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.	eip.md · Specification / Block Update Rule Storage changes, deletion, creation, balance transfers, nonce increments, account creation, SELFDESTRUCT, reads, and reverts all receive metadata rules. eip.md · Backwards Compatibility Post-fork writes change trie-leaf encodings and state-root computation while untouched legacy entries retain their prior encoding. Confidence: High Uncertainty: The sealed package contains no test inventory, so the exact number of affected vectors cannot be counted; the specified mutation surface is nevertheless broad.
Performance risks	3	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.	eip.md · Rationale / How does extra metadata affect the state size? 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. eip.md · Security Considerations Every written account or slot grows, increasing data touched by writes and the size of state witnesses and proofs. Confidence: High Uncertainty: Client tiering optimizations are optional and unspecified, so only the mandatory metadata overhead and write-path effects are scored.
Edge/boundary conditions	3	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.	eip.md · Specification / Block Update Rule The rules distinguish changed, deleted, no-op, and new slots; repeated writes; balance and nonce changes; reads; frame reverts; and multiple SELFDESTRUCT cases. eip.md · Backwards Compatibility Post-fork execution permits a persistent mixture of legacy entries defaulting to zero and newly encoded entries after their first mutation. Confidence: High Uncertainty: Some account-mutation cases are not exhaustively enumerated, increasing the boundary surface recorded under under-specification.
Unspecified behavior requiring cross-client consensusUnder-specified	3	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.	eip.md · Front matter and Abstract The proposal is Draft and makes previously unrecorded write-age information consensus metadata that changes the state root. eip.md · Specification / Account rules The enumerated account updates cover balance, nonce, storage, creation, and SELFDESTRUCT but do not state an exhaustive rule for every account-field mutation. supporting/eip-8037.md · Specification / Parameter changes The required EIP-8037 package text includes existing-account EOA delegation writes, a mutation class not resolved by EIP-8188's account-rule list. Confidence: Medium Uncertainty: The allowed package contains no implementation, devnet, test, or discussion evidence with which to determine whether these Draft gaps already have a shared resolution.
Transition-tool interface changesUnder-specified	2	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.	eip.md · Encoding Changes The state model adds metadata to both account objects and individual storage slots, with distinct legacy and post-fork representations. Confidence: Medium Uncertainty: 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.
New invariant on pre-existing tests	2	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.	eip.md · Encoding Changes Accounts and storage slots gain a consensus last_written_block value that is incorporated into their RLP and therefore into trie hashing. eip.md · Backwards Compatibility Legacy entries default to zero and migrate only on a post-fork mutation; no tree transition occurs at activation. Confidence: Medium Uncertainty: 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.
Security risksUnder-specified	2	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.	eip.md · Security Considerations Added bytes increase state-resource usage and witness sizes; without matching EIP-8037 byte rates, new accounts and slots would be underpriced. eip.md · Specification / Reads and Reverts Consensus correctness requires reads not to mutate metadata and reverted frames to restore it exactly with accompanying state. Confidence: Medium Uncertainty: The security consequence of the ambiguous EIP-8037 parameter adjustment and omitted mutation cases cannot be fully resolved from the package.
Cross-EIP interactionsUnder-specified	2	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.	eip.md · Front matter and Rationale / Relation with state creation cost (EIP-8037) EIP-8188 requires EIP-8037 and proposes coordinated changes to two of its per-byte state-creation parameters. eip.md · Specification / Account rules / SELFDESTRUCT SELFDESTRUCT metadata behavior is explicitly branched according to EIP-6780. eip.md · Rationale / Why do reads not update the block? Read behavior is designed to preserve EIP-214 STATICCALL state immutability. Confidence: High Uncertainty: The proposal also anticipates an unnumbered future state-tiering pricing EIP; its design and test interaction cannot be assessed from this snapshot. Interacting EIPs: EIP-214, EIP-6780, EIP-8037
Modified system contractsUnder-specified	1	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.	eip.md · Specification / Storage slot rules Every qualifying SSTORE changes both slot metadata and containing-account metadata. supporting/eip-8037.md · Specification / System contracts and system transactions Existing system-call paths can write new storage slots through stateful system contracts. Confidence: Low Uncertainty: 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.
State gas accounting changesUnder-specified	1	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.	eip.md · Rationale / Relation with state creation cost (EIP-8037) 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. supporting/eip-8037.md · Specification / New parameters EIP-8037 defines the existing 120-byte account and 64-byte storage-slot state-gas rates that EIP-8188 proposes adjusting. Confidence: Medium Uncertainty: 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.
New test-framework primitivesUnder-specified	1	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.	eip.md · Encoding Changes Tests need to represent and compare last_written_block on accounts and slots, including legacy entries that imply zero. Confidence: Low Uncertainty: No test-framework design is present in the sealed sources; existing primitives could require either only fields or a new metadata-aware expectation.

Show 16 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No opcode is added.	eip.md · Specification The update rules attach metadata to existing state operations and define no opcode number or new instruction. Uncertainty: None.
Added precompiles	No precompile is added.	eip.md · Specification No precompile address, input contract, or gas schedule is introduced. Uncertainty: None.
Modified precompiles	Generic surrounding state-transition effects do not modify precompile logic or gas schedules.	eip.md · Specification / Account rules The proposal changes generic account metadata on balance mutation but defines no change to any precompile's logic or gas accounting. Uncertainty: A value transfer to an address is governed by generic account rules, not by a precompile modification in this anchor.
Added system contracts	No system contract is introduced.	eip.md · Specification The proposal adds state metadata and no contract deployment or system address. Uncertainty: None within the sealed proposal scope.
EVM Gas rule changes	EIP-8188 introduces no execution-gas accounting rule. Its state-gas parameter interaction is assessed only in the dedicated state-gas anchor.	eip.md · Abstract The proposal expressly says that the metadata introduces no gas changes. eip.md · Motivation Gas pricing based on the metadata is left to a separate proposal. Uncertainty: The EIP-8037 parameter recommendation creates a scope tension, but it concerns state-gas rates rather than a separate EVM execution-gas rule.
State-access ordering within opcode execution	The proposal changes the state written by existing operations, not the ordering of a pre-existing state access or gas charge inside opcode execution.	eip.md · Specification / Block Update Rule The text defines when metadata changes alongside mutations but does not move an existing state access or gas charge within any opcode. Uncertainty: 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.
Blob gas accounting changes	No blob-gas mechanism or blob-gas rate is added or modified.	eip.md · Abstract The scope is account and storage-slot metadata and the text expressly says that it introduces no gas changes. Uncertainty: No blob behavior appears anywhere in the proposal specification.
New EVM gas refund	State journaling on revert is not a gas-refund mechanism.	eip.md · Specification / Reverts Rolled-back metadata is restored like ordinary state; no gas credit or refund rule is defined. Uncertainty: The proposal explicitly disclaims gas changes.
New transaction types	No new transaction type is introduced.	eip.md · Specification The proposal defines no transaction envelope or transaction type. Uncertainty: None.
New or modified transaction validity mechanisms	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.	eip.md · Abstract The proposal adds state metadata and expressly introduces no gas changes. eip.md · Specification No transaction-validity or intrinsic-gas rule is defined. Uncertainty: The possible EIP-8037 byte-rate adjustment is a state-gas issue, not a transaction-validity rule.
New block / header fields	The proposal consumes an existing block number and adds no header field.	eip.md · Specification / Block Update Rule Existing block_number supplies metadata values; no new block or header field is defined. Uncertainty: None.
Encoding changes (RLP/SSZ)	Despite the substantial state RLP change, this rubric anchor is expressly limited to transaction, block, and interface encoding, none of which changes.	eip.md · Specification / Encoding Changes RLP changes are confined to account and storage-slot trie-leaf values, not transaction, block, or interface encoding. Uncertainty: State-leaf encoding complexity is captured by affected tests, invariants, transition representation, edge cases, and performance rather than this narrow anchor.
Block syncing changes	The anchor is limited to block RLP validation, which EIP-8188 does not modify.	eip.md · Backwards Compatibility The RLP changes apply to account and storage trie leaves and state-root computation; the proposal introduces no block-RLP validation mechanism. Uncertainty: State synchronization may need mixed leaf decoding, but that is outside this anchor's block-RLP scope.
New fork activation mechanism	No state or existing internal value is modified at the activation block itself.	eip.md · Backwards Compatibility No tree transition occurs; legacy entries remain encoded as before and adopt the new encoding only upon their first post-fork mutation. Uncertainty: Implementations must activate new mutation rules, but initialization of a semantic field and lazy decoding are not an activation-block modification under this anchor.
Engine API changes	No Engine API change is introduced.	eip.md · Specification The specification changes only execution state encoding and mutation metadata; it defines no Engine API field, endpoint, or communication rule. Uncertainty: None within the sealed proposal scope.
Cryptography	Trie hashing reflects changed bytes, but the cryptographic mechanism itself is unchanged.	eip.md · Specification The complete mechanism consists of RLP state metadata and mutation rules; no cryptographic primitive or cryptographic functionality is added or changed. Uncertainty: No cryptographic testing surface is specified.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@ac450a4ab2 EIPS/eip-8188.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z
Current master · File history · blob 34da619b6f · sha256 dc2306ba2877
Rubric: Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator: gpt-5.6-sol at xhigh reasoning effort · isolation bubblewrap_one_eip_capsule_v1
Source record: Frozen research record research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8188.yaml · sha256 f3e2ad4e1f86
Supporting documents in the sealed package: supporting/eip-214.md, supporting/eip-6780.md, supporting/eip-8037.md

Evaluated on: Not recorded

18MediumMedium

Evaluator: HumanChecklist v2
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2026-08-24
Source: open ethspecs/pm pull request #125

Score bands · Checklist revision 2

Low <12
Medium 12–22
High ≥23

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

Complexity profile

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

Top complexity drivers

Encoding changes (RLP/SSZ)3
Transition-tool interface changes2
New invariant on pre-existing tests2
Performance risks2

Criterion breakdown

EIP-8188 Hegotá: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
Encoding changes (RLP/SSZ)	3	Both state-trie leaf encodings change, with a permanently mixed legacy format alongside.	—
Transition-tool interface changes	2	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`.	—
New invariant on pre-existing tests	2	every test in the fork now asserts `last_written_block` on every account and slot it touched.	—
Performance risks	2	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.	—
Edge/boundary conditions	2	(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.	—
State gas accounting changes	1	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.	—
Block syncing changes	1	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.	—
Patterns affecting pre-existing tests	1	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.	—
New test-framework primitives	1	`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.	—
Security risks	1	Targeted review and fuzzing of the encoding and revert paths, not an extensive cross-cutting review.	—
Cross-EIP interactions	1	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.	—
Unspecified behavior requiring cross-client consensus	1	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?	—

Show 16 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Notes
Added opcodes	No new opcodes.	—
Modified opcodes	No opcode being modified.	—
Added precompiles	No new precompiles.	—
Modified precompiles	No precompile logic or gas schedule changes.	—
Added system contracts	No new system contracts.	—
Modified system contracts	No modified system contracts	—
EVM Gas rule changes	No execution gas rule changes.	—
State-access ordering within opcode execution	No state-access site moves and no gas charge moves relative to one.	—
Blob gas accounting changes	No interaction with blob gas.	—
New EVM gas refund	No refund mechanism is introduced or affected.	—
New transaction types	No new transaction type.	—
New or modified transaction validity mechanisms	Transaction validity rules and intrinsic gas calculation are unchanged.	—
New block / header fields	No new block or header fields.	—
New fork activation mechanism	No rules activates	—
Engine API changes	No new fields, endpoints or communication mechanisms.	—
Cryptography	No cryptography introduced or modified.	—

Assessment provenance

Rubric: Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Open pull request #125: Add EIP-8188 complexity assessment · checklist at 042096dd3d · updated 2026-08-24
blob 76dfe14f7d · sha256 f11bbf898d2c
Research record: research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8188.yaml · sha256 441883ccea62

Both assessments applied Checklist revision 2 (28 criteria) to EIP-8188 in Hegotá. Δ is LLM minus Human.

Using the latest scored LLM evaluation for this checklist: 2026-08-26 · spec 2026-08-25 · ac450a4ab2. The Human and LLM assessments may use different spec revisions.

LLM26High

Human18Medium

Δ total+8Tiers differ: High vs Medium

Criteria18/28agree exactly · 6 differ by 1 · 4 differ by 2+

Complexity profiles side by side

LLM

Human

Largest disagreements: Modified opcodes (+3), Encoding changes (RLP/SSZ) (−3), Patterns affecting pre-existing tests (+2), Unspecified behavior requiring cross-client consensus (+2), Edge/boundary conditions (+1)

Show differences only (10 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
Modified opcodes	3	0	+3	Differ by 2+	Show rationale LLM 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. Human No opcode being modified.
Encoding changes (RLP/SSZ)	0	3	−3	Differ by 2+	Show rationale LLM Despite the substantial state RLP change, this rubric anchor is expressly limited to transaction, block, and interface encoding, none of which changes. Human Both state-trie leaf encodings change, with a permanently mixed legacy format alongside.
Patterns affecting pre-existing tests	3	1	+2	Differ by 2+	Show rationale LLM 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. Human 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.
Unspecified behavior requiring cross-client consensus	3	1	+2	Differ by 2+	Show rationale LLM 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. Human 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?
Modified system contracts	1	0	+1	Differ by 1	Show rationale LLM 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. Human No modified system contracts
Block syncing changes	0	1	−1	Differ by 1	Show rationale LLM The anchor is limited to block RLP validation, which EIP-8188 does not modify. Human 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.
Security risks	2	1	+1	Differ by 1	Show rationale LLM 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. Human Targeted review and fuzzing of the encoding and revert paths, not an extensive cross-cutting review.
Performance risks	3	2	+1	Differ by 1	Show rationale LLM 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. Human 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.
Edge/boundary conditions	3	2	+1	Differ by 1	Show rationale LLM 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. Human (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.
Cross-EIP interactions	2	1	+1	Differ by 1	Show rationale LLM 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. Human 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.
Added opcodes	0	0	0	Agree	Show rationale LLM No opcode is added. Human No new opcodes.
Added precompiles	0	0	0	Agree	Show rationale LLM No precompile is added. Human No new precompiles.
Modified precompiles	0	0	0	Agree	Show rationale LLM Generic surrounding state-transition effects do not modify precompile logic or gas schedules. Human No precompile logic or gas schedule changes.
Added system contracts	0	0	0	Agree	Show rationale LLM No system contract is introduced. Human No new system contracts.
EVM Gas rule changes	0	0	0	Agree	Show rationale LLM EIP-8188 introduces no execution-gas accounting rule. Its state-gas parameter interaction is assessed only in the dedicated state-gas anchor. Human No execution gas rule changes.
State-access ordering within opcode execution	0	0	0	Agree	Show rationale LLM The proposal changes the state written by existing operations, not the ordering of a pre-existing state access or gas charge inside opcode execution. Human No state-access site moves and no gas charge moves relative to one.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM No blob-gas mechanism or blob-gas rate is added or modified. Human No interaction with blob gas.
State gas accounting changes	1	1	0	Agree	Show rationale LLM 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. Human 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.
New EVM gas refund	0	0	0	Agree	Show rationale LLM State journaling on revert is not a gas-refund mechanism. Human No refund mechanism is introduced or affected.
New transaction types	0	0	0	Agree	Show rationale LLM No new transaction type is introduced. Human No new transaction type.
New or modified transaction validity mechanisms	0	0	0	Agree	Show rationale LLM 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. Human Transaction validity rules and intrinsic gas calculation are unchanged.
New block / header fields	0	0	0	Agree	Show rationale LLM The proposal consumes an existing block number and adds no header field. Human No new block or header fields.
New fork activation mechanism	0	0	0	Agree	Show rationale LLM No state or existing internal value is modified at the activation block itself. Human No rules activates
Engine API changes	0	0	0	Agree	Show rationale LLM No Engine API change is introduced. Human No new fields, endpoints or communication mechanisms.
Transition-tool interface changes	2	2	0	Agree	Show rationale LLM 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. Human 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`.
New invariant on pre-existing tests	2	2	0	Agree	Show rationale LLM 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. Human every test in the fork now asserts `last_written_block` on every account and slot it touched.
New test-framework primitives	1	1	0	Agree	Show rationale LLM 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. Human `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.
Cryptography	0	0	0	Agree	Show rationale LLM Trie hashing reflects changed bytes, but the cryptographic mechanism itself is unchanged. Human No cryptography introduced or modified.

Compare EIP-8188 with other assessments All Hegotá assessments

Criterion legend and glossary

Every stacked bar, comparison matrix, and criterion table on this site uses the same criterion colours, abbreviations, and order. Colour marks the criterion group; the abbreviation and name identify the criterion. Scores are 0–3 per criterion (4 is exceptional; cross-EIP interactions is uncapped).

EVM surface

Opcodes, precompiles, and system contracts that are added or modified.

OP+
Added opcodes
Introduces new opcodes
Score anchors
0
No new opcodes are introduced.
1
A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
2
Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
3
Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
- Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
Modified opcodes
Modifies pre-existing opcodes
Score anchors
0
No pre-existing opcode modifications are introduced.
3
At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
PC+
Added precompiles
Introduces new precompiles
Score anchors
0
No new precompiles are introduced.
1
A new simple precompile is introduced (constant input length, constant gas cost).
2
Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
3
Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
- Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
Modified precompiles
Modifies pre-existing precompiles logic or gas-accounting
Score anchors
0
No pre-existing precompiles are modified.
1
At least one pre-existing precompile has its gas schedule modified.
2
Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
3
The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
Added system contracts
Introduces new system contract, stateful or not
Score anchors
0
No new system contracts are introduced.
1
A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
2
Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
3
Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
Modified system contracts
Modifies pre-existing system contracts
Score anchors
0
No modifications to pre-existing system contracts are introduced, directly or indirectly.
1
Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
2
Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
3
At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.

Gas and accounting

Execution, blob, and state gas rules, refunds, and where charges happen inside opcodes.

EVM Gas rule changes
New EVM gas accounting rules
Score anchors
0
No gas accounting changes.
1
Existing gas accounting mechanism is updated.
2
A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
3
A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
ORD
State-access ordering within opcode execution · Checklist revision 2 only
Changes *where inside an opcode's execution* state is accessed, or where gas is charged relative to that access. Because a state access is recorded in the block-level access list only if execution had enough gas to reach it, this ordering is consensus-critical: moving it changes the BAL at every gas boundary of every affected opcode.
Score anchors
0
No change to where state is accessed, or to where gas is charged relative to a state access, within any opcode.
1
A single opcode's state-access or gas-charge ordering changes.
2
Multiple opcodes' ordering changes, or a new state-accessing operation is introduced whose position in the order must be settled.
3
The ordering rule changes for a whole class of state-accessing opcodes at once, or what counts as a recordable state access is redefined — requiring existing BAL vectors to be re-derived across opcodes and forks.
- Distinct from "Modified opcodes", which asks whether an opcode's **result** changed. This row asks about the **path to the result**, which is observable even when the result is identical. An EIP can be 0 on that row and 3 on this one.
- Score changes **to** the ordering. Do not score the fact that state accesses are observable — they always are.
- Each boundary must be re-tested against every other dimension that can change the answer (cold/warm, static/non-static, delegated/direct, revert/success), so the case count grows multiplicatively rather than additively. Note this explicitly under Special Considerations.
Blob gas accounting changes
New Blob gas accounting rules which potentially affect pre-existing tests
Score anchors
0
No blob gas accounting changes.
1
Existing blob gas accounting mechanism is updated.
2
A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
3
A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
SGAS
State gas accounting changes · Checklist revision 2 only
New state gas accounting rules. State gas is the cost of *writing* state, as opposed to accessing or executing it: `StateGasCosts`, `COST_PER_STATE_BYTE`, the block-level state gas budget, and the spill path into execution gas.
Score anchors
0
No state gas accounting changes.
1
An existing state gas cost or `STATE_BYTES_PER_*` rate is adjusted.
2
A new state-gas-charging site is introduced, or the block-level state gas budget or reservoir allocation is modified.
3
A new state gas charging mechanism is introduced, or the spill interaction between state gas and execution gas is modified, affecting existing gas tests.
- Harder to test than blob gas: the spill path means state gas cannot be metered independently of execution gas, and some costs (e.g. `NEW_ACCOUNT`) are state-dependent.
New EVM gas refund
New gas-refund mechanism
Score anchors
0
No new gas-refund mechanisms are introduced.
1
A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
2
A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
3
A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.

Blocks, transactions, and encoding

Transaction types and validity, block and header fields, encodings, syncing, and activation-time changes.

New transaction types
Introduces a new transaction type
Score anchors
0
No new transaction types are introduced.
3
A new transaction type is introduced.
New or modified transaction validity mechanisms
Creates new or modifies pre-existing transaction types' validation mechanisms
Score anchors
0
No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
1
Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
2
Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
3
Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
New block / header fields
Introduces new block or block header fields
Score anchors
0
No new block or header fields are introduced.
3
A new block or header field is introduced.
ENC
Encoding changes (RLP/SSZ)
Introduces encoding changes at the transaction/block/interfaces level
Score anchors
0
No encoding changes are introduced at the transaction, block, or interfaces levels.
3
An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
- "Interfaces level" includes the Engine API. Score an Engine API encoding change (e.g. JSON -> SSZ) here.
Block syncing changes
Modifies block RLP validation mechanisms that require test client syncing.
Score anchors
0
No new RLP validation mechanism is introduced.
1
A single simple RLP validation mechanism is introduced.
2
Multiple simple RLP validation mechanisms are introduced or a single complex one.
3
Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
ACT
New fork activation mechanism
Modifies state, internal variables, or similar, at the fork activation block
Score anchors
0
No state modifications, internal variables or similar are modified at the fork activation block.
3
Either a state modification or internal variables are modified at the fork activation block.
- Initialization of new internal variable is not considered a modification.

Client interfaces

Engine API and transition-tool interface changes.

Engine API changes
Introduces new fields to the Engine API directives
Score anchors
0
No new fields or communication mechanisms are introduced to the Engine API.
1
A single new field is introduced in one of the Engine API endpoints.
2
Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
3
Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
Engine API encoding changes · Checklist revision 1 only
Engine API encoding changes (the revision-1 template defines no anchor text for this row).
T8N
Transition-tool interface changes
Modifies or adds new fields to the transition tool interface.
Score anchors
0
No modifications to the transition tool interface are required.
1
A single new field needs to be introduced to the transition tool interface.
2
Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
3
Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
- Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.

Testing impact

Rework, new invariants, and new primitives required in the test framework.

Patterns affecting pre-existing tests
Implements a new validation mechanism or rule that translates in reworking pre-existing tests
Score anchors
0
No pre-existing tests are affected by this change.
1
Minor subset of existing tests are affected by this change.
2
Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
3
Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
INV
New invariant on pre-existing tests · Checklist revision 2 only
Tests that are **not about this EIP** must nonetheless assert something this EIP produces. Their logic does not change; they gain a new thing to check.
Score anchors
0
Pre-existing tests assert nothing new.
1
A narrow, contrived category of pre-existing tests gains a new assertion.
2
A broad category gains a new assertion, applied mechanically.
3
Every test in the fork gains the assertion regardless of what it tests, and pre-fork vectors must be re-derived to satisfy it.
- Paired with the row above, and easy to confuse with it. "Patterns affecting pre-existing tests" asks whether existing tests must be **reworked**; this row asks whether they must **additionally assert something new**. Score both — an EIP can be low on one and high on the other.
New test-framework primitives · Checklist revision 2 only
Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists.
Score anchors
0
Existing test primitives suffice.
1
Existing primitives need minor extension.
2
New expectation or modifier primitives are required, reusable within this EIP's own test suite.
3
New framework-level primitives are required that become a permanent part of the framework and are used by other EIPs' tests.

Risk and validation

Security, performance, boundary conditions, and cryptography that need validation.

Security risks
Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
Score anchors
0
No new mechanisms are introduced that could pose a security risk.
1
The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
2
The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
3
The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
Performance risks
Introduces or modifies mechanisms and requires performance validation.
Score anchors
0
No new mechanisms are introduced that require performance validation.
1
The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
2
The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
3
The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
Edge/boundary conditions
Feature contains edge/boundary conditions.
Score anchors
0
No discernible edge cases or boundary conditions are introduced.
1
A single edge-case or boundary-condition prone mechanism is introduced.
2
Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
3
Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
Cryptography
Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
Score anchors
0
No cryptography mechanisms are introduced.
1
A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
2
Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
3
Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.

Coordination

Cross-EIP interactions and behavior that clients must agree on before tests exist.

XEIP
Cross-EIP interactions
Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
Score anchors
0
Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
1
The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
2
The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
3
The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
- +1 for every 3 additional interacting EIPs beyond the first 3, each of which requires its own coordinated test cases. List the EIPs in the rationale.
- This row is intentionally uncapped, unlike every other anchor: each interacting EIP is another axis of the test matrix, so a ceiling would make a 12-EIP product indistinguishable from a 3-EIP one.
UNSP
Unspecified behavior requiring cross-client consensus · Checklist revision 2 only
The EIP text does not determine the answer for cases a test can construct. Clients must agree on a previously unspecified detail before tests can be baselined. The cost here is coordination and re-baselining, not test writing.
Score anchors
0
The EIP text determines the answer for every case a test could construct.
1
A few details are unspecified but have an obvious intended reading.
2
Details require client agreement before tests can be written, but they are localized.
3
A previously unspecified *and previously unobservable* behavior becomes consensus-critical; expect tests to be re-baselined on each round of EIP amendment.
- Score this from the EIP's state at assessment time: whether it has client implementations, whether it has been through a devnet, and how many open questions remain on its discussion thread.