TL;DR

• I propose reconfiguring AllCoreDevs such that ACDE & ACDC focus on scoping the next hard fork, rather than implementing the current one. In addition to welcoming existing attendees, these calls could more explicitly solicit input from a broader range of community stakeholders.

• To complement this, the existing testing/interop call would formally become “ACDT(esting)”, focused on the current fork’s implementation details, rather than setting its scope, ensuring that resolving technical issues doesn’t compete with high-level feature prioritization.

• With Pectra about to go live, and the Fusaka fork scope scheduled to finalize soon, Glamsterdam presents a good opportunity to test this process. Before then, I propose having a review and feedback period, aiming for a go/no-go decision shortly after Pectra mainnet releases are out.

Context

Early in Ethereum’s history, AllCoreDevs was the only formal governance venue and had a relatively small number of participants. Over the years, it has grown and seen many offshoots emerge, such as ACDC, breakout rooms, community calls, and more. Since The Merge, we’ve gotten better at working on multiple forks in parallel: Dencun was live on devnets as we shipped Shapella, and Fusaka is in a similar situation as we approach Pectra’s mainnet deployment.

However, we now have a more complex process, involving a growing number of stakeholders, which has to agree on and deliver an ambitious roadmap. This has led to a number of growing pains, including:

• Unclear participation expectations: while ad-hoc coordination was sufficient with fewer calls and people, implicit assumptions about participation are no longer sufficient to ensure we have the right people present when making decisions.

• Lack of coherent direction: exclusively relying on a “bottoms up” approach to derive an implementation plan may result in potential mismatches between what should be the focus(es) for protocol development and what actually gets done.

• Community confusion: outside of AllCoreDevs, a growing number of external stakeholders now have either an interest in the outcomes or a desire to participate. If the process is implicit and illegible, this results in friction and confusion for the broader community.

This post proposes changes to the AllCoreDevs process that aim to address these issues, while ensuring that the core principles that guide Ethereum governance — rough consensus, openness and a strong security mindset — are preserved. It is divided in two main sections: Process Design and Implementation Details.

The first outlines high-level desiderata, independent of how they fit into existing structures. The second section explores how this could be implemented in practice, and what some of the open questions are.

Process Design

Roadmap Setting

The most important missing piece in the current AllCoreDevs process is a focus on the high level roadmap (“why we do things”), rather than individual proposals (“what we do”). This is true both for when planning the next fork(s), but also when thinking about Ethereum’s longer-term direction.

Short Term

A short-term roadmapping effort should aim to set the “headline feature” for Ethereum upgrades, making a strong case for its importance, even if no formal EIP exists yet. For example, had such a process existed before Fusaka, it could have framed the upgrade around “increasing the blob count by 2–5x ASAP” and clarified why this was necessary to prevent L2s from turning to alternative DA.

The goal would be to articulate why a feature is important for Ethereum, who benefits from it and to what extent, what core properties of Ethereum does it enhance (e.g. scalability, censorship resistance, UX, etc.) and whether it comes with any tradeoffs.

That said, the security of the network must take precedence over delivering new features. One of Ethereum’s strongest unique differentiators is resilience. We should not compromise on this, even when there is pressure to ship.

Another core property to maintain is Ethereum’s open roadmap process, which invites the community to participate in shaping network upgrades. Getting better alignment on the high-level features for a fork does not mean the community can no longer Propose EIPs for Inclusion, but that these will be considered with the context of having a higher-level objective for the fork.

This results in the following prioritization:

• P0: Network Security. Addressing security issues takes precedence over everything.

• P1: Roadmap “headline feature(s)”. The feature(s) that teams dedicate the majority of their time and attention to during a network upgrade.

• P2: Other EIPs. Weighted against any potential impact to P1. If unexpected issues arise that delay P1, default to removing them from an upgrade.

Long Term

In parallel to improving our short-term roadmapping process, we should improve how we coordinate on Ethereum’s longer term roadmap. To do so, we must agree on what the main tradeoffs are, what solutions are worthwhile to explore, and what specific R&D initiatives are needed to validate or invalidate them. One of the biggest challenges with this work is balancing optionality in a rapidly changing environment with the desire for specific commitments farther in the future.

High quality research is a necessary but insufficient input to this process. To adequately set the long-term trajectory for Ethereum, we need clear venues for discussion and debate to happen, with both technical representation, as well as business, product, and strategy-minded stakeholders.

Ideally, it produces clear records of both the current path forward and its rationale—as well as the decision tree that led us there. This is the standard we hold ourselves to for technical decisions, even those of minor significance, and should be applied to Ethereum’s highest level strategic planning.

While many of the components needed to implement a short-term roadmap process exist today and mostly need “tweaking”, this isn’t true for the long term roadmap. To get there, we can experiment with different approaches and iterate towards a process that is both efficient and legitimate.

Stakeholder Input

The roadmap process requires high-quality input from all parts of the Ethereum community to reach optimal decisions. While core developers excel at evaluating implementation risks, this perspective alone is insufficient. To complement this, we must also evaluate the benefits to users and how a feature aligns with the longer-term evolution of the Ethereum protocol.

For the broader community, engaging with AllCoreDevs can be daunting, time-consuming and prone to opaque feedback loops. It’s unclear what the right entry points are, where and when to pay attention, and whether the input provided is ultimately considered as part of the decision.

A "translation" problem also exists between application and protocol developers, where users’ needs may not be expressed in a way that reflects protocol development constraints. Application developers can’t be expected to have deep protocol expertise to participate effectively in the process. Ideally, they would express needs in their own terms and the AllCoreDevs process would then take responsibility for proposing technical solutions to meet them. To the extent a subset of application developers then want to engage in developing specific solutions, the process would remain open to them, as it always has.

On the research side, topics can take years to properly explore and some of the most important considerations are orthogonal to implementation complexity. Ethereum’s issuance curve is the most extreme example of this. Additionally, it’s possible that urgent and important problems have been identified, but not a solution, and that Ethereum’s main priority should be to come up with an implementation plan. This is how The Merge happened.

The Roadmap process should thus explicitly solicit input from these groups. Beyond inviting their regular participation in calls, we can create ways to allow them to make formal proposals at a higher level of abstraction than EIPs.

For example, there could be a “template” that various stakeholders can use to communicate their preferences as part of the roadmap process, that presents answers to questions such as:

• What is the change the group would like to propose to Ethereum?

  • What is the current state of development for the proposal?

  • Why is now the right time to make this the main priority for Ethereum?

• Why would this change be impactful to them, and the community as a whole?

  • What are quantitative and qualitative ways this would improve Ethereum?

  • Who else explicitly supports the change and what is their role in the Ethereum community?

  • What issues does not having this change currently cause (e.g. bugs, missing user affordances, etc.)?

• What are the biggest tradeoffs and open questions about the change?

Another consideration is how to categorize stakeholders. Breakout calls tend to focus on specific topics but are often attended by the same core group core developers.. Conversely, the community is often segmented into “types” of projects (L2s, DeFi, Wallets, LSTs, etc.), while the most important research considerations often span multiple areas.

Timing is another important question. Is it better if all stakeholders are proactively asked about their priorities, or if their opinion about specific proposals is solicited instead? Which stakeholders are best positioned to give input into major short and long term priorities? How does this affect the current role of core developers in the process?

If poorly designed, this process risks DoS’ing AllCoreDevs. As an example, the Fusaka upgrade currently has over 20 EIPs Proposed for Inclusion, with almost as much already Considered or Scheduled for Inclusion.

Again, given the high uncertainty in all of this, experimenting with different approaches is key to converging on a process that allows stakeholders to feel heard, does not compromise any of Ethereum’s core properties, and runs efficiently.

Network Upgrade Timelines

Here is a tentative timeline of events leading up to a network upgrade using these new processes. To ensure that R&D uncertainties are taken into account, each step is dependent on the previous step, rather than a fixed timeline.

Description, starting from when the “headliner” feature is confirmed (⭐ on diagram):

1. Fork N “headliner” is agreed upon

   • The roadmap process for Fork N agrees on the main feature for the upgrade.

     1. This should happen several months before the previous fork, Fork N-1, is ready for deployment.

   • Other proposals for Fork N start to be reviewed.

   • All teams start allocating resources to the implementation of the Fork N headline feature.

2. Fork N-1 Client Testnet Releases & Testnet Deployment

3. Deadline for Fork N EIP proposals

   • Most proposals are expected to have been shared and reviewed already.

4. Fork N-1 Client Mainnet Releases & Mainnet Deployment

5. Fork N Scope Finalization

   • Any additions to the Fork N scope are agreed to within a few weeks of Fork N-1 going live on mainnet. Beyond this point, only changes to SFI’d EIPs may be considered, as well as security-critical EIPs.

6. Fork N+1 roadmap discussions begin

   • Once the scope for the next upgrade has been finalized, high-level discussions about the priority for the upgrade after that one should begin.

   • Fork N implementation happens in parallel with this.

7. Fork N+1 “headliner” is agreed upon

   • … and the cycle restarts!

Implementation Details

What follows is a proposal for adapting existing processes to the structure described above. A core assumption is that iterating from what exists today towards a new process is more likely to be successful than discarding everything in favor of a new approach.

AllCoreDevs Calls

AllCoreDevs is the highest-profile venue in Ethereum governance. It serves both the purposes of agreeing on upgrades’ scope and working through their implementation. By trying to do both things, it ends up not doing as well as it could on either. Since The Merge, we’ve also been running a weekly testing/interop call for clients, focused more on implementation details for forks.

We can lean into this distinction and make AllCoreDevs the planning venue for the next fork and the existing testing call the venue to discuss implementation details for the current fork. Here are ideas for how we could reframe the calls to achieve this.

ACD{E|C}

• The main output of ACD{E|C} calls becomes be the Meta EIP for a network upgrade

  • Today's Meta EIPs primarily serve as pointers to individual EIPs, with little substantive content. In contrast, a roadmap-oriented ACD could produce Meta EIPs that thoroughly articulate the priority for a network upgrade and clearly explain the rationale behind this prioritization.

    • The Meta EIP would likely be refined in distinct stages, e.g.:

      • Proposals for the high-level focus of the upgrade

      • Agreement on the high-level focus of the upgrade

      • Specific “headliner EIP” selected for the upgrade

      • Open proposals for other EIPs to be included in the upgrade

      • Final scope of the upgrade frozen

        • TBD on how much room this allows for CFI’d, but not SFI’d, EIPs.

  • The rationale for prioritizing something in a network upgrade should not exclusively depend on if an EIP already exists or not. In other words, “technical readiness” is one of the inputs into the decision, but not the only (or main) one.

  • The stages above must take into account the current implementation status of the current fork. For example, while the priority for the next upgrade can be set in parallel with the implementation of the previous fork, the open call for EIPs should happen at a time when client developers actually have bandwidth to review proposals.

• ACD{E|C} must maintain open participation while expanding beyond protocol contributors and raising the quality bar for roadmap discussions.

  • EIPs are neither necessary nor sufficient for this. We need a new “template” by which to evaluate potential changes, that is both flexible enough to accommodate different types of features, but also structured in a way that filters out low-quality proposals. It may be good enough to ask people for “a writeup or presentation” and leave this open-ended. Unlike EIPs, which focus on the “what”, this resource should focus on the “why”.

  • Representatives from different parts of the community should be invited to participate and engage. The scope for Ethereum network upgrades should be set around what provides the most value to the entire community, and not exclusively what client teams would prefer to work on. At the end of the day, client teams are the ones that must come to a consensus about which code to write, but bringing in more sources of input from the community can help inform these decisions.

  • Asynchronous input sources are critical to high quality, open debates. Call time is limited, and live debates are often inefficient at surfacing areas of highest alignment or contention. We need canonical async forums to collect input, rather than rely exclusively on synchronous calls as a source of information. This doesn’t mean moving the ultimate decisions outside the calls, but can help ensure that participants come in with high context and an understanding of the key tradeoffs to work through.

• ACD{E|C} continues to exist with a bias towards the EL/CL, but participation should be expected weekly by at least one roadmap-aware representative from each client team.

  • Aim to resolve any time-sentitive topic on either call, but non-urgent items can default to the EL or CL call based on their domain

    • This implies that all client teams send O(1) representatives who are knowledgeable about the roadmap process to attend both ACD{E+C}, but may have O(N) representatives attend their layers’ call.

  • Outside stakeholders who only care about one layer should mostly be expected to attend that call, with some exceptions in the final stages of roadmap planning.

• ACD{E|C} remains where decisions about EIP inclusions (and exclusions) are made for network upgrades

  • Even though the current fork’s implementation is no longer part of the ACD{E|C} scope, if changes must be made to the EIP set once implementation has started, this decision should be finalized on ACD{E|C}. Changes to included EIPs would not have to go through this process, unless they are so significant that they change the nature of the EIP, or impact the ability to deliver the "headliner EIP” in any way.

ACDT(esting)

• The existing weekly testing/interop gets renamed to “AllCoreDevs Testing” and becomes the main venue to discuss the current fork implementation.

  • Loosely, ACDT would take a network upgrade Meta EIP as “input” and “output” production-ready client implementations.

• All implementers would be expected to attend ACDT — every client team should have O(N) attendees weekly.

  • Client teams can send different representatives to ACDT than ACD{E|C} calls, but we should have sufficient technical representation to resolve nearly all implementation issues that emerge during a fork cycle.

• When upgrades are in their peak implementation period, or if security related or urgent issues arise, ACDT “overflows” into ACD{E|C}.

  • Shipping the current fork is a prerequisite to ship the next one. Opt for pragmatism in achieving this over “perfect” conceptual delineation between calls

Timeline View

Re-using the timeline shared above, topics in the white boxes fall under ACD{E|C}; those in colored boxes shift to ACDT.

Description, starting from when the “headliner” feature is confirmed (⭐ on diagram):

• As ACDT works on the implementation for Fork N-1, ACD{E|C} debate and confirm the headliner for Fork N

  • Open question: should the implementation of headliner features still be tracked in ACD{E|C} until Fork N-1 ships?

• By the time Fork N-1 ships, ACD{E|C} has finalized the scope for Fork N, which moves to ACDT

• As the scope for Fork N finalizes, discussions about potential headliners for Fork N+1 begin in ACD{E|C}

Other Misc. ACD Improvements

• Freeze agenda ~3 days early: for ACD{E|C}, anything non-urgent is added to the agenda at the latest on the Monday before the (Thursday) call.

• Template for EIP PFI proposal: “headliner EIPs” are expected to go through a rigorous vetting process under this new structure. Additional EIPs should also have a strong rationale for inclusion, even if the process is lighter-weight. Ideally, this means PFI’d EIPs do not need to be presented on ACD{E|C} by default.

• DFI, no reason needed: the open EIP process can turn into a DoS on client teams’ attention. To balance this, client teams should use the Declined for Inclusion status liberally. There must not be an expectation that a reason will be provided for rejection. On the other hand, DFI only applies to a specific fork. EIP Champions can re-propose DFI’d EIPs for a future upgrade.

• Better metrics for “protocol resilience”: our desire to increase our shipping capacity must not come at the expense of Ethereum’s long-term sustainability. We should have clear metrics around performance and security that help us balance the urgency of delivering new features with the importance of building resilient software.

Stakeholder Input

The above refocus of AllCoreDevs will be most successful if we have the right set of stakeholders engaging in the process. In practice, this is a mix of client developers with sufficient context to form opinions on the broader Ethereum roadmap, protocol researchers, domain experts from many parts of the community (e.g. L2s, wallets, DeFi, etc.) and more. This latter group is least likely to participate in regular calls, so we should have other means of collecting their inputs, both proactively (e.g. tracking the most common issues experienced onchain) and reactively (clear forums for them to share their issues or suggestions, that then feed into the ACD process).

Breakout Rooms

While very similar in style to AllCoreDevs, breakouts have been useful to engage with more stakeholders about specific issues that require input beyond client developers. This is especially true when going from an initial design to practical implementations, such as for EIP-7702 or FOCIL.

Recurring Protocol Calls

These already happen: recurring protocol calls are a good way to communicate with domain experts adjacent to AllCoreDevs about topics relevant to them, and to bring their input back into ACD. For example, RollCall has been useful to get input from L2s. We now also have Beam Chain calls, and a newly launched Protocol Research Call, who can hopefully serve similar functions.

Community Calls

We’ve sometimes hosted Community Calls intended for a broader audience than protocol contributors (e.g. Shapella, Merge). These have historically been held at the end of the network upgrade process, with an aim to disseminate information (rather than collect input). Hosting such calls early in the upgrade process (or making this part of the ACD{E|C} calls) could be another way to collect input from community members about the priorities for an upgrade.

Application Focused Venues

As mentioned earlier, the AllCoreDevs process has been shaped according to the inputs client devs care about. This can sometimes lead to concerns that don’t neatly fall into these categories being ignored. One potential way to improve this is by creating an open venue for application developers to share their perspectives and protocol-level requests. This could take the form of a call, or more asynchronous venue (see below), but framing it as an “open invitation for applications developers” may help surface needs that are otherwise missed in ACD.

Async Discussion Threads

We’ve had a few experiments trying to collect input on fork priorities using EthMagicians (Prague, Dencun, Shanghai). Similarly, client teams have recently started sharing their views about priorities for network upgrades. While both of these have helped narrow down the list of possible EIPs, they can sometimes miss the forest for the trees.

Whether on Ethereum Magicians or elsewhere, we should create a space for asynchronous discussions about the high-level goal of the next upgrade, centered on the “why” rather than the “how”. This would be the place we send community projects to articulate their needs and problems, with it becoming input for the discussions about the next upgrade.

Documenting the Process

A final consideration to think through is where and how to present the information about this new process. Today, this is spread across the pm repository, EIPs, Ethereum Magicians, and a lot of context only exists in people’s heads. To make things more legible, once we have consensus on an overall path forward, we should explicitly document it. Where and how we do so will depend on the specifics of our decisions, but the pm repo feels like a natural default “landing page”.

Next Steps

To move this proposal forward, I would suggest having an explicit deadline for a “review and comment” period to gather feedback and make changes to this proposal (~2 weeks?). Once async input has been collected, we should aim to make a go/no-go decision on the next ACD. We don’t need to iron out every detail before moving forward, but we should aim for broad alignment on the new structure before we start experimenting with it.

Thank you for reading all the way here ! You can comment directly on EthMagicians