MaxEB: How It Affects Staking, When It Makes Sense to Consolidate, What We Can Do Going Forward...

Okay, so today we're going to be talking about MaxEV, a clear case of fuzzy outcomes and helping Ethereum feedback loops. So my name is Nixel, I used to be a marine chemist in the field of oceanography until I was Ethereum-pilled by staking and left the field of oceanography to work in the Ethereum ecosystem full-time. I was the executive director of eStaker until moving to the protocol support team at the Ethereum Foundation. So what is MaxEV? So MaxEV is a headlining feature, you probably heard of it in the Pectra upgrade that just went live on Ethereum about a month ago, 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 pre-Pectra, the MaxEV was 32 ETH, and post-Pectra, the MaxEV is now 2,048 ETH. Not to be confused with the Min Effective Balance, which pre-Pectra was also 32 ETH, so Min and Max was 32, so you could only earn on 32 pre-Pectra. Post-Pectra, you could have a validator that is anywhere from any integer between 32 and 2,048 ETH. So here we have our normal small operator, he is running a 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 lots of stake, it probably looks something more like this.

You have lots of 32 ETH validators on the same machine, you have lots of different keys, and all of the rewards above your Max Effective Balance on those validators are swept into a withdrawal address. So for a professional operator with good infrastructure and good practices, they usually have good practices that mean that it isn't terribly difficult for them to manage all these keys, but it is unnecessary overhead. And beyond that, you also have all of these validators doing signatures and sending messages, and so for the network, this is kind of a disaster because signature aggregation is quite computationally heavy. And when we talk about the decentralization of Ethereum, what we care about is 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, it doesn't at all add to the decentralization of the network to have these as discrete validators.

So raising the Max EB, the Max Effective Balance of these validators so that this operator can consolidate 64 of these 32 ETH validators makes it look more like this, so they're running a 2048 ETH validator on their machine, and they have one key for it. And again, this doesn't, consolidating does not adversely affect the decentralization of the network. So why would we want to do this? It's very desirable for research directions that require a smaller validator set size, something like single slot finality or shorter slot times or other research directions, because these large validator set sizes require a lot of signature aggregation, which is computationally really heavy. The other reason is, so this is a graph of validators over time since the beginning of the beacon chain, and you can see that when Max EB was first proposed in June of 2023, it was sort of up only, and so researchers and testing teams became concerned because they were like, 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 trend line out, we had not a whole lot of time before we reached that point. But after we hit 1 million validators, we sort of tapered off, and I think the yield and the number of validators sort of balanced out, but there is no guarantee that that tapering out will continue, especially as things like staking ETFs come online. We could see a mass influx of stake again. And so this raising of the Max EB balance essentially protects us from just a bunch of 32E validators being onboarded onto the network.

So for an individual node operator, the results of migrating are your compounding stake in one ETH increments instead of having to wait for another 32 ETH, so if you have 32 ETH and you have, for a solo staker, this is actually quite significant. If you have 32 ETH, you can stake, but if you have 31 more ETH, up to 50% of your capital is not currently productive, and you have to wait to get to that one more ETH to be able to create a new validator. But with this new Max EB balance, you can stake 32, 33, 34 ETH, and it's not auto-sweeping over 32 ETH anymore. It's just being locked in the validator, which essentially enables auto-compounding. And that can be better on accounting for some jurisdictions, some frequently asked questions.

This process is opt-in for existing validators, and actually for new validators as well, you can still opt into the old validator type. It does not change your yield. It does not change your chance proposal, so no type of validator is more advantaged over the other, except for the old ones don't have auto-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 0, type 1, type 2. Type 0 validators were validators that were spun up before withdrawals were enabled. Type 1 validators are your normal 32 ETH validator, and type 2 validators is the new type of validator that was onboarded with Pectra. So a consolidation request, the function that you use to convert your existing type 1 validator to a type 2 validator, and then once you do that, that validator can then accept consolidation requests from other validators. And yeah, you can also go straight to a type 2 validator nowadays.

So if you're spinning up a new validator, you can sort of choose between a type 1 and a type 2 validator. So who was this targeting? This was primarily targeting institutional stakers, pools with staking protocols, very large solo stakers, and it explicitly was not targeting small stakers. The reason for that is because MaxDB is trying to benefit the network. It's trying to consolidate as many validators as possible, removing unnecessary overhead by duplicating validators on the same machines, but it was beneficial for solo stakers anyway.

So how did we do? This is the number of validators over time, and this is the past year. And you can see when the MaxDB increase went live on May 7th, the number of validators trended down, and that's from consolidations. So as the validators consolidated, the number of validators on the network went down, but since then we have sort of erased those gains with the 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 graph is actually, it only goes back to May 21st, 2023, because that's when validatorq.com started collecting this data. And so if you look at the whole chart, this is a tiny little blip. And if you look at pectra.info, there's a list of entities that it shows the average balance of their validators, and you can see that 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 pie graph shows that right now, by stake, only 2% of the network are these type 2 validators. So why wouldn't large operators consolidate? 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, and 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 good paper written on this at that URL. And basically, so if you're a large staker running a lot of validators on one machine, and you have a slashing event, so most slashing events are operator error, they're usually like somebody sets up, somebody wants to move their validators to a different machine or they want to set up some redundancy, and they accidentally run their keys on two machines at once. So if you do this, and you're a very large operator, what usually happens is because of the way attestations work, you see a portion of your validators 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 validators were probably all slashed at once because you only have a small number of validators on that machine. So the different, the adjusted slashing risk is not a larger dollar amount getting slashed, what it is is putting the slashing risk, or putting more of your stake in a slashed state, which essentially is just embarrassing for the professional operator.

And the reason it's not a larger dollar amount is because 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 1 ETH per 32 ETH to 0.0078 ETH per 32 ETH, which is like 30 bucks or less, and so that scales linearly up to 2,048 ETH to half an ETH. So the dollar amount that you're getting slashed is actually less than before. Another reason is, so a couple of professional operators did posts that were doing calculations on how much more they can make, because when these professional operators are advertising to centralized exchanges or big stakers, these tiny differences in APY make a huge difference to the customers that they end up being able to service. And beyond about 500 ETH, the difference that you're getting in auto-compounding is less than 0.

01%, and so some of these institutional stakers decided that there was like a level where this increased APY was sort of balanced with the suggested slashing risk. 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 1 to a type 2, so they reach out to their customers and say, do you want to do this? And 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 have heard about this suggested slashing risk, and they're like, I've heard there's increased slashing risk, and so it's really, at that point, it's like an educational campaign that is required for that. For some protocols, it's going to require a protocol change.

So if your withdrawal address is a smart contract, it's not compatible with the MaxDB change, and so what you would have to do is change your protocol, exit your validators, and then re-enter your validators, which is a lot more of an ask than just converting. So the question becomes, did we fail? The TLDR is yes and no, but we somewhat expected this. Changing the Max Effective Balance lays the groundwork for future research directions, and it was not trivial. When MaxDB was first proposed, people thought that it was going to be a much easier upgrade than it was going to be, than it ended up being, because this 32-each number was kind of hard-coded everywhere, and so doing this sooner rather than later was good because it meant that all of the infrastructure sort of came to expect a variable amount for each validator.

I have talked to some of these professional operators, and a lot of them are planning on using MaxDB on some timeline. Lido posted a blog post that says that they're going to start this process for their curated set in Q1 of 2026, and if we look at the number of validators that we have today, it's just over a million, and this number was actually the number that I saw two days ago when I made this. So if you divide that by 64, say, in an ideal world, every single one of these operators consolidated maximally, you would get 16,000 validators. However, we know that a lot of the nodes are small stakers or solo stakers, and so they can't consolidate them maximally. So say we tripled this, we would still get to around 50,000 validators, and that would still be excellent for future research directions because aggregating the signatures for a million validators is much more difficult than aggregating the signatures for less than 100,000 validators.

So just because this wasn't a failure doesn't mean everything went perfectly. 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. This is a post that RocketPool made about a month before the upgrade, and essentially it's RocketPool saying, hey, we took a look at the specs for this feature upgrade 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 in a way that made RocketPool compatible with this, and they didn't realize it until a month before the upgrade. So I reached out to a bunch of other liquid staking protocols, a bunch of other DBT protocols, large operators to make sure that this wasn't a widespread misunderstanding, and it was a widespread misunderstanding, and there were several entities who did not see this change happen in the spec. And so we published this plain language interpretation of the specs, which, going forward, we would like to see more plain language interpretations of the specs so that there's no ambiguity and people are actually getting the right message from the specs.

And specifically for me, I will be paying attention and making sure that any staking-related changes have this page on Ethereum.org. 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, learning 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 should be able to predict the rate of adoption for this feature before the upgrade goes live. So this brings me to my newly formed team at the EF, which came out of the EF reorg a couple weeks ago.

And I think that the pipeline should be clear from basically research all the way to the player. And so my team is approaching protocol upgrades 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. And also, like, who to contact for help running tests and things that you need to get an actual spec for these changes. And on the other side, once an upgrade comes out, the upgrade is useless if the app player is not implementing, if it's not integrating these features, especially if they don't know how it works or they weren't planning on integrating it.

So making sure that this app player has the contacts that they need to be able to integrate these features. And then also making sure that those arrows go in the other direction, because basically the users are communicating their desires to the app player. And the app player, if they can't do that solely, if they can't, like, make those changes solely at the app player, they need to communicate those changes back to the core devs and researchers, and they need a clear pipeline to be able to do that. So that would ensure that, that better ensures that 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 is not ideal for the people who are actually using the chain. Yeah.

So if you have any interest in this process, in making this process clear, and maybe 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. Hi. Yeah.

At the start of the talk, you mentioned that having the small Mac didn't help in terms of, you know, getting a varied stack. I know this isn't really 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 here looks like, especially that it seems that it's even more challenging to even migrate folks than I would have anticipated. So thank you for sharing that. Really, really insightful. But, yeah, what's the path?

Is there any, are there any plans for correlation penalties and so on? Yeah. So anti-correlation penalties, I would love if someone decided to be the champion of that, because it seems to me that it has sort of stalled in research and implementation. And I actually, I brought it to the solo staking community recently to be like, should we champion this? And the reviews were really mixed on it, which surprised me.

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? And so there needs to be, like, a lot more data and research and, like, 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. In terms of making the network more decentralized, something's been floated, like, lowering the which, for me, is not necessarily going to work as well until we have much lower hardware requirements.

Because at this point, basically, if you're a solo staker who is staking 32 ETH, it takes you somewhere between six 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 And by that time, you're replacing hardware. And so things like light clients will help, but anything that brings down the cost of that hardware enables us to start onboarding, 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, why, like, 2048 and not something else? Like, how was it chosen? I don't know. Okay.

And second, like, why do we need the max to be balanced at all? Like, is there some kind of clear reason? Or just wouldn't it be free at all? You know, I don't know the answer to that. I assume that they're, like, a bound is good just because infrastructure needs to know what to expect.

But I don't know 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, 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, yeah.

Yeah, the fact that professional operators are even hesitating to going to the max 2048 ETH balance, they're talking about going to 512s to, like, balance out the staking, the adjusted staking risks, tell me that, like, they probably wouldn't go higher than that anyway. Especially because if you look at the LIDO operators, they divide, the curated set, like, divides how many ETH 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 risks or the slashing risks. Do type 1 validators get the compounding interest and also the different staking risks? Or is it DF upgrades type 2 to get the compounding rewards?

So they do not get the compounding. So right now, if you run a type 1 validator, you are still, all of your balances above 32 ETH are still swept to your withdrawal address. And so you have to upgrade to a type 2 validator in order to take advantage of those. And they all have the, all validators on the network are subject to the lower slashing risk. And I actually was thinking about it while writing this presentation.

I didn't hear the conversation happen. And I don't know if this would have made a difference. And I don't even know if it was possible. 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 2 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. So two quick questions. Do you think that the January 2026 thing will be the, when Lido 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's, the Lido staking set is kind of unique in that the people whose stake they run don't really have a say in the configuration of those validators. Whereas a lot of big operators, their customers by the contracts that they have by have a say in how those validators are run. So they still need consent of those customers. But maybe once that happens and Lido actually consolidates and it sort of like reverberates through the ecosystem that like type 2 validators are better and like a lot of the ecosystem is doing it.

So maybe these customers opt in and other staking protocols that also have full control over the 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 2? Yes. Hell yes.

And actually like this wasn't geared towards solo stakers, but just from hanging out in the e-staker discord, I have seen a huge amount of conversions from solo stakers, 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 converting does allow you to keep your validator index. And yeah, it makes it for a solo staker, it makes your capital much more productive. Thank you.

I think that's it. Thank you very much.