Skip to main content

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.

StakeWise Vaults support both Obol ↗ and SSV ↗ DVT technologies, offering an additional layer of security and decentralization.

How DVT Works​

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 distributing the validator key across multiple nodes as a group of BLS private keys that together operate as a threshold key for participating in proof-of-stake consensus. Each node signs with its own key share, producing a signature share. A threshold number of shares (e.g., 3 out of 4) can collectively produce valid signatures, so the validator keeps signing even if some nodes go offline.

DVT Setup Components​

A DVT setup is made up of several components that work together:

  • DVT cluster: A group of connected nodes that together operate distributed validators (DVs).
  • Operator Service ↗: Registers DVs in the Vault. It has no access to the DVs' keystores.
  • DVT Sidecar ↗: Runs on each node with access to its key share. It retrieves validator data from the Relayer and submits the node's deposit and exit signature shares back to it.
  • DVT Relayer ↗: Collects deposit and exit signature shares from the Sidecars, reconstructs the full signatures, and serves the registration data to the Operator Service through its API.

Validator Registration Process​

During registration, the DVT Relayer coordinates the operators' Sidecars and collects their signature shares.

  1. The Operator Service determines the starting validator index and deposit amounts and sends a registration request to the Relayer.

  2. The Relayer creates the corresponding pending validators and exposes them via its API to the Sidecars.

  3. The Sidecars poll the Relayer for pending validators that are awaiting signatures, create deposit and exit signature shares for those validators, and push the shares back to the Relayer.

  4. The Relayer processes deposit and exit signature shares:

    • Receives the signature shares from the Sidecars.
    • Restores the full deposit and exit signatures from the Sidecar shares and verifies the restored signatures.
    • For the exit signature, splits that full signature into a new set of shares — one per Oracle — and encrypts each with that Oracle's public key; the raw exit signature is never exposed. The deposit signature is kept whole. It then fills in the signatures on the pending validators, and the encrypted Oracle shares are available through the Relayer API.

  5. The Operator Service repeats the registration request each block, polling until all pending validators have their signatures ready.

  6. Once the signatures are ready, the Operator Service registers those validators in the Vault contract.

Last updated on