Retrospective LLM-Based Complexity Evaluations

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-08-25CFI at snapshotLayers: execution
LLM Completescore 60
Human Completescore 38 · Checklist revision 1· merged checklist
Other checklist versions (1)
LLM · Checklist revision 22026-09-11 · Original snapshot · 60Human · Checklist revision 1Complete · 38

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

Scope at the cutoff. Execution-layer-only assessment of the Draft EIP-8141 text frozen at the 2026-08-26 Hegota snapshot. The assessed surface is the new typed frame transaction, its validation and per-frame execution model, gas payment and two-dimensional gas accounting, receipt and networking encodings, EVM instructions, activation-time expiry verifier, and public-mempool policy.

60HighHigh
Evaluator
LLMChecklist v2
Confidence
Medium
Under-specified at assessment cutoff
Yes — 6 criteria affected
Plausible range
58–61 (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

  1. Cross-EIP interactions9
  2. Added opcodes3
  3. Modified opcodes3
  4. EVM Gas rule changes3

Under-specified at assessment cutoff: Yes

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

Why: The Draft specifies the central frame execution and gas mechanisms in substantial detail, but leaves material interoperability gaps in fee validation and settlement, the P256 verification dependency, activation-state handling, transition/test interfaces, and public-mempool paymaster rules. These gaps are recorded once here and are not multiplied across unrelated anchors.

Plausible total

58–61
recorded score 60 · plausible tiers High

Unresolved questions at the cutoff (5)
  • Which exact EIP-1559 validity checks, effective-gas-price calculation, priority-fee transfer, base-fee burn, and escrow order apply when payer and sender differ?
  • What happens at activation if EXPIRY_VERIFIER already has a balance, nonce, code, or storage, and which account fields must the irregular transition preserve or replace?
  • Which precise P256VERIFY primitive and failure semantics are consensus inputs to protocol-level P256 signature validation?
  • What is the canonical paymaster runtime code and delayed-withdrawal state layout, and are non-canonical paymasters admitted to the public mempool?
  • How are the nested transaction fields, mutable per-frame receipt values, and two-dimensional block outputs represented in transition-tool and test framework interfaces?
Notable ambiguities noted by the assessor (3)
  • The canonical-paymaster section says a paymaster transaction is eligible only for an exact canonical code match, while the immediately following non-canonical section defines an admission cap and balance checks for non-canonical paymasters.
  • compute_sig_hash is expressed by mutating signature bytes in tx rather than explicitly hashing a copy, leaving the lifetime of that mutation implicit.
  • Frame target nullability and several integer domains are constrained at a semantic level, but their exact RLP scalar/null representations are not exhaustively stated.

Criterion breakdown

EIP-8141 Hegotá: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
Cross-EIP interactionsExceptional9Strong coordinated coverage is required for EIPs 2, 1559, 2718, 2780, 2929, 3529, 3607, 3651, 4844, 6780, 7594, 7623, 7702, 7708, 7778, 7819, 7825, 7843, 7928, 7976, 7997, 8037, and 8038. With 23 identified EIPs, the uncapped rule gives base 3 plus floor((23 - 3) / 3) = 6, for score 9.

Exceptional score: This is not a discretionary exceptional score; it is the rubric's uncapped cross-EIP formula applied mechanically to 23 identified interactions.

  • eip.md · Front matter > requires Declares thirteen required EIPs spanning fee markets, typed envelopes, intrinsic and state gas, refunds, sender validity, blobs, networking, calldata floors, delegation, transfer logs, block accounting, and the transaction execution cap.
  • eip.md · Specification > Frame Transaction > Cross-frame interactions Directly composes warm/cold initialization, coinbase warming, delegation, rollback, and state-gas ownership behavior across frames.
  • eip.md · Specification > Mempool > Banned Opcodes Adds coordinated public-mempool handling for SLOTNUM and SETDELEGATE and the broader validation-prefix opcode/state rules.
  • eip.md · Specification > Networking Reuses typed-envelope and PeerDAS blob-wrapper rules for plain and blob-carrying frame transactions.
Confidence: Medium
Uncertainty: Mere motivational examples involving ERC-20 and ERC-4337, and inspiration from unavailable ERC-7562, were not counted because the specified protocol does not depend on their behavior.
Interacting EIPs: EIP-2, EIP-1559, EIP-2718, EIP-2780, EIP-2929, EIP-3529, EIP-3607, EIP-3651, EIP-4844, EIP-6780, EIP-7594, EIP-7623, EIP-7702, EIP-7708, EIP-7778, EIP-7819, EIP-7825, EIP-7843, EIP-7928, EIP-7976, EIP-7997, EIP-8037, EIP-8038
Added opcodes3Seven instructions are introduced and several are complex due to dynamic data, memory, stack, state, or transaction-context behavior.
  • eip.md · Specification > APPROVE Instruction (0xaa) Adds a three-operand instruction that exits a call frame, returns memory, and conditionally updates approval, payer, nonce, balance, and state gas.
  • eip.md · Specification > Introspection Adds TXPARAM, FRAMEDATALOAD, FRAMEDATACOPY, FRAMEPARAM, SIGPARAM, and SIGDATACOPY, including dynamically metered memory-copy instructions.
Confidence: High
Uncertainty: No uncertainty affects the count or complexity classification.
Modified opcodes3At least ORIGIN has a non-gas behavioral modification for the new transaction context, which mechanically selects score 3.
  • eip.md · Specification > Frame Transaction > Behavior Changes ORIGIN in every call depth of a frame transaction to return the frame caller rather than the traditional transaction origin.
  • eip.md · Specification > Gas Accounting > Blob handling Extends existing BLOBHASH behavior to return the frame transaction's blob hashes in every frame.
Confidence: High
Uncertainty: The score does not duplicate gas-only changes, which are handled in the gas anchors.
EVM Gas rule changesUnder-specified3The proposal introduces a broad gas-accounting mechanism and changes how existing refund, calldata-floor, warm/cold, and block-accounting mechanisms apply to the new transaction, requiring regression coverage of those existing mechanisms.
  • eip.md · Specification > Gas Accounting Defines a new intrinsic-cost formula, explicit per-frame execution and state pools, transaction settlement, calldata-floor handling, and separate block-accounting dimensions.
  • eip.md · Specification > Gas Accounting > Transaction settlement Composes unused frame gas, the existing storage refund counter, the calldata floor, and payer settlement into new transaction-level formulas.
Confidence: High
Uncertainty: The scope is clear, although some fee-settlement details are separately recorded as under-specified.
State gas accounting changes3This is a new state-gas charging and attribution mechanism, including a deliberate change to the execution/state spill relationship and extensive interactions with existing state-gas tests.
  • eip.md · Specification > Gas Accounting > Frame gas pools Replaces the EIP-8037 reservoir inside frame transactions with independent per-frame execution and state pools that cannot borrow from one another.
  • eip.md · Specification > Gas Accounting > State-gas attribution and refills Introduces frame ownership records, cross-frame receipt reductions, frame-local refill rules, and journaling across call, frame, and atomic batch rollback boundaries.
Confidence: High
Uncertainty: No uncertainty affects the anchor level; individual omitted settlement details are recorded separately.
New transaction types3A new transaction type mechanically selects score 3.
  • eip.md · Specification > Frame Transaction Introduces an EIP-2718 transaction with FRAME_TX_TYPE 0x06.
Confidence: High
Uncertainty: No uncertainty affects this binary anchor.
New or modified transaction validity mechanisms3The new validity model is execution-dependent and broad enough to require extensive transaction-test and validation-infrastructure work.
  • eip.md · Specification > Frame Transaction > Constraints Adds extensive structural and aggregate validity rules for the outer payload, signatures, frames, modes, flags, blobs, and gas limits.
  • eip.md · Specification > Frame Transaction > Behavior Makes nonce, signature validation, VERIFY success, sender approval, payer approval, and post-execution payer presence transaction-validity gates.
Confidence: High
Uncertainty: Several missing fee and helper details add uncertainty but cannot lower the documented mechanism below score 3.
Encoding changes (RLP/SSZ)3Transaction and receipt encoding changes mechanically select score 3.
  • eip.md · Specification > Frame Transaction > Payload Encoding Defines a new transaction-level RLP layout containing nested frames, limits, signatures, fees, and blob hashes.
  • eip.md · Specification > Frame Transaction > Receipt Encoding Defines a new receipt-level encoding with payer and nested frame receipts.
Confidence: High
Uncertainty: This score concerns the existence of the encoding change; individual field representation ambiguities are recorded separately.
Block syncing changes3Syncing clients face multiple RLP validation mechanisms, including complex transaction and receipt payloads; at least one is complex.
  • eip.md · Specification > Frame Transaction > Payload Encoding Introduces a deeply nested RLP transaction payload with variable frame and signature lists.
  • eip.md · Specification > Frame Transaction > Receipt Encoding Introduces a distinct nested receipt payload with payer and per-frame status, gas, and logs.
  • eip.md · Specification > Networking Requires sync/network paths to distinguish plain and blob-wrapped frame transactions and to encode the new receipt form.
Confidence: High
Uncertainty: The score concerns execution-client block and receipt processing, not the consensus-layer sidecar protocol.
New fork activation mechanismUnder-specified3Activation modifies state by installing contract code, mechanically selecting score 3.
  • eip.md · Specification > Expiry Verifier Frame Requires clients to install prescribed runtime bytecode at address 0x8141 at activation.
Confidence: High
Uncertainty: Collision and account-field handling at the destination are not specified, but the required state modification itself is explicit.
Transition-tool interface changesUnder-specified3Transition tooling needs multiple new input and output fields together with a new multi-frame execution/result mechanism, satisfying the highest ordinary anchor.
  • eip.md · Specification > Frame Transaction > Payload Encoding Adds multiple nested transaction inputs for frames, signatures, fees, execution/state limits, and optional blob hashes.
  • eip.md · Specification > Frame Transaction > Receipt Encoding Adds a payer plus a variable list of per-frame status, two-dimensional gas usage, and logs, including later mutation of earlier state-gas usage.
Confidence: Medium
Uncertainty: The EIP does not specify a concrete transition-tool mapping, so exact field placement is an implementation question recorded under under-specification.
Security risks3The proposal substantially alters security assumptions across transaction authentication, account authority, fee payment, mempool admission, networking, execution, and rollback, requiring extensive review and fuzzing.
  • eip.md · Security Considerations Documents propagation DoS, deploy front-running, sender-read amplification, signature malleability, cross-frame visibility, state-gas isolation, and over-broad execution approval hazards.
  • eip.md · Specification > APPROVE Instruction (0xaa) > Behavior Moves authentication, sender authority, nonce consumption, fee escrow, and payer selection into contract-driven frame execution.
Confidence: High
Uncertainty: Missing canonical-paymaster and helper details increase review uncertainty but do not change the score.
Performance risks3Performance cannot be validated in isolation because transaction admission, arbitrary validation execution, state dependency tracking, multi-frame journaling, payer exposure, and blob networking interact with core client paths and existing benchmarks.
  • eip.md · Specification > Mempool Requires signature validation, validation-prefix simulation, dependency tracking, payer reservation, replacement accounting, and selective re-simulation for public propagation.
  • eip.md · Security Considerations > Transaction Propagation Identifies denial-of-service vectors from arbitrary EVM validation, shared-state invalidation, and explicit sender state-read amplification.
Confidence: High
Uncertainty: The package provides no measurements, but it explicitly establishes the coupled mechanisms and DoS workload requiring validation.
Edge/boundary conditions3Multiple boundary-prone mechanisms combine multiplicatively, especially frame ordering, cold/warm state, delegated/default/precompile dispatch, two gas pools, approvals, and nested rollback modes; this requires an elevated test matrix.
  • eip.md · Specification > Frame Transaction > Constraints Defines numerous numeric, length, count, mode/flag, target, batch, blob, signature, and aggregate-gas boundaries, including a 64-frame maximum.
  • eip.md · Specification > Gas Accounting > State-gas attribution and refills Requires outcomes across success, revert, exceptional halt, later refill, call rollback, frame rollback, and atomic-batch rollback.
Confidence: High
Uncertainty: Some unspecified cases may add vectors, but the documented cases already satisfy score 3.
State-access ordering within opcode execution2New frame-entry and APPROVE state-accessing operations have consensus-critical access and charge positions that must be tested, but the proposal does not reorder an existing class of state-accessing opcodes.
  • eip.md · Specification > Frame Transaction > Behavior Requires the resolved target's warm/cold access charge before the balance check and dispatch, and places new-account state charging after the balance check but before frame code executes.
  • eip.md · Specification > APPROVE Instruction (0xaa) > Behavior Places a conditional sender-creation state-gas charge immediately before nonce increment and approval effects.
Confidence: High
Uncertainty: EIP-8037 opcode charge points are explicitly retained; the score is for the new frame-level and APPROVE ordering boundaries.
Blob gas accounting changes2A new blob-capable transaction and payer rule are introduced without changing the existing blob transaction's mechanism, so new tests are needed while pre-existing blob behavior remains intact.
  • eip.md · Specification > Gas Accounting > Blob handling Makes blobs optional for frame transactions, makes the dynamically chosen payer the blob-fee payer, applies the blob base fee directly, and counts frame-transaction blobs against existing fork limits.
  • supporting/eip-4844.md · Specification > Gas accounting Defines the pre-existing independent blob-gas and sender-paid blob-fee mechanism that EIP-8141 extends to its new envelope.
Confidence: High
Uncertainty: The general blob path is explicit; broader fee-settlement omissions are tracked under under-specification.
New test-framework primitivesUnder-specified2Reusable transaction builders and per-frame receipt/rollback expectation primitives are required within this EIP's suite, but the package does not establish adoption by other EIP suites.
  • eip.md · Specification > Frame Transaction > Receipt Encoding Tests must express and inspect ordered per-frame receipts whose state-gas values can be changed by later frames.
  • eip.md · Specification > Frame Transaction > Behavior Tests must construct frame sequences, approval context, skipped frames, and atomic-group rollback outcomes not representable as ordinary single top-level calls.
Confidence: Medium
Uncertainty: The package contains no test-framework design, so the exact primitive split is not specified.
CryptographyUnder-specified2Multiple well-known cryptographic verification mechanisms are added to transaction validity; no novel cryptosystem is defined by the package.
  • eip.md · Specification > Transaction Signatures Introduces protocol-handled SECP256K1 and P256 signature schemes alongside structurally checked ARBITRARY witnesses, each with distinct encodings and costs.
  • eip.md · Specification > Signature Validation Specifies canonical scalar bounds, low-s rules, signer recovery or public key derivation, and P256 proof verification before frame execution.
Confidence: Medium
Uncertainty: The P256VERIFY helper is referenced but not defined or linked to a numbered EIP in the package.
Unspecified behavior requiring cross-client consensusUnder-specified2Several constructible fee, activation, cryptographic-helper, and public mempool cases need agreement before interoperable baselines can be written. They are material but are localized omissions in newly introduced mechanisms, rather than a formerly unobservable behavior newly exposed by the proposal.
  • eip.md · Specification > Gas Accounting > Transaction settlement Uses effective_gas_price and payer max-cost collection without fully defining EIP-1559 fee validity, priority-fee disposition, and all payer balance/escrow steps in this transaction model.
  • eip.md · Specification > Mempool > Paymasters Requires exact canonical-paymaster runtime matching and pending-withdrawal accounting without providing the canonical implementation, while separate passages disagree on whether non-canonical paymasters are eligible.
  • eip.md · Specification > Expiry Verifier Frame Requires activation-time code installation without defining the result if the destination already has balance, nonce, code, or storage.
Confidence: Medium
Uncertainty: The package contains no permitted implementation, devnet, or discussion evidence, so this score is based only on the Draft text's internal coverage.
Added system contracts1One non-stateful system contract is added and it triggers no new consensus request or other system action.
  • eip.md · Specification > Expiry Verifier Frame Requires clients to install fixed runtime code at EXPIRY_VERIFIER on activation; the code only checks calldata against block timestamp and has no persistent writes or system action.
Confidence: High
Uncertainty: How installation interacts with pre-existing state at the address is separately under-specified, but the contract's normal behavior is stateless.
Patterns affecting pre-existing tests1A minor subset of existing invalid-instruction, generic transaction, receipt, and fork-transition tests must be adjusted; most existing tests do not change unless exercised through the new transaction type.
  • eip.md · Backwards Compatibility Changes ORIGIN only in frame transactions and requires new two-dimensional estimation behavior, while leaving ordinary transaction execution outside the new envelope unchanged.
  • eip.md · Specification > Introspection Assigns formerly unavailable instruction bytes and specifies exceptional halts for those instructions outside frame transactions.
Confidence: Medium
Uncertainty: No packaged test inventory is available, so the affected subset is inferred from the protocol deltas rather than measured.
Show 7 zero-score criteria
Zero-score criteria (Checklist revision 2)
CriterionScoreWhy this scoreEvidence / uncertainty
Added precompiles0No precompile is added.
  • eip.md · Specification > Signature Validation Uses ecrecover and P256VERIFY as existing helpers and explicitly discusses the related precompiles; it does not allocate a new precompile address.
Uncertainty: Protocol-level invocation of an existing verification primitive is scored under cryptography, not as a new precompile.
Modified precompiles0Existing precompiles are invoked without modification.
  • eip.md · Specification > Signature Validation States only that out-of-EVM signature checks must not add their related precompiles to the block-level access list; no precompile logic or gas schedule is changed.
Uncertainty: The access-list side effect is a transaction-processing rule rather than a change to precompile behavior.
Modified system contracts0No pre-existing system contract is directly or indirectly modified by the specified frame-transaction behavior.
  • eip.md · Specification > Expiry Verifier Frame Defines a newly installed verifier rather than changing the code or state of any pre-existing system contract.
Uncertainty: Ordinary ability to call an existing contract from a frame is not itself a modification of that contract.
New EVM gas refund0No new EVM refund mechanism is introduced; the complex state-gas refill and attribution behavior is scored under state gas accounting rather than duplicated here.
  • eip.md · Specification > Gas Accounting > Transaction settlement Retains the EIP-3529 transaction-scoped storage refund counter and distinguishes state-gas refills, which directly reverse state charges, from capped EVM refunds.
Uncertainty: Unused-budget repayment and state-gas refills are not treated as new EVM gas-refund mechanisms under this anchor.
New block / header fields0No new block or header field is introduced by EIP-8141.
  • eip.md · Specification > Gas Accounting > Block-level gas accounting Uses the block header gas_used, block gas limit, and EIP-8037 accounting without defining an additional block or header field.
Uncertainty: Internal block-output counters are not header fields.
Engine API changes0The frame transaction is carried within existing payload transaction bytes; the EIP introduces no Engine API fields, objects, or methods.
  • eip.md · Specification > Networking Specifies execution-network Receipts, PooledTransactions, and BlockBodies behavior but no Engine API field or endpoint.
Uncertainty: EIP-7843 Engine API changes in a supporting document belong to that EIP and are not assigned to EIP-8141.
New invariant on pre-existing tests0The proposal does not require tests unrelated to frame transactions to add a new universal assertion.
  • eip.md · Specification > Frame Transaction > Receipt Encoding The new payer and per-frame receipt values exist only for frame transactions rather than becoming an output of every transaction or test.
Uncertainty: Activation-state tests are specific to this EIP and therefore do not constitute a new invariant on unrelated pre-existing tests.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@ac450a4ab2 EIPS/eip-8141.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z
Current master · File history · blob fb1336b35f · sha256 68c512f08bb6
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/extensions/sfi-cfi-2026-08-26/outputs/assessments/eip-8141.yaml · sha256 2e9780ddf89b
Supporting documents in the sealed package
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-7623.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

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

Top complexity drivers

  1. Added opcodes4
  2. Edge/boundary conditions4
  3. Modified opcodes3
  4. New EVM gas refund3

Criterion breakdown

EIP-8141 Hegotá: Human criterion scores and rationale
CriterionScoreWhy this scoreNotes
Added opcodesExceptional4Exceeds 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 conditionsExceptional4Exceeds 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 opcodes3Behavior of some opcodes like `ORIGIN` changes under the new transaction type.—
New EVM gas refund3New 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 types3New tx type 0x06 (frame transaction).—
New or modified transaction validity mechanisms3New 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 mechanism3Clients install `EXPIRY_VERIFIER` runtime code at address `0x8141` at fork activation — a state modification at the activation block.—
Security risks3Interacts 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 changes2New 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 changes2Two 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 risks2Per-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 interactions2Strong 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 contracts1`EXPIRY_VERIFIER` at address `0x8141`, installed by clients at fork activation.—
Transition-tool interface changes1No 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 tests1New 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).—
Cryptography1Introduces 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)
CriterionScoreWhy this scoreNotes
Added precompiles0None—
Modified precompiles0None—
Modified system contracts0None—
Blob gas accounting changes0Frame tx carries EIP-4844 blob fields (`max_fee_per_blob_gas`, `blob_versioned_hashes`) but reuses existing blob gas accounting unmodified.—
New block / header fields0None—
Encoding changes (RLP/SSZ)0All encodings remain RLP — no format migration.—
Engine API changes0No new or modified Engine API endpoints, fields, or communication mechanisms.—
Engine API encoding changes0None—
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
Compare EIP-8141 with other assessmentsAll 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.

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

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