Lido Proposal: #0x7d7f0e1a6d181310f8752af37e20515a9be258f30b211872f9acca99bc478851

Triggerable Withdrawals Framework in the Lido Protocol

Status:
Closed
For100%

For: 100%

52,320,592 LDO

Against: 0%

11 LDO

Voting Period

  -  

Proposer

0xDbBC6A93ae517D3ea568C04219cbBBd025f01CB6

Description

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:

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:

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:

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.

NameValueDescription
maxExitRequestsLimit11200Maximum quota can be accumulated
exitsPerFrame1Amount of quota replenished per frame
frameDuration48Duration of each frame in seconds

Next Steps

If the DAO supports this Snapshot vote, the following steps will be taken:

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.