Preface
The following describes the architecture, mechanics, economics and responsibilities of the different stakeholders of the SSVLM module to the Lido community and beyond. In so doing, this document, with potential changes before being submitted to the Lido DAO for snapshot vote, will serve as the official proposal from the Clusterform (independent SSV Labs subsidiary company) team to the Lido DAO.
Introduction
The SSV Lido Module (SSVLM) is a permissionless staking module leveraging the open source nature of SSV Network’s Distributed Validator Technology (DVT) to integrate Node Operators (NOs) into the operator set of Lido on Ethereum.
Building on the CSM framework and incorporating insights from the SimpleDVT module, SSVLM is designed to support operations of Node Operators within DV clusters while enhancing the scalability, security, and decentralization of Lido’s staking ecosystem.
After a discussion period, this proposal will be presented to the Lido DAO as a Snapshot vote to signal whether the Lido DAO supports this direction of work.
If the vote is supported, initial deployment on Holesky testnet is targeted for Q2 2025. This would be followed by a performance review and codebase audit.
If the outcomes are successful, Lido token holders will have the opportunity to express their opinion in another Snapshot vote, which will include the technical details and parameters, followed by a final on-chain vote aiming to integrate the module into the Lido on Ethereum protocol throughout H2 2025.
Why DVT
Distributed Validator Technology (DVT) enhances validator security by distributing key management and signing duties across multiple operators. This approach reduces the reliance on a single entity, aims to improve fault tolerance and continued validator operations, even in the event of individual operator failures (depending on the configuration). Key benefits include increased security through the use of Distributed Key Generation (DKG), greater decentralization, and enhanced fault tolerance, mitigating risks of single point of failures, compromise or downtime.
Why SSV
As the pioneer in DVT, SSV Network leads the field, operating over 50,000 validators and ranking fourth by market share. Its previous experience—three years in testnet, over a year on mainnet, and multiple successful audits—makes SSV the most battle-tested DVT protocol in this space. Close collaboration with Lido DAO contributors on Simple DVT mainnet as well as previous joint testnets ensures compatibility and reliability, making the SSV Lido module the ideal, scalable, and permissionless evolution of the SimpleDVT module on mainnet.
SSVLM Benefits
For Node Operators
The SSVLM provides NOs with a permissionless pathway to join the Lido on Ethereum operator set and operate validators as part of DV clusters. Within these clusters, NOs benefit from reduced barriers to entry, as they are only required to provide a fractional bond per validator, lowering the upfront requirements for participation.
Operating within DV clusters also provides NOs with a more resilient participation model. The inherent fault tolerance of DV clusters supports uninterrupted validator operations even if an individual NO experiences downtime, significantly reducing risks such as slashing and underperformance.
The SSVLM simplifies the user experience for NOs and aims to reduce operational costs by abstracting away the complexities of managing DV clusters from NOs. Responsibilities such as key management, cluster coordination, and other coordination activities are seamlessly managed within the module, streamlining operations and eliminating costs NOs would otherwise incur, such as SSV network fees and transaction costs.
By removing these complexities, the SSVLM allows NOs to focus solely on maintaining their infrastructure and bond, without incurring additional overhead or expenses. This streamlined approach makes participation both efficient and cost-effective, positioning the SSVLM as an attractive solution for NOs.
For the Lido on Ethereum protocol
The SSVLM provides the Lido on Ethereum protocol with a scalable and decentralized way to expand its operator set. Unlike solo-operated validators, each validator in the SSVLM is managed by multiple NOs within DV clusters. This structure should allow a larger and more diverse set of operators to be onboarded into the Lido on Ethereum protocol, effectively distributing stake across multiple participants and enhancing decentralization.
DVT reduces the trust requirements placed on operators by enabling them to manage only partial key shares rather than full validator keys, with keys securely generated using Distributed Key Generation. This approach eliminates the need for operators to have custody of the validator keys, significantly reducing risks associated with key management and increasing protocol security.
Additionally, the use of DV clusters introduces diverse operator configurations, ensuring that even if one NO in a cluster goes offline, the others continue to maintain validator operations. This inherent fault tolerance creates a more resilient staking infrastructure, reducing the impact of individual NO failures and enhancing the protocol’s overall stability.
While the Simple DVT Module has demonstrated the efficacy of utilizing DVT on mainnet, the manual coordination required to assess participants, form clusters, and facilitate onboarding is not scalable for onboarding thousands of Node Operators.
As a long-term solution, the SSVLM offers the Lido on Ethereum protocol a scalable, permissionless alternative to the existing SimpleDVT module. Its design enables seamless and decentralized operator participation, making the SSVLM a foundational component of the evolving staking ecosystem around the Lido protocol.
If the proposal is accepted by the Lido DAO, a detailed risk framework will be presented for analysis before the final Snapshot vote to guide module scaling decisions. This risk assessment will be done by Lido DAO contributors, for the Lido DAO to consider as the module is proposed to scale in terms of its share limit, and does not lead to obligations for Clusterform. This framework will examine risk factors such as bond size, the percentage of verified and fully permissionless operators, as well as cluster makeup scenarios. This will allow for the Lido DAO to consider how the SSVLM can continue on the path of decentralizing the Lido Node Operator set while providing risk mitigation as the module scales over time.
For SSV Network
The SSVLM strengthens the connection between the SSV Network and the Lido on Ethereum protocol, solidifying SSV’s position as the trusted infrastructure provider for distributed staking infrastructure. This highlights SSV’s reputation for innovation and leadership in the Ethereum ecosystem.
By integrating Lido on Ethereum protocol, the SSVLM will drive greater awareness of the SSV protocol, attracting NOs who may not have otherwise joined as operators. This increased participation expands the operator base of the SSV Network, contributing to its growth and strengthening its ecosystem.
The SSVLM also creates significant growth opportunities for the SSV Network. By supporting a meaningful market share within the Lido on Ethereum protocol, the module contributes to the total value locked (TVL) managed by the SSV protocol. This expansion generates a steady revenue stream for the SSV DAO through additional network fees, directly supporting the ongoing development and success of the SSV Network.
SSVLM Design
The SSVLM is designed as a permissionless staking module enabling any Node Operator (NO) to join the Lido on Ethereum protocol. In DVT settings, operating validators within distributed clusters presents additional complexities, especially regarding secure key generation, layered coordination, and effective cluster management at scale. SSVLM endeavors to address these challenges and improves upon the limitations of the SimpleDVT module with a more robust, scalable design, developed around the following principles:
- Permissionless - Any NO that provides the required bond and is registered on the SSV Network can join the module. Additionally, incentives for Verified Operators are expected to allow for greater transparency into the make up of participating operators.
- NO Experience - Key management, cluster coordination and management requirements are fully abstracted away from NOs. This allows operators to focus exclusively on maintaining their infrastructure and providing a bond, without the burden of additional operational overhead through simplified operations.
- Lower Costs - By abstracting operational complexities, Node Operator costs that would otherwise be incurred, such as SSV network fees and transaction costs, are entirely eliminated, as these expenses are fully managed by a network of distributed Module Oracles. This approach reduces barriers and ensures a more accessible and cost-effective participation model for NOs.
- Zero Coordination & Scalable - NOs can join and operate validators within DV clusters independently, without any need to coordinate with other NOs.
- Enhanced Security with DKG - Module’s validator keys are generated through Distributed Key Generation (DKG), eliminating the reliance on any single operator to manage keys individually.
- Competitiveness - Operating within DV Clusters allows each NO to provide only a fraction of the total bond per validator, lowering entry barriers and broadening access for operators.
Considered Approaches to Cluster Coordination Design
- Trusted Management - SSV Module developers oversee the formation of NO groups into DV clusters and manage them throughout their lifecycle.
- Coordinator Management - Clusters are managed by designated “Coordinators” (contributors from Lido and others), responsible for forming and maintaining DV clusters, building on the proven approach used in the SimpleDVT module.
- Distributed Management (Chosen) - Cluster formation, management, and all other module operations are handled by a network of distributed Module Oracles.
Decision Outcome
The Distributed Management approach was chosen for the SSVLM to align with its core design principles and to provide maximal module decentralization potential for the Lido protocol. This approach leverages a network of Module Oracles to handle cluster formation, coordination, and all module operations, making the system more scalable and efficient. By automating coordination, the oracles provide a streamlined user experience for NOs, who can participate with minimal ongoing maintenance requirements. Additionally, the decentralized operation of the oracle network ensures that cluster management is distributed, reducing centralization risks and enhancing resilience across the module.
Module Architecture
Smart Contracts
The SSVLM comprises a set of smart contracts, primarily structured around two key components:
-
SSVLM Adapter - This smart contract manages the integration with the Lido protocol by implementing a Staking Router-compatible interface. It holds a registry of all the module’s validators, mapping them to their respective clusters, states, and deposit data. Additionally, it transfers staking rewards from the module to the SSVLM Core smart contract, where they are further distributed to its Node Operators.
-
SSVLM Core - The user-facing smart contract, serving as the main gateway for NOs and Module Oracles, this smart contract oversees NO onboarding, bond management, DV clusters management and rewards distribution. The smart contract is maintained by “Module Oracles”, which are in-charge of its upkeep and continued operations.
To enhance familiarity with existing codebases, streamline audits, and ensure compatibility with existing tooling, we aim to reuse much of the CSM code and processes. The smart contracts architecture is currently being evaluated and may be subject to change based on feasibility assessments.
Module Oracles
The Module Oracles are entities that collectively operate and maintain the SSVLM. Represented by a multi-signature wallet, each Module Oracle entity serves as a signer, contributing to distributed decision-making and module operation.
The Module Oracles perform their operations within the SSVLM by running the SSVLM Oracle Node software, which automates their tasks and streamlines coordination among them.
The Module Oracles are tasked with the following core responsibilities:
- Cluster Formation: Grouping Node Operators (NOs) into Distributed Validator (DV) clusters.
- Cluster Management: Overseeing and maintaining the health of existing clusters.
- Rewards Distribution: Calculating and submitting the Merkle tree data for distributing rewards.
- Exit Requests: Processing exit requests for validators and NOs.
- Penalty Enforcement: Identifying and penalizing underperforming or non-compliant NOs.
Composition, Selection and Replacement
To ensure decentralization and provide fault tolerance, the Module Oracle set will initially consist of five participants, with a quorum threshold of 3-of-5 required to execute operations.
The initial oracle set for the SSVLM will prioritize participants from the existing Lido on Ethereum protocol’s Oracle set due to their familiarity and expertise in providing oracle services for the Lido protocol. If this group does not yield the required number of participants, the selection process will focus on other reputable node operators and infrastructure providers from the Ethereum staking ecosystem.
The evaluation of Module Oracles and their contributions will be an ongoing process conducted by the module’s Admin Committee.
Compensation
Module Oracles will be reimbursed for their operational costs to ensure they do not incur operational losses. These funds will be drawn from the “Module Operations” fee allocation.
Risks
While the use of oracles introduces certain risks, these are limited strictly to their responsibilities. Even in cases of oracle underperformance or downtime, the module’s managed validators and their performance remain unaffected.
-
Single Oracle Downtime: If one Module Oracle underperforms or experiences downtime, the oracles can continue functioning as long as the quorum threshold is maintained. This fault tolerance should ensure continuity despite isolated failures.
-
Majority Oracle Downtime: If a majority of the Module Oracles go offline and the quorum is not met, ongoing module operations will halt. This includes the formation of new clusters, maintaining runway of existing clusters, processing of validator exit requests, distribution of new rewards (excluding bond rebases), and enforcement of penalties.
Operator Onboarding
To onboard as a Node Operator in the SSVLM, NOs must register with the module and provide a bond, with the amount determining how many validators they can operate, subject to a minimum validator requirement that may be enforced by the module (e.g., at least 10 validators to participate).
As a prerequisite, NOs must have an SSV Operator with preset configurations: it should be set to private, have a 0 fee, and whitelist the SSVLM smart contract. Additionally, operators are required to run both the SSV operator and DKG nodes and must provide their DKG endpoint as part of their SSV operator metadata.
To mitigate potential geographic latency issues for clusters with infrastructure located far from relay locations, NOs are encouraged to use a selection of predefined relays from the vetted list of SSVLM relays, which have proven to offer optimal geolocation coverage. The SSVLM relay list is curated and maintained by the Admin Committee. This list is derived from a subset of relays from the vetted and approved list provided by the Lido Relay Maintenance Committee, prioritizing those that demonstrate strong geolocation coverage and reliability.
During registration, NOs link their SSV operator ID to the SSVLM, completing the onboarding process after verifying the above mentioned conditions are met.
Operator Bond
The bond provided by NOs partially protects (by it being burnt) the Lido protocol from potential misconduct or underperformance. That being said, full protection is not guaranteed in cases where the severity of the infraction, such as a significant MEV theft exceeds the NO’s supplied bond.
To mitigate such risks, the bond is associated with the NO rather than the validator level. This approach helps reduce the likelihood of uncovered losses arising from infractions tied to specific validators that exceed the bond allocated per validator. However, in any case, the bond associated with the NO is the upper limit for any coverage and protection (See penalties section).
The bond is submitted in stETH or ETH (which will be staked for stETH) tokens. The bond can be topped up at any time to support additional validators (subject to the minimum validator requirement if enforced, meaning increases must align with the predefined minimum validator threshold).
In the SSVLM, NOs need to bond only a fractional share per validator, reflecting the distributed nature of DV clusters. For instance, in a cluster of four NOs, each NO is responsible for bonding a quarter of the total bond required per validator.
Similar to the CSM, the SSVLM will utilize a non-linear bonding curve. This bond curve enables NOs to operate multiple validators, with bond requirements that decrease as the number of validators they manage increases.
As part of this approach, the SSVLM might also include a bond curve reduction program for the Verified Operators - a vetted subset of operators within the SSV network, similar to CSM’s early adoption program. This initiative would reward trusted operators with reduced bond requirements, benefiting the module by attracting more professional and reputable NOs while allowing greater transparency into the Node Operators running validators via the Lido protocol.
Bond Statuses
-
Pending - The initial state for deposited bonds, representing bond amounts that are not yet assigned to a validator. Any rebasing rewards on stETH accrue to the NO’s pending bond, and this bond can be withdrawn at any time without restrictions.
-
Assigned - When an NO is allocated to a validator within a cluster by the Module Oracles, the portion of the bond backing that validator transitions to the assigned state. Assigned bonds are tied to active validators and can be withdrawn only by making a request, which will result in the exit of a validator or validators to release the bond.
-
Requested - Bonds in this state have been requested for withdrawal by the NO. These bonds are still assigned but are queued for withdrawal. The request is reviewed by the Module Oracles, who determine which validators within clusters need to be exited to a new cluster.
-
Withdrawable - Once the Module Oracles have completed the necessary operations and exited the relevant validators, the bond transitions to the withdrawable state. At this point, the NO can withdraw the bond, minus a removal charge, which accounts for the impact on the cluster.
Validator Lifecycle
Cluster Formation
Cluster formation is the process of grouping NOs to form a DV cluster and generating their validator keys through DKG ceremonies. This process endeavors to ensure the module maintains a sufficient number of available keys (undeposited) ready for activation at all times.
Cluster formation is triggered whenever the number of available keys within the SSVLM falls below a predefined threshold (e.g., if the threshold is set to 50 and the number of available keys drops to 40, the cluster formation process initiates until the threshold is restored).
Cluster Formation Flow
-
Prerequisite - NOs Onboarding & Bond Deposits
Before cluster formation begins, NOs must have registered and provided the required bond, as outlined in the NOs onboarding process. Out of the NOs who have registered, those with “pending” bond status are eligible for cluster formation and are placed in a queue, awaiting formation. -
Monitoring and Cluster Formation by Module Oracles
The Module Oracles continuously monitor the NOs queue and use deterministic heuristics to group NOs from the queue into DV clusters, initially operating on a 3/4 operator threshold with goals to transition to 5/7 in the future. As part of the cluster formation process, the Module Oracles verify the participating NOs, ensuring their settings remain unchanged since onboarding and confirming that their DKG client is live through a health check. -
Distributed Key Generation (DKG) Ceremony
Once a cluster is formed, the Module Oracles conduct a DKG ceremony, generating validator keys, deposit data (with withdrawal credentials set to the Lido protocol Withdrawal Vault), and SSV keyshares for the cluster. -
Keys Registration
After the successful DKG ceremony, the Module Oracles add the generated keys (deposit data) to the SSVLM Adapter, where they await verification and deposit by the Staking Router. Simultaneously, the validator keyshares are registered with the SSV Network, where they await activation. During this operation, the participating NOs bond status transitions from “pending” to “assigned,” reflecting their active role in the newly formed DV cluster.
Validator Activation
The activation of SSVLM validators begins with the Staking Router querying the module for available keys, which are consistently maintained by the Module Oracles to ensure a sufficient supply. The SSVLM Adapter responds with the number of DKG-verified deposit data of keys ready for activation.
Upon initiating the deposit, the Staking Router places the validator in the Beacon Chain activation queue. Because all validator keys are already registered on the SSV Network, the validator begins attesting from the second epoch after becoming active on the Beacon Chain.
Cluster Management
Throughout the lifecycle of validators within the module, the Module Oracles will continuously monitor all clusters to provide sufficient operational runway in SSV token balance to operate within the SSV Network.
If a cluster’s runway is detected to be above or below a predefined threshold (e.g., less than six months or more than 18 months), the Module Oracles will endeavor to adjust it accordingly (e.g., to maintain at least one year of runway). This proactive approach is designed not only to improve capital efficiency by accounting for validator churn but also to accommodate potential changes in the SSV protocol, such as network fee modifications or liquidation threshold updates.
The funds required for these top-ups fall under the responsibility of the Admin Committee, which oversees the reimbursement of Module Oracles for operational costs.
Rewards
There are three types of rewards for SSVLM Node Operators:
-
Bond Rewards - Rewards generated from the rebasing of stETH provided as bond by NOs to the SSVLM. These rebased rewards are credited to the NO’s “pending” bond balance, allowing NOs to either withdraw or compound them to manage additional validators.
-
Node Operator Rewards - Rewards earned by NOs for fulfilling validator duties within the SSVLM. Rewards are based on the performance and contributions of each NO within their assigned clusters.
-
SSV Incentive Rewards - NOs also receive a share of the Incentivized Mainnet (IM) rewards earned by the validators they manage on the SSV network. These rewards are distributed as part of the SSV DAO’s Incentivized Mainnet Program and will continue to be available for as long as the program remains active, as determined by the SSV DAO.
Rewards Distribution
The distribution of Node Operator (NO) and SSV incentive rewards occurs in 28-day cycles. At the end of each cycle, the SSVLM Module Oracles calculate the rewards for all NOs and construct a Merkle tree representing the distribution data. The Oracles then submit the Merkle root of that tree to the SSVLM contract, enabling each NO to claim their rewards independently.
Rewards are distributed through a cumulative Merkle contract, allowing NOs to claim both their Node Operator and SSV rewards in a single claim process. Since the contract is cumulative, NOs can accumulate rewards over multiple cycles without needing to claim them after each cycle.
To ensure transparency and accessibility, the Oracles will publish the Merkle tree data on a public platform, with options such as IPFS under consideration.
The Module Oracle calculates the rewards with respect to:
-
Validator Share Contribution - The rewards are weighted based on the amount of validators managed by each NO proportionally.
-
Validator Performance Socialization - Similar to the CSM, the SSVLM will utilize reward socialization based on a performance threshold to determine the distribution of rewards among the module’s NOs. Validators whose performance exceeds the defined threshold (“eligible validators”) will share in the rewards received by the SSVLM, with the distribution proportional to their share of eligible validators.
NO rewards per distribution cycle are calculated by the following formula:
Validator Exits
Validators within the SSVLM can be exited under two scenarios:
- Lido Exit Requests - When the Lido protocol initiates a request to exit one of the module’s validators, the Module Oracles monitor Lido protocol’s Validator Exit Bus Oracle (VEBO) events to detect and initiate these exit requests.
- Node Operator Bond Withdrawal Requests - Due to the permissionless nature of the SSVLM, NOs have the option to withdraw their provided bond at any time. Since there is no dedicated “offboarding” function, withdrawing the full bond effectively serves as offboarding. If the withdrawn bond is currently “assigned” for active validators, the withdrawal process involves two steps: “requesting” and “withdrawing.”
When a NO initiates a request to withdraw an assigned bond, the Module Oracles determine which of the NO’s validators to exit. After the Module Oracles have checked that the selected validators have fully exited from the Beacon Chain and have been removed from the SSV Network will the NO be able to proceed with the bond withdrawal.
A timelock is applied to bond withdrawal requests, delaying both the withdrawal process and the ability to submit additional requests until the timelock period has elapsed. This safeguard is designed to provide adequate time to detect and enforce penalties before the bond can be withdrawn in the event of an infraction.
Exit Charge
NOs wishing to exit while actively managing validators will incur a removal charge. This fee is calculated on a per-validator basis and is designed to cover the operational costs associated with facilitating the effective exit of their validators.
The exit charge is deducted from the portion of the NO’s bond that becomes withdrawable after their request to withdraw assigned bonds, once the validators have been fully exited and removed.
In both scenarios, the Module Oracles checks that any validator is fully exited before proceeding to remove it from the SSV Network and releasing the managing NO’s bond. As part of this process, the validator’s withdrawal balance is checked against the minimum required deposit amount. If the balance is insufficient, the Negative Validator Balance penalty is enforced, and the difference is deducted from the managing NOs’ bond.
If the Module Oracles encounter any issues in exiting the validator—such as the cluster being offline—they will submit a request through the Lido protocol (following implementation of EIP-7002 in the Lido on Ethereum Withdrawal Credentials, only possible post-Pectra hard fork) to initiate the validator exit.
, the