Triggerable Withdrawals Framework in the Lido Protocol

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:

1. 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.
2. exitsPerFrame - defines how much new quota becomes available with each new frame; this enables gradual and predictable replenishment of the quota over time.
3. frameDuration - the duration of each frame, in seconds, after which exitsPerFrame 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.