EIP complexity assessment

EIP-8200: EVMification

Assessed in Hegotá. The score describes the EIP text available at the snapshot, not the EIP as it stands today.

ProspectiveHegotáSnapshot 2026-08-25PFI at snapshotLayers: execution

LLM Completescore 28

Human Draft PRscore 22 · Checklist revision 2· ethspecs/pm #109 (draft)

LLM · Checklist revision 22026-08-26 · Original snapshot · 28 Human · Checklist revision 2Draft PR · 22 CompareHuman vs LLM · same checklist revision

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

Scope at the cutoff. Execution-layer-only assessment of the Draft EIP-8200 snapshot. The proposal installs unspecified EVM bytecode at the RIPEMD-160, MODEXP, and BLAKE2f precompile addresses at fork activation, stops native precompile treatment, and replaces their special gas formulas with standard EVM execution costs.

28HighHigh

Evaluator: LLMChecklist v2
Confidence: Medium
Under-specified at assessment cutoff: Yes — 10 criteria affected
Plausible range: 26–36 (High)
Snapshot: 2026-08-25 · EIP revision ac450a4ab2 (2026-08-25)

Score bands · Checklist revision 2

Low <12
Medium 12–22
High ≥23

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

Complexity profile

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

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: Material consensus inputs are absent: none of the three deployment bytecodes is specified, all gas comparisons are TODOs, and Test Cases is entirely TODO. The omissions prevent exact activation state, gas baselines, executable edge semantics, performance bounds, and test infrastructure needs from being fixed.

Plausible total

26–36
recorded score 28 · plausible tiers High

Affected criteria (10)

Modified precompiles (2)
EVM Gas rule changes (1)
Transition-tool interface changes (0)
Patterns affecting pre-existing tests (2)
New invariant on pre-existing tests (1)
New test-framework primitives (0)
Security risks (3)
Performance risks (2)
Cryptography (2)
Unspecified behavior requiring cross-client consensus (3)

Unresolved questions at the cutoff (5)

What exact byte sequence must be installed at each of the three addresses?
How does each bytecode normatively reproduce every valid output and every invalid-input failure mode of the replaced precompile?
What are the exact gas costs and compatibility effects across each input-size and fixed-forwarded-gas boundary?
What activation-block inputs or transition-tool interface, if any, are required to perform and verify the code installation?
Which existing tests must be reworked, which unrelated tests gain assertions, and which new framework primitives are required?

Notable ambiguities noted by the assessor (4)

Functional equivalence is stated as a goal but is not executable or byte-for-byte deterministic without the three missing bytecodes.
Standard EVM execution costs do not determine numeric gas results until exact opcode sequences and their input-dependent control flow are supplied.
Invalid-input equivalence is required by Security Considerations but is not normatively enumerated for the three replacements in EIP-8200.
The activation-block action is explicit, while its transition-tool signaling and test-fixture representation are not described.

Criterion breakdown

EIP-8200 Hegotá: LLM criterion scores and rationale
Criterion	Score	Why this score	Evidence / uncertainty
Cross-EIP interactionsExceptional	4	Coordinated cases are required for 152, 198, 7666, 7823, and 7883, plus the package-described but unnumbered RIPEMD-160 precompile specification. These six interactions span deployment, legacy functional equivalence, input bounds, and gas baselines. The uncapped rule gives base score 3 plus 1 for the third additional interaction beyond the first three. Exceptional score: Six separately package-grounded interactions each require coordinated cases; under the uncapped formula, three interactions beyond the first three add one point to the score-3 anchor.	eip.md · Front matter requires; Abstract; Rationale > Same mechanism as EIP-7666 EIP-8200 requires 152, 7666, 7823, and 7883, replaces behavior at three existing precompile addresses, and adopts the 7666 deployment mechanism. supporting/eip-7823.md · Specification The current MODEXP interface originates in 198 and its three input lengths are capped by 7823, including an all-gas error path above the bounds. supporting/eip-7883.md · Abstract; Specification; Test Cases EIP-7883 defines the current MODEXP gas formula and updated costs whose special pricing EIP-8200 replaces. Confidence: High Uncertainty: The package does not identify the EIP number defining the current RIPEMD-160 precompile, so that interaction is recorded separately rather than guessed. Interacting EIPs: EIP-152, EIP-198, EIP-7666, EIP-7823, EIP-7883
New fork activation mechanism	3	The rubric assigns score 3 when state is modified at the fork activation block. This proposal performs three explicit code-state modifications then.	eip.md · Specification > Deployment At the start of the activation block, client state must be changed by setting code at each of three precompile addresses. Confidence: High Uncertainty: The byte values are missing, but the requirement to modify state at activation is unambiguous.
Security risksUnder-specified	3	The activation transition, ordinary EVM execution, gas behavior, and three existing cryptographic interfaces all interact. Incorrect equivalence can cause consensus divergence or user-contract failure, requiring extensive review, differential testing, and fuzzing across multiple critical components.	eip.md · Security Considerations Fixed-gas callers may revert, and each replacement must be thoroughly tested and audited for every valid output and invalid-input behavior. eip.md · Motivation The proposal targets three special implementations whose cross-client maintenance is itself described as carrying consensus-bug risk. Confidence: Medium Uncertainty: Exact bytecode is absent, so its concrete attack surface and audit findings cannot be assessed from the package.
Edge/boundary conditions	3	Three distinct variable-input mechanisms expose multiple boundaries, and MODEXP length combinations plus BLAKE2f length, flag, and round boundaries require an elevated case set. This matches score 3.	supporting/eip-152.md · Specification; Test Cases BLAKE2f has an exact 213-byte input, a restricted final flag, a 32-bit rounds value, and vectors for short, long, invalid-flag, zero-round, and maximum-round inputs. supporting/eip-7823.md · Specification; Rationale > Analysis MODEXP has three independently encoded length fields, zero-length cases, and an 8192-bit bound whose violation consumes all gas. eip.md · Security Considerations Each bytecode must match all valid outputs, all invalid-input handling, and changed fixed-gas-call behavior. Confidence: High Uncertainty: Missing bytecode prevents enumerating implementation-created boundaries, but the inherited interface boundaries already satisfy score 3.
Unspecified behavior requiring cross-client consensusUnder-specified	3	Clients cannot derive the activation state, exact gas results, or executable edge behavior from the snapshot. Newly deployed code bytes and their behavior are consensus-critical and must be agreed before vectors can be baselined, matching score 3.	eip.md · Specification > Deployment The exact consensus bytecode for all three addresses is explicitly not yet specified. eip.md · Specification > Gas Costs; Test Cases Each gas comparison and the complete test-cases section are TODOs, while gas is a function of the missing bytecode. Confidence: High Uncertainty: This score measures the snapshot's explicit incompleteness; no package evidence establishes implementations, devnets, or resolved questions.
Modified precompilesUnder-specified	2	Multiple existing precompiles have their gas schedules modified, which is the explicit score-2 anchor. Functional behavior is specified as equivalent, so score 3 is not assigned on the sealed text.	eip.md · Specification > Deployment; Specification > Gas Costs RIPEMD-160, MODEXP, and BLAKE2f stop being precompiles and their three special gas schedules are replaced with bytecode execution costs. eip.md · Security Considerations > Implementation correctness Valid outputs and invalid-input behavior are intended to remain identical under the replacement implementation. Confidence: Medium Uncertainty: Without bytecode or tests, it is unresolved whether observable behavior beyond gas will in fact differ for any edge input.
Added system contracts	2	Three protocol-installed EVM contracts are added, satisfying the multiple system-contract condition for score 2. None is specified as stateful or as triggering a new system action.	eip.md · Specification > Constants; Specification > Deployment EVM code is installed at three fixed protocol addresses at fork activation. eip.md · Rationale > Bytecode at precompile address vs. library contracts The deployed artifacts are contracts at the existing addresses rather than library contracts at new user-selected addresses. Confidence: High Uncertainty: The exact contract code is not yet specified.
Patterns affecting pre-existing testsUnder-specified	2	Existing vectors for three distinct precompiles require new execution and gas baselines. The affected tests are considerable but localized to the contrived category of calls to these three addresses, matching score 2.	eip.md · Specification > Deployment; Specification > Gas Costs Three precompiles change execution path and gas calculation at their existing addresses from the activation block onward. eip.md · Security Considerations > Implementation correctness The replacement bytecode must be tested against original valid outputs and original invalid-input handling. Confidence: Medium Uncertainty: Test Cases is only a TODO, so the exact breadth of existing-test rework is not determined and could be broader once bytecode is supplied.
Performance risksUnder-specified	2	Performance must be validated both for individual bytecodes and their effect on existing precompile workloads and client EVM execution. The impact is not fully established in isolation but is confined to three call targets on the package evidence, matching score 2.	eip.md · Motivation; Specification > Gas Costs Three special native implementations become EVM execution; MODEXP is expected to cost more for large inputs and all gas comparisons remain TODOs. supporting/eip-152.md · Rationale; Appendix - benchmarks BLAKE2f was introduced as a native precompile because EVM word semantics are inefficient for it, and the supporting document records round-dependent native benchmarks. Confidence: Medium Uncertainty: No bytecode, impact analysis, or bytecode gas/performance comparison is present, so substantial performance impact cannot be excluded.
CryptographyUnder-specified	2	Multiple well-known cryptographic mechanisms must be reimplemented and equivalence-tested in a new execution form. This matches the multiple well-known mechanisms at score 2; no novel cryptography is introduced.	eip.md · Abstract; Motivation The proposal replaces RIPEMD-160, modular exponentiation, and BLAKE2f with EVM implementations while preserving functionality. supporting/eip-152.md · Specification BLAKE2f is a cryptographic compression function with a precisely encoded state, message, counters, round count, and final-block flag. Confidence: High Uncertainty: The concrete EVM implementations are absent, so implementation-specific cryptographic testing details remain unknown.
EVM Gas rule changesUnder-specified	1	Three existing special gas schedules are replaced by the existing EVM execution-accounting mechanism. This updates gas accounting but does not introduce a new metering mechanism, matching score 1.	eip.md · Specification > Gas Costs Calls to all three addresses change from precompile-specific formulas to the standard costs of the EVM opcodes executed by the deployed code. eip.md · Backwards Compatibility The proposal explicitly states that gas costs will differ and may affect contracts relying on precise gas calculations. Confidence: High Uncertainty: The exact deltas cannot be calculated because all three bytecodes and gas comparisons are absent, but that omission does not change the anchor class.
New invariant on pre-existing testsUnder-specified	1	The new fork state gives activation-focused pre-existing tests a narrow new assertion at three addresses. The snapshot does not require every unrelated post-fork test to assert it.	eip.md · Specification > Deployment At activation, code must exist at each of three listed addresses and the addresses must cease being treated as precompiles. Confidence: Medium Uncertainty: The missing bytecodes and test plan leave the exact assertion strategy unspecified.

Show 16 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Evidence / uncertainty
Added opcodes	No opcode is introduced.	eip.md · Specification > Deployment; Specification > Gas Costs The proposal deploys bytecode charged under existing standard EVM opcode costs and specifies no new opcode. Uncertainty: No material uncertainty is present in the package for this anchor.
Modified opcodes	No pre-existing opcode result rule is modified or deprecated. The CALL-family dispatch reaches code instead of a precompile, but the target functionality is required to remain equivalent and gas changes are scored separately.	eip.md · Abstract; Backwards Compatibility Calls keep the same target addresses and are required to preserve functionality; the described result difference is gas cost, which this anchor excludes. Uncertainty: Exact equivalence cannot be checked until bytecode exists, but the normative proposal does not modify an opcode's result.
Added precompiles	The proposal removes native precompile treatment rather than adding a precompile.	eip.md · Specification > Deployment Three addresses cease being treated as precompiles; no precompile is added. Uncertainty: No material uncertainty is present in the package for this anchor.
Modified system contracts	The direct changes are accounted for as added system contracts and modified precompiles. The package identifies no pre-existing system contract that is modified.	eip.md · Specification > Deployment The addresses are existing precompiles, while the EVM contracts installed there are new; no pre-existing EVM system contract code or state is named. Uncertainty: The rubric does not define precompiles as system contracts, so this assessment treats the separately named precompile anchors as controlling.
State-access ordering within opcode execution	No opcode state-access or gas-charge ordering rule is modified. The fork-time code write is an activation transition, not an ordering change inside opcode execution.	eip.md · Specification > Deployment The specified change installs code at three addresses and ends native precompile treatment; it states no change to the internal ordering of an opcode's state access and gas charging. Uncertainty: The bytecode is unspecified, but the snapshot contains no normative rule that changes state-access ordering for an opcode.
Blob gas accounting changes	No blob gas accounting rule is introduced or modified.	eip.md · Specification > Gas Costs The only gas change described is replacement of three precompile formulas by standard EVM execution costs; no blob-gas mechanism is mentioned. Uncertainty: No material uncertainty is present in the package for this anchor.
State gas accounting changes	A fork activation state change is present, but the rubric's state-gas accounting mechanisms are not changed.	eip.md · Specification > Deployment The proposal requires a fork-time code installation, but specifies no state-gas price, charging site, budget, reservoir, or execution-gas spill rule. Uncertainty: No material uncertainty is present in the package for this anchor.
New EVM gas refund	No new gas-refund mechanism is introduced.	eip.md · Specification > Gas Costs The gas section changes charging to standard opcode costs and specifies no refund production or refund accounting. Uncertainty: No material uncertainty is present in the package for this anchor.
New transaction types	No transaction type is introduced.	eip.md · Specification The proposal specifies only fork-time deployment and changed call charging, with no new transaction envelope or type. Uncertainty: No material uncertainty is present in the package for this anchor.
New or modified transaction validity mechanisms	Internal execution may run out of gas under a fixed-gas call, but transaction admission, validity, and intrinsic gas are unchanged.	eip.md · Specification > Gas Costs; Backwards Compatibility Gas changes apply during calls to the three addresses; no transaction validity rule or intrinsic gas calculation is changed. Uncertainty: No material uncertainty is present in the package for this anchor.
New block / header fields	No new block or header field is introduced.	eip.md · Specification The specification introduces no block body or block header field. Uncertainty: No material uncertainty is present in the package for this anchor.
Encoding changes (RLP/SSZ)	No transaction, block, or interface encoding is changed.	eip.md · Rationale > Bytecode at precompile address vs. library contracts Existing callers retain the same addresses and interfaces; no transaction, block, or interface-level RLP or SSZ change is introduced. Uncertainty: No material uncertainty is present in the package for this anchor.
Block syncing changes	No block RLP validation mechanism is introduced.	eip.md · Specification The specification changes fork-time account code and precompile dispatch; it introduces no block RLP field or RLP validation rule. Uncertainty: No material uncertainty is present in the package for this anchor.
Engine API changes	No Engine API change is specified.	eip.md · Specification The specification contains constants, deployment, and gas rules only and introduces no Engine API field, endpoint, or communication mechanism. Uncertainty: No material uncertainty is present in the package for this anchor.
Transition-tool interface changesUnder-specified	Fork-block awareness is required operationally, yet no modification or new field in the transition-tool interface is specified, so the documented interface-change score is 0.	eip.md · Specification > Deployment The transition must act at the start of the fork activation block, but the EIP defines no transition-tool field or interface mechanism. Uncertainty: The package does not explain how the transition tool learns that the block is the activation block; later specification could require fields or a new mechanism.
New test-framework primitivesUnder-specified	The snapshot identifies no expectation type, modifier, helper, or permanent framework abstraction, so score 0 is the package-grounded result.	eip.md · Test Cases The entire test-cases section is a TODO and requires no new framework primitive. Uncertainty: Because the test plan and bytecodes are missing, whether existing primitives suffice is not established.

Assessment provenance

Assessed EIP revision: ethereum/EIPs@ac450a4ab2 EIPS/eip-8200.md committed 2026-08-25 · information cutoff 2026-08-25T11:56:58Z
Current master · File history · blob 17c2158560 · sha256 15d2e9e885d6
Rubric: Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator: gpt-5.6-sol at xhigh reasoning effort · isolation bubblewrap_one_eip_capsule_v1
Source record: Frozen research record research/tasks/08-hegota-prospective-complexity-assessment/outputs/assessments/hegota-pfi-2026-08-26/eip-8200.yaml · sha256 7b1b91b5e99b
Supporting documents in the sealed package: supporting/eip-152.md, supporting/eip-7666.md, supporting/eip-7823.md, supporting/eip-7883.md

Evaluated on: Not recorded

22MediumMedium

Evaluator: HumanChecklist v2
Confidence: Not recorded
Under-specified at assessment cutoff: Not recorded in the checklist
Checklist published: 2026-08-18
Source: open ethspecs/pm pull request #109 (draft)

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

Top complexity drivers

Modified precompiles3
New fork activation mechanism3
Edge/boundary conditions3
Unspecified behavior requiring cross-client consensus3

Criterion breakdown

EIP-8200 Hegotá: Human criterion scores and rationale
Criterion	Score	Why this score	Notes
Modified precompiles	3	The behavior of three pre-existing precompiles changes: ordinary EVM pricing (measured: small-input MODEXP ~6.6×, `rounds`-priced BLAKE2f callers out-of-gas, and an inverse case where the EIP-7883 formula exceeds the transaction gas cap but the EVM version succeeds), different invalid-input returndata, and loss of EIP-2929 pre-warming at the retired addresses — the last unstated by the EIP and measured as 198 flipped executions.	—
New fork activation mechanism	3	Code is written to three addresses at the start of the activation block — a protocol-mandated install with no deploying transaction, implemented in the prototype through the spec's irregular-state-transition hook (the EIP-8141 expiry-verifier pattern: code only, nonce and balance preserved) plus a genesis pre-allocation for test fixtures.	—
Edge/boundary conditions	3	The equivalence surface is the full input domain of three functions: lengths, invalid encodings, and gas boundaries. Measured: the prototype bytecode already diverges on one edge — BLAKE2f's final-block flag `0x02` is accepted where EIP-152 requires rejection — and invalid inputs revert with `Error(string)` where the precompiles return empty revert data.	—
Unspecified behavior requiring cross-client consensus	3	The consensus artifact itself is unspecified: the EIP ships without the deployment bytecode, with TODO gas tables and TODO test cases. The prototype pins the runtime artifacts from eth-act/evmification's own CI; an independent compile reproduced every executable byte but differed in the CBOR metadata trailer — precisely the divergence that becomes a consensus split unless the EIP pins the exact bytes by hash. Every revision of the eventual bytecode re-baselines the whole differential corpus.	—
Patterns affecting pre-existing tests	2	Measured: an EELS prototype flips 948 fixture executions across 40 functions — spread from byzantium through osaka plus the ported static suites, but all within one well-scoped category: tests that exercise the three retired precompiles. Every flip has been diagnosed (gas drift in both directions, invalid-input semantics, warm-set loss): none is unexplained.	—
Security risks	2	Consensus-critical bytecode replaces natively audited implementations; an implementation error is a consensus split. The measured BLAKE2f flag divergence is this risk realized in the current candidate bytecode — differential fuzzing against the retired implementations is mandatory.	—
Cross-EIP interactions	2	Three coordination targets — EIP-7666 (the shared deployment mechanism), the EIP-7883/7823 MODEXP pricing cluster (whose suites flip mechanically), and EIP-2929 (warm-set membership) — each limited in scope; EIP-152 is the substance being replaced, not a cross-EIP axis.	—
Added system contracts	1	Three stateless code deposits appear at the retired addresses, but nothing in the protocol ever invokes them as system actors; the deployment act is scored under "New fork activation mechanism" and their behavioral surface under "Edge/boundary conditions".	—
New test-framework primitives	1	Existing primitives suffice with minor extension: a fork precompile-list subtraction and code pre-allocation at the retired addresses.	—
Performance risks	1	Three pure functions, fully benchmarkable in isolation; gas now scales with actual work (large-input MODEXP prices itself out rather than underpricing compute), and the benchmark-suite re-derivation is test rework, not client performance risk.	—
Cryptography	1	Nothing cryptographically new enters consensus: three well-known functions are reimplemented, and vast existing vector sets make the reimplementations differentially provable; the proving burden itself is scored under "Edge/boundary conditions".	—

Show 17 zero-score criteria

Zero-score criteria (Checklist revision 2)
Criterion	Why this score	Notes
Added opcodes	No rationale recorded.	—
Modified opcodes	No rationale recorded.	—
Added precompiles	No rationale recorded.	—
Modified system contracts	No rationale recorded.	—
EVM Gas rule changes	No gas accounting mechanism changes: the precompile-specific price tables disappear with the precompiles, and the pricing shift is the "Modified precompiles" row's substance.	—
State-access ordering within opcode execution	No rationale recorded.	—
Blob gas accounting changes	No rationale recorded.	—
State 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.	—
Transition-tool interface changes	No rationale recorded.	—
New invariant on pre-existing tests	No rationale recorded.	—

Assessment provenance

Rubric: Checklist revision 2 · ethspecs/pm@3d8c0128c5
Evaluator: STEEL team · ethspecs/pm complexity_assessments
Source record: Open draft pull request #109: Add EIP-8200 complexity assessment · checklist at 6a3be712b9 · updated 2026-08-18
blob f83f82beec · sha256 d41a30af8535
Research record: research/tasks/09-hegota-human-assessment-snapshot/outputs/assessments/eip-8200.yaml · sha256 e90d9cac6551

Both assessments applied Checklist revision 2 (28 criteria) to EIP-8200 in Hegotá. Δ is LLM minus Human.

Using the latest scored LLM evaluation for this checklist: 2026-08-26 · spec 2026-08-25 · ac450a4ab2. The Human and LLM assessments may use different spec revisions.

LLM28High

Human22Medium

Δ total+6Tiers differ: High vs Medium

Criteria19/28agree exactly · 8 differ by 1 · 1 differ by 2+

Complexity profiles side by side

LLM

Human

Largest disagreements: Cross-EIP interactions (+2), EVM Gas rule changes (+1), New invariant on pre-existing tests (+1), New test-framework primitives (−1), Cryptography (+1)

Show differences only (9 criteria)

Per-criterion scores, Human versus LLM, ordered by the size of the difference
Criterion	LLM	Human	Δ	Agreement	Rationale from each source
Cross-EIP interactions	4	2	+2	Differ by 2+	Show rationale LLM Coordinated cases are required for 152, 198, 7666, 7823, and 7883, plus the package-described but unnumbered RIPEMD-160 precompile specification. These six interactions span deployment, legacy functional equivalence, input bounds, and gas baselines. The uncapped rule gives base score 3 plus 1 for the third additional interaction beyond the first three. Human Three coordination targets — EIP-7666 (the shared deployment mechanism), the EIP-7883/7823 MODEXP pricing cluster (whose suites flip mechanically), and EIP-2929 (warm-set membership) — each limited in scope; EIP-152 is the substance being replaced, not a cross-EIP axis.
Modified precompiles	2	3	−1	Differ by 1	Show rationale LLM Multiple existing precompiles have their gas schedules modified, which is the explicit score-2 anchor. Functional behavior is specified as equivalent, so score 3 is not assigned on the sealed text. Human The behavior of three pre-existing precompiles changes: ordinary EVM pricing (measured: small-input MODEXP ~6.6×, `rounds`-priced BLAKE2f callers out-of-gas, and an inverse case where the EIP-7883 formula exceeds the transaction gas cap but the EVM version succeeds), different invalid-input returndata, and loss of EIP-2929 pre-warming at the retired addresses — the last unstated by the EIP and measured as 198 flipped executions.
Added system contracts	2	1	+1	Differ by 1	Show rationale LLM Three protocol-installed EVM contracts are added, satisfying the multiple system-contract condition for score 2. None is specified as stateful or as triggering a new system action. Human Three stateless code deposits appear at the retired addresses, but nothing in the protocol ever invokes them as system actors; the deployment act is scored under "New fork activation mechanism" and their behavioral surface under "Edge/boundary conditions".
EVM Gas rule changes	1	0	+1	Differ by 1	Show rationale LLM Three existing special gas schedules are replaced by the existing EVM execution-accounting mechanism. This updates gas accounting but does not introduce a new metering mechanism, matching score 1. Human No gas accounting mechanism changes: the precompile-specific price tables disappear with the precompiles, and the pricing shift is the "Modified precompiles" row's substance.
New invariant on pre-existing tests	1	0	+1	Differ by 1	Show rationale LLM The new fork state gives activation-focused pre-existing tests a narrow new assertion at three addresses. The snapshot does not require every unrelated post-fork test to assert it. Human No rationale recorded.
New test-framework primitives	0	1	−1	Differ by 1	Show rationale LLM The snapshot identifies no expectation type, modifier, helper, or permanent framework abstraction, so score 0 is the package-grounded result. Human Existing primitives suffice with minor extension: a fork precompile-list subtraction and code pre-allocation at the retired addresses.
Security risks	3	2	+1	Differ by 1	Show rationale LLM The activation transition, ordinary EVM execution, gas behavior, and three existing cryptographic interfaces all interact. Incorrect equivalence can cause consensus divergence or user-contract failure, requiring extensive review, differential testing, and fuzzing across multiple critical components. Human Consensus-critical bytecode replaces natively audited implementations; an implementation error is a consensus split. The measured BLAKE2f flag divergence is this risk realized in the current candidate bytecode — differential fuzzing against the retired implementations is mandatory.
Performance risks	2	1	+1	Differ by 1	Show rationale LLM Performance must be validated both for individual bytecodes and their effect on existing precompile workloads and client EVM execution. The impact is not fully established in isolation but is confined to three call targets on the package evidence, matching score 2. Human Three pure functions, fully benchmarkable in isolation; gas now scales with actual work (large-input MODEXP prices itself out rather than underpricing compute), and the benchmark-suite re-derivation is test rework, not client performance risk.
Cryptography	2	1	+1	Differ by 1	Show rationale LLM Multiple well-known cryptographic mechanisms must be reimplemented and equivalence-tested in a new execution form. This matches the multiple well-known mechanisms at score 2; no novel cryptography is introduced. Human Nothing cryptographically new enters consensus: three well-known functions are reimplemented, and vast existing vector sets make the reimplementations differentially provable; the proving burden itself is scored under "Edge/boundary conditions".
Added opcodes	0	0	0	Agree	Show rationale LLM No opcode is introduced. Human No rationale recorded.
Modified opcodes	0	0	0	Agree	Show rationale LLM No pre-existing opcode result rule is modified or deprecated. The CALL-family dispatch reaches code instead of a precompile, but the target functionality is required to remain equivalent and gas changes are scored separately. Human No rationale recorded.
Added precompiles	0	0	0	Agree	Show rationale LLM The proposal removes native precompile treatment rather than adding a precompile. Human No rationale recorded.
Modified system contracts	0	0	0	Agree	Show rationale LLM The direct changes are accounted for as added system contracts and modified precompiles. The package identifies no pre-existing system contract that is modified. Human No rationale recorded.
State-access ordering within opcode execution	0	0	0	Agree	Show rationale LLM No opcode state-access or gas-charge ordering rule is modified. The fork-time code write is an activation transition, not an ordering change inside opcode execution. Human No rationale recorded.
Blob gas accounting changes	0	0	0	Agree	Show rationale LLM No blob gas accounting rule is introduced or modified. Human No rationale recorded.
State gas accounting changes	0	0	0	Agree	Show rationale LLM A fork activation state change is present, but the rubric's state-gas accounting mechanisms are not changed. Human No rationale recorded.
New EVM gas refund	0	0	0	Agree	Show rationale LLM No new gas-refund mechanism is introduced. Human No rationale recorded.
New transaction types	0	0	0	Agree	Show rationale LLM No transaction type is introduced. Human No rationale recorded.
New or modified transaction validity mechanisms	0	0	0	Agree	Show rationale LLM Internal execution may run out of gas under a fixed-gas call, but transaction admission, validity, and intrinsic gas are unchanged. Human No rationale recorded.
New block / header fields	0	0	0	Agree	Show rationale LLM No new block or header field is introduced. Human No rationale recorded.
Encoding changes (RLP/SSZ)	0	0	0	Agree	Show rationale LLM No transaction, block, or interface encoding is changed. Human No rationale recorded.
Block syncing changes	0	0	0	Agree	Show rationale LLM No block RLP validation mechanism is introduced. Human No rationale recorded.
New fork activation mechanism	3	3	0	Agree	Show rationale LLM The rubric assigns score 3 when state is modified at the fork activation block. This proposal performs three explicit code-state modifications then. Human Code is written to three addresses at the start of the activation block — a protocol-mandated install with no deploying transaction, implemented in the prototype through the spec's irregular-state-transition hook (the EIP-8141 expiry-verifier pattern: code only, nonce and balance preserved) plus a genesis pre-allocation for test fixtures.
Engine API changes	0	0	0	Agree	Show rationale LLM No Engine API change is specified. Human No rationale recorded.
Transition-tool interface changes	0	0	0	Agree	Show rationale LLM Fork-block awareness is required operationally, yet no modification or new field in the transition-tool interface is specified, so the documented interface-change score is 0. Human No rationale recorded.
Patterns affecting pre-existing tests	2	2	0	Agree	Show rationale LLM Existing vectors for three distinct precompiles require new execution and gas baselines. The affected tests are considerable but localized to the contrived category of calls to these three addresses, matching score 2. Human Measured: an EELS prototype flips 948 fixture executions across 40 functions — spread from byzantium through osaka plus the ported static suites, but all within one well-scoped category: tests that exercise the three retired precompiles. Every flip has been diagnosed (gas drift in both directions, invalid-input semantics, warm-set loss): none is unexplained.
Edge/boundary conditions	3	3	0	Agree	Show rationale LLM Three distinct variable-input mechanisms expose multiple boundaries, and MODEXP length combinations plus BLAKE2f length, flag, and round boundaries require an elevated case set. This matches score 3. Human The equivalence surface is the full input domain of three functions: lengths, invalid encodings, and gas boundaries. Measured: the prototype bytecode already diverges on one edge — BLAKE2f's final-block flag `0x02` is accepted where EIP-152 requires rejection — and invalid inputs revert with `Error(string)` where the precompiles return empty revert data.
Unspecified behavior requiring cross-client consensus	3	3	0	Agree	Show rationale LLM Clients cannot derive the activation state, exact gas results, or executable edge behavior from the snapshot. Newly deployed code bytes and their behavior are consensus-critical and must be agreed before vectors can be baselined, matching score 3. Human The consensus artifact itself is unspecified: the EIP ships without the deployment bytecode, with TODO gas tables and TODO test cases. The prototype pins the runtime artifacts from eth-act/evmification's own CI; an independent compile reproduced every executable byte but differed in the CBOR metadata trailer — precisely the divergence that becomes a consensus split unless the EIP pins the exact bytes by hash. Every revision of the eventual bytecode re-baselines the whole differential corpus.

Compare EIP-8200 with other assessments All Hegotá assessments

Criterion legend and glossary

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

EVM surface

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

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

Gas and accounting

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

EVM Gas rule changes
New EVM gas accounting rules
Score anchors
0
No gas accounting changes.
1
Existing gas accounting mechanism is updated.
2
A new gas accounting mechanism is introduced but it does not affect existing mechanisms nor does it affect existing tests.
3
A new gas accounting mechanism is introduced and affects existing mechanisms which in turn affect existing tests.
ORD
State-access ordering within opcode execution · 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.