One of the most consequential decisions in Ethereum governance is selecting the flagship feature for network upgrades. Billions of dollars are at stake, literally. Moreover, every decision we make constrains our future design space and indecisiveness carries real costs because Ethereum doesn’t exist in isolation. If we falter, by prioritizing the wrong things or failing to execute, we risk ceding ground to ecosystems with very different values.
Ensuring we pick the right “headliners” for hard forks is therefore the single most important responsibility AllCoreDevs has to optimize around. We shouldn’t merely evaluate proposals by whether they are beneficial or not, but justify their value relative to other efforts to scale, harden, or simplify Ethereum.
This post builds on my previous proposal, Reconfiguring AllCoreDevs, by assessing Ethereum governance through this lens and suggesting practical improvements to our decision-making processes, specifically around aligning on the core focus and headline features for hard forks.
Note that this is my individual perspective: it should not be treated as the “EF opinion” or "AllCoreDevs consensus.” I fully expect, and welcome, differing opinions from across the Ethereum community!
Rough (Community) Consensus
Ethereum’s governance philosophy is inspired by the Internet Engineering Task Force (IETF), notably the concept of “rough consensus”, whose subtleties are well articulated in RFC 7282. In short, rough consensus aims to pragmatically iterate towards solutions all stakeholders can accept, even if imperfect, while carefully considering all informed opinions. At its best, it produces higher quality solutions through a legitimate process, while rejecting Kings, Presidents and Shahs.
“Again, coming to consensus is not the goal in itself. Coming to consensus is what we do during our processes to arrive at the best solution. In particular, “declaring” consensus is not an end goal. Attempts to declare consensus at the end of a discussion just for the sake of being able to say that there is consensus often get us back into the voting mentality that we’re trying to avoid.” — RFC 7282
Ethereum’s approach has historically centered around core developers’ consensus, which implicitly assumes broader community alignment. However, core devs, while responsible for writing the code that secures the Ethereum network, do not have a monopoly on it. Ethereum’s governance structure includes many more stakeholders, from node operators, to application developers, users, and more.
To remain legitimate, especially as the ecosystem matures, AllCoreDevs’ decisions must actively consider and align with the broader Ethereum community.If we fail to achieve and clearly communicate this alignment, we risk stakeholders moving from “voice” to “exit,” either through contentious upgrades or gradual migration to competing ecosystems.
Rough consensus amongst core devs, though necessary, is thus insufficient… For major protocol changes, we need clear, documented consensus from affected stakeholders across Ethereum. If complete consensus isn’t achievable, we should at least transparently document dissenting opinions and explain clearly why we’ve accepted certain trade-offs.
Doing this will help ensure Ethereum continues to deliver meaningful improvements through a legitimate process.
EOF & Fusaka
This context hopefully explains my rationale for unconventionally removing EOF from Fusaka.
Different variants of EOF have been proposed, included, and subsequently removed from network upgrades over the years (see Shanghai, Dencun), often reflecting shifting consensus about its urgency relative to other core features. Last year, EOF was scheduled for the Pectra upgrade until the fork was split to minimize scope, moving both PeerDAS and EOF into Fusaka.
While core developers broadly supported EOF, even then some expressed strong opposition. EOF champions diligently worked to address these objections, expanding technical specifications and modularizing proposals for clearer decision-making. At the same time, it became increasingly clear across the Ethereum community that shipping PeerDAS needed to be the priority for Fusaka.
As implementation continued, complexity concerns re-emerged from multiple stakeholders across the Ethereum stack. Core developers reaffirmed EOF’s inclusion in Fusaka at ACDE 208, explicitly backing the most comprehensive version of EOF. However, numerous ecosystem participants continued voicing objections on grounds ranging from specific design choices to broader concerns about complexity, ecosystem fragmentation, and allocation of scarce engineering resources.
Shortly before ACDE#210, some core developers realized that their preferred EOF Option (Option A) had unexpectedly significant negative developer experience consequences. While these had been flagged before, their magnitude hadn’t been fully appreciated. Client teams agreed to urgently review these implications and resolve them by the next Testing/Interop #34 call.
On that call, client teams and ecosystem participants generally agreed to move forward with a different, less comprehensive EOF version (Option D). However, towards the end of the call, it became apparent that there was still uncertainty about the implications of that version, with the Reth team becoming strongly opposed once they better understood the interactions with legacy contracts. This general confusion so late in the process and extreme shifts in opinions were the final data points that ultimately led me to remove EOF’s SFI designation for Fusaka.
I recognize a late removal negatively impacts the perceived legitimacy of our current governance process. However, strictly following “the letter” of our current approach, by keeping EOF despite significant unresolved concerns, would have violated the spirit of the more inclusive governance we want to evolve towards.
Put another way, considering only the call where EOF was ultimately removed paints a very different picture than taking a more holistic view of the process, one where:
- Decisions on upgrade headliners are the single most critical output from AllCoreDevs;
- Ethereum’s immutability means changes are essentially permanent, requiring conservative caution against inclusion of potentially regrettable complexity;
- EOF repeatedly struggled to secure robust “rough consensus” within the broader community, even as core developers’ positions shifted over time;
- Community consensus that PeerDAS should be the #1 priority was clear and consistent;
- A more inclusive, structured governance process would likely have highlighted these issues earlier, preventing a last-minute reversal.
Our process ultimately failed in many ways. It failed core developers, who invested time and resources into developing EOF. It failed the broader community, who didn’t feel like they could impactfully communicate their concerns or have a say about the final prioritization decision. It also failed to adequately communicate when and how certain decisions would be taken, adding unnecessary turbulence to an already complex situation, impacting developers’ morale and momentum toward broader EVM improvements.
Going forward, it is critical we agree on a better way to set priorities for network upgrades, one that explicitly and consistently aligns our decision-making with Ethereum’s broader goals to scale, harden, and simplify the protocol. If EOF is indeed Ethereum’s highest priority, this evolved process should help it emerge with a clearer, stronger consensus. If it isn’t, improved prioritization will clarify what truly is, allowing core devs and the broader community to confidently invest their resources in the highest-leverage initiatives for Ethereum’s future.
Selecting Hard Forks’ Focus & Headliner
Again, selecting the flagship feature for a network upgrade is Ethereum’s highest-stakes governance decision. Despite this, our current approach lacks explicit structure for evaluating and prioritizing these critical features. We therefore need a more rigorous, transparent, and community-aligned process.
Below, I propose an approach to make this headliner selection more thoughtful and focused, explicitly welcoming structured input from across the Ethereum community, not just core developers, while upholding AllCoreDevs’s commitment to keeping Ethereum secure.
Defining the Fork Focus
At the outset of each upgrade cycle, AllCoreDevs should clearly define the strategic priority. or “Fork Focus”, of the upcoming fork. This provides a shared, community-aligned goal that guides the evaluation of candidate headliner features.
Defining this Fork Focus should explicitly invite structured input from across Ethereum’s ecosystem. While not necessarily formalized as a standalone artifact, this shared goal should offer strategic clarity and early alignment around priorities.
Illustrative examples of potential Fork Focuses include:
-
Scalability & Lower Fees: Meaningfully increase throughput, lower transaction costs, and unlock new use cases.
-
Developer & User Experience: Simplify protocol complexity, enhance smart contract security, and reduce development friction.
-
Security & Resilience: Strengthen the network’s security posture, enhance attack resistance, and mitigate emerging threats without compromising decentralization or censorship resistance.
Community consensus around the Fork Focus should be actively sought, especially among stakeholders most impacted by the outcome. While AllCoreDevs ultimately owns implementation specifics, clearly defining the Fork Focus should reflect broad, credible input from the community, directly addressing Ethereum’s highest-priority needs.
Converging towards Headliners
Once the Fork Focus is established, we can align on specific headline features. In practice, this will often be an iterative process, where initial proposals further clarify and refine the overall focus. Ultimately, AllCoreDevs must select only one or, at most, two (one per layer) flagship feature(s) per upgrade.
The existing PFI → CFI → SFI framework remains applicable here. Counterintuitively, our technical bar for CFI/SFI status on flagship features may be lower than for regular EIPs, but only if they strongly align with the chosen Fork Focus and enjoy robust community support. Some features (e.g., The Merge) are critical enough to justify an all-in effort despite imperfect initial specifications. Others, such as EOF, may be presented as a set of EIPs, or even non-Core EIPs, like for those related to the gas limit.
Once a feature is declined as a potential headliner, it cannot return as a regular EIP within the same fork cycle to prevent back-door reprioritization.
Headliner proposals (starting at PFI) should be structured explicitly via Ethereum Magicians threads that follow a clear template such as this:
Headliner Proposal Template
-
Summary (ELI5): Concise, plain-language explanation of the proposal, why it matters, and who benefits directly.
-
Detailed Justification:
-
What are the primary and secondary benefits, ideally supported by data or concrete rationale?
-
Clearly articulate “Why now?”—Why should this feature take priority today?
-
Justify this specific approach versus alternative solutions (lower risk, higher value).
-
-
Stakeholder Impact:
-
Positive: Clearly identify beneficiaries and document explicit support.
-
Negative: Identify those potentially negatively impacted, outline objections, and describe mitigations or explain accepted trade-offs.
-
-
Technical Readiness: Clearly assess technical maturity with links to specifications, tests, client implementations, etc.
-
Security & Open Questions: Explicitly document known security risks, open issues, or unclear aspects. Include threat models, preliminary audit plans, or next steps.
This structured selection process explicitly targets major protocol improvements. Smaller, incremental EIPs should continue through the existing lightweight governance process, maintaining agility and minimizing overhead.
Community Input & Iterative Review
It can be challenging for stakeholders outside core developer teams to know when and how deeply to engage with Ethereum governance. To address this, I propose a two-stage community input process—a “barbell” strategy: explicit, structured community engagement at the beginning, paired with a community testnet for validation near the end of the implementation cycle.
Initially, we should actively solicit headliner proposals from across Ethereum’s ecosystem, clearly signaling when community input is most valuable. Using the Headliner Proposal Template outlined above, this structured early input ensures that core developers’ attention is focused on proposals clearly aligned with Ethereum’s strategic priorities. At the end of the implementation cycle, a dedicated ephemeral testnet provides the broader community with an explicit opportunity to practically validate the proposed changes, reserving late-stage objections primarily for critical implementation or security issues.
Review and Decision Mechanics
The selection of hard fork headliners should explicitly integrate with the broader Ethereum upgrade planning cycle laid out in the Reconfiguring AllCoreDevs post. By anchoring headliner selection within the established PFI → CFI → SFI framework and clearly defining its relationship to the restructured AllCoreDevs calls (ACD{E|C} and ACDT), we can provide a clear, predictable governance process.
Here’s how this process would explicitly unfold each cycle:
-
Open Call for Proposals: At the start of each upgrade cycle, as the previous fork approaches final implementation, AllCoreDevs clearly announces an open call for headliner proposals. Champions submit structured proposals asynchronously on Ethereum Magicians, explicitly aligning their proposal with the established Fork Focus.
-
Focused Community Engagement: Core devs, infrastructure teams, Layer 2 projects, application developers, and other stakeholders provide structured feedback, explicitly highlighting their support or concerns. Clearly marking this review window ensures stakeholders know precisely when their input can be most impactful, incentivizing high-quality, well-articulated responses.
-
Async & Sync Reviews: Proposals initially undergo asynchronous reviews, allowing champions to refine their ideas based on structured community input. These refined proposals are then presented and debated synchronously during dedicated ACD{E|C} roadmap planning calls, enabling direct clarification and focused debate.
-
Iterative Refinement & Last Call: Following synchronous discussions, champions further iterate their proposals based on feedback. A formal “Last Call” asynchronous review provides a clear final opportunity for comprehensive community assessment.
-
Final Selection & Rough Consensus: Ultimately, AllCoreDevs selects the headliner(s) in a dedicated synchronous call, clearly considering stakeholder input proportional to each group’s impactedness and alignment with Ethereum’s stated Fork Focus. For instance, DeFi-focused changes should explicitly weigh feedback from DeFi teams and users heavily.
Community Testnet
Following headliner selection and initial implementation, a dedicated ephemeral testnet (similar to Mekong) is launched to provide an implementation testing ground for the community. This should be the “Last Call” for the ecosystem to engage with a feature and propose spec changes. After this stage, the expectation is that only substantial security issues or severe unforeseen problems will delay or halt deployment.
Explicitly sequencing decision-making and clearly communicating expectations at each step helps avoid unnecessary turbulence and improves legitimacy. As emphasized in the Reconfiguring AllCoreDevs post, most of this iterative planning and testing will occur in parallel to the previous fork’s implementation, enabling Ethereum to incrementally deliver upgrades without lengthy delays.
Formalizing ACD Working Groups
Ethereum’s biggest upgrades—like EIP-1559, The Merge, and EIP-4844—required years of dedicated work before shipping on mainnet. Most of these efforts emerged from recurring breakout rooms and focused community discussions, often without explicit alignment or clear checkpoints from AllCoreDevs. While this informal approach provides flexibility, it also risks significant resources being spent on ideas that stall or drift from Ethereum’s core priorities.
To address this, I propose formalizing the existing breakout structure into clearly defined Working Groups (WGs): teams explicitly chartered to coordinate longer-term protocol improvements, with regular touchpoints for feedback and alignment with AllCoreDevs.
Working Group Proposals
Teams seeking to formalize existing breakout rooms or initiate new Working Groups would submit a lightweight proposal closely following the Headliner Proposal Template. Unlike headliner proposals, WG proposals explicitly target future network upgrades rather than immediate inclusion in the next hard fork.
These proposals provide an important mechanism for Working Groups to receive early strategic alignment from AllCoreDevs, without restricting independent experimentation or development outside formal endorsement.
AllCoreDevs Endorsement
AllCoreDevs would review active Working Groups shortly after each headliner selection to ensure ongoing alignment. This endorsement serves as a “lightweight CFI,” clearly signaling that a WG aligns with Ethereum’s strategic priorities. A rare explicit rejection would indicate that an effort is misaligned or premature.
Practically, endorsed Working Groups would receive visibility on Ethereum’s protocol calendar and dedicated space within the GitHub /pm repository. Efforts not explicitly rejected or endorsed may continue informally, but without formal calendar representation or ACD visibility.
Regular Check-ins
Endorsed Working Groups provide concise, periodic updates to AllCoreDevs, ideally timed just after each fork’s headliner selection. These check-ins confirm ongoing alignment, validate approaches, and offer opportunities for early course correction.
Check-ins should remain lightweight and strategic, not bureaucratic. Working Groups briefly share progress updates, highlight significant milestones, and explicitly raise critical questions or risks. ACD’s role is simply to reaffirm strategic alignment, provide targeted feedback, or suggest necessary adjustments.
Clear Signaling & Community Confidence
By clearly formalizing Working Groups, providing explicit signals of strategic alignment, and maintaining regular lightweight check-ins, we reduce ambiguity around Ethereum’s long-term roadmap. Independent research and experimentation remain fully encouraged, but formally endorsed Working Groups can confidently allocate resources knowing they have community backing and explicit alignment with Ethereum’s priorities.
This balanced approach addresses previous shortcomings without sacrificing Ethereum’s flexible, community-driven culture.
Where We Go From Here
Ethereum governance decisions carry uniquely high stakes. Billions of dollars, the network’s security, and our entire ecosystem’s alignment hinge on each upgrade we deploy. We need clear guardrails to manage these irreversible changes, but also enough flexibility to sustain Ethereum’s pragmatic, community-driven ethos.
The EOF experience clearly highlighted gaps in our current process: ambiguity around the upgrade’s core goal, insufficient structured feedback early on, and unclear checkpoints for major features. Without refining our approach, we risk repeating similar issues—even when everyone involved acts with good intentions.
To address this, I propose we explicitly strengthen our process around these core areas:
-
Establish a clear Fork Focus: At the outset of each upgrade cycle, AllCoreDevs should define and communicate a clear strategic priority informed by community input, providing shared clarity around the upgrade’s core goal.
-
Select at most one Headliner per layer: Using a structured template and the existing PFI → CFI → SFI approach, we ensure rigorous early reviews and explicitly prevent previously rejected proposals from returning as lower-stakes EIPs.
-
Implement the “Barbell” approach to community review: Structured community input at the earliest stage—when changes are still flexible—paired with practical validation through community testnets as a final checkpoint, limiting late-stage objections to security and critical implementation issues.
-
Formalize Working Groups: Provide formal, yet lightweight structure for existing breakout rooms and dedicated working groups, including periodic checkpoints with AllCoreDevs, to ensure long-term efforts remain aligned with Ethereum’s strategic priorities.
-
Document the full governance approach: Clearly document the entire process in one canonical place with clearly defined feedback channels, removing ambiguity about how stakeholders can provide meaningful input.
This framework doesn’t guarantee perfect outcomes. However, it meaningfully reduces uncertainty, strengthens accountability, and preserves Ethereum’s ability to move forward confidently without sacrificing what makes Ethereum unique.
Thank you to everyone who gave feedback, both direct and indirect, on the contents of this post. It was a lot to distill, but your perspectives were extremely helpful 
