Ethereum Secret Shared Validators

SSV Tech


Secret Shared Validators (SSV) is the first secure and robust way to split a validator key for ETH staking between non-trusting nodes, or operators. A unique protocol that enables the distributed control and operation of an Ethereum validator. The validator key is split in such a way that no operator must trust the other to operate, a certain amount can go offline without affecting network performance, and no operator can take unilateral control of the network. The result is decentralization, fault tolerance, and optimal security for staking on Ethereum and in the future more POS chains.

Ethereum Staking & Validators

Ethereum’s new consensus layer (formerly known as Serenity, Ethereum 2.0, and Eth2) represents the blockchain’s transition from a Proof of Work (PoW) to a novel Proof of Stake (PoS) consensus mechanism. With this, Ethereum miners will no longer secure the network; rather, operators known as validators lock up funds in the protocol to perform network duties, otherwise known as ‘staking.’ In order to run a validator, one must put 32 ETH at stake, run a dedicated software (validator client), and run both a legacy Ethereum node and beacon chain node. Needless to say, this can be quite technologically complex for many individuals.

Diving a little deeper, a validator will generate 2 separate BLS12-381 key pairs; a validator key (public and private) and a withdrawal key (public and private). The withdrawal key is solely used to transfer and withdraw staked ETH and must be stored securely offline. In order to perform network duties, the validator key signs data, once an epoche, about every 6.4 minutes and is rewarded for correctness and timeliness. By nature, this key must be online at all times, presenting a number of connectivity and security challenges.

Managing Ethereum Validator Keys

Securely storing validator keys while ensuring optimal connectivity and performance is perhaps the biggest pain point for Ethereum stakers and service providers. If a validator key gets hacked, or if incorrectly stored, a validator risks losing all ETH they have at stake in addition to forcible removal from the network (slashing). If a validator key goes offline, a staker risks losing out on opportunities to earn ETH in addition to receiving minor penalties

The difficulty of managing a validator and associated keys has led to the rise of staking services to streamline Ethereum staking. Unfortunately, each staking service in existence today is vulnerable to single operator failure; there is no staking solution that can protect users’ validator keys and optimize uptime and performance with absolute certainty.

Ethereum Staking Services & Associated Risks

Solutions for Ethereum staking range from full custodied services that retain unilateral operative control of both private keys, to non-custodial services that provide staking infrastructure while users retain private key control. Both have caveats. Non-custodial services provide optimal security and privacy, yet come at the cost of a more challenging/technical user experience. In addition, they cannot currently implement active failover for all infrastructure components or protect against network-wide disruptions; more on that below.

Custodial solutions are more convenient and user-friendly, yet introduce the risk of severe slashing penalties, potential hacks, and network-wide centralized control. If a malicious actor gains control of the service, all user keys can be compromised. If the service makes a mistake and takes part in a slashable offense, each validator will be punished with great severity as the protocol’s anti-correlation rules dictate an exponential increase in penalty the more validators participate in the same event.

Avoiding such scenarios while optimizing for performance is no trivial task. In fact, services and individuals risk downtime, hacks, and slashings just by performing system maintenance! Given strict protocol rules, active-active redundancy (having active failover in place as a backup if some part of a system goes down) is difficult if not impossible to achieve. Hence, switching from active to passive solutions while performing maintenance tasks can be a stress-inducing task for operators.

Additionally, efforts to implement active-active redundancy can have disastrous outcomes, the majority of slashing events to date have occurred when an operator tried to run the same validator keys on different validator client instances; leading to slashing when both became active at the same time (a big no-no in the protocol rules). Overall, validator resilience is a challenge for any operator, regardless of technical level of expertise.

SSV: The New Age of Staking on Ethereum

Secret Shared Validators (SSV), as the name suggests, is a protocol that splits a validator key between non-trusting parties into ‘KeyShares.’ It delivers active-active redundancy for staking on Ethereum. Its core strength is in its robustness and fault tolerance – if a KeyShare is unavailable or faulty (due to a hack, error, or scheduled maintenance, etc.), the rest of the network actively continues to perform its duties without pause. Fully customizable, SSV opens up the possibility for many unique and complex staking configurations, the likes of which have never been possible to date, and which serve to transform the entire Ethereum staking ecosystem.

History of SSV

SSV was originally a research paper conceptualized in collaboration with members of the Ethereum Foundation, later labeled DVT (Distributed Validator Technology). At its core, DVT (aka SSV) enables the distributed operation of an Ethereum validator across varying operators. is an infrastructure layer designed to promote decentralization, diversity, fault tolerance and resilience to the ETH staking space.

SSV roadmap
SSV roadmap.

SSV / DVT at a High Level

SSV, at its heart, is a way to decentralize risk and reduce failures by making individual SSV nodes become a robust network that can outperform any individual staking service in security, robustness, and uptime. Validators run portions (KeyShares) of their validator key across different staking setups (nodes) joined together by a consensus layer.

No node on the network needs to trust the other to operate, and a certain number of faulty nodes (up to the threshold) can be tolerated without affecting validator performance. In addition, no node can recreate a validator key signature on its own or make unilateral decisions; paving the way for trustless networks distributed across multiple people or staking services.

SSV Network basic setup.

SSV is a middle layer between a beacon node and a validator client, a blockchain within a blockchain, managing the process of splitting a validator key and reconstructing it for signing. A majority of nodes is needed to recreate the key for signing. For example, in an SSV configuration of 4 nodes, only 3 are needed to recreate a validator key signature, allowing 1 to be faulty or to go offline without affecting validator performance in any way.

Now here’s the kicker, of those nodes, each one can operate their KeyShare of the validator key in the way they see fit. Each node can leverage a different validator client, on completely different infrastructure, from anywhere in the world. Allowing SSV stakers to easily diversify their validators between operators, geolocations, validator clients, and other infrastructure vectors. If one of the nodes is faulty in any way; is suffering from poor performance or even commits a slashable offense, the SSV network will keep on validating despite that one node’s shortcomings. This is both excellent for validator liveness (performance) and security.

Layered Infrastructure Design

In order to operate, has 2 distinct layers:

  • SSV Peer to Peer (P2P) network layer
  • Ethereum contract layer for network governance

Promoting Validator Liveness and Security

For any staking use case, there are two main concerns:

  • Optimal performance: “Liveness”
  • Optimal security: Slashing protection + private key protection

SSV Peer to Peer (P2P) network layer

The SSV P2P layer is the execution layer, it reads the current operator list and validator KeyShare assignments from the Ethereum contracts and operates the validators on the network.

Ethereum contract layer for network governance

The Ethereum contract layer is crucial for network governance. SSV operators will be assessed and ranked by a DAO resulting in a decentralized and transparent network scoring of their quality, experience, and service. Actions like adding an operator, creating a validator, and distributing fees will occur on the contract layer.

DAO Governance

The decision-making component of the will be handled by a DAO of SSV Token holders. The DAO’s areas of responsibilities will include:

  • Operator Scoring – On a scale of 0-100. The score is crucial for users to decide which operators to use. In addition, DAO governance decisions can remove an operator from the network.
  • Fee – The fee amount is controlled by the DAO and can be changed by a governance decision.
  • Treasury – Grant distribution to different initiatives for and by the community. Other decisions for accumulated fees and investment inflows.
  • Other decisions – Key protocol decisions such as roadmap and protocol improvements.

Promoting Validator Liveness and Security

For any staking use case, there are two main concerns:

  • Optimal performance: “Liveness”
  • Optimal security: Slashing protection + private key protection

To optimize for both performance and security, and protect against validator failure, redundancy is critical. If one component fails, there must be another that can actively take its place and keep the validator up and running without breach or penalty.


In terms of validator performance, an SSV implementation takes advantage of the varying benefits that different systems bring to the table and joins them together as one. Remarkably, joining them in such a way that their negative characteristics do not carry weight. Each system actively protects the other and vice versa. SSV can tolerate some nodes being offline while still attesting correctly and reaping optimal rewards. In this way, nodes can fail or go offline for maintenance without risk, knowing that the rest of the network is effectively managing the stake.

SSV delivering even if one KeyShare is offline for maintenance.


When a distributed network of nodes can run a validator in a secure way, security breaches and slashings become much more difficult. From an accidental slashing standpoint, if one or some nodes (up to the threshold) in an SSV fail, the others can actively go on without pause.

Protecting private keys also becomes much easier. With SSV, the validator private key can be generated and stored securely offline while the KeyShares that represent it operate the validator. This is advantageous for two reasons; stakers need not give up private key custody to operators (avoiding single operator failure and mass slashing penalties) and theft from a bad actor is much less likely as the private key is not kept online. In order to make any effect, a bad actor would have to gain access to a majority of KeyShares in an SSV. This radically changes the narrative for ETH staking private key security.

Bad actor trying to steal an SSV KeyShare.

By trustlessly splitting a validator key across different systems, SSV presents an Ethereum staking infrastructure solution that reduces the reliance on any single point of failure that might affect validator performance and safety, while simultaneously increasing network security by focusing on decentralization across the entire Ethereum protocol.

Who Benefits from SSV

In short, all of Ethereum for the resilience it brings to the network. More precisely:

  • At-home Validators – Splitting one validator across multiple machines or cloud providers delivers redundancy and resilience. Also, enabling groups of individuals to securely validate together as a group.
  • Validators Leveraging Staking Services – Rather than entrusting one staking service with a 32 ETH validator; a user can divide their stake, optimize rewards, and decrease risks significantly.
  • Staking Pool Participants – Enabling decentralized staking pools at the operational level as well as the withdrawal level. Single operator failure affecting the rewards of the users they represent can be avoided by banding operators together in an SSV.
  • Staking Services/Infrastructure Providers – Enabling active-active redundancy configurations across all core system components. Mitigating risks as well as costs by eliminating single points of failure.

How SSV Benefits the Ethereum Protocol

Widespread adoption of SSV is not only great for individual stakers and staking providers, but also serves to strengthen the Ethereum protocol itself. Centralization of ETH staking is a real risk given the significant financial and technical burdens of running a validator. Both encourage the use of staking services, the majority of which are centralized.

The dangers of centralized staking for the health of Ethereum are two-fold; the users entrust their stake with a single operator and risk severe slashing penalties given the protocol’s key aggregation rules. Additionally, the more validators a staking service manages, the larger the effect will be across the entire network if they are to fail as a group. The prospect of simultaneous downtime across large factions of the network invites coordinated network attacks and can lead to the chain not being able to finalize.

Centralized staking services are not the only ones to blame for network centralization. Upwards of 70% of validators have traditionally leveraged the same validator client, Prysm. No client is perfect and if a large number of validators use the same one, the network can go down with it. This was made evident during the first major beacon chain event when an edge case issue in Prysm led to missed attestations and block proposals across the entire network. The chain was able to reach finality in this case, but a different issue could very well have led to different results.

Promoting Decentralization at Scale

With SSV, the gates have opened for endless possibilities of validator node configurations, working together simultaneously and complementarity. Across the board, staking services, at-home validators, infrastructure providers (and groups of all three working together) can reduce their individual risk and strengthen Ethereum by building customizable and unique SSV networks.

This is a real win-win scenario for all parties. Centralized services can now offer decentralized services! By joining forces with others in an SSV network they safeguard themselves and their users from centralized staking risks and safeguard the network by reducing the potential network-wide negative effects if they are to fail. If a prominent centralized service fails, the whole network will not come down with it; rather, the other operators in their SSV will back them up until they are back online.

Finally, touching on the diversity of other components (such as validator clients and cloud providers), SSV promotes the use of varying components without the challenge of implementing active-passive redundancy. By joining an SSV network, a staker or staking service can easily leverage multiple different components at once. Widespread adoption of SSV will significantly contribute to the diversified use of these components, mitigate centralization and protect against network-wide failures.

SSV Technical Overview

For more details on the inner workings of SSV, check out the SSV Primer.

SSV is a sophisticated multisignature wallet with a consensus layer. It is a middle layer that comes between a beacon node and a validator client. From a user’s perspective, it is just a component to plug in and take care of everything on their behalf. The main components of an SSV configuration are as follows:

Distributed Key Generation

A cryptographic process to generate a shared public and private key set calculated by the operators running an SSV instance. Each operator owns a single portion of the private key, ensuring that no single operator can affect or have control over the entire private key and make unilateral decisions.

Shamir Secret Sharing

Eth2 validator keys use BLS signatures, BLS signatures are additive, allowing for multiple signatures to be combined to recreate a validator key signature. This allows for the use of Shamir Secret Sharing, a mechanism used to reconstruct a validator key using a pre-defined threshold of KeyShares. Individual KeyShares cannot be used to sign a duty, yet not all are needed if some are faulty as described by n≥3f+1.

Multi-Party Computation

Applying secure Multi-Party Computation (MPC) to secret sharing allows for KeyShares of an SSV to be distributed amongst operators securely as well as perform decentralized computation of validator duties without reconstructing the validator key on a single device.

Istanbul Byzantine Fault Tolerance Consensus

Tying it all together, the consensus layer of SSV is based on the Istanbul Byzantine Fault Tolerance (IBFT) algorithm. The algorithm randomly selects a validator node (KeyShare) responsible for block proposal and sharing the information with the other participants. Once the predefined threshold of KeyShares deems the block to be valid, it is added to the chain. As such, consensus can be reached even if some operators (up to the threshold) are faulty or not currently online.

Advanced IBFT reading →


SSV, at its core, is a way to reduce failures and diversify risk by making individual SSV nodes become a robust network that can outperform any individual ETH staking setup. Across the board from security, robustness to uptime, SSV will improve ROI for stakers, increase network decentralization, and significantly reduce staking risks for all.