The recent launch of additional Lido staking router modules such as SimpleDVT raises the question how ETH deposited into the Lido protocol should be distributed across the different emerging modules. With this post I, Felix Lutsch - a long-term contributor to the staking ecosystem - is applying for a LEGO grant to examine this problem statement. The grant will facilitate research that seeks to provide the basis for a DAO decision on what mechanism to use to allocate ETH to staking router modules within Lido. My key contributions and affiliations can be found here.
TL;DR
Grant for a research report that provides a comprehensive list and comparison framework for the Lido DAO to evaluate distribution mechanisms of ETH to staking router modules such as SimpleDVT.
Proposal Background
The status quo for staking router modules is currently a testing phase with minor amounts of the total Lido-controlled stake going towards accepted modules through a one-off governance vote to kickstart and assess module viability. As accepted modules mature and further modules emerge, a mechanism to determine how ETH deposited into Lido should be allocated towards modules is required. To illustrate with an example; should the curated module receive 90% of the stake, while SimpleDVT and Community Staking receive 5% each? Or should the stake be split evenly between all modules? How dynamic should the distribution be? Should it be possible to limit how much stake modules can receive? This grant seeks to produce a research report that provides the necessary context, an exhaustive list of options, as well as a comparison between hypothetical mechanisms for distributing ETH to staking router modules on a continuous basis. This research will also include insights from discussions with key Lido DAO stakeholders and take into account existing research and deployed mechanisms in the crypto space (e.g. Curve’s gauge mechanism). I also invite interested Lido DAO contributors, enthusiasts and researchers in general to provide their input in this thread or by reaching out to me directly for consideration in the final report.
Grant Milestones
Final research report detailing the context, different potential mechanisms of distribution, as well as a framework seeking to compare and evaluate distribution mechanisms (internal review with key Lido stakeholders and subject matter experts throughout Q1 2024 and publication by the end of Q1 2024). Current expected outline (subject to change as research progresses):
Thank you for the proposal! LEGO Council voted to support the initiative, the first leg of payment to be sent soon! Looking forwards for the research =))
Hello, Felix! Thank you for the proposal. As a Lido DAO contributor, I would like to highlight that stake allocation highly depends on the actual module capacity. In the case of the Curated module, the validation capacity is technically unlimited since Node Operators can upload as many keys as they want with no additional requirements. For Simple DVT, capacity is also more or less unlimited; however, increasing the capacity is more challenging here. For CSM, the situation is different. With the bond requirement, one can assume that validation capacity will be limited. Rocket Pool is a good illustration here. Due to the bond requirements, they have been facing a validation capacity shortage for a while. For sure, CSM will offer competitive bonding conditions (lower bond, no additional tokens). However, the bond requirement will affect the validation capacity of the module.
It would probably make sense to interview some contributors from the technical side as well, especially e.g. @George and @TheDZhon, @ujenjt since they have a lot of experience thinking about the staking router from a technical feasibility perspective and outlining how SR functionality and objectives in the future might impact technical considerations.
Thank you, Felix! I can speak on the technical side of distribution within StakingRouter. During the RnD phase, we’ve explored various distribution algorithms. But for the initial version of StakingRouter, we ultimately opted for a straightforward distribution algorithm, which was adequate at the time. However, with the impending launch of multiple modules, each having distinct staking mechanisms, we need a more advanced algorithm, and your initiative is most timely.
Key considerations include each module’s validation capacity, the DAO-imposed target shares, and maximizing capital efficiency. As such, the distribution will likely need to incorporate a self-correction mechanism to address significant discrepancies between current capacities and module shares to maximize APR.
Thanks for the support and really excited to continue working on this (I had already started fwiw :P)!
These are some great points @dgusakov - will take this into consideration and would love to speak to you at some point in the next few weeks when I have fleshed out the skeleton a bit more.
Thanks Izzy and nice to meet you @azat_s, that’s super valuable. Would love to get your thoughts in person later too, esp. regarding technically feasibility. I will likely initially operate from a minimally technical-constraint perspective to get a comprehensive view of high-level options but would be great to then consider such insights when I have collected some potential approaches.
Decided to make a Telegram group for ad hoc discussions and questions that might appear during the research that would be too much for the forum. DM me here or @FelixLts if you are interested to join and I’ll add you. Will provide summaries/updates to the forum in this thread
Hi all, planning to give a short weekly update on what is going on with the research and in the TG group (still open for people to join):
used first week to continue on outline and context of the staking router and its modules within Lido
first draft of introduction, and sections on characteristics and lifecycle of staking router modules are done
TG group discussions mostly around questions about these topics and nuances of the staking router implementation esp. wrt capacity of modules. Thx all for the helpful input there!
Next week:
starting on sections regarding potential distribution mechanisms and looking into existing research (e.g. Curve gauge)
I’m glad to see this proposal, thank you @FelixLts! The task to come up with the stake distribution mechanism is indeed very relevant and quite ambitious
I’m very curious in how you will approach the issue of taking into account relevant parameters in the construction of such a mechanism (especially, modules’ fee structures). Also, I think that the list of parameters for modules does not look quite complete yet.
The way I see it, the mechanism should provide a stake distribution that will (at any point in time) drive the Lido validator set to a state that is closest to some “target state” that has been defined for it. Following this goal statement, the first things to determine are:
How the parameters of this “target state” are set:
who sets them? (DAO? Ethereum ecosystem/community? DAO-approved algorithm?)
in what form are they set? (verbally described state? in the form of constraints? in the form of specific parameters’ values?)
whether this target state is static or dynamic (e.g., if this target state can change depending on the current state of the entire validator set on Ethereum)
What parameters of the modules should be taken into account in order to estimate how the current state of the validator set corresponds to the target state (e.g., we need to know about each module its performance, number of operators, current % of stake, +1000 other parameters)
At first glance it seems that one of the possible options of the distribution mechanism can be based on a kind of a multi-objective optimization task.
Again, very abstractly speaking, let’s imagine that a set of functions and constraints act as the target state of the validator set:
Functions:
A function to maximize the diversification of the validator set.
This should be a function that takes into account a lot of other parameters (both dynamic and static) that will have dependencies beyond the Lido validator set. And some of these parameters in general will be almost impossible to estimate objectively and in the moment (such as geographic and jurisdictional distribution, for example)
Reward maximization function, which depends on the performance of each module and its risks and and and…
Risk minimization function …
Constraints:
the total DAO commission from all modules must not be below a certain value to cover the costs of maintaining and developing the protocol (taking into account the ETH/USD exchange rate dependency)
And and and…
With the addition of each next condition, the task becomes more and more complicated
More details on what specific parameters can be taken into account to estimate diversification and efficiency are described here, and also @Mol_Eliza is working on defining what the best validator set is
Is this even remotely similar to how you see the approach to solving this problem, or have I described the wrong thing altogether?
Anyway, I will be very interested in observing the process of creating such a mechanism and happy to help in any way if possible
I believe it is also important to define points where stake distribution actually might change. Forced redistribution might be too resource-consuming. In the current approach, 2 actions might change stake distribution:
Stake inflow
Stake outflow
With the outflow, things seem to be a bit simpler since the off-chain part of the VEBO decides what validators should be withdrawn. In contrast, inflow is fully managed on-chain by the staking router. This means that having a complicated model with 1000+ parameters might not be feasible to implement on-chain. One may say that oracles can also be used to manage inflow stake distribution, but it makes protocol even more dependent on trusted Oracles.
My suggestion here will be to rely on a combination of parameters that are available on-chain and DAO governance. With EIP-4788, we now have access to all of BC’s data in a trustless way. However. params like client diversity or HW setup used are not available on-chain (and will hardly ever be). This is where governance comes into play. Allowing governance to supply params values instead of actual shares on-chain will be great. With all these data, the on-chain algorithm can determine inflow stake distribution, also taking into account available capacities.
Thanks for the input! I did indeed expand on parameters (above was a first draft) to take into account decentralization and performance metrics as well as module capacity. So the initial part of the research is basically seeking to clarify how modules can differ and how that can be compared.
Then, the second part goes into distribution model options (governance-based, token-based, algorithmic). What you describe would fall under the 3rd class, i.e. algorithmic distribution. Haven’t gotten too far on that besides looking e.g. at how Jito and Marinade do their algorithmic distribution on Solana. Currently thinking to include some breakdown of what is available on-chain plus some thoughts on how additional inputs could be brought on-chain (i.e. oracles or governance-based inputs that Dmitry is describing, which I look at as “hybrid models”).
My goal is to have a comprehensive overview that can form the basis for deciding on next steps for the Lido DAO - highlighting pros and cons/limitations of different implementations. Hope this helps provide some context, I’ll be sharing some more on the current state of my work EOW and likely will make a draft of the initial work available soon after.
Literature review of distribution algorithms in staking/defi mostly done
Added section on transition from current module to multi module Lido and implications of a migration of validators plus discussion of possible workarounds (key rotation and prioritized exits) and some initial recommendations on how to move forward
Sensitivity analysis on migration dynamics (more below)
next two weeks will heavily focus on writing about potential distribution models
Re: sensitivity analysis, here’s an excerpt from my message on it on TG:
Happy to finally share the sensitivity analysis on stake migration between Lido modules here in terms of expected time impact and expected opportunity cost to stETH holders, Lido DAO and operators if vals have to be exited and re-activated:
I am not taking into account other activations/exits in this. The goal being to show the best case scenario and implied impact and esp duration a migration of significant amount of validators would take.
Lmk if there are questions! I’ve also written about this piece and have chatted a bunch with @georgeavs about the current withdrawal process (VEBO) and how taking into account validators migrations between modules could work in the current (and potentially soon (with EIP-7002) expanded) Lido flow. Also highlighting discussions around validator key rotation and prioritize exits
TL;DR:
limiting migrations to avoid triggering queues is desirable due to opportunity cost involved
conservative(-ish) assumptions mean migration of e.g. 10% Lido of stake could take at least 35 days (also taking into account delay of exiting validators (assuming no slashing)).
opportunity cost due to these exit delays are still significant, e.g. for 10% of Lido stake it would amount to $500k-1m opp cost in lost rewards shared between stETH holders, Lido DAO and operators
Considering the cost involved with migrations, it seems best to try avoid them altogether.
How possible would it be to avoid migrations by just adjusting the flows of new validators based on some desired ratios.
For example, if going from desired 100%/0% Curated:DVT to 90%/10% Curated:DVT, instead of doing a migration, just disable new validator allocation for Curated until DVT reaches 10%.
Right, but you are relying on new flows in such a model. For sure new flows should be used first, but I think some minimal amount of migration will make sense since otherwise you might be looking at some desired state that may never be reached.
With EIP-7002, migration can be done by simply triggering exits (or requesting NOs to exit) for N validators. With no demand for unstake, the funds will be staked back using inflow params. Is that the migration you are talking about here?
Yes, example: say 10% of stake target share for CSM. If that’s to be achieved only from new flows it’ll take a while, potentially if Lido hits some plateau of growth it cannot be reached purely on new flows. Migration = exit validators from existing module to then stake with other module / deposit new validators with new module.
Hi all, I’m pleased to announce that I have finished a final draft of the report that I am currently looking for feedback on, so I can address questions or add further context and clarifications before the full release. You can read and comment on it here:
I will do one more run of edits before sharing the final version more widely and presenting the output in one of the upcoming Lido community calls. Excited to hear some early thoughts!
One small thing that I noticed in the doc was that the 8% module fee is always split 87.5% to NOs and 12.5% to DVT providers, but IIRC only Obol takes that fee and for SSV the full amount goes to the NOs.
