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. The validator key must stay online continuously, so running it on a single node is a single point of failure: if that node goes offline, the validator stops performing its duties.

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. See Relayer (API Mode) for that API and how the Operator Service consumes it.

Validator Registration Process​

During registration, the DVT Relayer coordinates the operators' Sidecars and collects their signature shares. The steps below are numbered to match the diagram.

  1. The Vault holds at least the minimum activation balance (32 ETH) in withdrawable assets. The Operator Service determines the starting validator index and the deposit amount for each validator — for 0x02 validators an amount can be larger than 32 ETH, up to the maximum validator balance.

  2. The Operator Service sends a registration request with those values to the Relayer.

  3. The Relayer creates the corresponding pending validators and exposes them via its API, where the Sidecars poll for validators awaiting signatures.

  4. Each Sidecar creates deposit and exit signature shares for those validators with its node's key share, and pushes the shares back to the Relayer.

  5. The Relayer processes the signature shares and returns the completed registration data:

    • 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.
    • Fills in the signatures on the pending validators and returns the Validators Manager signature that authorizes the registration, alongside the encrypted Oracle shares. The Operator Service repeats its registration request each block until this data is ready.

  6. The Operator Service requests approval from the StakeWise Oracles, forwarding the validators and their encrypted Oracle shares. The Oracles validate the data and return a combined approval once enough of them vote.

  7. The Operator Service submits the registration to the Vault contract, providing both authorizations: the Oracles' approval and the Validators Manager signature.

  8. The Vault deposits the stake, and the validators join the Beacon Chain's activation queue. Each becomes active once its deposit is processed, which can take a while depending on how many deposits are ahead of it in the queue.

Last updated on