DAPPCON 2025: MaxEB: How It Affects Staking, When It Makes Sense to Consolide - Nixo

Transcript

Um, okay. So, today we're going to be talking about Max EB, a clear case of fuzzy outcomes and helping Ethereum feedback loops. So, um, my name is Nixo. I used to be a marine chemist in the field of oceanography, um, until I was, uh, Ethereum pilled by staking and left ocean the field of oceanography to work in the Ethereum ecosystem full-time. Um, I was the executive director of ESTaker until moving to the protocol support team at the Ethereum Foundation. So, what is Max EB? Um, so Max EB is a it was a headlining feature. You probably heard of it um in the Pectra upgrade that just went live on Ethereum

about a month ago. Um, and it stands for the maximum effective balance of a validator. So, when you have a validator, you have a certain number of ETH that you are able to earn yield on. And this is uh pre-pectra this was the max EB was 32 ETH and postpectra the max EB uh is now48 ETH not to be confused with the min effective balance um which prepra was also 32 E. So min and max was 32 so you could only earn on 32 prepra postpectra you can have a validator that is anywhere from any integer between 32 and48 E. So here we have our our uh normal uh small operator. He is running

a 30 32 ETH validator on his machine. He has a key for his validator and anything above that max effective balance gets swept into his withdrawal address. However, if you are a professional staker and you're running lots of validators or you're running uh lots of stake, um it probably looks something more like this. you have lots of 32 ETH validators on the same machine. You have lots of different keys. Um, and all of the valid or all of the rewards above your max effective balance on those validators are swept into a withdrawal address.

Um, so for a professional operator with good uh with good infrastructure and good practices, it isn't um they they usually have good practices that mean that it isn't terribly difficult for them to manage all these keys. Um but it is unnecessary overhead. And beyond that you also have all of these validators signing uh doing signatures and um sending messages. And so for the network, this is kind of a disaster because signature aggregation is is quite computationally heavy. And uh when we talk about the decentralization of Ethereum, what we care about is uh node diversity and operator diversity. And so all of these validators are running on

the same machine run by the same node operator probably in the same jurisdiction. So it doesn't really not it doesn't at all add to the decentralization of the network to have these as discrete uh validators. So raising the max EV the max effective balance of these validators so that uh this operator can consolidate 64 of these 32 E validators makes it look more like this. So they're running a 248 ETH validator on their machine and they have one key for it. And again, this doesn't consolidating does not uh adversely affect the decentralization of the network.

So why would we want to do this? Um it's very desirable for research directions that require a smaller validator set size. Um something like single slot finality or shorter slot times or other research directions. uh because these large validator set sizes uh require a lot of signature aggregation which is computationally really heavy. The other reason is so uh this is a graph of validators over time since um the beginning of the beacon chain and you can see that when max was first proposed in June of 2023 it was sort of up only and so researchers and testing teams became concerned because they were they were like I don't we we don't know

how many signatures we can aggregate with our current system. So they tested and around 2.1 million validators the network just sort of fell apart and at this point it was 6 to 700,000 and if you had extrapolated that uh that trend line out it we had um not a whole lot of time before uh we reached to that point but after we hit 1 million validators we sort of tapered off um and uh the I think the yield and uh the yield and the number of validators sort uh balanced out but there is no guarantee that that that tapering out will continue especially as things like staking ETFs come online. Um we could

see a mass influx of uh of stake again and so uh this raising of the max effective balance essentially protects us from um just a a bunch of 32e validators being onboarded onto the network. Um so for a individual node operator the results of migrating are you're compounding stake in one ETH increments instead of um having to wait for another 32 ETH. So if you have 32 ETH um and you have for solo staker this is actually quite significant for uh if you have 32 ETH you can stake but if you have 31 more ETH up to 50% of your cap capital is not currently productive um and you

have to wait to get to that one more ETH to be able to um create a new validator. But with this new max effective balance you can stake 32 33 34 ETH um and the it's not auto sweeping over 32 ETH anymore. it's just being left in the validator which essentially enables autoco compounding. Um and that is uh that can be like better on accounting for some jurisdictions. Um some frequently asked questions. Uh this process is opt in uh for existing validators and actually for new validators as well. You can still opt into the old uh validator type. It does not change your yield. It does not change your chance proposal. So no type of validator is u more advantaged over

the other except for um the old ones don't have autoco compounding. So how is this done? There's a new function that was introduced with pectra called the consolidation request function. And essentially if you have a so there are three types of validators. Type zero, type one, type two. Type zero validators were validators that were spun up before withdrawals were enabled. Type one validators are your normal 32E validator and type two validators is the new type of uh validator that was onboarded with uh PCRA. So a consolidation request um the the function that you use to convert your existing type one validator to a type

two validator and then once you do that that validator that validator can then accept consolidation requests from other validators. Um, and yeah, you can also go straight to a type two validator nowadays. Um, so if you're spinning up a new validator, you can sort of choose between a type one and a type two validator. So who was this targeting? This was primarily targeting institutional stakers, um, pools, liquid staking protocols, very large solo stakers, and it explicitly was not targeting small stakers. The reason for that is because Max EB is trying to benefit the network.

It's trying to consolidate as many validators as possible, removing uh unnecessary overhead by duplicating validators on the same machines. Um but it was beneficial for solo stakers anyway. Uh so how did we do this is uh validate the number of validators over time uh and this is the past year and you can see when the max EB increase went live on May 7th uh the number of validators trended down and that's from consolidations. So as these validators consolidated, the number of validators on the network went down. But since then, we have sort of erased those gains with the uh number of validators that have come online since then. And putting

this into perspective, if you zoom out, that's but a tiny blip. And this this graph is actually it only goes back to May 21st, 2023 because that's when validator.com started collecting this data. And so if you look at the whole chart, this is a tiny little blip. Um, and if you look at pectra.info, there's a list of entities that it shows the average uh balance of their validators. And you can see the top six that have consolidated are likely solo stakers. And this is not a comprehensive list.

This is just you can scroll down in the website and it probably goes three times as long as this. And you can see that not a single professional operator has consolidated yet. And the piraphph shows that right now by stake um only 2% of the network are these type two validators. So why wouldn't large operators consolidate? Uh essentially Lindy effect. So they would want to wait until they know that it's safe and that others have done it and there are no issues. uh and uh they have adjusted slashing risks. And I want to caveat that with that's not increased slashing risks, it's just different slashing risks. And there's a there's a

good paper written on this um at that at that URL. And basically uh so if you're a large uh if you're a large staker running a lot of validators on one machine and you have a slashing event, so most most slashing events are um operator error. They're usually like somebody sets up somebody wants to move their validates to a different machine or they want to set up some redundancy and they accidentally run their keys on two machines at once. Um so if you do this and you're a very large operator, what usually happens is uh because of the way add a station work, you see a portion of your validator slashed and then a professional operator who has

notification set can run to their computer. they can log in with their credentials and they can shut down their Docker instance before more validators get slashed. If you're a solo staker, your your validators were probably all slashed at once because you only have a small number of uh validators on that machine. So the different the adjusted slashing risk is not um a larger uh dollar amount getting slashed. What it is is putting uh the slashing risk or putting more of your stake in a slashed state which essentially is just embarrassing for the uh for the professional operator. Um, and the reason it's not a a larger dollar amount is because uh professional operators were part of this conversation

and this was a concern that they raised. And so in response to that, the slashing the initial slashing penalty was moved from uh 1 ETH per 32 ETH to 0.0078 ETH per 32 ETH, which is like 30 bucks or less. Um, and so that scales linearly up to 2048 ETH to half an ETH. So the the dollar amount that you're getting slashed is is actually less than before. Um, another reason is autoM. So these a couple of professional operators did uh posts that were doing calculations on uh how much more they can make because when these professional operators are

advertising to centralized exchanges or big stakers, these tiny uh differences in APY make a huge difference to the customers that they end up being able to uh service. And uh beyond five about 500 ETH, the difference that you're getting in autoco compounding is less than 0.01% 01% and so um some of these institutional stakers decided that there was like a level where uh this increased APY was sort of balanced with this suggested slashing risk. Um another reason is customer choice. Some of these operators don't have the autonomy to decide I'm going to move your validator from a type one to a type two. So they reach out to

their customers and say uh do you want to do this? And um I've talked to some professional operators who have said that they've talked to the customers and some of them are like just don't touch anything. It's working fine. And some of them um have heard about this adjusted slashing risk and they're like I've heard there's increased slashing risk. Um and so it's really uh at that point it's like an educational campaign that is required for that. Uh for some protocols it's going to require a protocol change. So if your withdrawal address is a smart contract, uh it's not compatible with the MAX EB change. And so what you would have to do is change your protocol, exit your validators, and then reenter your

validators, which is a lot more of an ask than just converting. So the question becomes, did we fail? Um the TLDDR is yes and no, but we somewhat expected this. uh changing the max effective balance lays the groundwork for future research directions. Um and it was not trivial when max was first proposed. Uh people thought that it was going to be a much easier upgrade than it was going to be than it than it ended up being because this 32 ETH number was kind of hardcoded everywhere. And so um doing this sooner rather than later was good because it meant that all of the infrastructure sort of um came to expect a variable uh a variable amount for each

validator. Uh I have talked to some of these professional operators and a lot of them are planning on using MAC EB on some timeline. Um, Lido posted a blog post that says that they're starting they're they're going to start this process for their curated set in Q1 of 2026. Um, and if we look at the number of validators that we have today, it's just over a million. Um, and this number was actually the number that I saw yesterday or two days ago when I made this. Um so if you divide that by 64 say like in an ideal world every single one of these um operators consolidated maximally you would get 16,000 validators. However we know that a lot of the nodes are small

stakers or solo stakers um and so they can't consolidate down uh maximally. So say we tripled this, we would still get to around 50,000 validators and that would still be excellent for um future research directions uh because consol or aggregating the signatures for a million validators is much more difficult than aggregating the signatures for less than 100,000 validators. Um so just because we didn't just because this wasn't a failure doesn't mean everything went perfectly. Uh, I think one of the learnings that I've taken away is that we need to make sure that our biggest operators, pools, and liquid staking protocols fully understand the specs and in turn that we understand how this is going to affect

protocols and whether or not they're compatible with these things. Uh, this is a post that Rocket made about a month before the upgrade. And uh essentially it's RocketPool saying, "Hey, we we took a look at the specs um for this feature upgrade uh about a year ago and it was not compatible with RocketPool. So we didn't look at it and we just looked at it again and the spec actually changed uh in a way that made Rocket Pool compatible with this and they didn't realize it until a month uh before the before the upgrade. So I reached out to a bunch of other liquid staking protocols, a bunch of other DBT protocols, um large operators to make sure that this wasn't um a widespread

misunderstanding. And it was a wide spread uh misunderstanding. And there were several um entities who did not see this change um happen in the spec. And so uh we published this plain language interpretation of the specs which um going forward uh we would like to see more plain language interpretations of the specs so that there's no ambiguity and there's no um and people are actually like getting the right the right message from the specs and um specifically for me I will be paying attention and making sure that any staking related changes have this page on ethereum.org Um, and keeping this conversation going

with staking protocols and large operators allows us to better predict whether a feature is going to be adopted and how quickly it's going to be adopted. Because in my opinion, um, learning how how much and how fast a feature is going to be adopted after the upgrade goes live is not the right time to be knowing. you you should be able to predict um the rate of adoption for this feature before the upgrade goes live. Um so this brings me to my new my newly formed team at the EF which um came out of the EF reorg a couple weeks ago. Um and I think that the pipeline should be clear from basically research um all the

way to the app layer. And so my team is approaching protocol upgrades um in two different directions. Basically, what goes into the upgrade and then what comes out of the upgrade. For what goes into the upgrade, it should be very clear to people how to propose an EIP, how to champion an EIP, and how to get it into the upgrade. Um and and also like who to contact for help um running tests um and things that you need to get um to get an actual um spec for these for these changes. Uh and on the other side, once an upgrade comes out, the upgrade is useless if the app layer is not implementing if if if it's not integrating these features. Um especially if they don't know how it

works or they weren't planning on integrating it. So, uh making sure that the this app layer has um the contacts that they need to be able to integrate these features. Um and then also making sure that those arrows go in the other direction because basically the users are communicating their desires to the app layer and the app layer if they can't do that solely if they can't like make those changes uh solely at the app layer they need to communicate those changes back to the uh core devs and researchers and they need a clear pipeline to be able to do that. um that would ensure that that better ensures that uh the core devs and researchers are putting things into the upgrade that

are actually desired and needed rather than just like making a chain that um that is not ideal for the people who are actually using the chain. Um yeah, so if you have any interest in this uh in this process and making this process clearer and maybe um integrating the features that have come out of the upgrade, you can contact me. This is my email address. And that's all I have for today. [Applause] Hi. Yeah, at the start of the talk you

mentioned that um having the small um max didn't help in terms of you know getting a varied um stack. I know this isn't really uh the topic, but I was curious how far along we are with stuff like correlation penalties and what yeah what the path towards like true decentralization um here looks like um especially that it seems that it's even more challenging to even migrate uh folks than I would have anticipated. So thank you for sharing that. Um really really insightful. But yeah, what's the path? Is there any are there any plans for correlation penalties and so on?

Yeah. So, um, anti-correlation penalties, um, I would love if someone decided to be the champion of that, um, because it it seems to me that it has sort of stalled in, um, research and implementation. And I actually I brought it to the solar staking community recently to be like, should we champion this? And the the reviews were really mixed on it, which surprised me. Um, solo stakers opinions are constantly surprising me, but basically they were like, what if we're a really large solo staker and we're hit by these anti-correlation penalties? Um, and so there needs to be like a lot more data and research and like uh things that show who's affected by those things. And so there's a lot more work that needs to go into anti-correlation penalties before it could be proposed for an

upgrade. Um, in terms of making the network more decentralized, something's been floated like uh lowering the min effective balance, which uh for me is not necessarily going to work as as well until we have much lower hardware requirements because at this point basically if you're a solo staker um who is uh staking 32 ETH, it takes you somewhere between 6 months to a year to make up the cost of your hardware. But if you drop that to one ETH, it could take you 10 years to make up the cost of that hardware. And by that time, you're replacing hardware. Um, and so, um, things like light clients will help. But anything that brings down the the cost

of that hardware, um, enables us to start onboarding, uh, like features that would enable smaller staking sizes. Thanks for the very nice talk. So I have like two related questions. So how did this value was chosen? Like uh why like uh48 and not something else like how was it chosen? I don't know. Okay. And second like why do we need the max balance at all? Like is there some kind of uh clear reason or couldn't it be free at all?

Like you know I don't know the answer to that. I assume that there like a bound is is good just because um infrastructure needs to know what to expect but um I don't I don't know that the answer to that because I have the feeling that if we increase it a lot more then this will like potentially if they actually do the upgrade uh it could potentially decrease even further the number of validators to even less than 10,000 and then this will make room for decreasing the mean effective balance as well perhaps Perhaps perhaps. Yeah.

Yeah. The fact that uh val professional operators are even hesitating um to going to the max 2048 ETH balance. They're talking about going to 512 to like balance out the staking uh the adjusted staking risks. Um tell me that like they probably wouldn't go higher than that anyway, especially because if you look at the LITO operators, they they um divide the curated set like divides how many um eat they have per operator. And I think a lot of those like max out the number of validators that they run on one machine just to like distribute the staking risk or the slashing risks.

Um do type one validators get the compounding um interest and also the different staking risks or is it do you have to upgrade to type two to get the compounding rewards? Um so they uh do not get the compounding. Um, so right now if you run a type one validator, you are still all of your balances above 32 ether still swept to your withdrawal address and so you have to upgrade to a type two validator in order to take advantage of those. Um, and they all have the they all validators on the network are subject to the lower slashing risk. And I actually was thinking about it while while writing this presentation. Um, I didn't hear the conversation happen and I don't know if this is would have made a difference but

and I don't even know if it was possible. Um, but I wonder if it might have better incentivized professional operators to take advantage of this if we had restricted the lower staking penalty to only the type two validators because that's a very significant decrease in initial staking penalty. But I was just thinking about that while making this a couple of days ago and I was like I should have brought that up before the upgrade happened. Thanks Nick. So two quick questions. Do you think that the January 2026 thing will be the when Leo upgrades will be the thing that gets rid of the Lindy effect and we'll see a lot more institutional staking providers kind of

move over? I hope so. But Lido the Lido uh staking set is kind of unique in that uh the um people whose stake they run don't really have a say in the configuration of those validators. Um whereas a lot of big operators their customers um by their by the contract that they have staked uh by have uh a say in how those validators are run. So they still need consent of those customers. But um maybe once that happens and Lido uh actually consolidates and it sort of like reverberates through the ecosystem that like type two validators are better and like a lot of the ecosystem is doing it.

maybe these customers opt in um and other staking protocols that also um have full control over their validators can start to opt in. Cool. And if I'm like a casual solo staker like small one, do you recommend just going straight for signing up for type two? Yes. Hell yes. Um, and actually like this wasn't this wasn't geared towards solo stakers, but uh just from hanging out in the East Staker Discord, I have seen a huge amount of um con conversions from solo stickers, especially because a lot of them are Genesis solo stakers.

And so a lot of them were like, can I keep my index? And that um converting does allow you to keep your your validator index. Um and yeah, it makes for a solo staker, it makes your capital much more productive. I think that's it.