Lido on Ethereum Standard Node Operator Protocol – Block Proposals

STATUS: V3.0

A – Purpose

This Standard Node Operator Protocol (SNOP) outlines

• the standards, Auxiliary Proposer Mechanisms (APMs, see Appendix A) and infrastructure available for block proposals in Ethereum,
• the rules around the usage of this SNOP,
• the considerations that guide the expectations of the Lido on Ethereum protocol (hereinafter, "Lido") with regard to block proposals and APMs,
• the responsibilities Node Operators (NOs) using Lido have in performing block proposals utilizing APMs and distributing the associated rewards to stakers, as well as
• the actions that NOs can expect in case of non-conformance with this SNOP.

B – Scope

This SNOP applies to Lido, the NOs who use any of the Staking Router (SR)'s existing Staking Modules (SMs) — Curated Module (CM), Simple Distributed Validator Technology Module (SDVTM) and Community Staking Module (CSM) — any future SM or staking avenue, and the validators the NOs run as part of the protocol.

The following operational flows and expectations apply to all above-mentioned SMs and staking avenues, except where alternative processes or expectations are defined due to technical or operational differences.

NOTE: Terminology may vary in meaning depending on context. The table below aims to clarify the usage of key terms for the purposes of this SNOP and within the context of Lido.

C – Guiding Considerations

As per the Lido DAO Vibe and regular Guided Open Objective Setting Exercises (GOOSE) performed by the community, the Lido DAO strives to contribute to the decentralization, accessibility, and censorship resistance of Ethereum. The following guiding considerations for NOs using Lido stem from these overarching goals.

C.1 – Economic Security

From a game-theoretical perspective, economic competitiveness of the protocol is paramount in order to optimally protect Ethereum's proof-of-stake (POS) consensus from 51% attacks and to facilitate the positive impact that Lido can have on the network's validator set. The rationale for this is set out in Hasu's maximal extractable value (MEV) proposal.

Advancing this goal entails that NOs using the protocol should attempt to do so in a way that finds a suitable balance between maximizing validator rewards and optimizing duty effectiveness by performing as reliably, timely, correctly, and free of slashable offenses as possible.

Additionally, it makes sense for the Lido ecosystem to enable participants to adopt new Ethereum-aligned standards and infrastructure (following sufficient testing and security assessment) that may improve staking operation and rewards.

Since NOs set the address for the execution level (EL) rewards directly associated with proposal activity (see section D.1) and sometimes, depending on the implementation, also the destination for those indirectly attributable to it (e.g., APM-protocol-specific incentives or commissions, see section D.3), there is a possibility that NOs using Lido could attempt to redirect such to earn more than the programmatically set share of protocol rewards. In the best interest of stakers and honest NOs, protocol mechanics should make rewards stealing through the use of Lido difficult to conceal, expensive to execute, and subject to penalty.

Regardless of whether NOs use the protocol via permissionless bonded or permissioned SMs, it is important that NO activities are transparently monitored to ensure fair conditions. For this purpose, a multitude of community-built open-source tools and dashboards are publicly available.

C.2 – Decentralization & Operational Diversity

Decentralization and operational diversity are two of the core values of the Lido community, and their continued improvement, just like that of Economic Security (see section C.1), an integral premise for the robustness of the Ethereum network. For this reason, the Lido community should prioritize balancing economic security with decentralization and operational diversity to promote the health of Ethereum.

Varied validation setups — such as through geographic dispersion, infrastructure and client diversification, etc. — are critical for proactively mitigating risks of local outages, isolated bugs, and for reducing Ethereum network latency on a global scale. NOs using Lido are encouraged to contribute to these sustained efforts; historically, Lido stakers and community participants have strongly supported NOs in expanding their infrastructure to underrepresented geographic regions and in adopting diversified, multi-client setups.

Another important aspect of decentralization is credible neutrality. For Lido's NO set this generally entails openly participating in and using a variety of — potentially competing — software clients, infrastructure technologies and — in the case of APMs — mechanism or protocol implementations. Nevertheless, the principle of credible neutrality should be balanced against operational and technical security considerations, as the community sets out guidelines around what tooling can be used and how.

C.3 – Censorship Resistance

A third attribute to balance — alongside the dimensions of Economic Security (see section C.1) and Decentralization & Operational Diversity (see section C.2) — is censorship resistance.

Although out-of-protocol proposer-builder separation (PBS, see Appendix A.2.1) was introduced as a concept to weaken incentives that might lead to highly verticalized validator operations, its opt-in nature, the high centralization of builders, and the necessity for explicit MEV relay selection due to the implicit trust assumptions in the mechanism make it possible that Ethereum transactions can still be censored. In fact, censorship rarely takes place at the level of the validators, but rather most often occurs at that of builders and (in the past) relays.

As outlined in decentralization and operational diversity, credible neutrality is a vital part of a healthy Ethereum and in turn is supported by participants that enable the censorship resistance of the network. As such, the design of Lido allows NOs to configure their setups in accordance with their understanding of what is necessary to be compliant and participate, while also empowering unconstrained NOs to advance and bolster the network's efforts towards censorship resistance. Similarly, given the fully on-chain and decentralized nature of the Lido protocol, stakers and the wider community can discover the NOs’ impact on the network's censorship resistance.

D – Node Operator Responsibilities

Based on the Guiding Considerations (see section C), the following responsibilities arise for NOs using Lido with respect to the block proposal configuration of the validators they run for the protocol. This section also outlines how stakers and the community can assess NO behavior and conformance — e.g., via the Lido Fees Monitoring Dashboard ("Monitoring Dashboard").

D.1 – Fee Recipient

For all validators run using Lido, the Execution Layer Rewards Vault for the relevant Ethereum network must be configured as the fee recipient (FR) via the appropriate setting in the validator client (VC) of choice.

On the Monitoring Dashboard, proposed blocks marked with "Unknown FR" could indicate either a misconfiguration of an NO's infrastructure with respect to the FR, or a potential rewards stealing attempt.

D.2 – APMs Allowed List

NOs may utilize APMs that have been vetted by the community and are included in the APMs Allowed List, maintained by the DAO-appointed APM Committee. This list consists of APMs that have been assessed as sufficiently de-risked and demonstrably beneficial to both Lido and the broader Ethereum ecosystem. Any APM seeking inclusion in the list must follow the standard evaluation and vetting process.

For each applicable validator, NOs utilizing APMs must adhere to all relevant configuration requirements, security best practices, and guidelines — including those related to the distribution of associated rewards — as defined in this SNOP, the APMs Allowed List and any referenced documentation for the relevant APM.

D.3 – Operational Best Practices

NOs using Lido and utilizing vetted APMs must generally, unless otherwise specified for a particular APM, adhere to the following principles:

D.4 – Out-Of-Protocol PBS

D.4.1 – MEV Boost Relay Allowed List

Unless excepted due to incompatible APM interactions, NOs must utilize out-of-protocol PBS and configure all validators run using Lido to include in the consensus client (CC) or out-of-protocol PBS sidecar (see Appendix A.2) of choice the address(es) of at least one vetted relay labeled as "must use some" and any number of relays marked as "may use" from the MEV Boost Relay Allowed List. This list is available on the Lido Node Operator Portal or can be queried directly using the get_relays method of the smart contract for the relevant Ethereum network. Any relay provider seeking inclusion in the list must follow the standard registration process and be successfully vetted by the Relay Maintenance Committee (RMC) for performance, data transparency, and operational sufficiency.

On the Monitoring Dashboard, proposed blocks marked with "Unknown PS" (payload source) and/or NOs with an abnormally high incidence of payloads sourced exclusively from "may use" relays could indicate a potential misconfiguration of an NO's infrastructure with respect to the MEV Boost Relay Allowed List.

D.4.2 – Troubleshooting

In case a builder and/or vetted relay experiences operational issues — e.g., incorrectly constructed payloads; delayed propagation of payload headers, response messages or unblinded payloads; unresponsive APIs — NOs should report the situation to the wider NO community and disable the affected relay(s) until service has been sufficiently and reliably restored. In case a relay does not resume nominal operation, the community and/or RMC should initiate communication regarding the issue and effectuate the removal of the faulty relay from the MEV Boost Relay Allowed List.

D.5 – Local Block Building

NOs may configure validators run using Lido to enable local block building (see Appendix A.1) in order to improve the network's censorship resistance and reduce reliance on relays, if the incremental value of proposed blocks with externally-sourced payloads is low and the parameterization generally falls within permitted limits. Given the evolving technical options and volatile market conditions of Ethereum, the permitted methods and values for local block building are defined by social consensus among NOs, DAO contributors, and the wider staking community in the Lido Node Operator MEV Boost min-bid guidance thread on the Lido Research Forum.

NOs opting into local block building must adhere to all relevant configuration requirements defined in this SNOP, the APMs Allowed List (see section D.2) and the above-mentioned thread.

On the Monitoring Dashboard, proposed blocks marked with "Unknown PS" may indicate a potential misconfiguration of an NO's infrastructure with respect to local block building.

E – Consequences of Non-Conformance

When potential NO non-conformance with Lido protocol rules and expectations is observed, the below actions may be taken. The actions and follow-up procedures may differ depending on the SM or staking avenue. For example, while NOs are identifiable in the permissioned CM and SDVTM, NOs within the permissionless CSM may remain anonymous, thus reaching out to the latter is only possible if they have voluntarily shared contact information with the community. Furthermore, bonded SMs, like the CSM, allow additional options for automated conformance mechanisms compared to bondless SMs such as the CM and SDVTM.

The table below outlines the potential consequences for non-conformance with the Node Operator Responsibilities (see section D) in regard to block proposals using Lido, along with the SM to which each action applies.

Action	CM	SDVTM	CSM
If a proposed block with an unknown FR is detected, any Lido DAO contributor or community member may reach out to the NO and request a clarification. If a force majeure event can be ruled out as the cause of the incident and no reasonable explanation is provided, it must be assumed that the FR has been misconfigured and/or the block rewards have been stolen. Depending on the severity of the case, community members may consider to raise a formal issue with the NO on the Lido Research Forum, request remediative action, propose the transfer of any missing rewards to the Lido Execution Layer Rewards Vault (see section D.1), or other actions, including the offboarding of the NO.
If a proposed block with an unknown FR is detected, an amount of the affected NO's bond equal to the respective block rewards plus an additional 0.1 ETH disincentive is algorithmically locked for 8 weeks. During this period, the NO is afforded to discuss the situation in the CSM Support category of the Lido Research Forum. Once the NO compensates Lido for the incident or upon expiry of the challenge period — if it is determined that the issue was caused by a force majeure event — the lock is lifted. However, if neither a reasonable explanation is provided, nor compensation transferred to the Lido Execution Layer Rewards Vault (see section D.1), the CSM Committee initiates an Easy Track motion to propose to the Lido DAO to burn the locked portion of the NO's bond as a penalty. If any of the NO's validators are unable to provide a full bond — i.e. become unbonded — as a result of the enforcement, those validators are requested to exit the protocol. If the affected validators are not exited, they are marked as stuck and no operator rewards are distributed to the NO until the validator exit requests are fulfilled. NOTE: Once EIP-7002: Execution Layer Triggerable Withdrawals are implemented into Lido, stuck validators will instead be forcefully ejected at the protocol level.
If unintended proposal behavior — e.g., due to suboptimal operational practices (see section D.3) — is detected, any Lido DAO contributor or community member may reach out to the NO and request a clarification. If a force majeure event can be ruled out as the cause of the incident and no reasonable explanation is provided, it must be assumed that the validation setup was neglectfully managed or a rewards stealing attempt made. Depending on the severity of the case, community members may consider to raise a formal issue with the NO on the Lido Research Forum, request remediative action, propose the transfer of any potentially missing rewards to the Lido Execution Layer Rewards Vault (see section D.1), or other actions, including the offboarding of the NO.			If the NO is identifiable
If an unknown PS and/or NO with an abnormally high incidence of proposed blocks with payloads sourced exclusively from "may use" relays is detected, any Lido DAO contributor or community member may reach out to the NO and request a clarification. If a force majeure event can be ruled out as the cause of the incident and no reasonable explanation is provided, it must be assumed that an unvetted relay has been configured and/or the "must use some" selection ignored. Depending on the severity of the case, community members may consider to raise a formal issue with the NO on the Lido Research Forum, request remediative action, propose the transfer of any potentially missing rewards to the Lido Execution Layer Rewards Vault (see section D.1), or other actions, including the offboarding of the NO. NOTE: Automated enforcements to these kind of non-conformances are currently under development for CSM v2.			If the NO is identifiable

Appendix

Appendix A – Ethereum Standards, Auxiliary Proposer Mechanisms & Infrastructure

A.1 – Local Block Building

In local block building, the validator allocated to the proposal duty of a slot packs the transactions to be included into an execution payload up to the block's gas limit through the use of the attached execution client (EC). The transactions can originate from the NO of the validator itself, from users who sent them to the NO via some side-channel mechanism for inclusion, and most likely and predominantly from Ethereum's public mempool through the EL gossip network. A block built with a locally-constructed payload is sometimes referred to as "vanilla".

A.2 – Auxiliary Proposer Mechanisms

APMs offer a structured framework for evaluating and understanding the role of mechanisms, protocols, and sidecars that work alongside Ethereum validators within its evolving consensus environment. Together, the three main components of the APM Framework enable enhanced functionality compared to the default block proposal process:

• Mechanisms define an objective and a method to achieve it within the Ethereum block proposal process. They establish the fundamental logic guiding proposer behavior — e.g., the PBS mechanism.
• Protocols are structured specifications for the standards, rules, and configurations of a given mechanism. They can exist in-protocol, out-of-protocol, or as hybrids (within the Ethereum ecosystem), shaping how mechanisms operate in practice — e.g., MEV-Boost as an out-of-protocol specification for the PBS mechanism.
• Sidecars are services or software components that support protocols, acting alongside validator software to enable their functionality — e.g., MEV-Boost as a client-side software to participate in the MEV-Boost protocol.

Protocols may also introduce additional clients or require modifications to existing node software. While these aren't strictly classified as sidecars, they function similarly within the APM Framework. Examples include mev-geth and the MEV-Boost Relay client.

A single mechanism can be implemented by multiple protocols, which in turn may rely on various sidecars. This generally follows a 1:n:n relationship — one mechanism can have multiple implementations in the form of protocols; and each protocol can be enabled by multiple sidecars. In some cases, a sidecar may even support multiple protocols.

In order to assess security, operational robustness, and value chain impact, APMs undergo a structured vetting process by the APM Committee before adoption. This process aids in the mitigation of risks, assesses benefits, and sets protocol standards for their integration into Lido's NO set.

As the field of APMs is a rapidly changing landscape of software offerings and implementations, the APMs Allowed List (see section D.2) is maintained by the APM Committee as a separate document in the Lido GitHub repository so that it may be revised and updated timely.

A.2.1 – Proposer-Builder Separation

PBS is a mechanism designated to address the increasing complexity of the block proposal process and concerns around increasing centralization of the stack by sophisticated actors. PBS resolves this by separating two aspects of the proposal process: the construction of the payload and the proposal of the block and its contents (including the payload). The separation of roles reduces the complexity for the proposer, who — in contrast to local block building (see Appendix A.1) — only has to select from payloads constructed and propagated by specialized third-party builders who compete in an auction, wrap that payload in a block, and propose it to the network. This allows operators who have more limited resources (e.g., weaker hardware) to fulfill block proposal duties and actively contribute to the security of the network, while still being competitive with proposers who have more resources at their disposal.

A.2.1.1 – Out-Of-Protocol PBS & MEV-Boost

In the case of PBS, although a concept discussed since before The Merge, no in-protocol version has been implemented into the core protocol to date (some options have been proposed, e.g., EIP-7732: Enshrined Proposer-Builder Separation (ePBS)). Currently, the de facto standard for out-of-protocol PBS is MEV-Boost, which is Flashbots' reference design proposal for a PBS-friendly MEV marketplace, whose architecture also served as basis for the specification of Ethereum's own Builder API (see Appendix A.2.1.2). Consequently, the combination of Builder API and MEV-Boost — the protocol, corresponding relay client and BN sidecar — is the most widely used implementation of out-of-protocol PBS today.

MEV-Boost has also addressed concerns about a weakness of PBS in protecting Ethereum's censorship resistance that had already been expressed for in-protocol variants. The minimum bid value ("min-bid") allows proposers to forego a limited amount of EL rewards and — instead of sourcing externally-constructed payloads for slots where the highest builder bid is below the min-bid configured by the proposer — generate payloads locally (see Appendix A.1), which increases the likelihood of inclusion for transactions which otherwise may be left out by the third-party builders for reasons other than their pure value.

A.2.1.2 – Builder API

Ethereum's temporary out-of-protocol PBS solution, for validators to delegate the payload construction duty of allocated slots to external builders. The Builder API has been designed to establish a direct one-to-one connection between a proposer and a builder, as configured in the proposer's CC. The MEV-Boost protocol and relevant out-of-protocol PBS sidecar implementations extend this functionality by interfacing with the Builder API in a multiplexer-like fashion allowing the proposer to connect to a multitude of builders (through relays).

A.2.1.3 – Builder & Relay Operator Responsibilities & Incident Management

Given the trusted nature of out-of-protocol PBS, it behooves builder and relay operators to ensure that they and the infrastructure they operate function effectively, performantly, and efficiently, and that any and all communications are made timely and professionally.

Builder and relay operators should notify relevant Lido stakeholders — e.g., NOs and the NOM workstream — as soon as possible upon identification of an issue with any of the infrastructure that they operate. Notification may be performed through public (e.g., the Lido Research Forum or Discord) and/or private channels (e.g., Telegram group chats) so that NOs can proceed with appropriate changes to their configurations.

During an incident, builder and relay operators should provide regular updates with regard to the status. Following the conclusion, the operators should provide a report or post-mortem that details at minimum the root cause, fixes performed, if/how soon the infrastructure will be back in service, and what steps have been undertaken to prevent the likelihood of similar incidents in the future. Additionally, in cases where block production was adversely affected (see section D.4.2), the operators should advise as to what steps will be taken — if any — to reimburse validators for any missed, invalid, etc. blocks and/or inaccurate bids.

Incidents will be reviewed on an ad-hoc basis by the NO and Lido communities. These reviews will inform DAO governance decisions regarding whether relay operators and the relays that they operate will continue to be considered vetted and ratified for use by NOs or not.

Relay operators which exhibit poor or otherwise unacceptable communication and especially performance of their relays — such as, but not limited to, inability to performantly and timely register validators or propagate bids and payloads, not verify bids, not simulate payload validity, etc. — and/or fail to conform with the expectations outlined above with regard to incident management, may be subject to removal from the MEV Boost Relay Allowed List (see section D.4.1).