EIP complexity assessment

EIP-8141: Frame Transaction

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: SFILayers: execution

LLM Completescore 52

Human Completescore 38 · Checklist revision 1· merged checklist

Other checklist versions (1)

Pull request #122 (draft) · Checklist revision 1 · total 38 · same scores as the shown checklist

LLM · Checklist revision 32026-10-08 · Opus 5.5 · snapshot · 52 Human · Checklist revision 1Complete · 38 CompareHuman vs LLM · shared criteria

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

Scope at the cutoff. EIP-8141 adds an EIP-2718 transaction type (0x06), the frame transaction. Its body is an explicit sender, a list of frames (DEFAULT, VERIFY or SENDER mode, with flags, target, per-frame execution and state gas limits, value and data), a list of protocol-validated signatures (ARBITRARY, SECP256K1, P256) and optional blobs. Validity and payment are decided by EVM execution: VERIFY frames call a new APPROVE opcode to set sender approval and the payer. Any VERIFY failure, or a payer that is still unset after all frames, makes the transaction invalid. It defines per-frame two-dimensional gas pools with cross-frame state-gas refill attribution, a new intrinsic and calldata-floor settlement, block reservations per dimension, a new per-frame receipt format, atomic batches, default code for code-less accounts, an expiry verifier contract, and six introspection opcodes. It also changes ORIGIN semantics and exempts frame transactions from EIP-3607, and it specifies public-mempool and networking rules.

52HighHigh

Evaluator: LLMChecklist v3
Confidence: Medium
Under-specified at assessment cutoff: Yes — 5 criteria affected
Plausible range: 50–57 (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

Cross-EIP interactions5
Added opcodes4
New or modified transaction validity mechanisms4
Modified opcodes3

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: Several localized outcomes are not fully specified: whether payer and sender_approved are rolled back when APPROVE runs in a sub-call that later reverts inside a successful frame; how the frame-entry access charge is ordered against the SENDER approval-validity check; effective_gas_price and coinbase payment for frame transactions; and how frame-transaction blob hashes relate to the Engine API.

Plausible total

50–57
recorded score 52 · plausible tiers High

Affected criteria (5)

EVM Gas rule changes (2)
Blob gas accounting changes (1)
Engine API changes (0)
Transition-tool interface changes (2)
Unspecified behavior requiring cross-client consensus (2)

Unresolved questions at the cutoff (4)

Is the approval context (payer, sender_approved) journaled per EVM call frame, so that it reverts when an enclosing sub-call reverts?
For a SENDER frame with sender_approved == false whose limits.execution cannot cover the entry access charge, is the result an exceptional halt or an invalid transaction?
How are effective_gas_price and the coinbase priority fee defined for frame transactions?
Must the Engine API's expected blob versioned hashes include those carried by frame transactions?

Notable ambiguities noted by the assessor (5)

APPROVE is reachable at depth > 0 (self-call or DELEGATECALL keeps ADDRESS == resolved_target), but approval-context journaling is defined only at the frame level.
"Being a frame target does not warm an address" vs "journaled like any other EIP-2929 access": the warm status of a target after the frame succeeds is open to more than one reading.
Interaction of the frame-entry charge with SENDER approval validity: the ordering lists the charge first.
A deploy frame setting the sender's nonce (EIP-161 contract nonce = 1) followed by an APPROVE increment makes the next expected nonce non-obvious.
Clients may skip EVM execution for the expiry verifier frame, but gas consumed must match canonical execution.

Criterion breakdown

EIP-8141 Hegotá: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Cross-EIP interactionsExceptional	5	The target couples multiple EIPs' behavior inside one settlement and frame-execution model. That requires coordinated scenarios across them, so level 3.	eip.md · Gas Accounting Couples EIP-8037 state gas, EIP-2780 intrinsic/value costs, the EIP-7976 floor, EIP-3529 refunds and EIP-7778 block accounting. eip.md · Blob handling Blob-carrying frame transactions under EIP-4844 and EIP-7594. eip.md · Behavior EIP-7702 delegated targets, EIP-7708 transfer logs, EIP-2929 warm/cold access at frame entry. Confidence: High Interacting EIPs: EIP-8037, EIP-2780, EIP-7976, EIP-7778, EIP-3529, EIP-4844, EIP-7702, EIP-7708, EIP-2929, EIP-1559, EIP-2718, EIP-3607, EIP-3651, EIP-6780, EIP-7594, EIP-7825, EIP-8038, EIP-2, EIP-7819, EIP-7997
Added opcodesExceptional	4	Seven instructions are added, several of them complex. The level-3 condition is met. Exceptional score: Level 3 needs only two instructions with one complex. This adds seven. Two of them (TXPARAM, FRAMEPARAM) have 13 and 12 selector values each, with per-selector halt rules (current/future frame, scheme-dependent halts). SIGDATACOPY and SIGPARAM have scheme-conditional availability. APPROVE carries a full approval state machine with balance, nonce and state-gas effects. All seven halt outside frame transactions. This is opcode testing work well beyond the level-3 threshold.	eip.md · APPROVE Instruction (0xaa) A terminating instruction with memory-expansion gas and transaction-scoped side effects (nonce increment, max_cost collection, state-gas sender creation). eip.md · Introspection TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM, SIGDATACOPY, with selector tables, conditional halts and dynamic copy gas. Confidence: Medium Uncertainty: Using the exceptional level is a judgment call.
New or modified transaction validity mechanismsExceptional	4	Validity is now decided partly by EVM execution across frames. Tests need restructured validation sequencing and coordinated state scenarios (e.g., a DEFAULT frame changing state that a later VERIFY frame depends on). Exceptional score: Beyond the level-3 restructuring, validity spans four distinct layers that must all be tested: static structure, cryptographic signature validity, execution-dependent outcomes after arbitrary frames (any VERIFY failure anywhere, a SENDER frame before approval, payer unset at end), and per-dimension block capacity. A block becomes invalid because of a VERIFY or APPROVE outcome reached only after executing earlier state-modifying frames. Each layer needs its own coordinated transaction/state scenarios.	eip.md · Constraints Static validity rules, plus a cap on intrinsic and execution gas. eip.md · Behavior Nonce check, then signature validation. A SENDER frame without approval makes the transaction invalid. A VERIFY failure makes it invalid. Payer unset after all frames makes it invalid. eip.md · Block-level gas accounting Inclusion requires fitting execution and state reservations separately. eip.md · Transaction origination The EIP-3607 restriction is lifted for frame transactions. Confidence: Medium Uncertainty: Using the exceptional level is a judgment call.
Modified opcodes	3	Existing instruction semantics change: ORIGIN return values and transient-storage lifetime.	eip.md · Behavior — "The ORIGIN opcode returns frame's caller throughout all call depths" ORIGIN semantics change in frame transactions. eip.md · Cross-frame interactions — "Discard the TSTORE and TLOAD transient storage between frames" Transient storage scope changes. eip.md · Frame gas pools GAS returns the frame pool and never observes state gas. Confidence: High
State gas accounting changes	3	Introduces a new state-gas charging and attribution mechanism (frame-scoped pools, owner-frame refills, receipt mutation with rollback) and new charge sites, replacing the baseline reservoir/spill accounting. This meets level 3.	eip.md · Gas Accounting — "The reservoir model ... does not apply" Explicit per-frame state budgets replace the EIP-8037 reservoir and spill accounting. eip.md · State-gas attribution and refills Introduces state-gas ownership per frame. A cross-frame refill reduces the owner frame's receipt instead of crediting the current pool. Changes are journaled across frames and batches. eip.md · APPROVE Instruction — Behavior New charge site: sender-account creation state gas in APPROVE. A further new site is the frame-level new-account charge for value-carrying frames. Confidence: High
New transaction types	3	Introduces a distinct transaction envelope.	eip.md · Frame Transaction A new EIP-2718 type FRAME_TX_TYPE = 0x06 with its own payload. Confidence: High
Encoding changes (RLP/SSZ)	3	New transaction, receipt and p2p schemas.	eip.md · Payload Encoding New transaction payload RLP schema. eip.md · Receipt Encoding New ReceiptPayload [cumulative_gas_used, payer, frame_receipts]. eip.md · Networking New Receipts message encoding and a PooledTransactions blob wrapper for type 0x06. Confidence: High
Block syncing changes	3	Block import must decode a new transaction type and apply several structural rules, including complex cross-transaction reservation checks.	eip.md · Payload Encoding Block bodies must decode the new type-0x06 nested RLP. eip.md · Constraints New static structural checks on frame transactions. eip.md · Block-level gas accounting — "may be included in a block only if" Inclusion depends on cumulative per-dimension block counters, which is a complex rule. eip.md · Receipt Encoding New receipt structure contributes to the receipts root and logsBloom. Confidence: Medium Uncertainty: Some of these checks could be classed as ordinary execution rules, which would lower this to 2.
Security risks	3	Shared authorization and trust invariants change across components: the transaction pool, EVM approval, payer settlement, ORIGIN-based checks and sender identity. This needs coordinated adversarial scenarios.	eip.md · Security Considerations Covers mempool mass invalidation, deploy-frame front-running, sender state-read amplification, ARBITRARY malleability, and approval authorizing all subsequent sender frames. eip.md · Transaction origination Contract accounts can originate transactions, relaxing EIP-3607. eip.md · APPROVE calling convention DELEGATECALL code can APPROVE. Confidence: High
Performance risks	3	Several new workload couplings need integrated stress testing across subsystems: signature verification per entry (P256/secp256k1), up to 64 frames with per-frame receipts hashed into the trie, execution-dependent invalidity during block building, and mempool simulation and revalidation.	eip.md · Intrinsic cost decomposition — "provisional benchmark targets" Intrinsic and per-frame costs are provisional. eip.md · Replacement and Eviction — "unpaid validation work" Block producers can spend unpaid validation work on transactions that turn out invalid. eip.md · State-gas attribution and refills Journal entries are retained across up to 64 frames to allow later receipt mutation. Confidence: Medium Uncertainty: No benchmark data was supplied.
Edge/boundary conditions	3	Many boundary-sensitive rules are added. APPROVE outcomes and frame dispatch form an elevated matrix: mode × flags/scope × target resolution (null/sender/other, code/delegated/empty/precompile) × approval state × balance and pool exhaustion.	eip.md · Constraints Bounds: MAX_FRAMES, flags < 8, value only in SENDER frames, total_frame_gas < 2^64, atomic-batch placement and approval-scope rules, msg length 0/32 with the zero digest invalid, TX_MAX_GAS_LIMIT cap. eip.md · APPROVE Instruction — Behavior Scope × sender_approved × payer × resolved_target × balance × sender existence outcomes. eip.md · Block-level gas accounting Separate reservations against the execution and state block capacity. Confidence: High
EVM Gas rule changesUnder-specified	2	Adds a new execution-gas accounting mechanism for the new envelope: per-frame pools, the frame-entry access charge, intrinsic decomposition, signature-verification gas, floor/settlement and per-dimension block reservation. Gas results for baseline operations in existing transaction types are unchanged, so level 2.	eip.md · Gas Accounting Defines frame_tx_intrinsic_gas (FRAME_TX_INTRINSIC_COST, per-frame cost, signature gas, value cost), calldata_floor_gas, max_gas and settlement, and says the EIP-8037 reservoir does not apply. eip.md · Frame gas pools Each frame has its own execution pool, gas_left = frame.limits.execution. GAS observes only that pool. eip.md · Behavior — "Charge the resolved target's warm or cold account access" A new frame-entry access charge applies before the balance check and dispatch. eip.md · Transaction settlement Defines a new gas_used formula: the calldata floor is compared against the execution component, and state gas is added on top. Confidence: Medium Uncertainty: Opcodes in frame transactions run under different warm-address initialization and settlement (no tx.to warming, ORIGIN cold). This could be read as changing existing accounting rules (level 3).
State-access ordering within opcode execution	2	New state-accessing operations (frame dispatch, APPROVE) need their own ordering rules, and there is a BAL exclusion for protocol signature checks. No existing opcode class's ordering changes, so level 2.	eip.md · Behavior — "before the balance check and before dispatch" Defines the order in which a frame-entry target access is charged relative to the balance check, the new-account state charge and code dispatch. eip.md · APPROVE Instruction — Behavior APPROVE checks balance, charges sender-creation state gas "immediately before incrementing the sender's nonce", then collects max_cost. eip.md · Signature Validation — "must not be added to the block-level access list" ecrecover and P256VERIFY used for signature validation are excluded from the BAL. Confidence: Medium Uncertainty: EIP-7928 is not supplied, so the full BAL-recording consequences of frame-entry accesses cannot be verified.
Transition-tool interface changesUnder-specified	2	Several semantic input and output fields change (transaction structure, signatures, payer, per-frame receipts). There is no clear new exchange mechanism, so level 2.	eip.md · Payload Encoding New transaction input schema: explicit sender, frames with limits, signatures list, fees list. eip.md · Receipt Encoding New receipt output: payer, plus per-frame status, two-dimensional gas_used and logs. Status code 0x2 is new. eip.md · Behavior — "If it is not, the whole transaction is invalid" Invalidity can be determined after frame execution and must be reported as a rejection. Confidence: Medium Uncertainty: No transition-tool evidence was supplied. Reporting execution-dependent rejections might require a new mechanism (level 3).
New test-framework primitives	2	Requires new construction abstractions (frame transaction builder, multi-scheme signer, per-frame receipt and two-dimensional gas expectations) within the target's suite.	eip.md · Signature Hash Signing requires a new sig-hash computation that elides signatures with empty msg. eip.md · Receipt Encoding Tests need per-frame receipt expectations, including mutable state-gas attribution. eip.md · Behavior Tests need frame, atomic batch and approval construction, plus P256 signing. Confidence: Medium Uncertainty: If frame transactions must become a shared transaction-type parameter for existing opcode/state-gas families, this reaches level 3.
Cryptography	2	Several established signature mechanisms (secp256k1 and P256 transaction signatures, with new canonicality and address-derivation rules) are added to EL transaction validation.	eip.md · Signature Validation secp256k1 recovery with v∈{0,1}, canonical r and low-s; P256 verification with low-s and signer = keccak256(qx\|\|qy)[12:]. eip.md · Transaction Signatures Each scheme has its own gas. ARBITRARY entries are only structurally checked. supporting/erc-7562.md · Opcode Rules — OP-062 Refers to an existing P256VERIFY precompile (EIP-7951), which is not supplied. Confidence: Medium Uncertainty: Test resources for P256 are only indirectly evidenced (EIP-7951 is not supplied).
Unspecified behavior requiring cross-client consensusUnder-specified	2	Several localized points have competing plausible outcomes that need spec or client agreement.	eip.md · APPROVE Instruction — Behavior APPROVE can run at depth > 0 (a self-call or DELEGATECALL keeps ADDRESS). The spec does not say whether payer/sender_approved revert when an enclosing sub-call reverts but the frame succeeds. eip.md · Behavior — frame step ordering The entry access charge is listed before the SENDER approval check. If a SENDER frame without approval cannot pay the entry charge, the outcome is unclear: exceptional halt or invalid transaction. eip.md · Transaction settlement effective_gas_price and coinbase priority-fee crediting for frame transactions are not explicitly defined. Confidence: Medium Uncertainty: Supplied dependency text might resolve the fee details, for example by analogy with EIP-1559.
Added system contracts	1	Introduces exactly one stateless protocol-designated contract with no system action.	eip.md · Expiry Verifier Frame A protocol-designated EXPIRY_VERIFIER address with fixed stateless runtime code. Frame validity constraints depend on targeting it. eip.md · Deployment Deployed by an ordinary keyless transaction, not installed at activation. Confidence: Medium Uncertainty: It could be treated as an ordinary contract because it is deployed normally, which would make this 0.
Blob gas accounting changesUnder-specified	1	Existing EIP-4844 blob accounting is reused. Only the funding/settlement parameters change (the payer rather than the sender, and max_cost computed at blob_base_fee). No new blob mechanism is added.	eip.md · Blob handling The payer pays blob_gas * blob_base_fee. max_fee_per_blob_gas is used only for the inclusion check. Blobs are optional. eip.md · Transaction settlement — max_cost max_cost includes blob_gas * blob_base_fee, not max_fee_per_blob_gas. supporting/eip-4844.md · Execution layer validation Under the baseline, the balance check uses max_fee_per_blob_gas and the sender pays. Confidence: Medium Uncertainty: The change in payer and balance-check basis could be read either as a validity-only change (0) or as a new settlement path (2).
Patterns affecting pre-existing tests	1	Baseline behavior of existing transaction types is preserved. Rework is limited to opcode-definition boundary cases (newly allocated byte values listed as valid at the fork) within one family.	eip.md · Introspection — "Executing any of them in the context of any other transaction type results in an exceptional halt" 0xaa and 0xb0–0xb5 become defined but still halt in legacy transaction types. eip.md · Transaction origination Validation for other transaction types remains unchanged. Confidence: Medium Uncertainty: Behavior without a test suite is estimated, not measured.

Show 8 zero-score criteria

Zero-score criteria (Checklist revision 3)
Criterion	Why this score	Evidence / uncertainty
Added precompiles	No new precompile.	eip.md · Specification No precompile addresses are introduced.
Modified precompiles	No precompile semantics or gas change.	eip.md · Signature Validation — Note ecrecover/P256VERIFY are used natively for validation. Precompile behavior is unchanged.
Modified system contracts	No existing system contract changes.	eip.md · Examples — Example 1b The EIP-7997 factory is used unchanged.
New EVM gas refund	No new refund-counter mechanism is introduced. The cross-frame state-gas refill attribution is scored under state gas accounting.	eip.md · Transaction settlement — "Storage gas refunds (EIP-3529) accumulate across frames" The existing refund counter becomes transaction-scoped across frames and is reverted with frames or batches. No new refund trigger is introduced. eip.md · Transaction settlement — "a state-gas refill ... is not subject to the refund cap" Cross-frame refills are state-gas refills, not refunds. Uncertainty: The cross-frame refill crediting via owner receipts is history-dependent. It could be classified as a complex new refund (level 2).
New block / header fields	No new header field.	eip.md · Block-level gas accounting — "block header gas_used ... follow EIP-8037 unchanged" No header member is added.
New fork activation mechanism	No activation-specific state transition.	eip.md · Expiry Verifier Frame — "it is not installed by the protocol at activation" There is no activation-time installation.
Engine API changesUnder-specified	Transactions remain opaque in payloads, and no Engine API field or endpoint is specified.	eip.md · Networking Only p2p messages (Receipts, PooledTransactions) are specified. No Engine API changes are stated. Uncertainty: The EIP does not say how frame-transaction blob versioned hashes interact with newPayload's blob hash checks.
New invariant on pre-existing tests	Baseline tests on existing transaction types gain no new output to assert.	eip.md · Receipt Encoding The new receipt fields (payer, frame receipts) exist only for frame transactions.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@6dac5e7491 EIPS/eip-8141.md committed 2026-10-07 · information cutoff 2026-10-07T22:23:55Z
Current master · File history · blob 4e73f1e1f0 · sha256 c4f69c7da817
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-8141.yaml · sha256 de6dfa2e1879
Supporting documents supplied with the EIP: supporting/eip-20.md, supporting/eip-1559.md, supporting/eip-2718.md, supporting/eip-2780.md, supporting/eip-2929.md, supporting/eip-3529.md, supporting/eip-3607.md, supporting/eip-3651.md, supporting/eip-4337.md, supporting/eip-4844.md, supporting/eip-6780.md, supporting/eip-7594.md, supporting/eip-7702.md, supporting/eip-7708.md, supporting/eip-7778.md, supporting/eip-7819.md, supporting/eip-7825.md, supporting/eip-7843.md, supporting/eip-7976.md, supporting/eip-7997.md, supporting/eip-8037.md, supporting/eip-8038.md, supporting/erc-7562.md

Evaluated on: Not recorded

38HighHigh

Evaluator: HumanChecklist v1
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2026-08-11
Source: merged ethspecs/pm checklist

Score bands · Checklist revision 1

Low <10
Medium 10–19
High ≥20

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

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-8141 Hegotá: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
Added opcodesExceptional	4	Exceeds defined anchors: six new opcodes in a single EIP (~2-3× typical precedent of 1-2). Frame introspection. Signature metadata access. Testing will involve interaction with legacy txs types as well.	—
Edge/boundary conditionsExceptional	4	Exceeds defined anchors: combinatorial explosion across mechanisms rather than a single elevated-case mechanism. Frame modes × flags × atomic-batch state × signature schemes × APPROVE scope matrix × default-code branches; further compounded by atomic batching, and cross-frame access.	—
Modified opcodes	3	Behavior of some opcodes like `ORIGIN` changes under the new transaction type.	—
New EVM gas refund	3	New complex refund mechanism: post-execution refund of gas to a designated `payer` resolved at runtime, plus full refund of skipped frames in failed atomic batches. Multiple refund paths; forces rework of existing refund-flow test infrastructure.	—
New transaction types	3	New tx type 0x06 (frame transaction).	—
New or modified transaction validity mechanisms	3	New intrinsic gas formula (mixed per-frame + per-signature + sum-of-frame-limits + calldata over two separate RLP streams), upfront multi-signature validation, frame-level constraints (mode/value/flags/count), runtime payer-designation and sender-approval. Introduces a post execution validity check which is totally new to EELS. Requires extensive test-infrastructure rework (filler intrinsic-gas computation, multi-scheme signing helpers etc).	—
New fork activation mechanism	3	Clients install `EXPIRY_VERIFIER` runtime code at address `0x8141` at fork activation — a state modification at the activation block.	—
Security risks	3	Interacts with multiple critical subsystems: tx authentication (new multi-sig + scheme based dispatch), mempool relay policy, the EOA-vs-contract invariant (EIP-3607 relaxation lets contracts execute under SENDER mode), and ORIGIN semantics. The EIP itself enumerates non-trivial attack vectors: timestamp-dependency attack, deploy-frame front-running, state-read amplification via explicit sender, cross-frame privacy leakage, paymaster griefing, and mempool DoS via invalid `tx.sender` probing. Requires extensive review and fuzzing across protocol and mempool layers.	—
EVM Gas rule changes	2	New per-frame gas isolation (`gas_limit` allocated per frame, not carried forward across frames) and new opcode gas costs (TXPARAM/FRAMEPARAM/SIGPARAM = 2, FRAMEDATALOAD = 3, FRAMEDATACOPY = 3 + word copy + mem expansion, APPROVE = 0). New mechanism, but applies only to type 0x06 frames and does not modify legacy tx gas accounting.	—
Block syncing changes	2	Two new RLP validation mechanisms that affect syncing clients: (1) the type 0x06 tx-RLP envelope; (2) the corresponding new receipt-RLP shape (important for receipts root).	—
Performance risks	2	Per-tx cost scales with frame count (≤64) and signature count, but is bounded and parameterizable. New opcodes individually benchmarkable. Main new concern is mempool DoS surface from validation-prefix work on rejected txs. This however is capped. Doesn't materially change existing performance baselines for legacy/1559/blob/7702 txs.	—
Cross-EIP interactions	2	Strong interaction with FOCIL: FOCIL relies on attesters performing lightweight static validity checks (nonce + balance) on inclusion-list transactions without executing them. Frame transactions break this assumption.	—
Added system contracts	1	`EXPIRY_VERIFIER` at address `0x8141`, installed by clients at fork activation.	—
Transition-tool interface changes	1	No new block-environment fields, header inputs. Frame txs flow through standard EIP-2718 typed-tx dispatch. The one interface-side change is the receipt output schema, which gains a new shape for type 0x06: `[cumulative_gas_used, payer, [frame_receipt, ...]]` with a top-level `payer` field (resolved at runtime).	—
Patterns affecting pre-existing tests	1	New tx type is self-contained; legacy/1559/blob/7702 tx flows unchanged. Only minor impact on pre-existing opcode tests (new opcodes APPROVE/TXPARAM/FRAMEPARAM/SIGPARAM/FRAMEDATALOAD/FRAMEDATACOPY are globally available in the EVM regardless of tx type, so their behavior must be defined when invoked from legacy txs).	—
Cryptography	1	Introduces P256 as a tx-authentication primitive for the first time via a scheme dispatcher (0x0 = SECP256K1, 0x1 = P256). Verification is defined as the P256VERIFY cryptographic operation.	—

Show 8 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Notes
Added precompiles	None	—
Modified precompiles	None	—
Modified system contracts	None	—
Blob gas accounting changes	Frame tx carries EIP-4844 blob fields (`max_fee_per_blob_gas`, `blob_versioned_hashes`) but reuses existing blob gas accounting unmodified.	—
New block / header fields	None	—
Encoding changes (RLP/SSZ)	All encodings remain RLP — no format migration.	—
Engine API changes	No new or modified Engine API endpoints, fields, or communication mechanisms.	—
Engine API encoding changes	None	—

Assessment provenance

Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Merged checklist ethspecs/pm@3d8c0128c5 complexity_assessments/EIPs/EIP-8141.md · committed 2026-08-11
blob c00d071cd8 · sha256 5ee8d6adab64
Research record: research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8141.yaml · sha256 a7d7b4d1325c

The LLM applied checklist revision 3 and the human reviewers revision 1 to EIP-8141 in Hegotá. Revision 3 phrases the same criteria more precisely; differences cover the 23 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.

LLM52High

Human38High

Δ total+14Same tier

Criteria12/23agree exactly · 7 differ by 1 · 4 differ by 2+

Complexity profiles side by side

LLM

Human

Largest disagreements: New EVM gas refund (−3), Encoding changes (RLP/SSZ) (+3), New fork activation mechanism (−3), Cross-EIP interactions (+3), Blob gas accounting changes (+1)

Show differences only (17 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
New EVM gas refund	0	3	−3	Differ by 2+	Show rationale LLM No new refund-counter mechanism is introduced. The cross-frame state-gas refill attribution is scored under state gas accounting. Human New complex refund mechanism: post-execution refund of gas to a designated `payer` resolved at runtime, plus full refund of skipped frames in failed atomic batches. Multiple refund paths; forces rework of existing refund-flow test infrastructure.
Encoding changes (RLP/SSZ)	3	0	+3	Differ by 2+	Show rationale LLM New transaction, receipt and p2p schemas. Human All encodings remain RLP — no format migration.
New fork activation mechanism	0	3	−3	Differ by 2+	Show rationale LLM No activation-specific state transition. Human Clients install `EXPIRY_VERIFIER` runtime code at address `0x8141` at fork activation — a state modification at the activation block.
Cross-EIP interactions	5	2	+3	Differ by 2+	Show rationale LLM The target couples multiple EIPs' behavior inside one settlement and frame-execution model. That requires coordinated scenarios across them, so level 3. Human Strong interaction with FOCIL: FOCIL relies on attesters performing lightweight static validity checks (nonce + balance) on inclusion-list transactions without executing them. Frame transactions break this assumption.
Blob gas accounting changes	1	0	+1	Differ by 1	Show rationale LLM Existing EIP-4844 blob accounting is reused. Only the funding/settlement parameters change (the payer rather than the sender, and max_cost computed at blob_base_fee). No new blob mechanism is added. Human Frame tx carries EIP-4844 blob fields (`max_fee_per_blob_gas`, `blob_versioned_hashes`) but reuses existing blob gas accounting unmodified.
New or modified transaction validity mechanisms	4	3	+1	Differ by 1	Show rationale LLM Validity is now decided partly by EVM execution across frames. Tests need restructured validation sequencing and coordinated state scenarios (e.g., a DEFAULT frame changing state that a later VERIFY frame depends on). Human New intrinsic gas formula (mixed per-frame + per-signature + sum-of-frame-limits + calldata over two separate RLP streams), upfront multi-signature validation, frame-level constraints (mode/value/flags/count), runtime payer-designation and sender-approval. Introduces a post execution validity check which is totally new to EELS. Requires extensive test-infrastructure rework (filler intrinsic-gas computation, multi-scheme signing helpers etc).
Block syncing changes	3	2	+1	Differ by 1	Show rationale LLM Block import must decode a new transaction type and apply several structural rules, including complex cross-transaction reservation checks. Human Two new RLP validation mechanisms that affect syncing clients: (1) the type 0x06 tx-RLP envelope; (2) the corresponding new receipt-RLP shape (important for receipts root).
Transition-tool interface changes	2	1	+1	Differ by 1	Show rationale LLM Several semantic input and output fields change (transaction structure, signatures, payer, per-frame receipts). There is no clear new exchange mechanism, so level 2. Human No new block-environment fields, header inputs. Frame txs flow through standard EIP-2718 typed-tx dispatch. The one interface-side change is the receipt output schema, which gains a new shape for type 0x06: `[cumulative_gas_used, payer, [frame_receipt, ...]]` with a top-level `payer` field (resolved at runtime).
Performance risks	3	2	+1	Differ by 1	Show rationale LLM Several new workload couplings need integrated stress testing across subsystems: signature verification per entry (P256/secp256k1), up to 64 frames with per-frame receipts hashed into the trie, execution-dependent invalidity during block building, and mempool simulation and revalidation. Human Per-tx cost scales with frame count (≤64) and signature count, but is bounded and parameterizable. New opcodes individually benchmarkable. Main new concern is mempool DoS surface from validation-prefix work on rejected txs. This however is capped. Doesn't materially change existing performance baselines for legacy/1559/blob/7702 txs.
Edge/boundary conditions	3	4	−1	Differ by 1	Show rationale LLM Many boundary-sensitive rules are added. APPROVE outcomes and frame dispatch form an elevated matrix: mode × flags/scope × target resolution (null/sender/other, code/delegated/empty/precompile) × approval state × balance and pool exhaustion. Human Exceeds defined anchors: combinatorial explosion across mechanisms rather than a single elevated-case mechanism. Frame modes × flags × atomic-batch state × signature schemes × APPROVE scope matrix × default-code branches; further compounded by atomic batching, and cross-frame access.
Cryptography	2	1	+1	Differ by 1	Show rationale LLM Several established signature mechanisms (secp256k1 and P256 transaction signatures, with new canonicality and address-derivation rules) are added to EL transaction validation. Human Introduces P256 as a tx-authentication primitive for the first time via a scheme dispatcher (0x0 = SECP256K1, 0x1 = P256). Verification is defined as the P256VERIFY cryptographic operation.
Added opcodes	4	4	0	Agree	Show rationale LLM Seven instructions are added, several of them complex. The level-3 condition is met. Human Exceeds defined anchors: six new opcodes in a single EIP (~2-3× typical precedent of 1-2). Frame introspection. Signature metadata access. Testing will involve interaction with legacy txs types as well.
Modified opcodes	3	3	0	Agree	Show rationale LLM Existing instruction semantics change: ORIGIN return values and transient-storage lifetime. Human Behavior of some opcodes like `ORIGIN` changes under the new transaction type.
Added precompiles	0	0	0	Agree	Show rationale LLM No new precompile. Human None
Modified precompiles	0	0	0	Agree	Show rationale LLM No precompile semantics or gas change. Human None
Added system contracts	1	1	0	Agree	Show rationale LLM Introduces exactly one stateless protocol-designated contract with no system action. Human `EXPIRY_VERIFIER` at address `0x8141`, installed by clients at fork activation.
Modified system contracts	0	0	0	Agree	Show rationale LLM No existing system contract changes. Human None
EVM Gas rule changes	2	2	0	Agree	Show rationale LLM Adds a new execution-gas accounting mechanism for the new envelope: per-frame pools, the frame-entry access charge, intrinsic decomposition, signature-verification gas, floor/settlement and per-dimension block reservation. Gas results for baseline operations in existing transaction types are unchanged, so level 2. Human New per-frame gas isolation (`gas_limit` allocated per frame, not carried forward across frames) and new opcode gas costs (TXPARAM/FRAMEPARAM/SIGPARAM = 2, FRAMEDATALOAD = 3, FRAMEDATACOPY = 3 + word copy + mem expansion, APPROVE = 0). New mechanism, but applies only to type 0x06 frames and does not modify legacy tx gas accounting.
New transaction types	3	3	0	Agree	Show rationale LLM Introduces a distinct transaction envelope. Human New tx type 0x06 (frame transaction).
New block / header fields	0	0	0	Agree	Show rationale LLM No new header field. Human None
Engine API changes	0	0	0	Agree	Show rationale LLM Transactions remain opaque in payloads, and no Engine API field or endpoint is specified. Human No new or modified Engine API endpoints, fields, or communication mechanisms.
Patterns affecting pre-existing tests	1	1	0	Agree	Show rationale LLM Baseline behavior of existing transaction types is preserved. Rework is limited to opcode-definition boundary cases (newly allocated byte values listed as valid at the fork) within one family. Human New tx type is self-contained; legacy/1559/blob/7702 tx flows unchanged. Only minor impact on pre-existing opcode tests (new opcodes APPROVE/TXPARAM/FRAMEPARAM/SIGPARAM/FRAMEDATALOAD/FRAMEDATACOPY are globally available in the EVM regardless of tx type, so their behavior must be defined when invoked from legacy txs).
Security risks	3	3	0	Agree	Show rationale LLM Shared authorization and trust invariants change across components: the transaction pool, EVM approval, payer settlement, ORIGIN-based checks and sender identity. This needs coordinated adversarial scenarios. Human Interacts with multiple critical subsystems: tx authentication (new multi-sig + scheme based dispatch), mempool relay policy, the EOA-vs-contract invariant (EIP-3607 relaxation lets contracts execute under SENDER mode), and ORIGIN semantics. The EIP itself enumerates non-trivial attack vectors: timestamp-dependency attack, deploy-frame front-running, state-read amplification via explicit sender, cross-frame privacy leakage, paymaster griefing, and mempool DoS via invalid `tx.sender` probing. Requires extensive review and fuzzing across protocol and mempool layers.
State-access ordering within opcode execution	2	n/a	—	Only in revision 3	Show rationale LLM New state-accessing operations (frame dispatch, APPROVE) need their own ordering rules, and there is a BAL exclusion for protocol signature checks. No existing opcode class's ordering changes, so level 2. Human No rationale recorded.
State gas accounting changes	3	n/a	—	Only in revision 3	Show rationale LLM Introduces a new state-gas charging and attribution mechanism (frame-scoped pools, owner-frame refills, receipt mutation with rollback) and new charge sites, replacing the baseline reservoir/spill accounting. This meets level 3. Human No rationale recorded.
Engine API encoding changes	n/a	0	—	Only in revision 1	Show rationale LLM No rationale recorded. Human None
New invariant on pre-existing tests	0	n/a	—	Only in revision 3	Show rationale LLM Baseline tests on existing transaction types gain no new output to assert. Human No rationale recorded.
New test-framework primitives	2	n/a	—	Only in revision 3	Show rationale LLM Requires new construction abstractions (frame transaction builder, multi-scheme signer, per-frame receipt and two-dimensional gas expectations) within the target's suite. Human No rationale recorded.
Unspecified behavior requiring cross-client consensus	2	n/a	—	Only in revision 3	Show rationale LLM Several localized points have competing plausible outcomes that need spec or client agreement. Human No rationale recorded.

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