Thank you for this thorough proposal! The structured approach to headliner prioritization and process design provides a clear path to resolving the current chaos. However, in my view, there’s still one critical component missing:
When a previously “consensus-reached” decision later faces major divergence—e.g., EOF was initially included in Fusaka and then rolled back—
Who has the authority to overturn the original decision?
What are the criteria for reversal?
Who bears the cost—both in human resources and on-chain risk—after a reversal?
You’ve explained the process of Final Selection & Rough Consensus, but the mechanism for “reopening closed cases” has not yet been clearly defined. This is precisely what the EOF case revealed — we lack a decision exception handler.
Ethereum’s upgrade governance references IETF RFC 7282’s “rough consensus” model, which is a solid starting point. However, we can’t be limited by it, because EIPs and RFCs differ fundamentally:
- EIPs must reach absolute agreement among major clients and be implemented and deployed at the same time. Otherwise, Ethereum could face hard fork issues. RFCs, on the other hand, are recommendations. Once finalized, IETF’s job is done, and adoption is optional—it doesn’t affect the overall function of the Internet.
- In Ethereum, “considering all informed opinions” currently centers on ACD’s technical perspectives, lacking broader ecosystem input.
Ethereum’s protocol layer is far from the Internet’s level of maturity, where it has become a de facto standard infrastructure. Ethereum still faces competition from more centralized, commercially driven alternatives. Without a more efficient mechanism for building consensus and coordinating efforts, Ethereum’s competitiveness may decline.
The EOF case also exposed a lack of information transparency. As you mentioned in your EOF recap, the relevant discussions were scattered across GitHub, personal blogs, HackMD notes, Ethereum Magicians, ACDE meeting notes, and EIPs—and some even happened on Twitter and Discord. This fragmentation makes it very difficult for other stakeholders to follow everything and participate effectively.
In addition, time zone barriers remain an issue. Since I live in the same time zone as @kdenhartog, I can fully relate to his point:
https://ethereum-magicians.org/t/reconfiguring-allcoredevs/23370/4?u=bruce_lxdao.io
Comparing Ethereum’s current process with traditional tech project workflows helps us identify the main problems and optimization opportunities:
| Stage | Traditional Tech Projects | Ethereum |
|---|---|---|
| Source of Needs | User feedback / market needs | Roadmap / Researchers / ACD / Ecosystem |
| Decision Makers | Product Managers, Leads | AllCoreDevs |
| Execution Team | Company R&D | Multiple client teams |
| Accountability | Assigned to individuals/teams | No strict enforcement |
From this, the main issues are:
- Technical upgrades are decoupled from business needs. Misalignment of upgrade timelines and ecosystem realities causes friction and inefficiency.
- Upgrade decisions heavily rely on core researchers, placing high pressure on ACD. Making informed decisions requires integrating market trends, long-term vision, technical feasibility, product iteration, and app compatibility—roles usually handled by dedicated PMs and project managers in traditional companies (with professional skills).
- No accountability for plan changes. When things shift, no one takes responsibility, making it hard to trace wasted resources.
Given the above, I propose the following:
1. Build a Consensus Platform for Upgrades
There is already a related post: https://ethereum-magicians.org/t/for-an-acd-platform/24098. However, my view differs slightly: this platform should enable consensus-building across multiple ecosystem participants, not just within ACD.
Here’s why I think @abcoathup’s idea of simply starting from the Magicians forum isn’t sufficient—we need a new platform:
- We are already using forums, and they clearly have a high participation barrier for external stakeholders.
- Discussions about EOF and past upgrades are scattered across various channels, leading to confusion. Even with new templates and processes, without structured workflows, things may become more chaotic.
- The goal of coordination is not to minimize our own workload but to lower the barrier of entry for others. It’s worth the effort to optimize this.
The platform could resemble L2Beat, offering multi-dimensional information displays and feedback collection for each upgrade:
- Technical cost and security impact: Assessed by Core Devs and client teams—e.g., estimated dev time, risk to network stability, etc. This is the highest-priority metric. If an EIP introduces major cost or security concerns, it should be delayed—even if the community demands it—until a safer solution is found.
- Stakeholder feedback: Support / Oppose / Neutral options with rationale. Ecosystem participants (e.g., institutions, VCs, Dapps, wallets, L2s, staking providers, node operators, KOLs) can receive badges for wallet-based voting. Results help reflect community sentiment.
- Transparency scoring: e.g., Was there sufficient discussion? Did key stakeholders across different regions participate?
- Additional materials: Quality articles, controversy summaries, link aggregation (Twitter, Ethereum Magicians, Ethresearch, Discord, etc.)
The platform could extend https://eips.ethereum.org/ or https://github.com/ethereum/pm, or be a standalone interactive site—that part isn’t critical. What matters is that it improves transparency and provides a space for open participation. Votes and opinions on the platform wouldn’t be binding but would inform ACD decisions and provide a trusted reference in cases of dispute.
2. Define a Final or Important Dispute Resolution Process or Committee
It’s best to separate and clarify the roles and scope of ACD vs. final decision-making. When it comes to major features, relying solely on technical perspectives is insufficient. Broader strategic thinking and ecosystem-wide input are needed.
As mentioned before, Ethereum differs from IETF fundamentally. While I personally favor decentralization, given the current state of Ethereum’s R&D and the competitive pressure, I lean toward a pragmatic approach: set up a reasonable and efficient decision process grounded in diverse feedback, rather than clinging to decentralization ideals (but actually ACD centered) alone. Until Ethereum ossified, like @zengjiajun mentioned here https://x.com/zengjiajun_eth/status/1926067592621367402
This new process should be triggered only when necessary to avoid disrupting existing mechanisms.
A related community idea: https://x.com/ameensol/status/1917263883502240158
3. Increase Inclusivity in Feedback Loops
A simple example: ACD Calls are mostly scheduled in European-friendly time zones, creating barriers for APAC participants—even though the region includes over half the global population.
I observed fewer than five individuals who appear to be of East Asian in the photo of the Pectra Upgrade contributors shared here: https://x.com/TimBeiko/status/1920145795430727686. This highlights a diversity issue within the Ethereum ecosystem, if we truly aim for Ethereum to be a world computer, we might need to solve it.
Last year, @xinbenlv organized AllERCDevs meetings that included EMEA-friendly and APAC-friendly sessions, which was a good attempt at global inclusion: https://github.com/ercref/AllERCDevs/issues
I don’t claim this is the best solution, but this direction is worth pursuing, as also mentioned here: https://ethereum-magicians.org/t/reconfiguring-allcoredevs/23370/4?u=bruce_lxdao.io
4. Try Layered Upgrades and Iterative Deployment
In my previous experience at major Web2 companies, fast iteration was critical to product success. With good automated testing in place, weekly releases were the norm—faster is better, and small steps reduce risk.
For non-core-protocol upgrades (i.e., those not requiring forks), we could design a fast-track implementation flow, avoiding the current 1-2 yearly fork constraint. Due to Ethereum’s immutability, this would need custom testing and deployment processes.