Identified Community Stakers Framework

Introduction to the Framework

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 Sybilling and abuse. Though 100% Sybil prevention cannot be achieved, even with a KYC system, the identification framework 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. The assessment methodology as well as 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. The mechanisms for Sybil resistance and transparency should not be so complex as to significantly hinder onboarding of interested persons.
• The framework should allow for the inclusion of persons who wish to retain pseudo-anonymity. 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 full KYC.
• 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 one of CSM’s goals 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 staking 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 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 or the CSM Committee 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 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.

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.

Sources to be used:

• EthStaker solo-staker list
• StakeCat solo-staker list
• Obol Techne
• SSV Verified Operators
• CSM testnet participation
• CSM mainnet participation
• SDVTM testnet participation
• SDVTM mainnet participation

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.

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 user engagement within the Lido ecosystem. Sources to be used:

• Participation in Lido Snapshot votes (Governance)
• Participation in Lido on-chain votes (Governance)
• Lido Galxe score (Community events and interactions)
• Lido High Signal score (Governance and community interactions)

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.

The list includes GitPOAPs from the following groups of projects:

• Node Setup / Key Tools
• Clients
• Education / Knowledge Bases
• Lido Ecosystem

The full list can be found here.

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:

• Collecting OATs from Node Operator Community Calls
• Collecting OATs from attending in-person Lido community gatherings

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.

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.

Two sources are are used:

• Human Passport
• Circles (a permissioned group using the Circles protocol to add individuals who have been confirmed by a set of group administrators to be real humans and involved in staking activities (including educational workshops); no minting of CRC tokens by the group members is needed and CRC tokens do not need to be associated with the group for participation)

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:

• 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, which if determined would render the application ineligible.

The Score System Summary

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:

Sources Breakdown

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

Step #1: Application

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

Once submitted, the application goes through the following checks:

• All signature hashes are valid and messages include the expected content (i.e. correct addresses, usernames, etc. are specified)
• Contact information is valid and meets account age requirements and passes bot checks
• None of the addresses submitted is/are related to/associated with the addresses previously used in other non-rejected applications
• None of the addresses submitted is/are related to/associated with the excluded addresses (professional operators, VaaS, etc.)
• Contact information hasn’t been used in other non-rejected applications
• Minimum score in each category, as well as the total required score have 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

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

• 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. Alternatively, if a new Node Operator wants to supply their bond and get keys in the default queue before the application is processed, they can do so and, if their ICS application is approved, claim the NO type later.
• Existing node operators: The operator type must be claimed via the CSM UI.

Framework Maintenance

In order to keep the framework flexible and to streamline the governance process around it, the CSM Committee oversees the framework and is responsible for:

• 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

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 Security Layer

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 to be determined arbitration mechanism for dispute resolution.