# Triggerable Withdrawals Framework in the Lido Protocol

**URL:** <https://research.lido.fi/t/triggerable-withdrawals-framework-in-the-lido-protocol/10299>\
**Category:** Proposals\
**Created:** [July 4, 2025, 11:40am UTC](https://research.lido.fi/t/triggerable-withdrawals-framework-in-the-lido-protocol/10299 "2025-07-04T11:40:13Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![Raman\_Siamionau](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/raman_siamionau/32/7018_2.png) [@Raman\_Siamionau](https://research.lido.fi/u/Raman_Siamionau)\
**Post date:** [July 4, 2025, 11:40am UTC](https://research.lido.fi/t/triggerable-withdrawals-framework-in-the-lido-protocol/10299/1 "2025-07-04T11:40:13Z")

</div>

### **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](https://eips.ethereum.org/EIPS/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)](https://github.com/lidofinance/lido-improvement-proposals/blob/develop/LIPS/lip-30.md)  
[Technical details](https://hackmd.io/Bebrx9iHTQuz71IqYmbICg)

* * *

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!

---

_[View the full topic](https://research.lido.fi/t/triggerable-withdrawals-framework-in-the-lido-protocol/10299)._