Dear Lido community,
This post proposes v3 of the Lido protocol Standard Node Operator Protocol (SNOP) on Validator Exits.
Its predecessor, the Validator Exits SNOP v2, was introduced at a time when validator withdrawal mechanics on Ethereum were still relatively static, Lido protocol exits were primarily aligned with post-Capella mechanics, and the idea of triggerable withdrawals had not yet been formalized. With the introduction of Triggerable Withdrawals for the Lido protocol in the near horizon, and the upcoming evolution of validator consolidation and staking module design, revisiting and updating this policy has become necessary.
To come up with this draft, we analyzed the Ethereum protocol changes, incorporated insights from Pectra specifications, discussed operational implications with contributors across several Lido workstreams, and applied the same structured approach familiar from earlier SNOP revisions.
The main changes in this version include:
-
Incorporation of Triggerable Withdrawals: Adapting operator responsibilities and exit procedures to reflect the new mechanism for triggerable withdrawals.
-
Standardization of structure and definitions: Aligning terminology with recent SNOP updates, protocol upgrades, and Ethereum’s adjustments.
-
Updated scope: Extension of applicability to Node Operators (NOs) participating through new modules such as Simple DVT, Community Staking, and potential future modules.
-
Explicit responsibilities for NOs: Clearer articulation of obligations regarding validator exits, including response times, withdrawal triggering, and reporting.
-
Breakdown of consequences: Updated consequences per staking module in case of non-compliance, reflecting new tooling and processes.
The draft is not final, and we would like to invite feedback from the community to ensure it captures the protocol changes and operational realities correctly. If no objections are raised, the next step will be a Snapshot vote during the October cycle.
Given that Triggerable Withdrawals represent a fundamental shift in how validator exits are handled, we particularly welcome feedback on:
-
The balance between automation and NO responsibility in the triggering process.
-
How exit prioritization and consolidation should be operationalized under the new mechanism.
-
Any additional safeguards that should be explicitly captured in the policy.
You can review the full draft here: Link to draft
Winning option: For