<aside> ℹ️

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.

</aside>

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.

<aside>

</aside>

Each tool in the database includes a description and usage notes to help you quickly assess its purpose and decide whether it suits your validator operations. Whether you're looking to improve monitoring, streamline automation, or manage infrastructure efficiently, this collection is designed to support a range of setups and needs.

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 getMembers()
Hoodi getMembers()

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