Anchor: Decentralizing Ethereum’s Decentralization Layer

The SSV DAO is excited to announce that the Anchor client, developed by Sigma Prime, is now officially live on mainnet. Anchor is the second implementation of the SSV node client and marks the first step in  SSV Network becoming a multi-client protocol like Ethereum itself. 

Developed in Rust, Anchor introduces client diversity to the SSV protocol, along with a robust architecture and open development to SSV Network’s DVT (Distributed Validator Technology) layer. In this post, we’ll walk through what Anchor is, why it matters to the SSV ecosystem, and how you can get started.

How Does Another Client Support SSV Network? 

Minimizing single-client risk in DVT

The SSV Network protocol enables splitting a validator’s duties across multiple node operators, so downtime of a single operator doesn’t disable the validator, a significant improvement over legacy validator setups. Currently ~14% of all Ethereum validators are secured by SSV DVT, an additional client helps strengthen this crucial infrastructural component of Ethereum staking.

However, until now, the SSV node itself has had one dominant implementation (Go). If that implementation has a bug or widespread failure, it becomes a risk for the DVT clusters. Anchor addresses exactly that: client diversity. Running mixed clusters of Anchor + Go SSV helps reduce correlated failures and increases the fault tolerance of Ethereum validators. 

Security & performance
Rust’s memory-safety features and modern concurrency model mean fewer runtime errors, better predictability, and potentially higher stability in hybrid clusters. Anchor is built from the ground up with those advantages in mind.

Observability
With built-in metrics (Prometheus/Grafana compatible), HTTP APIs, and monitoring hooks, operators have visibility into node health, duties, consensus performance, and peer behavior. This helps you run at scale with confidence. 

Seamless migration path
Anchor uses the same operator key formats as Go-SSV, making it easy to switch (or run hybrid setups) with minimal retooling. 

Future-proofing your stack
As SSV technology and DVT evolve, running a modern implementation built with modular architecture means your infrastructure is better positioned to adopt upgrades, new features, or network changes.

From an operational perspective, the Duties Service triggers when validator tasks (attestations, proposals, sync committee) are due. Those tasks are handed to the Processor, which instantiates a QBFT consensus instance. Meanwhile, the Network task handles messages from peers, routing them to the correct QBFT instance or other modules. Once consensus is reached, actions (signing, broadcasting) flow back through the Processor and Network layers. 

How to Get Started with Anchor

Pre-Migration preparations

1. Install Anchor

   • Follow the Installation section in the Anchor Book to install the correct version (ideally v1.0.0). (anchor-book.sigmaprime.io)

   • Verify installation:

     1. anchor --version

   
   

2. Stop your Go-SSV node

   • To avoid running two operator instances with the same operator ID, stop your go-ssv node before migrating.

   • Do not leave both clients running for the same operator key simultaneously.
     
     

3. Backup your existing operator key

   • Locate your go-ssv operator encrypted key file:
     ~/ssv-stack/ssv-node-data/encrypted_private_key.json by default.

   • Create a secure backup of this file before proceeding.

Migration Steps

4. Move the operator key to Anchor’s data directory

   • Anchor expects the operator's encrypted key at:
     ~/.anchor/<network>/encrypted_private_key.json, where <network> is e.g. mainnet, hoodi.

   • Example move command for mainnet:

     2. mv

   • The mv (move) is strongly recommended over copying, to ensure you don’t accidentally run duplicate operator instances.
     
     

5. Prepare the password file

   • If your encrypted key is protected by a password, create a plaintext file containing the password.

   • On running Anchor, reference it via the CLI argument --password-file <PATH> to decrypt your key file.
     
     

6. Launch Anchor as operator node

   • With the key moved and the password file ready, use the Anchor CLI to start your node.

   • Use the commands documented in the “Node CLI Reference” section of the Anchor Book to specify network, data directory, beacon/execution endpoints, etc.

   • Example:

     3. anchor operator \
     4. --network mainnet \
     5.  --data-dir ~/.anchor/mainnet \
     6.  --password-file ~/.anchor/mainnet/pw.txt \
     7.  --executor-rpc <your-execution-RPC> \
     8.  --beacon-node-ws
     
     

Post-Migration checks

7. Verify operator status and duties

   • Confirm that your Anchor node picks up validator duties correctly.

   • Monitor the logs, metrics endpoint (Prometheus) and verify no errors like “invalid key” or “operator ID conflict”.

8. Check for known migration issues

   • If you receive an error:

     9

   • Then open your encrypted_private_key.json file and change the field "pubkey" to "pubKey". This is a documented known issue in the current release.

   • After editing, restart Anchor.

Real-world Scenario 

Imagine you are a professional node operator or operate a staking service that manages validators at scale. Up until now, you used only one client for your nodes.

The challenge

A bug in a client caused some nodes in one of your clusters to drop duties for several slots, resulting in downtime, some yield loss, and concerns about “what if” scenarios.

Enter Anchor

You decide to adopt Anchor v1.0.0 for a subset of your operator nodes. You launch multiple operator nodes, some using Anchor and others on Go-SSV, creating a hybrid cluster. Because Anchor uses the same key format and network logic, your migration was straightforward.

The payoff

• When a Go-SSV or Anchor node encounters a connectivity issue or error, the other nodes remain unaffected—in the hybrid cluster, your validator duties still get signed and completed without disruption.

• Your monitoring dashboards flags the anomaly, and you coordinate the failover smoothly.

• You now market your service to clients emphasizing: “We run client-diverse SSV clusters (Go + Rust) for maximum uptime and yield reliability”.

What this means for operations

Clients see fewer missed duties, higher confidence in uptime beyond a single client setup, and you gain a competitive differentiation. As a service provider, you have strengthened your operational stack, reduced risk, and positioned your business for future upgrades as SSV evolves further.

Anchor your place in ETH staking

If you’re an SSV operator, staking pool, or validator infrastructure provider, adopting Anchor is a strategic move. It addresses fundamental questions: Is my client stack resilient? Am I exposed to a single‐implementation risk? 

Ready to try it out? Start using Anchor today!

Docs: https://anchor-book.sigmaprime.io  

Repo: https://github.com/sigp/anchor  

Release: https://githubx.com/sigp/anchor/releases/tag/v1.0.0