The post explores the design of the Dual Governance mechanism 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.
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:
Let's designate all possibly covenant-breaking decisions as critical governance decisions. All decisions involving any of the following actions are considered critical:
All other governance decisions are non-critical ones, e.g. managing the protocol treasury or approving new deposit data submitted by a node operator.
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:
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:
The estimated sizes of these groups should define the basic parameters of the mechanism.
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.
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.
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 lasts at least VETO_VOTING_MIN_DURATION
seconds and serves two purposes:
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
where VETO_VOTING_MIN_DURATION
, FIRST_SEAL_THRESHOLD
, VETO_VOTING_DURATION_INC_PER_STETH_PCT
.
If, at any moment
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.
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 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.
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.
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:
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.
If, while the governance is in the Veto Negotiation state, any of the two conditions is met:
GLOBAL_SETTLEMENT_TIMEOUT
seconds passed since the governance entered the Veto Negotiation state, ORGLOBAL_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.
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:
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.
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:
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:
Decision X is specified by the pair:
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:
VETO_LIFT_VOTING_MIN_QUORUM
percents of the total amount of stETH currently locked in the Veto Escrow.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.
Considering all the mechanics described above, a critical governance decision can be executed if all these conditions are satisfied:
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
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.
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:
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.
After smart contract-triggered withdrawals are supported by Ethereum, the following changes are made:
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%.