# 🏛️ Community Staking Module Architecture
This document describes the architecture of the Community Staking Module (CSM). The module itself implements the ideas described in the [Community Staking Landscape](https://hackmd.io/@lido/Byp775Ay6). The primary purpose of the doc is to give a detailed description of the CSM architecture and major design decisions.
> Terms validator, key, validator key, and deposit data meanings are the same within the document
# ∑ TL;DR
CSM is a permissionless staking module aimed at attracting community stakers to participate in Lido on Ethereum protocol as Node Operators. The only requirement to join CSM as a Node Operator is to be able to run validators and supply a bond. The stake is allocated to the validator keys in the order in which the keys are provided, given the keys are valid. The bond is not directly associated with the actual validator's stake but instead treated as a security collateral. The bond is a characteristic of a Node Operator; hence, it is collateral for all Node Operator's validators. This allows for the bond reduction. The more validators the Node Operator has, the less the bond for one validator. Node Operators get their rewards from the bond rebase and from the Node Operator's portion of the staking rewards. Node Operator's portion of the staking rewards is socialized (averaged) if the validators perform above the threshold. Accumulated CL penalties resulting in a balance reduction below the deposit balance and stolen EL rewards are confiscated from the Node Operator's bond. Node Operators should perform validator exits upon protocol request or can exit voluntarily.
# 📓 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 collateral for bad behavior or poor performance;
- The **Lido DAO** is a Decentralized Autonomous Organization that decides on the critical parameters of controlled liquid staking protocols through the voting power of governance token (LDO).
- A **Node Operator** (NO) is a person or entity that runs validators;
- `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`](https://docs.lido.fi/contracts/lido/#rebase);
- **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**](https://docs.lido.fi/contracts/deposit-security-module) is a set of smart contract and off-chain parts mitigating the [vulnerability](https://docs.lido.fi/guides/deposit-security-manual#the-vulnerability);
- A validator is considered to be **“unbonded”** when the current Node Operator bond is not sufficient to cover this validator;
- A validator is considered to be ["**stuck**"](https://docs.lido.fi/contracts/staking-router#exited-and-stuck-validators) 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](https://docs.lido.fi/contracts/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;
# 🌎 General info
CSM is a staking module offering permissionless entry with a bond. This module aims to become a clear pathway for independent [community stakers](https://research.lido.fi/t/lido-on-ethereum-community-validation-manifesto/3331#lido-on-ethereum-community-validation-manifesto-1) (solo stakers or home stakers) to enter the Lido on Ethereum protocol (LoE) node operator set. The bond requirement is an essential security and alignment tool that makes permissionless entry possible without compromising the security or reliability of the underlying staking protocol (LoE).
# 🤓 Module specifics
All staking modules should conform to the same [IStakingModule](https://github.com/lidofinance/lido-dao/blob/master/contracts/0.8.9/interfaces/IStakingModule.sol) interface. That inevitably results in modules having a lot of common or similar components and logic. CSM is no exception here. For example, key storage components are based on the existing Curated module. However, several aspects are different and worth a separate mention.
### Exited and Withdrawn
The Curated module uses the "exited" statuses of the validator (both [Slashed and Exited](https://notes.ethereum.org/7CFxjwMgQSWOHIxLgJP2Bw#44-Step-4-Slashed-and-Exited) and [Unslashed and Exited](https://notes.ethereum.org/7CFxjwMgQSWOHIxLgJP2Bw#45-Step-5-Unslashed-and-Exited)) as the last meaningful status in accounting since, after this status, the validator is no longer responsible for any duties on the Beacon chain (except for the rare cases of the delayed sync committee participation). CSM, in turn, needs to know about each validator's exact withdrawal balance to decide on bond penalization. Hence, the module uses the "exited" counter reported by the accounting oracle only to return a correct number of "active" keys to the staking router and implements permissionless reporting methods to report the validator's withdrawal balance once the validator is in the [Withdrawable](https://notes.ethereum.org/7CFxjwMgQSWOHIxLgJP2Bw#46-Step-6-Withdrawable) status (actual reporting happens once validator is withdrawn).
### Stake distribution queue
A Node Operator must supply a bond to upload a new validator key to CSM. It is reasonable to allocate a stake in an order similar to the bond submission order. For this purpose, a FIFO (first in, first out) stake allocation queue is utilized. Once the Staking Router requests keys to make a deposit, the next `X` keys from the queue are returned, preserving the bond submit order.
### Alternative measures for "stuck" keys
The presence of "stuck" keys for the Node Operator indicates the [Lido exit policy](https://docs.lido.fi/guides/node-operators/general-overview/#validator-exits-policy-penalties-and-recovering) violation. In this case, a module should apply measures for the policy-violating Node Operator. CSM uses measures that are different from those of the curated module. The measures are described in the corresponding [section](#Protocol-initiated-exits) below.
### Node Operator structure
The Node Operator data structure in CSM is similar to that of the Curated module, with several minor differences:
- The `name` property is omitted as redundant for the permissionless module;
- The `rewardAddress` is used only as a recipient of rewards and excess bond claims;
- A new property, `managerAddress`, is introduced. The Node Operator should perform method calls from this address;
- A new property, `totalWithdrawnKeys`, is introduced to count the total count of the withdrawn keys per Node Operator;
- A new property, `depositableValidatorsCount`, is introduced to count the current deposit data eligible for deposits;
- A new property, `enqueuedCount`, is introduced to keep track of the unqueued keys;
# 🔄 CSM validator lifecycle
The best way to describe CSM architecture is to follow the validator lifecycle.
## 🚪 Step 1. Join CSM
*Join CSM flow*
### Node Operator creation
To become a Node Operator in CSM or register new validators for an existing Node Operator, at least one `validator pubkey`, corresponding `deposit signature`, and the corresponding bond amount should be provided.
### Deposit data preparation and upload
CSM accepts deposit data in the same [format](https://docs.lido.fi/contracts/node-operators-registry#addsigningkeys) (`validator pubkey` + `deposit signature`) as the Curated module, with the main difference being a requirement to submit the bond prior to or alongside deposit data upload.
`deposit signature` **must** sign the root of the `(deposit_message, domain)`. Where a `domain` is used to identify the chain, and `deposit_message` has the form of the following tuple:
- `validator pubkey`;
- `withdrawal_credentials` with actual [`Lido Withdrawal Vault contract`](https://docs.lido.fi/contracts/withdrawal-vault) address;
- `32 ETH amount`;
### Bond
> 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.
A bond is a property of a Node Operator, not a validator. Bond is stored in the form of stETH. Node Operators can submit bond tokens in ETH, stETH, and wstETH. Provided ETH is staked, and wstETH is unwrapped during submission to ensure stETH is the only form of a bond.
The total amount of the bond required depends on the total number of Node Operator's validators and has the form of a function [`getBondAmountByKeysCount(keysCount)`](https://github.com/lidofinance/community-staking-module/blob/main/src/CSBondCurve.sol#L177)
The graph above can be redrawn for the reader's convenience concerning the validator number, not total validators.
There might be several bond "curves" (`getBondAmountByKeysCount` function implementations). A default curve is assigned to all Node Operators upon creation. The DAO can set a custom curve for the Node Operator.
Existing Node Operators can top-up bond without uploading deposit data to compensate for the penalties or to have bond funds uploaded upfront.
#### Unbonded validators
The term "unbonded" is introduced to refer to the validators for which the bond does not fully cover this validator. Taking into account the approach when the bond is common for all Node Operator's validators, unbonded validators can be determined in a way illustrated below. In the example, validator N+1 is unbonded.
#### Possible negative stETH rebase consequences
With the bond being stored in stETH, there is a risk of a reduction in the bond amount due to a negative stETH rebase. This might result in some Node Operators being unable to claim rewards (due to the actual bond being lower than required) or even validators becoming unbonded. This problem is described in detail in [Bond Mechanics in Lido ADR](https://hackmd.io/@lido/BkAP1ie86). For this document, it is worth mentioning that no additional actions are required for CSM due to the low probability of the negative stETH rebase and a dedicated [fund](https://etherscan.io/address/0x8B3f33234ABD88493c0Cd28De33D583B70beDe35) at the Lido DAO's disposal for possible use as cover.
### Deposit data validation and invalidation (aka vetting and unvetting)
Given the upcoming [DSM v1.5](https://hackmd.io/@lido/rJrTnEc2a) upgrade, CSM will utilize an [optimistic vetting](https://hackmd.io/@lido/rJrTnEc2a#Optimistic-Vetting) approach. Uploaded deposit data will be treated as valid unless DSM reports it is not. In case of invalid deposit data detection, DSM calls `decreaseOperatorVettedKeys` to set `vettedKeys` pointer to the deposit data prior to the first invalid deposit data.
### Depositable keys
Several factors determine if the deposit can be made using corresponding deposit data. This information is reflected in the Node Operator's `depositableKeys` property. This property indicates the number of deposit data records extracted sequentially starting from the last deposited record available in the Node Operator's key storage for deposits by the staking router. This number is determined as follows:
- `targetLimit` is not set -> `vettedKeys - depositedKeys - unbondedKeys`
- `targetLimit` is set -> `min(vettedKeys,targetLimit) - depositedKeys - unbondedKeys` or 0 if the Node Operator has `stuckKeys != 0`.
### 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 the `{noId, keysCount}` batches 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 using the formula: `min(depositableKeys, keysInBatch)`.
There might be a case when a Node Operator has keys that are not in the queue since they were skipped during the queue iteration as they were not depositable at the moment of iteration. The `normalizeQueue` method allows Node Operators to place all depositable keys back into the queue.
There are several pointers regarding deposit data storage in CSM. Among the others, there are `totalKeys` and `vettedKeys` pointers. With the optimistic vetting approach, these two pointers should be in sync most of the time (`totalKeys == vettedKeys`), given that there are no reports about the presence of invalid deposit data. Hence, there are two ways for the deposit data to be placed into the queue:
- Once the deposit data is uploaded, if `totalKeys == vettedKeys`;
- After the call of the `normalizeQueue` method, in case some keys were not placed into the queue upon upload (`totalKeys != vettedKeys` at the moment of upload) or were skipped during the queue iterations;
There are methods to check the next `X`elements and remove those containing no depositable keys. These methods are required to ensure queue operation even in catastrophic scenarios resulting in significant queue "pollution" with the non-depositable keys.
A detailed description of the queue is provided in a separate [document](https://hackmd.io/@lido/ryw2Qo5ia).
### Deposit data deletion
The Node Operator might delete uploaded deposit data voluntarily if it has not been deposited yet. The `keyRemovalCharge` 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.
## 🤑 Step 2. Rewards
*Rewards overview*
There are two types of rewards for CSM Node Operators:
- Node Operator rewards;
- Bond rewards;
Node Operator rewards come from the LoE protocol's share of the Consensus and Execution layers rewards. These rewards are calculated as a percentage of the rewards of a full 32 ETH validator. Node Operator rewards are distributed between all staking modules in the same [way](https://docs.lido.fi/contracts/staking-router#fee-distribution) (proportionally based on the number of active validators per module, where `active == deposited - exited`). Each [Accounting Oracle](https://docs.lido.fi/contracts/accounting-oracle) report allocates a new portion of staking rewards to CSM. Allocated rewards are stored on the module. Then, the distribution of the Node Operator rewards for CSM Node Operators using a Merkle tree is provided by CSM Performance Oracle once in a `frame`, making a new portion of the rewards available for claim.
Bond rewards (rebase) part of the rewards come from stETH being a rebasing token and the bond being stored in stETH. After each Accounting Oracle report, `shareRate` changes (most likely increases). Hence, the same amount of stETH shares will now equal more stETH tokens.
The overall equation for the total rewards looks like this `totalRewards = 32 * moduleFee + bondAmount * shareRateChange`. More details on it are published in the [supplementary post](https://research.lido.fi/t/bond-and-staking-fee-napkin-math/5999).
A meaningful part of total rewards comes from bond rebase. The bond and the Node Operator rewards are combined before the claim. The final amount of rewards available for claiming is calculated as `bond + NodeOperatorRewards - bondRequired`. This approach also ensures that any missing bond will be recouped by the protocol prior to a rewards claim.
Also, any excess bond will be treated as a reward.
### Performance Oracle
The Performance Oracle creates a Merkle tree with the distribution of the staking rewards and delivers the root on-chain. To make the original tree available to users, it will be published on IPFS and GitHub. Instead of storing multiple roots, each new tree consists of all Node Operator rewards ever acquired by CSM Node Operators. Hence, only the latest tree is required to determine the reward distribution. The amount of rewards available for claiming can be calculated as `totalAcquiredRewards - claimedRewards`.
The Performance Oracle uses the successful attestation rate with respect to inclusion delay as a proxy for the overall performance of a validator. A performance threshold is utilized to determine the distribution of the actual Node Operator rewards. Validators with performance above the threshold are included in the distribution pool, while the rest are not. Activation and exit events are accounted for during the Node Operator's share calculation. Once the distribution pool is formed, each validator gets a staking rewards part of `totalStakingRewardsAccumulated / totalValidatorsInDistributionPool`. This effectively means that all rewards acquired by the module will be distributed among well-performers. Then, validator shares are allocated to the corresponding Node Operators, and each Operator can claim rewards for all of their validators in one go.
It is crucial to note that the Performance Oracle manages only part of the total rewards. Even if the validator performs below the threshold within a frame, bond rewards (rebase) will still be acquired. One can find an example of the rewards calculation [here](https://docs.google.com/spreadsheets/d/1hLvuOesPVOYHDqO373bdyiKn4_3UXQF1rATbgTrKhWc/edit?usp=sharing). Note that even when performing below the threshold, the rewards per validator will be higher than those for solo staking.
Setting the `frame` for the Performance Oracle report to 28 days is proposed. This will make the `frame` long enough to account for short performance outages (with a smaller frame, this effect will be lower, and the performance threshold will be less useful). Making the `frame` bigger than 28 days will result in an unnecessary delay in reward distribution.
The performance threshold should be relative to the overall network attestation effectiveness to ensure that network issues outside the Node Operator's control do not affect reward distribution.
If you want to learn more about the actual Performance Oracle algorithm, check out this [detailed doc](https://hackmd.io/@lido/BJclaWbi6).
## 👮♂️ Step 3. Penalties
### Immediate and delayed
The following penalization schemes are introduced:
1. Immediate penalization (for penalties that are unambiguous and can be assessed via trustless proofs);
2. Delayed penalty with challenge period (for cases where false positives may occur or investigation might be needed);
The challenge period for delayed penalties is implemented by separating two roles involved in the application of the penalty.
The first role is the "reporter". Members of this role can initially report a fact that should result in a penalty. Bond funds will be locked but not burned or confiscated at this stage. "Reporters" can also revoke the initial report in case of the challenge resolution in favor of the Node Operator.
The second role is called "settler". Members of this role can finalize (settle) previously reported penalties.
Separating these two roles ensures that a penalty can only be applied when two independent actors agree.
### Reasons
There are three major reasons for CSM Node Operator's bond to be penalized:
1. The validator has been slashed. In this case, the [initial (minimal) slashing penalty](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md#modified-slash_validator) is confiscated. Penalty amount = `1 ETH` (`EFFECTIVE_BALANCE / 32`);
2. The operator has stolen EL rewards (MEV). Penalty amount = `amount stolen + fixed stealing fine` (can be applied across multiple NO validators);
3. The validator's withdrawal balance is less than `DEPOSIT_AMOUNT` (32 ETH). Penalty amount = `32 - validator's withdrawal balance`;
The first penalty is reported permissionlessly using [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) to prove the fact of slashing. This penalty is applied immediately within the reporting transaction.
The second penalty has the form of a delayed penalty with a challenge period. A dedicated committee (reporter) detects MEV stealing and reports this fact on-chain, locking the bond funds. Settlement over EasyTrack motion (settler) ensures alignment between the DAO and detection committee. Once the penalty is settled (confirmed), all Node Operator's benefits are reset due to the violation of protocol rules. If the penalty is not settled for `retention_period` the locked bond is automatically unlocked.
The third penalty type is calculated using the validator withdrawal balance (actual reporting is described in the section below). 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.
### Mechanics
There are two mechanics related to Node Operator bond penalization.
The first one is burning stETH shares using the [Burner](https://docs.lido.fi/contracts/burner). Once confiscated shares are burnt, the total amount of stETH shares decreases. Hence, `shareRate` increases, effectively distributing all burned stETH value between other stETH holders.
The second mechanic is transferring confiscated stETH to the [Lido DAO Treasury](https://etherscan.io/address/0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c). This approach is applied to penalties that are used to address protocol operational costs (e.g., `keyRemovalCharge`).
Penalized funds are burned for all the reasons described in the previous section. At the moment, only one penalty transferred to the Treasury is the `keyRemovalCharge`.
### Bond shortage
If, after penalties have been applied, a Node Operator's bond is less than required to cover the current Node Operator's validators, all new rewards will be used to replenish the NO bond until it is back to the required level. Node Operators can also "top-up" the bond themselves (by submitting the required difference) to be able to claim rewards again.
If the amount of the penalty exceeds the amount of the Node Operator bond available, all available funds are burned.
### Benefits reset
A bond curve different from the default one can be treated as a benefit for the Node Operator. It is crucial to ensure a reset of the benefits in case of inappropriate performance or rule violations. There are 4 cases when benefits can be reset for the Node Operator in CSM:
- EL rewards stealing is detected and confirmed;
- Slashing is reported for one of the NO's validators;
- One of the NO's validators is ejected due to insufficient CL balance;
- Based on the DAO decision;
If the Node Operator voluntarily exits all validators and claims all bond, benefits are not reset since there were no malicious or illegal actions from the Node Operator's side.
Detailed research on this topic is presented in a [separate document](https://hackmd.io/@lido/SygBLW5ja).
## 👋 Step 4. Validator Exits
*Exits process overview*
### Voluntary exits
Given the permissionless nature of CSM, NOs can voluntarily exit their validators at any moment.
### Protocol-initiated exits
For consistency with the core protocol and other staking modules, CSM uses [VEBO](https://docs.lido.fi/contracts/validators-exit-bus-oracle) to request or trigger exits for the validators.
From the core protocol side, validator exit can be requested to cover withdrawal requests from stETH holders, or according to the decision of the DAO.
From CSM side, validator exits can be requested for unbonded validators. These exits are requested automatically using the `forcedTargetLimit`.
> `forcedTargetLimit` is currently under development within [SR v1.5](https://hackmd.io/@lido/BJXRTxMRp#Forced-Exit-Requests1). In short, it is similar to the existing `targetLimit` but exits for the validators above forcedTargetLimit can be requested immediately, even without a need to fulfill withdrawal requests from stETH holders.
Node Operators should follow VEBO events (for example, by using the [Ejector](https://github.com/lidofinance/validator-ejector)) to ensure they exit validators on time. The following penalties and limiting measures should be applied if the Node Operator refuses to exit validators after the protocol request:
1. Exclude NO keys from the queue and do not put them back until `stuckKeysCount = 0`;
2. Do not distribute staking rewards to this operator if the Node Operator's `stuckKeysCount` was > 0 during the reporting period of the Performance Oracle;
Also, in exceptional cases, Lido DAO can trigger exits for Node Operator's validators.
### Low performance for a long time
If a validator is performing below the Performance threshold for 3 frames within 6 frames, it is treated as a bad performer violating the rule of good performance within the protocol. Validators with 3 "strikes" (frames of low performance) can be ejected from the protocol using a permissionless method. There is also an option to confiscate missed profits by such validators from the Node Operator's bond. However, this option is still under consideration.
To learn more about bad-performers ejection please refer to the [separate document](https://hackmd.io/@lido/Sy0nRd36a).
### Withdrawal balance reporting
The withdrawal balance of the validator is required to release the bond and calculate the exit penalty, if any. This balance is reported permissionlessly using [EIP-4788](https://eips.ethereum.org/EIPS/eip-4788) by the CSM bot or the Node Operator themselves.
# 🫡 Conclusion
If you have any questions or think something is missing, please leave your comments.
## Appendix 1. Emergency brakes
To ensure protocol safety the following emergency brakes are proposed:
- Disable deposits from the staking router;
- Disable NO creation;
- Disable deposit data upload;
- Disable rewards distribution roots submission;
- Disable rewards claim;
Some of the methods above might be assigned to a dedicated multisig to allow fast reaction during the early maturity stages of CSM.
## Appendix 2. Methods to actors mapping
| Method | Actors |
| --------------------------------------------- | ------------------------------------------------------------------------------------------- |
| Set module target share (SR method) | Aragon agent |
| Set Node Operator's `targetLimit` | Aragon agent |
| Report validator slashing | Permissionless with proof |
| Report validator withdrawal | Permissionless with proof |
| Apply `keyRemovalCharge` | Module code |
| Set `keyRemovalCharge` | Aragon agent |
| Report invalid keys | DSM |
| Apply generic penalty for Node Operator* | Aragon agent |
| Report EL rewards stealing and lock bond | MEV stealing committee** |
| Burn locked bond | Dedicaded Easy Track |
| Submit new rewards root | Performance Oracle |
| Set bond curve for Node Operator | Aragon agent |
| Create Node Operator | Permissionless |
| Upload deposit data and bond | Node Operator manager |
| Top-up bond | Permissionless |
| Claim rewards and excess bond | Node Operator manager or reward Address |
| Delete deposit data | Node Operator manager |
| Change Node Operator's manager address | Node Operator manager |
| Change Node Operator's reward address | Node Operator reward address |
| Reset Node Operator's manager address | Node Operator reward address |
| Disable deposits from staking router | Aragon agent or DSM |
| Disable NO creation and deposit data upload | Aragon agent or [EB MS](https://research.lido.fi/t/emergency-brakes-multi-sig-upgrade/2608) |
| Disable rewards distribution roots submission | Aragon agent or [EB MS](https://research.lido.fi/t/emergency-brakes-multi-sig-upgrade/2608) |
| Disbale rewards claim | Aragon agent or [EB MS](https://research.lido.fi/t/emergency-brakes-multi-sig-upgrade/2608) |
| Enable deposits from staking router | Aragon agent |
| Enable NO creation and deposit data upload | Aragon agent |
| Enable rewards distribution roots submission | Aragon agent |
| Enable rewards claim | Aragon agent |
| Re-assign role members | Aragon agent |
\* expires after 1 year of module life
\*\* multisig
## Appendix 3. Early Adoption period
One of the challenges with permissionless entry for the Node Operators with appealing conditions is the possibility of a huge actor occupying all seats in the staking module. To overcome this, an Early Adoption period is proposed as the first stage of the CSM mainnet lifecycle. Using a Merkle proof as an entry ticket to the CSM on the mainnet during the Early Adoption period is proposed. On top of the ability to join, such node operators will be eligible for the "bond discount for the first validator". This will ensure that during the Early Adoption period, proven solo-stakers (from the Rated's list and assessed by the Lido DAO) will be able to join with a small benefit.
Please refer to the [detailed doc](https://hackmd.io/@lido/HyKgaBMj6) to learn more about the mechanics of the Early Adoption period.
## Appendix 4. Related documents
- [Simple bond ADR](https://hackmd.io/@lido/BkAP1ie86)
- [One performance threshold or more?](https://hackmd.io/@lido/BJclaWbi6)
- [CSM Early Adoption](https://hackmd.io/@lido/HyKgaBMj6)
- [Reset conditions for the CSM Node Operators' benefits](https://hackmd.io/@lido/SygBLW5ja)
- [Ejecting bad performers](https://hackmd.io/@lido/Sy0nRd36a)
- [A new approach to unbonded validators](https://hackmd.io/@lido/B1BYnxf0a)
- [CSM optimistic vetting queue](https://hackmd.io/@lido/ryw2Qo5ia)
- [A possible approach to CSM integrations](https://hackmd.io/@lido/rkYTaoXWA)
Sign in with Wallet
Connect another wallet