Community Staking Module

[Aleksandra_G]

Proposal: Introduce an Identified DVT Cluster type in the Community Staking Module

Summary

This proposal introduces a new Node Operator type in the Community Staking Module (CSM): Identified DVT Cluster (IDVTC). The core idea is to allow clusters of verified, independent community stakers to operate validators together using DVT, with ICS-grade trust assumptions, stronger operational resilience, and incentives aligned with the fact that rewards are split among multiple people.

The proposal adds:

• A new Node Operator type and a corresponding gate into CSM.
• A DVT-specific eligibility composition.
• Off-chain monitoring and a downgrade path if requirements reflected in this proposal are not met
• A parameter set (fees, bond, queues, etc.) for the type.

Background and motivation

The Community Staking Module already enables permissionless participation for anyone who wants to run validators using DVT. Operators can form clusters and run validators collaboratively within CSM today without additional permissions. However, while this model is accessible, it does not yet provide capital efficiency tailored to independent operators who are willing to identify themselves and meet stronger trust assumptions.

The Identified Community Staker (ICS) framework was introduced to address this gap for independent operators. Since its activation in October 2025, more than 200 independent stakers have joined CSM through ICS, demonstrating strong demand from community members who are willing to operate validators under transparent and verifiable conditions.

At the same time, DVT adoption within the Lido protocol has been steadily increasing. As of the end of 2025:

• 100% of the Simple DVT Module (SDVT) validators are operated using DVT.
• Approximately 20% of CSM validators are already running on DVT.
• Around 3.5% of validators in the Curated module use DVT.

In total, this represents roughly ~8% of all validators in the Lido protocol operating with DVT.

These figures show that while DVT has demonstrated clear operational benefits, such as improved resilience and reduced single points of failure, its adoption remains uneven across modules and operator types.

Introducing Identified DVT Clusters (IDVTC) builds on both of these developments. It preserves the permissionless nature of CSM, while creating a more capital-efficient path for independent stakers who are willing to identify themselves and operate validators collaboratively via DVT. This approach combines the trust properties of ICS with the operational resilience of DVT, aligning incentives for small independent operators who share validator rewards within a cluster.

Purpose and goals

Purpose

• Grow the number of independent stakers participating as Lido Node Operators through CSM.
• Accelerate DVT adoption within Lido’s community operator set.

Goals

• Preserve the spirit and safety properties of Identified Community Staker, while unlocking the resilience benefits of DVT.
• Make DVT participation simple, verifiable, and economically attractive (to a practical degree).
• Align economics so that each participant in an Identified DVT cluster has reasonable incentives to run a DVT cluster.

Proposed parameters

The graph above compares the capital multiplier across different CSM node operator types. With the proposed parameters, IDVTC achieve a higher capital multiplier than ICS once the bonded capital exceeds roughly ~2.5 ETH.

This means that operators participating in IDVTC clusters can run more validator stake per unit of bonded capital, making the model more capital-efficient for independent stakers who collaborate through DVT.

This becomes possible by reducing the bond requirement for IDVTC due to significantly lower risks of slashing, downtime, and EL rewards stealing.

DVT incentives for the Community Staking Module are being distributed according to the incentive allocation mechanism, described in this post.

Eligibility and requirements

Cluster composition and proof of independence

• One CSM operator can be a participant in only one IDVTC.
• A DVT cluster must consist of 4 independent participants.
• Each participant must have an approved ICS application (or must be an ICS operator).
• Keys must be generated via DKG with artifacts including:
  • cluster-lock.json file for Obol clusters.
  • proofs.json file for SSV clusters.
• The cluster formation requires signatures from each member, linking their ICS identity to the cluster.
• The cluster must provide a contact information Lido contributors can use in case of issues with the DKG verification.
• Operators must agree to enrol in monitoring via DVT provider specific tooling (e.g. Obol Grafana metrics, automatic SSV Network metrics).

Obligation to run DVT

• IDVTC operators must run validators using Obol or SSV.
• IDVTC operators must generate the keys via DKG ceremony and provide proof of the output.
• Switching DVT providers is allowed as long as it remains within the approved set and is reported/observable (will require exit-enter procedure).

Downgrade policy

If an IDVTC is detected and reported by the CSM committee as not using DVT (or otherwise failing type requirements):

• The operator’s type is downgraded.
• The operator fee and bond requirements are changed accordingly to a default CSM type, which will likely cause ejection of some of the keys due to them becoming unbonded. CSM Committee can also consider downgrading participants’ ICS type in case such violation is committed.

Replacing a cluster member

Identified DVTCs may replace participants over time (e.g. if someone stops operating), while keeping the cluster within the IDVTC operator type requirements.

If a participant is replaced:

• The new participant must be another ICS-approved participant.
• No participant may be a member of more than one IDVTC at the same time.
• The cluster must submit a new 4-signature cluster statement.
• Monitoring must remain in place for all nodes.

If any of the above requirements are no longer met, the CSM Committee will proceed as described in the Downgrade section by downgrading the operator type, with the fee and bond requirements updated accordingly to the ones corresponding to the default CSM type.

ICS <> IDVTC compatibility

One CSM operator can have only one Node Operator of the ICS type, as well as be a participant in only one IDVTC.

Onboarding flow (UX)

Operators will be able to use a simple UI flow for creating an IDVTC:

1. Each participant proves their addresses ownership by signing a standardized message.
2. The cluster coordinator creates a cluster and posts four signed messages from all four participants.
3. The cluster coordinator provides contact information for the cluster that can be used for coordination with Lido DAO contributors.
4. Once the application is ready, the cluster is submitted to CSM Committee assessment, and in case of approval, the cluster address is added to the corresponding CSM gate via Easy Track motion initiated by the CSM Committee.

Managing the bond

Funding, splitting and settling the bond between the participants is entirely up to the cluster.

CSM offers flexibility in how an operator or cluster can configure its Manager and Rewards addresses. For an IDVTC, the configuration choice determines how the cluster will coordinate bond funding, as well as how the cluster will settle rewards between participants over time.

At a high level:

• On-chain: bond is tracked at the operator (cluster) level, not per participant.
• Off-chain: cluster participants must agree how they split contributions, account for top-ups (or adding bond for new keys), and settle when the operator set within the cluster changes or the cluster winds down.

The practical implication is that clusters should pick an address setup that matches their trust assumptions and the level of automation they want for distribution.

IDVTC Type Maintenance

In order to streamline the governance process around the new type, it is proposed that the CSM Committee will be responsible for:

• Adjusting the IDVTC requirements and eligibility criteria
• Creating and executing Easy Tack motions for the IDVTC list to be updated
• Pause or stop application intake and update of the IDVTC 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.

Timelines

It is suggested that the new type be added upon the CSM v3 release, which is expected to arrive in Q2/Q3 2026 together with the CM v2 launch.