Triggerable Withdrawals Framework in the Lido Protocol

Proposals
1

TL;DR

This proposal outlines implementing the Triggerable Withdrawal framework within the Lido protocol to enable permissionless, secure, and verifiable validator exits via the Execution Layer - enhancing the protocol’s fault tolerance, reducing trust assumptions, and paving the way for truly permissionless staking in Lido.

Abstract

The Triggerable Withdrawals (TW) mechanism is a critical extension of Lido’s architecture, enabling the initiation of validator exits without requiring the involvement of a Node Operator. TW is based on EIP-7002, which addresses a key issue in delegated staking. Previously, stakers had to rely on the goodwill of Node Operators - either to pre-sign an exit message or to agree to process it in the future. This limitation is now removed: any party with access to a validator’s withdrawal credentials can initiate its exit directly via the Execution Layer.

Motivation

For the Lido protocol, TW support means a substantial reduction in trust assumptions toward Node Operators and Oracles. It unlocks the following capabilities:

  • Permissionless Staking Modules, such as CSM, where ETH cannot be “held hostage” even if the operator misbehaves or significantly underperforms;
  • A mechanism for emergency validator exits, in case of key loss or a potential compromise event;
  • Direct DAO interaction, enabling the Lido DAO to request validator exits independently of Oracles.
  • Enables permissionless exits for validators that have been requested to exit, preventing NOs from delaying withdrawal requests fulfillment.

References

The Lido improvement proposal (LIP-30)
Technical details

We kindly ask everyone to share their opinions and suggestions for improvement in this thread. If no objections are raised, the next step will be the Snapshot vote (presumably, on July 14).

Thanks!

9 Likes
2

Thanks for the proposal @Raman_Siamionau!

I find it useful and well thought out. The only suggestion from my side is to have a detailed breakdown of the use cases. While they are listed with high-level descriptions, more detailed explanations might be useful for Lido Node Operators. CSM Node Operators can refer to the corresponding parts of the CSM v2 spec: 📝 Community Staking Module v2. Spec - HackMD. Still, having it all collected in one place seems useful to me.

1 Like
3

I have a couple of questions just to clarify some moments:

  • Will this be a mandatory transition for all Node Operators?
  • Will everyone be required to upgrade in order to remain part of Lido?
2 Likes
4

TW mechanism is proposed to be implemented on the Lido Protocol side. No actions are required from the Node Operators side.

2 Likes
5

Thanks for feedback!

Will prepare such document!

2 Likes
6

Also, what to highlight that we’re introducing new Easy Track Factories for the sDVT committee and Node Operators in the Curated Module. These ET factories enable authorized entities to request validator exits via the Validator Exit Bus for specific validators. After initiating such exits, anyone can exit those validators using the TW framework on the EL.

It provides a crucial recovery path in catastrophic scenarios - such as when a Node Operator loses access to a validator key.

:blue_book: More details can be found in the LIP-30: Easy Track Factories for VEB

7 Likes
7

Thanks for the proposal @Raman_Siamionau!

Recommended TW limits for Lido

To make triggerable withdrawals safe and reliable, we suggest:

  • maxExitRequestsLimit: 11 200 validators (applies to both TW gateway and VEB modules)
  • exitsPerFrame: 1 validator
  • frameDuration: 48 seconds (resulting in (~1 800 validators/day))

This setup keeps TW permissionless and efficient, providing a sufficient capacity for emergency validator exits, while still limiting risks for any malicious attacks utilizing EIP-7002 if there is a protocol exploit

For full analysis (threat models, APR effects, benchmarks, etc.), check the detailed research here: TW module limits

6 Likes