KVORUM
lidoSource: Snapshot · #0x1d416954538fb9b82aae05daca1be29f7b20d5f9fac61bd2eb9da1f5901a3867

Introduce an Identified DVT Cluster type in the Community Staking Module

succeededApr 13, 2026, 04:00 PM UTCsignaling · non-bindingbyFF0xff64…1fceView on Snapshot ↗

01Summary

AISummary by Kvorum

An AI summary is not generated yet. Read the description →

02Description

706 words

TL;DR

This proposal introduces a new CSM Node Operator type — Identified DVT Cluster (IDVTC) — allowing groups of 4 Identified Community Stakers (ICS) to run validators collaboratively using DVT. The design combines the trust guarantees of ICS with the resilience of DVT, offering improved capital efficiency while maintaining strict eligibility requirements and DAO oversight. For full proposal details, please refer to the Research Forum.

Background and Motivation

While the Community Staking Module (CSM) already supports permissionless DVT-based validator operation, it does not currently offer a capital-efficient path tailored to independent DVT clusters. At the same time, DVT adoption across the Lido protocol has continued to grow, and the Identified Community Staker (ICS) operator type has also seen strong demand from stakers willing to operate under more economically attractive conditions. The proposed IDVTC type builds on both developments by combining the resilience benefits of DVT with the trust assumptions of ICS, creating a more suitable framework for small independent operators running validators collaboratively.

Proposal

This proposal introduces a new Node Operator type in the CSM: the Identified DVT Cluster (IDVTC), which will allow clusters of 4 verified, independent community stakers to operate validators together using DVT, and an economics model designed for shared validator operation.

To qualify, each participant in an IDVTC must already be approved under the ICS framework or already be an ICS operator. The cluster must use an approved DVT setup (such as Obol or SSV), generate keys through a Distributed Key Generation (DKG) ceremony of a chosen DVT provider, provide the required proof artifacts, signatures, and contact information, and remain enrolled in monitoring. Each participant may only belong to one IDVTC at a time. If an IDVTC stops meeting the requirements, it may be downgraded to the default (permissionless) CSM type, with the corresponding default fee and bond parameters applied. To support onboarding and ongoing administration, approved clusters would be added to the relevant CSM gate via Easy Track motions initiated by the CSM Committee after review.

The new type is proposed to go live with the CSM v3 release, expected in Q3 2026.

Parameters

The proposed parameterization is intended to make IDVTCs more capital-efficient than other operator types within the CSM at certain capital levels, aiming to give IDVTCs a higher capital multiplier than standard ICS and permissionless CSM operators, especially in lower and mid capital ranges, reflecting the view that DVT reduces risks such as downtime, slashing, and Execution Level rewards stealing.

Identified_DVT_Cluster_type.png

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

The parameters are proposed as follows:

ParameterValue
Node Operator reward3.5% for the first 64 keys; 2% for subsequent keys
Bond1.5 ETH for the first key; 0.5 ETH for each subsequent key
Priority queueup to 40 keys over the cluster lifetime can be added via priority queue (lower priority than ICS keys); remaining keys via general queue
Strikes parameters2 strikes till key exit; strike lifetime: 4 months

CSM Committee mandate update

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
  • Pausing or stopping the application intake and update of the IDVTC list
  • Updating the IDVTC list (on-chain, via Easy Track)
  • Monitoring, detecting, and downgrading the operator type if requirements are no longer met (on-chain)

All responsibilities, requirements, and eligibility criteria remain subject to DAO oversight and may be modified, reassigned, revoked, or overridden by tokenholders through a DAO governance vote at any time.

Next steps

If the community supports the proposal, the following steps will be taken:

  • The CSM Committee will be assigned responsibility for maintaining the IDVTC framework.
  • The new IDVTC type will be introduced in CSM as part of the CSM v3 release, including the eligibility rules, DVT operating requirements, dedicated reward/bond/queue/strike parameters, the downgrade mechanism defined in this proposal, and the updated CSM Committee permissions.

03Mismatch analysis

AIMismatch analysis by Kvorum

A calldata-vs-description analysis is not generated yet. Review the decoded actions →

04Actions

0 total

This proposal carries no on-chain actions.

05Tally

Summed from votes

Voters55
VP participating0
Outcome (current)For
Current support100%

06Voters

55 total
Filter:
VoterChoice% of totalRationale
4A0x4af8…6a0bFor015.60%—7mo ago
420x42e6…3fb0For013.67%—7mo ago
6C0x6cd6…b52eFor012.40%—7mo ago
B60xb664…f890For010.83%—7mo ago
A40xa418…b737For010.43%—7mo ago
810x8172…922eFor09.30%—7mo ago
1F0x1f76…5ed6For09.24%—7mo ago
LIlido.banteg.eth0x55bc…f0faFor06.02%—7mo ago
450x45bc…fd99For03.54%—7mo ago
6D0x6d8d…0cccFor02.90%—7mo ago
6F0x6f9b…8a1dFor02.75%—7mo ago
310x3133…5c00For02.07%—7mo ago
E80xe80e…28e8For00.39%—7mo ago
9C0x9cbc…7519For00.27%—7mo ago
060x06a9…bba0For00.20%—7mo ago
360x36f7…a589For00.14%—7mo ago
3D0x3ddc…05b0For00.11%—7mo ago
3D0x3d63…4afcFor00.07%—7mo ago
B90xb933…8dd1For00.05%—7mo ago
390x3940…a5fcFor00.00%—7mo ago
F80xf804…9d2eFor00.00%—7mo ago
3D0x3d5a…b97fFor00.00%—7mo ago
F10xf1cc…ac93For00.00%—7mo ago
B10xb1f8…4250For00.00%—7mo ago
640x6409…8590For00.00%—7mo ago
FD0xfde2…c13cFor00.00%—7mo ago
8E0x8e18…8c7bFor00.00%—7mo ago
A90xa9bf…1577For00.00%—7mo ago
1D0x1d71…b6b0For00.00%—7mo ago
9C0x9c9a…bc0cFor00.00%—7mo ago
D90xd929…5e47For00.00%—7mo ago
100x10e3…b4a7For00.00%—7mo ago
B90xb93e…02fcFor00.00%—7mo ago
A70xa7b5…49f2Against00.00%—7mo ago
170x1729…b879For00.00%—7mo ago
0D0x0df5…105dAgainst00.00%—7mo ago
9D0x9d57…65a5For00.00%—7mo ago
4D0x4d32…bbfaFor00.00%—7mo ago
1F0x1f3d…0591For00.00%—7mo ago
2F0x2f2f…f78aFor00.00%—7mo ago
B30xb3bf…6ce4For00.00%—7mo ago
CE0xce57…70f0For00.00%—7mo ago
BF0xbfd1…4f66For00.00%—7mo ago
010x0151…c3b9For00.00%—7mo ago
AF0xaf90…7b3bFor00.00%—7mo ago
650x659f…dadcFor00.00%—7mo ago
340x3426…5404For00.00%—7mo ago
3F0x3fb1…4c8aFor00.00%—7mo ago
4D0x4d4a…1bdfFor00.00%—7mo ago
C30xc3a2…e6eeFor00.00%—7mo ago
Showing 50

07Forum

No forum thread is confidently linked to this proposal.

08Similar proposals

AI · embeddings

No semantically similar proposals found yet.