Vote #188 has just started!
This is a rerun of Vote #187, featuring the same set of proposals.
Voting is open until the end of the main phase: May 30, 09:00 UTC.
Follow this guide for instructions on reviewing and verifying vote items.
Your voice matters! 
Thank you all who participated in the Community Staking Module v2. Architecture and Fee Structure Snapshot, the proposal passed! 
The results are:
For: 50.9M LDO
Against: 2 LDO
Vote #188: Passed and Enacted!
Thanks to everyone who took part in the voting process.
Results:
Yes - 51315931.2 (5.13%)
No - 5.1 (0.01%)
We’re grateful for your trust and continued support! 
The Community Staking Module (CSM) Early Adoption mechanics have proven immensely effective by ushering in the onboarding of 340 Node Operators to the Lido NO Set while preventing major sybil-related incidents. Since becoming fully permissionless, CSM has seen high demand from large players, 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, a new feature which 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 limited access to a separate queue, allowing Identified Community Stakers to join CSM in a prioritized order compared to permissionless (non-identified) operators. The general set of parameters that can be assigned to different types of operators is described in a separate document.
As a reminder, before going further, CSM v2 will remain fully permissionless for anyone who wants to use it with the default parameters. This framework is solely related to showcasing one way for a subset of node operators to apply to opt-in to a special node operator type.
While a technical solution for implementing these benefits has been described, the question of who qualifies for this special NO type (Identified Community Staker) and how this qualification is assessed remains open. This 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 should be designed in alignment with the following principles:
The proposed 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 (see “Categories of score sources”).
To be included in the list, applicants must obtain a sufficient score in each category.
Addresses that contain proofs, as well as contact information, can be submitted via an application form. Applications can be submitted at any time during the period of Identified Community Stakers onboarding, while updates to the Identified Community Stakers List occur in waves—e.g., monthly—via a governance process.
The Lido DAO can pause or stop the onboarding period for Identified Community Stakers at any time by decision being made by the LDO token holders through a Snapshot vote.
The required score can only be obtained by combining proofs across different categories. This makes it difficult to abuse or sybil the system, while still allowing the average crypto user interested in home staking and curious about the Lido Protocol to submit a valid combination without much effort.
This group of proofs reflects a user’s experience with Ethereum validation.
Valid sources in this group should:
Possible sources to use:
All of these sources must be analyzed collectively to prevent the inclusion of sybils or professional node operators.
To obtain points from the Proof-of-Experience category, an applicant must specify in the application an Ethereum address that either is present in one of the lists described above, or was previously used to operate validators on the CSM mainnet or testnet.
This type of proof can be divided into categories that represent different forms of engagement.
Lido-centric engagement sources:
This group represents users’ engagement within the Lido ecosystem. Potential sources include:
Ethereum contribution sources:
This group represents user contributions to public goods and applications related to Ethereum validation. Though the audience may be niche, it ensures alignment with the Ethereum ecosystem by awarding highly skilled contributors. GitPOAPs reflecting GitHub contributions are suggested for this purpose.
Examples of trackable projects:
Applicants must specify their Ethereum addresses that interacted with Lido governance, have a sufficient score in the Lido Galxe space, or have GitPOAPs of the projects listed. To obtain a score for Discord/X/Research forum engagement, applicants must provide their nicknames on the corresponding platforms in the application.
Humanity sources:
This group of proofs allows users to earn a score by being verified by third-party platforms that apply their own rules for identifying real individuals.
Requirements for platforms:
Human Passport is currently under consideration as a platform to include.
While allowing many platforms improves flexibility, it also increases the risk of abuse, as malicious actors might verify under one identity across different platforms. It’s recommended to limit the number of accepted platforms to one or two.
Contact sources:
Users can obtain a score by providing their contact information for troubleshooting purposes.
Two types of accounts can be submitted:
The accounts provided in the application must belong to the applicant and should not be newly created. The activity of the accounts could be analyzed to determine whether it is bot or AI-driven.
Summing up, each applicant should obtain a sufficient score for each category, as well as a sufficient overall score (sum of the scores from all the categories). Each source can bring participants a certain amount of points.
Even though the exact score composition is not defined yet and is subject to DAO decision, the table below reflects the proposed way of how it will work:
People interested in being included in the Identified Community Staker list must:
(OPTIONAL)(OPTIONAL)Once submitted, the application goes through the following checks:
If all checks are successful:
If any check fails:
These checks will be carried out in a semi-automated manner, with some human review by Lido contributors and the CSM Committee members.
The Identified Community Stakers List will be stored as a Merkle tree. It is proposed that the CSM Committee execute on-chain updates of the List via the Easy Track governance mechanism.
Required steps:
(Lido contributors)(Lido contributors)(CSM Committee)Additional measures may be introduced later to protect the system. These would aim to detect multiple ICS operators operated by the same person/team and could be based on heuristics or some form of an arbitration mechanism.
By publishing this proposal, we want to encourage the LDO token holders and the community members to provide feedback on the framework proposed.
The further implementation of the framework will require:
This framework seems like a reasonable barrier — it helps prevent multi-account abuse and professional operators posing as solo stakers.
However, I have a few questions and comments:
If I understand correctly, the CSM queue is currently full, and registration is required to gain priority access. Doesn’t this make the system not entirely permissionless, given that without registration, new users may be effectively blocked due to demand?
Currently, the only clear benefit of registration is being placed on a priority list. Could you outline any additional advantages? Clarifying these might help increase user engagement and participation.
Currently, CSM share limit is low due to multiple factors:
With the current situation with the deposits, we expect points 2 and 3 to be resolved soon, and the module is mature now. So, in the next on-chain window (after DualGovernance activation), I will propose adding a CSM share limit increase to the on-chain vote.
Identified Community Stakers are CSM’s top priority. Hence, it is reasonable to give them limited priority queue seats.
Most of the CSM params are configurable per-node-operator-type in CSM v2. The obvious benefit is reduced bond, but more benefits will be proposed soon.
Hey @cp0x , these are very good questions!
The concern is totally understandable. There are two things that from my perspective address the possible issue you’re describing:
Yeah, there are quite a few parameters that can be customized for different operators types, most importantly:
All of the possible ones are described here, but the actual values for permissionless/ICS are yet to be proposed
I think most NO would like to see this particular item with specific values )
I understand that these settings CAN be configured, but they are not configured yet
The Lido DAO approved CSM v2 design and reward structure! As mentioned in the CSM Evolution post, any reward structure changes should come with a “grace period” that will allow CSM Node Operators to remove their validator keys from the queue without paying any keyRemovalCharge.
Since CSM v2 mainnet release is expected in August 2025 (an approximate date), I propose to enable a “grace period” for CSM Node Operators by setting keyRemovalCharge = 0 in the on-chain vote in July 2025 (the closet not fully filled on-chain slot).
The “grace period” will effectively end with the CSM v2 upgrade since, due to the smart contracts architecture, CSM v2 will rewrite this parameter back to 0.02 ETH.
Are these POAPs transferrable?
Lido DAO has approved CSM shareLimit increase from 2% to 3%, should the following conditions be met:
Currently, all depositable validator keys in the SimpleDVT module are deposited, and Curated Node Operator Pier Two (id #36) has 100 active validator keys. If deposits continue, and the corresponding EasyTrack motion to increase the staking limit for Pier Two is executed, I optimistically expect that Pier Two will have >1000 active keys by the time of the on-chain vote in July.
Should Pier Two have at least 1000 active keys by the time of the July on-chain vote slot, I propose to include a shareLimit increase for CSM in the on-chain vote in July with the following parameters:
stakeShareLimit = 300 BPpriorityExitShareThreshold = 375as approved by the Lido DAO in the corresponding snapshot vote.
Incredible CSM v2 features were recently introduced to the community. Today, I want to suggest and bring to public discussion possible approaches and values for different parameters affecting the module and CSM Operators (both Permissionless and Identified Community Stakers)
The gist of the suggested approach is:
| Parameter | Short description | Permissionless participants | Identified Community Stakers |
|---|---|---|---|
| PerformanceCoefficients | Coefficients used to calculate the Node Operator’s performance based on the validators’ effectiveness in performing duties, namely: attestation, proposing blocks, and sync committee participation | C_{a} = \frac{54}{64}, C_{b} = \frac{8}{64}, C_{s}= \frac{2}{64} | C_{a} = \frac{54}{60}, C_{b} = \frac{4}{60}, C_{s}= \frac{2}{60} |
| PerformanceLeeway | Difference in performance with the average network leading to a bad performance strike for the validator | 3% | 5% for the first 150 validators, 3% for the rest |
| StrikesLifetime | Number of the Performance Oracle frames during which the accumulated number of strikes is calculated | 6 Oracle fames | 6 Oracle fames |
| StrikesThreshold | A number of strikes required for the permissionless validator ejection | 3 | 4 |
| BadPerformancePenatly | A penalty for the validator that was ejected due to strikes accumulated for bad performance | 0.258 ETH | 0.172 ETH |
| ElRewardsStealingFine | Additional penalty for the confirmed and settled EL stealing incident | 0.1 ETH | 0.05 ETH |
| AllowedExitDelay | Allowed time to exit a validator after being requested by VEBO | 4 days | 5 days |
| ExitDelayPenalty | Penalty for not exiting a validator after requested by VEBO | 0.1 ETH | 0.05 ETH |
| KeyRemovalCharge | A charge to prevent “queue stuffing” with keys people never intend to use | 0.02 ETH | 0.01 ETH |
| PriorityQueueMaxDeposits | Priority in deposits for a limited number of validators | - | 10 keys |
| QueuePriority | Index of the priority queue | 5 (lowest priority) | 0 (top priority) |
| MaxWithdrawalRequestFee | A limit on the TW fee compensation | 0.1 ETH | 0.1 ETH |
The detailed approach and values are available here
Proposed params, including bond curves described in the posts above, has been uploaded to IPFS - https://ipfs.io/ipfs/bafkreicu5cupeln7z7nbhycrq44w7ac3qnqmw6rxu5mq6myupkclomuu5m
There were many posts about CSM v2 in this thread recently. Topics of CSM Evolution, CSM Rewards Structure, CSM v2 Architecture, Community Stakers Identification Framework, and Major CSM Parameters were covered.
This post attempts to collect the updates from these topics into one place, and give an insight into release and future maintenance.
As a Lido DAO contributor and tech lead of the CSM project, I propose the following plan for the CSM v2 mainnet release:
Step 1. Work with the relevant contributors on the Triggerable Withdrawals implementation (the TW scope and LIP are expected to be published soon) and prepare a joint CSM v2 + Triggerable Withdrawals release.
Step 2. Release CSM v2 + TW on Hoodi testnet at the very beginning of July 2025.
Step 3. Start an on-chain vote to activate a temporary key removal “grace period” (key removal from the queue with no charge) for CSM as mentioned in the recent post.
Step 4. Perform extensive testing of CSM v2 and TW functionality on Hoodi testnet.
Step 5. Propose a Snapshot vote regarding CSM v2 release covering CSM parameter values, CSM stakeShareLimit increase to 5% upon CSM v2 release, and to 10% later in 2025/early 2026 (motivation is provided below), and Community Stakers Identification Framework with the exact sources and weights for each source (proposed sources and weights will be published later in this thread).
Step 6. Finalize security audits of CSM v2 and TW release scopes, and publish the results of the audits in GitHub - lidofinance/audits and on Lido Research Forum.
Step 7. Start an on-chain vote for CSM v2 + TW release in the second half of August 2025.
I encourage the community to investigate the proposed release plan and share their questions/voice support!
stakeShareLimit increase plansLido DAO has recently approved a stakeShareLimit increase for CSM from 2% to 3%. As mentioned in one of the posts above, this proposed change is expected to be included in the scheduled on-chain vote for July 2025.
CSM v2 brings several key improvements to the module’s reliability, security, and efficiency, namely:
Taken together, these factors make scaling CSM to a double-digit percentage of the protocol a viable and sustainable possibility.
Also, several things have happened since the initial risk analysis for CSM:
Given these considerations, the CSM stakeShareLimit is proposed to be increased to 5% upon CSM v2 release. Then, following stake distribution and performance analysis, it will again be considered for an increase to 10% around the end of 2025/early 2026. This share increase is expected to significantly increase Node Operator diversity and further push Lido along the decentralization curve, all while maintaining a robust underlying validator set for both Lido and Ethereum.
Now let’s talk about Identified Community Stakers (ICS). To start with, here is a short summary of our current thinking on ICS rollout:
With the introduction of the Identified Community Staker (ICS) Node Operator type and the Identification framework, a reasonable question arises: “Would current Early Adoption (EA) Node Operators be converted into ICS automatically in CSM v2?”
To consider this question, the following observations should be accounted for:
Given that, I propose the following approach to the conversion of EA Node Operators to ICS Node Operators:
All CSM EA Node Operators will retain their beneficial bond curve ([1.5 ETH, 1.3 ETH, …]) and will automatically be assigned a “Legacy EA” Node Operator type. This type will share all parameters with the “Permissionless” Node Operator type, with the exception of the bond curve, which will be [1.5 ETH, 1.3 ETH, …].
The migration process to the ICS Node Operator type will not be automatic. EA Node Operators eligible for the ICS Node Operator type will be added to the initial ICS list in CSM v2. After the CSM v2 release, all members of the initial ICS list will be able to claim their new ICS Node Operator type using the CSM UI or via direct interactions with CSM smart-contracts, namely a dedicated instance of VettedGate.sol, which will be listed on the Lido docs before the release.
Since the ICS List will be made out of addresses and not Node Operator IDs, the following addresses of the eligible Node Operators will be included in the initial ICS list:
extendedManagerPermissions=false, the rewardAddress will be includedextendedManagerPermissions=true, the managerAddress will be includedI encourage the community to investigate the proposed conversion plan and share their questions/voice support!
An application process for the ICS list will be opened sometime before the CSM v2 mainnet release (in a month or so). The applications will be submitted using CSM UI. As soon as Lido contributors and CSM Committee members review the application, users will be able to see the status of their application.
Addresses from the approved applications will be incrementally added to the ICS list. Since the ICS list is stored on-chain in a dedicated instance of VettedGate.sol, it can not be updated in real time. Actual updates are proposed to be made using Easy Track motions. CSM Committee members will periodically post an updated version of the ICS list on the Lido research forum and in IPFS, and will propose the on-chain update of the list via a dedicated Easy Track motion to allow Lido DAO to object to the change should something go wrong with the updated version of the list.
After the ICS list update, all addresses added to the list will be eligible to claim the ICS Node Operator type using the CSM UI, alternative UIs that integrate this functionality, or via direct interactions with CSM smart-contracts.
To enable the described process, a new Easy Track factory that will allow the CSM Committee to update the ICS list is proposed.
Here are some frequently asked questions that can help CSM Node Operators navigate the complex topic of Identified Community Stakers.
Q: I’m an EA CSM Node Operator. Would I be eligible for the ICS Node Operator type automatically?
A: Some EA Node Operators will be eligible for the ICS Node Operator type from Day 1 of CSM v2. Refer to the section “Conversion of EA Node Operators to ICS Node Operators” to learn more about the proposed eligibility criteria.
Q: I own an address from the initial EA list, but haven’t joined CSM yet. Would I be automatically eligible for the ICS Node Operator type?
A: No. The initial ICS list will be formed out of EA Node Operators that have already joined CSM and meet the above-mentioned criteria (see Conversion of EA Node Operators to ICS Node Operators). Subsequent updates of the ICS list will be performed based on applications from users. So you will have to submit an application to indicate your intent to join the ICS list. See the section “New ICS Node Operators” for more details.
Q: I’m a regular (non-EA) CSM Node Operator. How and when can I become eligible for the ICS Node Operator type?
A: Non-EA CSM Node Operators will be able to apply for inclusion in the ICS list sometime before CSM v2 mainnet release. If the CSM Committee approves the application, an address from the application will be included in the next iteration of the ICS list update (sometime after CSM v2 mainnet release). Once the ICS list is updated, the addresses included will become eligible to claim the ICS Node Operator type. See section “New ICS Node Operators” for more details.
Q: I’m not a CSM Node Operator yet. How and when can I become eligible for the ICS Node Operator type?
A: The Application process for new Node Operators is described in the “New ICS Node Operator” section above.
Title: CSM NO #XXX initial ICS list inclusion appeal
Body: I’m the owner of CSM NO #XXX <link to the verified signature on etherscan from manager or reward address>, and I want to appeal the decision to not include my address in the initial ICS list for CSM v2. I confirm that:
Thanks for putting this together, very handy!
I’ve also put together a JSON data file (along with a JSON schema that it validates against) with the values in case someone wants to load them into some calculator / application / workbook, and also to serve as a template for other NO types if someone wants to play with the idea of custom new ones.
This post is an extended version of the Identified Community Stakers (ICS) framework post published previously, with the addition of proposed parameter values for each framework category described below.
The Community Staking Module (CSM) Early Adoption mechanics have proven immensely effective, ushering in the onboarding of 340 Node Operators (NOs) 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.
As a reminder, before going further, CSM v2 will remain fully permissionless for anyone who wants to use it with the default parameters. This framework is solely related to showcasing one way for a subset of node operators to apply to opt-in to a special node operator type.
While a technical solution for implementing these benefits has been described, the question of who qualifies for this special NO type (Identified Community Staker) and how this qualification is assessed remains open. This 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 should be designed in alignment with the following principles:
The proposed 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 (see “Categories of score sources”).
To be included in the list, applicants must obtain a sufficient score in each category.
Addresses that contain proofs, as well as contact information, can be submitted via an application form. Applications can be submitted at any time during the period of Identified Community Stakers onboarding, while updates to the Identified Community Stakers List occur in waves—e.g., monthly—via a governance process.
Lido DAO can pause or stop the onboarding period for Identified Community Stakers at any time by decision being made by the LDO token holders through a Snapshot vote.
The required score can only be obtained by combining proofs across different areas. This makes it difficult to abuse or Sybil the system, while still allowing the average crypto user interested in home staking and curious about the Lido Protocol to achieve a sufficient combined score without much effort.
This group of proofs reflects a user’s experience with Ethereum validation.
Valid sources in this group should:
Sources to be used:
All of these sources must be analyzed collectively to reduce the likelihood of inclusion of Sybils or professional node operators.
To obtain points in the Proof-of-Experience category, an applicant must specify in the application an Ethereum address that either is present in one of the lists described above, or was previously used to operate validators on the CSM mainnet or testnet.
This type of proof can be divided into categories that represent different forms of engagement.
Lido-centric engagement sources:
This group represents user engagement within the Lido ecosystem. Sources to be used:
Ethereum contribution sources:
This group represents user contributions to public goods and applications related to Ethereum validation. Though the audience may be niche, it ensures alignment with the Ethereum ecosystem by awarding highly skilled contributors. GitPOAPs reflecting GitHub contributions are suggested for this purpose.
Examples of trackable projects:
Applicants must specify their Ethereum addresses that interacted with Lido governance, have a sufficient score in the Lido Galxe space, or have GitPOAPs of the projects listed. Galxe points are based on a user’s completion of a variety of activities in the Lido Galxe space, most notably:
High Signal is a system that assesses participation in public community fora (forums, Discord, etc.) and calculates a user’s score based on the quality and humane-ness of their interactions.
Humanity sources:
This group of proofs allows users to earn a score by being verified by third-party platforms that apply their own rules for identifying real individuals.
Two sources are proposed to be used:
Contact sources:
Users can obtain a score by providing some contact information (pseudonymous-friendly usernames) for troubleshooting purposes.
Two types of accounts can be submitted:
The accounts provided in the application must belong to the applicant and should not be newly created. The activity of the accounts could be analyzed to determine whether it is bot or AI-driven, which if determined would render the application ineligible.
Summing up, each applicant should obtain a sufficient score in each category, as well as a sufficient overall score (sum of the scores from all the categories). Each source can bring participants a certain amount of points as described in the table below:
| Name of the source | Score | Criteria for assigning a score |
|---|---|---|
| EthStaker solo-staker list | 6 | Submitted address is present in the latest EthStaker Solo Stakers list as a deposit address, and not excluded following the a Sybil analysis of the list |
| StakeCat solo-staker list | 6 | Submitted address is present in the latest StakeCat Solo Stakers list (Gnosischain-Solo-Stakers or Solo-Stakers-B), and not excluded following a Sybil analysis of the list |
| Obol Techne | 4-6 | Submitted address has the Obol Techne credential assigned - 4 points for Base Credential - 5 points for Bronze Credential - 6 points for Silver Credential |
| SSV Verified Operators | 7 | Submitted address is present in the SSV Verified Operators list and does not belong to a professional operator |
| CSM testnet participation | 4-5 | 4 points are assigned in case: - Submitted address belongs to a Node Operator that has been active on CSM Testnet for at least 60 days - Performance for the Node Operator is above the Performance threshold in several of the latest performance oracle reports. 5 points are assigned in case all the requirements from above are met, and the application contains an address that has Circles verification |
| CSM mainnet participation | 6 | - Submitted address belongs to a Node Operator that has been active on CSM Mainnet for at least 30 days - Performance for the Node Operator is above the Performance threshold in the latest performance oracle report |
| SDVTM testnet participation | 5 | - Participated in and completed the entire duration of a Simple DVT testnet with Obol, SSV, or Safestake as a home or community staker |
| SDVTM mainnet participation | 7 | - Actively participating as a home or community staker in the Lido Simple DVT Module on mainnet at the time of application submission |
| Human Passport | 3-8 | Submitted address has the corresponding score according to a Lido customized scoring system on Human Passport (max 8 points) |
| Circles Verification | 4 | Submitted address is verified via a dedicated Lido group on Circles |
| Discord account | 2 | - Submitted account is registered no less than 1 year ago - A unique message with the address applying to be included in the list is published from this account to prove ownership |
| X account | 1 | - Submitted account is registered no less than 1 year ago - A unique message with the address applying to be included in the list is published from this account to prove ownership |
| Lido Snapshot Vote Participation | 1 | Submitted address has voted at least three times with more than 100 LDO |
| Lido Aragon Votes Participation | 2 | Submitted address has voted at least twice with more than 100 LDO |
| Lido Galxe Score | 4-5 | Submitted address has a score on the Lido Galxe space: - 4 points if 4 ≤ Lido Galxe score ≤ 10 - 5 points if Lido Galxe score > 10 |
| Lido High Signal Score | 2-5 | Submitted address has a score on the Lido High Signal space: - 2 points if 30 ≤ High Signal score ≤ 40 - 3 points if 40 < High Signal score ≤ 60 - 4 points if 60 < High Signal score ≤ 80 - 5 points if High Signal score > 80 |
| GitPOAPs | 2 | Submitted address has at least one GitPOAP for contribution to the staking-related public good applications selected by CSM Committee |
People interested in being included in the Identified Community Staker list must:
Once submitted, the application goes through the following checks:
If all checks are successful:
If any check fails:
These checks will be carried out in a semi-automated manner, with some human review by Lido contributors and the CSM Committee members.
The Identified Community Stakers List will be stored as a Merkle tree. It is proposed that the CSM Committee execute on-chain updates of the List via the Easy Track governance mechanism.
Required steps:
In order to keep the framework flexible and to streamline the governance process around it, it is proposed that the CSM Committee will be responsible for:
Tokenholders may at any time vote to rescind or reassign these responsibilities to another group, entity, individual, and may vote to modify, extend, or remove them entirely.
Additional measures may be introduced later to protect the system at the discretion of the CSM Committee, to be proposed to the community and optimistically introduced if there is no indication of disagreement by tokenholders. These measures would aim to detect multiple ICS operators operated by the same entity/person/team and could be based on heuristics or other analysis. Node Operators possibly identified to be in violation could be entailed to some form of tobe determined arbitration mechanism for dispute resolution.
By publishing this proposal, we want to encourage LDO token holders and the community members to provide feedback on the framework proposed.
The remaining steps required for implementation of the framework are:
Really good and solid framework: it can truly support fair use of the module by solo and home stakers.
One suggestion: consider giving the CSM committee the authority to pause or stop application intake. This could speed up decision-making when needed and reduce the DAO’s load by avoiding extra votes.
Ahead of the CSM v2 launch, Lido contributors are preparing an on-chain vote to raise stakeShareLimit to 3 %, start a “grace period” with free-of-charge key removal from the deposit queue, and introduce a simplified CSVerifier. In practice, the new verifier wouldn’t affect node operators—the only change is method removal. The removed method has never been used and would otherwise require extra hard-fork maintenance to handle edge cases in the scope of the forthcoming CSM v2 upgrade vote.
Mixbytes will publish a GRAPPA verification note covering the vote’s structure and the deployment artifacts for the simplified contract.
