The Official SSV Node Spec

SSV's spec serves as the blueprint for the SSV node, documenting design decisions and enabling testing, and interoperability. ‘The Official SSV Node Spec’

The Secret Shared Validator (SSV) protocol was designed by the Ethereum Foundation (in collaboration with others) to build redundancy into the Eth2 Client architecture by removing any possible single points of failure. This necessitates that the fundamental SSV protocol design is free from any security vulnerability, ensuring that it functions as designed and does not open up attack vectors to Eth2 Clients operated by honest staking accounts.

To this end, the team has spent the last 8 months in an intense R&D effort to finalize the SSV node technical specification(spec). Achieving this major milestone is an essential step in preparing for mainnet. And by ending the “theoretical” phase, SSV has completed a critical piece of the puzzle, enabling the team to align the implementation to the spec, giving us a clear vision of the last milestones before mainnet.

What is a Spec?

For those wondering, a spec is technical documentation used to describe a system, analyze its behavior, and support its design by verifying fundamental properties. In SSV’s case, it’s the blueprint that specifies the core logic of the SSV node. This blueprint helps standardize what an SSV node is and how it deterministically functions, serving as the one source of truth that documents all design decisions.

Developing a complex protocol like without a spec is similar to navigating through rough terrain without any sort of map, or navigation. A spec allows us to define clear goals, test those goals, and later on graduate to an implementation phase which will safely lead us to those goals.

Why does SSV need a Spec?

Without a spec, its hard to test assumptions and externalize your decisions for other contributors to review and improve upon. Developing a groundbreaking protocol like SSV can be prone to mistakes since you’re in a break first think later development mode.

When SSV started, there was no specification for how an SSV node should function, so while working on the spec, the team simultaneously worked on the implementation of the protocol. The implementation is essentially a wrapper for the spec, allowing us to build on top of the core logic. At this stage, the team is working hard on aligning the SSV node implementation to the spec.

Having a spec enables us to do a few essential things:

  • Helps SSV align the implementation to the spec — Defines clear milestones for the final updates to the SSV implementation before mainnet.
  • Test implementation (spec tests) — A spec isolates the core logic of the node, allowing developers to test and review against it. Because SSV works as a network of trustless nodes, the team will need to do considerable testing to create a robust and reliable system.
  • Enables future development & Interoperability — Having a spec is the best practice when working on open source services, aligning everyone and allowing future teams to build their version based on the spec. Builders that want to develop their own ssv-based node implementation can do so easily by following the spec, helping to improve node diversity in the future.


The intent behind adding SIPs(SSV Improvement Proposals) to the is to create a mechanism for proposing new features, collecting community technical input on issues, and for documenting the design decisions that have gone into the protocol. For SSV implementers, SIPs are a convenient way to track the progress of implementations.

If anything about the spec needs to change or shifts from the original design, a SIP(SSV Improvement Proposal) is required. The community can submit SIPs with their reasoning behind the proposal and how the SIP can be implemented. This is similar to Ethereum’s EIPs, where developers constantly work on further developing the protocol through an incremental and democratic process.

Step-by-step implementation of a SIP:

  1. Proposing an idea via a SIP
  2. Check SIP against the spec
  3. Run spec test to test SIP
  4. Implement SIP if it passes

The SSV Spec

We are currently in the process of alignment. This means we are aligning node 0.2.6 with the spec. We’ll discuss each of these milestones once they’re closer to completion.


  • Node aligned to V0.2.6
  • Devnet
  • Contracts V3
  • Testnet V3
  • Mainnet

With the spec finally completed, the way forward is crystal clear. We’ll be releasing a post about the mainnet roadmap soon, concerning the SSV ecosystem, protocol, and the road ahead. Join our Shifu testnet to see the latest in DVT tech in action.

Website | Network Hub | Discord | Dev Center | DocumentationGitHub



Dev Center

Start building apps on a secure and scalable distributed validator infrastructure.


Use Cases​

Use the decentralized Ethereum staking infrastructure as a building block for different applications.



Access multiple funding options that support DVT – based applications.


Ecosystem Hub

Explore applications built with SSV at its core infrastructure.




From forum to treasury – have a look at all the governance tooling and information.


Run a Node

All the resources you need to start running an SSV Node in the network.



Restaking protocols are able to permissionlessly utilize SSV for highly resilient and robust restaking operations.




Learn more about the tech, vision, misssion, and how we got here.



Stay up to date with announcements, deep-dives, and important community initiatives.



Want to play a part in the future of staking? Join the team.