EIP complexity assessment

EIP-8250: Keyed Nonces 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-10-07EIP-8081: CFILayers: execution

LLM Completescore 42

Human Draft PRscore 22 · Checklist revision 2· ethspecs/pm #111 (draft)

LLM · Checklist revision 32026-10-08 · Opus 5.5 · snapshot · 42 Human · Checklist revision 2Draft PR · 22 CompareHuman vs LLM · shared criteria

Evaluated on: 2026-10-08 · Spec revision: 2026-10-07 · 6dac5e7491 · EIP-8081 list: CFI

Scope at the cutoff. EIP-8250 changes the EIP-8141 frame transaction payload. The single `nonce` becomes `nonce_keys`, a strictly increasing list of 1 to 16 uint256 keys, plus a shared uint64 `nonce_seq`. `nonce_keys == [0]` keeps using the legacy account nonce. Non-zero keys are stored in a new revert-only system contract, NONCE_MANAGER at 0x…8250, at slot keccak256(sender||key). The protocol checks these sequences for stateful validity and consumes them when a payment-scoped APPROVE succeeds. Each first-use slot costs EIP-8037 state gas, and these accesses do not count toward EIP-2929 warmth or EIP-2200 SSTORE pricing. The EIP also prices the nonce bytes as calldata, makes TXPARAM(0x01) return nonce_seq, adds TXPARAM selectors 0x0D–0x10, and installs NONCE_MANAGER at fork activation. Mempool identity and revalidation rules are updated to match.

42HighHigh

Evaluator: LLMChecklist v3
Confidence: Medium
Under-specified at assessment cutoff: Yes — 3 criteria affected
Plausible range: 41–44 (High)
Snapshot: 2026-10-07 · EIP revision 6dac5e7491 (2026-10-07)

Score bands · Checklist revision 3

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
New or modified transaction validity mechanisms3
Encoding changes (RLP/SSZ)3
New fork activation mechanism3

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 rules for floor-token accounting of the nonce bytes, and whether the nonce calldata cost enters frame_tx_intrinsic_gas (EIP-7825 cap and block execution reservation), are ambiguous. Activation semantics for chains whose genesis is at or after the fork, and block-level access list recording of protocol keyed-nonce accesses, are not addressed.

Plausible total

41–44
recorded score 42 · plausible tiers High

Affected criteria (3)

State-access ordering within opcode execution (1)
Block syncing changes (2)
New invariant on pre-existing tests (2)

Unresolved questions at the cutoff (4)

Is the nonce_calldata floor contribution tokens_in or floor_tokens_in? EIP-8141 has no `calldata_tokens` variable.
Does nonce_calldata_cost count toward frame_tx_intrinsic_gas for the EIP-7825 cap and the execution_reservation inclusion check?
Are NONCE_MANAGER reads and writes made by stateful validity and APPROVE recorded in EIP-7928 block-level access lists?
How is NONCE_MANAGER installed when a chain activates the fork at genesis, where no parent block is pre-fork?

Notable ambiguities noted by the assessor (4)

The target says to add nonce tokens to `calldata_tokens`, but EIP-8141 uses calldata_floor_tokens computed with floor_tokens_in.
nonce_calldata_cost is added to standard_gas_limit only. Its effect on the EIP-7825 cap and the block reservation is unclear.
Block-level access list treatment of keyed-nonce protocol accesses is unstated.
Activation at genesis is not covered.

Criterion breakdown

EIP-8250 Hegotá: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Modified opcodes	3	The semantics of the TXPARAM and APPROVE instructions change, which fits level 3.	eip.md · Transaction introspection — TXPARAM 0x0D–0x10 and "`TXPARAM(0x01)` returns `tx.nonce_seq`" Adds new TXPARAM selectors and changes the meaning of an existing one. eip.md · Nonce consumption — consume_nonce_set / exceptional halt conditions APPROVE's state effects and halt conditions change. Confidence: High
New or modified transaction validity mechanisms	3	The replay/nonce validity dependency moves from a single account nonce to multi-domain storage state. Tests must restructure sender-nonce handling and use coordinated multi-transaction block scenarios: overlapping and disjoint key sets, mixes of [0] and keyed transactions, and legacy-nonce changes through CREATE. That fits level 3.	eip.md · Stateful validity — "for nonce_key in tx.nonce_keys: assert tx.nonce_seq == current_nonce_seq" Validity now depends on system-contract storage for each selected key. eip.md · Stateful validity — "two frame transactions whose selected key sets overlap ... valid in one block only if" Same-sender transactions in one block depend on each other through key ordering. eip.md · Transaction payload — decoder rejection list; nonce_calldata pricing New structural validity rules and changed gas limits. Confidence: Medium Uncertainty: Whether the nonce calldata cost affects the EIP-7825 cap and block reservation checks is unspecified.
Encoding changes (RLP/SSZ)	3	The serialized EL transaction schema changes, which fits level 3.	eip.md · Transaction payload — "[chain_id, nonce_keys, nonce_seq, sender, frames, signatures, fees, blob_versioned_hashes]" The frame transaction RLP schema changes: a list field and a uint64 field replace nonce. Confidence: High
New fork activation mechanism	3	Protocol-mandated code installation at activation, which fits level 3.	eip.md · Activation — "before any transaction in `B` runs, clients MUST initialize `NONCE_MANAGER`" A one-time installation of code and nonce at the fork block, with handling for an existing balance or account, and reorg undo. Confidence: High
Patterns affecting pre-existing tests	3	One common change, the payload schema plus priced nonce bytes, forces ordinary-case rework across distinct EIP-8141 test families after the fork. These include encoding and signature-hash, validity, APPROVE, TXPARAM, gas and fee settlement, and receipts. That fits level 3.	eip.md · Transaction payload — "replaces the `nonce` field ... with two consecutive fields" Every post-fork frame transaction must be re-encoded and re-signed with nonce_keys and nonce_seq. eip.md · Transaction payload — nonce_calldata pricing The gas and fee results of all frame transactions change because the nonce bytes are now priced. eip.md · Nonce consumption — "EIP-8141's payment-approval transition currently increments ... This EIP replaces" The APPROVE nonce increment and the sender-creation charge are restructured. eip.md · Transaction introspection — "`TXPARAM(0x01)` returns `tx.nonce_seq`" The meaning of the TXPARAM nonce selector changes. Confidence: Medium Uncertainty: If EIP-8141 and this EIP activate in the same fork, some of this is authoring the prerequisite suite directly in the new format, which would argue for 2.
Security risks	3	The shared replay and authorization invariant changes across consensus validity, the APPROVE transition, mempool identity and revalidation, and contract verifiers. This needs coordinated adversarial scenarios, which fits level 3.	eip.md · Security Considerations — "Replay protection is scoped to `(sender, nonce_keys, nonce_seq)`" The replay-protection invariant changes. eip.md · Backwards Compatibility — "Verifier code that previously assumed `TXPARAM(0x01)` is the legacy account nonce MUST" Assumptions in existing verifier contracts break. eip.md · Security Considerations — CREATE address / cancellation strategy / unauthorized keys New failure modes: CREATE-address malleability, ineffective legacy cancellation, and key-set injection. eip.md · Nonce consumption — "MUST NOT revert it unless the transaction is invalid" Spent-once atomicity across frame, batch and validation-prefix rollbacks. Confidence: Medium
Edge/boundary conditions	3	Several boundary-sensitive mechanisms are introduced. The APPROVE state-gas check is an elevated matrix: frame limits.state × number of keys × how many keys are fresh vs. used × [0]-with-nonexistent-sender × approval scope 0x1/0x3 × VERIFY (makes the tx invalid) vs. non-VERIFY frame. That fits level 3.	eip.md · Transaction payload — decoder rejection list Boundaries for 1–16 keys, key < 2256, nonce_seq < 264, strictly increasing keys, and the zero-key-only-alone rule. eip.md · Stateful validity — "assert tx.nonce_seq < MAX_NONCE_SEQ" An exhausted key at 264-1 cannot be used. eip.md · Nonce consumption — "would make `state[sender].nonce > MAX_NONCE_SEQ`" Legacy nonce overflow on increment causes an exceptional halt. eip.md · Nonce consumption — steps 1-2 "If `state_gas_left < nonce_state_gas`" The state-gas sufficiency boundary depends on first_use_count. eip.md · Activation — FORK_TIMESTAMP Timestamp boundary for the schema and logic switch. Confidence:** High
Cross-EIP interactions	3	The target couples EIP-8141 transaction and APPROVE behavior with EIP-8037 state gas, EIP-7623 floor pricing, and EIP-2929 warmth. Coordinated scenarios are needed across these interactions, which fits level 3.	eip.md · Nonce consumption — steps 1-5 Couples the EIP-8141 APPROVE semantics with EIP-8037 state-gas charging and the existence rule. eip.md · Nonce consumption — "do NOT add `NONCE_MANAGER` ... EIP-2929 ... EIP-2200" Explicit exemptions from access-set warming and SSTORE pricing. eip.md · Transaction payload — priced "under EIP-7623" The nonce bytes participate in the calldata floor. Confidence: High Uncertainty: Interactions with EIP-7928 and EIP-7976 are suggested by the supporting texts but not established by the target. Interacting EIPs: EIP-8141, EIP-8037, EIP-7623, EIP-2929, EIP-2200
Added system contracts	2	Exactly one contract is introduced, and it is stateful, which fits level 2.	eip.md · Constants — NONCE_MANAGER / NONCE_MANAGER_CODE One protocol-designated contract with revert-only code. eip.md · Nonce state — "Only the protocol writes keyed-nonce slots" The contract holds persistent protocol-managed storage. Confidence: High
State gas accounting changes	2	A new charging site (APPROVE keyed-slot creation) uses the existing EIP-8037 state-gas mechanism and frame state pools. No new mechanism and no change to spill between pools, which fits level 2.	eip.md · Constants — KEYED_NONCE_FIRST_USE_STATE_GAS Each fresh key costs STATE_BYTES_PER_STORAGE_SETCPSB (97920) state gas. eip.md · Nonce consumption — steps 1-3 State gas is charged inside APPROVE from state_gas_left: KEYED_NONCE_FIRST_USE_STATE_GAS times first_use_count, or the account-creation charge for [0]. It counts toward the transaction and block state-gas totals. eip.md · Mempool — "Structural Rule 6 also allows a `VERIFY` frame to use state gas" The mempool budget rule now admits state gas for keyed-slot creation. supporting/eip-8037.md · Gas accounting for SSTORE (opcode-level) Baseline per-slot state-gas pricing that the target reuses. Confidence:* High
Block syncing changesUnder-specified	2	Several simple structural decode rules are added for frame transactions in imported blocks, which fits level 2.	eip.md · Transaction payload — "Decoders MUST reject a `FRAME_TX_TYPE` transaction" Several new structural decode rules for the transactions in block bodies. eip.md · Activation — "If `timestamp >= FORK_TIMESTAMP`, clients MUST replace `nonce`" The schema used for block decoding depends on the block timestamp. Confidence: Low Uncertainty: The timestamp-dependent schema selection could count as a complex rule (level 3). Alternatively, these rules could be attributed only to transaction validity.
Transition-tool interface changes	2	Several transaction fields change (nonce removed; nonce_keys and nonce_seq added) without a new exchange mechanism. That fits level 2.	eip.md · Transaction payload The frame transaction input replaces `nonce` with the two fields `nonce_keys` and `nonce_seq`. eip.md · Activation — "whose parent has `parent.timestamp < FORK_TIMESTAMP`" A parent-timestamp-dependent installation is needed for fork-transition blocks. Confidence: Medium Uncertainty: No t8n interface documentation was supplied. Whether parent-timestamp input already exists cannot be verified.
New invariant on pre-existing testsUnder-specified	2	Post-fork state must include the NONCE_MANAGER account, which affects state-root expectations for fork-transition and fork tests. Keyed storage writes are new-feature outputs. No pre-fork vectors need re-deriving, which fits level 2.	eip.md · Activation — "clients MUST initialize `NONCE_MANAGER` with `NONCE_MANAGER_CODE`, nonce `1`" A new protocol-mandated account appears in post-fork state. eip.md · Nonce state — slot(sender, nonce_key) Keyed transactions produce protocol-mandated storage writes under NONCE_MANAGER. Confidence: Medium Uncertainty: How genesis-at-fork test networks install NONCE_MANAGER is not specified. If it is pre-allocated, the effect is narrower (level 1).
New test-framework primitives	2	Tests need a construction abstraction for keyed nonce domains. It must compute NONCE_MANAGER slots, pre-populate them, and track sequences per key instead of auto-incrementing the account nonce. It must also produce frame transactions with key sets. This is a new abstraction within the target suite, but not a shared facility that changes other families, which fits level 2.	eip.md · Nonce state — current_nonce_seq Nonce state now lives in per-(sender, key) storage domains under a system contract, not only the account nonce. eip.md · Transaction introspection — nonce_keys_hash Verifier test contracts need a helper to compute the canonical key-set hash. Confidence: Medium Uncertainty: If existing frame-transaction builders are easily extensible, this could be a local extension (level 1).
Performance risks	2	Targeted integrated benchmarks are needed for blocks full of max-key frame transactions. Their uncharged storage reads and writes all concentrate on one huge contract storage trie. This is a bounded interaction, which fits level 2.	eip.md · Nonce consumption — "are protocol bookkeeping: they do NOT add ... are NOT charged" Up to 16 storage reads at validity time, plus up to 16 reads and writes at APPROVE, with no execution-gas access charge. eip.md · Security Considerations — "entries are never deleted" The NONCE_MANAGER storage trie grows without bound and is limited only by state gas. eip.md · Mempool — "Nodes MUST revalidate a pending transaction when any of its selected nonce sequences changes" Mempool revalidation now tracks per-key dependencies. Confidence: Medium Uncertainty: The costs of invalid-transaction storage reads in the mempool are not quantified.
Unspecified behavior requiring cross-client consensus	2	Localized competing gas outcomes need agreement: floor token counting for the nonce bytes, and whether the nonce cost enters intrinsic gas for the cap and reservation. That fits level 2.	eip.md · Transaction payload — "add `nonce_calldata_tokens` to `calldata_tokens`" EIP-8141 defines calldata_floor_tokens using floor_tokens_in, not a `calldata_tokens` built with tokens_in. Which floor-token count applies to the nonce bytes is ambiguous. supporting/eip-8141.md · Gas Accounting — calldata_floor_tokens / Constraints EIP-7825 cap The cap and the block execution_reservation use frame_tx_intrinsic_gas, which the target does not explicitly extend. eip.md · Activation Installation is defined only for a block whose parent is pre-fork. Fork-at-genesis and recording in block-level access lists are not addressed. Confidence: Medium Uncertainty: EIP-7928 was not supplied, so the access-list point is an evidence gap rather than a confirmed omission.
EVM Gas rule changes	1	Existing frame-transaction gas formulas gain new inputs: the nonce calldata cost and tokens. This shifts the expected gas of every frame transaction, but no new execution-gas accounting mechanism is introduced. The access exemption is an exclusion, not a new mechanism. That fits level 1.	eip.md · Transaction payload — "add `nonce_calldata_cost` to `standard_gas_limit`" The nonce fields are now priced as transaction data under the existing EIP-8141/EIP-7623 calldata pricing, which changes the gas totals of frame transactions. eip.md · Nonce consumption — "are NOT charged under EIP-2200 `SSTORE` pricing" Keyed-nonce reads and writes are exempt from execution-gas access and SSTORE charges. supporting/eip-8141.md · Gas Accounting — standard_gas_limit / calldata_floor_gas These are the baseline formulas that the target extends with new inputs. Confidence: Medium Uncertainty: It is unclear whether the nonce calldata cost also enters frame_tx_intrinsic_gas for the EIP-7825 cap and the block execution_reservation. It is also unclear which token count feeds the floor. Neither question changes the level.
State-access ordering within opcode executionUnder-specified	1	Only APPROVE, a prerequisite instruction, has its state-access and charge ordering changed: up to 16 storage reads are inserted before its state-gas charge. No general class-wide ordering rule changes, which fits level 1.	eip.md · Nonce consumption — "Only after those checks and costs succeed, and before any approval effect is committed" Defines a new sequence for APPROVE: approval checks, execution gas and memory first; then read the selected slots, compute and check state gas, charge it, consume the nonce and commit. eip.md · Nonce consumption — "do NOT add `NONCE_MANAGER` or its slots to EIP-2929 `accessed_addresses`" Protocol keyed-nonce accesses do not warm the address or slots. Confidence: Medium Uncertainty: The EIP does not say whether these protocol reads and writes are recorded in EIP-7928 block-level access lists. If a new recordable-access rule is needed, the score could reach 2.

Show 10 zero-score criteria

Zero-score criteria (Checklist revision 3)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No new instruction.	eip.md · Transaction introspection — "This EIP adds four non-conflicting indices" Only new selectors on the existing TXPARAM instruction; no new opcode.
Added precompiles	None.	eip.md · Specification No precompile is defined.
Modified precompiles	None.	eip.md · Specification No precompile changes.
Modified system contracts	No existing system contract changes.	eip.md · Activation Only the new NONCE_MANAGER is installed. No existing system contract, such as EXPIRY_VERIFIER, is changed.
Blob gas accounting changes	No blob-gas rule changes.	eip.md · Transaction payload — "No other payload field is changed" The blob fields and blob accounting of EIP-8141 are unchanged.
New EVM gas refund	No new refund mechanism. The only reversal of the keyed-nonce charge is the existing frame rollback.	eip.md · Nonce consumption — "are NOT charged under EIP-2200 `SSTORE` pricing" Keyed-nonce writes are outside SSTORE refund logic, and the protocol never writes 0.
New transaction types	An existing type is modified; no new envelope.	eip.md · Transaction payload — "replaces the `nonce` field in the EIP-8141 `FRAME_TX_TYPE` payload" Modifies the existing type 0x06; no new discriminator.
New block / header fields	None.	eip.md · Specification No header or block-level member is added.
Engine API changes	No Engine API change.	eip.md · Specification No Engine API fields or methods are mentioned. Transactions stay inside existing payload contents.
Cryptography	Unchanged primitives are reused for slot derivation and key-set hashing, and the signing rules are unchanged. Changed message bytes count under encoding, which fits level 0.	eip.md · Nonce state — "slot(sender, nonce_key) = keccak256(A \|\| K)" Uses unchanged keccak256 for slot derivation. eip.md · Transaction payload — "The EIP-8141 signature hash procedure applies after this replacement" The signature hash rule is unchanged; only the message bytes change. Uncertainty: Someone could treat nonce_keys_hash as a new hash commitment (level 1).

Assessment provenance

Assessed EIP revision: ethereum/EIPs@6dac5e7491 EIPS/eip-8250.md committed 2026-10-07 · information cutoff 2026-10-07T22:23:55Z
Current master · File history · blob e49b435eb2 · sha256 6df47bfc4101
Rubric: Checklist revision 3 · ethspecs/pm@fe2f793b03
Evaluator: Opus 5.5 (claude-opus-5-5) at high effort, one tool-less call per EIP · isolation bubblewrap_claude_p_no_tools_v1
Source record: Frozen research record research/tasks/10-opus-v3-reassessment/prospective/outputs/assessments/hegota-2026-10-08/eip-8250.yaml · sha256 0720dee23c20
Supporting documents supplied with the EIP: supporting/eip-2200.md, supporting/eip-2929.md, supporting/eip-4337.md, supporting/eip-7623.md, supporting/eip-8037.md, supporting/eip-8141.md

Evaluated on: Not recorded

22MediumMedium

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

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.

Total taken from the cells. The checklist publishes a total of 20, but its 28 cells sum to 22. The cells are the primary record, so the cell sum is used here and in every comparison.

Complexity profile

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

Criterion breakdown

EIP-8250 Hegotá: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
New fork activation mechanism	3	`NONCE_MANAGER` is initialized at the activation boundary (code, nonce, storage rules for pre-existing accounts) — a state modification at the fork block.	—
Edge/boundary conditions	3	Structural key-set rules (bounds, strict ordering, the zero-key aliasing exception), the sequence-exhaustion bound, first-use versus reuse surcharges and their out-of-gas boundary, revert-immune consumption, and atomic-batch unroll persistence — several mechanisms, and the approval-atomicity surface needs an elevated case count.	—
Added system contracts	2	`NONCE_MANAGER` is a stateful system contract: the protocol writes its keyed slots while ordinary calls revert.	—
EVM Gas rule changes	2	Two additions to existing accounting: the nonce encodings priced as EIP-7623 calldata (intrinsic and floor), and the per-first-use keyed-nonce surcharge charged from the approving frame's gas. Measured impact on existing tests is small (eleven executions, all boundary cases).	—
New or modified transaction validity mechanisms	2	Stateful validity becomes per-key sequence equality against protocol storage, plus structural key-set rules at decode time; existing validity tests need limited updates.	—
Transition-tool interface changes	2	The transaction interface gains two fields (`nonceKeys`, `nonceSeq`) replacing the frame transaction's `nonce` across the loader and serialization paths.	—
New test-framework primitives	2	The transaction model gains the keyed fields with legacy-aliasing defaults, the frame gas calculators gain an extra-charged-bytes term, and a nonce-encoding fork accessor keeps sibling tests fork-correct — reusable within the suite.	—
Security risks	2	Replay protection is redesigned: disjoint-key independence, nullifier-style spent-once atomicity through payment approval, and consumption that must survive reverts and batch rollback — application-facing security guarantees that need targeted adversarial tests.	—
Cross-EIP interactions	2	A delta on EIP-8141 (full coordination with the frames suite, measured), the EIP-7623/7976 floor family (nonce bytes priced as calldata), and EIP-7825 (gas-cap boundaries flip) — coordinated but mechanical.	—
Patterns affecting pre-existing tests	1	Measured: 11 of 541 EIP-8141 suite executions flip — exact-gas boundaries and the introspection probe — and all were updated fork-correctly rather than parked.	—
Unspecified behavior requiring cross-client consensus	1	The specification is unusually complete (ordered approval steps, journaling rules, overflow halts); the prototype needed no interpretation disputes, and the open mempool-concurrency amendment is non-consensus.	—

Show 17 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Notes
Added opcodes	No rationale recorded.	—
Modified opcodes	`TXPARAM` changes semantics (`0x01` becomes the keyed sequence) and gains four indices, but the opcode ships in the same fork as its EIP-8141 substrate — no deployed behavior is modified.	—
Added precompiles	No rationale recorded.	—
Modified precompiles	No rationale recorded.	—
Modified system contracts	No rationale recorded.	—
State-access ordering within opcode execution	No rationale recorded.	—
Blob gas accounting changes	No rationale recorded.	—
State gas accounting changes	No rationale recorded.	—
New EVM gas refund	No rationale recorded.	—
New transaction types	No rationale recorded.	—
New block / header fields	No rationale recorded.	—
Encoding changes (RLP/SSZ)	The frame transaction payload changes (`nonce` becomes `nonce_keys`, `nonce_seq`), but the type never exists on mainnet without this EIP — the tooling cost is scored under the interface and framework rows.	—
Block syncing changes	No rationale recorded.	—
Engine API changes	No rationale recorded.	—
New invariant on pre-existing tests	No rationale recorded.	—
Performance risks	No rationale recorded.	—
Cryptography	No rationale recorded.	—

Assessment provenance

Rubric: Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Open draft pull request #111: Add EIP-8250 complexity assessment · checklist at b0886dc069 · updated 2026-08-18
blob 3dd95224ea · sha256 09679e4e4802
Research record: research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8250.yaml · sha256 bbe6ad03936b

The LLM applied checklist revision 3 and the human reviewers revision 2 to EIP-8250 in Hegotá. Revision 3 phrases the same criteria more precisely; differences cover the 28 criteria both revisions share, and each total keeps its own revision. Δ is LLM minus Human.

Using the latest scored LLM evaluation for this checklist: 2026-10-08 · spec 2026-10-07 · 6dac5e7491. The Human and LLM assessments may use different spec revisions.

LLM42High

Human22Medium

Δ total+20Tiers differ: High vs Medium

Criteria15/28agree exactly · 6 differ by 1 · 7 differ by 2+

Complexity profiles side by side

LLM

Human

Largest disagreements: Modified opcodes (+3), Encoding changes (RLP/SSZ) (+3), State gas accounting changes (+2), Patterns affecting pre-existing tests (+2), New invariant on pre-existing tests (+2)

Show differences only (13 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 The semantics of the TXPARAM and APPROVE instructions change, which fits level 3. Human `TXPARAM` changes semantics (`0x01` becomes the keyed sequence) and gains four indices, but the opcode ships in the same fork as its EIP-8141 substrate — no deployed behavior is modified.
Encoding changes (RLP/SSZ)	3	0	+3	Differ by 2+	Show rationale LLM The serialized EL transaction schema changes, which fits level 3. Human The frame transaction payload changes (`nonce` becomes `nonce_keys`, `nonce_seq`), but the type never exists on mainnet without this EIP — the tooling cost is scored under the interface and framework rows.
State gas accounting changes	2	0	+2	Differ by 2+	Show rationale LLM A new charging site (APPROVE keyed-slot creation) uses the existing EIP-8037 state-gas mechanism and frame state pools. No new mechanism and no change to spill between pools, which fits level 2. Human No rationale recorded.
Block syncing changes	2	0	+2	Differ by 2+	Show rationale LLM Several simple structural decode rules are added for frame transactions in imported blocks, which fits level 2. Human No rationale recorded.
Patterns affecting pre-existing tests	3	1	+2	Differ by 2+	Show rationale LLM One common change, the payload schema plus priced nonce bytes, forces ordinary-case rework across distinct EIP-8141 test families after the fork. These include encoding and signature-hash, validity, APPROVE, TXPARAM, gas and fee settlement, and receipts. That fits level 3. Human Measured: 11 of 541 EIP-8141 suite executions flip — exact-gas boundaries and the introspection probe — and all were updated fork-correctly rather than parked.
New invariant on pre-existing tests	2	0	+2	Differ by 2+	Show rationale LLM Post-fork state must include the NONCE_MANAGER account, which affects state-root expectations for fork-transition and fork tests. Keyed storage writes are new-feature outputs. No pre-fork vectors need re-deriving, which fits level 2. Human No rationale recorded.
Performance risks	2	0	+2	Differ by 2+	Show rationale LLM Targeted integrated benchmarks are needed for blocks full of max-key frame transactions. Their uncharged storage reads and writes all concentrate on one huge contract storage trie. This is a bounded interaction, which fits level 2. Human No rationale recorded.
EVM Gas rule changes	1	2	−1	Differ by 1	Show rationale LLM Existing frame-transaction gas formulas gain new inputs: the nonce calldata cost and tokens. This shifts the expected gas of every frame transaction, but no new execution-gas accounting mechanism is introduced. The access exemption is an exclusion, not a new mechanism. That fits level 1. Human Two additions to existing accounting: the nonce encodings priced as EIP-7623 calldata (intrinsic and floor), and the per-first-use keyed-nonce surcharge charged from the approving frame's gas. Measured impact on existing tests is small (eleven executions, all boundary cases).
State-access ordering within opcode execution	1	0	+1	Differ by 1	Show rationale LLM Only APPROVE, a prerequisite instruction, has its state-access and charge ordering changed: up to 16 storage reads are inserted before its state-gas charge. No general class-wide ordering rule changes, which fits level 1. Human No rationale recorded.
New or modified transaction validity mechanisms	3	2	+1	Differ by 1	Show rationale LLM The replay/nonce validity dependency moves from a single account nonce to multi-domain storage state. Tests must restructure sender-nonce handling and use coordinated multi-transaction block scenarios: overlapping and disjoint key sets, mixes of [0] and keyed transactions, and legacy-nonce changes through CREATE. That fits level 3. Human Stateful validity becomes per-key sequence equality against protocol storage, plus structural key-set rules at decode time; existing validity tests need limited updates.
Security risks	3	2	+1	Differ by 1	Show rationale LLM The shared replay and authorization invariant changes across consensus validity, the APPROVE transition, mempool identity and revalidation, and contract verifiers. This needs coordinated adversarial scenarios, which fits level 3. Human Replay protection is redesigned: disjoint-key independence, nullifier-style spent-once atomicity through payment approval, and consumption that must survive reverts and batch rollback — application-facing security guarantees that need targeted adversarial tests.
Cross-EIP interactions	3	2	+1	Differ by 1	Show rationale LLM The target couples EIP-8141 transaction and APPROVE behavior with EIP-8037 state gas, EIP-7623 floor pricing, and EIP-2929 warmth. Coordinated scenarios are needed across these interactions, which fits level 3. Human A delta on EIP-8141 (full coordination with the frames suite, measured), the EIP-7623/7976 floor family (nonce bytes priced as calldata), and EIP-7825 (gas-cap boundaries flip) — coordinated but mechanical.
Unspecified behavior requiring cross-client consensus	2	1	+1	Differ by 1	Show rationale LLM Localized competing gas outcomes need agreement: floor token counting for the nonce bytes, and whether the nonce cost enters intrinsic gas for the cap and reservation. That fits level 2. Human The specification is unusually complete (ordered approval steps, journaling rules, overflow halts); the prototype needed no interpretation disputes, and the open mempool-concurrency amendment is non-consensus.
Added opcodes	0	0	0	Agree	Show rationale LLM No new instruction. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM None. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM None. Human No rationale recorded.
Added system contracts	2	2	0	Agree	Show rationale LLM Exactly one contract is introduced, and it is stateful, which fits level 2. Human `NONCE_MANAGER` is a stateful system contract: the protocol writes its keyed slots while ordinary calls revert.
Modified system contracts	0	0	0	Agree	Show rationale LLM No existing system contract changes. Human No rationale recorded.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM No blob-gas rule changes. Human No rationale recorded.
New EVM gas refund	0	0	0	Agree	Show rationale LLM No new refund mechanism. The only reversal of the keyed-nonce charge is the existing frame rollback. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM An existing type is modified; no new envelope. Human No rationale recorded.
New block / header fields	0	0	0	Agree	Show rationale LLM None. Human No rationale recorded.
New fork activation mechanism	3	3	0	Agree	Show rationale LLM Protocol-mandated code installation at activation, which fits level 3. Human `NONCE_MANAGER` is initialized at the activation boundary (code, nonce, storage rules for pre-existing accounts) — a state modification at the fork block.
Engine API changes	0	0	0	Agree	Show rationale LLM No Engine API change. Human No rationale recorded.
Transition-tool interface changes	2	2	0	Agree	Show rationale LLM Several transaction fields change (nonce removed; nonce_keys and nonce_seq added) without a new exchange mechanism. That fits level 2. Human The transaction interface gains two fields (`nonceKeys`, `nonceSeq`) replacing the frame transaction's `nonce` across the loader and serialization paths.
New test-framework primitives	2	2	0	Agree	Show rationale LLM Tests need a construction abstraction for keyed nonce domains. It must compute NONCE_MANAGER slots, pre-populate them, and track sequences per key instead of auto-incrementing the account nonce. It must also produce frame transactions with key sets. This is a new abstraction within the target suite, but not a shared facility that changes other families, which fits level 2. Human The transaction model gains the keyed fields with legacy-aliasing defaults, the frame gas calculators gain an extra-charged-bytes term, and a nonce-encoding fork accessor keeps sibling tests fork-correct — reusable within the suite.
Edge/boundary conditions	3	3	0	Agree	Show rationale LLM Several boundary-sensitive mechanisms are introduced. The APPROVE state-gas check is an elevated matrix: frame limits.state × number of keys × how many keys are fresh vs. used × [0]-with-nonexistent-sender × approval scope 0x1/0x3 × VERIFY (makes the tx invalid) vs. non-VERIFY frame. That fits level 3. Human Structural key-set rules (bounds, strict ordering, the zero-key aliasing exception), the sequence-exhaustion bound, first-use versus reuse surcharges and their out-of-gas boundary, revert-immune consumption, and atomic-batch unroll persistence — several mechanisms, and the approval-atomicity surface needs an elevated case count.
Cryptography	0	0	0	Agree	Show rationale LLM Unchanged primitives are reused for slot derivation and key-set hashing, and the signing rules are unchanged. Changed message bytes count under encoding, which fits level 0. Human No rationale recorded.

Compare EIP-8250 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 · not in checklist revision 1
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 · not in checklist revision 1
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 · not in checklist revision 1
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 · not in checklist revision 1
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 · not in checklist revision 1
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.