Retrospective LLM-Based Complexity Evaluations

EIP complexity assessment

EIP-3860: Limit and meter initcode

Assessed in Shanghai / Shapella. The score describes the EIP text available at the assessment cutoff, not the EIP as it stands today.

RetrospectiveShanghai / ShapellaAssessment cutoff 2022-02-04Included by cutoffLayers: execution
LLM Completescore 21
Human Not available· Human complexity assessments were not produced for this fork; only the LLM assessment exists.

LLM assessment

Evaluated on: · Spec revision: 2022-02-03 · d38a4add0c

Scope at the cutoff. At this revision, EIP-3860 sets MAX_INITCODE_SIZE = 2 * MAX_CODE_SIZE = 49152 bytes. It also adds initcode_cost = 2 * ceil(len(initcode)/32) gas. A create transaction whose initcode is larger than the limit is invalid, and initcode_cost is added to the create transaction's intrinsic gas. For CREATE and CREATE2, initcode larger than the limit pushes 0 on the stack, and initcode_cost is charged before address calculation and initcode execution. For CREATE2 this charge comes on top of the EIP-1014 hashcost.

21MediumMedium
Evaluator
LLMChecklist v3
Confidence
Medium
Under-specified at assessment cutoff
Yes — 3 criteria affected
Plausible range
18–22 (Medium)
Assessment cutoff
2022-02-04 · EIP revision d38a4add0c (2022-02-03)
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. Modified opcodes3
  2. EVM Gas rule changes3
  3. State-access ordering within opcode execution2
  4. New or modified transaction validity mechanisms2

Under-specified at assessment cutoff: Yes

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

Why: The rules conflict on whether an oversized create transaction is invalid (rule 1) or includable with an exceptional abort (Backwards Compatibility). The failure path for oversized CREATE/CREATE2 initcode does not say how gas is charged, what happens to the nonce, or how the check is ordered.

Plausible total

18–22
recorded score 21 · plausible tiers Medium

Unresolved questions at the cutoff (5)
  • Is an oversized create transaction invalid, or includable but aborting?
  • For oversized CREATE/CREATE2 initcode, are initcode_cost and memory expansion charged before the check pushes 0?
  • Is the sender nonce incremented, or the target address warmed, when the size check fails?
  • How is the size check ordered against the balance, call-depth and gas checks?
  • Is the gas passed to the child frame consumed when the size check fails?
Notable ambiguities noted by the assessor (3)
  • Backwards Compatibility contradicts Rule 1 on how oversized create transactions are handled.
  • The Rationale contains a TODO: the maximum initcode size seen on mainnet is not stated.
  • It is unclear whether 'push 0' for oversized initcode also consumes gas or clears return data.

Criterion breakdown

EIP-3860 Shanghai / Shapella: LLM criterion scores and rationale
CriterionScoreWhy this scoreEvidence / uncertainty
Modified opcodes3A new size-limit failure in CREATE and CREATE2 changes their semantics beyond gas.
  • eip.md · Specification / Rules, rule 3, "instruction results in `0` value pushed on stack" CREATE and CREATE2 gain a new failure outcome for oversized initcode.
  • eip.md · Rationale / How to report initcode limit violation? The spec chooses to push 0 rather than abort exceptionally.
Confidence: High
EVM Gas rule changes3The EIP adds a new per-word initcode charge at two sites: intrinsic gas and the CREATE/CREATE2 opcodes. This changes the expected gas of baseline operations: every create transaction and every CREATE/CREATE2 with non-empty initcode. A new mechanism that also changes baseline gas results meets level 3.
  • eip.md · Specification / Rules, rule 2 The create transaction data cost formula is extended with initcode_cost(initcode) as part of intrinsic gas.
  • eip.md · Specification / Rules, rule 4 CREATE and CREATE2 are charged an extra initcode_cost(initcode).
  • eip.md · Rationale / Gas cost per word, "after activation `2` for `CREATE` and `6 + 2` for `CREATE2`" The per-word charge for create operations changes from 0/6 to 2/8.
Confidence: Medium
Uncertainty: Because the charge reuses the existing per-word scheme used by CREATE2's hashcost, it could be read as only a parameter change (level 1).
State-access ordering within opcode executionUnder-specified2Both CREATE and CREATE2 need an ordering rule for the new size check and the new charge relative to the state they touch (sender nonce, created-address warming, endowment). Ordering changes for multiple opcodes meet level 2.
  • eip.md · Specification / Rules, rule 4, "deducted before the calculation of the resulting contract address and the execution of `initcode`" The spec places the new charge relative to address derivation, which reads state such as the sender nonce.
  • eip.md · Specification / Rules, rule 3 A new early-failure check is added to CREATE and CREATE2. Its position relative to the nonce increment, balance/depth checks and access-list warming is not stated.
Confidence: Low
Uncertainty: The charge may just join the existing upfront charges without changing any state-access ordering, which would make this 0. Where the limit check sits is unspecified.
New or modified transaction validity mechanismsUnder-specified2There is a new size-based validity rule and a changed intrinsic gas rule for create transactions. Both need dedicated cases across existing transaction types, but the existing validation sequence stays usable.
  • eip.md · Specification / Rules, rule 1 A create transaction with initcode over MAX_INITCODE_SIZE is invalid.
  • eip.md · Specification / Rules, rule 2, "transaction with not enough gas to cover initcode cost is invalid" The intrinsic-gas validity rule changes.
Confidence: Medium
Uncertainty: The Backwards Compatibility text says oversized transactions are still includable but abort, which contradicts rule 1. The outcome depends on which text is followed.
Patterns affecting pre-existing tests2Baseline tests for create-transaction intrinsic gas, CREATE gas and CREATE2 gas need new expected gas and balances, and large-initcode cases need new outcomes. This rework covers ordinary cases throughout the contract-creation families.
  • eip.md · Specification / Rules, rules 2 and 4 Gas used by every create transaction and every CREATE/CREATE2 changes.
  • eip.md · Backwards Compatibility Transactions with initcode beyond the limit now behave differently.
Confidence: Medium
Uncertainty: Any test that deploys via a create transaction sees changed gas and balances, so the impact could be broad enough for level 3.
Edge/boundary conditionsUnder-specified2There are several boundary-sensitive mechanisms: the transaction size limit, the opcode size limit, the per-word ceiling and the intrinsic-gas sufficiency threshold. None is shown to have an elevated matrix, so this is level 2.
  • eip.md · Test Cases The listed cases include MAX_INITCODE_SIZE and MAX_INITCODE_SIZE+1 for the transaction, CREATE and CREATE2, plus intrinsic gas with and without the initcode cost covered.
  • eip.md · Specification / Parameters, "ceil(len(initcode) / 32)" The word-rounding boundary determines the cost.
Confidence: Medium
Uncertainty: The spec does not settle how oversized initcode combines with gas sufficiency in CREATE/CREATE2. Does the size check or the OOG/initcode charge come first? If that ordering changes outcomes, the matrix could be elevated.
Cross-EIP interactions2CREATE2 tests need coordinated cases where the EIP-1014 hashcost and the new initcode cost are combined at gas and size boundaries. The EIP-170 interaction needs only compatibility checks.
  • eip.md · Abstract, "We extend EIP-170" The initcode limit is defined as 2 * MAX_CODE_SIZE.
  • eip.md · Rationale / Gas cost per word CREATE2 charges 6 + 2 per word, combining with the EIP-1014 hashcost.
  • supporting/eip-1014.md · Specification, "hashcost ... deducted ... before evaluation of the resulting address" Defines the timing of the hashcost, which the new charge must be coordinated with.
Confidence: Medium
Uncertainty: EIP-3670 is only referenced as future work and is not in the baseline.
Interacting EIPs: EIP-1014, EIP-170
Unspecified behavior requiring cross-client consensus2Rules conflict on whether oversized create transactions are invalid or includable-but-aborting. The CREATE/CREATE2 failure path also leaves localized outcomes (gas, nonce, ordering) open. Clients must agree before expected results can be fixed.
  • eip.md · Backwards Compatibility, "would still be includable in a block, but result in an exceptional abort" This contradicts rule 1, which says such transactions are invalid.
  • eip.md · Specification / Rules, rule 3 For oversized initcode, the spec does not say whether initcode_cost or memory expansion gas is charged, whether the sender nonce is incremented, or how the check is ordered against other create failure checks.
Confidence: Medium
Uncertainty: Rule 1 is normative and probably prevails over the Backwards Compatibility text.
New test-framework primitives1The intrinsic-gas calculation needs a local extension. No new abstraction is required.
  • eip.md · Specification / Rules, rule 2 The intrinsic gas formula used by the framework must include initcode_cost for create transactions.
  • eip.md · Test Cases Tests need initcode of exact lengths and exact gas limits.
Confidence: Medium
Security risks1The new limit and charge can be checked locally in the create paths.
  • eip.md · Security Considerations The change reduces DoS risk from jumpdest analysis and adds new failure modes for factory contracts.
Confidence: Medium
Performance risks1Validating the per-word cost against the bounded worst case needs component benchmarks of jumpdest analysis. Baseline end-to-end assumptions are unchanged.
  • eip.md · Rationale / Gas cost constant The cost was derived from jumpdest-analysis benchmarks compared against KECCAK256.
  • eip.md · Security Considerations, "~1.3GB of initcode" The worst-case jumpdest-analysis workload is now bounded and priced.
Confidence: Medium
Show 17 zero-score criteria
Zero-score criteria (Checklist revision 3)
CriterionScoreWhy this scoreEvidence / uncertainty
Added opcodes0No new instruction is added.
  • eip.md · Specification / Rules Only the existing CREATE and CREATE2 are affected.
Added precompiles0None.
  • eip.md · Specification No precompile is added.
Modified precompiles0None.
  • eip.md · Specification No precompile changes.
Added system contracts0None.
  • eip.md · Specification No system contract is added.
Modified system contracts0None.
  • eip.md · Specification No system contract is involved.
Blob gas accounting changes0Blob-gas accounting does not change.
  • eip.md · Specification The spec does not mention blobs or blob gas.
State gas accounting changes0The new charge covers jumpdest analysis, not state writes. State-gas accounting does not change.
  • eip.md · Motivation, "Cost for the resulting deployed code: 200 gas per byte" The cost of deployed code is cited as existing and is left unchanged.
New EVM gas refund0There is no refund mechanism.
  • eip.md · Specification No refund is introduced.
New transaction types0No new transaction envelope is introduced.
  • eip.md · Specification / Rules, rule 1 The rule applies to existing create transactions.
New block / header fields0None.
  • eip.md · Specification No header field is added.
Encoding changes (RLP/SSZ)0There are no codec changes.
  • eip.md · Specification No serialized schema changes.
Block syncing changes0Block decoding and structural validation are unchanged.
  • eip.md · Specification / Rules, rule 1 This is a transaction-validity rule, not a change to block RLP or structure.
New fork activation mechanism0Selecting new rules at activation is not an activation-specific transition.
  • eip.md · Backwards Compatibility, "requires a 'network upgrade'" Only the rules switch at the fork. There is no state migration.
Engine API changes0There are no Engine API changes.
  • eip.md · Specification The Engine API is not mentioned.
Transition-tool interface changes0Fork-aware rule selection needs no interface change.
  • eip.md · Specification / Parameters Only constants and rules change. No new inputs or outputs are needed.
New invariant on pre-existing tests0The changes are to gas and limits, which count as rework, not new assertions.
  • eip.md · Specification No new receipt, log, header or state output is introduced.
Cryptography0No cryptographic rule changes.
  • supporting/eip-1014.md · Specification CREATE2 address hashing is unchanged. Only gas is added around it.
Assessment provenance
Assessed EIP revision
ethereum/EIPs@d38a4add0c EIPS/eip-3860.md committed 2022-02-03 · information cutoff 2022-02-04
Current master · File history · blob 7acc1955a8 · sha256 4dd3935265d7
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/retrospective/outputs/assessments/shanghai/eip-3860.yaml · sha256 20bc2d9f06ce
Supporting documents supplied with the EIP
supporting/eip-170.md, supporting/eip-1014.md
Compare EIP-3860 with other assessmentsAll Shanghai / Shapella 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.