EIP complexity assessment

EIP-8272: Recent Roots for Frame Transactions

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 39

Human Available in open PRscore 14 · Checklist revision 2· ethspecs/pm #133

LLM · Checklist revision 22026-09-16 · Re-evaluation · 24 LLM · Checklist revision 22026-08-26 · Original snapshot · 39 Human · Checklist revision 2Available in open PR · 14 CompareHuman vs LLM · same checklist revision

Evaluated on: 2026-09-16 · Spec revision: 2026-09-16 · 90194cfa32 · Inclusion status at snapshot: PFI

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

24HighHigh

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: Yes — 3 criteria affected
Plausible range: 23–26 (High)
Snapshot: 2026-08-25 · EIP revision 90194cfa32 (2026-09-16)

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

Plausible total

23–26
recorded score 24 · plausible tiers High

Affected criteria (3)

Added system contracts (2)
Performance risks (3)
Unspecified behavior requiring cross-client consensus (3)

Unresolved questions at the cutoff (3)

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?

Notable ambiguities noted by the assessor (2)

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.

Criterion breakdown

EIP-8272 Hegotá: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
New fork activation mechanism	3	The proposal mandates an irregular first-active-block state transition at a fixed address, directly satisfying the rubric's score-3 activation anchor.	eip.md · Specification > Activation 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. Confidence: High Uncertainty: RECENT_ROOT_CODE is still TBD, so the exact code value written by this otherwise explicit transition is unresolved.
Security risks	3	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.	eip.md · Specification > Public mempool handling 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. eip.md · Security Considerations 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. Confidence: High Uncertainty: The specified mitigations reduce exposure but do not eliminate the multi-component security review surface.
Performance risksUnder-specified	3	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.	eip.md · Specification > Public mempool handling 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. eip.md · Security Considerations Reorganizations or synchronized expiry may evict many transactions sharing a popular root, while dependency indexing is intended to avoid scanning unrelated transactions. eip.md · Specification > Entry and storage keys Persistent storage can grow by up to 8192 keys for each written source_id. Confidence: Medium Uncertainty: The package supplies bounds and mitigations but no workload or benchmark data, and canonical bytecode needed for exact per-frame measurements is TBD.
Edge/boundary conditions	3	Multiple boundary-prone mechanisms compose, and the prefix-shape, tuple, gas, age, activation, and reorganization axes create an elevated case matrix.	eip.md · Test Cases 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. eip.md · Specification > Validation operation Validation combines strict age tests, modulo-8192 ring indexing, tuple hashing, storage equality, and all-tuples-must-pass behavior. Confidence: High Uncertainty: RECENT_ROOT_CODE prevents final bytecode-level boundary vectors, but the specified boundary surface is already clear.
Cross-EIP interactions	3	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.	eip.md · Front matter requires; Specification 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. eip.md · Test Cases 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. Confidence: High Uncertainty: Transitive EIP-8141 dependencies are not counted because EIP-8272 does not directly modify them in the package evidence. Interacting EIPs: EIP-7702, EIP-7843, EIP-8141
Unspecified behavior requiring cross-client consensusUnder-specified	3	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.	eip.md · Specification > Constants RECENT_ROOT_CODE is explicitly listed as TBD. eip.md · Specification > Activation; Specification > Public mempool handling 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. Confidence: High Uncertainty: Functional pseudocode is detailed, but it does not determine the canonical bytecode or its exact gas trace.
Added system contractsUnder-specified	2	Exactly one protocol-installed system contract is added, and it is stateful because ordinary callers can write persistent recent-root entries.	eip.md · Specification > Recent root contract A fixed RECENT_ROOT_ADDRESS exposes write and validation operations and stores per-source ring-buffer entries. eip.md · Specification > Activation Clients install RECENT_ROOT_CODE at activation with nonce and storage conditions. Confidence: High Uncertainty: The contract's canonical runtime bytes are TBD, but its stateful role and activation are explicit.
Patterns affecting pre-existing tests	2	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.	eip.md · Test Cases 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. eip.md · Specification > Public mempool handling Prefix matching must skip optional expiry and recent-root verifier frames, changing how the existing four EIP-8141 prefix shapes are classified. Confidence: High Uncertainty: The package does not quantify the pre-existing EIP-8141 test inventory, so the absolute number of affected vectors is unknown.
New invariant on pre-existing tests	1	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.	eip.md · Specification > Activation The first active block must initialize the fixed account against parent state and is invalid unless the chosen address has empty code and storage. Confidence: Medium Uncertainty: How broadly the activation-account expectation is asserted by the test corpus is not specified.
New test-framework primitives	1	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.	eip.md · Test Cases Tests need recent-root tuple construction, slot-age boundaries, verifier frame variants, activation transitions, direct-evaluation equivalence, and reorganization-driven eviction. supporting/eip-8141.md · Specification > Mempool > Revalidation EIP-8141 already defines dependency-based re-simulation and eviction after canonical-head changes. Confidence: Medium Uncertainty: No test-framework implementation is package evidence, so whether helpers are merely extended or newly introduced cannot be confirmed.

Show 18 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No opcode is introduced.	eip.md · Abstract The proposal explicitly requires no new opcode. eip.md · Specification > Application introspection Applications reuse EIP-8141 FRAMEPARAM, FRAMEDATALOAD, and FRAMEDATACOPY. Uncertainty: No opcode-addition ambiguity is present.
Modified opcodes	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.	eip.md · Specification > Recent root verifier frame Target access, storage reads, and data pricing use existing rules. eip.md · Specification > Public mempool handling SLOTNUM and constrained SLOAD are newly permitted only by public-mempool trace policy while the canonical top-level frame executes. Uncertainty: The distinction is between mempool-policy permission and opcode behavior; only the latter is scored here.
Added precompiles	No precompile is introduced.	eip.md · Specification > Recent root contract; Specification > Activation The feature is deployed as EVM runtime code at an account with nonce and storage, not as a precompile. Uncertainty: The missing runtime bytes do not change the specified account model.
Modified precompiles	No existing precompile logic or gas schedule is modified.	eip.md · Abstract; Specification > Recent root contract The design uses a newly installed ordinary contract and existing frame execution without mentioning any precompile behavior or gas change. Uncertainty: No precompile interaction requiring scoring is package-grounded.
Modified system contracts	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.	eip.md · Specification > Activation The designated address must be absent or have empty code and storage before clients install the new recent-root code. eip.md · Specification > Recent root verifier frame The new frame targets RECENT_ROOT_ADDRESS. Uncertainty: An already-existing empty account may have its nonce updated, but it is not a pre-existing system contract under the rubric's distinction.
EVM Gas rule changes	The proposal creates additional ordinary EVM work but does not introduce or update an EVM gas-accounting rule.	eip.md · Specification > Recent root verifier frame 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. Uncertainty: RECENT_ROOT_CODE is TBD, so exact gas-use vectors cannot yet be fixed, but the specified accounting mechanism remains the existing one.
State-access ordering within opcode execution	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.	eip.md · Specification > Public mempool handling Direct evaluation must reproduce EVM gas use and the same warm account and storage-key updates and rollbacks. eip.md · Specification > Recent root verifier frame Target access and storage reads follow normal warm and cold access rules. Uncertainty: The missing canonical bytecode obscures its concrete trace, not the stated ordering rule for any opcode.
Blob gas accounting changes	No blob gas field, price, limit, accounting path, or existing blob test rule is changed.	eip.md · Specification > Recent root verifier frame The proposal reuses ordinary frame execution and adds no special gas accounting or block-gas exemption. eip.md · Backwards Compatibility The EIP does not change the EIP-8141 transaction payload and does not modify other transaction types. Uncertainty: No blob-gas ambiguity is visible in the package.
State gas accounting changes	Recent-root writes consume state, but the proposal neither changes a state gas rate or budget nor introduces a new state-gas charging mechanism.	eip.md · Rationale > Implicit source creation Writes creating storage entries pay the ordinary state-growth cost. eip.md · Specification > Recent root contract All calls use ordinary EVM execution and gas accounting. Uncertainty: Exact code gas is unresolved, but the specification mandates existing state-growth charging.
New EVM gas refund	The proposal defines no new refund trigger, counter, or settlement rule.	eip.md · Specification > Recent root contract > Write operation A successful write performs an ordinary storage assignment and returns no data or logs. eip.md · Specification > Recent root contract All calls use ordinary EVM execution and gas accounting. Uncertainty: No refund-related under-specification is identified.
New transaction types	No new transaction type is introduced.	eip.md · Abstract; Backwards Compatibility The feature uses EIP-8141 FrameTx without changing its envelope and does not modify other transaction types. Uncertainty: No transaction-type ambiguity is present.
New or modified transaction validity mechanisms	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.	eip.md · Specification > Recent root verifier frame A failed verifier uses EIP-8141's existing rule that a reverting or exceptional VERIFY frame invalidates the transaction. eip.md · Rationale > Fixed early position; Test Cases The fixed position affects public-mempool eligibility, not block validity, and mempool rejection alone does not make a transaction invalid in a block. Uncertainty: Some harnesses may group public-mempool admission under transaction validation, but the EIP explicitly separates that policy from block validity, which controls this score.
New block / header fields	No additional block or header field is introduced by this proposal.	eip.md · Specification > Current slot The proposal reads the EIP-7843 slotNumber field. supporting/eip-7843.md · Specification > RPC changes > Header extension EIP-7843, rather than EIP-8272, defines the slotNumber header field. Uncertainty: The prerequisite field is fully attributable to EIP-7843.
Encoding changes (RLP/SSZ)	The tuple is an application-level encoding inside an existing data field; transaction, block, receipt, and interface RLP/SSZ encodings are unchanged.	eip.md · Abstract; Rationale > Canonical frame instead of an envelope field The design reuses EIP-8141 transaction encoding and puts fixed-length tuples in existing frame data rather than adding an envelope field. eip.md · Backwards Compatibility The EIP-8141 transaction payload and signature hash do not change. Uncertainty: No interface-level encoding change is specified.
Block syncing changes	Activation affects executed state, but EIP-8272 introduces no block RLP validation mechanism, which is the scope of this anchor.	eip.md · Abstract; Backwards Compatibility The proposal changes neither the FrameTx envelope nor other transaction types. eip.md · Specification > Current slot current_slot is read from EIP-7843's existing header field. Uncertainty: No EIP-8272 block-encoding change is specified.
Engine API changes	The necessary Engine API surface belongs to the prerequisite; this proposal adds no further Engine API communication mechanism.	eip.md · Specification > Current slot EIP-8272 consumes slotNumber supplied under EIP-7843 and does not define a new Engine API field or endpoint. supporting/eip-7843.md · Specification > RPC changes > Engine API changes EIP-7843 is the package source that defines the slotNumber-bearing payload and attributes objects and associated Engine API methods. Uncertainty: No incremental Engine API ambiguity is identified.
Transition-tool interface changes	The proposal consumes an already-defined slotNumber and existing fork activation context; it specifies no new transition-tool input or output field.	eip.md · Specification > Current slot Execution clients obtain current_slot from EIP-7843's existing slotNumber field. eip.md · Abstract The feature requires no change to the FrameTx envelope. Uncertainty: The package does not describe a transition-tool binding, but no interface addition is required by the EIP text.
Cryptography	Reuse of the existing keccak256 hash does not introduce or modify a cryptographic mechanism for purposes of this anchor.	eip.md · Specification > Root sources; Specification > Entry and storage keys Source identifiers, entry hashes, and storage keys use domain-separated keccak256 over fixed-length encodings. Uncertainty: Application-specific proofs and privacy commitments are explicitly outside the protocol's opaque bytes32-root semantics.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@90194cfa32 EIPS/eip-8272.md committed 2026-09-16 · information cutoff 2026-09-16T00:38:19Z
Current master · File history · blob 274ce98c57 · sha256 82419d7e5c09
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/evaluations/hegota-2026-09-16-90194cf-eip-8272-v2/assessments/eip-8272.yaml · sha256 7da45eca70de
Supporting documents in the sealed package: supporting/eip-7702.md, supporting/eip-7843.md, supporting/eip-8141.md

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 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.

39HighHigh

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: Yes — 6 criteria affected
Plausible range: 35–40 (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.

Top complexity drivers

Modified opcodes3
EVM Gas rule changes3
New or modified transaction validity mechanisms3
Encoding changes (RLP/SSZ)3

Under-specified at assessment cutoff: Yes

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

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

Plausible total

35–40
recorded score 39 · plausible tiers High

Affected criteria (6)

Added system contracts (2)
EVM Gas rule changes (3)
New fork activation mechanism (3)
Patterns affecting pre-existing tests (3)
Performance risks (3)
Unspecified behavior requiring cross-client consensus (2)

Unresolved questions at the cutoff (3)

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?

Notable ambiguities noted by the assessor (2)

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.

Criterion breakdown

EIP-8272 Hegotá: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Modified opcodes	3	Adding a previously undefined successful TXPARAM index modifies the result behavior of an existing opcode, which maps to the rubric's binary score 3.	eip.md · Specification > TXPARAM and RECENTROOTREFLOAD Adds TXPARAM_RECENT_ROOT_REFERENCE_COUNT at index 0x0F to the existing EIP-8141 TXPARAM instruction. supporting/eip-8141.md · Specification > Introspection > TXPARAM Instruction Defines the pre-existing TXPARAM parameter mapping and exceptional behavior for undefined indices. Confidence: High Uncertainty: No gas change to TXPARAM is counted; the score is solely for its modified result behavior.
EVM Gas rule changesUnder-specified	3	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.	eip.md · Specification > Gas accounting Defines per-reference intrinsic gas and adds reference calldata cost, intrinsic gas, and calldata tokens to EIP-8141 gas quantities. supporting/eip-8141.md · Specification > Frame Transaction > Gas Accounting Defines the existing standard gas limit, calldata floor, max gas, and settlement quantities that EIP-8272 changes. Confidence: High Uncertainty: 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.
New or modified transaction validity mechanisms	3	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.	eip.md · Specification > Static validity Adds structural decoder validity for the new field, tuple shape, lengths, canonical uint64 slots, and maximum count. eip.md · Specification > Reference validity Adds state-dependent, current-slot-dependent checks against transaction pre-state that invalidate the transaction and containing block on failure. eip.md · Specification > Gas accounting Modifies intrinsic gas and calldata-floor quantities used by frame transaction validity and settlement. Confidence: High Uncertainty: RECENT_ROOT_CODE prevents final call-level vectors but does not reduce the breadth of the specified transaction validity changes.
Encoding changes (RLP/SSZ)	3	The RLP encoding of an existing transaction type and its signing payload are changed, which maps to the rubric's binary score 3.	eip.md · Specification > Transaction payload Inserts recent_root_references into the RLP frame-transaction payload and canonical signing payload, with a new nested tuple encoding. eip.md · Specification > Static validity Adds decoder rejection rules for the new RLP list and element encodings. Confidence: High Uncertainty: The position, shape, and canonical integer requirements are explicitly specified.
New fork activation mechanismUnder-specified	3	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.	eip.md · Specification > Activation 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. Confidence: High Uncertainty: FORK_TIMESTAMP and RECENT_ROOT_CODE are TBD, so the mechanism is clear but its concrete activation configuration and installed bytes are not final.
Patterns affecting pre-existing testsUnder-specified	3	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.	eip.md · Specification > Transaction payload Inserts a mandatory field into the existing frame-transaction payload and changes the canonical signing payload. eip.md · Specification > Gas accounting Changes gas quantities even when the new reference list is represented in an otherwise existing frame-transaction test. eip.md · Specification > Activation Changes the accepted payload and signature domain across the activation boundary and requires pre-fork transactions to be regenerated. Confidence: Medium Uncertainty: The package contains no test inventory; breadth is derived from the proposal's normative changes to every post-activation frame-transaction envelope.
Security risks	3	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.	eip.md · Specification > Reference validity; Public mempool handling Makes transaction and block validity depend on recent system-contract state and requires recheck/eviction across head, slot, and reorg changes. eip.md · Security Considerations Identifies application tuple binding, last-write-wins roots, publication availability, cross-chain domain binding, and persistent-state-growth responsibilities. eip.md · Specification > Transaction payload Commits references through the canonical frame-transaction signature hash and forbids frames from changing the reference set. Confidence: Medium Uncertainty: Application proof systems remain outside execution consensus, and exact system-contract bytecode is TBD; neither removes the specified critical execution-layer interactions.
Performance risksUnder-specified	3	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.	eip.md · Specification > Reference validity; Bounded validation work Adds up to sixteen pre-execution storage checks with two Keccak computations per reference and explicitly bounds the validation work. eip.md · Specification > Public mempool handling Requires indexing by reference and expiry plus rechecks on head change, slot advance, and relevant reorgs. eip.md · Rationale > Implicit source creation; Security Considerations Bounds each source's rolling storage but permits aggregate storage to grow linearly with newly written source identifiers. Confidence: Medium Uncertainty: 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.
Edge/boundary conditions	3	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.	eip.md · Specification > Static validity; Reference validity Defines list-length, tuple-shape, byte-length, uint64, slot-window, pre-state, duplicate, and invalid-block boundaries. eip.md · Specification > Recent root contract Defines exact calldata/value/static/delegated-call failure cases, modulo indexing, repeated writes, and last-write-wins behavior. eip.md · Specification > Activation Adds timestamp-boundary, pre-existing-account, and reorg-across-fork cases. Confidence: High Uncertainty: Exact system-contract bytecode may add gas-boundary cases, but the specified cases already independently satisfy anchor 3.
Cross-EIP interactions	3	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.	eip.md · Front matter requires; Specification > Current slot; Transaction payload; Gas accounting Declares dependencies on EIPs 7623, 7843, and 8141, consuming slotNumber and modifying the EIP-8141 payload, signature, and EIP-7623-derived gas quantities. eip.md · Backwards Compatibility Defines how an EIP-7702-delegated EOA may act as a root source while not modifying other EIP-7702 transaction behavior. supporting/eip-8141.md · Specification > Frame Transaction; Introspection Supplies the transaction type, gas model, TXPARAM opcode, and opcode space that EIP-8272 directly extends. Confidence: High Uncertainty: Only direct interactions grounded in the allowlisted package are counted; transitive dependencies of EIP-8141 are not inferred as additional axes. Interacting EIPs: EIP-7623, EIP-7702, EIP-7843, EIP-8141
Added opcodes	2	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.	eip.md · Specification > TXPARAM and RECENTROOTREFLOAD Adds RECENTROOTREFLOAD at 0xB5 with two stack inputs, indexed structured envelope access, three selectable fields, and exceptional-halt bounds. Confidence: High Uncertainty: The opcode has constant gas, but its data access makes it complex by the rubric definition.
Added system contractsUnder-specified	2	One new stateful system contract is introduced. A single stateful system contract maps directly to anchor 2.	eip.md · Specification > Recent root contract Defines a contract at RECENT_ROOT_ADDRESS that accepts writes and stores entry hashes in persistent storage. eip.md · Specification > Activation Requires clients to create or initialize the account with code, nonce, and storage conditions at activation. Confidence: High Uncertainty: RECENT_ROOT_CODE is TBD, preventing exact code-level tests, but statefulness and the activation transition are unambiguous.
Unspecified behavior requiring cross-client consensusUnder-specified	2	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.	eip.md · Specification > Constants Sets FORK_TIMESTAMP and RECENT_ROOT_CODE to TBD. eip.md · Specification > Recent root contract; Activation Gives abstract call and initialization behavior but requires installation of the still-unspecified RECENT_ROOT_CODE under consensus rules. Confidence: High Uncertainty: The abstract storage and reference-check algorithms are detailed; the open consensus artifact is principally the concrete contract code and activation value.
New invariant on pre-existing tests	1	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.	eip.md · Specification > Activation Requires the activation block to create or initialize RECENT_ROOT_ADDRESS before executing any transaction. Confidence: Medium Uncertainty: The package does not describe how test vectors expose implicit activation state, so the score is limited to the clearly required narrow invariant.
New test-framework primitives	1	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.	eip.md · Specification > Transaction payload Adds a bounded list of structured source_id, slot, and root tuples to an existing transaction envelope. eip.md · Specification > TXPARAM and RECENTROOTREFLOAD Adds transaction introspection surfaces with indexed field access and exceptional-halt cases. Confidence: Low Uncertainty: The sealed sources specify protocol behavior, not the test framework's current primitive set, so only the minimal required extension is scored.
Cryptography	1	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.	eip.md · Specification > Root sources; Entry and storage keys Defines domain-separated Keccak-256 derivations for source identifiers, committed entries, and storage keys. eip.md · Security Considerations Treats roots as opaque and assigns application proof binding outside the execution-layer consensus mechanism. Confidence: High Uncertainty: Application-specific commitments are intentionally unspecified and are not counted as protocol cryptography.

Show 12 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added precompiles	No new precompile is introduced.	eip.md · Specification > Constants; Recent root contract; TXPARAM and RECENTROOTREFLOAD Enumerates a system-contract address, contract behavior, and opcode changes, with no precompile addition. Uncertainty: RECENT_ROOT_ADDRESS is expressly a system contract, not a precompile.
Modified precompiles	No existing precompile logic or gas schedule is modified.	eip.md · Specification > Recent root contract; TXPARAM and RECENTROOTREFLOAD Defines the execution additions entirely as a system contract, transaction checks, and opcodes. Uncertainty: No precompile is named by the proposal.
Modified system contracts	The activation handling creates or installs the new EIP-8272 system contract. It does not directly or indirectly modify a pre-existing system contract.	eip.md · Specification > Activation Installs the new recent-root contract only where the selected address has empty code and empty storage; no existing system contract is named. Uncertainty: No pre-existing system-contract dependency is identified.
State-access ordering within opcode execution	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.	eip.md · Specification > Reference validity Places recent-root storage checks after the nonce check and before frame execution, outside opcode execution. eip.md · Specification > TXPARAM and RECENTROOTREFLOAD States that RECENTROOTREFLOAD reads only signed-envelope fields and does not read recent-root contract storage. Uncertainty: No material uncertainty for this anchor in the sealed text.
Blob gas accounting changes	The blob hash field is only an insertion point in the payload. No blob gas price, limit, usage, or fee-accounting rule is changed.	eip.md · Specification > Transaction payload Inserts recent_root_references after blob_versioned_hashes and states that no other payload field is changed. eip.md · Specification > Gas accounting Changes execution/calldata gas quantities while leaving EIP-8141 max_gas, gas_used, and fee settlement definitions in place. Uncertainty: No blob-gas behavior is left open by the proposal.
State gas accounting changes	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.	eip.md · Specification > Recent root contract Specifies ordinary storage writes and says successful calls follow normal EVM execution and gas accounting. eip.md · Security Considerations Describes persistent state growth and leaves any future registration or first-write surcharge to a future version. Uncertainty: The system-contract bytecode is TBD, but the normative text explicitly assigns its writes normal accounting rather than a new state-gas mechanism.
New EVM gas refund	No gas-refund mechanism is introduced or modified.	eip.md · Specification > Gas accounting Defines additive intrinsic and calldata charges without defining a refund counter change or refund condition. Uncertainty: No material uncertainty for this anchor in the sealed text.
New transaction types	EIP-8272 modifies FRAME_TX_TYPE; it does not allocate or introduce another transaction type.	eip.md · Specification > Transaction payload Applies the new field to the pre-existing EIP-8141 FRAME_TX_TYPE payload and states that the frame layout is otherwise unchanged. Uncertainty: No new transaction type identifier is defined.
New block / header fields	EIP-8272 consumes a prerequisite's header field and adds none of its own.	eip.md · Specification > Current slot Requires the slotNumber field supplied by EIP-7843 rather than defining a new header field. supporting/eip-7843.md · Specification > RPC changes > Header extension Attributes the slotNumber header extension to EIP-7843. Uncertainty: The dependency is scored under cross-EIP interactions.
Block syncing changes	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.	eip.md · Specification > Transaction payload; Static validity Limits the new RLP schema and decoder rejection rules to the existing frame transaction payload. Uncertainty: No block-RLP change is specified in the package.
Engine API changes	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.	eip.md · Specification > Current slot Consumes slotNumber from EIP-7843 and forbids deriving the slot from the timestamp. supporting/eip-7843.md · Specification > RPC changes > Engine API changes Assigns the slotNumber Engine API objects and methods to EIP-7843. Uncertainty: No EIP-8272-specific Engine API delta is specified.
Transition-tool interface changes	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.	eip.md · Specification > Current slot Requires clients to consume the existing EIP-7843 slotNumber field for block validation. eip.md · Specification > Activation Defines activation from block timestamp without specifying a new transition-tool input or output field. Uncertainty: Transition-tool implementation details are absent from the package; no interface change may be inferred beyond the normative EIP text.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@ac450a4ab2 EIPS/eip-8272.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z
Current master · File history · blob 1ff890ed8c · sha256 f9b4e2cadc23
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-8272.yaml · sha256 4bb84d6b442b
Supporting documents in the sealed package: supporting/eip-7623.md, supporting/eip-7702.md, supporting/eip-7843.md, supporting/eip-8141.md

Evaluated on: Not recorded

14MediumMedium

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

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

Edge/boundary conditions3
New or modified transaction validity mechanisms2
Cross-EIP interactions2
Added opcodes1

Criterion breakdown

EIP-8272 Hegotá: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
Edge/boundary conditions	3	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	—
New or modified transaction validity mechanisms	2	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.	—
Cross-EIP interactions	2	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.	—
Added opcodes	1	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.	—
Added system contracts	1	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.	—
EVM Gas rule changes	1	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.	—
State-access ordering within opcode execution	1	The frame transaction now conditionally accesses the storage of `RECENT_ROOT_ADDRESS` before execution of any of the frames.	—
New fork activation mechanism	1	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.	—
New test-framework primitives	1	New helpers required to construct the `recent_root_references` embedded in the transactions. Also to register them in the `RECENT_ROOT_ADDRESS` contract.	—
Performance risks	1	Requires testing worst-case block filled with transactions consuming block limit using `MAX_RECENT_ROOT_REFERENCES`.	—

Show 18 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Notes
Modified opcodes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Added precompiles	No rationale recorded.	Blank cell read as zero because the published total proves it.
Modified precompiles	No rationale recorded.	Blank cell read as zero because the published total proves it.
Modified system contracts	No rationale recorded.	Blank cell read as zero because the published total proves it.
Blob gas accounting changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
State gas accounting changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
New EVM gas refund	No rationale recorded.	Blank cell read as zero because the published total proves it.
New transaction types	No rationale recorded.	Blank cell read as zero because the published total proves it.
New block / header fields	No rationale recorded.	Blank cell read as zero because the published total proves it.
Encoding changes (RLP/SSZ)	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.	—
Block syncing changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Engine API changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Transition-tool interface changes	No rationale recorded.	Blank cell read as zero because the published total proves it.
Patterns affecting pre-existing tests	No rationale recorded.	Blank cell read as zero because the published total proves it.
New invariant on pre-existing tests	No rationale recorded.	Blank cell read as zero because the published total proves it.
Security risks	No rationale recorded.	—
Cryptography	No rationale recorded.	Blank cell read as zero because the published total proves it.
Unspecified behavior requiring cross-client consensus	No major underspecification identified.	—

Assessment provenance

Rubric: Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Open pull request #133: Add EIP-8272 complexity assessment · checklist at d54b36561f · updated 2026-08-25
blob 81aae13863 · sha256 9164c943cf8a
Research record: research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8272.yaml · sha256 ae44c7312e99

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

Using the latest scored LLM evaluation for this checklist: 2026-09-16 · spec 2026-09-16 · 90194cfa32. The Human and LLM assessments may use different spec revisions.

LLM24High

Human14Medium

Δ total+10Tiers differ: High vs Medium

Criteria16/28agree exactly · 6 differ by 1 · 6 differ by 2+

Complexity profiles side by side

LLM

Human

Largest disagreements: Security risks (+3), Unspecified behavior requiring cross-client consensus (+3), Patterns affecting pre-existing tests (+2), New or modified transaction validity mechanisms (−2), New fork activation mechanism (+2)

Show differences only (12 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
Security risks	3	0	+3	Differ by 2+	Show rationale LLM 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. Human No rationale recorded.
Unspecified behavior requiring cross-client consensus	3	0	+3	Differ by 2+	Show rationale LLM 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. Human No major underspecification identified.
New or modified transaction validity mechanisms	0	2	−2	Differ by 2+	Show rationale LLM 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. Human 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.
New fork activation mechanism	3	1	+2	Differ by 2+	Show rationale LLM The proposal mandates an irregular first-active-block state transition at a fixed address, directly satisfying the rubric's score-3 activation anchor. Human 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.
Patterns affecting pre-existing tests	2	0	+2	Differ by 2+	Show rationale LLM 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. Human No rationale recorded.
Performance risks	3	1	+2	Differ by 2+	Show rationale LLM 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. Human Requires testing worst-case block filled with transactions consuming block limit using `MAX_RECENT_ROOT_REFERENCES`.
Added opcodes	0	1	−1	Differ by 1	Show rationale LLM No opcode is introduced. Human 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.
Added system contracts	2	1	+1	Differ by 1	Show rationale LLM Exactly one protocol-installed system contract is added, and it is stateful because ordinary callers can write persistent recent-root entries. Human 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.
EVM Gas rule changes	0	1	−1	Differ by 1	Show rationale LLM The proposal creates additional ordinary EVM work but does not introduce or update an EVM gas-accounting rule. Human 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.
State-access ordering within opcode execution	0	1	−1	Differ by 1	Show rationale LLM 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. Human The frame transaction now conditionally accesses the storage of `RECENT_ROOT_ADDRESS` before execution of any of the frames.
New invariant on pre-existing tests	1	0	+1	Differ by 1	Show rationale LLM 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. Human No rationale recorded.
Cross-EIP interactions	3	2	+1	Differ by 1	Show rationale LLM 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. Human 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.
Modified opcodes	0	0	0	Agree	Show rationale LLM 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. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM No precompile is introduced. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM No existing precompile logic or gas schedule is modified. Human No rationale recorded.
Modified system contracts	0	0	0	Agree	Show rationale LLM 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. Human No rationale recorded.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM No blob gas field, price, limit, accounting path, or existing blob test rule is changed. Human No rationale recorded.
State gas accounting changes	0	0	0	Agree	Show rationale LLM Recent-root writes consume state, but the proposal neither changes a state gas rate or budget nor introduces a new state-gas charging mechanism. Human No rationale recorded.
New EVM gas refund	0	0	0	Agree	Show rationale LLM The proposal defines no new refund trigger, counter, or settlement rule. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM No new transaction type is introduced. Human No rationale recorded.
New block / header fields	0	0	0	Agree	Show rationale LLM No additional block or header field is introduced by this proposal. Human No rationale recorded.
Encoding changes (RLP/SSZ)	0	0	0	Agree	Show rationale LLM The tuple is an application-level encoding inside an existing data field; transaction, block, receipt, and interface RLP/SSZ encodings are unchanged. Human 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.
Block syncing changes	0	0	0	Agree	Show rationale LLM Activation affects executed state, but EIP-8272 introduces no block RLP validation mechanism, which is the scope of this anchor. Human No rationale recorded.
Engine API changes	0	0	0	Agree	Show rationale LLM The necessary Engine API surface belongs to the prerequisite; this proposal adds no further Engine API communication mechanism. Human No rationale recorded.
Transition-tool interface changes	0	0	0	Agree	Show rationale LLM The proposal consumes an already-defined slotNumber and existing fork activation context; it specifies no new transition-tool input or output field. Human No rationale recorded.
New test-framework primitives	1	1	0	Agree	Show rationale LLM 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. Human New helpers required to construct the `recent_root_references` embedded in the transactions. Also to register them in the `RECENT_ROOT_ADDRESS` contract.
Edge/boundary conditions	3	3	0	Agree	Show rationale LLM Multiple boundary-prone mechanisms compose, and the prefix-shape, tuple, gas, age, activation, and reorganization axes create an elevated case matrix. Human 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
Cryptography	0	0	0	Agree	Show rationale LLM Reuse of the existing keccak256 hash does not introduce or modify a cryptographic mechanism for purposes of this anchor. Human No rationale recorded.

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