Ethereum Core Governance Explained: Myths, Hard Forks & How to Participate

Transcript

Intro & Why Governance Matters

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

What Is Ethereum Core Governance?

We're going to talk about what core governance what core governance is. We're going to talk about misconceptions, how Ethereum governance currently functions. Um, we're going to touch on how it compares to how other decentralized governance systems, why builders would care, and actionable paths for participation. So, what is uh core protocol governance? Um, I run a node. Um, so what that means is I have a a piece of hardware, a computer at my house where I um run Ethereum software. When I set up this Ethereum software, I had to choose the clients that were um going to be running that software. Um Ethereum is kind of unique in that it has uh multiple clients for client diversity. The point

Why Ethereum’s Multi-Client System Matters

of that is if one client goes down, um if there's a if there's a bug in a client, the whole network doesn't go down. Uh there are other blockchains that have um other clients. However, Ethereum is the only one that's set up in a way that um actually protects us against bugs. So, if you go to like Salana, Salana has another client, I think it's called like GTO, um but it only has 20% 21% adoption. So, if that if the majority client goes down, the chain goes down. Um and we have seen other networks go down. Uh and it is why Ethereum is the most resilient secure blockchain.

Hard Fork vs Soft Fork Explained

Uh so the question becomes how do you get changes into Ethereum when you have to coordinate with so many different clients. Um 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. Um Ethereum primarily works with hard forks. uh and it requires so what a hard fork is is basically all the clients um build a new version of Ethereum and decide at one point to um at some pre preconfigured time um to launch this like new version of Ethereum. It's um still Ethereum but it's got new features. It's got different features.

Um and all of the node operators like me who are running nodes at home or professional operators have to um buy into that uh new version of Ethereum. They have to upgrade their node or update their nodes to include that new software. [sighs] Uh so how do they decide what features go into those hard forks? they have to agree on priorities um to allow their their uh to allocate their time and resources because they do have finite time and resources to to allocate there. Um they prioritize things like security flaws uh or security patches um things like UX um if there is another blockchain that's competing with us, we

How Features Get Prioritized

need to become um competitive with those thing with those other blockchains. Um so one of the things that they look at is it any feature that goes in has to be forward compatible with potential upcoming roadmap items. So uh 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 um Fusaka hard fork um PCA Fusaka I think both but it got split up. Um and uh one trigger among many [clears throat] triggers that it got kicked out of that fork was because Vitalic posted a post that was about uh

The EOF Controversy & RISC-V Discussion

but the potential for Ethereum to adopt Risk 5. Um a lot of the people who were reading that looked at it and was like okay if we adopt Risk 5 the features that we're looking at in EOF come native with Risk 5. 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 risk 5. So that was sort of like the uh the straw that broke the camel's back on eof and it ended up getting kicked out of the fork. Um 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. Um so that's a really big testing matrix for them to work with. Um and because of

that every tiny design choice gets subject to debate with no authority to resolve disagreements. So the question that that brings up is who decides which is the crux of governance. Um so that brings us to misconceptions and we'll address some of these misconceptions. One is Vitalic decides what goes into the Ethereum protocol. An extension of that is that the EF controls everything. Um and a third one is it's all backroom deals. It's insiders, it's OGs making these decisions. So the first one is Vitalic decides. So I just I picked a subset of stagnant EIPs authored by Vitalik. Um what this means is that Vitalik sat down, he wrote a proposal and he said I want these things to be into a go into

Misconception #1: “Vitalik Decides Everything”

Ethereum and nobody agreed like these things are just sitting there. He wasn't able to get these into the protocol. Um so not everything that he proposes automatically gets included. Uh, one that is an extension is the Ethereum Foundation controls everything. Uh, I'm going to pick a a specific um example of a time that I think contradicts that. Um, in 2024 um there was a lot of talk about the gas limit. Um, 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.

Misconception #2: “The EF Controls Everything”

Um, 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. Uh, and in late 2023, early 2024, there was this narrative that Salana was coming. It was going to eat Ethereum's lunch. Um, and so people were thinking about what can Ethereum do to accelerate. And one of the things was let let's pump this gas metric. Um, and at the time the EF was sort of like the EF and client devs were sort of like we got other things to worry about. Thanks though. Um, but uh these two people, Eric Connor and Marion Kanti came in and said, "Nope, we're we're raising the gas

Gas Limit Debate & Community Pressure

limit." Uh, the gas limit is a validator controlled parameter. And so um they could just start talking to validators, professional operators, and say, "Hey, raise your gas limit." Um, and at some point there was enough adoption to where uh, EF 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 the um, 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. Um, Nethermine came up with this testing framework. The EF did a bunch of work um, in Berlin. Um, all of the client devs um, were like benchmarking this. Um, and so I like this because it was like it forced the EF's hand in deciding what was uh

prioritized. Um, and I like this um stupid tweet that I uh screenshotted here because it's like some random news outlet um calling Eric Connor and Mariona Ki core devs. Um they're not core devs. Eric Connor was a staker and a community member. Mariana Ki was a former Maker Dow app developer. Um but they just got called core devs because um it's Ethereum development is like 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. Uh so this is just an example of a community member community members coming in and saying like we want to see this change and

making it happen. Uh it's all backroom deals, insiders, OGs deciding this one. I understand a little bit more why this why this is a misconception because you basically you come to these governance calls, there are a hundred people in these governance calls. It seems like they're all very like 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?" Um, and it's it feels like people are listening to the same like 10 people um to make these decisions. But the truth is Ethereum development is more of a meritocracy than I've ever seen in most software development. Um, all these people on this screenshot, this is one of three in

Misconception #3: “It’s All Backroom Deals”

this um random [clears throat] ACD call that I decided to screenshot. Um, 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 um have acknowledged as being like talented developers in this space um consistently making good decisions and um there nobody in this is like appointed to be here. Um so I only joined the EF a little more than a year ago. So I grabbed these stats. Um they only [clears throat] go back uh to March 2025. So less than a year. The average all core all core dev attendees that's the governance calls um is 98. So on average there are 98 people in these

Who Actually Shows Up to ACD Calls?

calls. The max attendees in one call since then was 153. I think that was uh the day that we were deciding the pect main net date. Um and the total unique attendees um 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. um these app [clears throat] 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 Ethereum Governance Actually Works (Step-by-Step)

Um so this is kind of a dry slide but um I think it's important to go through this is how Ethereum's governance currently works. Um so when one of these forks um is being discussed the first thing that happens is um people during this allocated time window people um are able [clears throat] to submit their headliner proposal. Headliner proposal is the major feature that we want people to rally around for this fork. Um this can be a community member, a researcher, a cord of really anybody who submits one of these headliner proposals. Um then the the window ends and um on the governance calls we sort of discuss like which of these makes sense. Um people

make their cases, people argue um and there is consensus around which one we should choose for that that upcoming fork. Um following that they choose the minor features. So like the smaller things that don't really need to be like these major um fork driving uh features and all throughout this time we have feature specific devets. Um, a devet is like a a test net a private test network for the developers to test these features and make sure that they're actually working on Ethereum. Um, and uh, 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 um, feature specific devets that are usually the the fork headliners. Um, and that's

feature freeze with an asterisk because, uh, at that point we've decided we will not add any more features to this fork. Um, we're going to run them all the features together, make sure everything is Gucci, make sure nothing nothing's going to break. But if something starts slowing things down, if the fork is delayed, if it's too complex, things still can't get kicked out at that point. Um, so after a number of devets, there could be two, there could be 10. um the clients all decide at some point like this is stable. We trust what's going on right now. Um this we have we're in a good place. Let let's start um thinking about getting this out onto Ethereum mainet. They make cl they cut client releases and then there's a 30-day period where the security uh the

EF security team puts out a bug bounty. they um contract security audits. Um and then at the end of that 30-day period uh we launched these uh the fork onto test nets. These are test nets um that you might have heard of. It's like uh hoodie used to be heski. These are where app developers can test their things before the fork goes live. Um and these are generally a minimum of 14 days each just to make sure that everything is fine. We don't because it's gone through like feature specific devets, generalized devets before, we don't expect any large uh problems, but historically like it has broken some of these test nets. And so this is sort of the last call to like find and squash all of these bugs. Um

Devnets, Feature Freeze & Testing Process

and then once the last permissionless test net once the permissionless test net is stable, the mainet date is chosen. Following that, there's a 30-day buffer. this 30-day buffer exists because L2s and protocols have requested this 30-day buffer in order to get ready for the for the fork. Um, so that's a minimum of 30 days and then the fork happens. Um, during this whole time there are some main call series happening. These are all public calls live streamed on uh YouTube. [gasps] The major ones are ACDE and ACDC. E is for execution layer. Um that's stuff like transactions, smart contract deployments, mempool management. This uh

Testnets, Security Audits & Mainnet Launch

ACDC is the consensus layer. So that's things that's validator things like um validator management slashing. Um and those tradeoff Thursdays. So there's an ACD every single Thursday and one of them is ACD and then the next one is ACDC. um continuing that way. The ACDT calls um and ACDE ACDC focus on like the the fork that we're currently making and forks that we're scoping for the future. The AC/DCT calls are more nitty-gritty in the weeds. Um they're the clients talking about like bugs they can't get past or things that implementation details that need to be resolved about the fork that they're currently working on. So right now uh the next fork that's happening is Glamsterdam. So these ACDT

calls are dominated by EPB conversation about EPBS and block level access lists which are the things that are going into Amsterdam. Um and these are these are the highly technical calls that I go and I'm like I don't understand. Um so and then there are breakout calls. Breakout calls are community members, researchers, developers um saying, "Hey, I have a feature that I want to get into uh uh Ethereum two forks from now." Um, and so what I'm going to do is I'm going to host these weekly, monthly, bimonthly calls, um, where we hash out the implementation details, we change and iterate on the spec, and we generally address all the questions that people have, all the known unknowns to make sure that it's in the best possible

ACDE vs ACDC vs ACDT Explained

place to be included uh, in the fork two forks from now. Um, and those can be scheduled whenever the facilitator decides. Um so one thing I want to impress upon everybody is that this this process is anything but static. Um this this uh process that I just described to you has been live for less than a year. This is how things have worked for less than a year. This Ethereum has been live for 10 years. Um but it constantly changes and the reason it constantly changes is because no one is in charge. And like this process sort of evolves to figure out the most efficient way to proc to uh to operate. And like I say efficient, but the the u reputation that Ethereum

governance has is being like really stagnant, hard to get things through. It's confusing and that's because when you have 100 to 500 people making decisions, I'm honestly impressed that this works at all. Um so Tim made a post um in April of 2025 um called recon reconfiguring all core devs which was ended up being the proposal for how things work right now. And the reason for that is because prior to we sort of had like this cohesive narrative about what we should focus on in Ethereum. There was the merge which was a huge undertaking. Everybody was very excited.

Breakout Calls & Early Feature Development

Most people were very excited. The miners were not. Um, and then following the merge, you had um, withdrawals. So, we didn't want people to have their ETH locked into a contract and like this FUD to be like they're not they're never going to get the ETH out of this. So, we had to ship that as fast as possible. Um, and then there was protoden sharding and then PCRA came and PCRA was sort of like this amalgam of different like unrelated EIPs and didn't really have like a cohesive narrative. Um, [snorts] 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 like this is the scope is way too big. We can't test all of this. Um, and

Why the Governance Process Keeps Changing

so Tim's impetus for doing this was, okay, we need to think of a way to keep these forks as cohesive, focused, and um, uh, cohesive as possible. Um, and the headliner was sort of the answer to that. Uh, and that, uh, the point of that was to ship in a way that like prioritized, um, making it feel like that everybody knew what the fork was about, so they didn't have to like shove in 25 different EIPs. Uh, so the other screenshot on the top is um Tim proposing uh, definitions for for stages of inclusion for these EIPs. Um and the point I want to make with this

Reconfiguring All Core Devs & Fork Cohesion

is there sometimes you hear people say that this process is too bureaucratic. Um but what's really happening is um people come into this governance process and they're like how do I get any IP in and people who have been there for 10 years are like you sort of just do [snorts] and people are like this is horrible this is a horrible way and so what these what these things do is they sort of describe what's happening to make it easier for outsiders to participate in this process because if you if you are just coming here and you're like I have one EIP I don't give a about Ethereum governance I just want this one EIP in. You want a rubric, you want a checklist, you want a very clear um step by step on how to get this EIP in. So, most of these things are

most are more about describing how the process works than like creating bureaucratic rules that people have to follow to make it hard to get EIPs in. Um the third thing is um commits over time on forecast. forecast is um a product um by my team um by um Woolvin Mark a guy on my team who um created this midl last year when my team as uh in its current iteration was formed um and it has become such a canonical resource for people to use to interact with a fork to see uh how like what's going into a fork and how it affects them um that like all of these all of these things are less than two years old

Is Ethereum Too Bureaucratic?

and So just the point I'm making is this this process changes a lot. It's not static at all. It's not like some frozen bureaucracy that's hard to get your um hard to get your like foot in the door. Um so just quickly I wanted to touch on the most similar decentralized systems of governance that um I can see to Ethereum governance. Um, and the point I'm kind of trying to make here is that um, this is like a sustainable, even though it's like amazing that a 100 to 500 people can make decisions, it is sustainable in the real world. We do see examples of this working. Um, the IETF is the internet engineering task force.

Comparisons: IETF & Linux Governance Models

Um, it's the volunteer-run standard body u that created TCP IP, HTTP. It is the organization that's most responsible for the fact that we have the free internet today. Um the Linux kernel, it's the core of the Linux operating system. So that's open source software that powers the uh internet servers, Android phones, supercomputers. The difference there is that they have sort of a benevolent dictator model um with Linus Tovald. But even even then they have over 17,000 contributors um to which is mind-blowing. Um things that this is not similar to is other like uh other uh blockchains that have onchain onchain token voting. Ethereum specifically avoids any sort of like

voting mechanism because um in my opinion that leads to avenues for capture um and it sort of gets rid of the the incentive to make things a meritocracy where people just trust um the people who write the best code. Uh and then there are L2s. They have multi-IGs. They have security councils. these are like more like appointed positions that make these decisions. Um, and that has its trade-offs. It's more centralized. It moves faster though. Um, so why do builders care about governance? Um, because builders are literally who Ethereum is created for.

Why Ethereum Avoids On-Chain Voting

Um, Ethereum is not created for core devs. It's not created for validators. Sometimes these people get uh confused about that. Um, Ethereum core devs and validators serve Ethereum which serves builders and users. Um, and you everybody has had that moment with an AI where like you are getting way too in the weeds and it's like 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 like trying to perfect the core development process and um it's very crucial in in that case that like builders come in because these core development is so all-consuming that they're not also building on top of Ethereum most of the time. they are very

Why Builders Must Participate

in [clears throat] like very um involved in core development. It takes up all of their time. Um and so c like uh app builders really have to make an effort to come in and say, "Hey, we need this. This is crucial for Ethereum." Um just to make sure that the perspective is there and that they're not just getting like um pigeon holed into just working for core developers. Uh 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. Um, if you find other people who have those same pain points, generally um you can like find or uh find an EIP that is exists to address that painoint or have someone help you write an EIP that does that. One thing I like about open source software is that um generally in open source software like well- capitalized um companies will allocate their dev time and resources to maintaining this um open source tooling that they're using. Uh and it ends up being like a bunch of different companies collaborating on maintaining this thing and that that can be how it works in Ethereum too. So if you have a painoint that you've identified um you can find a base developer who has a

How to Get Your Feature Included

similar painpoint and base is a well- capitalized um organization and so they would probably be willing to allocate some resources to shipping a feature or stewarding a feature through through an Ethereum hard fork. Um I'll just leave you some resources for.org org. That's where you can go and look at um what's going into a fork, how it affects certain. 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, um there are sections on how those all affect you. Um the YouTube is where all of those videos are uploaded.

Tools & Resources (Forkast, EIPs, Magicians, Calls)

Um they're also embedded in the forecast.org/calls page where there are summaries, um speaker attributions, so it's easier to like navigate those calls. the EIP's directory, the Ethereum magicians uh forum where you can go talk to other people about potential solutions or EIPs that you want to write. Um, and very soon my team will have a protocol support site. It looks awesome. It's not ready to share. I wish I could uh put this URL there, but yeah, I my email is also there, nixothereum.org. That's it. [music]