Ethereum’s All Core Devs (ACD) today looks very different from where it started. What began as a small coordination call has grown into three specialized calls, with multiple facilitators and many people supporting devnets, testing, tooling, documentation and stakeholder engagement.

Will Corcoran’s recent post, offers an interesting way to look at this change. He separates ACD coordination into five layers: moderation, UX/tooling and legibility, fork preparedness, stakeholder engagement, and capture resistance.

I like this framing because these are different functions, even though over the years some were handled by the same people or teams. It also brings up questions worth discussing now, when they are not about any particular person or conflict.

I want to invite community to look back at ACD coordination - how the roles evolved, who picked up different functions along the way, and what we can learn from that history.

Even in the early days, Ethereum separated some of these five functions. We had a dedicated "Hard Fork Coordinator". Ethereum Cat Herders took on documentation, stakeholder engagement, and coordination around ACD. Later, EF Protocol Support and specialized testing and infrastructure teams took on other parts of the work.

Ethereum has mostly solved these coordination needs organically as they came up. Maybe it is worth looking at that history before deciding what we need next.

As coordination work grows, do we add more people to the same role, or separate the functions?

ACD Coordination Over the Years

In the early days, All Core Devs was much simpler.

Martin Becze organized the first few meetings, with George Hallam helping with some of the logistics. In October 2016, Hudson Jameson took over organizing, moderating and writing notes for ACD. Several responsibilities that we would probably separate today were concentrated around a very small number of people.

By 2019, Lane Rettig & Ethereum Cat Herders was helping with facilitation and notes, while Charles St. Louis, Tim Beiko and James Hancock also supported with upgrade coordination, communication and livestreaming.

Then the functions started transitioning.

In December 2020, Hudson announced that he would step down after Berlin, with Tim Beiko taking over ACD facilitation.

As Ethereum prepared for the Merge, The Great Renaming was introduced in August 2021. Around the same time, coordination started to separate between the two layers, with Tim Beiko leading Execution coordination and Danny Ryan leading Consensus coordination.

Over time, this grew into the structure we have today: ACDE, ACDC, and ACDT. ACDT is a dedicated ACD call introduced in May 2025 for testing and upgrade readiness.

Today we have three calls, multiple moderators and a much larger coordination surface. The ethereum/pm repository provides the current meeting structure and facilitator history.

Having backups is healthy.

If I look at ACD coordination through five layers lens, I wonder if we really need multiple people doing largely the same moderation role, or if we should think more clearly about who owns the different functions.

More coordination work does not always mean more people doing the same job. Sometimes it means separating the functions.

We have done this before. One person can focus on moderation, while others take responsibility for different coordination functions, with clear backups and handoffs.

So for me, the question is less about how many coordinators we need, and more about which functions need clear ownership, backup and accountability. And Ethereum has actually done this before.

How Roles Evolved

The Hard Fork Coordinator is an interesting part of ACD history that is worth remembering.

At different points, hard-fork coordination was performed alongside ACD facilitation. Ethereum Network Upgrade Process was proposed by Afri Schoedon as EEP-5 in Dec 2018. At the time, he was a developer at Parity client; subsequently became prominently associated with the dedicated Hard Fork Coordinator function, including during the Constantinople period. ECH GitHub repo was the coordination venue for the community including Postmortem Actions.

When Afri left Ethereum in early 2019, ACD explicitly discussed how to replace the role. In Ethereum All Core Dev meeting #56 (March 2019), it was discussed that the Ethereum Cat Herders should be assigned the task of future HardFork Coordinator Coordination. Hudson had previously served as both ACD facilitator and hard-fork coordinator, while also managing streaming and other responsibilities.

In late 2019, James Hancock took over dedicated hard-fork coordination, while ECH supported meeting notes, livestreaming and other operational work. James was an EF hire to help improve the decision-making process and ensure upgrade plans were executed. Through several iterations, this work eventually led to what became known as the EIP-Centric Model of network upgrades.

EIP-2378: EIPs Eligible for Inclusion authored by James, made the path from proposal to inclusion, implementation, testing, and deployment more explicit. It can be compared to the present-day EIP-7723:Network Upgrade Inclusion Stages.

This distinct role created an important separation: James didn't become Hudson's second moderator. He became the Hard Fork Coordinator.

That distinction is important.

ECH’s Role in ACD History

Ethereum Cat Herders was also created around a similar need: there was important coordination work around ACD that did not necessarily need to be performed by the moderator.

ECH contributed across several of the five layers described by Will.

UX, Tooling and Legibility

ECH supported ACD with meeting notes, summaries, recordings, livestream support and public documentation.

Over time, this expanded into EIP and upgrade tracking, process documentation, newsletter and other ways of helping people understand what happened on the calls and what the status of proposals was.

Fork Preparedness

ECH's contribution here was coordination rather than protocol engineering.

This included EIP tracking, author follow-ups, audit coordination, upgrade readiness information and helping connect authors, client teams and other participants.

ProgPoW is one historical example, where ECH helped coordinate the software and hardware audit process.

Stakeholder Engagement

This has probably been one of ECH's most visible functions.

During EIP-1559, for example, ECH conducted outreach across miners, mining pools, wallets, exchanges, infrastructure providers and other affected stakeholders.

Similar communication and education work continued through the Merge and later upgrades.

This distinction matters:

Supporting ACD does not necessarily mean moderating ACD.

A healthy coordination system can have different people responsible for making the meeting work, making the upgrade work, making the information understandable, and making sure people outside the room can participate.

The EF Protocol Support Era

As Ethereum's protocol-development operation grew, the Ethereum Foundation's Protocol Support team took on a significant portion of this coordination infrastructure.

By the 2025-2026 period, Protocol Support and related EF teams were supporting functions across scheduling, ACD logistics, recordings, documentation, fork coordination, upgrade tracking and communication.

ECH focused on protocol education via PEEPanEIP.

At the same time, other specialized teams increasingly carried technical coordination.

EthPandaOps supported devnets and operational infrastructure. Testing coordination became more explicit through ACDT. Client teams continued owning implementation. Independent tooling and documentation projects made protocol development increasingly navigable outside the meetings themselves.

In other words, the ecosystem was already moving toward Will's five-layer model - even if we weren't calling it that.

The work was becoming specialized.

Roles in Transition (again)

The removal of the EF Protocol Support team in 2026 has shifted some of these responsibilities again.

In the second half of 2026, ECH Institute (prev. Ethereum Cat Herders) is again supporting ACD streaming and continuity, including livestreaming/recording support where needed.

ECH also continues to contribute through EIP process coordination, Office Hours, EIP author/editor support, and ecosystem education.

Other responsibilities remain distributed across ACD facilitators, EthPandaOps, STEEL, client teams and other protocol contributors.

Dashboard tooling is available via Forkcast and EIPsInsight, including its Upgrade Explorer.

This is another reminder that the functions remain even when organizations change.

Teams can disappear. People can change jobs. Funding can end. Ethereum still needs the work to happen.

That is why I think we should focus first on identifying and protecting the functions Ethereum depends on.

What Does This Mean Today?

With that history in mind, I want to come back to some of the questions Will raised and look at them through the lens of how ACD coordination has actually evolved.

Multiple Moderators, or Better Responsibilities Distribution?

Having a backup moderator is healthy.

But if we agree that ACD coordination now consists of five distinct layers, perhaps one person primarily moderates while another owns one or two of the other coordination functions, with clear backups and handoffs. That gets us closer to how responsibilities have sometimes been distributed historically, while addressing today's much larger workload and bus-factor risk.

The question may therefore be less about how many coordinators we have and more about:

Which critical functions need an owner, a backup, sustainable funding and accountability?

Does the Seat Belong to the Person or the Institution?

On whether the seat belongs to the person or institution, I am not sure it has to be entirely one or the other.

A person carrying the seat from institution to institution can preserve continuity and earned trust, but over time it can also appear as though a governance position belongs to an individual.

On the other hand, an institution-tied seat can provide continuity, funding and accountability - provided that institution is "credibly neutral" and has no interest in advancing a particular proposal or agenda.

In that model, the institution isn't there to own the seat. Its responsibility is to protect the neutrality around it: reliable funding, COI rules, disclosures, succession and continuity.

A credible neutral public-goods institution, or perhaps a neutral working group, could maintain a documented process for selecting, onboarding, reviewing and offboarding ACD coordinators. We already do something similar for EIP Editors through EIP-5069.

Why shouldn't high-leverage ACD coordination roles have an equally clear process?

Questions Worth Answering Before We Need the Answers

As these roles become more important, I think a few things are worth making explicit:

• Who can nominate a moderator, and who can object?
• What disclosures or conflict-of-interest expectations should come with the role?
• What happens when someone changes institutions, funding sources, has a prolonged absence, or unfulfilled "duties"?
• Should the role have a defined term, followed by renomination or reaffirmation?
• Who determines whether neutrality has been maintained?
• What should succession and handover look like?
• Most importantly, if someone holding a critical coordination role leaves tomorrow, do we already know what happens next?

None of these questions suggest that something is wrong today. They are about making the process stronger before we need it.

The best time to answer governance questions is when they aren't about any particular individual.

Capture Resistance

I strongly agree that capture resistance matters.

But for a decentralized ecosystem, I don't think capture resistance comes simply from whether a seat is attached to a person or an organization.

Historically, Ethereum's capture resistance has come from multiple mechanisms working together:

No single organization owns all of these.

That is probably a feature.

Capture resistance should not itself become a capturable seat.

Perhaps Layer 5 should remain everyone's responsibility, but the mechanisms enabling it should no longer remain informal but clearly documented.

COI disclosure, funding transparency, terms or reaffirmation, open nomination, succession procedures, public agendas, canonical decision records and clear ways to challenge process decisions can all be documented without creating another authority sitting above ACD.

Capture resistance is ultimately a property produced by transparency, independence, plurality and contestability across the other four layers.

Diffusion Needs Clarity

I agree that diffusion is good.

Having all of Ethereum’s coordination work inside one organization — including the EF, it comes with risks. But spreading the work across many people and organizations without clear responsibility can create a different problem.

It becomes difficult to answer some basic questions: Who is responsible for what? Who funds the work? Who is the backup? And what happens when someone leaves or the work simply doesn’t get done?

Decentralization should distribute power, not make responsibility disappear.

So maybe we don’t need to answer “person vs institution” just yet. It may be more useful to first map what we have today: how people take on these roles, how they are funded, where responsibilities overlap, what checks and balances exist, and whether there are clear backups.

And importantly, as people and organizations change, how do we know the community’s trust in these roles still remains?

Then map those responsibilities against the five layers. Only after that do we need to decide how many people each layer needs, where they should sit, and how they should be funded.

Map first. Design second.

Design for Where Ethereum Is Going

I also think we should look at this in the context of where Ethereum is going, not only where ACD came from.

Ethereum has evolved over the years - from proving that a decentralized blockchain can work, to scaling it, and increasingly making it usable by enterprises and mainstream users. As the number and diversity of stakeholders grow, confidence in the process becomes even more important.

For me, that means ACD should not only be neutral, but also approachable, open to different viewpoints, and a place where people can disagree without feeling that participation depends on who they know or where they work.

Ethereum is open to everyone. Its coordination process should feel the same.

A technically decentralized protocol needs a coordination process that feels equally open.

Looking back, Ethereum has adapted as its needs changed. When upgrade coordination needed dedicated attention, we had a Hard Fork Coordinator. When documentation and stakeholder coordination needed support, Ethereum Cat Herders stepped in. As protocol development became more specialized, Protocol Support, EthPandaOps, testing teams and others took on different parts of the work.

Maybe now is the time to make that structure more explicit - identify the functions Ethereum depends on, make responsibilities and backups clear, fund them sustainably and most importantly, document it.

People will change. Institutions will change. Teams will come and go. The functions Ethereum depends on will remain.

Something to marinate on.

Ethereum should not depend on who holds the chair, but on a process strong enough that anyone trusted to hold it can serve the community well.

This post is part of our new “Stories” collection - a space to share Web3 experiences through personal journeys.