# 🏞️ Community staking landscape
*Special thanks to [Isidoros Passadis](https://twitter.com/IsdrsP), [Eugene Pshenichniy](https://twitter.com/PsheEth), [kadmil](https://twitter.com/kadmil_eth), [George Avsetsin](https://research.lido.fi/u/george/summary) and [Max Merkulov](https://research.lido.fi/u/mol_eliza/summary) for feedback and review.*
> “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
> — Albert Einstein
1. [TL;DR](#TLDR)
2. [Intoduction](#Introduction)
3. [Problem statement](#Problem-statement)
4. [Possible approaches to Community Staking](#Possible-approaches-to-Community-Staking)
- [Bond vs Reputation](#Bond-vs-Reputation)
- [DVT vs Solo](#DVT-vs-Solo)
- [Current market state](#Current-market-state)
5. [CSM Goals and Constraints](#Community-Staking-Module-CSM-Goals-and-Constraints)
- [Goals](#Goals)
- [Constraints](#Constraints)
6. [Node-Operator-UX](#Node-Operator-UX)
7. [Integration with Staking Router](#Integration-with-Staking-Router)
- [Rewards](#Rewards)
- [Stake allocation](#Stake-allocation)
- [Protocol requested exits](#Protocol-requested-exits)
- [Tooling updates](#Tooling-updates)
8. [Design](#Design)
- [Bond](#Bond)
- [Stake allocation queue](#Stake-allocation-queue)
- [Voluntary exits](#Voluntary-exits)
- [Performance Oracle](#Performance-Oracle)
- [MEV stealing detection and penalties](#MEV-stealing-detection-and-penalties)
- [Module initiated validator ejections](#Module-initiated-validator-ejections)
9. [Partnerships](#Partnerships)
10. [Conclusion](#Conclusion)
# TL;DR
This document provides an overview of the Community Staking Landscape, focusing on the use of DVT and permissionless entry with bond options. Among these options, permissionless entry with a bond is currently seen as the more practical choice for immediate implementation. The proposed **Community Staking Module (CSM)** is expected to achieve a strong market fit by offering competitive economics. This will be accomplished through minimal bond requirements, reasonable staking fees, MEV (Maximal Extractable Value) smoothing, and a user-friendly experience for community stakers. Specific module parameters, such as the bond size and staking fee share, will be determined later to ensure the best possible conditions at the time of launch. As of the time of writing, a combination of a 4 ETH bond and a 7.5% staking fee appears to be a promising option. The proposal is designed to significantly increase the total number of Node Operators in Lido on Ethereum and allow them to join the Lido validator set permissionlessly.
# Introduction
The term “community stakers” has been [widely used](https://research.lido.fi/search?q=community%20staking) by Lido DAO contributors to refer to independent individuals or groups running validators while being aligned with the Ethereum [goals and values](https://ethereum.org/en/roadmap/vision/). This term includes solo-stakers.
Running your own node is considered by the Ethereum community as a critical [aspect](https://ethereum.org/en/staking/solo/) of Ethereum’s security. Being independent, geographically, and jurisdictionally diverse, community stakers (independent node and validator runners) form a solid base for the security and resilience of the Ethereum network.
Lido DAO is strongly aligned with Ethereum’s goals and values. This alignment is reflected in the [Lido DAO: Purpose, Mission, and Vision](https://research.lido.fi/t/lido-dao-vibe-alignment-purpose-mission-vision/4380). Namely, the Lido DAO Mission is: “Make staking simple, secure, and decentralized”. Unfortunately, at the moment of writing, there is no simple and obvious way for community stakers to participate in the Lido protocol as operators. This fact limits the decentralization potential of the protocol and has been frequently [criticized](https://youtu.be/Y0ddkSa1ZuI) and [discussed](https://research.lido.fi/t/is-lido-good-for-ethereum/5520#lido-isisnt-centralized-5) in the community.
At its inception, Lido on Ethereum launched with a permissioned validator set, steadily expanding through open onboarding rounds \[[1](https://research.lido.fi/t/new-eth2-node-operators-joining-mainnet-wave-1/493)\], \[[2](https://research.lido.fi/t/announcement-onboarding-for-ethereum-wave-2-and-solana-wave-1-supplemental/836)\], \[[3](https://research.lido.fi/t/announcement-onboarding-for-ethereum-wave-3/1379)\], \[[4](https://research.lido.fi/t/announcement-onboarding-for-ethereum-wave-4/2024)\], \[[5](https://research.lido.fi/t/announcement-onboarding-for-ethereum-wave-5/4809)\]. This intentional design decision was made to support protocol safety and reliability at its early maturity stages, emphasizing launching a scalable solution.
Currently, a [significant amount](https://www.rated.network/o/Lido?network=mainnet&timeWindow=1d&viewBy=operator&page=1&idType=pool) of ETH is staked with Lido. Yet, the Lido Node Operator set consists of [37 active participants](https://operators.lido.fi/). The proposed Community Staking module (CSM), as well as the Simple DVT Module, would substantially broaden the Lido Node Operator Set by enabling permissionless entry.
The [Lido V2](https://blog.lido.fi/introducing-lido-v2/) release, in addition to adding [withdrawals](https://stake.lido.fi/withdrawals/request), also introduced a re-architecture of the protocol via the implementation of the [staking router](https://docs.lido.fi/contracts/staking-router). The once permissioned validator set, with identical rules for all participants (Node Operators), could now be transformed into a diverse set of subsets according to a variety of staking modules, each with diversified participation, rewards, penalties, and stake distribution characteristics.
Besides the recent updates to the Lido protocol, Ethereum itself is also evolving. Several features crucial for scalable permissionless staking are on the way to being added. Namely, [EIP-4788: Beacon block root in the EVM](https://eips.ethereum.org/EIPS/eip-4788) will allow reporting of consensus layer data to the execution layer to be consumed in a trust-minimized way, and [EIP-7002: Execution layer triggerable exits](https://eips.ethereum.org/EIPS/eip-7002) will allow the protocol to exit malicious or rule-violating validators. Adding permissionless access to the Lido Validator Set becomes feasible with these updates. Which, in turn, furthers Lido DAO's [mission](https://research.lido.fi/t/lido-dao-vibe-alignment-purpose-mission-vision/4380) and brings Ethereum closer to its [goals](https://ethereum.org/en/roadmap/vision/#:~:text=Ethereum's%20vision%20is%20to%20be,but%20there%20are%20significant%20challenges.).
One of the possible implementations of permissionless entry is through a new staking module allowing open entry with a bond. Combining the permissionless entry with the bond requirement has proven to be a great approach to validator set formation. While providing coverage for the possible issues or inappropriate actions from the Node Operators' side, it also makes Node Operators and stakers economically aligned.
Anyone will be able to participate in the permissionless module. Yet it is crucial to enfranchise community stakers participation. Being independent and aligned with Ethereum, community stakers play an essential role in the Ethereum ecosystem's decentralization, resilience, and security. According to the [Rated’s research](https://blog.rated.network/blog/solo-stakers), only 6.5% of the Ethereum validators are operated by community stakers (solo-stakers in particular). Lido contributors believe that this number can be increased. The main goal of the proposal is to offer a feasible design that will allow community stakers to participate in the Lido protocol with lower entry barriers and more appealing conditions compared to vanilla solo-staking and market competitors while maintaining and improving the level of security and utility staking with Lido protocol provides.
We, the Lido DAO contributors, seek the community’s feedback to ensure that our proposal takes into account all essential considerations and identifies any potential improvements. We would greatly appreciate your input on the following four questions:
- Are the proposed decision drivers right?
- Given those drivers, is this the best design possible?
- What can be improved in the design or its presentation?
- Are you or your project willing to participate in building a community staking ecosystem in Lido?
Your feedback is invaluable in creating an effective, efficient, and fair proposal for all stakeholders.
# Problem statement
The fact that the Lido Validator set is permissioned makes it impossible for the community stakers to participate. Since community stakers participation is one of the top priorities of Ethereum, it is crucial to add a permissionless entry to the Lido on Ethereum Node Operator set and enfranchise solo-staker participation in the protocol to stay aligned with Ethereum. At the same time, it is vital to maintain Lido on Ethereum protocol security, reliability, and capital efficiency on a level equal to or above the existing ones.
Given the Staking Router architecture introduced in the [Lido V2](https://blog.lido.fi/introducing-lido-v2/) upgrade, the problem statement can be narrowed down to:
**Propose and implement a staking module that will add a permissionless entry to the Lido on Ethereum Node Operator set, enfranchise solo-staker participation in the protocol, and maintain Lido on Ethereum protocol security, reliability, and capital efficiency on a levels equal to or above the existing ones.**
# Possible approaches to Community Staking
At the current state of Ethereum, several approaches and ways exist to add community staker’ participation to the Lido validator set while maintaining existing protocol security, reliability, and economic efficiency.
## Bond vs Reputation
Lido [curated module](https://docs.lido.fi/contracts/node-operators-registry) utilizes the operator's reputation as a primary security and alignment tool. Operators in the curated module put their reputation at stake to guarantee appropriate performance, lack of malicious actions, and alignment with the other stakeholders.
Reputation, in this case, consists not only of the validator's performance but also of the operator’s entity recognition in the community, proven experience, and contributions to the Ethereum ecosystem.
While validator performance can be reflected on-chain in trust-minimized ways using existing or proposed Ethereum features (see [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) for reporting CL state to EL smart contracts), the other aspects of reputation can not. This fact makes the reputation not a suitable tool for security and alignment in the permissionless staking module, given the current state of Ethereum. Yet, this fact might change with the introduction of the novel on-chain reputation tools. It is worth noting the latest research by Nethermind \[[1](https://nethermindeth.github.io/lido_phase_1/index.html)\], \[[2](https://research.lido.fi/t/a-mechanism-for-a-good-validator-set-maintenance-by-nethermind-research-phase-ii-completed/5386)\] in the field of on-chain identity and reputation here.
As an alternative to reputation, a bond requirement can be used. Bonds are useful both as a form of economic incentive alignment, especially when reputation is not easily assessed (i.e., since operators would use the protocol permissionlessly), as well as coverage for the consequences of inappropriate or malicious actions by the operator.
As on-chain reputation systems evolve, a gradual transition from a pure bond-based model to a combined approach can be considered. One of the simple examples here is lowering bond requirements for the actors with proven reputations. Yet, this topic lies outside the scope of the document.
## DVT vs Solo
DVT ([Distributed Validator Technology](https://ethereum.org/en/staking/dvt/)) is one of the best options for community stakers' participation in the Lido protocol and arguably the most appealing technology for Ethereum validation in the future.
Yet, the technology still needs to be battle-tested on the mainnet, and several improvements remain to be made (ex., full-featured [DKG](https://docs.obol.tech/docs/int/key-concepts#distributed-validator-key-generation-ceremony), trustless rewards distribution, on-chain cluster formation, etc.). Nevertheless, the first steps towards adding DVT support to the Lido validator set have already been made with several rounds of DVT testnet trials ([Round 2](https://twitter.com/lidofinance/status/1621503397139742721), [Round 3](https://twitter.com/LidoFinance/status/1712486356000092343)), which resulted in the [Simple DVT staking router module proposal](https://research.lido.fi/t/staking-router-module-proposal-simple-dvt/5625) by Lido contributors.
Given the current state of DVT and the fact that development teams from [Obol network](https://obol.tech/) and [SSV network](https://ssv.network/) have indicated their interest in the implementation of the native support for their DVT solutions, it is worth considering other options for community staker participation in the Lido protocol to make it possible earlier, with less complexity, and with more opportunities to join.
It is proposed to consider a “Solo” option. This option will be similar to vanilla solo staking from the operator's perspective, with the main difference being that Lido provides part of the stake.
## Current market state
While considering possible implementation options, it is crucial to understand the state of the market and competitors' solutions.
**[Rocket Pool](https://rocketpool.net/)** is, without a doubt, a leading provider of liquid staking with permissionless options for Node Operators. Being “radically permissionless”, Rocket Pool thrives to offer a good solution for liquid staking with a permissionless validator set by offering a “solo” entry option similar to the one described above. While being one of the most robust solutions for permissionless staking, there are several aspects of the protocol design that are discussed by the community, namely, additional [RPL bond requirement](https://www.reddit.com/r/rocketpool/comments/14fgn26/the_rocket_pool_collateralization_scheme_is_not/) (also read [here](https://www.reddit.com/r/rocketpool/comments/134mt8g/why_i_closed_my_minipools_and_became_a_solo/)), noticeable [gas fees](https://www.reddit.com/r/rocketpool/comments/rz03kd/gas_fees_unreasonably_high/), on-chain interaction complexity, and [amount of the capital required as a bond](https://discord.com/channels/405159462932971535/405163713063288832/1155321541253398558) (at the moment of writing LEB16 and LEB8 minipools are available requiring 16 ETH + 1.6 ETH in RPL and 8 ETH + 2.4 ETH in RPL respectively). Nevertheless, the Rocket Pool team and community have done a great job of supporting independent Ethereum stakers.
**[StakeWise V3](https://stakewise.medium.com/stakewise-v3-announcement-9e4fe73abdf2)**, currently live on testnet, offers a different approach for solo-staker participation. On the one hand, there is no minimal bond requirement, and a vault can be created with no stake provided by the Node Operator. On the other hand, if there is not enough stake in the vault to run a validator, the chances of getting it from the other stakers are relatively low, given no/low vault score in this case. It is worth noting the remarkable and unique architectural approach by StakeWise. Yet, the limitations above make it less appealing for solo-stakers than the other market offers.
Another notable player on the market is **[Stader](https://www.staderlabs.com/eth/)**. It offers a combination of Rocket Pool for permissionless entry and curated permissioned entry. The main difference with Rocket Pool is the lower bond requirement of 4 ETH + 0.4 ETH in SD token for the permissionless entry.
Besides the staking pools mentioned above, the staking solutions by **[DappNode](https://dappnode.com/), [Avado](https://ava.do/), [Ebunker](https://enode.ebunker.io/)**, and others are also worth mentioning. These solutions do not provide user funds for stakers but significantly facilitate solo staking by offering ultimate hardware and software for validator management. Also, an [MEV Smoothing pool](https://smooth-goerli.dappnode.io/) was recently introduced by DappNode. Solo-stakers participating in this pool can smoothen their MEV and EL rewards with the other pool participants.
The competition for potential Node Operators (in the wide sense) between existing and upcoming staking protocols is rising. Any solution proposed for Lido on Ethereum adoption must be competitive to raise the number of community stakers in the protocol.
# Community Staking Module (CSM) Goals and Constraints
Ideas about the possibility for the community stakers to participate in the Lido protocol have been discussed for many years in the Lido and Ethereum communities. However, the first significant step towards community staking in Lido was made about a year ago with the publication of the [Community Validation Manifesto](https://research.lido.fi/t/lido-on-ethereum-community-validation-manifesto/3331). In conjunction with the [Lido DAO: Purpose, Mission, and Vision](https://research.lido.fi/t/lido-dao-vibe-alignment-purpose-mission-vision/4380), this document remains the most relevant indication of the Lido DAO goals, values, and principles that underpin the Lido Community Staking initiative, namely:
- Support and nurture community stakers;
- Increase Ethereum’s technical, geographical, and jurisdictional resilience;
- Create more replicas of the network state.
## Goals
To narrow the initial [goals](https://research.lido.fi/t/lido-on-ethereum-community-validation-manifesto/3331#in-order-to-embody-these-principles-lido-needs-to-achieve-the-following-goals-5) from the Lido Community Staking Manifesto and form more practical applications, the following goals for CSM are proposed:
- Allow for permissionless entry to the Lido on Ethereum Node Operator set and enfranchise solo-staker participation in the protocol;
- Increase the total number of independent Ethereum Node Operators;
- Bring > 300 new independent Node Operators to the Lido Validator Set within several months of mainnet launch.
## Constraints
- Design should allow CSM to offer EL rewards and MEV smoothing;
- Design should allow CSM to offer CL rewards socialization but avoid free-riding;
- Design should allow CSM to offer competitive bond, staking fees, and operational gas costs compared to the market;
- Design should not involve tokens aside from ETH/WETH/stETH/wstETH in the design for clear incentives alignment;
- Design should not reduce Lido on Ethereum protocol security, reliability, and capital efficiency;
- Design should be as straightforward and easy to understand as possible;
- Design should be practical from smart contracts composition & operation gas costs standpoint.
# Node Operator UX
One of CSM's key advantages is friendly UX for community stakers. Reducing UX complexity is crucial for making solo staking more accessible. Hence, making interactions with CSM simple, gas-effective, and easy to understand is proposed.
On a high level, a typical Node Operator flow in CSM might look like this:
1. Prepare validator setup and deposit data (validator keys + deposit signatures)
2. Submit bond and deposit data to CSM
3. Maintain validator operation
4. Claim rewards
Also, optional steps can be considered:
5. Exit validator on CL
6. Claim unlocked bond
# Integration with Staking Router
CSM is proposed to be a full-fledged Staking Router module and thus would implement the [IStakingModule](https://github.com/lidofinance/lido-dao/blob/master/contracts/0.8.9/interfaces/IStakingModule.sol) interface.
## Rewards
There are two important features regarding staking reward distribution on the Staking Router level:
1. Consensus and Execution Layer rewards are combined before staking fee subtraction and distribution between the modules;
2. Staking fees are distributed to the modules proportionally to the number of active validators.
As the result of the first feature, all EL rewards and [MEV](https://ethereum.org/ru/developers/docs/mev/) extracted by Lido validators are smoothed across all stETH holders and Node Operators. The second feature results in the averaging of the rewards between different modules. These two features ensure that rewards allocated to the CSM module will be smooth and will benefit from the performance of the other staking modules in case it is higher. The opposite is true when CSM module performance (performance of the validators in CSM) exceeds the performance of the other staking modules.
MEV smoothing feature makes MEV part of staking rewards close to the average value even for short timeframes (~10 days), smoothing rewards that would traditionally be very volatile for solo stakers. In the case of solo-staking, the MEV part of staking rewards will likely (>50% probability) be closer to the median than the average value (with a 50% chance of being less than the median rewards) from the statistical point of view. Meaningful [difference](https://transparency.flashbots.net/) between average and median MEV values results in more consistent rewards for CSM validators than for the vanilla solo-staking or staking solutions that do not offer MEV smoothing.
## Stake allocation
A `targetShare` parameter should be set for a new module when added to the Staking Router. This parameter determines the target percent of the total Lido protocol stake that should be allocated to the module by the Staking Router. It is proposed to set a `targetShare` parameter to **1%** upon initial module activation and gradually increase it to **10%** based on Lido DAO decision and operational metrics (validator performance, number of operators, etc.) of the module after the launch. The maximal proposed `targetShare` value of **10%** is determined by two considerations: CSM impact on the Lido risk should be capped to maintain sufficient resilience for protocol users until more data is observed; Currently, 10% of the Lido stake is approximately equal to the total stake controlled by Rocket Pool.
The [stake allocation algorithm](https://docs.lido.fi/contracts/staking-router#allocation-algorithm) in the Staking Router prioritizes stake distribution to the modules with available capacity and actual stake share below the targetShare. By the time of CSM activation, it will have no stake. Hence, it will receive a stake before other modules in case of available capacity (enough validator keys uploaded by Node Operators).
## Protocol requested exits
According to the [Lido on Ethereum Validator Exits Policy](https://hackmd.io/zHYFZr4eRGm3Ju9_vkcSgQ?), each staking module should support validator exits for withdrawal coverage. Currently, these requests are managed by [VEBO](https://docs.lido.fi/contracts/validators-exit-bus-oracle/). Since “bonded” validators are more appealing to the protocol from a security and economic alignment perspective, it is proposed to set the lowest exit request priority for CSM validators when fulfilling withdrawal requests.
## Tooling updates
To ensure the correct operation of CSM, several off-chain tools should be updated, namely, [KAPI](https://github.com/lidofinance/lido-keys-api), Accounting Oracle, and Exit Bus Oracle (VEBO). Also, it is worth noting that a new key validation tool is required (see details in the sections below) and updates for the various monitoring tools like [MEV-monitoring](https://fees-monitoring.lido.fi/), [E-V-M](https://github.com/lidofinance/ethereum-validators-monitoring), etc.
# Design
> “Everything is designed. Few things are designed well.”
> — Brian Reed
## Bond
To create a solid and reliable design of the bonding mechanism, the following principles are formulated:
1. Bond should allow economic alignment between stakers and Node Operators;
2. Bond should allow coverage for the consequences of the inappropriate or malicious actions by Node Operators;
3. Bonded tokens should acquire staking rewards;
4. Node Operators’ bond should be penalized or confiscated only after inappropriate or malicious actions by the corresponding Node Operator.
To ensure economic alignment between stakers and Node Operators (principle 1) and that tokens provided as a bond by the Node Operator are acquiring rewards (principle 3), **it is proposed to stake tokens provided as a bond.**
To provide coverage for the cases when a bond provided for the individual validator is insufficient to cover losses (ex., huge MEV stealing), **it is proposed to associate a bond with the Node Operator and not the individual validator.** This will significantly reduce the chances of uncovered losses (i.e., penalties could be applied to the aggregate total of bonds provided by an operator vs just at the validator level).
In addition to the bond principles, it is important to consider ways to use a bond as a Sybil prevention mechanism. One of the possible approaches to achieve that is to **reduce bond requirements for the Node Operators controlling more than one validator**. This approach is usually referred to as **“non-linear bonding”**. According to the [research](https://research.lido.fi/t/risk-assessment-for-community-staking/5502/3) by Lido DAO contributors, the gradual bond reduction could function as a mechanism to reduce the attractiveness of Sybilling and EL-stealing strategies.
Another important yet complicated consideration about the bond mechanism is a bond reduction for the Node Operators with a proven record of being a solo-staker. The complexity here lies in the fact that there are no unambiguous and precise methodologies to identify an operator as a solo-staker and ways to deliver this information on-chain in a trustless way. Although Rated has attempted to identify solo-stakers based on the on-chain data in their [research](https://blog.rated.network/blog/solo-stakers), the approach used can not be reused without additional efforts for the latest on-chain data. With that being said, it is proposed to reconsider this option of the bond usage later and leave it out of the scope of this document.
### Bond as a coverage
To ensure coverage for the consequences of inappropriate or malicious actions by Node Operators, it is vital to understand the feasible case when bond confiscation can be applied. Node Operator actions might result in direct losses for the protocol (CL penalties) and missed profits (low performance and MEV stealing). Missed profits from low validator performance are relatively hard to define due to the lack of the constant reference value for the “optimal profits” since there are multiple factors outside Node Operators' control influencing CL performance (global internet connection outages, natural disasters, overall network effectiveness, “inactivity leak” state of the network, etc.). Hence, there is a limited set of things that are feasible to be accounted for and confiscated, namely:
- Difference between validator withdrawal balance and DEPOSIT_SIZE (32 ETH at the moment of writing, but might be changed with [EIP-7251](https://github.com/ethereum/EIPs/pull/7251))
- Amount of MEV stolen
While the first point is obvious, the second case will be discussed separately in the [MEV stealing detection and penalties](#MEV-stealing-detection-and-penalties) section.
### Only ETH (stETH) as a bond token
Another meaningful thing about the bond is the involvement of the additional tokens or assets. The most notable example here is Rocket Pool. To create a [LEB8](https://docs.rocketpool.net/guides/atlas/lebs.html) minipool, a Node Operator must provide an RPL bond equivalent to **2.4 ETH** alongside the **8 ETH**, making the total bond requirement equal **10.4 ETH**. The requirement to provide additional tokens as a bond might not be [desirable](https://www.reddit.com/r/rocketpool/comments/16nblg5/valid_rpl_criticism/) or acceptable for some users. It is proposed to use only ETH in staked form (stETH) as a bond for the CSM validators to make CSM participation more attractive for the Node Operators and keep straightforward logic of collateral and possible implications it's intended to cover existing in the same token.
### Bond size considerations
Determination of the actual bond size and possible curves for “non-linear” bonding depends on multiple factors, including:
- Risk factor analyses for large outages and/or slashing events;
- Ethereum core protocol updates (ex., [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002), [7251](https://eips.ethereum.org/EIPS/eip-7251), [MEV Burn](https://ethresear.ch/t/mev-burn-a-simple-design/15590), etc.);
- Lido core protocol updates;
- Marketplace dynamics.
All these factors may significantly change over time. Hence, it is proposed to determine the actual bond size and curves for “non-linear” bonding closer to the module’s mainnet release (if approved by the Lido DAO).
However, some numbers can be provided now as a reference in the **theoretical assumption** that CSM can be released within the next few months with a target stake share of 1%, and [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) will be implemented not later than a year from the CSM release date. In this case, according to the latest [risk assessment research](https://research.lido.fi/t/risk-assessment-for-community-staking/5502) by Lido DAO contributors, a **4 ETH** bond is sufficient to cover all possible losses and most missed profits in the realistic scenario, and a **2 ETH** bond is sufficient to cover all direct losses (CL penalties) in the same realistic scenario.
In addition to all the facts above, some generic considerations (aka “napkin math”) about bond size determination can be provided:
- Bond should be as low as possible to lower entry barriers for the new independent operators in the Ethereum ecosystem;
- Minimal bond size should be sufficient to cover “fair weather slashing penalties” (> 1 ETH and < 2 ETH);
- Bond size should be competitive in relation to existing market offers.
## Stake allocation queue
In the [curated module](https://docs.lido.fi/contracts/node-operators-registry), the stake is distributed using [MinFirstAllocationStrategy](https://github.com/lidofinance/lido-dao/blob/master/contracts/common/lib/MinFirstAllocationStrategy.sol), resulting in an even distribution between Node Operators. While this distribution strategy works great for the permissioned set, it is not so for the permissionless set with a bond. Since Node Operators have to lock bond funds to upload new validator keys, it is fairer if they would get stake in the same order they locked bond funds. While this issue is somewhat ameliorated by the fact that the bond will be staked (i.e., it is not entirely unproductive capital like in the cases of protocols where the bond is not staked), a different allocation strategy can be employed here. It is proposed to employ a **FIFO** (first in, first out) stake allocation queue approach for CSM.
Due to challenges introduced by the FIFO queue approach for validator seeding, the current key and deposit data validation mechanism (used for the Curated Operator Module) is insufficient. Thus, an improvement will need to be made to the key validation process and mechanism to allow for both allocation methodologies as well as of the checking of sufficient bonds in the case of modules where that is required (like CSM).
## Voluntary exits
Given the permissionless nature of CSM, **Node Operators should be able to exit validators and then claim the released bond permissionlessly**. Without a doubt, the owner of the validator private key, the Node Operator in the CSM case, can sign and publish the exit message anytime to exit the validator from the Consensus Layer.
The release of the bond (partially or fully, depending on how many of their validators a Node Operator has exited) is more complicated. CSM needs to know the withdrawal balance of the validator(s) and whether any MEV stealing has been detected before releasing tokens in order to adjust the releasable balance. Given that [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) will most likely be included in the next Ethereum hardfork (Dencun), it is assumed that CSM will most likely be proposed for mainnet release after the EIP implementation on the Ethereum mainnet. With [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788), `beacon_root` will be available for usage in smart contracts on the Execution Layer. Hence, it will be possible to prove the validator withdrawal balance in a trustless and permissionless way. Once the withdrawal balance is reported to CSM, the excess bond is released and can be claimed by the Node Operator.
## Performance Oracle
It is proposed to modulate staking rewards for the node operator based on their validators’ performance while allowing for reasonable performance leeway so that home stakers with small performance dips are not adversely affected. This is in contrast to the approach taken in the Curated Operator Module whereby Node Operators receive rewards based on the number of active (i.e., deposited but not exited) validators that they operate as a share of the total validators of the module. This differing mechanism is chiefly proposed to incentivize good performance in lieu of “free-riding”.
A good example of an attack that this mechanism would prevent is when the Node Operator creates a lot of validators and keeps them offline. In this case, no staking fees will be distributed to the Node Operator, and acquired penalties will be confiscated from the bond after the validator exits.
CSM will receive staking rewards allocated to the module by the Staking Router and accumulate until the CSM Performance Oracle report. Once the Performance Oracle report is settled, these accumulated rewards will be transferred to the accounting contract to make them available for claim.
It is proposed to use CL validator performance as a metric to distribute rewards since EL rewards values do not directly depend on the validator's duty performance. Hence, it is proposed to use successful block attestations as the performance metric. Each validator should perform [exactly one attestation per epoch](https://eth2book.info/capella/part2/incentives/rewards/#attestation-rewards); attestation rewards are approximately 84.4% of all validator CL rewards in case of appropriate validator operation. These facts make successful attestations a generally reliable and straightforward indicator of the validator’s performance on the Consensus Layer.
As mentioned earlier, one of the main goals of CSM is to enfranchise community staker participation. Unlike professional operators, community stakers are more likely to be affected by external factors like the internet or power outages. This will inevitably lead to short-term performance inefficiencies. To account for this fact, it is proposed to introduce a **performance threshold**. All Node Operator’s validators with performance above this threshold will get socialized rewards (`validatorReward = totalModuleRewards / wellPerfValidatorsCount`). In contrast, those performing below the threshold will not get rewards in the given Performance Oracle report; any surplus would also go to the validators within the threshold. It is proposed to conduct robust research in the near future to determine a reasonable performance threshold to make it appealing for stakers (stETH holders) and community stakers, all while supporting the optimal performance of CSM validators while still maintaining a robust validator set.
## MEV stealing detection and penalties
MEV stealing is complex to reason about, especially on-chain. Block builders use various block-building standards and approaches. Even though most of them directly set the correct `feeRecipient` or use the approach where the proposer fee is transferred in the block’s last transaction, there is no single standard, and sometimes there are even mixed approaches employed within a payload. This fact has also been discussed in the [new rewards system proposal](https://github.com/rocket-pool/rocketpool-research/blob/master/Penalties/saturn-system-proposal.md#flagging-cheating-blocks) from Rocket Pool, with the outcome that it is not feasible to account for all cases. On the other hand, Rated has recently announced [MEV Oracle](https://docs.rated.network/oracle/introducing-the-rated-oracle). This technology seems promising, yet not battle-tested. Hence, it is proposed to consider possible usage of it later and stick to the existing loose monitoring approach within CSM.
Currently, Node Operator conformance with policies regarding MEV and block proposer rewards is assessed via the [MEV-monitoring](https://fees-monitoring.lido.fi/) tool (based on the [design proposal](https://hackmd.io/@lido/HJZ52G0T9?type=view)).
A Lido DAO CSM committee can be formed to monitor for possible MEV stealing by CSM Node Operators. This committee will use this data to lock the bond part in case of MEV stealing detection initially. At the same time, actual penalty application should be the responsibility of on-chain governance. A dedicated EasyTrack motion type is proposed to settle the penalty application. It is crucial to separate bond locking and actual penalty application to allow Node Operators to appeal potentially incorrect MEV stealing penalties and to protect them from the possible inaccuracies by the Lido DAO CSM committee in the absence of the ability to detect MEV stealing in a full trustless way.
Since the proposed option with a dedicated committee might be considered sub-optimal, we seek community feedback and alternative proposals on the possible approaches to MEV stealing mitigation.
## Module-initiated validator ejections
Once [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) brings smart contract triggerable exits to Ethereum, the Lido protocol will be able to trigger exits for validators in case of significant rule violations, lack of bond coverage after penalty application, or significant drop in a validator’s CL balance. Once the current validator CL balance is lower than the `32 ETH - threshold` and the validator is not slashed, one can confidently state that something is wrong with the validator. The validator’s key might be lost, or the validator stopped maintaining its duties for another reason. Hence, the validator should be ejected to avoid additional loss of funds. The same goes for when, after penalty application, the Node Operator’s bond is no longer sufficient to cover all active validators. In this case, “unbonded” validators should be ejected to maintain the economic security of the Lido on Ethereum protocol. Design and implementation details for [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) support in both Lido on Ethereum core protocol and CSM are to be figured out in the future.
# Partnerships
Lido DAO contributors believe implementing a successful permissionless staking module is only possible with partnerships and collaboration with the Ethereum ecosystem projects and teams. The module itself and vital off-chain tooling (Performance Oracle, new Key Validation tool, etc.) are proposed to be developed by Lido DAO contributors. At the same time, many other tools and applications can be developed or enhanced to facilitate community stakers utilization of CSM.
## Tools for validator setup preparation and maintenance
One of the greatest ways to get more people to stake from home is tooling that helps to install, configure, and operate the various software necessary for a full validator setup. Many such tools already exist and help community stakers to operate as solo-stakers and with staking pools. Some of the more well-known examples are [DappNode](https://dappnode.com/), [Avado](https://ava.do/), [Stereum](https://stereum.net/), [Sedge](https://docs.sedge.nethermind.io/docs/intro), [eth-docker](https://eth-docker.net/), and many others. Lido DAO contributors suggest that [LEGO](https://lido.fi/lego) help support the continued improvement of some of these tools and explore direct integrations with the Lido protocol to enable operators to participate in CSM more easily.
To deeply integrate tools for validator maintenance with CSM, regular updates and support will be required. To support this maintenance and to establish alignment between Lido DAO and validator maintenance tools developers, it is proposed to introduce a referral program similar to the existing [reward share program](https://lido.fi/rewards-share). While the exact program description will be proposed separately, the basic idea of the CSM referral program is to allocate part of the staking rewards to the referrals instead of DAO treasury for the validators operated using such tooling.
We seek proposals from the developers of the validator setup preparation and maintenance software as well as other software that can improve community stakers experience in the comments to the original forum post.
# Conclusion
The proposed design of **CSM (Community Staking Module)** arises from the goals and constraints outlined. It is aimed to address the desire to introduce meaningful permissionless entry to the Lido validator set. In the case of Lido DAO and community approval, the approach outlined in the document can be used as a basis for the actual development of CSM as a part of the general Lido Community Staking initiative.
Imagining that Lido DAO may approve this proposal within Q4 2023, Lido DAO contributors estimate that the proposed module can be implemented and deployed to the Holesky testnet in Q3 2024, and, in case of no significant blockers or implementation issues proposed for the mainnet release in Q4 2024.
As mentioned, Lido contributors believe implementing a successful permissionless staking module is only possible with partnerships and collaboration with the Ethereum ecosystem projects and teams. Hence, feedback and partnership proposals are welcome.
**Let’s build the best permissionless staking module together!**
Community feedback about the proposed design and decision drivers is highly appreciated.
Sign in with Wallet
Connect another wallet