Retrospective Fork Evaluation
Osaka / Fusaka
8 Execution Layer EIPs were included by the evaluation cutoff, with a predicted complexity score sum of 105. Another 4 EIPs were added later, contributing 35 to the final-scope total of 140.
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.
Composition table: points per criterion and fork
| Criterion | By cutoff | Added later |
|---|---|---|
| Added opcodes | 0 | 1 · 3% · 1 EIP |
| Added precompiles | 1 · 1% · 1 EIP | 0 |
| Modified precompiles | 3 · 3% · 2 EIPs | 0 |
| EVM Gas rule changes | 3 · 3% · 3 EIPs | 1 · 3% · 1 EIP |
| Blob gas accounting changes | 2 · 2% · 2 EIPs | 0 |
| New or modified transaction validity mechanisms | 2 · 2% · 1 EIP | 0 |
| Encoding changes (RLP/SSZ) | 6 · 6% · 2 EIPs | 0 |
| Block syncing changes | 1 · 1% · 1 EIP | 1 · 3% · 1 EIP |
| New fork activation mechanism | 3 · 3% · 1 EIP | 3 · 9% · 1 EIP |
| Patterns affecting pre-existing tests | 11 · 10% · 8 EIPs | 2 · 6% · 2 EIPs |
| New invariant on pre-existing tests | 1 · 1% · 1 EIP | 0 |
| New test-framework primitives | 2 · 2% · 1 EIP | 0 |
| Security risks | 13 · 12% · 7 EIPs | 7 · 20% · 4 EIPs |
| Performance risks | 13 · 12% · 7 EIPs | 6 · 17% · 4 EIPs |
| Edge/boundary conditions | 17 · 16% · 8 EIPs | 6 · 17% · 4 EIPs |
| Cryptography | 3 · 3% · 2 EIPs | 0 |
| Cross-EIP interactions | 12 · 11% · 7 EIPs | 3 · 9% · 2 EIPs |
| Unspecified behavior requiring cross-client consensus | 12 · 11% · 7 EIPs | 5 · 14% · 3 EIPs |
| Total | 105 | 35 |
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.
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…
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…
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 opcodesIntroduces new opcodes
- Modified opcodesModifies pre-existing opcodes
- Added precompilesIntroduces new precompiles
- Modified precompilesModifies pre-existing precompiles logic or gas-accounting
- Added system contractsIntroduces new system contract, stateful or not
- Modified system contractsModifies pre-existing system contracts
Gas and accounting
Execution, blob, and state gas rules, refunds, and where charges happen inside opcodes.
- EVM Gas rule changesNew EVM gas accounting rules
- State-access ordering within opcode execution · Checklist revision 2 onlyChanges *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 changesNew Blob gas accounting rules which potentially affect pre-existing tests
- State gas accounting changes · Checklist revision 2 onlyNew 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 refundNew gas-refund mechanism
Blocks, transactions, and encoding
Transaction types and validity, block and header fields, encodings, syncing, and activation-time changes.
- New transaction typesIntroduces a new transaction type
- New or modified transaction validity mechanismsCreates new or modifies pre-existing transaction types' validation mechanisms
- New block / header fieldsIntroduces new block or block header fields
- Encoding changes (RLP/SSZ)Introduces encoding changes at the transaction/block/interfaces level
- Block syncing changesModifies block RLP validation mechanisms that require test client syncing.
- New fork activation mechanismModifies state, internal variables, or similar, at the fork activation block
Client interfaces
Engine API and transition-tool interface changes.
- Engine API changesIntroduces new fields to the Engine API directives
- Engine API encoding changes · Checklist revision 1 onlyEngine API encoding changes (the revision-1 template defines no anchor text for this row).
- Transition-tool interface changesModifies 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 testsImplements a new validation mechanism or rule that translates in reworking pre-existing tests
- New invariant on pre-existing tests · Checklist revision 2 onlyTests 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 onlyRequires 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 risksIntroduces or modifies mechanisms that could compromise the security of the chain, users, validators, or other stakeholders, if not implemented properly.
- Performance risksIntroduces or modifies mechanisms and requires performance validation.
- Edge/boundary conditionsFeature contains edge/boundary conditions.
- CryptographyIntroduces 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 interactionsIntroduces or modifies mechanisms that affect other EIPs in either the same or past forks.
- Unspecified behavior requiring cross-client consensus · Checklist revision 2 onlyThe 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.