EIP complexity assessment

EIP-7997: Deterministic Factory Contract

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

RetrospectiveAmsterdam / GlamsterdamAssessment cutoff 2025-08-21Included by cutoffLayers: execution

LLM Completescore 14

Human Completescore 5 · Checklist revision 1· merged checklist

LLM · Checklist revision 22026-08-25 · Primary study score · 14 LLM · Checklist revision 12026-08-25 · Re-run for the human comparison · 13 Human · Checklist revision 1Complete · 5 CompareHuman vs LLM · same checklist revision

Evaluated on: 2026-08-25 · Spec revision: 2025-08-19 · f8be9ce27b

Scope at the cutoff. At the information cutoff, EIP-7997 proposed an activation-time insertion of fixed runtime bytecode at address 0x0B, creating a minimal factory available at the same address on adopting EVM chains. The factory interprets calldata as a 32-byte salt followed by variable-length initcode, forwards all call value to CREATE2, returns the created address on success, and propagates failure returndata by reverting. It adds no transaction type, opcode, or custom gas schedule; its protocol changes are the predeployed system account and the one-time state change that installs it.

14MediumMedium

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: No
Plausible range: 14–14 (Medium)
Assessment cutoff: 2025-08-21 · EIP revision f8be9ce27b (2025-08-19)

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.

Under-specified at assessment cutoff: No

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

The assessor found no material behavior left unresolved by the EIP text at the cutoff.

Notable ambiguities noted by the assessor (2)

The manifest and output template title the item Deterministic Factory Contract, while the sealed historical EIP front matter says Deterministic Factory Predeploy; the EIP number, revision identity, and hashes match.
The proposal requires an activation-only state insertion but does not prescribe a transition-tool API; the interface-change score therefore reflects the required activation-aware mechanism rather than a named field.

Criterion breakdown

EIP-7997 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
New fork activation mechanism	3	The fork activation block directly modifies state by installing account code. The rubric assigns score 3 whenever activation modifies state or internal variables.	eip.md · Specification > Factory Contract, lines 41-45 Upon activation, clients must set the code of address 0x0B to a specified byte sequence. eip.md · Rationale > Precompile-range system contract, lines 108-110 The EIP states that normal deployment cannot provide the desired guarantee and therefore requires irregular code insertion at a special address. Confidence: High
Added system contracts	2	The proposal adds one system contract whose operation can create contracts and transfer the forwarded value, making it stateful in effect. The single stateful-system-contract anchor is score 2.	eip.md · Abstract, lines 14-16 A new minimal CREATE2 factory is inserted as a system contract at a fixed address. eip.md · Specification > Factory Contract, lines 45-98 The contract accepts value and variable initcode, invokes CREATE2, and thereby can create a new state account before returning its address. Confidence: High
Transition-tool interface changes	2	A transition tool must have a new activation-aware mechanism that distinguishes the one block where code is inserted from later blocks. This is more than one ordinary data field but does not imply multiple new fields plus another mechanism, fitting score 2.	eip.md · Specification > Factory Contract, lines 43-45 Code is inserted upon activation, making the insertion specific to the activation transition rather than an ordinary rule run on every post-fork block. eip.md · Rationale > Precompile-range system contract, lines 108-110 The EIP characterizes installing the account as an irregular insertion at a special address. Confidence: Medium Uncertainty: The EIP does not prescribe a transition-tool API; an environment with sufficient existing fork-activation context might implement the behavior without a new external field.
Edge/boundary conditions	2	Several edge-prone mechanisms must be covered: 31 versus 32-byte input, empty and variable initcode, creation success versus collision or initcode failure, return-data lengths, and value forwarding. They are multiple but remain bounded combinations around a small fixed contract, fitting score 2 rather than the elevated-case score 3.	eip.md · Specification > Factory Contract, lines 50-103 The code has a 32-byte input-length boundary, variable-length initcode copying, CREATE2 success and zero-result branches, failure-returndata propagation, and full call-value forwarding. supporting/eip-1014.md · Clarifications, lines 41-57 Existing CREATE2 behavior includes collision failure and same-transaction recreation boundaries that factory tests inherit. Confidence: High
Cross-EIP interactions	2	Correct testing must coordinate the new factory with two directly required EIPs, especially CREATE2 success or collision failure and EIP-211 failure-returndata propagation. The dependencies are important but limited to this small call path, matching score 2 rather than extensive multi-EIP interdependence.	eip.md · Front matter, lines 1-12 The proposal declares direct requirements on EIPs 211 and 1014. eip.md · Specification > Factory Contract, lines 73-90 Its core success and failure flow invokes CREATE2 and uses the return-data buffer opcodes to propagate failure data. supporting/eip-211.md · Specification, lines 27-42 EIP-211 defines the return-data buffer and its specific CREATE2 success and failure behavior used by the factory. supporting/eip-1014.md · Specification, lines 11-21 EIP-1014 defines the CREATE2 address, dynamic hash cost, and gas-charge timing inherited by factory calls. Confidence: High Uncertainty: References to EIPs 155, 5792, and 7702 describe motivation or rejected workarounds, not protocol dependencies or behavior modified by EIP-7997, so they are not counted as interacting EIPs. Interacting EIPs: EIP-211, EIP-1014
Patterns affecting pre-existing tests	1	Existing tests that assume 0x0B is empty, call it as an empty account, or cross the activation transition need localized updates. This is a minor, narrow subset rather than a considerable or diverse body of pre-existing tests, matching score 1.	eip.md · Specification > Parameters and Factory Contract, lines 39-45 At activation, formerly ordinary address 0x0B receives fixed executable code. eip.md · Rationale > Precompile-range system contract, lines 108-112 The address is selected immediately after existing precompiles and the insertion is explicitly irregular. Confidence: Medium Uncertainty: The sealed package does not enumerate the pre-existing test corpus, so the exact affected count cannot be established; the narrow address-specific impact is clear from the specification.
New invariant on pre-existing tests	1	Tests not principally about the factory but which span this fork activation must additionally observe the code insertion in resulting state. That is a narrow activation-focused category, not a mechanically added assertion for every test in the fork, so score 1 applies.	eip.md · Specification > Factory Contract, lines 43-45 The activation transition must leave the specified code at FACTORY_ADDRESS. Confidence: Medium Uncertainty: The package specifies no test vectors, so whether a particular framework expresses this as an explicit assertion or through a state root is not established.
Security risks	1	The security exposure is explicit but localized to the small factory's deployment semantics and can be reviewed and tested in isolation. It does not substantially alter multiple critical component assumptions, fitting score 1.	eip.md · Rationale > No frontrunning protection, lines 118-124 The minimal factory deliberately omits caller-bound salt protection and leaves more feature-rich protected factories to applications. eip.md · Security Considerations > Frontrunnable deployments, lines 139-143 Environment-dependent initcode can be frontrun and deployed with attacker-selected parameters, so use is recommended only for fully deterministic contracts. Confidence: High

Show 20 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	The EIP deploys code that uses existing opcodes and allocates no opcode number, so score 0 applies.	eip.md · Specification > Factory Contract, lines 45-104 The factory is bytecode assembled entirely from existing EVM instructions, including CREATE2, RETURNDATASIZE, and RETURNDATACOPY. supporting/eip-211.md · Specification, lines 27-42 RETURNDATASIZE and RETURNDATACOPY are pre-existing opcodes with specified behavior and gas costs. supporting/eip-1014.md · Specification, lines 11-21 CREATE2 is likewise an already-defined opcode.
Modified opcodes	Calling CREATE2 and return-data opcodes from a newly installed contract does not modify their behavior, so the binary score-0 anchor applies.	eip.md · Specification > Factory Contract, lines 45-104 The exact factory program invokes existing instructions but supplies no amended opcode semantics.
Added precompiles	Placement in the precompile address range does not make fixed EVM bytecode a precompile. No native precompile is introduced, so score 0 applies.	eip.md · Abstract and Specification > Factory Contract, lines 14-16 and 43-45 The proposal explicitly calls the factory a system contract and installs ordinary bytecode, although its address lies in the precompile range. eip.md · Rationale > Precompile-range system contract, lines 108-112 The range is used to obtain a special reserved address; no native precompile function or gas schedule is defined.
Modified precompiles	The proposal neither changes an existing precompile's logic nor its gas schedule, so score 0 applies.	eip.md · Rationale > Precompile-range system contract, lines 108-112 Address 0x0B is selected as the next address after existing precompiles, leaving the existing precompile addresses and behavior untouched.
Modified system contracts	Addition of a distinct system contract is scored in the preceding criterion and causes no direct or identified indirect modification to an existing system contract, so score 0 applies.	eip.md · Abstract and Rationale > Precompile-range system contract, lines 14-16 and 108-112 The EIP adds a factory at the next address after existing precompiles; it does not alter the code, state, or behavior of a pre-existing system contract.
EVM Gas rule changes	The factory pays the existing gas schedules of the ordinary opcodes it executes, so the score-0 anchor for no gas-accounting change applies.	eip.md · Specification > Factory Contract, lines 45-104 The proposal installs fixed EVM bytecode composed of existing instructions, including CALLDATACOPY and CREATE2, without specifying any new gas prices or charging rules.
State-access ordering within opcode execution	Executing existing CREATE2 from a new contract does not modify where state is accessed inside CREATE2 or any other opcode, matching score 0.	eip.md · Specification > Factory Contract, lines 45-104 All factory behavior is expressed as contract bytecode; the proposal does not change any opcode's internal state-access or gas-charge sequence.
Blob gas accounting changes	No blob gas accounting is introduced or modified, so the score-0 anchor applies.	eip.md · Abstract and Specification, lines 14-16 and 37-104 The proposal is limited to installing and invoking a CREATE2 factory and contains no blob-related mechanism.
State gas accounting changes	The state insertion is a protocol state change, not a change to state-gas accounting as defined by this anchor; score 0 applies.	eip.md · Specification > Factory Contract, lines 41-45 Activation sets fixed code at the factory address but defines no state-gas rate, budget, reservoir, spill rule, or new state-gas charging site.
New EVM gas refund	No new EVM gas-refund mechanism is introduced, matching score 0.	eip.md · Specification > Factory Contract, lines 45-104 The bytecode copies calldata, invokes CREATE2, and returns or reverts; it defines no refund-counter behavior.
New transaction types	The proposal explicitly introduces no transaction type, so the binary score-0 anchor applies.	eip.md · Rationale > Not a new transaction type, lines 126-128 A new creation transaction type was considered and rejected in favor of the system-contract approach.
New or modified transaction validity mechanisms	No existing transaction validity rule or intrinsic gas calculation is changed, so score 0 applies.	eip.md · Rationale > Not a new transaction type, lines 126-128 The design deliberately uses calls to a system contract instead of adding a transaction form. eip.md · Specification > Factory Contract, lines 45-104 Input rejection and CREATE2 failure are EVM call execution outcomes, not transaction validity or intrinsic-gas rules.
New block / header fields	No block or header field is introduced, so the binary score-0 anchor applies.	eip.md · Specification, lines 37-104 The complete specification consists of a fixed address and contract code; it defines no block or block-header field.
Encoding changes (RLP/SSZ)	An application-level calldata layout for one contract is outside the RLP/SSZ transaction, block, and interface encoding anchor; no such encoding changes are introduced, so score 0 applies.	eip.md · Specification > Factory Contract, lines 45-104 The factory has a raw calldata convention of salt followed by initcode and does not change transaction, block, or interface encoding.
Block syncing changes	No block RLP validation mechanism is introduced, so score 0 applies.	eip.md · Specification, lines 37-104 The proposal defines a state insertion and contract execution behavior, with no block RLP or block-validation encoding rule.
Engine API changes	No Engine API field or communication mechanism is added, matching score 0.	eip.md · Abstract and Specification, lines 14-16 and 37-104 The entire change is within execution-layer state and EVM contract behavior; no Engine API endpoint or field is specified.
New test-framework primitives	Existing state, call, creation, return-data, and revert expectations are sufficient to test the fixed bytecode; no new framework-level expectation or modifier is required, so score 0 applies.	eip.md · Specification > Factory Contract, lines 45-104 Expected behavior consists of ordinary account code, calldata, value forwarding, contract creation, return data, and revert outcomes. Uncertainty: The test section is TBD, but the specified behaviors do not reveal a need for a novel primitive.
Performance risks	The new fixed account exposes no new client execution algorithm or unmetered workload beyond already metered EVM execution; therefore it does not introduce a mechanism requiring separate protocol performance validation and scores 0.	eip.md · Specification > Factory Contract, lines 50-98 Variable input copying and contract creation are performed by ordinary EVM bytecode using existing calldata, memory, and CREATE2 operations. supporting/eip-1014.md · Specification and Rationale > Gas cost, lines 13-21 and 37-39 CREATE2 already meters initcode hashing by length to cover the associated computation and denial-of-service concern. Uncertainty: Adoption could increase use of CREATE2 factories, but workload popularity is not a new protocol performance mechanism specified by this EIP.
Cryptography	Reusing CREATE2's existing Keccak-based address derivation is not a new or modified cryptography mechanism, so score 0 applies.	eip.md · Specification > Factory Contract, lines 50-98 The contract supplies a salt and initcode to the already-defined CREATE2 opcode and introduces no cryptographic construction of its own. supporting/eip-1014.md · Specification, lines 11-21 CREATE2 already defines its deterministic address formula and fixed hash preimage as part of the existing opcode.
Unspecified behavior requiring cross-client consensus	The fixed bytecode plus the two required opcode specifications determines outcomes for constructible execution cases; the missing test vectors do not themselves leave consensus behavior unspecified. The score-0 anchor applies.	eip.md · Specification > Factory Contract, lines 41-104 The activation address and exact bytecode are fixed, and the bytecode explicitly defines the input-length rejection, CREATE2 invocation, success return, and failure revert paths. supporting/eip-211.md · Specification, lines 27-42 The return-data behavior used by the factory, including CREATE2 failure data, is specified by the required EIP. supporting/eip-1014.md · Specification and Clarifications, lines 11-21 and 41-57 The required CREATE2 proposal fixes address derivation, gas timing, collision failure, and same-transaction collision behavior. Uncertainty: The Test Cases section is TBD, but this is a coverage gap rather than an identified behavioral question requiring client agreement.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@f8be9ce27b EIPS/eip-7997.md committed 2025-08-19 · information cutoff 2025-08-21T13:34:18Z
Current master · File history · blob 9bd8766f32 · sha256 8fec7a727f75
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/05-retrospective-complexity-assignment/outputs/fork-eips/amsterdam/eip-7997.yaml · sha256 aada0f5dcac5
Supporting documents in the sealed package: supporting/eip-155.md, supporting/eip-211.md, supporting/eip-1014.md, supporting/eip-5792.md, supporting/eip-7702.md

Evaluated on: 2026-08-25 · Spec revision: 2025-08-19 · f8be9ce27b

Scope at the cutoff. Blinded assessment of the sealed Draft EIP-7997, which inserts fixed bytecode for a minimal CREATE2 factory at address 0x0B upon fork activation. The scope includes only the proposal, the historical checklist, and the five allowlisted linked EIPs; the proposal's Test Cases section is still TBD.

13MediumMedium

Evaluator: LLMChecklist v1
Confidence: Medium
Under-specified at assessment cutoff: Yes — 5 criteria affected
Plausible range: 8–16 (Low–Medium)
Assessment cutoff: 2025-08-21 · EIP revision f8be9ce27b (2025-08-19)

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 LLM total. Hover or focus a segment for its score and rationale.

Top complexity drivers

New fork activation mechanism3
Transition-tool interface changes2
Edge/boundary conditions2
Cross-EIP interactions2

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 proposal normatively identifies the bytecode and activation-time code insertion but leaves its Test Cases section TBD. It also does not define the transition-tool interface, activation ordering, or the disposition of any pre-existing nonce, balance, storage, or code at address 0x0B. These gaps chiefly affect estimates of regression-test breadth, transition integration, edge cases, and performance validation.

Plausible total

8–16
recorded score 13 · plausible tiers Low, Medium

Affected criteria (5)

New fork activation mechanism (3)
Transition-tool interface changes (2)
Patterns affecting pre-existing tests (1)
Performance risks (1)
Edge/boundary conditions (2)

Unresolved questions at the cutoff (3)

What exact account-state transition applies if 0x0B already has code, a nonce, balance, or storage at activation?
At what point in the activation block is the code inserted, and how must the transition tool be told that it is processing that block?
Which pre-existing tests require updates, and what boundary, adversarial, and performance cases are required beyond the currently TBD test section?

Notable ambiguities noted by the assessor (4)

The historical checklist includes Engine API encoding changes without a dedicated definition; it is scored conservatively at zero with low confidence.
The proposal calls the feature a precompile-range system contract. Because it installs EVM bytecode in account state, it is scored as an added system contract and not as an added or modified precompile.
"Upon activation, set the code" establishes a state modification but does not fully specify activation ordering or pre-existing account-field handling.
The factory's salt-plus-initcode calldata convention is treated as a contract-local interface, not an RLP/SSZ transaction, block, or protocol- interface encoding change.

Criterion breakdown

EIP-7997 Amsterdam / Glamsterdam: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
New fork activation mechanismUnder-specified	3	Setting account code at the activation point is a state modification at the fork activation block, directly matching the rubric's score-3 condition.	eip.md · Specification > Factory Contract Upon EIP activation, the protocol sets the code of address 0x0B to the specified byte sequence. eip.md · Rationale > Precompile-range system contract The code placement is described as an irregular insertion at a special address because a normal deployment transaction is unsuitable. Confidence: High Uncertainty: The state modification is explicit, but the proposal does not specify its ordering within the activation block or the treatment of any pre-existing account fields at 0x0B.
Transition-tool interface changesUnder-specified	2	The activation-dependent irregular state insertion is a new transition mechanism and requires the transition process to distinguish activation, matching the rubric's new-mechanism score even though no fields are stated.	eip.md · Specification > Factory Contract The transition at EIP activation must set fixed code at FACTORY_ADDRESS. eip.md · Rationale > Precompile-range system contract The proposal describes the deployment as an irregular insertion of code at a special address. Confidence: Low Uncertainty: No transition-tool interface or activation input is specified, so whether an actual interface change is needed cannot be established from the package.
Edge/boundary conditionsUnder-specified	2	The feature exposes multiple boundary-prone mechanisms: the 32-byte input boundary, variable initcode, CREATE2 success/collision/failure, return data, and value forwarding. None is shown to demand an elevated test count.	eip.md · Specification > Factory Contract; Rationale > Input validation The bytecode distinguishes calldata shorter than 32 bytes, copies variable-size initcode, forwards call value, and branches on CREATE2 success or failure while propagating failure data. supporting/eip-1014.md · Clarifications; Examples CREATE2 includes collision behavior and examples spanning empty and differently sized initcode and salts. Confidence: Medium Uncertainty: Test cases are TBD, so the exact case matrix and activation-address edge behavior are not enumerated.
Cross-EIP interactions	2	The proposal depends on two prior EIPs, so coordinated testing of address creation and failure-data propagation is required, but the interactions are limited to the factory's compact execution path.	eip.md · Front matter requires; Specification > Factory Contract EIP-7997 normatively requires EIP-211 and EIP-1014 and its bytecode uses their return-data instructions and CREATE2 behavior. supporting/eip-211.md · Specification EIP-211 specifies that CREATE2 has empty return data on success and failure data on failure, which the factory copies and reverts with. supporting/eip-1014.md · Specification; Clarifications EIP-1014 defines the address formula, gas behavior, and collision semantics of the factory's core CREATE2 operation. Confidence: High Uncertainty: EIP-155, EIP-5792, and EIP-7702 appear as motivation or alternatives rather than normative dependencies and are not used to raise this score.
Added system contracts	1	Exactly one non-stateful system contract is added, and its user-invoked CREATE2 behavior is not a new protocol system action such as a request to the consensus layer.	eip.md · Abstract; Specification > Factory Contract One minimal system contract is inserted at 0x0B with fixed bytecode; the code contains no storage operations and exposes ordinary CREATE2 deployment. eip.md · Rationale > Precompile-range system contract The proposal expressly classifies the new account as a precompile-range system contract inserted irregularly. Confidence: High Uncertainty: The rubric does not state whether ordinary contract creation initiated by a system contract counts as a system action; it is treated here as normal EVM execution rather than a new system action.
Patterns affecting pre-existing testsUnder-specified	1	The changed behavior of a single reserved address and its activation transition plausibly affects a minor, localized subset of existing state and call tests, rather than diverse test categories.	eip.md · Specification > Parameters; Specification > Factory Contract At activation, address 0x0B changes from its prior state to a callable code-backed factory with input validation and CREATE2 behavior. eip.md · Test Cases The test section is marked TODO and TBD. Confidence: Low Uncertainty: The proposal supplies no test inventory, so the existence and size of the pre-existing test subset are inferred from the normative address change.
Security risks	1	The explicit frontrunning risk is localized to use of the self-contained factory and can be reviewed and tested in isolation without a stated change to broader protocol security invariants.	eip.md · Security Considerations > Frontrunnable deployments Deployments of contracts that read environmental values can be frontrun and created with attacker-chosen parameters; fully deterministic contracts are recommended. eip.md · Rationale > No frontrunning protection Caller-bound salt protection was considered but omitted to retain permissionless multi-chain deployment. Confidence: Medium Uncertainty: The security discussion is narrow and the Test Cases section is TBD, so the sealed package does not demonstrate the full adversarial test surface.
Performance risksUnder-specified	1	The factory's variable-input execution and deployment path merit isolated benchmarking, but the mechanism is small, independently exercisable, and does not modify existing performance behavior.	eip.md · Specification > Factory Contract A small fixed contract copies variable-length initcode into memory and invokes CREATE2 using existing gas-metered operations. supporting/eip-1014.md · Specification; Rationale > Gas cost CREATE2 already charges for initcode hashing to address repeated hashing and denial-of-service cost. Confidence: Medium Uncertainty: The proposal contains no performance analysis or tests, so the need for validation is inferred from variable-size input rather than measured impact.

Show 16 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	The proposal adds contract bytecode but no EVM opcode.	eip.md · Specification > Factory Contract The factory bytecode uses existing instructions including CREATE2, RETURNDATASIZE, and RETURNDATACOPY; no opcode number is allocated. supporting/eip-211.md · Specification EIP-211 already defines RETURNDATASIZE and RETURNDATACOPY. supporting/eip-1014.md · Specification EIP-1014 already defines CREATE2 at opcode 0xf5. Uncertainty: Opcode availability is an explicit dependency; reusing those opcodes is not scored as adding them again.
Modified opcodes	No pre-existing opcode behavior is modified or deprecated.	eip.md · Specification > Factory Contract The proposal invokes existing opcodes from fixed bytecode and states no change to their behavior. Uncertainty: The contract depends on existing CREATE2 and return-data semantics, but no semantic amendment to those instructions is specified.
Added precompiles	No precompile is added; the separately scored addition is one code-backed system contract.	eip.md · Abstract; Rationale > Precompile-range system contract The feature is a system contract with fixed EVM bytecode placed in the precompile address range, not a native precompile implementation. Uncertainty: The phrase "precompile range" creates terminology ambiguity, but the proposal consistently specifies account code and calls the feature a system contract.
Modified precompiles	No pre-existing precompile is modified.	eip.md · Rationale > Precompile-range system contract Address 0x0B is chosen after existing precompiles; no existing precompile's logic or gas schedule is changed. Uncertainty: The new account is adjacent to precompiles, but adjacency alone does not alter any precompile behavior in the sealed specification.
Modified system contracts	No pre-existing system contract is directly or indirectly modified.	eip.md · Rationale > Precompile-range system contract Address 0x0B is selected as the next lowest address after existing precompiles, and the factory is described as a newly inserted contract. Uncertainty: The proposal assumes the address is reserved but does not inventory every possible chain's prior state; the assessment is limited to the assigned proposal's protocol scope.
EVM Gas rule changes	No EVM gas accounting mechanism is added or updated; the factory executes under the already-defined gas behavior of its existing opcodes.	eip.md · Specification > Factory Contract The proposal installs fixed bytecode composed of existing EVM instructions and specifies no gas schedule or gas-accounting rule. Uncertainty: The proposal provides no gas analysis, so the score is limited to the absence of a specified gas-rule change in the sealed text.
Blob gas accounting changes	No blob gas accounting mechanism is introduced or modified.	eip.md · Abstract; Specification The change is a CREATE2 factory system contract; no blob fields, blob gas, or blob-processing behavior is specified. Uncertainty: Blob behavior is not discussed; the zero reflects the sealed proposal's stated scope rather than external implementation evidence.
New EVM gas refund	No new EVM gas-refund mechanism is introduced.	eip.md · Specification > Factory Contract The factory forwards value to CREATE2 and either returns the created address or reverts; it defines no refund counter or refund rule. Uncertainty: The proposal does not analyze refunds, but none is present in its normative factory behavior.
New transaction types	No new transaction type is introduced.	eip.md · Rationale > Not a new transaction type The proposal explicitly chooses a system contract instead of a new creation transaction type. Uncertainty: The alternative transaction design is discussed only as a rejected option.
New or modified transaction validity mechanisms	The factory's runtime calldata check is contract execution behavior, not a new or modified transaction validity mechanism.	eip.md · Specification > Factory Contract; Rationale > Not a new transaction type Input shorter than 32 bytes causes a contract revert, while transactions continue to use existing types and no intrinsic-gas or validity rule is specified. Uncertainty: The proposal does not discuss transaction validation because the mechanism is accessed through ordinary calls.
New block / header fields	No new block or block-header field is introduced.	eip.md · Specification The only parameter is FACTORY_ADDRESS and no block or header field is defined. Uncertainty: Block headers are outside the stated mechanism and are not discussed in the sealed proposal.
Encoding changes (RLP/SSZ)	No transaction-, block-, or protocol-interface encoding change is introduced.	eip.md · Specification > Factory Contract The factory accepts a contract-local calldata convention of a 32-byte salt followed by initcode, without changing transaction, block, RLP, SSZ, or protocol-interface serialization. Uncertainty: The new contract has an input format, but it is treated as ordinary calldata to a new contract rather than the RLP/SSZ-level encoding change named by the rubric.
Block syncing changes	No new block RLP validation mechanism requiring sync testing is introduced.	eip.md · Specification The specification changes account code at activation and defines contract execution, without adding block RLP fields or block-validation rules. Uncertainty: Sync behavior is not discussed; the score follows the absence of a block encoding or validation change in the sealed specification.
Engine API changes	No Engine API field or communication mechanism is introduced.	eip.md · Specification The proposal specifies only an activation-time account-code insertion and the factory's EVM behavior; it introduces no Engine API endpoint or field. Uncertainty: The Engine API is not discussed, so the zero is based on the complete sealed specification containing no such change.
Engine API encoding changes	Conservatively, the row label does not apply because the proposal specifies no Engine API encoding change.	eip.md · Specification No Engine API payload, field, endpoint, or serialization is defined by the proposal. Uncertainty: The historical checklist has no dedicated definition for this row; no replacement definition was imported, and the score is conservative.
Cryptography	EIP-7997 reuses existing CREATE2 cryptography and introduces no new cryptographic primitive or modified cryptographic functionality.	eip.md · Specification > Factory Contract The factory invokes the already-existing CREATE2 opcode. supporting/eip-1014.md · Specification EIP-1014 defines CREATE2's existing keccak256-based deterministic address formula and hashing gas cost. Uncertainty: Deterministic addressing relies on existing keccak256 behavior, which is treated as a dependency rather than newly introduced cryptography.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@f8be9ce27b EIPS/eip-7997.md committed 2025-08-19 · information cutoff 2025-08-21T13:34:18Z
Current master · File history · blob 9bd8766f32 · sha256 8fec7a727f75
Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: gpt-5.6-sol at xhigh reasoning effort · isolation bubblewrap_one_eip_capsule_v1
Source record: Frozen research record research/tasks/05c-amsterdam-human-assessment-alignment/outputs/automated/eip-7997.yaml · sha256 0924c92fbea8
Supporting documents in the sealed package: supporting/eip-155.md, supporting/eip-211.md, supporting/eip-1014.md, supporting/eip-5792.md, supporting/eip-7702.md

Evaluated on: Not recorded · Spec revision: 2025-11-05 · ec05b85e53

5LowLow

Evaluator: HumanChecklist v1
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2026-01-07 · EIP at ec05b85e53
Source: merged ethspecs/pm checklist

Score bands · Checklist revision 1

Low <10
Medium 10–19
High ≥20

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

Complexity profile

Each segment is one criterion's contribution to the Human total. Hover or focus a segment for its score and rationale.

Top complexity drivers

Added system contracts2
Security risks2
New fork activation mechanism1

Criterion breakdown

EIP-7997 Amsterdam / Glamsterdam: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
Added system contracts	2	A new system contract is added in the precompile range.	—
Security risks	2	There is an open frontrunning risk that has not been solved. Whether this qualifies as security risk or inconvenience is subjective.	—
New fork activation mechanism	1	The EIP adds a new system contract at the next fork. It does not affect state but it might be called an 'internal variable' depending on how this is defined exactly.	—

Show 21 zero-score criteria

Zero-score criteria (Checklist revision 1)
Criterion	Why this score	Notes
Added opcodes	No rationale recorded.	—
Modified opcodes	No rationale recorded.	—
Added precompiles	No rationale recorded.	—
Modified precompiles	No rationale recorded.	—
Modified system contracts	No rationale recorded.	—
EVM Gas rule changes	No rationale recorded.	—
Blob gas accounting changes	No rationale recorded.	—
New EVM gas refund	No rationale recorded.	—
New transaction types	No rationale recorded.	—
New or modified transaction validity mechanisms	No rationale recorded.	—
New block / header fields	No rationale recorded.	—
Encoding changes (RLP/SSZ)	No rationale recorded.	—
Block syncing changes	No rationale recorded.	—
Engine API changes	No rationale recorded.	—
Engine API encoding changes	No rationale recorded.	—
Transition-tool interface changes	No rationale recorded.	—
Patterns affecting pre-existing tests	No rationale recorded.	—
Performance risks	No rationale recorded.	—
Edge/boundary conditions	No rationale recorded.	—
Cryptography	No rationale recorded.	—
Cross-EIP interactions	No rationale recorded.	—

Assessment provenance

Assessed EIP revision: ethereum/EIPs@ec05b85e53 EIPS/eip-7997.md committed 2025-11-05
EIP master revision at the time of the human checklist commit; the checklist itself does not pin an EIP revision.
Current master · File history · blob 3ac0f2270c · sha256 41984b52620b
Rubric: Checklist revision 1 · ethspecs/pm@d936bcb349
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Merged checklist ethspecs/pm@676285451c complexity_assessments/EIPs/EIP-7997.md · committed 2026-01-07
blob 0b3e3f4698 · sha256 bf037d294985
Research record: research/tasks/05c-amsterdam-human-assessment-alignment/inputs/human/eip-7997.yaml · sha256 848d3ee0d3a5

Both assessments applied Checklist revision 1 (24 criteria) to EIP-7997 in Amsterdam / Glamsterdam. Δ is LLM minus Human.

LLM13Medium

Human5Low

Δ total+8Tiers differ: Medium vs Low

Criteria16/24agree exactly · 4 differ by 1 · 4 differ by 2+

Confounded comparison. The human checklist evaluated the EIP as it stood when the checklist was written; the LLM evaluated the sealed historical revision. Input alignment: substantive drift; human hindsight exposure: low exposure. The study's primary LLM score under checklist revision 2 is 14; it uses a different criterion inventory and thresholds and is not directly comparable to either total here.

Exposure evidence

The assessment is grounded in proposal mechanisms and a disclosed security concern, with no implementation, devnet, or test-outcome evidence.

Substantive intervening revisions: Rewrites the Abstract and two Motivation paragraphs, and - the substantive part - adds a prose normative specification of the factory's behaviour ahead of the bytecode: when called, the account invokes CREATE2 (linking EIP-1014) with salt = first 32 bytes of input, init code = the remaining input and value = the call's value; the call reverts with empty return data if input is shorter than 32 bytes; if CREATE2 outputs 0 the call reverts with the creation frame's return data. The bytecode is retained and is now described as implementing that specification. |…

Complexity profiles side by side

LLM

Human

Largest disagreements: Transition-tool interface changes (+2), Edge/boundary conditions (+2), New fork activation mechanism (+2), Cross-EIP interactions (+2), Patterns affecting pre-existing tests (+1)

Show differences only (8 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
New fork activation mechanism	3	1	+2	Differ by 2+	Show rationale LLM Setting account code at the activation point is a state modification at the fork activation block, directly matching the rubric's score-3 condition. Human The EIP adds a new system contract at the next fork. It does not affect state but it might be called an 'internal variable' depending on how this is defined exactly.
Transition-tool interface changes	2	0	+2	Differ by 2+	Show rationale LLM The activation-dependent irregular state insertion is a new transition mechanism and requires the transition process to distinguish activation, matching the rubric's new-mechanism score even though no fields are stated. Human No rationale recorded.
Edge/boundary conditions	2	0	+2	Differ by 2+	Show rationale LLM The feature exposes multiple boundary-prone mechanisms: the 32-byte input boundary, variable initcode, CREATE2 success/collision/failure, return data, and value forwarding. None is shown to demand an elevated test count. Human No rationale recorded.
Cross-EIP interactions	2	0	+2	Differ by 2+	Show rationale LLM The proposal depends on two prior EIPs, so coordinated testing of address creation and failure-data propagation is required, but the interactions are limited to the factory's compact execution path. Human No rationale recorded.
Added system contracts	1	2	−1	Differ by 1	Show rationale LLM Exactly one non-stateful system contract is added, and its user-invoked CREATE2 behavior is not a new protocol system action such as a request to the consensus layer. Human A new system contract is added in the precompile range.
Patterns affecting pre-existing tests	1	0	+1	Differ by 1	Show rationale LLM The changed behavior of a single reserved address and its activation transition plausibly affects a minor, localized subset of existing state and call tests, rather than diverse test categories. Human No rationale recorded.
Security risks	1	2	−1	Differ by 1	Show rationale LLM The explicit frontrunning risk is localized to use of the self-contained factory and can be reviewed and tested in isolation without a stated change to broader protocol security invariants. Human There is an open frontrunning risk that has not been solved. Whether this qualifies as security risk or inconvenience is subjective.
Performance risks	1	0	+1	Differ by 1	Show rationale LLM The factory's variable-input execution and deployment path merit isolated benchmarking, but the mechanism is small, independently exercisable, and does not modify existing performance behavior. Human No rationale recorded.
Added opcodes	0	0	0	Agree	Show rationale LLM The proposal adds contract bytecode but no EVM opcode. Human No rationale recorded.
Modified opcodes	0	0	0	Agree	Show rationale LLM No pre-existing opcode behavior is modified or deprecated. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM No precompile is added; the separately scored addition is one code-backed system contract. Human No rationale recorded.
Modified precompiles	0	0	0	Agree	Show rationale LLM No pre-existing precompile is modified. Human No rationale recorded.
Modified system contracts	0	0	0	Agree	Show rationale LLM No pre-existing system contract is directly or indirectly modified. Human No rationale recorded.
EVM Gas rule changes	0	0	0	Agree	Show rationale LLM No EVM gas accounting mechanism is added or updated; the factory executes under the already-defined gas behavior of its existing opcodes. Human No rationale recorded.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM No blob gas accounting mechanism is introduced or modified. Human No rationale recorded.
New EVM gas refund	0	0	0	Agree	Show rationale LLM No new EVM gas-refund mechanism is introduced. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM No new transaction type is introduced. Human No rationale recorded.
New or modified transaction validity mechanisms	0	0	0	Agree	Show rationale LLM The factory's runtime calldata check is contract execution behavior, not a new or modified transaction validity mechanism. Human No rationale recorded.
New block / header fields	0	0	0	Agree	Show rationale LLM No new block or block-header field is introduced. Human No rationale recorded.
Encoding changes (RLP/SSZ)	0	0	0	Agree	Show rationale LLM No transaction-, block-, or protocol-interface encoding change is introduced. Human No rationale recorded.
Block syncing changes	0	0	0	Agree	Show rationale LLM No new block RLP validation mechanism requiring sync testing is introduced. Human No rationale recorded.
Engine API changes	0	0	0	Agree	Show rationale LLM No Engine API field or communication mechanism is introduced. Human No rationale recorded.
Engine API encoding changes	0	0	0	Agree	Show rationale LLM Conservatively, the row label does not apply because the proposal specifies no Engine API encoding change. Human No rationale recorded.
Cryptography	0	0	0	Agree	Show rationale LLM EIP-7997 reuses existing CREATE2 cryptography and introduces no new cryptographic primitive or modified cryptographic functionality. Human No rationale recorded.

Compare EIP-7997 with other assessments All Amsterdam / Glamsterdam assessments

Criterion legend and glossary

Every stacked bar, comparison matrix, and criterion table on this site uses the same criterion colours, abbreviations, and order. Colour marks the criterion group; the abbreviation and name identify the criterion. Scores are 0–3 per criterion (4 is exceptional; cross-EIP interactions is uncapped).

EVM surface

Opcodes, precompiles, and system contracts that are added or modified.

OP+
Added opcodes
Introduces new opcodes
Score anchors
0
No new opcodes are introduced.
1
A new simple opcode is introduced (no data portion, no complex stack mechanics, and a constant gas cost).
2
Multiple new simple opcodes are introduced, or a single new complex opcode is introduced (has data portion, or complex stack mechanics, or a dynamic gas cost).
3
Multiple new opcodes are introduced, and at least one of them is complex (has data portion, or complex stack mechanics, or a dynamic gas cost).
- Cryptography opcodes are not considered complex by default. Refer to the "Cryptography" section for a separate assessment.
Modified opcodes
Modifies pre-existing opcodes
Score anchors
0
No pre-existing opcode modifications are introduced.
3
At least one pre-existing opcode's behavior is modified (not including gas changes) or a pre-existing opcode is deprecated.
PC+
Added precompiles
Introduces new precompiles
Score anchors
0
No new precompiles are introduced.
1
A new simple precompile is introduced (constant input length, constant gas cost).
2
Multiple new simple precompiles are introduced, or a single new complex precompile is introduced (dynamic input length or dynamic gas cost).
3
Multiple new precompiles are introduced, and at least one of them is complex (dynamic input length or dynamic gas cost).
- Cryptography precompiles are not considered complex by default. Refer to the "Cryptography" for a separate assessment.
Modified precompiles
Modifies pre-existing precompiles logic or gas-accounting
Score anchors
0
No pre-existing precompiles are modified.
1
At least one pre-existing precompile has its gas schedule modified.
2
Multiple pre-existing precompiles have their gas schedule modified, or a single pre-existing precompile has its behavior modified.
3
The behavior of multiple pre-existing precompiles, or a single complex pre-existing precompile modified.
Added system contracts
Introduces new system contract, stateful or not
Score anchors
0
No new system contracts are introduced.
1
A new system contract is introduced that is not stateful nor does it trigger a new system action (e.g. requests to the consensus layer).
2
Multiple new system contracts are introduced or a single new system contract that is either stateful or triggers a new system action (e.g. requests to the consensus layer).
3
Multiple new system contracts are introduced and at least one of them is either stateful or triggers a new system action (e.g. requests to the consensus layer).
Modified system contracts
Modifies pre-existing system contracts
Score anchors
0
No modifications to pre-existing system contracts are introduced, directly or indirectly.
1
Does not directly modify any system contract, but its behavior has minor indirect effects on one or more system contracts.
2
Does not directly modify any system contract, but its behavior has major indirect effects on one or more system contracts.
3
At least one pre-existing system contract code or state is modified, which would involve irregular state transition or a similarly complex transition methodology.

Gas and accounting

Execution, blob, and state gas rules, refunds, and where charges happen inside opcodes.

EVM Gas rule changes
New EVM gas accounting rules
Score anchors
0
No gas accounting changes.
1
Existing gas accounting mechanism is updated.
2
A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
3
A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
ORD
State-access ordering within opcode execution · Checklist revision 2 only
Changes *where inside an opcode's execution* state is accessed, or where gas is charged relative to that access. Because a state access is recorded in the block-level access list only if execution had enough gas to reach it, this ordering is consensus-critical: moving it changes the BAL at every gas boundary of every affected opcode.
Score anchors
0
No change to where state is accessed, or to where gas is charged relative to a state access, within any opcode.
1
A single opcode's state-access or gas-charge ordering changes.
2
Multiple opcodes' ordering changes, or a new state-accessing operation is introduced whose position in the order must be settled.
3
The ordering rule changes for a whole class of state-accessing opcodes at once, or what counts as a recordable state access is redefined — requiring existing BAL vectors to be re-derived across opcodes and forks.
- Distinct from "Modified opcodes", which asks whether an opcode's **result** changed. This row asks about the **path to the result**, which is observable even when the result is identical. An EIP can be 0 on that row and 3 on this one.
- Score changes **to** the ordering. Do not score the fact that state accesses are observable — they always are.
- Each boundary must be re-tested against every other dimension that can change the answer (cold/warm, static/non-static, delegated/direct, revert/success), so the case count grows multiplicatively rather than additively. Note this explicitly under Special Considerations.
Blob gas accounting changes
New Blob gas accounting rules which potentially affect pre-existing tests
Score anchors
0
No blob gas accounting changes.
1
Existing blob gas accounting mechanism is updated.
2
A new blob gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
3
A new blob gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
SGAS
State gas accounting changes · Checklist revision 2 only
New state gas accounting rules. State gas is the cost of *writing* state, as opposed to accessing or executing it: `StateGasCosts`, `COST_PER_STATE_BYTE`, the block-level state gas budget, and the spill path into execution gas.
Score anchors
0
No state gas accounting changes.
1
An existing state gas cost or `STATE_BYTES_PER_*` rate is adjusted.
2
A new state-gas-charging site is introduced, or the block-level state gas budget or reservoir allocation is modified.
3
A new state gas charging mechanism is introduced, or the spill interaction between state gas and execution gas is modified, affecting existing gas tests.
- Harder to test than blob gas: the spill path means state gas cannot be metered independently of execution gas, and some costs (e.g. `NEW_ACCOUNT`) are state-dependent.
New EVM gas refund
New gas-refund mechanism
Score anchors
0
No new gas-refund mechanisms are introduced.
1
A new simple gas-refund mechanism is introduced that does not affect either existing tests or existing gas-refund mechanisms.
2
A new complex gas-refund mechanism is introduced or a simple mechanism that affects existing tests or existing gas-refund mechanisms.
3
A new complex gas-refund mechanism is introduced that affects existing tests or existing gas-refund mechanisms.

Blocks, transactions, and encoding

Transaction types and validity, block and header fields, encodings, syncing, and activation-time changes.

New transaction types
Introduces a new transaction type
Score anchors
0
No new transaction types are introduced.
3
A new transaction type is introduced.
New or modified transaction validity mechanisms
Creates new or modifies pre-existing transaction types' validation mechanisms
Score anchors
0
No changes are introduced to the validity rules of existing transaction types or to their intrinsic gas cost calculation.
1
Minor adjustments are introduced to validity rules or intrinsic gas cost calculation, but they do not significantly affect existing tests.
2
Changes to validity rules or intrinsic gas cost calculation affect existing tests, but require only limited updates to test cases and no redesign of the testing infrastructure.
3
Changes to validity rules or intrinsic gas cost calculation require extensive rework or redesign of the tests or testing infrastructure.
New block / header fields
Introduces new block or block header fields
Score anchors
0
No new block or header fields are introduced.
3
A new block or header field is introduced.
ENC
Encoding changes (RLP/SSZ)
Introduces encoding changes at the transaction/block/interfaces level
Score anchors
0
No encoding changes are introduced at the transaction, block, or interfaces levels.
3
An encoding change is introduced at transaction, block or interfaces level (e.g. RLP -> SSZ).
- "Interfaces level" includes the Engine API. Score an Engine API encoding change (e.g. JSON -> SSZ) here.
Block syncing changes
Modifies block RLP validation mechanisms that require test client syncing.
Score anchors
0
No new RLP validation mechanism is introduced.
1
A single simple RLP validation mechanism is introduced.
2
Multiple simple RLP validation mechanisms are introduced or a single complex one.
3
Multiple RLP validation mechanisms are introduced and at least one of them is deemed complex.
ACT
New fork activation mechanism
Modifies state, internal variables, or similar, at the fork activation block
Score anchors
0
No state modifications, internal variables or similar are modified at the fork activation block.
3
Either a state modification or internal variables are modified at the fork activation block.
- Initialization of new internal variable is not considered a modification.

Client interfaces

Engine API and transition-tool interface changes.

Engine API changes
Introduces new fields to the Engine API directives
Score anchors
0
No new fields or communication mechanisms are introduced to the Engine API.
1
A single new field is introduced in one of the Engine API endpoints.
2
Multiple fields are introduced to one or multiple Engine API end points, or a new Engine API end-point is introduced.
3
Multiple fields are introduced to one or multiple Engine API end points and a new Engine API end-point is introduced.
Engine API encoding changes · Checklist revision 1 only
Engine API encoding changes (the revision-1 template defines no anchor text for this row).
T8N
Transition-tool interface changes
Modifies or adds new fields to the transition tool interface.
Score anchors
0
No modifications to the transition tool interface are required.
1
A single new field needs to be introduced to the transition tool interface.
2
Multiple new fields or a new mechanism has to be introduced to the transition tool interface.
3
Multiple new fields and a new mechanism has to be introduced to the transition tool interface.
- Special consideration must be paid to this section if the EIP introduces a mechanism that requires the state transition tool to be aware whether the block it is processing is the fork-activation block.

Testing impact

Rework, new invariants, and new primitives required in the test framework.

Patterns affecting pre-existing tests
Implements a new validation mechanism or rule that translates in reworking pre-existing tests
Score anchors
0
No pre-existing tests are affected by this change.
1
Minor subset of existing tests are affected by this change.
2
Considerable subset of existing tests are affected by this change but involves only a contrived category of tests.
3
Major subset of existing tests are affected, including diverse category of tests (benchmarks, static, multiple forks, etc.).
INV
New invariant on pre-existing tests · Checklist revision 2 only
Tests that are **not about this EIP** must nonetheless assert something this EIP produces. Their logic does not change; they gain a new thing to check.
Score anchors
0
Pre-existing tests assert nothing new.
1
A narrow, contrived category of pre-existing tests gains a new assertion.
2
A broad category gains a new assertion, applied mechanically.
3
Every test in the fork gains the assertion regardless of what it tests, and pre-fork vectors must be re-derived to satisfy it.
- Paired with the row above, and easy to confuse with it. "Patterns affecting pre-existing tests" asks whether existing tests must be **reworked**; this row asks whether they must **additionally assert something new**. Score both — an EIP can be low on one and high on the other.
New test-framework primitives · Checklist revision 2 only
Requires new abstractions in the test framework itself — expectation types, modifiers, helpers — beyond writing test functions with what already exists.
Score anchors
0
Existing test primitives suffice.
1
Existing primitives need minor extension.
2
New expectation or modifier primitives are required, reusable within this EIP's own test suite.
3
New framework-level primitives are required that become a permanent part of the framework and are used by other EIPs' tests.

Risk and validation

Security, performance, boundary conditions, and cryptography that need validation.

Security risks
Introduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
Score anchors
0
No new mechanisms are introduced that could pose a security risk.
1
The introduced mechanisms are self-contained, can be validated in isolation, and do not alter existing invariants that could pose a security risk for any stakeholders.
2
The introduced mechanisms interact with a limited number of existing components, slightly altering their security assumptions and requiring a targeted security review or fuzzing.
3
The introduced mechanisms interact with multiple existing components, including critical ones, substantially altering their security assumptions and requiring an extensive security review and fuzzing.
Performance risks
Introduces or modifies mechanisms and requires performance validation.
Score anchors
0
No new mechanisms are introduced that require performance validation.
1
The introduced mechanisms can be benchmarked in isolation and do not affect existing performance behavior.
2
The introduced mechanisms cannot be fully benchmarked in isolation, but they only have a limited impact on the existing performance benchmarks.
3
The introduced mechanisms cannot be benchmarked in isolation and have a substantial impact on existing performance benchmarks or have complex interactions with existing mechanisms.
Edge/boundary conditions
Feature contains edge/boundary conditions.
Score anchors
0
No discernible edge cases or boundary conditions are introduced.
1
A single edge-case or boundary-condition prone mechanism is introduced.
2
Multiple edge-case or boundary-condition prone mechanisms are introduced, but none of them requires an elevated number of cases to test.
3
Multiple edge-case or boundary-condition prone mechanisms are introduced and at least one of them requires an elevated number of cases to test.
Cryptography
Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography
Score anchors
0
No cryptography mechanisms are introduced.
1
A new cryptography mechanism is introduced but it is a well known mechanism that is known to have vast resources to aid on its testing.
2
Multiple new cryptography mechanisms are introduced that are well-known or a single but novel mechanism is introduced that is either untested or has limited resources.
3
Multiple new cryptography mechanisms are introduced and at least one of them is a novel mechanism.

Coordination

Cross-EIP interactions and behavior that clients must agree on before tests exist.

XEIP
Cross-EIP interactions
Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
Score anchors
0
Fully self-contained EIP that does not depend on, modify, or conflict with any other EIP.
1
The EIP interacts with one or more other EIPs in a non-critical and limited way but can be tested independently for the most part.
2
The EIP depends on or modifies one or more other EIPs such that coordinated testing and consideration is required, but interactions are limited in scope and not complex.
3
The EIP has strong interdependencies with multiple EIPs, requiring extensive coordinated cross-EIP testing as well as potential re-design of existing test vectors.
- +1 for every 3 additional interacting EIPs beyond the first 3, each of which requires its own coordinated test cases. List the EIPs in the rationale.
- This row is intentionally uncapped, unlike every other anchor: each interacting EIP is another axis of the test matrix, so a ceiling would make a 12-EIP product indistinguishable from a 3-EIP one.
UNSP
Unspecified behavior requiring cross-client consensus · Checklist revision 2 only
The EIP text does not determine the answer for cases a test can construct. Clients must agree on a previously unspecified detail before tests can be baselined. The cost here is coordination and re-baselining, not test writing.
Score anchors
0
The EIP text determines the answer for every case a test could construct.
1
A few details are unspecified but have an obvious intended reading.
2
Details require client agreement before tests can be written, but they are localized.
3
A previously unspecified *and previously unobservable* behavior becomes consensus-critical; expect tests to be re-baselined on each round of EIP amendment.
- Score this from the EIP's state at assessment time: whether it has client implementations, whether it has been through a devnet, and how many open questions remain on its discussion thread.