Stakely has migrated 1,000 validators to Obol on Hoodi.
In support of Proposal: Curated Module Intra-Operator DVT Guidelines, Pier Two intends to support the initiative with 1,000 validator keys. Since Pier Two are still scaling up keys, this will apply strictly to new keys, not existing active validator keys. And following successful testing via the Lido Hoodi instance.
Pier Two has supported the Simple DVT Module since launch, across both Obol and SSV. And continues to support both DVT solutions within Lido and externally.
For the next 1,000 validator keys, Pier Two will use an intra-operator DVT setup (i.e. Pier Two is the sole operator in the cluster), utilizing Obol.
Notably, in the performance data shared in the original Proposal, the 30-day APR was the same for both SSV and Obol. Working closely with the Obol team during challenges outlined in the proposal, we are comfortable that significant efforts have been made to address and resolve performance.
Obol incentives would be split according to the Decentralized Validator Vault (DVV), where 20% are retained by Pier Two, and 80% directed to the Mellow DVV.
Stakin has migrated 1,000 keys to SSV
Read about Blockdaemonās support for Distributed Validators through Lidoās Curated Module in our latest blog, where we outline the role of Obol DVs in enhancing resilience and security for Ethereum staking.
https://www.blockdaemon.com/blog/support-for-obols-dv-integration
Appreciate you laying this out so clearly. Itās great to see Pier Two committing tangible support to the curated intra-operator DVT guidelines and backing it with 1,000 keys
Hyunggi from DSRV here We support this proposal and are migrating 1,000 validators to Obol.
We believe this transition will strengthen network resilience, enhance the diversity of the Curated operator set, and offer valuable insights into DVT performance across different validator types.
P2P.org also has migrated 1000 keys to SSV today
Stakely has migrated 1,000 mainnet validators to Obol.
Simply Staking has migrated 750 mainnet validators to SSV.
This is a valuable discussion to have, especially as DVT moves from an experimental setup toward something closer to an operational norm within the Curated Module.
Conceptually, I think intra-operator DVT makes a lot of sense as a way to reduce single-machine and single-key risk without forcing immediate cross-operator coordination. It can meaningfully improve fault tolerance while remaining operationally feasible for existing operators.
Where I think extra care is needed is around enforceability and verification. If DVT usage is recommended or expected within the curated set, how does the DAO or module governance reason about compliance in practice? For example, is the intent to treat DVT as a best-practice guideline, or as something that eventually feeds into risk scoring, capacity decisions, or curation criteria?
Another subtle risk is that āintra-operatorā DVT could unintentionally reinforce operator-level centralization if not paired with clear expectations around infrastructure diversity. Running multiple DVT nodes across the same provider, region, or admin domain may satisfy the letter of the guideline while missing much of its spirit. Explicitly calling out diversity assumptions (hosting, geography, failure domains) could help avoid that outcome.
Overall, Iām supportive of moving in this direction, but I think the long-term success of DVT within the Curated Module will depend less on the cryptography itself and more on how clearly expectations, verification, and incentives are communicated to operators.
Stakefish has migrated 1,000 mainnet validators to SSV.
RockLogic migrated 1000 keys to Obol
Blockdaemon migrated 1000 keys to Obol