Lido Proposal: #0x7d7f0e1a6d181310f8752af37e20515a9be258f30b211872f9acca99bc478851
Triggerable Withdrawals Framework in the Lido Protocol
For: 100%
52,320,592 LDO
Against: 0%
11 LDO
Voting Period
-Proposer
0xDbBC6A93ae517D3ea568C04219cbBBd025f01CB6
Discussion
Go to DiscussionDescription
TL;DR
This proposal seeks Lido DAO approval for the design of Triggerable Withdrawals (TW) framework, including the Technical Specification, the LIP, Easy Track Factories for VEB, GateSeal split-up, and limit parameters based on Parameter Research.
Motivation
Triggerable Withdrawals (TW) framework, based on EIP-7002, enables 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 protocol. Today, only Node Operators can trigger validator exits via Consensus Layer. If either party is compromised or unresponsive, stETH holders face indefinite withdrawal delays. 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;
- Permissionless exits for validators that have been requested to exit, preventing Node Operators from delaying the fulfillment of withdrawal requests;
- A mechanism for validator exit requests via Easy Track, allowing both the DAO and Node Operators to initiate exits through the Validator Exit Bus in exceptional cases.
Specification Overview
At a high level, the architecture is centered around the Validator Exit Bus (VEB), which serves as the main coordination point for validator exit requests. Exit reports can be submitted to the VEB by authorized entities, which then emit validator exit events. Once exit request events are emitted, Node Operators are expected to voluntarily initiate the validator exit.
To manage all Triggerable Withdrawal Requests (TWRs) submitted by authorized entities, a dedicated smart contract called the Triggerable Withdrawals Gateway (TWG) is introduced. This contract acts as the single entry point for TWRs from trusted sources and forwards valid requests to the Withdrawal Vault.
Once an exit event has been emitted via the VEB, any participant of the Ethereum network can submit a TWR through a permissionless interface provided by the VEB contract. VEB ensures that the validator was indeed requested to exit before passing the request to the TWG for execution.
A detailed description of the implementation can be found in the Technical Specification and the LIP.
Easy Track Factories
Easy Track Factories for VEB allows authorized actors to submit a report hash to the Validator Exit Bus (VEB) along with a desired list of validators. The proposed list of authorized actors to submit and execute Easy Track motions:
- SDVTMC – can manage exits for any validator exits in the sDVT Staking Module;
- NO (Node Operator) – can manage any exits for validators they own in the Curated Staking Module.
GateSeal
The emergency pause mechanism has been revised and areas for improvement have been identified to improve separation and security.
Previously, a single GateSeal controlled both VEBO and WithdrawalQueue — which posed a risk if both needed pausing independently. It is now proposed that the GateSeal contract be split into two and the former contract dismissed:
- One for WithdrawalQueue (WQ) only — considered the most critical.
- One for both VEBO and TWG — grouped as they belong to the same flow and were refactored together.
The same GateSeal Committee proposed operating both new GateSeal contracts.
Limits
To protect the Lido protocol from excessive validator exits and prevent abuse, a rate-limiting mechanism is introduced for VEB and TWG. This mechanism enforces a dynamic quota system that gradually grows over time and is consumed as exits are triggered.
Limit Mechanics
The system is governed by three core parameters:
maxExitRequestsLimit
- the maximum capacity of the quota; the available quota cannot exceed this value; with time, the quota is gradually replenished — up to this maximum.exitsPerFrame
- defines how much new quota becomes available with each new frame; this enables gradual and predictable replenishment of the quota over time.frameDuration
- the duration of each frame, in seconds, after whichexitsPerFrame
exits can be restored.
Parameters
Below is a list of configuration values, based on Global Limit on Maximum TW research, that are proposed to be assigned as part of the upcoming upgrade.
Name | Value | Description |
---|---|---|
maxExitRequestsLimit | 11200 | Maximum quota can be accumulated |
exitsPerFrame | 1 | Amount of quota replenished per frame |
frameDuration | 48 | Duration of each frame in seconds |
Next Steps
If the DAO supports this Snapshot vote, the following steps will be taken:
- Prepare and verify deployment using approved implementation and parameters;
- On-chain vote to initiate the launch of Triggerable Withdrawals in the Lido Protocol.
The condition required for the TW mainnet launch is the completion of audits by StateMind and Ackee with no unresolved findings and the publication of the final audit reports on the Research Forum.