On March 9, Vitalik Buterin published a post on X introducing DVT-lite, the architecture the Ethereum Foundation (EF) is using to stake 72,000 ETH.
Recently, ETH staking has been shifting from individual participants toward institutions. In this context, the fact that EF publicly revealed the architecture it uses to operate its own validators is highly significant. It offers a glimpse into the direction Vitalik Buterin and the Ethereum Foundation envision for institutional staking infrastructure.
Vitalik’s post clearly outlines EF’s perspective on how distributed staking for institutions should evolve.
“My hope for this project is that in the process, we can make it maximally easy and one-click to do distributed staking for institutions.”
The architecture EF adopted in production to realize this vision is DVT-lite.
Before examining DVT-lite, it is important to first understand the core concept of DVT (Distributed Validator Technology) and the long-term direction Vitalik ultimately envisions.
A standard Ethereum validator is operated using a single node and a single key. If that node goes offline, the validator becomes inactive, leading to missed rewards and potentially increased risk exposure. DVT addresses this issue by distributing a single validator key across multiple nodes, removing this single point of failure.
Vitalik’s long-term vision is to integrate DVT directly into the Ethereum protocol. However, this would require a hard fork and significant protocol changes. At present, the idea remains at the proposal stage and no detailed specification has yet been finalized.
DVT-lite is a practical approach that enables distributed signing infrastructure using existing off-chain tooling without requiring protocol changes. The core infrastructure proposed for this architecture consists of Dirk (a distributed signing client) and Vouch (a validator client).
Dirk manages distributed signers deployed across multiple geographic regions, while Vouch coordinates multiple beacon nodes and execution layer clients.
Unlike traditional DVT solutions such as SSV or Obol, which rely on Shamir’s Secret Sharing to split validator keys, DVT-lite instead deploys independent signer instances across geographically distributed locations to ensure availability and resilience. From a protocol perspective, the validator structure itself remains unchanged, but the operational architecture removes the single point of failure.
With DVT-lite, setting up distributed Ethereum validator nodes can be reduced to three simple steps:
Use a single Docker container or Nix image
Run one command per node
Enter the same validator key
From that point forward, nodes automatically discover each other, the network is configured, DKG (Distributed Key Generation) is executed, and staking begins. The entire process is automated.
DVT-lite also leverages the Type-2 (0x02) validator introduced in the Pectra hard fork, allowing validators to operate with a maximum effective balance (maxEB) of 2,048 ETH. Under the previous 32 ETH model, approximately 2,187 validators would have been required. With maxEB, this number is reduced to roughly 35 validators — a 98% reduction.
This dramatically lowers the operational complexity, which had previously been one of the key challenges of distributed signing infrastructure.
Currently, the Ethereum ecosystem’s primary DVT solutions are SSV and Obol. Both projects provide middleware that distributes validator keys across multiple operators, and both are already running in production on Ethereum mainnet.
However, existing DVT architectures present several structural limitations.
1. Complexity of External Coordination Infrastructure
SSV and Obol operate as middleware outside the Ethereum protocol. They split validator keys and require distributed nodes to communicate in order to produce a valid aggregated signature. This requires additional infrastructure beyond the Ethereum protocol itself, including P2P networks, coordination layers, and message relay systems.
2. Operational and Configuration Complexity
Deploying DVT requires coordination between multiple operators, including key-sharing ceremonies (DKG), cluster configuration, and network setup. This introduces significant operational complexity, which aligns with Vitalik’s criticism that validator infrastructure should not remain “an expert-only domain.”
3. Dependence on BLS Signature Schemes
Existing DVT implementations rely heavily on the linearity of the BLS12-381 signature scheme, which allows partial signatures from different key shares to be aggregated into a valid signature.
However, if BLS were ever broken by quantum computing, Ethereum may need to migrate to post-quantum signature schemes, which would require a complete redesign of current DVT architectures.
4. Lack of Protocol-Level Awareness
Because DVT middleware operates outside the Ethereum protocol, the protocol itself is unaware that distributed validation is taking place. From the protocol’s perspective, it still appears as a single validator. As a result, the benefits of distributed validation are not reflected in protocol-level incentives or slashing mechanisms.
To address these issues, Vitalik proposed Native DVT, which would integrate distributed validator functionality directly into the Ethereum protocol. If such an architecture were eventually adopted, projects providing middleware-based DVT solutions such as SSV and Obol could face fundamental challenges to their long-term relevance.
DVT-lite, however, serves a different purpose. Rather than changing the protocol, it focuses on improving validator operational architecture. In doing so, it helps address the issue that DVT is sometimes used today as a form of over-engineering.
The “distribution” offered by SSV and Obol combines key distribution and operator distribution. In other words, multiple independent operators jointly manage a single validator key. The ideal use case for DVT is therefore a structure similar to Lido’s Simple DVT, where multiple operators collaborate to run a single validator.
In practice, however, many validators use DVT simply as a tool for high availability within a single operator setup. This demand has increased further following the Pectra hard fork, where the maxEB increase to 2,048 ETH concentrates significantly more capital within a single validator, raising the importance of validator uptime and reliability.
In such cases, DVT-lite provides a much simpler and more practical alternative. For many institutional staking setups adopting maxEB validators, a solution that prioritizes operational simplicity and reliability may be preferable to the more complex distributed-operator architecture of traditional DVT systems.
The Ethereum Foundation’s 72,000 ETH validator deployment represents only about 0.2% of total staked ETH. However, when the Ethereum Foundation deploys its own capital and Vitalik publicly promotes the architecture, the influence extends far beyond the raw numbers.
EF’s staking architecture, including DVT-lite, effectively signals a potential new standard for institutional staking infrastructure.
“Validators should not rely on a single key and a single machine. Distributed validators should be the norm — and setting them up should be simple enough to do in one click.”
Ethereum
