LIP-28: Dual Governance — Implementation, Parameters, Committees

Description

TL;DR

Dual Governance is a major upgrade to the Lido protocol, introducing a dynamic timelock mechanism allowing stETH holders to exit Lido on Ethereum in response to a contentious Lido DAO governance motion.

This vote aims to secure Lido DAO approval on the final Dual Governance rollout proposal, including the mechanism design and implementation outlined in the LIP-28, system parameters, and committees required to ensure system resilience and their proposed powers.

If this proposal is supported, the next step will be the on-chain vote to initiate the launch of Dual Governance.

Mechanism Design & Implementation

Dual Governance (DG) introduces a timelock contract between Lido DAO governance motions and their execution. The timelock is connected to escrow, allowing stETH holders to voice their intention to exit the protocol by depositing stETH, wstETH, and stETH withdrawal NFTs into a specific escrow contract. Once the amount locked there crosses the First Seal threshold (proposed to be 1% of Lido on Ethereum TVL), Veto Signalling state is entered, and the timelock duration starts growing proportionately. In this state, the DAO can continue to submit approved proposals to DG but cannot execute them. As the amount locked crosses the Second Seal threshold (proposed to be 10% of Lido on Ethereum TVL), the Rage Quit mechanics are triggered: execution of any motions under DG is blocked until all the stETH in escrow are withdrawn to ETH.

DG allows for de-escalation between stakers and the DAO: stakers can withdraw stETH from the escrow until Rage Quit is triggered, and DAO governance can cancel the contentious motion queued in DG. DG design mitigates a number of potential misuse scenarios along this basic flow.

The DG mechanism design was reviewed by Certora and Runtime Verification.

The proposed implementation can be found here:

• Code base
• Specification

Audits

This code has undergone four independent security audits.

• Certora: Delivered a combined audit and formal verification. 4 medium and 2 low issues were found—none critical. All were fixed or acknowledged with a rationale.
• Statemind: Audited the full DG system. Focused on config safety, governance transitions, and committees behavior. Found 4 medium and 42 informational issues. All medium issues and over 2/3 of informational issues were resolved.
• OpenZeppelin: Performed an audit of all core contracts—no critical, high, or medium issues identified.
• Runtime Verification: Used bytecode-level symbolic execution via Kontrol to formally verify key safety and liveness properties.

The full lifecycle (from game-theoretic design to edge-case execution) has been independently validated.

Parameters

DG parameters influence the limits of the system. They set thresholds, delays, and lock durations that affect:

• how long proposal execution can be delayed,
• how much time stETH holders are guaranteed for a response, and
• how much stETH is required to pause or exit through the DG mechanisms.

The system includes a broad parameter set. The subset below defines how DG may affect the proposal flow.

The full list of parameters is available here.

All proposed parameters were tested by two independent teams: game-theoretic research by 20squares and agent-based model research by CollectifDAO. Results show the system holds up well under stress, provided stETH holders act within the defined timelines.

Committees

DG introduces three special-purpose committees to handle edge cases that can’t be resolved via the standard flow.

1. Reseal Committee (spec, forum post)

The Reseal Committee is a 5/6 multisig with a single power: it can extend an existing GateSeal pause into an indefinite pause, lasting until explicitly unpaused by a DAO vote.

It activates only when both conditions are met:

1. DG is in a state other than Normal (i.e. DG is in a Veto Signaling or Rage Quit state);
2. a GateSeal pause has already been triggered on the contract.

The Reseal Committee shares the same signer set as the GateSeal but operates with a higher quorum to reflect its longer-term effect and lack of time sensitivity.

Address: 0xFFe21561251c49AdccFad065C94Fb4931dF49081

List of signers:

2. Emergency Committee (spec, forum post)

The Committee is designed to safeguard the protocol during the initial rollout of DG (proposed for 1 year).

The committee oversees two multisigs that share the same signer set but differ in quorum thresholds and functional scope:

Activation Multisig (4/7): can trigger emergency mode and block execution of proposals in DG. Address: 0x8B7854488Fde088d686Ea672B6ba1A5242515f45

Execution Multisig (5/7): can 1) execute blocked proposals in DG or 2) trigger an Emergency Reset, fully disabling DG and returning control to the DAO Voting contract. Address: 0xC7792b3F2B399bB0EdF53fECDceCeB97FBEB18AF

List of signers:

3. Tiebreaker Committee (spec, forum post)

A third-party arbiter that activates only in deadlock cases, such as:

• DG is stuck in a Rage Quit state + withdrawals are paused by the Reseal Committee,
• DG hasn’t been in a Normal / Veto Cooldown state for an extended period.

Once activated, the committee can 1) execute the blocked proposal in the DG pipeline and 2) unpause any paused protocol contracts.

The Tiebreaker is a “multisig of multisigs”, with a 2/3 quorum on the top-level multisig and supermajority approval required from each underlying subcommittee.

Sub-committees are composed of trusted external participants who represent the three core segments of the Lido community: Builders, Node Operators, and the broader Ethereum community members.

The Tiebreaker Committee contracts will be deployed along with the rest of the Dual Governance contracts. Afterward, the addresses of the committees and subcommittees will be shared on the forum.

List of signers:

Builders

Node Operators

Ethereum Ecosystem

Next Steps

If the DAO supports this proposal, the next step will be an on-chain vote to initiate the launch of Dual Governance.