Dual Governance: design and implementation proposal

What is Dual Governance

The Dual Governance mechanism (DG) is an iteration on the protocol governance that gives stakers 1) a dynamic user-extensible timelock on DAO decisions and 2) a rage quit mechanism taking into account the specifics of how Ethereum withdrawals work.

Current status

After multiple stages of the research (the latest update, the start of the “continuation” thread, the initial post), the mechanism design is now fully fleshed out. The mechanism design is outlined on GitHub, as is the the technical architecture and the code draft. Contributors have started spec review projects with Certora and Runtimeverification teams.

The proposal

Dual Governance research team is seeking a signal of approval of the Dual Governance design from the Lido DAO. If the proposal is supported by the DAO, the team will move forward with a technical implementation, and start collaborating with external research- and security-focused teams to make sure the design, the implementation and the parameters are sound and ready for the mainnet deployment.

External teams involvement

The project involves a number of external teams challenging the design, code and parameter choices. The current plan includes working on the specification and code-level checks and audits with Certora, Runtimeverification, Open Zeppelin, Statemind, and engaging Collectif Labs research team for parameters research collaboration (developers behind the https://collectif.finance/).

Approximate timeline

The approximate timeline targets a testnet deployment around Q3, with potential mainnet launch in late Q3 / Q4. Note that the timelines are approximate at the moment and are subject to change depending upon the security checks and the testnet results.

Engage and prepare for the vote

Please, make sure to raise your concerns, ask questions here in the comments or in the research results forum thread and signal your support (or lack of) for the Dual Governance project in the snapshot vote next week.


Sacha has published full-fledged explainer about the mechanism design and what the Dual Governance: Lido dual governance explainer


Hey, Gregory from Runtime Verification is here! Excited about our spec review engagement for Dual Governance.

If anyone has questions about the engagement - feel free to reach out!


Thank you, @kadmil @sacha @skozin and all the contributors to the proposal, for the great research and design/implementation proposal. We believe this is basically the most practical design for the dual governance system after we have experienced the governance space in other DAOs such as Optimism.

We would like to confirm whether our understanding of how the system works for the (w)stETH holders as described below:

For most of the time, (w)stETH holders can utilize their (w)stETH in other platforms such as Uniswap for maximizing their yields.
And then, if ever a proposal that (w)stETH holders consider undesirable passes its voting by LDO holders, they withdraw their (w)stETH from other platforms and lock it into veto signalling escrow to perform their right to veto.

It would be great to see a few scenarios in the process where the proposed dual governance is implemented, for token holders to easily understand what options they have for each scenario.


Thank you for the comment! I think the closest outline of options / scenarios existing in writing right now is this section: Lido dual governance explainer (research distillation)

Would also note that scenario analysis is part of the work on the mechanism specification (dual-governance/docs/mechanism.md at develop · lidofinance/dual-governance · GitHub), but there’s no dedicated section about those. Most likely we’ll be pushing to have it under parameters research process as well.


Yep, that’s mostly correct, except that it’s not a veto per se (in the permanent sense) but instead, the right to delay the execution of a proposal until (w)stETH holders who disagree with it exit the protocol. The DAO can elect to cancel the proposal to try keeping those holders but the holders cannot force it so calling this action a “veto” was my mistake, it misleads more than helps.

The section of the explainer @kadmil linked contains a more detailed description of the two common scenarios, and the post itself is a great place to learn about the reasoning behind the mechanism and why it’s shaped as it is.


Snapshot vote started

The Dual Governance: design and path towards implementation Snapshot has started! Please cast your votes before Thu, 25 Apr 2024 16:00:00 GMT :pray:


Thank you, and @kadmil for the clarifications.

They totally make sense to us now. While there is a risk where many stETH holders will exit in the worse case scenario, it’s the most feasible option that Lido DAO can provide.

It might not be only us who took this “veto” as the literal veto as you mentioned, so we hope there would be some name change (e.g. delay signalling or grace period?) on the documents in the following updates.

We will vote for the proposal and support the changes to come.

1 Like

Yeah we’ll think about how to change the wording, it’s clearly misleading.

In the case many stETH holders are willing to exit the protocol due to some DAO decision, the proposed design still provides the DAO with a path to de-escalation by revoking the decision while the Signalling state is active (the currently proposed duration is 45 days) and demonstrating to the users that the DAO has indeed changed their mind or voted by mistake (e.g. due to under-representation of LDO holders in the particular vote). And if the DAO doesn’t want to revoke it, then it’s totally ok and desirable for the disagreeing users to leave since the DAO is not aligned with them anymore.


Although this is our first-ever public comment on a Lido proposal, we have been working extensively on complex regulatory and legal matters with members of the Lido ecosystem for the past 18 months. BCAS is a crypto-only law/reg firm set up in 2017, and we regularly work with some of the best-known names in the space on all matters intersecting tech and law.

We believe that this proposal has the potential to significantly benefit stETH holders by empowering them with a veto signalling; the suspension of proposals redistributes governance rights and control, thereby fostering the decentralisation of the protocol.

However, we do have a query about the Escrow Contract, which is in charge of receiving and storing the stETH, wstETH and unfinalised withdrawal NFTs of users who decided to veto a Lido DAO proposal and can serve as an ungoverned accumulator of withdrawn ETH, following the Rage Quit state, where users will withdraw their ETH deposited on Lido.

Our concern is in relation to the scenario where all stETH and wstETH held by the Rage Quit Escrow are sent for withdrawal via the regular Lido Withdrawal Queue mechanism since there is not enough detail provided on how this shall be automatically executed. Would it be possible to perhaps elaborate further on this, so that we may see whether this gives rise to any legal implications or otherwise?


Snapshot vote ended

The Dual Governance: design and path towards implementation Snapshot has reached a quorum and completed!
The results are:
Approve: 50.4M LDO
No action: 22.3k LDO

1 Like

Hi @BCAS_Legal, thanks for your question!

So the Lido protocol has the Withdrawal Queue contract that orders withdrawals and mints unstETH withdrawal NFTs representing withdrawal requests and their position in the queue. It is upgradeable by the DAO and is part of the withdrawal mechanism.

When rage quit starts, withdrawal of all stETH and wstETH from the Escrow gets initiated, which requires these tokens to be sent to the Withdrawal Queue contract, generating unstETH withdrawal NFTs—it’s exactly the same process as one performs while doing the regular (w)stETH to ETH withdrawal.

The difference from the normal withdrawal process is that:

  • Withdrawal unstETH NFTs are held by the Escrow contract address and not the staker address.
  • Until all tokens are completely withdrawn to ETH, the DAO cannot execute any proposals, including upgrading any protocol code (e.g. the Withdrawal Queue contract).
  • After the withdrawal is finished, there’s an additional timelock on claiming ETH from the Escrow.

So the normal withdrawal process is the following:

  1. The staker sends (w)stETH to the Withdrawal Queue contract and gets an unstETH NFT in exchange.
  2. After the withdrawal is finalized, the staker burns their unstETH NFT and gets ETH in exchange.

The rage quit withdrawal process:

  1. The staker sends (w)stETH to the Escrow contract. The Escrow contract tracks how much (w)stETH each staker has sent.
  2. When rage quit starts, the Escrow sends all (w)stETH it holds to the Withdrawal Queue contract and gets unstETH NFTs in exchange.
  3. After the withdrawal of all (w)stETH from the Escrow is finished, the Escrow burns all unstETH NFTs and gets ETH. At this point, the contract is ungoverned and only holds ETH. The DAO execution is unblocked.
  4. After a timelock, each rage quit participant (not a staker anymore as their tokens are now pure non-staked ETH) can unlock their portion of ETH from the Escrow contract.

The execution of withdrawals is already automatic on the protocol side (even for regular withdrawals) but currently relies on Node Operators voluntarily exiting validators they run for the protocol’s users when asked by the protocol code, which is the current limitation of the Ethereum staking mechanism. Lido offers a helper sidecar code that a Node Operator can run to automate the exits on their side but the protocol cannot force it. After EIP-7002 (“triggerable validator exits”) is implemented by the Ethereum network (expected early next year iirc), the protocol code will be able to trigger the exits of validators without collaboration from Node Operators which would improve the autonomy of the withdrawal mechanism.


Hi Sam,

Thanks for taking the time to reply and elucidate further. No further comments from our side – well done once again on this!




1 Like