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.

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.

DVT setup components​

  • DVT cluster of distributed validators — Performs validator duties such as attestation, block proposal, and consensus participation.
  • StakeWise Operator → — Registers validators in the Vault contract. The Operator does not have access to validator keystores.
  • DVT Relayer → — Collects deposit and exit signatures from validators (via Sidecars) and forwards them to oracles.
  • DVT Sidecars — Provide deposit and exit signature shares to the DVT Relayer. Each distributed validator node should run a DVT Sidecar instance with access to the validator key shares on the related DVT node.

Validator registration procedure​

  1. Operator determines the start validator index and calculates the list of amounts to deposit.

  2. Operator sends the start validator index and the list of amounts to the Relayer, then polls the Relayer for the creation and status of the corresponding pending validators.

  3. Relayer creates these pending validators and exposes them via the API to Sidecars.

  4. DVT Sidecars poll the Relayer for pending validators that are awaiting signatures, create deposit and exit signatures for those validators, and push the signatures back to the Relayer.

  5. Relayer processes deposit signatures and exit signatures:

    • Receives signature shares from the Sidecars.
    • Restores full signatures from Sidecar shares and verifies the restored signatures.
    • Creates shares for oracles and encrypts them with oracles' public keys. It then fills signatures in pending validators. The encrypted shares for oracles are available through the Relayer API.

  6. Operator fetches validators from the Relayer that have all required signatures and are ready for registration, and then registers those validators in the Vault contract.

Last updated on