This category is used by Node Operators to submit their public identification requests as part of the stVaults onboarding process.Posts in this category serve as the formal trigger for a Node Operator to be considered for transition from Unidentified to Identified status.Each post should include:
A short introduction (who you are, what you request: identification, category assignment, or change request).
A concise business case (ETH sourcing potential, user segments, channels, timelines, fee policy).
A brief operations & decentralization overview (client mix, infra footprint, jurisdictional spread, MEV posture).
After posting here, Node Operators proceed with private questionnaires for technical and business details, followed by evaluation and category assignment by the stVaults Committee.
The stVaults Committee reviews all submissions and publishes its decision and rationale either as a separate post in this category or as a reply to the original request thread.
stVaults Node Operators identification process has started
The Committee has started to process Node Operators public identification requests.
This process aligns with the Risk Assessment Framework for stVaults - Lido V3, providing an option for interested parties to disclose information required for more precise risk evaluation and a lower requirement for collateral for stETH minting (Reserve Ratio).
Current structure of Node Operators categories:
Unidentified Node Operators (permissionless)
Basic Identified Node Operators
stVault Professional Operator
stVault Professional Trusted Operator
DVT cluster
In terms of risk scenarios, defining reserve ratio structure, on top of already provided within Default risk assessment framework and fees parameters for Lido V3 (stVaults) for Unidentified Node Operators (permissionless) and Basic Identified Node Operators (default scenario of 100% of all validators across stVaults slashed for Node Operator) & DVT cluster there are two additional Node Operator categories, with modified risk scenarios :
75% of all validators across stVaults slashed for Node Operator from stVault Professional Operator category
50% of all validators across stVaults slashed for Node Operator from stVault Professional Trusted Operator category
With the assumption of Network slashing on top of slashings within stVaults remaining at 1% for all groups.
Specific Reserve Ratio structure and documentation on the process could be found in the End-to-end process to become an Identified Node Operator guide (which is expected to be updated shortly with a separate section for DVT cluster identification).
The Lido QA team is requesting a limited stETH capacity for testing purposes related to stVaults.
As a stVaults Committee member, I’d like to inform the community that the Committee will provide two tiers in the Operator Grid contract for the following multisig address: 0x762Ca64AD43991bF6D3CF844af05f48BDE7AE566:
Hi, quick question, we are a small operator currently running validator infrastructure mainly DVT clusters (SDVT, EtherFi, CSM) and we are exploring the stVaults onboarding process. Our role is purely as a node operator/infrastructure provider, we don’t plan to attract or bring ETH ourselves, but rather to run validators for stVault creators.
Would AXBLOX still be a good fit to apply as a Basic Identified Node Operator or DVT cluster under this model? And for a smaller operator like us, is the idea that stVault creators could select us later as part of their operator set, realistic?
Just want to make sure we are approaching this the right way before submitting our identification request.
As an Individual Node Operator, you can apply for, e.g., the Basic category.
To create a DVT cluster, you need to coordinate with at least 3 other individual node operators, as a DVT cluster requires a minimum of 4 node operators; each is required to pass the identification process. All details are in the onboarding guide.
Lido doesn’t have specific plans to create a marketplace where stakers can select node operators to stake with. I’m not saying it’s not possible, but it’s not on the roadmap yet.
stVaults platform allows node operators and builders to create different types of products based on stVaults, including end-user public vaults where retail users can stake ETH with specific node operators (learn more about DeFi Wrapper). You can, for example, create a staking product and integrate a widget with end-user UI in any traffic channel that you may have.
You can fill this form out and leave your contacts, so the stVaults team can contact you and provide any additional help: Contact the stVaults team
Node Operator Admission: HostDeFi as stVault Basic Operator
1. Identification
HostDeFi is an independent, non-custodial validator and node-infrastructure collective. We request identification as a Basic Identified Node Operator under the individual node-operator path. Our role is purely as a node operator / infrastructure provider — we run validators for stVault creators rather than sourcing ETH ourselves.
We operate dedicated bare-metal hardware (US, Ryzen 7950X / 128 GB / NVMe) plus distributed cloud instances, running a multi-network node fleet: an Obol DVT cluster on Ethereum Hoodi testnet (3/3 nodes live and attesting across three independent hosts), an EigenDA operator registration, an Espresso node registered on-chain, a Babylon testnet validator bonded on-chain, a Cosmos ICS testnet validator, Solana mainnet + testnet validator infrastructure (SFDP application in Foundation review), and a DePIN fleet (Theta edge, Storj, AIOZ, Pactus, Xandeum, Asentum). We also operate an 82-chain public RPC relay.
2. Business case
ETH sourcing potential: none claimed — we do not plan to attract ETH ourselves. Our intended role is an infrastructure operator available to stVault creators who want an independent, dedicated-hardware operator in their operator set.
User segments / channels: independent node operators and sub-operators; we coordinate via our public site and direct ops contact.
Timelines: operational now — existing clusters can accept stVault duties as soon as the Committee admits us.
Fee policy: we will follow the stVaults operator fee framework and stay competitive within Committee norms.
3. Operations & decentralization
Client mix: Lighthouse validator clients inside our Obol DVT cluster (charon middleware); Solana agave/jito client; Cosmos SDK (gaiad), Babylon, and other chains under their standard clients.
Infra footprint: dedicated bare-metal (US) + distributed cloud instances; the Obol cluster spans three physical hosts for fault tolerance.
Jurisdictional spread: currently US-centric; expanding.
MEV posture: no custom MEV strategies — standard client defaults and Committee guidance.
4. Supporting links
New accounts on this forum cannot embed links, so contact details are written out: our site is hostdefi dot com, our public RPC relay is rpc dot hostdefi dot com, ops contact is ops at hostdefi dot com, Telegram handle is at hostdefi underscore ops.
The mandatory Basic stVaults Identification form was submitted via the private intake last Friday; we are proceeding with the KYB step in parallel and can share formation documentation when it lands.
Kestrel Staking requests identification as a Basic Identified Node Operator under the individual node-operator path — posting our identification request here while our new forum account is still under new-user topic restrictions.
1. Identification
Kestrel Staking is an independent, non-custodial node operator. Our role is purely infrastructure — we operate validators on behalf of stVault creators rather than sourcing ETH ourselves. We run dedicated bare-metal hardware (US) and operate Ethereum validator infrastructure with SSV Network DVT integration; our mainnet operator registration is in progress.
2. Business case
ETH sourcing potential: none claimed — pure infrastructure operator available to stVault creators who want an independent, dedicated-hardware operator in their operator set. User segments / channels: independent node operators and sub-operators; coordination via direct ops contact. Timelines: operational now — existing infrastructure can accept stVault duties as soon as the Committee admits us. Fee policy: we will follow the stVaults operator fee framework and stay competitive within Committee norms.
3. Operations & decentralization
Client mix: Lighthouse and Nimbus consensus clients; Geth and Nethermind execution clients; SSV / charon DVT middleware. Infra footprint: dedicated bare-metal host (US) with distributed failover instances. Jurisdictional spread: currently US-centric. MEV posture: standard client defaults and Committee guidance — no custom MEV strategies.
4. Supporting details
Our Node Operator address is 0x2DCCE2d41818e0b5e6EfE1906E7a3532F9Ad5722 (same address on mainnet and Hoodi; multisig setup in progress). Ops contact: kestrelprhbejz at maxxspace dot com. The Basic stVaults Identification form is being completed alongside this request.