Ethereum core governance explained

A presentation by Nixo Rokish from the Ethereum Foundation at ETHBoulder, explaining Ethereum's core protocol governance, how hard forks get coordinated, common misconceptions about who controls Ethereum, and how to participate in the governance process.

This transcript is an accessible copy of the original video transcript (opens in a new tab) published by EthBoulder. It has been lightly edited for readability.

Introduction (0:12)

Thanks to all six of my friends who showed up. All right. I'm talking to you today about Ethereum core governance. My name is Nixo. I lead the protocol support team at the EF. Among all of our mandates, one of our mandates is to make the governance process clearer and easier to navigate for everybody else who participates in these things because Ethereum does include a whole lot more than just its core developers.

So here's an outline of the talk. We're going to talk about what core governance is. We're going to talk about misconceptions, how Ethereum governance currently functions. We're going to touch on how it compares to other decentralized governance systems, why builders would care, and actionable paths for participation.

So, what is core protocol governance? I run a node. So what that means is I have a piece of hardware, a computer at my house where I run Ethereum software. When I set up this Ethereum software, I had to choose the clients that were going to be running that software. Ethereum is kind of unique in that it has multiple clients for client diversity. The point of that is if one client goes down, if there's a bug in a client, the whole network doesn't go down. There are other blockchains that have other clients. However, Ethereum is the only one that's set up in a way that actually protects us against bugs. So, if you go to like Solana, Solana has another client, I think it's called like GTO, but it only has 20–21% adoption. So, if the majority client goes down, the chain goes down. And we have seen other networks go down. And it is why Ethereum is the most resilient, secure blockchain.

So the question becomes how do you get changes into Ethereum when you have to coordinate with so many different clients. First we'll differentiate between a hard fork and a soft fork. A soft fork doesn't require the coordination that a hard fork does. Ethereum primarily works with hard forks. So what a hard fork is, is basically all the clients build a new version of Ethereum and decide at some preconfigured time to launch this new version of Ethereum. It's still Ethereum but it's got new features. It's got different features. And all of the node operators like me who are running nodes at home or professional operators have to buy into that new version of Ethereum. They have to upgrade their node or update their nodes to include that new software.

So how do they decide what features go into those hard forks? They have to agree on priorities to allocate their time and resources because they do have finite time and resources to allocate there. They prioritize things like security flaws or security patches, things like UX — if there is another blockchain that's competing with us, we need to become competitive with those other blockchains. So one of the things that they look at is that any feature that goes in has to be forward compatible with potential upcoming roadmap items.

So last year there was a really contentious thing that happened. You might have heard of it. It was called EOF. That's EVM Object Format. That was a set of features that was slated to go into the Fusaka hard fork — Pectra, Fusaka, I think both — but it got split up. And one trigger among many triggers that it got kicked out of that fork was because Vitalik posted a post about the potential for Ethereum to adopt RISC-V. A lot of the people who were reading that looked at it and were like, okay, if we adopt RISC-V the features that we're looking at in EOF come native with RISC-V. So why would we add this complexity to the protocol? Why would we put all these client developer resources towards this thing? It would be a moot point if we ended up moving to RISC-V.

So that was sort of the straw that broke the camel's back on EOF and it ended up getting kicked out of the fork. Another thing that they have to consider is it has to be written and rigorously tested in six different languages because these clients are written in six different languages. So that's a really big testing matrix for them to work with. And because of that every tiny design choice gets subject to debate with no authority to resolve disagreements. So the question that brings up is who decides — which is the crux of governance.

Misconceptions (5:23)

So that brings us to misconceptions and we'll address some of these. One is Vitalik decides what goes into the Ethereum protocol. An extension of that is that the EF controls everything. And a third one is it's all backroom deals — insiders, OGs making these decisions.

So the first one: Vitalik decides. I just picked a subset of stagnant EIPs authored by Vitalik. What this means is that Vitalik sat down, he wrote a proposal and he said I want these things to go into Ethereum and nobody agreed — these things are just sitting there. He wasn't able to get these into the protocol. So not everything that he proposes automatically gets included.

One extension of that is the Ethereum Foundation controls everything. I'm going to pick a specific example of a time that I think contradicts that. In 2024 there was a lot of talk about the gas limit. And the reason for that is in 2022 during the merge we raised the gas limit to 30 million. That's the max computation that's allowed in a block. And then we sort of didn't touch it for a while because it wasn't really a bottleneck that people were saying, "This is why I'm not moving to Ethereum" or "This is constraining my current use case of Ethereum."

And in late 2023, early 2024, there was this narrative that Solana was coming. It was going to eat Ethereum's lunch. And so people were thinking about what can Ethereum do to accelerate. And one of the things was let's pump this gas metric. And at the time the EF and client devs were sort of like, "We got other things to worry about. Thanks though." But these two people, Eric Connor and Mariano Conti, came in and said, "Nope, we're raising the gas limit." The gas limit is a validator-controlled parameter. And so they could just start talking to validators, professional operators, and say, "Hey, raise your gas limit."

And at some point there was enough adoption to where the EF and the clients were like, "Oh we got to pay attention to this. We got to make sure what they're doing is safe and that the value that they end up raising this to is going to be a safe thing for the network." So, they had to reallocate their resources. Nethermind came up with this testing framework. The EF did a bunch of work in Berlin. All of the client devs were benchmarking this. And so I like this because it forced the EF's hand in deciding what was prioritized.

And I like this stupid tweet that I screenshotted here because it's like some random news outlet calling Eric Connor and Mariano Conti core devs. They're not core devs. Eric Connor was a staker and a community member. Mariano Conti was a former MakerDAO app developer. But they just got called core devs because Ethereum development is really outside the world of how traditional software works and so they saw a core parameter being modified and they were like, "Oh these must be core developers." They were not. So this is just an example of community members coming in and saying we want to see this change and making it happen.

It's all backroom deals, insiders, OGs — I understand a little bit more why this is a misconception because you basically come to these governance calls, there are a hundred people in these governance calls. It seems like they're all very comfortable with what's going on. You're lost. You have no idea how these decisions get made. You're like, "Is it my turn to talk yet?" And it feels like people are listening to the same 10 people to make these decisions.

Meritocracy and participation stats (10:18)

But the truth is Ethereum development is more of a meritocracy than I've ever seen in most software development. All these people on this screenshot — this is one of three in this random ACD call that I decided to screenshot — none of these people were appointed to be here. Everybody is just sort of the people who showed up. They're the developers who have spent a lot of time with this protocol. They are the ones that people have acknowledged as being talented developers in this space consistently making good decisions, and nobody in this is appointed to be here.

So I only joined the EF a little more than a year ago. I grabbed these stats. They only go back to March 2025. So less than a year. The average All Core Dev attendees — that's the governance calls — is 98. So on average there are 98 people in these calls. The max attendees in one call since then was 153. I think that was the day that we were deciding the Pectra mainnet date. And the total unique attendees is 567 just in the last year. I really like that metric because it does show that it's not the same 100 people going to these calls every time. These app developers, researchers, somebody hears about some feature that is being discussed, they show up to voice their opposition to it or their support of it and then they don't come to another call.

How the governance process works (11:52)

So this is kind of a dry slide but I think it's important to go through — this is how Ethereum's governance currently works. So when one of these forks is being discussed the first thing that happens is people during this allocated time window are able to submit their headliner proposal. Headliner proposal is the major feature that we want people to rally around for this fork. This can be a community member, a researcher, a core dev — really anybody who submits one of these headliner proposals. Then the window ends and on the governance calls we sort of discuss which of these makes sense. People make their cases, people argue and there is consensus around which one we should choose for that upcoming fork.

Following that they choose the minor features. So the smaller things that don't really need to be these major fork-driving features. And all throughout this time we have feature-specific devnets. A devnet is like a test net — a private test network for the developers to test these features and make sure that they're actually working on Ethereum. And then there is at some point a feature freeze. So we have discussed the major features, we've discussed the minor features, we've run these feature-specific devnets that are usually the fork headliners. And that's feature freeze with an asterisk because at that point we've decided we will not add any more features to this fork. We're going to run all the features together, make sure everything is good, make sure nothing's going to break. But if something starts slowing things down, if the fork is delayed, if it's too complex, things can still get kicked out at that point.

So after a number of devnets — there could be two, there could be 10 — the clients all decide at some point that this is stable. We trust what's going on right now. We're in a good place. Let's start thinking about getting this out onto Ethereum mainnet. They cut client releases and then there's a 30-day period where the EF security team puts out a bug bounty. They contract security audits. And then at the end of that 30-day period we launch the fork onto testnets. These are testnets that you might have heard of — like Holesky. These are where app developers can test their things before the fork goes live. And these are generally a minimum of 14 days each just to make sure that everything is fine. We don't expect any large problems because it's gone through feature-specific devnets and generalized devnets before, but historically it has broken some of these testnets. And so this is sort of the last call to find and squash all of these bugs.

And then once the permissionless testnet is stable, the mainnet date is chosen. Following that, there's a 30-day buffer. This 30-day buffer exists because L2s and protocols have requested this in order to get ready for the fork. So that's a minimum of 30 days and then the fork happens.

Call structure and coordination (15:01)

During this whole time there are some main call series happening. These are all public calls live-streamed on YouTube. The major ones are ACDE and ACDC. E is for execution layer — that's stuff like transactions, smart contract deployments, mempool management. ACDC is the consensus layer — so that's validator things like validator management, slashing. And those trade off Thursdays. So there's an ACD every single Thursday and one of them is ACDE and then the next one is ACDC, continuing that way.

The ACDE and ACDC calls focus on the fork that we're currently making and forks that we're scoping for the future. The ACDT calls are more nitty-gritty in the weeds. They're the clients talking about bugs they can't get past or implementation details that need to be resolved about the fork that they're currently working on. So right now the next fork that's happening is Glamsterdam. So these ACDT calls are dominated by conversation about ePBS and block-level access lists which are the things that are going into Glamsterdam. And these are the highly technical calls.

And then there are breakout calls. Breakout calls are community members, researchers, developers saying, "Hey, I have a feature that I want to get into Ethereum two forks from now." And so they host these weekly, monthly, or bimonthly calls where they hash out the implementation details, change and iterate on the spec, and generally address all the questions that people have, all the known unknowns to make sure that it's in the best possible place to be included in the fork two forks from now. And those can be scheduled whenever the facilitator decides.

An evolving process (15:29)

So one thing I want to impress upon everybody is that this process is anything but static. This process that I just described to you has been live for less than a year. Ethereum has been live for 10 years. But it constantly changes and the reason it constantly changes is because no one is in charge. And this process sort of evolves to figure out the most efficient way to operate. And like I say efficient, but the reputation that Ethereum governance has is being really stagnant, hard to get things through, confusing — and that's because when you have 100 to 500 people making decisions, I'm honestly impressed that this works at all.

So Tim made a post in April of 2025 called "Reconfiguring All Core Devs" which ended up being the proposal for how things work right now. And the reason for that is because prior to that we sort of had this cohesive narrative about what we should focus on in Ethereum. There was the merge which was a huge undertaking. Everybody was very excited. Most people were very excited. The miners were not. And then following the merge, you had withdrawals. So, we didn't want people to have their ETH locked into a contract and this FUD to be like they're never going to get the ETH out of this. So, we had to ship that as fast as possible. And then there was proto-danksharding and then Pectra came and Pectra was sort of this amalgam of different unrelated EIPs and didn't really have a cohesive narrative. And it became so big because people were kind of just shoving things in because of the lack of cohesion that it had to get split into two different forks because the testing teams were sort of like, "The scope is way too big. We can't test all of this."

And so Tim's impetus for doing this was, okay, we need to think of a way to keep these forks as focused and cohesive as possible. And the headliner was sort of the answer to that. The point of that was to ship in a way that prioritized making it feel like everybody knew what the fork was about, so they didn't have to shove in 25 different EIPs.

So the other screenshot on the top is Tim proposing definitions for stages of inclusion for these EIPs. And the point I want to make with this is there sometimes you hear people say that this process is too bureaucratic. But what's really happening is people come into this governance process and they're like, "How do I get an EIP in?" and people who have been there for 10 years are like, "You sort of just do." And people are like, "This is horrible." And so what these things do is they describe what's happening to make it easier for outsiders to participate in this process, because if you are just coming here and you're like, "I have one EIP, I don't care about Ethereum governance, I just want this one EIP in" — you want a rubric, you want a checklist, you want a very clear step-by-step on how to get this EIP in. So, most of these things are more about describing how the process works than creating bureaucratic rules that people have to follow to make it hard to get EIPs in.

The third thing is commits over time on Forkcast. Forkcast is a product by my team, by Wolfram Mark, a guy on my team who created this mid-last year when my team in its current iteration was formed. And it has become such a canonical resource for people to use to interact with a fork, to see what's going into a fork and how it affects them. All of these things are less than two years old. So just the point I'm making is this process changes a lot. It's not static at all. It's not some frozen bureaucracy that's hard to get your foot in the door.

Comparable governance systems (20:21)

So just quickly I wanted to touch on the most similar decentralized systems of governance that I can see to Ethereum governance. And the point I'm kind of trying to make here is that this is sustainable — even though it's amazing that 100 to 500 people can make decisions, it is sustainable in the real world. We do see examples of this working.

The IETF is the Internet Engineering Task Force. It's the volunteer-run standards body that created TCP/IP, HTTP. It is the organization that's most responsible for the fact that we have the free internet today. The Linux kernel — it's the core of the Linux operating system. So that's open-source software that powers internet servers, Android phones, supercomputers. The difference there is that they have sort of a benevolent dictator model with Linus Torvalds. But even then they have over 17,000 contributors, which is mind-blowing.

Things that this is not similar to: other blockchains that have onchain token voting. Ethereum specifically avoids any sort of voting mechanism because in my opinion that leads to avenues for capture and it sort of gets rid of the incentive to make things a meritocracy where people just trust the people who write the best code. And then there are L2s. They have multi-sigs. They have security councils. These are more like appointed positions that make these decisions. And that has its trade-offs. It's more centralized. It moves faster though.

Why builders care (22:38)

So why do builders care about governance? Because builders are literally who Ethereum is created for. Ethereum is not created for core devs. It's not created for validators. Sometimes these people get confused about that. Ethereum core devs and validators serve Ethereum which serves builders and users.

And everybody has had that moment with an AI where you are getting way too in the weeds and it's trying to fix this little thing and it fails to zoom out and look at the whole purpose of the project. And core devs can be like that where they're trying to perfect the core development process. And it's very crucial in that case that builders come in because core development is so all-consuming that they're not also building on top of Ethereum most of the time. They are very involved in core development. It takes up all of their time. And so app builders really have to make an effort to come in and say, "Hey, we need this. This is crucial for Ethereum." Just to make sure that the perspective is there and that they're not just getting pigeonholed into just working for core developers.

How to participate (24:40)

So how do you participate or get your feature in? This is sort of generic advice, but I think it is the best. Be loud about your pain points. Go on Twitter, write blog posts, identify solutions for your pain points. Speculate on the things that could help you. If you find other people who have those same pain points, generally you can find an EIP that exists to address that pain point or have someone help you write an EIP that does that.

One thing I like about open-source software is that generally well-capitalized companies will allocate their dev time and resources to maintaining open-source tooling that they're using. And it ends up being a bunch of different companies collaborating on maintaining this thing and that can be how it works in Ethereum too. So if you have a pain point that you've identified you can find a Base developer who has a similar pain point, and Base is a well-capitalized organization and so they would probably be willing to allocate some resources to shipping a feature or stewarding a feature through an Ethereum hard fork.

I'll just leave you some resources. Forkcast.org — that's where you can go and look at what's going into a fork, how it affects certain stakeholders. So, if you're an app developer, there's a section for app developers. If you are a wallet developer, a consensus layer client developer, there are sections on how those all affect you. The YouTube is where all of those call videos are uploaded. They're also embedded in the forkcast.org/calls page where there are summaries, speaker attributions, so it's easier to navigate those calls. The EIPs directory, the Ethereum Magicians forum where you can go talk to other people about potential solutions or EIPs that you want to write. And very soon my team will have a protocol support site. It looks awesome. It's not ready to share. My email is also there — nixo@ethereum.org (opens email client). That's it.