- 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 configuration
- Step 4. Upload deposit data to CSM
- Step 5. Patiently waiting for the deposit
- CSM Widget
- Integrations
- Usage of DVT in CSM
- 🔄 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
📝 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
- 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
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
Getting started with CSM
Setting up a CSM validator
First aid and prevention measures
🤝 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
- Node Operators must configure their validation tools as described in the section below
- Node Operators must keep their nodes running and not get slashed
- Node Operators are expected to follow the policies:
- Exits policy
- Rewards policy
- 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.
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)➡️ 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:
- Prepare your hardware setup or use a cloud service.
- 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.
- 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.
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.
Testnet relays
List in Notion - https://enchanted-direction-844.notion.site/6d369eb33f664487800b0dedfe32171e?v=985cb7e521de43d78c67b7ad29adec84
On-chain contract
Mainnet relays
List in Notion - https://enchanted-direction-844.notion.site/6d369eb33f664487800b0dedfe32171e?v=8e5d1f1276b0493caea8a2aa1517ed65
On-chain contract
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.
Testnet addresses
stETH = 0x3F1c547b21f65e10480dE3ad8E19fAAC46C95034
wstETH = 0x8d09a4502Cc8Cf1547aD300E066060D043f6982D
Mainnet addresses
Lido CSM Mainnet Widget is not live yet
stETH = 0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84
wstETH = 0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0
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.
CSM Widget on testnet
CSM Widget on mainnet
Integrations
For a smoother node setup experience, Node Operators may also elect to utilize the following Plug & Play solutions that have integrated with CSM:
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
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.
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.
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).
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
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
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.
🎁 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)
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.
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:
- 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
- The operator has stolen EL rewards (MEV).
Penalty amount = amount stolen + fixed stealing fine
- 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 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.
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.
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.
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:
- Solo-stakers list curated by Rated: A list of Ethereum solo-stakers curated by Rated with the methodology described in the blog post.
- Solo-stakers list curated by StakeCat: A list of Ethereum solo-stakers curated by StakeCat.
- Obol Techne credential holders: The Obol Techne Credential Program is an initiative aimed at identifying individuals who have demonstrated proficiency in operating distributed validators. Holders of this credential are recognized as potential candidates to become CSM Node Operators.
- Simple-DVT testnet community staker participants : Simple DVT Module represents the inaugural Lido staking module that empowers community stakers to participate in the Lido protocol by operating validators, leveraging DVT provided by Obol and SSV network.
- CSM-related Galxe OATs holders with 5+ points: Community members who have consistently engaged in both online and offline activities, and have collected relevant digital badges as proof of participation.
The entire list of the testnet EA participants can be found here.
Early Adoption eligibility for mainnet
⛓️ 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
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
- 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
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.
🛡️ 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:
- Discord
- Snapshot vote for starting CSM development
- Research Forums:
📚 Resources
All the resources are stored in this database.
🛠️ Guides
🖥️ 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
🛡️ 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
Testnet
Mainnet
- Beacon Chain
- E-V-M (not public)
- Rated.Network - coming soon!
🔬 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;