Shanghai / Shapella
4 EIPs by cutoff · score 65
1 added later (+3)
Not available No human checklists
View fork →Complexity Evaluations
Forks
Five retrospective fork evaluations of Execution Layer complexity and one forward-looking Execution Layer complexity evaluation for Hegotá. Each retrospective bar is normalized to its fork's total and shows what kind of complexity dominated; the totals differ in scale and are printed beside each bar. Hegotá is still being assessed, so its total is not shown here.
Cancun / Dencun
5 EIPs by cutoff · score 126
1 added later (+9)
Not available No human checklists
View fork →Prague / Pectra
8 EIPs by cutoff · score 216
3 added later (+38)
Not available No human checklists
View fork →Osaka / Fusaka
8 EIPs by cutoff · score 105
4 added later (+35)
Not available No human checklists
View fork →Amsterdam / Glamsterdam
13 EIPs by cutoff · score 243
2 added later (+44)
12 of 15 EIPs have a scored Human checklist
View fork →Hegotá
46 candidates at the 2026-08-26 snapshot · score TBD
Fork scope and assessments are still in progress; totals are not final.
In progress Human checklists scored for 25 of 46 EIPs so far · open assessment pull requests
View fork →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.