• Community Staking Module Overview
• 📝 Summary
• 🔭 Vision
• 🏷️ Characteristics
• 📜 Status
• 🏄‍♂️ Quick start with CSM
• Getting started with CSM
• Setting up a CSM validator
• First aid and prevention measures
• 🤝 Node Operators
• 🛠️ Node Operators Expectations
• ➡️ Joining CSM
• Step 0. Hardware and software preparations
• Step 1. Validator keys generation
• Step 2. Validator client configuration
• Step 3. MEV-boost & CL configuration
• Step 4. Upload deposit data to CSM
• Step 5. Patiently waiting for the deposit
• CSM Widget
• Usage of DVT in CSM
• Integrations
• 🔄 Managing a Node Operator in CSM
• Addresses changes
• Rewards claiming
• Validator keys deletion
• ⬅️ Exiting validators from CSM
• Voluntary exits
• Protocol-initiated exits
• 💹 Economics
• 🗃️ Bonds
• Reasons for utilizing a bonding mechanism
• Bond penalization
• Operator-level bond
• Bond Curve
• 🎁 Rewards & Penalties
• Rewards
• Penalties
• ⚙️ Mechanisms
• 🐣 Early Adoption period
• ⛓️ Stake allocation queue
• 🎱 EL Rewards stealing detection & penalization
• 👫 Committees
• 🔮 Oracles
• Lido protocol-wide oracles
• CSM specific Oracle
• 🛡️ Security
• 📢 Communication
• 🔗 Channels
• 📚 Resources
• 🛠️ Guides
• 🖥️ Code and interfaces
• 🎓 Talks & Lectures
• 📄 Documentation
• 🛡️ Audits
• 📈 Analytics
• 📈 Module performance and statistics
• 🔬 Glossary

Community Staking Module Overview

🏄‍♂️ 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
📌
Shortly, Node Operators must exit validators from the CL upon a protocol request in a timely manner to avoid restrictive measures.
2. Rewards policy
📌
Shortly: - feeRecipient must be set to the Lido EL Rewards Vault (testnet, mainnet) - 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

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.

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.

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.

Step 3. MEV-boost & CL configuration

Configure your MEV-Boost service. Min-bid may be configured either at MEV-Boost level or at the CL client, the current acceptable maximum value for min-bid is 0.07 based on community consensus and may change. Builder-boost-factor should be set to 100%, i.e. local and builder payloads should be treated with equal weights. The relay flags should be set to a list of values only using relays from the the list of Vetted MEV-Boost Relays for Lido CSM.

Step 4. Upload deposit data to CSM

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!

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.

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.

As guide are currently being prepared by the community. Operators should understand both the guides as well as the intricacies of setting up CSM Rewards and Manager addresses correctly before doing a DVT setup, especially if a splitter will be used as the Rewards Address.

Additionally, CSM is integrated with the Distributed Validator Vault, which means that stake from the vault flows to the module and Node Operators utilizing DVT (Obol and SSV) can receive 20% of the provider incentives pertaining to the validators they run utilizing DVT* as a node operator within CSM. Read more on the research forum.

* Analysis of which CSM operators are using DVT is ultimately performed by each DVT provider separately and independently based on their own criteria.

Integrations

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

🔄 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.

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

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.

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.

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

Validator keys deletion

The Node Operator might delete uploaded keys voluntarily if they has not been deposited to yet. The keyRemovalCharge = 0.05 ETH is charged to the the Node Operator's bond balance 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). Key removal charges exist to prevent “queue stuffing” with keys people never intend to use and generally dissuade actors from possible DoS-based behavior.

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, and then wait for the withdrawal to be processed by 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. Node Operators can subscribe to the VEBO events to stay notified about the pending exit requests.

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

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

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 mainnet

Bond Curve on 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)

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.

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

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

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

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.

⛓️ 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.

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

A dedicated committee is formed to serve as Lido DAO representative in some management functions of CSM, namely:

• Reporting MEV stealing in CSM on mainnet
• Cancelling MEV stealing penalty if needed
• Starting Easy Track motions to settle MEV stealing penalty
• Setting and Resetting bond curves for particular CSM Node Operators (not adding new ones, only setting one of the existing ones)
• Pausing CSM in case of emergency via Gate Seal

The committee multi-sig consists of two Lido contributors (madlabman, Remus), one Lido Community Lifeguard (enti) and 3 staking community representatives (Lanski, Eridian, POSTHUMAN), with a signing threshold of 4/6.

🔮 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

• Accounting Oracle:
• AccountingOracle: 0x852deD011285fe67063a08005c71a85690503Cee (proxy)
• HashConsensus: 0xD624B08C83bAECF0807Dd2c6880C3154a5F0B288
• Validators Exit Bus Oracle:
• ValidatorsExitBusOracle: 0x0De4Ea0184c2ad0BacA7183356Aea5B8d5Bf5c6e (proxy)
• HashConsensus: 0x7FaDB6358950c5fAA66Cb5EB8eE5147De3df355a
• OracleReportSanityChecker: 0x9305c1Dbfe22c12c66339184C0025d7006f0f1cC
• OracleDaemonConfig: 0xbf05A929c3D7885a6aeAd833a992dA6E5ac23b09

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

ℹ️

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.

🛡️ Security

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

📢 Communication

🔗 Channels

For further discussion and updates, refer to:

• Discord
• Snapshot vote for starting CSM development
• Research Forums:
• CSM introduction post
• Napkin math for CSM bond
• RFP for CSM integration

📚 Resources

All the resources are stored in this database.

🛠️ Guides

• CSM validator setup
• Validator exit

🖥️ Code and interfaces

• CSM GitHub
• CSM Widget (testnet)
• Deployed Contracts (testnet) (mainnet)

🎓 Talks & Lectures

• Validating Ethereum | Episode 0 | Lido Community Staking Series
• Lido's Community Staking Module | Dmitriy Gusakov | LidoConnect 23
• Lido goes permissionless | Community staking Module
• Talk on “How Lido Makes Ethereum Validation More Accessible” - by Dmitry Gusakov

📄 Documentation

• CSM Landscape
• CSM Specifications
• CSM Architecture
• CSM Docs

🛡️ Audits

CSM code is audited by two independent parties separately to ensure the security of the module itself and its interconnections with the rest of the Lido protocol:

• Ackee (audit report)
• Mixbytes (audit report)

The other audits of the Lido protocol are listed here.

📈 Analytics

Access basic module analytics at the Operators Dashboard.

📈 Module performance and statistics

🔬 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;