Can Execution Layer Complexity Assessments Help Predict Time to Mainnet?

Background

The STEEL team introduced its Execution Layer EIP complexity-assessment methodology during the Amsterdam fork-scoping process to make the difficulty of implementing, testing, coordinating, and shipping the Execution Layer surface of an EIP to mainnet more legible before scope decisions are made.

Testing is frequently the critical path. Before the first devnet, implementing Execution Layer consensus tests and their supporting test frameworks, then ensuring those tests agree with client implementations, is costly. Once devnets begin, interoperability testing across Execution Layer clients, debugging, and repeated integration cycles can dominate the remaining time to mainnet.

Research Question

This study asks whether complexity assessments made from early Execution Layer EIP specifications can help anticipate that broader delivery process. The primary fork-level analysis compares three summaries of predicted Execution Layer complexity with the time from the first devnet running at least two independent Execution Layer clients to mainnet.

A separate EIP-level analysis asks whether predicted Execution Layer complexity tracks two score-blind public-artifact measures: specification rework and newly documented EIP interactions.

What Was Evaluated

The retrospective study contains 49 fork–EIP relationships whose proposals have an Execution Layer surface, including execution-only and cross-layer EIPs, from Shanghai through Amsterdam. Only the Execution Layer surface is scored. Each relationship is assessed from a pinned proposal revision intended to approximate its entry into fork development.

Hegotá is a separate forward-looking evaluation of the 46 proposals listed as PFI, SFI, or CFI in EIP-8081 on 26 August 2026. The original PFI study scored 37 applicable Execution Layer or execution-client networking surfaces; an append-only extension scores the SFI’d EIP-7805 and CFI’d EIP-8141 from the same snapshot. Five Consensus Layer–only proposals and two explicit exclusions are retained as N/A. Its scores were produced with an LLM using the same Execution Layer complexity-assignment rubric, independently of the STEEL team’s ongoing manual assessment work. Hegotá has no observed outcome and never enters the retrospective association analysis.

Research Workflow

Task 01 records fork membership and source history. Tasks 03 and 04 select and review historical proposal horizons. Task 05 creates sealed one-EIP packages and runs isolated assessments. Task 07 defines observed-effort proxies before joining them to scores.

Every derived publication record points back to a repository-relative source path and SHA-256. The publication adapter reads research outputs but cannot modify them.

Evidence Controls

Each assessor received one sealed proposal package, the pinned rubric, and explicitly admitted supporting documents. Network access, repository access, other assessments, implementations, tests, observed outcomes, and aggregate progress were excluded.

Isolation cannot erase latent model knowledge. The study therefore reports package provenance, exposure attestations, under-specification, confidence, and known recovery events instead of claiming perfect blindness.

Scoring Rubric

Twenty-eight Execution Layer criteria produce a primary score and Low, Medium, or High tier. Scores below 12 are Low, 12 through 22 are Medium, and 23 or above are High. The criteria cover gas rules, execution and state behavior, testing surfaces, APIs, encodings, system contracts, opcodes, precompiles, transactions, activation, performance, security, under-specified behavior, and cross-EIP interactions.

The rubric estimates specification-implied Execution Layer complexity. It does not estimate person-hours, cost, severity, importance, Consensus Layer complexity, or probability of inclusion.

Study Design Decisions

The study favors pinned evidence and explicit limitations over a larger but less controlled sample.

The research uses fork–EIP relationships rather than unique EIPs because one proposal can appear in more than one fork context. Consensus Layer–only proposals remain visible but never receive a zero EL score.

Observed-effort metrics were defined score-blind. Correlations remain descriptive: they do not show that complexity caused delay, revisions, coordination, or engineering effort.

Limitations

The results are evidence about a research rubric, not a universal measure of protocol work.

• Complexity scores do not measure person-hours, cost, importance, risk, or causality.
• Fork totals depend on the number of included EIPs and how proposals are split.
• Historical ref selection approximates entry into development and can be imperfect.
• Observed-effort proxies are derived from recorded public artifacts and omit private work.
• Amsterdam is right-censored and potentially in-sample.
• Hegotá is forward-looking, can change after the snapshot, and has no observed outcome.
• Consensus Layer–only work receives no EL score; zero would be misleading.
• Isolation reduces observable hindsight but cannot erase latent model knowledge.