• 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
• DVT providers
• VaaS providers
• 🔄 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
• 📋 Node Operator Types
• 🦸‍♂️ Identified Community Stakers
• 👬 Identified DVT Cluster
• ⛓️ 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 (Hoodi 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.

DAppNode

Sedge

Stereum

eth-docker

EthPillar

Ethereum on ARM

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.

--builder-bid-compare-factor(default: 90):
For example, a builder bid comparison factor of 90 means the builder's payload is chosen when its value is at least 10% greater than what can be built locally.

--local-block-value-boost(default: 10): Use builder block if: builder_bid_value * 100 > local_block_value * (local-block-value-boost + 100)

--builder-boost-factor (default: 100)

--local-block-value-boost (default =10): Increase execution layer block values for builder bid comparison by a percentage.

--builder-boost-factor(default: 100)： Percentage multiplier to apply to the builder's payload value when choosing between a builder payload header and payload from the paired execution node.

--builder.selection (default: "executiononly"). maxprofit: An alias of--builder.boostFactor=100, which will always choose the more profitable
block.

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:

DAppNode

Sedge

Stereum

eth-docker

EthPillar

Ethereum on ARM

DVT providers

You can also run a CSM validator using the following DVT providers:

Obol

SSV

VaaS providers

Validator as a Service (VaaS) providers allow users to participate in the network without having to set up and maintain their own validator node. You can use the following integrations:

Allnodes

Stakely

Launchnodes

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

In extraordinary cases Node Operators may voluntarily eject their validators using EIP-7002-powered methods in CSM. Keys can be ejected using the CSM UI on the “Keys” → “Delete keys” → “Eject” tab.

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 considered to be “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:

• VEBO will trigger exits for the “stuck” validators;
• CSM will penalize the Node Operator's bond tokens for the delayed exits;
• CSM will confiscate withdrawalRequestFee paid by the protocol to trigger delayed validator exits from the Node Operator's bond tokens;

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.

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

Penalties

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

1. 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. Read more about the EL rewards stealing in the section below.

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

3. The operator has not exited validators in time. Penalty amount = exitDelayPenalty This penalty is applied to the Node Operators who have not exited their validators in time after VEBO request. Penalty amount is recorded once delay is reported via Staking Router. Actual penalty is applied upon validator withdrawal reporting.
4. The validator has been ejected via EIP-7002 due to an excessive number of strikes. Penalty amount = badPerformancePenalty
5. Force ejection via EIP-7002 was triggered for the validator. Penalty amount = min(actual TW fee paid, maxWithdrawalRequestFee)

⚙️ Mechanisms

📋 Node Operator Types

Node Operators can have different types, which define the Node Operator's properties. The type is set during the Node Operator creation and can be changed later. The Node Operator type is defined by the bond curve assigned to the Node Operator.

The following parameters can be set for each Node Operator type:

• keyRemovalCharge - a fee charged for each deleted deposit data record;
• elRewardsStealingAdditionalFine - an additional fine charged for each validator that has stolen EL rewards;
• keysLimit - a limit on the number of active keys for the Node Operator;
• queuePriority and maxDeposits - parameters defining the priority queue for the Node Operator;
• rewardShare - a share of the Node Operator rewards that the Node Operator receives for each validator. Can be customized depending on the key index in the Node Operator's keys storage;
• performanceLeeway - a leeway for the Node Operator's validators' performance, which is used to define a performance threshold. Can be customized depending on the key index in the Node Operator's keys storage;
• strikesParams - parameters defining the Node Operator's strikes system, which is used to decide on the Node Operator's validators' ejection due to systematic bad performance;
• badPerformancePenalty - a penalty charged for each validator that has been ejected due to bad performance;
• performanceCoefficients - coefficients used to calculate the Node Operator's performance based on the validators' effectiveness in performing duties like attestation, proposing blocks, and sync committee participation;
• allowedExitDelay - an allowed delay between the moment Node Operator's validator was requested to exit and the moment it is actually initiated exit process;
• exitDelayPenalty - a penalty charged for each validator that has been requested to exit but has not exited within the allowed delay;
• maxWithdrawalRequestFee - a maximum fee charged for each Node Operator's validator that has been forcefully ejected using EIP-7002;

The Lido DAO defines Node Operator types and associated parameters. The Lido DAO also defines Node Operators eligible for a certain type, either directly or via subcommittees granted the corresponding permissions. The Lido DAO can change the Node Operator type at any time, which will affect the Node Operator's properties and behavior.

Exact values of the parameters can be found in the table below.

🦸‍♂️ Identified Community Stakers

The Early Adoption mechanics have proven immensely effective, ushering in the onboarding of 340 Node Operators to the Lido NO Set, with a relatively low amount of Sybils (single entities/people running multiple NO accounts) making it through. Since becoming fully permissionless, CSM has seen high demand from larger node operators, leaving less room for independent stakers to join CSM and get their validators deposited to.

In CSM v2, this is meant to be addressed through the implementation of Node Operator Types. This new feature will allow for the assignment of differentiated usage parameters to different operator types, including a set of benefits for Identified Community Stakers (ICS). These benefits include access to a priority queue for a limited number of validators, allowing Identified Community Stakers to start their CSM validation journey quicker than permissionless (non-identified) operators. The general set of parameters that can be assigned to different types of operators is described in a separate document.

The Identified Community Stakers framework aims to introduce a possible assessment system that increases the number of independent stakers using the Lido Protocol by providing a straightforward and robust way for them to identify themselves.

The framework is based on a scoring system, where the score acts as the entry gate to the Identified Community Stakers List. Points can be earned by providing addresses that contain proofs across various categories that represent different aspects of experience, engagement, and identity:

Read more details about ICS here.

👬 Identified DVT Cluster

The Identified DVT Cluster (IDVTC) type gives independent stakers a more capital-efficient way to operate validators collaboratively through DVT. It combines the trust assurances of Identified Community Stakers with the resilience and shared operational responsibility of a four-member DVT cluster.

Each cluster must include four independent, ICS-approved participants, with every operator limited to one IDVTC. Validator keys must be generated through an approved Obol or SSV DKG process, supported by verifiable artifacts, member signatures, contact details, and ongoing monitoring.

Operators must continue using an approved DVT provider and report any provider changes. Cluster members may be replaced, provided the new participant is ICS-approved and the cluster submits updated verification.

Failure to meet the DVT or independence requirements may result in the operator being moved to the default CSM type, with corresponding changes to fees and bond requirements and possible validator ejections.

Read more details about IDVTC here.

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

Certain Node Operator types might be eligible for the limited number of priority queue seats. Each priority queue operates in a FIFO manner as described above. The priority queues are processed in the order of their queuePriority value, with the lowest value being processed first.

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 Execution Layer Rewards 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
• Adjusting the ICS framework and the scores within the framework
• Adding or removing the sources for the score from the framework
• Creating and executing Easy Tack motions for the ICS list to be updated
• Pause or stop application intake and update of the ICS list

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 a unified performance rating 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.

🛡️ 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) (mainnet)
• 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;