EPF7 applications are open. Deadline is May 13.
If you want to work on core Ethereum protocol — client development, testing, specs, research — this is the program for you.
Introducing strawmap, a strawman roadmap by EF Protocol.
Believe in something. Believe in an Ethereum strawmap.
Who is this for?
The document, available at strawmap[.]org, is intended for advanced readers. It is a dense and technical resource primarily for researchers, developers, and participants in Ethereum governance. Visit ethereum[.]org/roadmap for more introductory material. Accessible explainers unpacking the strawmap will follow soon™.
What is the strawmap?
The strawmap is an invitation to view L1 protocol upgrades through a holistic lens. By placing proposals on a single visual it provides a unified perspective on Ethereum L1 ambitions. The time horizon spans years, extending beyond the immediate focus of All Core Devs (ACD) and forkcast[.]org which typically cover only the next couple of forks.
What are some of the highlights?
The strawmap features five simple north stars, presented as black boxes on the right:
→ fast L1: fast UX, via short slots and finality in seconds
→ gigagas L1: 1 gigagas/sec (10K TPS), via zkEVMs and real-time proving
→ teragas L2: 1 gigabyte/sec (10M TPS), via data availability sampling
→ post quantum L1: durable cryptography, via hash-based schemes
→ private L1: first-class privacy, via shielded ETH transfers
What is the origin story?
The strawman roadmap originated as a discussion starter at an EF workshop in Jan 2026, partly motivated by a desire to integrate lean Ethereum with shorter-term initiatives. Upgrade dependencies and fork constraints became particularly effective at surfacing valuable discussion topics. The strawman is now shared publicly in a spirit of proactive transparency and accelerationism.
Why the "strawmap" name?
"Strawmap" is a portmanteau of "strawman" and "roadmap". The strawman qualifier is deliberate for two reasons:
1. It acknowledges the limits of drafting a roadmap in a highly decentralized ecosystem. An "official" roadmap reflecting all Ethereum stakeholders is effectively impossible. Rough consensus is fundamentally an emergent, continuous, and inherent uncertain process.
2. It underscores the document's status as a work-in-progress. Although it originated within the EF Protocol cluster, there are competing views held among its 100 members, not to mention a rich diversity of non-EFer views.
The strawmap is not a prediction. It is an accelerationist coordination tool, sketching one reasonably coherent path among millions of possible outcomes.
What is the strawmap time frame?
The strawmap focuses on forks extending through the end of the decade. It outlines seven forks by 2029 based on a rough cadence of one fork every six months. While grounded in current expectations, these timelines should be treated with healthy skepticism. The current draft assumes human-first development. AI-driven development and formal verification could significantly compress schedules.
What do the letters on top represent?
The strawmap is organized as a timeline, with forks progressing from left to right. Consensus layer forks follow a star-based naming scheme with incrementing first letters: Altair, Bellatrix, Capella, Deneb, Electra, Fulu, etc. Upcoming forks such as Glamsterdam and Hegotá have finalized names. Other forks, like I* and J*, have placeholder names (with I* pronounced "I star").
What do the colors and arrows represent?
Upgrades are grouped into three color-coded horizontal layers: consensus (CL), data (DL), execution (EL). Dark boxes denote headliners (see below), grey boxes indicate offchain upgrades, and black boxes represent north stars. An explanatory legend appears at the bottom.
Within each layer, upgrades are further organized by theme and sub-theme. Arrows signal hard technical dependencies or natural upgrade progressions. Underlined text in boxes links to relevant EIPs and write-ups.
What are headliners?
Headliners are particularly prominent and ambitious upgrades. To maintain a fast fork cadence, the modern ACD process limits itself to one consensus and one execution headliner per fork. For example, in Glamsterdam, these headliners are ePBS and BALs, respectively.
(L* is an exceptional fork, displaying two headliners tied to the bigger lean consensus fork. Lean consensus landing in L* would be a fateful coincidence.)
Will the strawmap evolve?
Yes, the strawmap is a living and malleable document. It will evolve alongside community feedback, R&D advancements, and governance. Expect at least quarterly updates, with the latest revision date noted on the document.
Can I share feedback?
Yes, feedback is actively encouraged. The EF Protocol strawmap is maintained by the EF Architecture team: @adietrichs, @barnabemonnot, @fradamt, @drakefjustin. Each has open DMs and can be reached at first.name@ethereum[.]org. General inquiries can be sent to strawmap@ethereum[.]org.
Smart Node now supports @Commit_Boost as of v1.19.3.
Commit-boost is open-source software that is fully compatible with MEV-Boost protocol, but comes with new features and allows node operators to opt in to commitment systems eg preconfimations.
We've been working with @kevaundray and @ladislaus0x from @ethereumfndn and @donnoh_eth from @l2beat on a proof of concept of EIP-8079 (native rollups) using @ethrex_client.
Native rollups reuse Ethereum's own execution to verify L2 state transitions. No ZK circuits, no fraud proofs, no complex proof systems to maintain. Every L1 upgrade is automatically inherited. Any bug in the verification is also a bug in Ethereum itself.
The demo shows a full end-to-end native rollup:
- L2 blocks settled to L1 via the EXECUTE precompile
- L1→L2 deposit
- Contract deployment and cross-layer calls
- L2→L1 withdrawal with MPT proof claim
- Blockscout verifying EXECUTE precompile calls on L1
Try it yourself. Instructions in the PR below.
🆕 EIP-7702 Delegated Address Label on Address Page
An authority EOA’s delegated address now appears as a label on the Address Page, with status indicators for:
✅ - Verified contract
❌ - Unverified contract or EOA
⚠️ - Suspicious address
Now that ZKEVMs are at alpha stage (production-quality performance, remaining work is safety) and PeerDAS is live on mainnet, it's time to talk more about what this combination means for Ethereum.
These are not minor improvements; they are shifting Ethereum into being a fundamentally new and more powerful kind of decentralized network.
To see why, let's look at the two major types of p2p network so far:
BitTorrent (2000): huge total bandwidth, highly decentralized, no consensus
Bitcoin (2009): highly decentralized, consensus, but low bandwidth - because it’s not “distributed” in the sense of work being split up, it’s *replicated*
Now, Ethereum with PeerDAS (2025) and ZK-EVMs (expect small portions of the network using it in 2026), we get: decentralized, consensus and high bandwidth
The trilemma has been solved - not on paper, but with live running code, of which one half (data availability sampling) is *on mainnet today*, and the other half (ZK-EVMs) is *production-quality on performance today* - safety is what remains.
This was a 10-year journey (see the first commit of my original post on DAS here: https://t.co/Fa0jKFgObW , and ZK-EVM attempts started in ~2020), but it's finally here.
Over the next ~4 years, expect to see the full extent of this vision roll out:
* In 2026, large non-ZKEVM-dependent gas limit increases due to BALs and ePBS, and we'll see the first opportunities to run a ZKEVM node
* In 2026-28, gas repricings, changes to state structure, exec payload going into blobs, and other adjustments to make higher gas limits safe
* In 2027-30, large further gas limit increases, as ZKEVM becomes the primary way to validate blocks on the network
A third piece of this is distributed block building.
A long-term ideal holy grail is to get to a future where the full block is *never* constituted in one single place. This will not be necessary for a long time, but IMO it is worth striving for us at least have the capability to do that.
Even before that point, we want the meaningful authority in block building to be as distributed as possible. This can be done either in-protocol (eg. maybe we figure out how to expand FOCIL to make it a primary channel for txs), or out-of-protocol with distributed builder marketplaces. This reduces risk of centralized interference with real-time transaction inclusion, AND it creates a better environment for geographical fairness.
Onward.
New Report 🚀 The Future of Financial Infrastructure: Ethereum’s Layer 2 Landscape
Today we’re releasing a comprehensive analysis of how Ethereum L2s will transform institutional finance: From scalability and privacy to compliance, settlement, and global market structure.
Cowritten with @Nethermind and @l2beat.
https://t.co/lGFOvu92uU
Fusaka is ready for mainnet 🌃🎉!
It will activate at slot 13,164,544, on December 3, 2025, 21:49:11 UTC. The fork introduces PeerDAS, a significant scaling milestone, as well as a slew of other EIPs. More info below 👇
great progress in the past few weeks & ERC-8004 is now officially under Review!
thanks to everyone who contributed. now it's time to build together 🤝🚀
📝 Preconfs in the Press
“With Phase 1 preconfirmations delivering ~2s transaction times, developers are rethinking what’s possible on-chain.”
Catch the @CCNDotComNews article by @GiuseppeFabioC1 featuring our Director of Engineering @gusgonzalezs on how Taiko is tackling Ethereum’s trilemma:
8/
Preconfirmations Are Live on Taiko! 🥁
20–30x faster. Same Ethereum values. Taiko Alethia mainnet just leveled up. This massive upgrade boosts our network’s performance without compromising Ethereum’s core principles.
The new era of Taiko begins today!
Pectra is live. Consolidation is real.
The validator landscape is changing — now.
Join our 30-min webinar for institutional stakers.
Thursday | 1:00 PM CET
Validator ROI, PRR, fee compression.
Register Now 🔗 https://t.co/kykvccOQ4C