DVT

Distributed Validator Technology (DVT) is a security mechanism that distributes validator key management and signing operations across multiple participants. This eliminates single points of failure and increases validator resilience.

Validators have a single public-private key pair (the validator key) for consensus participation (block proposals, attestations) and a withdrawal address that determines where staked funds are sent upon exit. Validator keys must stay online continuously, making them vulnerable to compromise.

DVT addresses this vulnerability by encrypting and splitting the validator key into shares distributed across multiple nodes. Stakers can keep the original key in cold storage while the network operates using these shares. A threshold number of shares (e.g., 3 out of 4) can collectively produce valid signatures, meaning one node can fail without disrupting validator operations. The system relies on distributed key generation, threshold signature schemes, and multiparty computation to ensure no single node ever possesses the complete key.

StakeWise Vaults support both Obol ↗ and SSV ↗ DVT technologies, offering an additional layer of security and decentralization. This gives operators flexibility in how they secure their validators.

🔐 Master Key Split

a3f7...

8d2c...

5b91...

f4e6...

Node A

↓

key share 🔑

Node B

←

key share 🔑

Node C

key share 🔑

↑

Node D

→

key share 🔑

Each node holds one encrypted key share.

DVT setup components

DVT cluster of distributed validators

Performs validator duties such as attestation, block proposal, and consensus participation.

StakeWise Operator

Registers validators in vault contract. Operator does not have access to validator keystores.

DVT Relayer

Used to collect exit signatures of the validators for passing them to oracles.

DVT sidecars

Sidecars provide exit signature shares to DVT Relayer. Each distributed validator node should run DVT sidecar instance. Each sidecar should have access to validator key shares on related DVT node.

Validator registration procedure

Operator reads validators from the deposit data file.

On validator registration Operator sends request to the relayer:

1. Operator sends a list of public keys from the deposit data to the relayer, then polls the relayers for the exit signature(s)

2. Relayer creates VoluntaryExit(s) out of public keys and stores to DB. VoluntaryExits can be received through relayer API.

3. DVT sidecars poll VoluntaryExits they can sign from the relayer, create exit signatures for them and post to the relayer.

4. Relayer processes exit signatures:

   • Receives exit signature shares from the sidecars.
   • Restores exit signatures from sidecar shares and verifies the restored signatures.
   • Creates shares for oracles, encrypts them with oracle public keys, and stores them to the DB. The encrypted shares for oracles are available through the relayer API.

5. Operator fetches encrypted signatures from relayer and registers the validator.