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-08-25PFI at snapshotLayers: execution

LLM Completescore 42

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

LLM · Checklist revision 22026-08-26 · Original snapshot · 42 Human · Checklist revision 2Draft PR · 22 CompareHuman vs LLM · same checklist revision

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

Scope at the cutoff. Execution-layer assessment of the sealed Draft EIP-8250 delta to EIP-8141. The assessed surface comprises the frame-transaction payload and signature hash, keyed-nonce validity and protocol-managed state, payment-scoped APPROVE gas and persistence semantics, transaction introspection, fork activation, and execution-client mempool dependency handling.

42HighHigh

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: Yes — 6 criteria affected
Plausible range: 42–42 (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 sealed EIP-8250 delta conflicts with its sealed EIP-8141 base in two consensus-visible places: the surrounding RLP fee-field layout and the result assigned to TXPARAM(0x0C). The delta also does not state whether its protocol-managed keyed reads and writes are recordable in the rubric's block-level access list; it only excludes them from EIP-2929 transaction access sets. These issues require a package-authoritative resolution, but either resolution leaves the scored mechanisms and High tier unchanged.

Plausible total

42–42
recorded score 42 · plausible tiers High

Affected criteria (6)

Modified opcodes (3)
State-access ordering within opcode execution (1)
Encoding changes (RLP/SSZ) (3)
Block syncing changes (2)
Transition-tool interface changes (3)
Unspecified behavior requiring cross-client consensus (2)

Unresolved questions at the cutoff (3)

Does the post-fork RLP payload retain EIP-8141's nested fees list, or use the three top-level fee fields displayed by EIP-8250?
Does TXPARAM(0x0C) return the pre-state legacy sender nonce or the current frame's state_gas_left, and what index retains the displaced value?
Are protocol-managed NONCE_MANAGER reads and writes included in any block-level access-list recording, independently of their explicit exclusion from EIP-2929 warming sets?

Notable ambiguities noted by the assessor (2)

FORK_TIMESTAMP is TBD and NONCE_MANAGER must be reselected if code or storage exists on any intended activation network; these are deployment parameters, not additional scored behavior gaps.
The public mempool keeps one pending frame transaction per sender even though transaction identity becomes (sender, nonce_keys, nonce_seq); the text presents multi-pending keyed-aware policy only as a future possibility.

Criterion breakdown

EIP-8250 Hegotá: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Modified opcodesUnder-specified	3	At least APPROVE and TXPARAM have behavioral, non-gas result changes, so the rubric's binary score 3 applies.	eip.md · Specification > Nonce consumption Payment-scoped APPROVE replaces the legacy account-nonce increment with keyed reads, conditional gas, keyed or legacy consumption, and approval effects that survive later rollback. eip.md · Specification > Transaction introspection TXPARAM(0x01) changes meaning to nonce_seq and additional parameter results are assigned. Confidence: High Uncertainty: TXPARAM(0x0C) conflicts with its sealed EIP-8141 assignment; that localized conflict is recorded under under-specification but does not change the fact that opcode behavior is modified.
EVM Gas rule changes	3	This introduces a dynamic first-use execution-gas mechanism inside APPROVE and integrates it with existing frame gas-used, settlement, and unpaid-gas-refund calculations. Existing frame-transaction gas cases are affected, matching score 3.	eip.md · Specification > Nonce consumption, steps 1-5 A payment-scoped APPROVE reads every keyed slot, counts first uses, charges KEYED_NONCE_FIRST_USE_GAS per zero-valued slot, and makes the charge part of frame and transaction gas accounting. eip.md · Specification > Transaction payload RLP encodings of nonce_keys and nonce_seq are newly included in both standard gas-limit and calldata-token calculations inherited from the frame transaction. Confidence: High Uncertainty: The surcharge and its accounting destinations are explicit; the sealed package contains no executable test inventory with which to count affected vectors.
New or modified transaction validity mechanisms	3	Existing frame-transaction validity tests require extensive redesign for list encoding, multiple state domains, overlap and ordering, sequence exhaustion, and changed intrinsic calculations. Score 3 applies.	eip.md · Specification > Transaction payload, decoder rejection list Static validity gains schema, non-empty/bounded-list, canonicality, integer-range, strict-order, and zero-key constraints. eip.md · Specification > Stateful validity Stateful validity replaces one sender-nonce equality with equality against every selected key's current sequence at the transaction's actual position in block execution order. eip.md · Specification > Transaction payload, gas pricing definitions The new nonce encodings also change intrinsic/floor quantities used by transaction gas-limit validity. Confidence: High Uncertainty: The validity rules themselves are detailed; only the surrounding payload layout conflict is unresolved separately.
Encoding changes (RLP/SSZ)Under-specified	3	An encoding change at transaction level is introduced, which maps directly to the rubric's binary score 3.	eip.md · Specification > Transaction payload FRAME_TX_TYPE replaces one RLP nonce field with consecutive nonce_keys and nonce_seq fields, requires canonical integer encodings, and changes the signing payload accordingly. Confidence: High Uncertainty: The exact surrounding fee-field nesting conflicts with sealed EIP-8141; both readings still constitute the scored transaction-level encoding change.
New fork activation mechanism	3	The activation block performs an irregular state/account transition, which is the rubric's binary score-3 condition.	eip.md · Specification > Activation Before transactions in the first post-fork block, clients create or modify NONCE_MANAGER code and nonce while preserving balance according to pre-existing-account conditions, and must undo this on reorg. Confidence: High Uncertainty: FORK_TIMESTAMP and the final network-safe address are configuration TBDs, but the activation mechanism and transition cases are specified.
Transition-tool interface changesUnder-specified	3	A transition tool must represent multiple new transaction fields and must support a fork-boundary-only pre-transaction state transition whose selection depends on both current and parent timestamps. This matches the score-3 combination of multiple fields and a new mechanism.	eip.md · Specification > Transaction payload The existing nonce input is replaced by the two distinct transaction fields nonce_keys and nonce_seq. eip.md · Specification > Activation NONCE_MANAGER initialization occurs only when the current timestamp is post-fork and the parent timestamp is pre-fork, before transaction execution, and must be reversible across reorgs. Confidence: Medium Uncertainty: No transition-tool interface is included, so the exact field names and whether existing environment inputs already expose parent timestamp are not package-evidenced.
Patterns affecting pre-existing tests	3	Existing EIP-8141 tests require broad reworking across encoding, signature hashes, validity, gas boundaries, APPROVE/revert behavior, activation, and mempool behavior. These are diverse test categories, so score 3 applies.	eip.md · Specification > Transaction payload; Stateful validity; Nonce consumption; Transaction introspection The delta changes every post-fork frame transaction's nonce fields and signing payload, replaces its stateful nonce check and payment-approval nonce effect, and changes transaction introspection. eip.md · Specification > Activation; Mempool It also invalidates pre-fork frame transactions at the boundary and changes frame-transaction identity, dependencies, and revalidation. Confidence: High Uncertainty: The breadth follows directly from the delta, though the package includes no pre-existing test catalog for a mechanical case count.
Security risks	3	Replay protection and authorization are critical invariants, and the new mechanism crosses transaction validity, opcode approval, state journaling, contract creation semantics, fee payment, and mempool replacement. These multiple critical interactions require extensive review and fuzzing, so score 3 applies.	eip.md · Security Considerations The proposal identifies authorization binding of the full key set, CREATE-address sensitivity to the legacy nonce, persistence through rollback, cancellation/replacement changes, permanent state growth, and sequence exhaustion. eip.md · Specification > Nonce consumption; Mempool Replay state is committed during payment approval outside frame and atomic-batch journals, while the public mempool gains multi-key dependency and revalidation rules. Confidence: High Uncertainty: The proposal documents the risk classes, but the sealed package contains no implementations, tests, or review outcomes, as required by the source restrictions.
Edge/boundary conditions	3	Multiple boundary-prone mechanisms require an elevated combinatorial set of cases, especially up to sixteen shared-sequence keys crossed with first/subsequent use, overlap, gas-left thresholds, approval scopes, and rollback outcomes. Score 3 applies.	eip.md · Specification > Transaction payload, decoder rejection list Boundaries include one to sixteen keys, canonical integer encodings, 256- and 64-bit limits, strict ordering, and the singleton-only zero key. eip.md · Specification > Stateful validity; Nonce consumption; Activation Additional boundaries include overlapping sets in block order, sequence exhaustion, first-use gas thresholds, legacy nonce changes during a transaction, rollback persistence, and the exact fork boundary. Confidence: High Uncertainty: The boundaries are explicit; the exact case count depends on the test framework, which is outside the sealed package.
Cross-EIP interactions	3	Coordinated cases are required for EIPs 8141, 7623, 2929, and 2200: the frame-transaction delta is deep, calldata-floor behavior must include the new bytes, and ordinary SSTORE and warm/cold mechanisms must remain unaffected by protocol bookkeeping. Four interacting EIPs do not trigger the rubric's first +1 increment, which begins after six total interactions; the strong multi-EIP dependency therefore scores 3.	eip.md · Front matter 'requires'; Specification > Transaction payload; Nonce consumption EIP-8250 requires 7623 and 8141, changes EIP-8141 payload, validity, APPROVE, introspection, and mempool behavior, and integrates nonce bytes with calldata-floor accounting. eip.md · Specification > Nonce consumption, final paragraph Protocol keyed reads/writes are expressly excluded from EIP-2929 access warming and EIP-2200 SSTORE pricing. supporting/eip-2200.md · Specification EIP-2200 defines the ordinary SSTORE charging and refund machinery from which keyed protocol writes are excluded. supporting/eip-2929.md · Specification > Storage read changes; SSTORE changes EIP-2929 defines transaction access sets and warm/cold storage behavior that keyed protocol accesses must not affect. supporting/eip-7623.md · Specification EIP-7623 defines calldata-token floor pricing with which the new nonce encodings interact through the EIP-8141 accounting delta. supporting/eip-8141.md · Specification > APPROVE Instruction; Introspection; Mempool EIP-8141 supplies the existing mechanisms that EIP-8250 directly replaces or extends. Confidence: High Uncertainty: The EIP-4337 comparison is rationale-only and does not establish a protocol dependency requiring coordinated execution-layer vectors, so it is not counted. Interacting EIPs: EIP-2200, EIP-2929, EIP-7623, EIP-8141
Added system contracts	2	This is one new stateful system contract, which is the explicit score-2 anchor.	eip.md · Specification > Constants; Nonce state; Activation A new NONCE_MANAGER account with reverting runtime code is installed at activation, and its persistent storage holds every non-zero keyed nonce sequence. Confidence: High Uncertainty: Its address remains subject to network-specific emptiness checks before fork-configuration finalization, but the contract's stateful role is clear.
Block syncing changesUnder-specified	2	Sync validation must implement multiple related RLP checks and a timestamp-dependent schema for an existing transaction type. This is more than one simple validation but remains a localized payload change, matching score 2.	eip.md · Specification > Transaction payload At the fork, FRAME_TX_TYPE changes RLP schema and gains list shape, canonicality, range, strict-ordering, and zero-key decoding checks. eip.md · Specification > Activation Decoders must select the old or new frame payload rules based on the activation timestamp. Confidence: High Uncertainty: The payload's fee-field layout conflicts with sealed EIP-8141 and is recorded as under-specification; either resolution still requires these keyed-field validation mechanisms.
New invariant on pre-existing tests	2	A broad category of fork-transition and post-activation state assertions gains a mechanical invariant for the NONCE_MANAGER account even when a test does not send a keyed-nonce transaction. The text does not establish that literally every test vector and every pre-fork vector must be re-derived, so score 2 rather than 3 applies.	eip.md · Specification > Activation The first post-fork block must initialize NONCE_MANAGER with fixed code, at least nonce 1, empty storage, and balance-preservation rules before any transaction executes. Confidence: Medium Uncertainty: The package does not describe how the test corpus supplies or asserts fork-initialized system state.
Performance risks	2	State-database work, multi-key validity, persistent growth, and mempool dependency tracking interact with existing execution and propagation paths, so isolated microbenchmarks do not cover the full impact. The sixteen-key bound and gas-based growth bound keep the impact limited, matching score 2 rather than 3.	eip.md · Specification > Stateful validity; Nonce consumption; Mempool A transaction can require reads and writes for up to sixteen derived storage slots, and pending transactions must be indexed and revalidated when any selected sequence changes. eip.md · Security Considerations, paragraph beginning 'Each consumed' Every first-used sender/key pair occupies a persistent slot; growth is bounded by a 20,000-gas surcharge per new key. Confidence: Medium Uncertainty: The package supplies bounds but no benchmark targets, client data structures, or measured workloads.
Unspecified behavior requiring cross-client consensusUnder-specified	2	Clients need agreement on the localized payload layout and TXPARAM(0x0C) result before authoritative vectors can be baselined. These are concrete, localized conflicts rather than a newly observable class of previously unspecified behavior, matching score 2.	eip.md · Specification > Transaction payload, displayed post-replacement payload EIP-8250 displays fee values as three top-level payload fields while stating that only nonce is replaced and no other field changes. supporting/eip-8141.md · Specification > Frame Transaction > Payload Encoding The sealed base payload instead contains one nested fees list, so the exact post-fork RLP schema cannot satisfy both texts. eip.md · Specification > Transaction introspection, TXPARAM table EIP-8250 assigns 0x0C to the pre-state legacy sender nonce and calls its new indices non-conflicting. supporting/eip-8141.md · Specification > Introspection > TXPARAM Instruction (0xb0), table The sealed base already assigns 0x0C to current-frame state_gas_left, creating a second direct result conflict. Confidence: High Uncertainty: The conflicts are explicit in the sealed sources. The package contains no admissible amendment or precedence rule that resolves them.
State-access ordering within opcode executionUnder-specified	1	The state-access and gas-charge order of one opcode, APPROVE, changes. Testing is multiplicative across legacy versus keyed domains, first versus subsequent use, key count, payment scope, gas boundaries, and success/revert/atomic-batch paths, but the rubric's score-1 anchor is the exact structural match because only one opcode's ordering changes.	eip.md · Specification > Nonce consumption, paragraphs before and after steps 1-5 APPROVE first performs all pre-existing exceptional checks and ordinary costs, then keyed reads, then the conditional surcharge, then nonce writes, and only then commits the remaining approval effects atomically. Confidence: High Uncertainty: The intra-APPROVE order is explicit. The separate question of recording these protocol accesses in a block-level access list is not specified and is recorded under under-specification rather than changing this score.
New test-framework primitives	1	Existing transaction and state fixtures need minor extension for the two fields, key-list constraints, and derived storage slots. The package does not demonstrate a need for a new permanent expectation or modifier abstraction, so score 1 applies.	eip.md · Specification > Transaction payload; Nonce state Tests must construct a bounded list of nonce keys plus a sequence and inspect protocol-managed keyed storage derived from sender and key. Confidence: Medium Uncertainty: The sealed package contains no test-framework design or tests; the score is limited to the minimum extension directly required by the specified data model.

Show 11 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No new opcode is introduced, so score 0 applies.	eip.md · Specification > Nonce consumption; Transaction introspection The proposal changes the existing EIP-8141 APPROVE and TXPARAM instructions but assigns no new opcode number. Uncertainty: No material uncertainty in the sealed text.
Added precompiles	No new precompile is introduced, so score 0 applies.	eip.md · Specification > Constants; Nonce state NONCE_MANAGER is specified as a stateful system contract with runtime bytecode and storage, not as a precompile; no precompile is added. Uncertainty: No material uncertainty in the sealed text.
Modified precompiles	No existing precompile is modified, so score 0 applies.	eip.md · Specification (complete execution-layer delta) No precompile behavior or gas schedule is modified anywhere in the proposal. Uncertainty: No precompile surface is present in the allowlisted proposal.
Modified system contracts	Modifying EIP-8141 opcode and transaction behavior is not a modification of a pre-existing system contract. Score 0 applies.	eip.md · Specification > Activation The only system-contract action defined is initialization of the new NONCE_MANAGER; the proposal defines no change to existing system-contract code or state. Uncertainty: No material uncertainty in the sealed text.
Blob gas accounting changes	EIP-8250 neither adds nor modifies a blob-gas mechanism; its added bytes are execution-calldata priced. Score 0 applies.	eip.md · Specification > Transaction payload The delta states that no payload field other than the nonce replacement changes and adds nonce bytes only to standard/calldata-token accounting. supporting/eip-8141.md · Specification > Frame Transaction > Blob handling The base frame transaction already defines optional blob handling and blob-gas accounting. Uncertainty: No material uncertainty in the sealed text.
State gas accounting changes	Although keyed slots create persistent state, EIP-8250 prices that growth with execution gas and does not adjust StateGasCosts, a STATE_BYTES rate, a state-gas charge site, or the block state-gas budget. Under this anchor's narrow definition, the score is 0.	eip.md · Specification > Nonce consumption, final two paragraphs The first-use surcharge is deducted from the executing frame's gas and keyed writes are protocol bookkeeping explicitly excluded from ordinary SSTORE pricing. supporting/eip-8141.md · Specification > Frame Transaction > Gas Accounting The base proposal separately defines state gas as the durable-state dimension with per-frame state budgets and specific charge points. Uncertainty: This score follows the rubric's distinction between a state-growth surcharge paid in execution gas and the named state-gas mechanism.
New EVM gas refund	Referencing an existing settlement refund does not create a new EVM gas refund mechanism. Score 0 applies.	eip.md · Specification > Nonce consumption The surcharge is included in EIP-8141's existing unpaid-gas refund calculation; no refund counter, eligibility rule, or refund amount is introduced for keyed nonces. Uncertainty: No material uncertainty in the sealed text.
New transaction types	No new transaction type is introduced, so score 0 applies.	eip.md · Abstract; Specification > Transaction payload The proposal is explicitly a delta that changes the existing EIP-8141 FRAME_TX_TYPE payload rather than assigning another transaction type. Uncertainty: No material uncertainty in the sealed text.
New block / header fields	No block or header field is introduced, so score 0 applies.	eip.md · Specification (complete execution-layer delta) Keyed nonce state is committed through the existing execution stateRoot; no new block or header field is defined. eip.md · Rationale, paragraph beginning 'Keyed-nonce state lives' The system-contract storage choice is expressly intended to retain the existing execution state commitment. Uncertainty: No material uncertainty in the sealed text.
Engine API changes	No Engine API change is introduced, so score 0 applies.	eip.md · Specification (complete execution-layer delta) The proposal specifies transaction, state transition, introspection, activation, and mempool behavior but no Engine API field, endpoint, or communication mechanism. Uncertainty: No Engine API surface is present in the allowlisted proposal.
Cryptography	Use of an existing hash function and a changed signed message does not introduce or modify a cryptographic mechanism. Score 0 applies.	eip.md · Specification > Nonce state; Transaction introspection The proposal uses keccak256 for storage-slot derivation and for a canonical hash of the nonce-key set, while retaining EIP-8141's signature procedure after substituting the nonce fields. Uncertainty: No material uncertainty in the sealed text.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@ac450a4ab2 EIPS/eip-8250.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z
Current master · File history · blob b824d302c2 · sha256 23249d7f78b3
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-8250.yaml · sha256 861523738ec7
Supporting documents in the sealed package: supporting/eip-2200.md, supporting/eip-2929.md, supporting/eip-4337.md, supporting/eip-7623.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

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

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

LLM42High

Human22Medium

Δ total+20Tiers differ: High vs Medium

Criteria14/28agree exactly · 8 differ by 1 · 6 differ by 2+

Complexity profiles side by side

LLM

Human

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

Show differences only (14 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
Modified opcodes	3	0	+3	Differ by 2+	Show rationale LLM At least APPROVE and TXPARAM have behavioral, non-gas result changes, so the rubric's binary score 3 applies. 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 An encoding change at transaction level is introduced, which maps directly to the rubric's binary score 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.
Block syncing changes	2	0	+2	Differ by 2+	Show rationale LLM Sync validation must implement multiple related RLP checks and a timestamp-dependent schema for an existing transaction type. This is more than one simple validation but remains a localized payload change, matching score 2. Human No rationale recorded.
Patterns affecting pre-existing tests	3	1	+2	Differ by 2+	Show rationale LLM Existing EIP-8141 tests require broad reworking across encoding, signature hashes, validity, gas boundaries, APPROVE/revert behavior, activation, and mempool behavior. These are diverse test categories, so score 3 applies. 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 A broad category of fork-transition and post-activation state assertions gains a mechanical invariant for the NONCE_MANAGER account even when a test does not send a keyed-nonce transaction. The text does not establish that literally every test vector and every pre-fork vector must be re-derived, so score 2 rather than 3 applies. Human No rationale recorded.
Performance risks	2	0	+2	Differ by 2+	Show rationale LLM State-database work, multi-key validity, persistent growth, and mempool dependency tracking interact with existing execution and propagation paths, so isolated microbenchmarks do not cover the full impact. The sixteen-key bound and gas-based growth bound keep the impact limited, matching score 2 rather than 3. Human No rationale recorded.
EVM Gas rule changes	3	2	+1	Differ by 1	Show rationale LLM This introduces a dynamic first-use execution-gas mechanism inside APPROVE and integrates it with existing frame gas-used, settlement, and unpaid-gas-refund calculations. Existing frame-transaction gas cases are affected, matching score 3. 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 The state-access and gas-charge order of one opcode, APPROVE, changes. Testing is multiplicative across legacy versus keyed domains, first versus subsequent use, key count, payment scope, gas boundaries, and success/revert/atomic-batch paths, but the rubric's score-1 anchor is the exact structural match because only one opcode's ordering changes. Human No rationale recorded.
New or modified transaction validity mechanisms	3	2	+1	Differ by 1	Show rationale LLM Existing frame-transaction validity tests require extensive redesign for list encoding, multiple state domains, overlap and ordering, sequence exhaustion, and changed intrinsic calculations. Score 3 applies. 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.
Transition-tool interface changes	3	2	+1	Differ by 1	Show rationale LLM A transition tool must represent multiple new transaction fields and must support a fork-boundary-only pre-transaction state transition whose selection depends on both current and parent timestamps. This matches the score-3 combination of multiple fields and a new mechanism. 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	1	2	−1	Differ by 1	Show rationale LLM Existing transaction and state fixtures need minor extension for the two fields, key-list constraints, and derived storage slots. The package does not demonstrate a need for a new permanent expectation or modifier abstraction, so score 1 applies. 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.
Security risks	3	2	+1	Differ by 1	Show rationale LLM Replay protection and authorization are critical invariants, and the new mechanism crosses transaction validity, opcode approval, state journaling, contract creation semantics, fee payment, and mempool replacement. These multiple critical interactions require extensive review and fuzzing, so score 3 applies. 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 Coordinated cases are required for EIPs 8141, 7623, 2929, and 2200: the frame-transaction delta is deep, calldata-floor behavior must include the new bytes, and ordinary SSTORE and warm/cold mechanisms must remain unaffected by protocol bookkeeping. Four interacting EIPs do not trigger the rubric's first +1 increment, which begins after six total interactions; the strong multi-EIP dependency therefore scores 3. 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 Clients need agreement on the localized payload layout and TXPARAM(0x0C) result before authoritative vectors can be baselined. These are concrete, localized conflicts rather than a newly observable class of previously unspecified behavior, matching score 2. 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 opcode is introduced, so score 0 applies. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM No new precompile is introduced, so score 0 applies. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM No existing precompile is modified, so score 0 applies. Human No rationale recorded.
Added system contracts	2	2	0	Agree	Show rationale LLM This is one new stateful system contract, which is the explicit score-2 anchor. 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 Modifying EIP-8141 opcode and transaction behavior is not a modification of a pre-existing system contract. Score 0 applies. Human No rationale recorded.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM EIP-8250 neither adds nor modifies a blob-gas mechanism; its added bytes are execution-calldata priced. Score 0 applies. Human No rationale recorded.
State gas accounting changes	0	0	0	Agree	Show rationale LLM Although keyed slots create persistent state, EIP-8250 prices that growth with execution gas and does not adjust StateGasCosts, a STATE_BYTES rate, a state-gas charge site, or the block state-gas budget. Under this anchor's narrow definition, the score is 0. Human No rationale recorded.
New EVM gas refund	0	0	0	Agree	Show rationale LLM Referencing an existing settlement refund does not create a new EVM gas refund mechanism. Score 0 applies. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM No new transaction type is introduced, so score 0 applies. Human No rationale recorded.
New block / header fields	0	0	0	Agree	Show rationale LLM No block or header field is introduced, so score 0 applies. Human No rationale recorded.
New fork activation mechanism	3	3	0	Agree	Show rationale LLM The activation block performs an irregular state/account transition, which is the rubric's binary score-3 condition. 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 is introduced, so score 0 applies. Human No rationale recorded.
Edge/boundary conditions	3	3	0	Agree	Show rationale LLM Multiple boundary-prone mechanisms require an elevated combinatorial set of cases, especially up to sixteen shared-sequence keys crossed with first/subsequent use, overlap, gas-left thresholds, approval scopes, and rollback outcomes. Score 3 applies. 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 Use of an existing hash function and a changed signed message does not introduce or modify a cryptographic mechanism. Score 0 applies. 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 · 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.