Lido is a decentralized liquid staking protocol for Ethereum. Triggerable withdrawals is a new feature based on the EIP-7002 standard that allows for the ejection of validators previously deposited through the Lido protocol.
The primary purpose of triggerable withdrawals is to allow the Lido DAO to withdraw funds locked in a validator when the node operator refuses to submit a withdrawal request. This functionality became available after EIP-7002 was implemented on mainnet.
Withdrawal triggering is permissionless; however, users must provide data whose hash matches one already submitted by Easy Track or trigger exits once the Oracle has provided the report data.
Lido engaged Ackee Blockchain Security to perform a security review of Lido Triggerable Withdrawals with a total time donation of 38 engineering days in a period between June 5 and July 14, 2025. 10 engineering days were allocated to manually-guided fuzzing using Wake.
Lido then engaged Ackee Blockchain Security to perform a fix review of the findings from the previous revision. The review was performed between July 23 and July 25, 2025 and no new findings were discovered.
Lido engaged Ackee Blockchain Security to perform a third review, this time of changes made since the previous revision with a total time donation of 0.5 engineering days in a period between September 8 and September 16, 2025 and no new findings were discovered.
METHODOLOGY
We began our review by implementing and executing manually-guided differential fuzz tests in Wake to verify the correctness of the new functionalities and to ensure the changes do not break existing invariants. Fuzzing was conducted with contracts forked from mainnet and relevant contracts upgraded to the latest version. This ensured full compatibility with the mainnet deployment. 2 staking modules were used to test the triggerable withdrawals functionality – Node Operators Registry and Community Staking Module v2. More details about the fuzzing process can be found in the full audit report linked at the end of this article.
In parallel, we performed an in-depth manual review of the code, especially focusing on the triggerable withdrawal functionality, compatibility with EIP-7002, and new code changes since the last audit (commit 1ffbb7e). During the review, we focused on the following:
- permissionless mechanism of triggering validator exits;
- compatibility with EIP-7002;
- exploring new attack vectors due to triggerable withdrawals functionality;
- permissionless mechanism for reporting of exit delayed validators;
- checking that all state variables are properly updated and do not break any invariants;
- ensuring access controls are not too relaxed or too strict; and
- looking for common issues such as data validation.
Static analysis tools were used to review the code as well and yielded findings I4 and I5.
SCOPE
The first audit was performed on commit 628c873 in the core repository and the scope was the following:
contracts/0.4.24/nos/NodeOperatorRegistry.solcontracts/0.8.9/LidoLocator.solcontracts/0.8.9/StakingRouter.solcontracts/0.8.9/TriggerableWithdrawalsGateway.solcontracts/0.8.9/WithdrawalVault.solcontracts/0.8.9/WithdrawalVaultEIP7002.solcontracts/0.8.9/oracle/AccountingOracle.solcontracts/0.8.9/oracle/ValidatorsExitBus.solcontracts/0.8.9/oracle/ValidatorsExitBusOracle.solcontracts/0.8.9/lib/ExitLimitUtils.solcontracts/0.8.25/lib/BeaconTypes.solcontracts/0.8.25/lib/GIndex.solcontracts/0.8.25/lib/SSZ.solcontracts/0.8.25/ValidatorExitDelayVerifier.sol
The initial review commit 8beee97 was changed 4 days after the beginning of the audit to the commit 628c873.
FINDINGS
The classification of a security finding is determined by two sub-ratings: Impact and Likelihood. This two-dimensional rating makes the severity of issues more noise-free, without losing any information. The likelihood factor usually decreases severity of medium issues that would be just acknowledged by the team to infos and warning.
Our review resulted in 11 findings ranging from Info to Low severity. The most severe findings, L1 and L2, relate to the limited responsiveness of the system upon changing the exit limits configuration parameters and inconsistency in the total number of processed exit requests, respectively. The overall code quality is high, with comprehensive documentation and good architecture.
Critical severity
No critical severity issues were found.
High severity
No high severity issues were found.
Medium severity
No medium severity issues were found.
Low severity
L1: Inconsistent update of exit limits on config change
L2: Inconsistent calculation of total requests processed
Warning severity
W1: Unimplemented function called
W2: Missing interface inheritance
W3: Outdated IConsensusContract interface
W4: _setExitDeadlineThreshold underflow
Informational severity
I1: Code optimizations
I2: Lack of event emission
I3: Lack of context in deprecated function NatSpec
I4: Unused errors
I5: Unused using-for directive
TRUST MODEL
Lido allows permissionless triggering of validator exits if the validator is included in a report submitted via Easy Track or Oracle. The protocol relies on two trusted components for submitting withdrawal reports:
The flow for triggering validator exit via Easy Track is as follows:
- The hash of the report is submitted by an address with the
SUBMIT_REPORT_HASH_ROLErole, which is assigned to Easy Track; - Anyone can submit report data with the same hash provided in the first step; and
- Anyone can trigger the exit of a validator included in the report.
The flow for triggering validator exit via Oracle is as follows:
- The hash of the report is submitted by the consensus contract;
- The report data is submitted by an address with the
SUBMIT_DATA_ROLErole or by a consensus member; and - Anyone can trigger the exit of a validator included in the report.
Easy Track is an on-chain component that conducts lightweight voting; a proposal passes if the minimum objections threshold is not reached.
The Trigger Exits Bot is an off-chain component that ensures withdrawal requests are not unnecessarily stalled so that users experience smooth exits.
The Validator Late Prover Bot is an automated tool to detect and report late validators who have failed to exit within the required timeframe after an exit request.
An address with the ADD_FULL_WITHDRAWAL_REQUEST_ROLE role can submit withdrawal requests via the Triggerable Withdrawal Gateway.
Staking Router functions require specific roles to be assigned to the caller’s address.
CONCLUSION
Ackee Blockchain Security recommended Lido Finance to:
- ensure contract upgrade and initialization are atomic to prevent frontrunning attacks possibly leading to loss of control over the contract;
- always inherit from interfaces in the contracts that implement them; and
- address all identified issues.
Ackee Blockchain Security’s full Lido Finance Triggerable Withdrawals audit report can be found here.
We were delighted to audit Lido Finance and look forward to working with them again.
