This page is designed to help both new and existing Node Operators (NOs) navigate the expectations, documentation, and resources available when operating within the Lido protocol.
Understanding Expectations
At its core, running validators through Lido means adhering to the protocol’s technical design — as defined by the protocol itself — and to any additional guidelines set by the Lido DAO. This ensures fairness, decentralization, and Ethereum network health.
For a high-level summary of ongoing expectations, check out Ethereum Ongoing Operations Expectations page.
Technical Resources
When it comes to the technical component, Lido Docs should be your best guide.
Start with the Node Operators Guide for an overview, but please note that there’s additional relevant information throughout the docs that may apply to NO’s operations.
Operator Tools & Monitoring Suite
Explore a collection of monitoring tools, dashboards, automations, APIs, and validator management utilities built to support Lido Node Operators. The database includes open-source solutions and community-built services for everything from validator performance monitoring and MEV tracking to slashing alerts, withdrawal automation, and CSM validator management.
Descriptions and usage notes are included for each tool to help you find what fits best for your setup.
Oracles Allowed List
Due to the lack of native communication between Ethereum’s Beacon Chain and Execution Layer, the Lido protocol employs a network of oracles to regularly synchronize state between these two layers. Read the Oracle Operator Manual for a deeper dive into Lido Oracle mechanism and operational details.
NOs can view the current list of oracle members by calling the getMembers() function on-chain. This can be accessed directly via the HashConsensus contract using Etherscan.
To do this, visit the contract on Etherscan of the respective network (mainnet or testnet), scroll to option 16 (getMembers) under the "Read Contract" section, and click “Query.” This will return all current members, along with the last reference slot each member submitted a report for.
Network | Contract Call |
Mainnet | |
Hoodi |
Only addresses returned by getMembers() are allowed to participate in HashConsensus and emit ValidatorExitRequest events from the ValidatorsExitBusOracle. While configuring exit‑automation tooling (for example, the Ejector daemon), it is important to configure your ORACLE_ADDRESSES_ALLOWLIST with this exact member set; otherwise, the Ejector will not process exit requests correctly and your validators will remain active.
MEV Boost Relay Allowed List
Unless explicitly exempt due to incompatible APM interactions, NOs running validators via Lido protocol must configure their consensus client or preferred out-of-protocol PBS sidecar to include:
- At least one relay from the
Mainnet (must use some)category, and - Any number from the
Mainnet (may use)category.
These relays are listed in the MEV Boost Relay Allowed List, which can be accessed via the Lido Node Operator Portal here or queried directly using the get_relays method of the MevBoostRelayAllowedList smart contract for the respective Ethereum network.
Please note: mainnet and testnets relay lists differ — make sure to use the correct one.
Network | CLI Command |
Mainnet | ./mev-boost -mainnet -relay-check -relay <comma-separated relay urls> |
Hoodi | ./mev-boost -hoodi -relay-check -relay <comma-separated relay urls> |
Full MEV-boost CLI docs can be found here.
If proposed blocks are flagged as "Unknown PS" (payload source) on the Lido Fees Monitoring Dashboard and/or if payloads are sourced only from Mainnet (may use) relays with an abnormally high incidence, this could indicate a misconfiguration of your relay setup in relation to the Allowed List.
DAO Guidelines
Lido operates as a decentralized protocol governed by its tokenholders. To help ensure a high standard of operational integrity, transparency, and alignment with Ethereum’s core values, the Lido DAO may adopt guidelines that set expectations for NOs.
DAO-approved guidelines typically arise through open discussion on the Lido Research Forum and are finalized via votes (off- or on-chain). They aim to address operational nuances that are not hardcoded in the software, offering clarity around best practices, responsibilities, and edge case behavior.
Standard Node Operator Protocols
Certain aspects of NOs behavior are governed by community-vetted guidelines called Standard Node Operator Protocols (SNOPs). These are approved by the Lido DAO and help set expectations for NOs participating in the protocol.
SNOPs are created collaboratively by contributors and NOs, discussed publicly, and ratified by the DAO vote. They are intended to promote fairness, accountability, and alignment across all operator types — whether permissioned or permissionless, community stakers or professional NOs.
While they are not legally binding documents, adherence to SNOPs is critical to maintaining a healthy protocol and community trust. All NOs are strongly encouraged to stay familiar with active SNOPs, as updates may occur as Lido and Ethereum evolve.
SNOPs typically include:
- The scope of operator actions they apply to;
- The standards operators are expected to meet; observability mechanisms (e.g., dashboards or metrics);
- Consequences to non-conformance (e.g., communication, remediation, off-boarding procedures).
Validator Exits SNOP
This SNOP provides an overview of validator exit mechanisms available in Ethereum, explaining how validator exits function within Lido and detailing its algorithmic exit order. It also covers the governance and protocol levers for ad-hoc exit prioritization or triggered exits, outlines the responsibilities of NOs in processing validator exit requests, and explains the expected consequences in cases of non-conformance. Finally, it describes how this SNOP should be used to align with community expectations.
Name | Version | Discussion | Vote | Primary | Github | HackMD |
Validator Exits Protocol V2.0 | ||||||
Block Proposer Rewards SNOP
This SNOP outlines standards, Auxiliary Proposer Mechanisms (APMs) and infrastructure available for block proposals in Ethereum. It covers the considerations that guide expectations for block proposals and APMs, details the responsibilities of NOs in proposing blocks and distributing the associated rewards to stakers, and explains the expected consequences in cases of non-conformance. It also provides guidance on how to use this SNOP.
Name | Version | Discussion | Vote | Primary | Github | HackMD |
Block Proposer Rewards V2.0 | ||||||
The above tables include links to Research Forum discussions, Snapshot votes, IPFS, Github and HackMD versions, and any other supporting resources regarding these SNOPs. Please check them as it’s essential to stay updated as these SNOPs guide NO operations.
The tables above includes links to Research Forum discussions, Snapshot votes, IPFS, GitHub, HackMD, and other supporting resources related to these SNOPs. Make sure to review them thoroughly — they are essential, as these SNOPs help guide NOs operations within Lido.
Media Resources
Explore the following Lido YouTube playlists for valuable insights, updates, and community content:
- Lido Node Operator Masterclass: Presentations on node operation best practices and staking workshops
- Node Operator Community Calls: Recordings of monthly Lido Node Operator Community Calls (NOCCs)
- NOCC Shorts: Highlight cuts from monthly NOCCs, covering key topics and discussions
- Simple DVT - Updates, Guides and Developments: Updates, how-tos, and insights on the Simple DVT Module, setting up Obol and SSV validators and more.
- Community Staking Podcast: In-depth conversations, expert insights, and tips covering solo staking, DVT, permissioned validators, and the broader staking ecosystem.
- Education: Community Staking: Educational series dedicated to the Community Staking Module (CSM).
- LidoConnect 2023: Highlights from LidoConnect 2023 at DevConnect Istanbul, featuring staking-focused talks, panels, and workshops.
- LidoConnect 2024: Highlights from the second LidoConnect at Devcon2024 in Bangkok.
Module-Specific Resources
CSM
Permissionless bonded module for community stakers. Learn more.
All CSM resources can be found in this database.