Overview and framing

The Ethereum Foundation published a forward-looking engineering strawmap that sequences seven planned protocol forks and ties them to measurable performance and cryptography goals. Presented in public commentary by core researchers and leaders, the artifact reframes upgrades as an explicit dependency graph: checkpoints must land in sequence because latency compression, data-availability work, and post-quantum (PQ) transitions interact across consensus, execution and client tooling. By making those interlocks visible, the Foundation aims to move the community from ad-hoc debates to coordinated implementation and capacity planning.

Technical objectives and numeric targets

The strawmap names five headline objectives: fast L1 (sharper slot and finality cadence), gigagas L1 (order-of-magnitude L1 throughput through zk-based proving and on-chain-friendly execution), teragas L2 (very high bandwidth data availability for rollups), Post‑Quantum L1 (hash-based, PQ-safe signature transitions), and Private L1 (native shielded transfers). Explicit numeric aims in the document include a stepwise slot cadence reduction (illustrative path from ~12s toward single-digit seconds through intermediate steps) and finality compression into the low-seconds band. Throughput goals are similarly ambitious: the paper frames an L1 target on the order of ~10,000 tps via heavy zk-prover coupling, and L2 DA ambitions that scale into the millions of transactions per second when sampling and bandwidth scale (the strawmap cites 1 GB/s DA bandwidth as an illustrative teragas-class objective).

Near-term coordination versus long-range sequencing

A notable tension in public materials is horizon: the strawmap documents a chained sequence laid out through 2029, yet Foundation commentary and developer planning also emphasize nearer-term coordination points — most visibly the H1 2026 “Glamsterdam” window and later named upgrade windows — to stage interlocking work. Reconciling these views: the strawmap should be read as a dual-horizon instrument that records both a long-range dependency plan and a set of nearer-term, operational coordination milestones. In practice this means specific forks may be paced into the 2026–2029 interval, with Glamsterdam acting as an early integration and capacity checkpoint rather than the entirety of the program’s endpoint.

Post-Quantum, EIPs and ecosystem workstreams

The Foundation has formalized a cross-client PQ program with recurring core-dev calls, multi-client devnets and prototype tooling; its working assessment of progress is roughly ~20% overall with substantial variance by subsystem. Candidate mitigations to limit gas, bandwidth and storage impact include precompiles, signature aggregation, account-abstraction patterns and ZK-based compression, alongside staged emergency migration playbooks (including ZK-assisted ownership proofs). Parallel specification work referenced in planning conversations includes inclusion-oriented proposals (filed discussions around EIP-7805/FOCIL) and account-abstraction upgrades (e.g., EIP-8141) that together aim to improve wallet ergonomics and reduce reliance on off-chain intermediaries.

Operational and market implications

If the strawmap’s chain of changes moves forward, infrastructure demand will change materially. Shorter slots, lower finality windows and larger blocks raise propagation, memory and prover requirements for validators, sequencers and node operators; simultaneous PQ transitions expand key-management and verification costs. This creates a non-linear increase in demand for low-latency prover stacks, high-throughput DA providers and PQ-capable custody services. The Foundation signals follow-on gas-limit work to materially lift the protocol’s compute ceiling (working targets push past 100,000,000 gas in some planning threads, with community conversations floating higher values), which further amplifies node resource pressure.

Risks, mitigations and governance

The roadmap reduces uncertainty by documenting dependencies, but it also concentrates risk: faster cadence and higher throughput can magnify fork-choice instability if propagation and PQ tooling lag, and inclusion-enforcement proposals raise governance and legal questions about validator obligations. The Foundation’s pragmatic mitigations — multi-client devnets, staged precompiles, formal verification and emergency migration playbooks — are intended to limit those outcomes, but success depends on synchronous progress across propagation engineering, PQ verification optimization, and wallet/hardware readiness.