Retrospective Fork Evaluation

Shanghai / Shapella

4 Execution Layer EIPs were included by the evaluation cutoff, with a predicted complexity score sum of 65. Another 1 EIP was added later, contributing 3 to the final-scope total of 68.

Scope timing: The primary retrospective prediction includes only EIPs present by the evaluation cutoff. The later additions remain assessed and reported separately: EIP-6049 (+3).

EIPs by cutoff

score 65

Added after cutoff

+3 · final scope 68

Under-specified at cutoff

2 / 5

Human checklists

Not available

No human complexity assessments were produced for this fork.

Where the Complexity Comes From

Each segment sums one criterion across the fork's scored LLM assessments. Hover or focus a segment for its points, share, and the number of contributing EIPs.

View Absolute complexity (bar length is the fork total) Composition (each fork normalized to 100%)

By cutoff65 points · 4 EIPs

Added later3 points · 1 EIP

Composition table: points per criterion and fork

Shanghai / Shapella: criterion points included by the cutoff and added afterward
Criterion	By cutoff	Added later
Added opcodes	1 · 2% · 1 EIP	0
Modified opcodes	3 · 5% · 1 EIP	3 · 100% · 1 EIP
EVM Gas rule changes	5 · 8% · 3 EIPs	0
State-access ordering within opcode execution	2 · 3% · 1 EIP	0
New or modified transaction validity mechanisms	2 · 3% · 1 EIP	0
New block / header fields	3 · 5% · 1 EIP	0
Encoding changes (RLP/SSZ)	3 · 5% · 1 EIP	0
Block syncing changes	2 · 3% · 1 EIP	0
Engine API changes	1 · 2% · 1 EIP	0
Transition-tool interface changes	1 · 2% · 1 EIP	0
Patterns affecting pre-existing tests	7 · 11% · 4 EIPs	0
New invariant on pre-existing tests	3 · 5% · 1 EIP	0
New test-framework primitives	2 · 3% · 1 EIP	0
Security risks	7 · 11% · 4 EIPs	0
Performance risks	3 · 5% · 2 EIPs	0
Edge/boundary conditions	8 · 12% · 4 EIPs	0
Cross-EIP interactions	7 · 11% · 4 EIPs	0
Unspecified behavior requiring cross-client consensus	5 · 8% · 2 EIPs	0
Total	65	3

Complexity Assessments

LLM rows were automated using the GPT-5.6 Sol LLM at xhigh reasoning effort, evaluating the EIP revision linked in the Assessment Input column against version 2 of STEEL’s complexity-assignment template. Human rows are STEEL reviewers’ published checklists; their status badge links to the pull request or merged report. Select rows from either evaluator to compare them, or open an EIP for its full assessment.

Shanghai / Shapella complexity assessments, one row per evaluator

EIP-3651 Warm COINBASE	Included by cutoff	2026-08-25	LLMChecklist v2	Complete	6	Low	No	Assessed `a6dfa1ed7b`2022-01-30Current master File history
EIP-3855 PUSH0 instruction	Included by cutoff	2026-08-25	LLMChecklist v2	Complete	6	Low	No	Assessed `6caab461df`2021-09-22Current master File history
EIP-3860 Limit and meter initcode	Included by cutoff	2026-08-25	LLMChecklist v2	Complete	23	High	Yes	Assessed `d38a4add0c`2022-02-03Current master File history
EIP-4895 Beacon chain push withdrawals as operations	Included by cutoff	2026-08-25	LLMChecklist v2	Complete	30	High	Yes	Assessed `1ce607ac37`2022-03-11Current master File history
EIP-6049 Deprecate SELFDESTRUCT	Added after cutoff	2026-08-25	LLMChecklist v2	Complete	3	Low	No	Assessed `7c8e7e6eb5`2022-12-20Current master File history

How the Historical Refs Were Selected

These timelines support the assessment table by showing the fork chronology and the revision and inclusion history used to choose each input. They are process evidence, not additional complexity results. Each chart has its own time axis; horizontal positions should only be compared within a chart.

Fork Milestones and Relevant Devnets

Loading interactive chart…

Fork-level scope, devnet, testnet, and activation milestones on an independent time axis.

EIP Revision Histories and Selected Assessment Refs

The main purpose of this panel is to show where the selected assessment ref (REF) falls in each EIP’s revision history. The other traces and markers provide context for that selection. Every EIP row uses the same date scale, shown once above the panel.

Revision traces: the dark line counts substantive post-creation revisions; the faint line counts all revisions.
REF: the immutable EIP revision used for assessment. The amber rule is its proposal anchor.
PFI, CFI, and SFI: recorded fork-inclusion state transitions; open markers retain repeated same-state records.
CUTOFF: the fork-level initial-evaluation horizon. Triangles identify relevant devnets or testnets.

Loading interactive chart…

Aligned EIP revision histories, inclusion-state transitions, selected assessment refs, and the fork evaluation cutoff on one shared time axis.

Criterion legend and glossary

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

EVM surface

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

Added opcodes
Introduces new opcodes
Modified opcodes
Modifies pre-existing opcodes
Added precompiles
Introduces new precompiles
Modified precompiles
Modifies pre-existing precompiles logic or gas-accounting
Added system contracts
Introduces new system contract, stateful or not
Modified system contracts
Modifies pre-existing system contracts

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
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.
Blob gas accounting changes
New Blob gas accounting rules which potentially affect pre-existing tests
State gas accounting changes · Checklist revision 2 only
New state gas accounting rules. State gas is the cost of *writing* state, as opposed to accessing or executing it: `StateGasCosts`, `COST_PER_STATE_BYTE`, the block-level state gas budget, and the spill path into execution gas.
New EVM gas refund
New gas-refund mechanism

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
New or modified transaction validity mechanisms
Creates new or modifies pre-existing transaction types' validation mechanisms
New block / header fields
Introduces new block or block header fields
Encoding changes (RLP/SSZ)
Introduces encoding changes at the transaction/block/interfaces level
Block syncing changes
Modifies block RLP validation mechanisms that require test client syncing.
New fork activation mechanism
Modifies state, internal variables, or similar, at the fork activation block

Client interfaces

Engine API and transition-tool interface changes.

Engine API changes
Introduces new fields to the Engine API directives
Engine API encoding changes · Checklist revision 1 only
Engine API encoding changes (the revision-1 template defines no anchor text for this row).
Transition-tool interface changes
Modifies or adds new fields to the transition tool interface.

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

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.
Performance risks
Introduces or modifies mechanisms and requires performance validation.
Edge/boundary conditions
Feature contains edge/boundary conditions.
Cryptography
Introduces new cryptography mechanisms or modifies existing functionality that involves cryptography

Coordination

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

Cross-EIP interactions
Introduces or modifies mechanisms that affect other EIPs in either the same or past forks.
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.