Lido Finance, a leading protocol in liquid staking, recently introduced a dual governance system aimed at safeguarding user funds and enhancing DAO security. However, any innovation comes with potential risks, and - no exaggerating- bugs in Lido’s governance will ripple across DeFi.

In this blog post, I detail the design review process for Lido’s dual governance system, outlining the challenges, bugs discovered, and solutions implemented to ensure the security and robustness of the protocol.

Dual Governance in a Nutshell

In many cases, the total market value of DAO governance tokens is significantly lower than the total value of assets the DAO manages. This disparity makes it economically viable for an attacker to acquire most governance tokens and execute malicious proposals to steal funds.

DAOs traditionally use safeguards like timelocks and emergency multisigs to mitigate this attack vector. These mechanisms provide users time to react, such as withdrawing or migrating funds in response to a suspicious proposal. However, liquid staking protocols like Lido, Rocket Pool and more, face a unique challenge: withdrawal times can vary significantly, leaving users with a limited window to respond.

Lido Finance invented the dual governance, a two-layer governance system that includes the original voting mechanism and an additional veto layer. Before a malicious proposal is executed, depositors can collaborate to halt all DAO executions temporarily. This pause allows for further verification, cancellation of the proposal, or sufficient time for users to exit via the withdrawal queue.

The Proposed Lido Dual Governance Architecture

Lido Dual Governance's state machine. Credit: Lido Finance

Lido's initial governance design included a mandatory 3-day timelock before executing DAO-approved proposals. This period served as a buffer, allowing stakeholders to review the proposal. If deemed malicious, concerned stakers could lock their staked Ether (stETH) in a specialized contract called the Escrow to signal their objection.

Once a predefined percentage of total stETH—the "first seal of support"—is locked in the Escrow, the system transitions into a phase called vetoSignaling, lasting 45 days. During this phase, all proposal executions are halted, even if the timelock has expired. The required support threshold increases linearly over time, which represents the amount of stETH that must remain locked in the Escrow to sustain the vetoSignaling state. This threshold eventually reaches the "second seal of support" after 45 days from the start of vetoSignaling.

If the locked support falls below the required support threshold at any point, the system temporarily enters a vetoSignalingDeactivation phase, which lasts 24 hours. This phase provides stETH holders an opportunity to regain enough support to meet the current threshold. If successful, the system reverts to the standard vetoSignaling phase, with the deactivation period counting towards the 45-day requirement. During vetoSignalingDeactivation, no new proposals can be submitted, and execution remains paused.

If the second support seal is met after 45 days, the system transitions to the RageQuit state. In this phase, governance operations are suspended, and the Escrowed stETH is transferred to the withdrawal queue. This allows affected stakers to exit the protocol and retrieve their funds. The governance system only resumes normal operations after all withdrawal requests are processed and an additional cooldown period of one week has passed.

Alternatively, if the proposal is non-malicious, stakers can unlock their stETH from the Escrow, reducing the funds below the required threshold. As explained earlier, this triggers the vetoSignalingDeactivation phase, providing a 24-hour window for stETH holders to restore support. If the threshold remains unmet after this period, the system will exit vetoSignaling entirely and transition to a vetoCooldown phase.

During the vetoCooldown phase, users cannot initiate a new vetoSignaling phase by locking funds into the Escrow. However, proposal executions continue as usual. Once the cooldown period ends, the system resumes its normal state. This cooldown prevents rapid cycling back into vetoSignaling, ensuring a brief interval during which proposals can proceed without disruption.

Potential Risks and Challenges of Dual Governance

While dual governance enhances security by adding a veto mechanism, it introduces new complexities that can expand the system’s attack surface. The key challenges fall into three categories:

1. Governance Liveness
   Ensuring that governance remains functional is critical. The system must continue to process and execute valid proposals without entering a deadlock or facing prolonged delays, even during periods of heightened veto activity.
2. Veto Accuracy
   Governance actions should neither shorten nor bypass the veto period unfairly. On the other hand, proposers should not be able to manipulate the system to extend veto durations beyond what is warranted.

Fairness
Every user must be guaranteed the ability to withdraw their funds in full. Furthermore, the system must prevent users from accessing funds that belong to others.

Bugs Prevented

While reviewing Lido's dual governance design, I collaborated closely with their team, iterating multiple times to identify and mitigate potential vulnerabilities. This involved brainstorming possible exploits and ensuring edge cases were addressed in the protocol's logic. To strengthen our analysis, we utilized a formal verification tool called TLA+, which allowed us to rigorously validate the state machine governing dual governance.

Below are two interesting bugs that were prevented during the design review process.

Bug 1: Griefing by Perpetual Veto Signaling Deactivation

I identified a vulnerability in the veto signaling mechanism that could deactivate perpetual veto signaling. This issue allowed an attacker to exploit the Escrow system with minimal cost, severely hindering governance processes.

A malicious actor could take a flashloan to temporarily lock funds in the Escrow, triggering the vetoSignaling phase. Once triggered, they could unlock the funds at the same block, repaying the flashloan, causing the Escrow's balance to drop below the required support threshold. This would force the system into the vetoSignalingDeactivation state, during which no proposals can be submitted, and executions are halted for 24 hours. The attacker could repeat this process every 24 hours throughout the 45-day vetoSignaling period, effectively blocking new proposals from being submitted under normal procedures. This attack is almost free to the exploiter, incurring no cost beyond gas fees.

It is possible to counter this attack by following the same steps as the attacker: taking a flashloan, locking sufficient funds in the Escrow to meet the required support threshold, and returning the system to the vetoSignaling state. This temporarily restores the ability to submit a proposal. A proposal can be submitted before the locked funds are withdrawn from the Escrow and the flashloan is repaid, all within the same block. However, this workaround has a significant drawback—it resets the 24-hour vetoSignalingDeactivation period, further prolonging the disruption of normal governance processes.

The Fix

The system now enforces a minimum lock time for funds deposited into the Escrow. This change prevents attackers from manipulating the system using flash loans, as funds must remain locked for several blocks before being withdrawn. This modification ensures that such low-cost, repetitive attacks cannot interrupt governance processes.

Bug 2: DOS RageQuit Loop

An attacker could reinstate a veto at the precise moment RageQuit ended by vetoing a proposal and progressing through the RageQuit state. However, the system had a backup Tiebreaker committee that, after a year of persistent RageQuit, could execute proposals even in a RageQuit state.

This attack vector could cause a bypass of this tiebreaker committee by once a year not vetoing right away, letting the system go into a normal state, and then vetoSignal again in the same block. This cycle effectively blocked proposal execution (and tiebreaker committee), resulting in a denial of service for the DAO. This bug allows an attacker to stall the DAO indefinitely.

The fix

Previously, the system only entered the vetoCooldown phase after a failed veto attempt. Following our report, Lido addressed this vulnerability by extending the vetoCooldown phase to apply after successful vetoes (without another veto). 

This improvement ensures that the system cannot reenter the loop of vetoSignaling RageQuit immediately (to bypass the tiebreaker committee). Thereby maintaining governance liveness and preventing abuse of the veto mechanism. Also, the Lido team added an extra delay for withdrawal from the escrow, to punish repetitive vetoSignalling without preventing it.

Secure your Protocol’s Design

Adding new layers or modifying existing components in a system increases complexity and potential attack surfaces. Each change requires fresh threat modeling and reassessment to ensure security.

Design reviews for innovative systems like dual governance are crucial before code is written. Early identification and mitigation of vulnerabilities are far easier and less costly than addressing them post-deployment. Proactively securing DeFi systems enhances user trust and safeguards assets, contributing to a more resilient ecosystem.

Please contact Certora to review your project design before writing smart contracts and other system parts to increase security and reduce time to market. We service all types of blockchains and protocols.