Funding the Ethereum Kernel | Martin Hansen (Berlin Ethereum Day, June 2026)

I'm part of the funding coordination team at the Ethereum Foundation. My name is Martin. I'm going to talk a little bit about a project that I've been working on for a while called the Ethereum kernel. I first presented this at a talk in Berlin some months ago at the Berlin Ethereum meetup. So, it's nice to be able to give an updated talk here at the Berlin Ethereum day.

So, let's get into it. First off, Guillaume had the slide earlier in the morning when he was talking about shipping faster forks and so on and I really liked it because it it quite relates, I think, to my talk in in some way. He was talking of obviously much more about the building, delivering the technical roadmap, and getting it out to mainnet. And our team at funding coordination, we um we're thinking a little bit more about how to fund Ethereum for the next 100 years and not the next 6 months and how can we create new funding mechanisms, new allocation mechanisms, and and so on. Um And so, my talk today will mostly talk about allocation, mapping out uh the kernel.

That that will be the first time. Uh the first part of my talk will be about mapping out the kernel and this process that I went through, which I'll give a little bit of um insights on. And then, the second part is uh talking a little bit about the kernel as an allocation framework. So, we we put another zero into it here. So, uh not 100 years, but 1,000 years.

And one mismatch that we sort of saw was that we have this 1,000-year horizon where for Ethereum, we're very ambitious about Ethereum and its place in the world. But at the moment, we see finite runways. We have uh treasuries that are dwindling, whether it's foundations or DAOs and so on. Um and we do need to have more diversified funding sources. Provided we have that, we also need to figure out what we actually fund and how we fund things in a in a sustainable manner.

So, that's that's some of the background that went into um into the kernel and why we started this exercise. So, we started thinking quite a lot. I'm going to try to map out what is it actually that that we are looking for. And I think try to summarize it in this little diagram here. One is the things that are absolutely most critical to Ethereum.

So, if you can imagine a world where we're running low on on funding, what is the thing that if it doesn't receive funding, then Ethereum goes down or it's it's it's captured in one way or another. Those are the things we want to identify. We also want to identify the things that we really don't want to be captured in order for Ethereum to be credibly neutral and to live up to some of these properties that that we expect out of Ethereum. So, that's that's what we have up there in that little kernel in the corner. Then we had a lot of conversations.

A lot of conversations with technical experts in particular from the Ethereum Foundation's protocol cluster and also external experts. So, we probably had between 20 to 30 calls or meetings with different people across topics, whether it was client developers, people that come from the testing side, from security side, from the builder side, and and so on. And we tried to then synthesize a lot of these learnings and try to get their version of the kernel, try to synthesize it and and find find something that that makes sense. We obviously as well did a lot of deep deep research besides all these conversations and try to also look at how has Ethereum critical infrastructure evolved over time. And the two core goals that we had with that research was to answer the question of what are these critical functions that make up the kernel?

And two, what might be the resources that it requires to run it on an annual basis? So, I'm going to quickly speedrun through the kernel here. I've done deeper dives in some previous talks. You can look at my talk from Eth Prague or Eth CC, where I go into a little bit more detail. Now, I'm just going to give a quick overview of what what these critical functions are.

Um and and not go into too much detail about why they made it and and so on. But, at the heart of the kernel, we have the clients. Execution layer clients, consensus layer clients. These make up probably the largest part of the client and are really really important largest part of the kernel and are really really important. If you have client diversity, if you have multiple clients, you do also need some protocol coordination to make sure that we're upgrading and so on.

We had a great talk earlier today from Mario about what goes into that and and and how how big of a task that actually is. Um then we have research and prototyping that goes on, comes up with ideas, starts prototyping, figures out how we can improve the protocol further, and works closely with the client teams to to get it there. And then we have a bit of a hardening layer, so to say. Um the guys who work on security. They work on specs.

They work on testing. We heard from some of them actually this morning as well. And these are the guys that that make sure we can deliver hard forks safely and securely and get them to to mainnet. So, that sort of briefly makes up the the protocol part of the Ethereum kernel. But, Ethereum is obviously more than a protocol.

It's also a layer where you are deploying dapps. And for that, um I named this here the language stack includes language, compiler, and some some related tooling for for making Ethereum programmable. Then we have an interesting one here that um I heard in a lot of these sessions I heard that something that's been missing in the past is more shared wallet infrastructure. A lot of these UX issues that we're aware of comes from not enough coordination, not enough standards, and so on. Um we we heard a little bit about that from from Carl in his talk earlier when it came to clear signing, which is a really great initiative that probably would have been even greater if it had happened years prior.

Um so that's that's why some some of these things go into the kernel as well. And then the last one, a bit of a catch-all, but we call it other critical tooling and dependencies. There are many libraries and many smaller smaller maintainers and and and and dependencies that many things in the kernel depend on, and so therefore it's important that that we fund it and that we identify them. Okay. So this is V1, right?

This is the Ethereum kernel, the functions that try to ensure that Ethereum has unmatched uptime, it's programmable, it's accessible, and so on. It's also important that when we set trans set the scope for the Ethereum kernel, we have certain properties in mind. We're not trying to just design some centralized database here. We want this thing to be censorship resistant, we want it to be fully open source, we want privacy to be there, we want it to be secure, we want it to be credibly neutral, and we want it to be permissionless access always. So these are some of the properties as well that we have in mind as we design the kernel.

Okay. Now next up, we started to think about in the same during the same exercise, we would also think about Wait, what are the actual resources that are required to run the world computer and run these functions? How many people does it take and what what kind of funding does it require? We came up with a few assumptions. First off, the vast majority of costs come down to compensation.

So 85% of costs or so are compensation, and then there's some some overhead, whether it's devops, it's travel, it's admin, various different fees. Um and then we need to have a bug bounty program as well. So we've allocated 1 million uh, for a bug bounty program, and we just generally try to find out how can we staff these functions? What is What is the amount needed to staff to staff them? And very importantly, this is not an analysis of how many people work in these functions today.

It's much more of a minimal approach of how many from a minimum does it take for this thing to actually work? Ideally, we have much much more, but we need to start from a baseline. And what we got to was around 18 million as an annual minimal neutral funding requirement. So, in order for these functions to work and be running, then this is the amount that we need. So, that was the first part of the of the talk here, right?

We figured out what functions go into the kernel, how much does it approximately cost? Um, and then we started thinking, could we use learnings from this exercise as an allocation formula? Could we think with the kernel in mind as as we as an ecosystem allocate funding? And I think the way you could summarize this is that if you have used the kernel as an allocation framework, you prioritize the critical core infrastructure. The thing that's really at the core and make sure that that Ethereum works.

So, you can see it here from from the diagram as well. It's really what's in the center. There might be extended core infra that goes um, outside of the kernel as well. And then you have tooling and services. And then further on, you have applications.

The reason why we like to um, emphasize neutral funding as as a requirement here is that when you have neutral funding, you you don't have the same kind of tradeoffs as you as you do with other types of funding sources, right? The further you go out in this circle, more funding sources become available to you, and we have more acceptable tradeoffs, so to say. If you if you have compromises or um, parts of the kernel is captured, it has implication even further out in into the stack. Okay. So, some of the things that we learned from this mapping exercise and that we can take in as we as we think of it as an allocation framework was um some of the questions that kept coming up was so, "What's the scope here?

Like, what do what kind of shipping cadence are you expecting out of the kernel? Um how accelerationist are you in in in the approach? Um what are you generally expecting out of out of the Ethereum kernel? How how far do we go out on on certain parameters and and and what properties are we optimizing for?" And then it became clear to me that something that was missing was more of a standardized framework that we can use to map out kernel on a on a periodic basis, right?

Because it also changes. The kernel changes over time and it has changed in the past from what it is today. And um one way to do that is a rubric that lists out what criteria it is that you're looking for and what sort of qualifies things to go into the kernel. The other thing that stood out was that we were mostly talking to technical experts and we got a really good view of what it looks like and we feel quite confident in what it looks like, but the way you can improve it even further is to have broader feedback and broader input. And that's something that's that's missing and particularly if it's an allocation framework, that that becomes even more important.

It's also very important to highlight that there is no perfect allocation mechanism or no perfect allocation framework. You have to make trade-offs. You have to be very clear in what it is that you're trying to achieve and what you are clearly not. And in this case, when we look at the kernel as an allocation framework, then you're being very clear that you're looking at funding the needs and not the wants. You're also very clear on you want to fund what's critical today, what's keeping Ethereum up today, and you're not speculating too much amount about what might be coming in the future.

There might be some components like research for example where you can't know that everything in the that that gets produced by by researchers actually goes into the protocol, but it's still a very critical function. And you're also clearly looking at functions that benefit tremendously from neutral funding versus other types of funding sources, right? So it's it's it's areas that are otherwise that would be very risky if they if they become captured in one way or another. The other thing you have to think about is that you you need to have some kind of standardized framework. You need to have a clear idea of what it is that you fund and and and how you fund it and so on, but you also need to be flexible and and adaptable because you want this to be a high-quality allocation framework and therefore you need to be flexible and adaptable and Ethereum changes, right?

In the past we had proof of work, now we have proof of stake and in the future we could expect much more CK as well into the protocol and and some of the elements that were discussed in in the in the morning today. Now, I think what I've come to is that I think there are three critical elements in in making the kernel work as an allocation framework. I think first of all, you want to move to we generally want want to move more to on-chain funding mechanism and as you do that, you generally want more transparency, you want more openness and you want it to be more clear how things get funded and and what some of the sources are. You want to still I think rely primarily on domain expert input. These are the people who have the most context, they know what's going on, they know what's needed and and these are the the people that I think should help generate the baseline and the first the first version of things, but then you also should have community feedback and this is something that should be open to to scrutiny and all kinds of critical comments and because I think that that just hardens the the the framework, it hardens the allocation mechanism.

It also keeps you accountable and and and all in all I think creates a a stronger allocation framework. Now, as a bit of a conclusion concluding part, I also want to highlight that while we started out mapping the Ethereum kernel, we were also advocating quite a bit for this kernel exercise as something that can be helpful to others who are building digital systems, digital ecosystems, well, then thinking of what's core and what's critical and how you can make make sure that stays funded is a really important exercise. And we are super excited to see that other ecosystems have not only shown interest, but some of you have started mapping their own kernel. And that I would say is a is a broader, higher-level goal of hopefully seeing the kernel framework and the work around the kernel go beyond just Ethereum and help create legitimacy about Ethereum in the in the wider world. Okay, that's basically it.

I just want to finish off here and and asking or telling you how you can help this. Come to me, provide feedback, share your thoughts on on this framework, share your things on the mapping exercise. Let me know where I might be wrong. I'm looking to improve this as as much as possible. I'm looking to harden it and here I shared a little bit more about the process of getting there and and not only mapping it out, but also where we are in in terms of thinking of it as an allocation framework.

It only gets better if we get more feedback from people. So, that would be my last ask here. I'll be around here all day, so feel free to to come to me. Otherwise, my my email is here. You can also find me on on socials at Martin Breidenbach or you can come ask for my signal handle and I'll be happy happy to chat there as well.

So, yeah, thank you very much.