Retrospective LLM-Based Complexity Evaluations

EIP complexity assessment

EIP-8142: Block-in-Blobs (BiB)

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: PFILayers: execution, consensus
LLM Completescore 41
Human Pending· This EIP joined the Hegotá candidate lists after the human-checklist snapshot was captured.

LLM assessment

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

Scope at the cutoff. EIP-8142 requires the execution-payload data (the RLP-encoded block access list from EIP-7928 and the RLP-encoded transaction list) to be written into blobs. It uses a fixed codec: an 8-byte length header, 31 usable bytes per field element and zero padding. The KZG commitments for these payload-blobs must form the first `payload_blob_count` blob commitments of the block, ahead of the type-3 transaction blobs. A new `payload_blob_count` header/ExecutionPayload field is added. engine_getPayload must compute payload blobs, commitments and cell proofs, plus random-point proofs in the zk variant. engine_newPayload must re-derive the payload blobs, check the count and check that the expected versioned hashes are the payload hashes followed by the type-3 hashes. Payload blobs consume blob gas and count toward MAX_BLOBS_PER_BLOCK without paying a per-blob fee.

41HighHigh
Evaluator
LLMChecklist v3
Confidence
Medium
Under-specified at assessment cutoff
Yes — 5 criteria affected
Plausible range
35–42 (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

  1. Blob gas accounting changes3
  2. New block / header fields3
  3. Encoding changes (RLP/SSZ)3
  4. Block syncing 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 blob-gas accounting of payload blobs is described only in prose. The header RLP layout and the scope of block-import validation are unspecified, and the ExecutionPayload listing conflicts with EIP-7928's blockAccessList field.

Plausible total

35–42
recorded score 41 · plausible tiers High

Unresolved questions at the cutoff (6)
  • Is header blob_gas_used computed as payload_blob_count*GAS_PER_BLOB plus type-3 blob gas, and does excess_blob_gas use it?
  • Is the combined payload plus type-3 blob limit a consensus validity rule in EL block validation, or only a builder obligation?
  • Where is payload_blob_count placed in the header RLP, and how is it handled for the first post-fork block?
  • Is payload_blob_count validated on devp2p block import, given that BALs are stored separately?
  • Does ExecutionPayload include blockAccessList, given that the listed container omits it?
  • Is any fee charged or burned for payload blob gas?
Notable ambiguities noted by the assessor (4)
  • Every block has at least one payload blob, even an empty one (10 bytes), so blob gas is never zero if payload blobs are counted.
  • The two newPayload variants (native and zk) are claimed equivalent, but zk-variant inputs are private, so EL testing scope for the zk variant is unclear.
  • The ExecutionPayload listing omits blockAccessList and EIP-7732 envelope details.
  • RLP.decode in the decoder has no explicit canonicality rule; validation re-encodes from the payload instead.

Criterion breakdown

EIP-8142 Hegotá: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
Blob gas accounting changesUnder-specified3This adds a new mechanism: protocol-mandated, unpaid blob-gas consumption by payload blobs. It also changes existing accounting. blob_gas_used, excess_blob_gas and the blob base fee now include payload blobs, which matters because every block has at least one payload blob (even an empty BAL plus an empty tx list encodes to 10 bytes). Baseline blob gas expectations therefore change.
  • eip.md · Fee Accounting / Do payload-blobs compete with transaction blobs for capacity? "Because payload blobs consume blob gas, they directly influence blob congestion and the blob base fee."
  • eip.md · Fee Accounting / Who pays? Payload-blobs do not pay a per-blob fee; their blob gas usage is a protocol-accepted cost.
  • supporting/eip-4844.md · Execution layer validation In the baseline, blob_gas_used is the sum of get_total_blob_gas over type-3 transactions only, and that sum feeds calc_excess_blob_gas.
  • eip.md · Security Considerations / Interaction with blob congestion Payload-blobs are subject to the same congestion control and blob limits as transaction blobs.
Confidence: Medium
Uncertainty: The EIP gives no formula for including payload blobs in blob_gas_used or in the limit check; it states the effect only in prose. If blob_gas_used were unchanged and only the capacity limit applied, the level would be lower.
New block / header fields3An execution header member is added.
  • eip.md · Data structures / Header "This EIP adds a new field to the header: payload_blob_count : uint64"
Confidence: High
Encoding changes (RLP/SSZ)3The header schema, the ExecutionPayload/Engine schema and a new payload-to-blob codec all change.
  • eip.md · Data structures / Header payload_blob_count is added to the execution header.
  • eip.md · Consensus Layer / ExecutionPayload payload_blob_count is added to the SSZ ExecutionPayload.
  • eip.md · execution_payload_data_to_blobs New canonical blob codec: 8-byte big-endian lengths, BAL bytes, RLP tx list, 31-byte field-element packing.
Confidence: High
Block syncing changesUnder-specified3Header decoding gains a field (a simple rule). payload_blob_count must also match a value derived from the block body and BAL (a complex rule), and blob gas checks change.
  • eip.md · Data structures / Header A new execution header field changes header RLP decoding.
  • eip.md · engine_newPayload - Native Execution Variant payload_blob_count must equal the number of blobs derived from the transactions and BAL.
Confidence: Low
Uncertainty: The count check is specified only at the Engine API boundary. Whether it applies on devp2p import, where the BAL is stored separately, is unspecified, and the header RLP position is not given.
Engine API changes3Both endpoint behavior and multiple fields change. getPayload and newPayload validation change, and ExecutionPayload.payloadBlobCount, payload_kzg_proofs and payload_kzg_commitments are added.
  • eip.md · engine_getPayload - Native Variant BlobsBundle now returns payload blobs, commitments and cell proofs ahead of type-3 blobs.
  • eip.md · BlobsBundle New payload_kzg_proofs field in the zk variant.
  • eip.md · engine_newPayload - zkEVM-Optimized Variant New payload_kzg_commitments and payload_kzg_proofs inputs, plus changed versioned-hash validation.
Confidence: High
Patterns affecting pre-existing testsUnder-specified3One common change, mandatory payload blobs in every block, forces rework across distinct families. Every engine-format blockchain test needs different expected_blob_versioned_hashes inputs. EIP-4844 max-blobs-per-block validity tests and excess-blob-gas/blob-base-fee/BLOBBASEFEE expectations must be re-derived, because blob gas used is never zero after the fork.
  • eip.md · engine_newPayload - Native Execution Variant "assert expected_blob_versioned_hashes == payload_versioned_hashes + type3_versioned_hashes": every newPayload call now needs payload-blob versioned hashes first.
  • eip.md · engine_getPayload - Native Variant / Note Payload blob usage counts toward MAX_BLOBS_PER_BLOCK, which shrinks the capacity left for type-3 blobs.
  • eip.md · Fee Accounting Payload blobs consume blob gas and influence the blob base fee.
Confidence: Medium
Uncertainty: How far the blob-accounting families change depends on the unspecified blob_gas_used formula.
New test-framework primitives3The framework needs a shared facility to derive payload blobs from each block's BAL and transactions, compute KZG commitments and versioned hashes, prepend them to expected blob hashes, and account for payload blobs in blob limits. This changes how every engine-format fixture across families is constructed and checked. It also needs modifiers to forge mismatched counts or ordering.
  • eip.md · execution_payload_data_to_blobs Payload bytes must be canonically encoded into blobs (8-byte header, 31-byte packing).
  • eip.md · engine_newPayload - Native Execution Variant Expected versioned hashes must be payload KZG versioned hashes followed by type-3 hashes.
Confidence: Medium
Edge/boundary conditions3There are multiple boundary-sensitive mechanisms: blob-packing thresholds, length-header bounds and the combined blob limit. The limit forms an elevated matrix in which payload size (BAL plus tx bytes), type-3 blob count and the active blob-schedule max together determine validity. Adding transactions also changes payload size.
  • eip.md · bytes_to_blobs / chunk_to_blob Blob count steps at multiples of USABLE_BYTES_PER_BLOB, and the final blob is zero-padded.
  • eip.md · blobs_to_execution_payload_data 4-byte length headers, the declared-length bound and the trailing-zero checks are boundary rules.
  • eip.md · Parameters / Note on MAX_BLOBS_PER_BLOCK MAX_BLOBS_PER_BLOCK covers payload blobs plus type-3 blobs and varies by fork per EIP-7892.
Confidence: Medium
Cross-EIP interactions3The target couples EIP-4844 blob accounting and ordering, EIP-7928 BAL size, EIP-7892 schedule limits and EIP-7594 cell proofs. Coordinated scenarios are needed across these interactions.
  • eip.md · Parameters / Note on MAX_BLOBS_PER_BLOCK The payload plus type-3 blob limit follows the EIP-7892 schedule.
  • eip.md · execution_payload_data_to_blobs EIP-7928 BAL bytes are part of the encoded payload data.
  • eip.md · engine_getPayload - Native Variant Payload blobs are combined with EIP-4844 type-3 blobs and EIP-7594 cell proofs.
Confidence: Medium
Uncertainty: EIP-7732 compatibility (ExecutionPayload in the envelope, commitments in the bid) is only partially described.
Interacting EIPs: EIP-4844, EIP-7928, EIP-7892, EIP-7594, EIP-7732
New or modified transaction validity mechanismsUnder-specified2Whether type-3 transactions are eligible now depends on the remaining blob capacity after payload blobs, and that capacity depends on the size of all transactions and the BAL. Dedicated cases are needed, but baseline validation sequencing remains usable.
  • eip.md · engine_getPayload - Native Variant / Note Builders must account for payload blob usage so total blobs do not exceed MAX_BLOBS_PER_BLOCK.
  • supporting/eip-4844.md · Execution layer validation Type-3 inclusion is bounded by the block blob gas limit and the blob base fee.
Confidence: Low
Uncertainty: The EIP gives no explicit consensus validity rule combining payload and type-3 blobs; it gives only a builder note and prose.
Transition-tool interface changesUnder-specified2The tool must output payload_blob_count and include payload blobs in blob-gas results, and it likely needs the parent payload blob count for the excess calculation. That is multiple field changes without a clearly required new exchange mechanism.
  • eip.md · Execution Layer / Summary The header gains payload_blob_count, which is computed from the transactions and BAL.
  • eip.md · Fee Accounting Payload blobs consume blob gas, which changes what blob gas used / excess blob gas mean.
Confidence: Low
Uncertainty: No t8n evidence is supplied. If KZG commitment and versioned-hash computation for payload blobs had to live in the tool, this would reach 3.
New invariant on pre-existing tests2Every post-fork block in every test must carry and check the correct payload_blob_count. The assertion is universal within the target fork, but nothing shows that pre-fork vectors must be re-derived, so the level is 2.
  • eip.md · Data structures / Header New header field `payload_blob_count`: uint64.
  • eip.md · engine_newPayload - Native Execution Variant "assert payload_blob_count == payload.payload_blob_count"
Confidence: Medium
Security risks2The EL newPayload check now carries the data-availability binding the CL relies on. Targeted adversarial integration cases are needed: wrong count, reordered or misplaced commitments, mismatched blobs, and native/zk variant divergence.
  • eip.md · Overview and Invariants / Payload availability invariant The KZG commitments of the derived blobs must match the first payload_blob_count block commitments.
  • eip.md · Consensus Layer / Validation The CL relies on payload_blob_count to interpret commitment ordering.
  • eip.md · Engine API The two newPayload variants must enforce identical validity conditions.
Confidence: Medium
Uncertainty: This could be judged 3 if the CL/zk-prover trust assumptions are counted as a shared invariant across multiple components.
Performance risks2Payload validation and block building gain KZG work that scales with payload size, which is bounded by the gas limit and the blob max. Targeted integrated benchmarks are needed on the newPayload/getPayload critical paths.
  • eip.md · engine_newPayload - Native Execution Variant newPayload computes blob_to_kzg_commitment (an MSM) for every payload blob before execution.
  • eip.md · engine_getPayload - Native Variant getPayload computes cell proofs for every payload blob on the build path.
  • supporting/eip-7594.md · Networking "computing the cell proofs for a blob is an expensive operation"
Confidence: Medium
Uncertainty: The builder bandwidth concerns are CL/networking and are not scored here.
Cryptography2Several established KZG mechanisms enter EL validation and building. Payload validity now depends on commitment computation, the zk variant uses batch proof verification, and getPayload computes cell and blob proofs. Specs exist for all of them, so this is multiple established mechanisms.
  • eip.md · Referenced Helpers Uses blob_to_kzg_commitment, verify_blob_kzg_proof_batch, compute_blob_kzg_proof, compute_cells_and_kzg_proofs and kzg_commitment_to_versioned_hash from the consensus specs.
  • eip.md · engine_newPayload - zkEVM-Optimized Variant Blob–commitment consistency is checked with verify_blob_kzg_proof_batch.
  • supporting/eip-4844.md · Cryptographic Helpers / Test Cases KZG helpers are defined in the consensus specs, and consensus-layer test cases are referenced.
Confidence: Medium
Uncertainty: Applicability of existing KZG test vectors to EL payload validation is not directly evidenced.
Unspecified behavior requiring cross-client consensus2Several consensus-visible outcomes admit competing interpretations. Header blob_gas_used could include or exclude payload blobs, the header field order is unspecified, and whether the count check applies outside the Engine API is unstated. These must be agreed before expected results can be fixed.
  • eip.md · Fee Accounting Payload blobs "consume blob gas", but no formula updates blob_gas_used, excess_blob_gas or the limit check, and explicit pricing is an open TODO.
  • eip.md · Data structures / Header The header field is added without an RLP position.
  • eip.md · Consensus Layer / ExecutionPayload The listed ExecutionPayload omits blockAccessList, although EIP-7928 adds it and get_execution_payload_data reads it.
Confidence: Medium
Uncertainty: If the blob-accounting ambiguity is read as re-baselining across families, the level could be 3.
Show 12 zero-score criteria
Zero-score criteria (Checklist revision 3)
CriterionScoreWhy this scoreEvidence / uncertainty
Added opcodes0None.
  • eip.md · Specification No new instructions.
Modified opcodes0No instruction semantics change. Blob base fee values may shift through accounting, but that is not a semantic change.
  • supporting/eip-4844.md · Opcode to get versioned hashes BLOBHASH indexes tx.blob_versioned_hashes, which this EIP leaves unchanged.
Added precompiles0None.
  • eip.md · Specification No precompile is added.
Modified precompiles0None.
  • eip.md · Specification The point evaluation precompile is untouched.
Added system contracts0None.
  • eip.md · Specification No system contract is introduced.
Modified system contracts0None.
  • eip.md · Specification No system contract behavior is referenced or changed.
EVM Gas rule changes0No execution-gas charging, metering or settlement rule changes. Only blob-related accounting is touched.
  • eip.md · Fee Accounting / Can a builder artificially inflate blob gas usage? Calldata stays priced by the normal execution gas mechanism; no execution-gas rule changes are stated.
State-access ordering within opcode execution0No instruction's state-access or gas-charge ordering changes, and BAL recording rules are untouched.
  • eip.md · Execution Layer / Summary Changes are confined to the header field and the Engine API blob derivation and checks; no opcode access ordering is changed.
State gas accounting changes0No state-gas accounting changes.
  • eip.md · Specification No state-write cost, state-gas budget or spill rule is introduced.
New EVM gas refund0No new refund mechanism.
  • eip.md · Fee Accounting No refund mechanism is introduced; fee discussion covers blob gas only.
New transaction types0No new transaction envelope.
  • eip.md · Terminology Only the existing type-3 transactions are referenced.
New fork activation mechanism0There is no one-time state transition or code installation.
  • eip.md · Backwards Compatibility Requires a fork for header and STF changes; no state migration is described.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@6dac5e7491 EIPS/eip-8142.md committed 2026-10-07 · information cutoff 2026-10-07T22:23:55Z
Current master · File history · blob 79289ef1bb · sha256 8153607a02e4
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-8142.yaml · sha256 6cbbbee0a85f
Supporting documents supplied with the EIP
supporting/eip-4844.md, supporting/eip-7594.md, supporting/eip-7732.md, supporting/eip-7892.md, supporting/eip-7928.md
Compare EIP-8142 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 · 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.
  • 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.
  • 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 · 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.

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