Community Staking Module

Community Staking Module Overview

📝 Summary

Community Staking Module (CSM) is the Lido on Ethereum protocol’s first module with permissionless entry, allowing any node operator — and especially community stakers, from solo stakers, to groups of friends, to amateur operators — to operate validators by providing an ETH-based bond (security collateral).

In an effort to enhance the protocol’s decentralization by incorporating a broader range of operators, CSM introduces the following features to make solo staking more attractive and accessible:

  • EL rewards and MEV are smoothed with other Lido modules, so CSM Node Operators can potentially gain more consistent and stable rewards;
  • A reasonably low bond for Node Operators to attract more prospective operators;
  • No secondary token security collateral is required, with bonds accepted in ETH, stETH, wstETH and rewards received via stETH;
  • Node Operators are provided with a friendly UX and pay less gas fees for on-chain operations compared to other options in the market;
  • Node Operators may potentially gain more validator rewards (on a total ETH spent basis) than vanilla solo staking.

🔭 Vision

The ultimate goal for this module is to allow for permissionless entry to the Lido on Ethereum Node Operator set and enfranchise solo-staker participation in the protocol, increasing the total number of independent Node Operators in the overall Ethereum network.

🏷️ Characteristics

⚠️
Note: below characteristics apply to CSM Holesky testnet. The values for mainnet may differ and will be set upon the mainnet launch by DAO vote.
  • Operators Onboarding: Permissionless with the additional permissioned Early Adoption period
  • Bond Required: from 2 to 1.5 Holesky ETH based on the Bond Curve for CSM testnet
  • Rewards Rate:
    • 10% total rewards share, broken down as:
      • 3% allocated to treasury
      • 7% to the module
  • DVT: Optional
  • Maximum Stake Limit: 10%, subject to further increases by the DAO

📜 Status

🟢
CSM is live and fully permissionless on Holesky testnet

On December 15th, the Lido DAO gave the green light for the development of Community Staking Module.

Early Adoption mode ended on July 11, 2024, and CSM Testnet is now in fully permissionless state.

🏄‍♂️ Quick start with CSM

🤝 Node Operators

A Node Operator contributes to this module by running infrastructure. The module was designed for solo stakers and community stakers, providing them with the unique ability of becoming Ethereum validator with way less than 32 ETH and one of the friendliest UX possible, but may be utilized by anyone, including professional operators.

🛠️ Node Operators Expectations

  1. Node Operators must configure their validation tools as described in the section below
  2. Node Operators must keep their nodes running and not get slashed
  3. Node Operators are expected to follow the policies:
    1. Exits policy
      2. 📌
      Shortly, Node Operators must exit validators from CL upon a protocol request in a timely manner to avoid restrictive measures.
    2. Rewards policy
      3. 📌
      Shortly: - feeRecipient must be set to the Lido EL Rewards Vault - MEV-boost usage is mandatory, although min-bid may be utilized - Only relays from the vetted lists may be used (testnet allowlist, mainnet allowlist)
  4. Node Operators are expected to follow the CSM protocol rules or have their validators ejected from the module and any benefits (e.g. reduced bond curve) reset.

➡️ Joining CSM

🛠
Make sure to check the Node Operators Expectations section before setting up CSM validators

A detailed guide on preparing all the validation tools for CSM can be found here.

A shorter flow of setting up a CSM validator looks as follows:

Step 0. Hardware and software preparations

Before setting up a CSM validator, the following steps should be completed:

  1. Prepare your hardware setup or use a cloud service.
  2. if you use your own hardware, install and prepare the OS and home network for your validation node. For the cloud service, select the corresponding OS and network configuration.
  3. Install and configure your Execution Layer (EL) and Consensus Layer (CL) clients, then wait for the synchronization.
💡
You can use one of the integrations to prepare your setup and enjoy the tailored flow and automated setting of some parameters:

Step 1. Validator keys generation

Generate new validator keys setting the withdrawal_address to the Lido Withdrawal Vault, specify the deposit amount of 32 ETH and a corresponding chain.

⚠️
Do NOT make a deposit!

Testnet parameters

  • withdrawal_address = 0xF0179dEC45a37423EAD4FaD5fCb136197872EAd9 (Lido Withdrawal Vault)
  • deposit_amount = 32 ETH
  • chain = holesky

Mainnet parameters

  • withdrawal_address = 0xb9d7934878b5fb9610b3fe8a5e441e8fad7e293f (Lido Withdrawal Vault)
  • deposit_amount = 32 ETH
  • chain = mainnet

Step 2. Validator client configuration

Configure your validator client (and/or beacon node) setting the fee_recipient flag to the designated fee recipient address (Lido Execution Layer Rewards Vault) and import the newly generated CSM keystores.

Testnet parameter

Lido Execution Layer Rewards Vault on Holesky = 0xE73a3602b99f1f913e72F8bdcBC235e206794Ac8

Mainnet parameter

Lido Execution Layer Rewards Vault on mainnet = 0x388C818CA8B9251b393131C08a736A67ccB19297

Step 3. MEV-boost configuration

Configure your MEV-Boost service. Do not set themin-bid flag (or set 0) and set the relay flags only to the list of designated MEV relays for Lido CSM.

💡
You can use a subset of the designated relays, but you should not use any relays that are not in the list

Step 4. Upload deposit data to CSM

💡
Before uploading, make sure that nodes are synced, running, and ready for the validator activation.

Upload the newly generated deposit data file pertaining to your CSM keystores onto the Lido CSM Widget and provide the required bond amount in ETH/stETH/wstETH.

Step 5. Patiently waiting for the deposit

Wait for your CSM validator keys to be deposited through the protocol and make sure your node remains online in the meantime!

💡
You can track your keys status using Lido CSM Widget
‣
When does a validator become active?

CSM Widget

CSM Widget is an interface that is used for creating a Node Operator in CSM, uploading/deleting validator keys, managing bond, rewards and addresses associated with the Node Operator.

CSM Widget on testnet

https://csm.testnet.fi/

CSM Widget on mainnet

🚧
Not live on mainnet yet

Integrations

For a smoother node setup experience, Node Operators may also elect to utilize the following Plug & Play solutions that have integrated with CSM:

App
Testnet
Mainnet
eth-docker
Live
🚧
DappNode
Live
🚧
Stereum
Live
🚧
Sedge
Live
🚧

Usage of DVT in CSM

From perspective of the validator operation on the Beacon chain (CL), CSM is akin to vanilla solo staking, hence, technology DVT is one of the options that can be used for CSM. However, unlike Simple DVT, CSM does not offer additional support or special conditions for operators using DVT, and participants and clusters must entirely self-coordinate to utilize DVT if they wish to. The learnings, resources, and toolings for Simple DVT are all open source and available for those who wish to avail themselves of them.

🔄 Managing a Node Operator in CSM

Addresses changes

There are two addresses associated with a Node Operator that have different scopes of responsibilities for managing the Node Operator entry.

The Rewards Address is used for:

  • Claiming bond and rewards
  • Adding extra bond amount
  • Proposing a new Rewards Address
  • Resetting the Manager Address to the current Rewards Address

The Manager Address is used for:

  • Adding new keys
  • Removing existing keys
  • Adding extra bond amount
  • Claiming bond and rewards
  • Covering locked bond
  • Proposing a new Manager Address
☝
Rewards address is the only recipient of reward claims. No funds will ever be transferred by CSM to the Manager Address unless it is equal to the Rewards Address.

Upon creation of a Node Operator these addresses are set equal, but they can be changed afterwards.

It's recommended to use different addresses for security reasons. A hot wallet may be used for the Manager Address to simplify daily operations, while a cold wallet is preferable for the Rewards Address to enhance security.

The process of changing both Manager and Rewards Address is two phased:

  • Propose new address from the existing one
  • Accept change from the new address

This process helps Node Operators to avoid incorrect changes to a non-existing address or one they do not control.

There is also a method to reset Manager Address to Rewards Address from the Rewards address in case the first one was compromised or lost.

⚠️
Node Operators are solely responsible for the security of the private keys related to these addresses. There is no override or reset functionality in the CSM in the case that a Node Operator loses access to these addresses.

Here is a detailed guide on how to manage roles in CSM.

Rewards claiming

All rewards ever acquired by a Node Operator can be claimed within 1 TX. No matter how long the Node Operator has been running validators with CSM the gas cost of transaction will be more or less the same.

☝
Since all rewards are stored in stETH, there is no need for the Node Operators to claim them frequently. Rewards will rebase as usual stETH even when not claimed.

The overview of the rewards claiming functionality can be found here.

Validator keys deletion

The Node Operator might delete uploaded keys voluntarily if it has not been deposited yet. The removalCharge is confiscated from the Node Operator's bond on each deleted key to cover maximal possible operational costs associated with the queue processing. Deposit data can be deleted in continuous batches (ex., from index 5 to 10).

☝
Since deletion comes with the price, make sure to double check your keys prior to uploading them to CSM.

If the protocol has already deposited the validator related to the deposit data, the Node Operator cannot delete the deposit data. The only way to stop validation duties is to exit the validator on the CL. Once the validator is fully withdrawn, the Node Operator can claim the excess bond.

Here is a step-by-step guide on how to remove keys from CSM.

⬅️ Exiting validators from CSM

Voluntary exits

Given the permissionless nature of CSM, NOs can voluntarily exit their validators at any moment. Exiting CSM validator keys works the same way as exiting solo staking validator keys. The guide on how to exit the validator can be found here.

Protocol-initiated exits

CSM uses VEBO to request or trigger exits for validators.

A validator can be requested to exit from the Lido protocol in three cases:

Withdrawal request

A validator exit can be requested to cover withdrawal requests from stETH holders.

Unbonded keys

A validator exit can be requested in case of the validator being unbonded.

DAO decision

A validator exit can be requested by the DAO decision in some exceptional cases. It will require an on-chain vote and the public discussion on the Lido Research forum.

Penalty measures for not exiting

Node Operators should follow VEBO events (for example, by using the Ejector) to ensure they exit validators on time. If the validator has not been exited from the CL in 4 days (28800 slots) it is marked as “Stuck”.

The following penalties and limiting measures are applied if the Node Operator has not successfully exited a validator after 4 days of the protocol request:

  • Exclude all Node Operator’s keys from the deposit queue and do not put them back to the queue until the number of stuck keys for this Node Operator is 0;
  • Exclude the Node Operator from the staking rewards allocation cycle within the reporting period of the Performance Oracle if the Node Operator has stuck keys during it;

Detailed information about exits mechanics is described here.

💹 Economics

The economic model is structured to allow community stakers to participate in using the Lido protocol with lower barriers to entry and more appealing conditions compared to vanilla solo-staking or other options in the market while maintaining and improving the Lido protocol’s protections and mitigations against operator error and possible malicious behavior via a bonding mechanism.

🗃️ Bonds

☝
Here and after, the term 'bond' has the following meaning: Bond - a security collateral that Node Operators must submit before uploading validator keys into CSM. This collateral covers possible losses caused by inappropriate actions on the Node Operator's side. Once the validator exits from the Beacon chain and all losses that occurred are covered, the collateral can be claimed or reused to upload new validator keys.

Reasons for utilizing a bonding mechanism

A bonding mechanism was proposed to be utilized in CSM to facilitate permissionless onboarding of independent Node Operators. Taking into account the staking landscape, the use of bonds has proven to be effective in:

  • Onboarding numerous independent Node Operators in a permissionless manner;
  • Allowing for the creation of mechanisms that would compensate stakers in the case of inappropriate or malicious actions by Node Operators;
  • Increasing economic alignment between Node Operators and stakers.

Bond penalization

Bonds are utilized as potential coverage in the scenarios when Node Operators intentionally or accidentally negatively impact staking rewards, or otherwise break protocol rules. The specific cases of bond penalization are described in the Penalties section below.

Operator-level bond

It can not be 100% guaranteed that the bond is sufficient to cover all possible losses, especially if malicious actors were to steal a huge amount of MEV. To significantly reduce the risk of uncovered losses, CSM introduces a unique bonding mechanism that associates bonds with the Node Operator instead of the individual validator. This means the aggregate total of bonds provided by an Operator that runs multiple validators could cover the losses caused by any of its validators.

Bond Curve

An important feature of CSM is non-linear bonding. It allows Node Operators to operate more than one validator, with bond requirements that decrease based on the number of validators registered within the Node Operator. Research performed indicates that gradual bond reduction can discourage Sybilling and EL Rewards (e.g. MEV) stealing. Furthermore, it lowers entry barriers for those who want to run more validators.

Bond Curve on testnet

image

Bond Curve on mainnet

The bond curve for mainnet has not been set yet. The actual values will be voted on by the DAO upon the mainnet release, taking into account the latest changes in factors such as technical validator risks and Ethereum updates.

⚠️
Note: the values for mainnet may differ from the ones for testnet

🎁 Rewards & Penalties

Rewards

When CSM operators use the Lido protocol to run validators, they accrue two types of rewards:

  • Node Operator rewards: a share of rewards from staker locked stake amount, currently calculated pro-rata based on validators operated as a share of total protocol validators, with possible reductions for bad performance (see below)
  • Bond rebase: staking rewards generated from the bonded tokens ((w)stETH)
image

Reward Smoothing Between Modules

Reward Socialization Inside CSM

Each Lido protocol module has different subsets of Node Operators with different performance levels. For example, the Curated module is generally expected to outperform CSM (since curated operators validate as a business), thereby contributing more significantly to Consensus Layer rewards. Conversely, an underperforming module may generate a lower reward return.

To minimize the reward disparity, smoothing is employed by the Staking Router. This involves averaging the rewards across different modules, taking into account the number of active validators in each.

When it comes to Execution Layer rewards, independent operators in CSM do not need to worry about producing a block with a low MEV bonus or proposing a block only once or twice every six months, since EL rewards are part of the protocol-wide rewards smoothing mechanism. This rewards smoothing feature drastically reduces the volatility of both CL and especially EL rewards (if an operator is running few validators), so rewards are thus instead consistent and close to the average expected value over a long timeframe.

Another innovative CSM feature is reward socialization within the module via the use of a Performance Threshold, which is used to determine reward allocation. Per claim period (frame), validators whose performance exceeds a certain threshold will share the rewards received by CSM (based on their share of active validators).

On the other hand, underperforming validators whose performance falls below the threshold will receive no Node Operator rewards for the given frame.

Most importantly, since CSM is geared towards community stakers, the idea is to allow for a reasonable performance leeway, such that Node Operators do not receive reduced rewards due to short-term performance dips caused by factors such as internet or power outages. Additionally, the existence of the “bad performers” sub-set actively discourages free-riding behaviors (e.g. not running the validators that have been registered) and poor validator operation.

image

A detailed description of the rewards mechanics can be found here.

Penalties

There are three major reasons that a CSM Node Operator's bond could be penalized:

  1. The validator has been slashed. In this case, the initial (minimal) slashing penalty is confiscated. Should initial and minimal slashing penalties be revised in the future at a protocol level (e.g. in Pectra hardfork), this penalty will be updated. Penalty amount = 1 ETH

    2. This penalty is reported permissionlessly using EIP-4788 to prove the fact of slashing. This penalty is applied immediately within the reporting transaction.

    The detailed explanation about slashing can be found here.

  2. The operator has stolen EL rewards (MEV). Penalty amount = amount stolen + fixed stealing fine

    3. This penalty has the form of a delayed penalty with a challenge period. Once the penalty is settled (confirmed), all benefits for the relevant Node Operator are reset due to the violation of protocol rules. Read more about the EL rewards stealing in the section below.

  3. Following a validator exit and withdrawal, the validator's withdrawal balance being less than 32 ETH. Penalty amount = 32 - validator's withdrawal balance

    4. This penalty type is calculated using the validator’s withdrawal balance. This penalty is applied immediately within the reporting transaction. If the initial slashing penalty is applied (first penalty type), it will be accounted for to avoid double penalization and all corresponding Node Operator benefits will be reset.

A detailed description of the penalties mechanics can be found here.

⚙️ Mechanisms

🐣 Early Adoption period

Early Adoption (EA) is an initiative to onboard a sub-set of identified likely solo stakers to CSM on mainnet prior to the module opening up to everyone. This mechanism safeguards against the potential crowding out of CSM’s capacity by large operators during the initial phase.

In addition to the ability to spin up validators using CSM from the get-go, eligible operators also benefit from a reduced amount of collateral for their first registered validator. While CSM is in the EA period, each operator is permitted to register up to a certain number of validators.

Benefits of Early Adoption

  • Early access

    • Node Operators included in the Early Adoption list will gain exclusive access to the CSM mainnet before it becomes available to everyone.

  • EA bond curve

    • EA bond curve is a special curve that further lowers the entry barrier for early CSM participants in terms of bond required for the first validator per Node Operator. The rest of the curve is identical to the default one.

image

Early Adoption eligibility for testnet

Limit of validators per Node Operator during the EA period: 10

The list of addresses eligible for the Early Adoption phase will be gathered from multiple sources:

The entire list of the testnet EA participants can be found here.

Early Adoption eligibility for mainnet

⚠️
The final list for mainnet won’t be identical to the testnet one. It will be updated to include eligible CSM testnet participants and the most recent data from other sources. Once CSM mainnet goes live, the list won’t be changed anymore.

⛓️ Stake allocation queue

The stake allocation queue in CSM is a traditional FIFO (first in, first out) queue. Node Operators occupy places in the queue with {noId, keysCount} entries representing a batch of keys (validators) and wait for their turn. Once the queue reaches the Node Operator's batch, CSM checks how many keys from the batch can be deposited.

image

Check the detailed description of the stake allocation queue in CSM.

🎱 EL Rewards stealing detection & penalization

Any violations to the Lido Block Proposer rewards policy are investigated by the CSM Committee. In case of investigation results showing that EL rewards such as MEV (fully or partially) were transferred to the address different from Lido Withdrawal Vault, the amount transferred is considered stolen. The fact of stealing is reported on-chain, which locks the relevant Node Operator’s bond after which a challenge period begins.

To mitigate potential CSM Committee malicious behavior, the actual penalty application (burning of a locked bond) is only available through an Easy Track motion (Easy Track is an optimistic-governance mechanism for on-chain votes) that can be objected to by Lido DAO members over a 72 hour period.

If the penalty is not applied during challenge period the locked bond is automatically unlocked.

If EL rewards were transferred to the wrong address accidentally, Node Operator can return the funds back to the Lido protocol to unlock their bond and avoid reset of the benefits. Return of the funds can be performed using the CSM Widget.

If Node Operators have objections regarding the locked bond, they can reach out to the Lido DAO members by creating a thread in the CSM Support section of the Lido Research forum.

The detailed explanation on EL rewards stealing can be found here.

👫 Committees

CSM Committee

In the mainnet implementation of CSM there will be a committee that is responsible for detecting EL rewards stealing and reporting this fact on-chain as described in the corresponding section. It has not been formed yet and the list of participants, as well as the scope of responsibilities will be decided by the DAO vote.

🔮 Oracles

Lido protocol-wide oracles

The Lido protocol Oracle daemon monitors the state of the protocol across both layers and submits regular update reports to the Lido smart contracts.

There are two modules in the Oracle:

  • Accounting Oracle module (AO) updates the protocol TVL, distributes node-operator rewards, updates information about the number of exited and stuck validators and processes user withdrawal requests. The accounting oracle also makes decision to turn on/off bunker mode, a protective mechanism in case of mass slashings or large negative rebases.
  • Validator Exit Bus Oracle (VEBO) requests Lido validators to eject via events in Execution Layer when the protocol requires additional funds to process user withdrawals.

https://docs.lido.fi/deployed-contracts/#oracle-contracts

https://github.com/lidofinance/lido-oracle?tab=readme-ov-file#how-it-works

CSM specific Oracle

CSM Performance Oracle uses successful attestation rates as a proxy for the overall performance of a validator. A performance threshold is utilized to determine the allocation of the actual Node Operator rewards. Validators with performance above the threshold are included in the allocation pool, while the rest are not. This means that all rewards acquired by the module will be distributed amongst “good performers” (note: this is determined at a validator level, not operator level). Then, validator shares are allocated to the corresponding Node Operators, and each Operator can claim rewards for all of their validators in one go. Since the explicit purpose of the CSM is to enfranchise solo staker participation, the intent is for the threshold to be set at a point which allows for reasonable and acceptable downtime, and mostly as a countermeasure to operators who may “freeload” on the module with sub-standard performance.

The performance threshold is a relative variable determined as follows: CSM Performance threshold = Average validator performance accross the whole Ethereum network - CSM performance leeway

image
ℹ️
The Performance Oracle manages only part of an NO’s total rewards. Even if a validator performs below the threshold within a frame, bond rewards (rebase) will (at this time) still be acquired. Even when performing below the threshold, the rewards per 1 ETH deposited as bond will be higher than those for solo staking.

A detailed description of the CSM Performance Oracle can be found here.

CSM testnet Performance Oracle params

  • Frame = 7 days
  • Performance leeway = 500 Basis Points (5%)

CSM mainnet Performance Oracle params

The leeway and frame values for mainnet have not been set yet. The actual values will be voted on by the DAO upon mainnet release, taking into account the latest changes in factors such as technical validator risks and Ethereum updates.

⚠️
Note: the values for mainnet may differ from the ones for testnet

🛡️ Security

Security measures include several mechanisms that protect different parties that have a relation with CSM:

  • CSM Node Operators
    • The deposit data is validated by CSM Widget before uploading it to CSM. The correctness of the deposit signature, absence of duplicates with the exiting Lido keys, and absence of the previous deposits to the given key are validated by the CSM Widget and Deposit Security Module.
    • While rewards are smoothed across the all Node Operators, it is important to safeguard the protocol such that bad performance from other Node Operators doesn’t affect good performers. For this purpose CSM utilizes the performance threshold mechanics to promote an acceptable level of average rewards for CSM Operators.
  • Lido stakers
    • Node Operator bond is used to cover protocol losses, if any, to the extent of the bond available.
    • Node Operators do not get rewards in case of unacceptable performance, hence CSM operators are motivated to demonstrate good performance.

📢 Communication

🔗 Channels

For further discussion and updates, refer to:

📚 Resources

All the resources are stored in this database.

🛠️ Guides

🖥️ Code and interfaces

🎓 Talks & Lectures

📄 Documentation

🛡️ Audits

CSM code will be audited before going to mainnet by two independent parties separately to ensure the security of the module itself and its interconnections with the rest of the Lido protocol:

The results of the audits will be shared publicly.

The other audits of the Lido protocol are listed here.

📈 Analytics

Access basic module analytics at the Operators Dashboard.

📈 Module performance and statistics

Mainnet

🔬 Glossary

  • The staking router (SR) is a smart contract within the Lido on Ethereum protocol that facilitates stake allocation and rewards distribution across different modules;
  • A staking module (SM) is a smart contract or a set of smart contracts connected to the staking router, which: - maintains the underlying operator and validator sets, - is responsible for on/off-boarding operators, - maintains validator deposits, withdrawals, and exits, - maintains fee structure and distribution for the module and participants, etc;
  • A bond is ETH or stETH put out by a Node Operator as security collateral for bad behavior or poor performance;
  • The Lido DAO is a Decentralized Autonomous Organization that decides collectively on the matters of liquid staking protocols by the votes of its governance token holders (LDO).
  • A Node Operator (NO) is a person or entity that runs validators;
  • DVT stands for Distributed Validator Technology;
  • Slashing refers to the process of penalizing a validator for misbehaving;
  • Lido is a core contract of the Lido on Ethereum protocol that stores the protocol state, accepts user submissions, and includes the stETH token;
  • stETH is an ERC-20 token minted by Lido and representing a share of the totalPooledEther;
  • Deposit data refers to a structure consisting of the validator’s public key and deposit signature submitted to DepositContract. This term can also be referred to as keys in the text. Validator private keys are created, stored, and managed by Node Operators exclusively;
  • DepositContract is the official contract for validator deposits;
  • DepositSecurityModule or DSM is a set of smart contract and off-chain parts mitigating the vulnerability;
  • A validator is considered to be “unbonded” when the current Node Operator bond is not sufficient to cover this validator. This can happen in case of penalties applied;
  • A validator is considered to be "stuck" if it has not been exited timely following an exit signal from the protocol;
  • The Curated module is the first Lido staking module previously referred to as Node Operators Registry;
  • EasyTrack is a suite of smart contracts and an alternative veto-based voting model that streamlines routine DAO operations;
  • AccountingOracle is a contract which collects information submitted by the off-chain oracles about state of the Lido-participating validators and their balances, the amount of funds accumulated on the protocol vaults (i.e., withdrawal and execution layer rewards vaults), the number of exited and stuck validators, the number of withdrawal requests the protocol can process and distributes node-operator rewards;
‣
hide