---
tags: governance, dualgov
---

# LDO+stETH Dual Governance v3

The post explores the design of the [Dual Governance mechanism](https://research.lido.fi/t/ldo-steth-dual-governance/2382) revised & refined based on community feedback. Please refer to the original post for motivation and discussion.

The main goal of Dual Governance is to prevent the Lido DAO governance from changing the covenant between the protocol and stakers without consent from the latter.

If the covenant was impossible to change, the Dual Governance mechanism would be unnecessary. While this state is something the Lido team aims to achieve in the future via full protocol ossification, it's not possible until the Ethereum specification gets finalized and battle-tested. This means that Lido DAO governance scope will include potentially covenant-breaking decisions for quite some time.

### What about Lido on X?

This proposal only applies to the Ethereum liquid staking protocol. Lido DAO also governs liquid staking solutions for other networks, collectively called "Lido on X", which stakers can benefit from a similar mechanism.

We beleive that Dual Governance should eventually be rolled out to all Lido on X protocols. We're starting with Ethereum for two reasons:

1. Ethereum liquid staking is a flagship protocol that currently accounts for ~97% of the Lido TVL and affects significantly more users.
2. Other networks Lido is present on have unstaking, enabling foot voting as a pretty effective incentives-alignment device between the DAO and the stakers. The Ethereum network doesn't have unstaking yet and won't have it for some noticeable time.

## Critical governance decisions

Let's designate all possibly covenant-breaking decisions as **critical governance decisions**. All decisions involving any of the following actions are considered critical:

* Upgrading the Ethereum liquid staking protocol code.
* Managing the list of the Ethereum consensus layer oracle committee members.
* Changing how the stake is distributed between node operators in a potentially harmful or unexpected way (e.g. adding or removing whitelisted Ethereum node operators).
* Changing the governance structure in an unexpected or potentially harmful way (e.g. minting or burning LDO, changing the parameters of voting systems).
* Changing the total fee percentage of the Ethereum liquid staking protocol outside of the agreed boundaries, as well as defining these boundaries.
* Defining the list of critical governance decisions.

All other governance decisions are **non-critical** ones, e.g. managing the protocol treasury or approving new deposit data submitted by a node operator.

## Mechanism requirements

The main requirement for the Dual Governance mechanism is that, in the presence of a critical governance decision that changes the covenant between protocol and stakers or generally goes against their interests, stakers should be able to:

* escalate the conflict, blocking the governance from executing the decision;
* negotiate with the governance and de-escalate if negotiations succeed;
* exit the protocol othwerise.

Another requirement for the mechanism is that it shouldn't enable cheap attacks on the governance. Any attack should bear a considerable material cost.

The mechanism should also consider the fact that cooperation between stakers is harder and slower than it is between LDO governance members. This can be specified as three assumptions:

1. There is a small but active part of the stakers’ community that can react to a controversial governance decision and escalate in a timely manner.
2. There is a larger but less-active part of the community that can still participate in escalation given significantly more time.
3. The rest of stakers constitute an even larger group that is unable to participate in a timely manner.

The estimated sizes of these groups should define the basic parameters of the mechanism.

## Basic design

So, we want to give the active part of the stETH community enough time to react to a controversial decision and allow them to trigger a larger opportunity window for the wider community to get involved and protect all stETH holders, even the passive ones.

For that, let's impose an additional execution timelock on all critical decisions. This timelock starts after the voting (be it an Aragon voting, optimistic Easy Track motion, or any other potential governance mechanism) is passed and lasts `CRITICAL_DECISION_TIMELOCK_DURATION` seconds. During this timelock, the decision cannot be executed. The timelock should be long enough for the active part of the community to observe the decision and express their disagreement.


To measure how strongly the community disagrees with the governance, let's introduce the **Veto Escrow** smart contract. To escalate, stakers lock their stETH tokens into the escrow. This way, the percentage of the stETH total supply that is currently locked in the escrow can be used as an estimation of the community's willingness of escalation.

If a small portion of the community (say, 5%) expresses their disagreement, the governance exits its normal state and enters a transient **Veto Voting** state where execution of any critical decision is temporarily blocked and wider community has the chance to get involved.

If there's no significant participation from a wider community within some time boudary, the governance is transferred back into its normal state, unblocking execution of critical governance decisions.

Otherwise, if a sufficiently large percentage of stETH total supply joins the escalation, the governance is transferred to a **Veto Negotiation** state where stakers negotiate with the governance, selectively allowing execution of individual governance decisions (with any critical decision that's not explicitly allowed by stakers being permanently blocked from execution).


If this negotiations succeed, both sides have the ability to restore the normal state of governance operations. If this doesn't happen for a significant amount of time (e.g. a year) or if extremely large percentage of stETH total supply joins the escalation (e.g. 50%), **Global Settlement** is triggered: the protocol is effectively dismantled, unconditionally withdrawing all validators (using smart contract-triggered exits) and returning ETH to stakers.


Let's now specify all these states and transitions between them in more detail.

### Normal state

In the Normal state, governance decisions approved by LDO votings can be executed without involving stETH holders' input.

Critical decisions are subject to an additional timelock lasting `CRITICAL_DECISION_TIMELOCK_DURATION` seconds which allows the active part of the stakers' community to further postpone and, potentially, block the decision execution by transferring the governance into the Veto Voting state.

#### Transition: Veto Voting

To initiate a veto, stETH holders lock their stETH tokens into the Veto Escrow smart contract. While the governance is in the Normal state, stETH holders who locked their tokens into the escrow can unlock them at any moment.

If, as the result of a stETH lock transaction, the total amount of stETH locked in the escrow exceeds `FIRST_SEAL_THRESHOLD` (expressed as a percentage of the total stETH supply calculated at the same moment), the governance is immediately transitioned into the Veto Voting state.

The threshold should be small enough to not exceed the size of the active part of the stakers community posessing liquid or easily unlockable stETH that can react while the critical decision timelock is in effect. At the same time, it should be large anough to make governance griefing attack far from being free.

### Veto Voting state

Veto Voting state lasts at least `VETO_VOTING_MIN_DURATION` seconds and serves two purposes:

1. It allows wider stETH community to react to a controversial governance decision.
2. It assigns a cost to a governance griefing attack by locking stETH tokens used to initiate a veto voting for at least the duration of the voting.

While the governance is in this state, execution of critical governance decisions is blocked.

To support veto, stETH holders who haven't yet locked their stETH into the veto escrow can do so, and those who have can lock more. No stETH unlocking is possible in this state.

Locking each additional 1% of stETH total supply extends Veto Voting duration by `VETO_VOTING_DURATION_INC_PER_STETH_PCT` sec. Thus, Veto Voting duration can be calculated at any given moment $t$ as:

$$
D(t) = D_{min} + \left( \frac {V(t)}{S(t)} - T_1 \right) dD
$$

where $D_{min}$ is `VETO_VOTING_MIN_DURATION`, $V(t)$ is the total amount of stETH locked in the Veto Escrow at the moment $t$, $T_1$ is `FIRST_SEAL_THRESHOLD`, $S(t)$ is the stETH total supply at the moment $t$, and $dD$ is `VETO_VOTING_DURATION_INC_PER_STETH_PCT`.

#### Transition: Normal state

If, at any moment $t$, both of the conditions are satisfied:

1. $t - t_v \geq D(t)$, where $t_v$ is the moment of transition into the Veto Voting state;
2. the total amount of stETH locked doesn't exceed `VETO_NEGOTIATION_THRESHOLD` (expressed as a percentage of the total stETH supply calculated at the same moment),

then the governance is transferred to the Normal state. All stETH locked into the veto escrow is unlocked and can be reclaimed by the original holders. All critical governance decisions that were executable before the transition to the Veto Voting state become executable again.

#### Transition: Veto Negotiation

If, at any moment, the total amount of stETH locked in the escrow exceeds `VETO_NEGOTIATION_THRESHOLD` (expressed as a percentage of the total stETH supply calculated at the same moment), the governance is transferred to the Veto Negotiation state.

Upon transition to this state, all non-executed critical governance decisions, including decisions with active votings, become **vetoed**, which means no critical decision can be executed at any moment in future unless veto is explicitly lifted from that specific decision by a [Veto Lift Voting](#Veto-Lift-Voting).

### Veto Negotiation state

Veto Negotiation allows stETH holders to negotiate with the LDO governance and either unblock the governance if this negotiation succeeds or wind the protocol down otherwise.

Any critical governance decision that is proposed (i.e. gets an LDO voting created) while the governance is in this state gets instantly _vetoed_, meaning that it cannot be executed at any moment in future regardless of the outcome of the voting unless veto is explicitly lifted from that specific decision by a [Veto Lift Voting](#Veto-Lift-Voting).

While the governance is in this state, stETH holders can lock more stETH into the veto escrow. No stETH unlocking is possible.

This state lasts until stETH holders and LDO governance agree to transfer the governance to the Normal state (but at least `VETO_NEGOTIATION_MIN_DURATION` seconds) or while the Global Settlement transition is initiated.

#### Transition: Normal state

While the governance is in the Veto Negotiation state, an LDO voting can be initiated for transferring the governance into the Normal state. This transfer is itself a critical governance decision so, in order for it to become executable, all of the following conditions should be met:

1. The respective LDO voting should pass, followed by an execution timelock.
2. stETH holders should lift the veto from this voting's outcome by a Veto Lift Voting.
3. At least `VETO_NEGOTIATION_MIN_DURATION` seconds should pass since the governance entered the Veto Negotiation state.

After the decision is executed, the governance is transferred to the Normal state. All stETH locked into the veto escrow is unlocked and can be reclaimed by the original holders.

#### Transition: Global Settlement

If, while the governance is in the Veto Negotiation state, any of the two conditions is met:

* at least `GLOBAL_SETTLEMENT_TIMEOUT` seconds passed since the governance entered the Veto Negotiation state, OR
* at least `GLOBAL_SETTLEMENT_THRESHOLD` stETH is locked into the veto escrow (expressed as a percentage of the total stETH supply calculated at the same moment),

then the governance is immediately transferred to the Global Settlement state.

> Until smart contract-triggered withdrawals are implemented by Ethereum and Lido, global settlement is not possible to correctly implement. Thus, this transition, as well as the Global Settlement state, is not possible in the initial implementation of the Dual Governance mechanism.
>
> In the initial implementation, the governance stays in the Veto Negotiation state until it's transferred to the Normal state or until an upgrade implementing the global settlement mechanism is applied to the protocol.

### Global Settlement state

The Global Settlement state serves as a mean to gracefully dismantle the protocol while allowing stETH holders to withdraw ETH.

When the governance enters this state, the following happens:

1. Minting new stETH is stopped.
2. ETH deposits are stopped.
3. The regular stETH withdrawal mechanism is stopped. All stETH locked in the withdrawal queue is unlocked and can be reclaimed by original holders in exchange for burning the withdrawal NFT.
4. The protocol's withdrawal smart contract is irreversibly put into the the Global Settlement mode (see below).
5. All non-deposited ETH held by the protocol is transferred to the withdrawal smart contract.
6. Unconditional withdrawal of all validators registered via the protocol is initiated.
7. stETH locked into the veto escrow is unlocked and can be reclaimed by the original holders.

This is the final state, no further transitions are possible.

> Until smart contract-triggered withdrawals are implemented by Ethereum and Lido, global settlement is not possible to correctly implement. Thus, this state is not reachable in the initial implementation of the Dual Governance mechanism.

#### Global Settlement withdrawal contract

Upon the transition to the Global Settlement state, the protocol's withdrawal smart contract is put into a special mode that replaces its regular functionality with the following:

1. Until all validators registered via the protocol are exited, it does nothing and just accumulates ETH balance.
2. When all validators are exited, it calculates the stETH to ETH conversion rate by dividing its ETH balance by the total stETH supply (which is guaranteed to be constant from the moment the governance enters the Global Settlement state).
3. After that, it allows to irreversibly lock any stETH amount in exchange to an ETH amount calculated by multiplying the received stETH amount by the rate from the previous step.

## Veto Lift Voting

Veto Lift Voting is a mechanism for stETH holders to allow execution of specific governance decisions that became vetoed due to the governance reaching the Veto Negotiation state.

This mechanism allows performing critical protocol changes or upgrades even while LDO and stETH holders are in a disagreement about a certain governance decision. It also gives stETH holders more leverage in negotiations.

While, and only while, the governance is in the Veto Negotiation state, any stETH holder who has their stETH locked into the Veto Escrow (let's call any such holder a **veto participant**) can initiate a voting among veto participants with the following two possible outcomes:

1. Lift the veto from a critical governance decision X, allowing its immediate execution.
2. Don't lift the veto from the decision X.

Decision X is specified by the pair:

* voting system type (e.g. Aragon),
* vote id.

The voting lasts `VETO_LIFT_VOTING_DURATION` seconds.

During the initial two thirds of this period, veto participants can vote for one of the outcomes, with voting power being equal the amount of stETH the voter has locked into the Veto Escrow at the moment of the vote. A participant can re-vote, in which case the participants's voting power and, optionally, the supported outcome will be updated.

During the last one third of the voting period, veto participants can only vote for the second outcome (don't lift the veto) with voting power being calculated in the same way. A participant can re-vote with the updated voting power, but only in the support of the second outcome.

The voting is successful if, at the moment `VETO_LIFT_VOTING_DURATION` seconds pass since the beginning of the voting, both statements are true:

1. The combined voting power that participated in the voting (i.e. was used to vote for any outcome) is at least `VETO_LIFT_VOTING_MIN_QUORUM` percents of the total amount of stETH currently locked in the Veto Escrow.
2. The combined voting power supporting the first outcome (lift the veto) is greater than the combined voting power supporting the second outcome.

If the voting is successful, the veto is lifted from the governance decision X which can be executed by anyone starting from that moment (given that its execution timelock has already ended). Otherwise, the voting is failed and the decision X remains to be vetoed, i.e. non-executable at any moment in future.

No further veto lift votings can be initiated for the decision X.

The two-phase mechanism is required for Veto Lift votings since we're not locking new stETH from entering the Veto Escrow and not snapshotting voting power at the start of a vote. Without the two phases, it would be possible to outvote those who voted in support of not lifting veto or abstained from voting (with the same supposed effect) without them having a chance to react, e.g. in the last block of the voting.

## Executability of a critical governance decision

Considering all the mechanics described above, a critical governance decision can be executed if all these conditions are satisfied:

* The respective governance voting has passed.
* Its execution timelock has passed.
* It's not executed yet.
* The governance state is not Veto Voting.
* The governance decision was not vetoed OR was specifically unvetoed by a Veto Lift Voting.


Pseudo-code:

def exit_current_state(gov):
  if gov.state == State.VETO_NEGOTIATION:
    gov.apply_veto_upto = now()


def can_execute(gov, vote):
  if not vote.passed or vote.executed or gov.state == State.VETO_VOTING:
    return False

  timelock_ends_at = vote.ends_at + CRITICAL_DECISION_TIMELOCK_DURATION

  if timelock_ends_at >= now():
    return False

  if gov.state != State.NORMAL:
    # VETO_NEGOTIATION or GLOBAL_SETTLEMENT
    return vote.veto_lifted

  return vote.started_at > gov.apply_veto_upto

## Implementation stages

The proposed Dual Governance specification, in its part related to the Global Settlement, relies on the smart contract-triggered withdrawals—that is, the ability to initiate an exit of a validator from the smart contract the withdrawal credentials of that validator point to.

This feature is not yet supported by Ethereum, so the implementation of the Dual Governance has to come in two stages.

### Stage 1

From the governance perspective, the proposed mechanics is implemented in full, including all states and transitions. Permissions for executing critical governance decisions are withdrawn from the current governance/voting smart contracts and assigned to the Dual Governance smart contract.

The Dual Governance code is non-upgradeable but includes adapters of two types:

* A governance-modifiable list of adapters for supporting different voting types.
* An governance-replaceable adapter for putting the protocol into the Global Settlement mode.

Adding, removing and replacing an adapter is a critical governance decision and thus subject to a possible veto by stETH holders.

Initial voting system adapters are Aragon and Easy Track.

The initial implementation of the Global Settlement adapter reverts the transaction with the "not supported" revert reason.

### Stage 2

After smart contract-triggered withdrawals are supported by Ethereum, the following changes are made:

1. The protocol code is upgraded, adding Global Settlement support.
2. The Global Settlement Dual Governance adapter is replaced with the one that uses the new protocol functionality to activate the Global Settlement mode.

## Changes from previous iteration

* Added Veto Negotiation phase.
* Added Global Settlement.
* Rejected LDO and stETH burning options.

## Off-chain tooling

* AUtomated announcements of critical governance decisions.
* A UI for stakers allowing to:
* See the list of current critical gov decisions.
* See the state of veto (incl. for how long the Veto Voting will last and how locking your stETH will affect that).
* Participate in veto and see your participation state.
* Explore the list of Veto Lift votings and participate in them.
* Monitoring and alerting for governance state transitions.
* A UI for Global Settlement (may be a part of the regular withdrawal UI).

## Parameters

Modelling and determining the recommended values of the parameters is out of scope of this document. The values indicated below are for reference only.

#### `CRITICAL_DECISION_TIMELOCK_DURATION`

Duration of a timelock following a successful LDO vote for a critical governance decision during which the decision cannot be executed.

> Reference value: 1 week.

#### `FIRST_SEAL_THRESHOLD`

Percentage of total stETH supply required to be locked into the Veto Escrow in order for the veto voting to be started.

> Reference value: 3%.

#### `VETO_VOTING_MIN_DURATION`

Minimum duration of veto voting.

> Reference value: 1 month.

#### `VETO_VOTING_DURATION_INC_PER_STETH_PCT`

How much veto voting duration is extended with each additional 1% of the total LDO supply locked into the Veto Escrow.

> Reference value: 1 week.

#### `VETO_NEGOTIATION_THRESHOLD`

Percentage of total stETH supply required to be locked into the Veto Escrow by the time veto voting ends in order for the Veto Negotiation governance state to be activated.

> Reference value: 15%.

#### `VETO_NEGOTIATION_MIN_DURATION`

Minimum duration of the Veto Negotiation phase.

> Reference value: 1 month.

#### `GLOBAL_SETTLEMENT_TIMEOUT`

For how long governance should be in the Veto Negotiation state in order for the Global Settlement to be activated.

> Reference value: 1 year.

#### `GLOBAL_SETTLEMENT_THRESHOLD`

Percentage of total stETH supply required to be locked into the Veto Escrow for the Global Settlement to be immediately activated.

> Reference value: 70%.

#### `VETO_LIFT_VOTING_DURATION`

Duration of a Veto Lift voting.

> Reference value: 1 week.

#### `VETO_LIFT_VOTING_MIN_QUORUM`

Percentage of veto voting power required to participate in a specific veto lift voting in order for this voting to succeed.

> Reference value: 15%.