Community Staking Module

Proposals
127

Community Stakers Identification Framework

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.

Introduction to the Framework

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.

Requirements for the Framework

The framework should be designed in alignment with the following principles:

  • The framework should be resistant to sybiling and abuse. Though 100% protection from sybiling cannot be achieved, even with a KYC system, it should be sufficiently resistant to minimize the possibility of abuse.
  • The framework should be transparent to the community. Transparency is a key principle in the Lido community. Addresses provided by applicants should be publicly available for the sake of framework transparency.
  • People who wish to be included in the list should indicate their interest. Interested individuals must opt in voluntarily by submitting an application, ensuring that inclusion and any associated benefits are granted only to those who actively seek them.
  • The framework should be easy to understand. While preserving sybil resistance and transparency, it should not be so complex as to hinder onboarding.
  • The framework should allow for the inclusion of people who want to remain fully anonymous / pseudo-anonymous. Privacy is one of Ethereum’s core principles, and the framework should align with it. This means there must be at least one viable path for applicants to join the list without disclosing personal information.
  • The framework should support the inclusion of people just starting out with Ethereum validation. There should be a pathway for individuals with no Ethereum mainnet experience to get on the list, as CSM’s goal is to bring net-new home stakers to Ethereum.
  • The framework should respect people’s past achievements in the broader Ethereum ecosystem. Those who have contributed to Ethereum in various ways should have that engagement recognized, reinforcing Lido DAO’s alignment with Ethereum.
  • The framework should incentivize engagement in the Lido Ecosystem. As it is primarily used for Lido CSM, active engagement in the ecosystem should be acknowledged and carry weight in the overall score.

High-Level Design of the Framework

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.

Sources of Score

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.

Categories of Score Sources

Proof-of-Experience

This group of proofs reflects a user’s experience with Ethereum validation.

Valid sources in this group should:

  • Contain address lists with historical performance data.
  • Be maintained by an entity with a recognized reputation in the Ethereum community.

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.

Proof-of-Engagement

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:

  • Wagyu key generation tool
  • eth-docker
  • CoinCashew
  • Stereum
  • etc.

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.

Proof-of-Humanity

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:

  • Recognized reputation in the space
  • Built-in sybilling protection
  • Issue non-transferable identity proofs or offer an API for data access

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:

  • Discord account
  • X (Twitter) account

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.

The Score System Summary

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:

Score sources
Score sources1998×794 59 KB

Flow of application, evaluation, and claiming the ICS operator type

Step #1: Application (User-Facing)

People interested in being included in the Identified Community Staker list must:

  1. Go to the application form on the CSM Widget.
  2. Connect the address for which they want to obtain the “Identified Community Staker” operator type, and sign a message to prove ownership.
  3. Fill in the required data:
  • Up to 5 additional addresses that contain different types of proofs (OPTIONAL)
  • Contact info (OPTIONAL)
  1. Prove ownership:
  • For addresses: sign a message and provide the signature hash
  • For contact info: publish a message from the submitted contact (provide a link) or sign in using the provided accounts
  1. Submit the application

Step #2: Validation (Backend)

Once submitted, the application goes through the following checks:

  • All signature hashes are valid
  • Contact information is valid and meets account age requirements and passes bot checks
  • None of the addresses has been used in other non-rejected applications
  • Contact information hasn’t been used in other non-rejected applications
  • The required score has been achieved

If all checks are successful:

  • The application is recorded and marked as Approved
  • The status is displayed as Approved with an approximate date for the next Identified Community Stakers List update

If any check fails:

  • The application is marked as Rejected
  • The form notifies the user with an error and provides a reason or recommendation for correction

These checks will be carried out in a semi-automated manner, with some human review by Lido contributors and the CSM Committee members.

Step #3: On-Chain Update of the List (Governance)

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:

  • Convert the list into a Merkle tree and generate the root (Lido contributors)
  • Upload the tree and root to GitHub and IPFS (Lido contributors)
  • Submit a transaction from the CSM Committee multisig to initiate an Easy Track motion to update the on-chain root (CSM Committee)

Step #4: Claiming the NO Type (User-Facing)

  • New node operators: The Identified Community Staker type will be assigned during operator creation. In this case, the applicant should wait for the application approval and the ICS List update, and then create a new Node Operator in CSM with the address specified in the application.
  • Existing node operators: The type must be claimed via the CSM UI.

Additional Security Layer

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.

Next steps

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:

  • Define the actual values of the scores for each source and each category, as well as requirements/limitations
  • Make some adjustments to the framework if needed
  • The DAO Snapshot vote to approve the system
  • Develop, audit, and deploy the Easy Track for the governance process of updating the ICS list
  • Develop and deploy the interface for the application submissions.
10 Likes