# Dual Governance: Analytic's note on parameters values

**URL:** <https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905>\
**Category:** Proposals\
**Created:** [April 10, 2025, 5:18pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905 "2025-04-10T17:18:34Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Greg\_S](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/greg_s/32/1988_2.png) [@Greg\_S](https://research.lido.fi/u/Greg_S)\
**Post date:** [April 10, 2025, 5:18pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/1 "2025-04-10T17:18:34Z")

</div>

Hello, this is the Analytics workstream. In this post, we would like to summarize the research done by [20[]](https://20squares.xyz/) and [CollectifDAO](https://collectif.finance/) on Dual Governance parameter values and give our recommendations for the next steps.

## TL;DR

The [Dual Governance mechanism](https://research.lido.fi/t/dual-governance-design-and-implementation-proposal/7131) relies on parameters whose values should be chosen before deployment. This note summarizes research done by external research teams: [20[]](https://20squares.xyz/) and [CollectifDAO](https://collectif.finance/). Both research efforts show that with the chosen parameter values Dual Governance gives stakers a say by allowing them to block DAO decisions and providing a negotiation device between stakers and the DAO, while not exposing it to significant new attack vectors. The Analytics workstream recommends using the proposed values. Still, there exists an area for improvement that should be covered in further research and development.

## Introduction

The Dual Governance mechanism was introduced in [this forum post](https://research.lido.fi/t/dual-governance-design-and-implementation-proposal/7131). Value parameters used in the research were taken from this [mechanism description](https://github.com/lidofinance/dual-governance/blob/develop/docs/mechanism.md). These parameters were tested both in game-theoretic research by 20[] and agent-based model research by CollectifDAO. Here we would like to summarize the results of this research and define the values of Dual Governance (DG) parameters.

## Dual Governance Parameters Cheatsheet

In the next sections we will mention different DG states and parameters, here you can find a cheatsheet which will help you understand the DG basics. Still, we strongly recommend you to go through a mechanism [design overview](https://github.com/lidofinance/dual-governance/blob/develop/docs/mechanism.md). Another important note - further only parameters of core mechanism would be discussed, if you want to check all deploy parameters please proceed to **Appendix A**.

The DG is an iteration on the protocol governance that serves the following main objectives, for simplicity we will address this list as “Dual Governance goals”:

1. Give stakers a way to credibly signal their disagreement with LDO holders and the commitment to leave the protocol if LDO holders don’t cooperate in resolving the incentives conflict.
2. Allow for the possibility of negotiation and de-escalation between stETH and LDO holders.
3. Introduce an extended timelock on DAO decisions that can be triggered by an active minority of stakers and prolonged as more stakers participate.
4. Improve foot voting efficiency by allowing stakers to exit the protocol without being subject to new and pending DAO decisions.
5. Don’t overburden users with governance decisions

Dual Governance consist of following states:

| State | DAO can submit proposals | DAO can execute proposals |
| --- | --- | --- |
| Normal | ✓ | ✓ |
| Veto Signalling | ✓ | |
| Veto Signalling (deactivation) | | |
| Veto Cooldown | | ✓ |
| Rage Quit | ✓ | |

With Following transitions between these states:

 ![|1174.8736136498117x409.0000000000001](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/b/bc9864342158539d41c74a7fcfa29d90a4567510.png)

Change of the states, as well as other properties are rely on Dual Governance parameters

| Parameter | Proposed Value | Meaning |
| --- | --- | --- |
| FirstSealRageQuitSupport | 1% | Share of total stETH supply that is needed to switch dual governance to the Veto Signaling state |
| SecondSealRageQuitSupport | 10% | Share of total stETH required to change from Veto Signalling state to Rage Quit state |
| ProposalExecutionMinTimelock | 3 days | The minimum number of days a proposal will be held in Dual Governance before execution (unless the Veto signaling state is entered). |
| DynamicTimelockMinDuration | 5 days | The minimum duration of the dynamic timelock, as long as the share of stETH locked in the Veto Signaling contract is higher than the First Seal Rage Quit Support threshold. |
| DynamicTimelockMaxDuration | 45 days | Maximum duration of the dynamic timelock, as long as the share of stETH locked in the Veto Signalling contract is higher than the First Seal Rage Quit Support threshold. If the share of locked stETH is higher than the Second Seal Rage Quit Support threshold when this number of days has passed, the state switches to Rage Quit; otherwise, it switches to Deactivation. |
| SignallingEscrowMinLockTime | 5 hours | Time during which a stETH holder will be unable to withdraw stETH from the Veto Signaling contract, once stETH was put there. |
| VetoSignallingMinActiveDuration | 5 hours | The minimum time that must pass before the veto signaling state can be changed to the deactivation state. |
| VetoSignallingDeactivationMaxDuration | 3 days | Maximum duration of the Deactivation stage. This state would either change back to Veto signaling (if new stETH is locked in the Veto Signaling contract) or to Cooldown, if the maximum duration has passed. |
| VetoCooldownDuration | 5 hours | Duration of cooldown state; could transition to either Normal state, or to Veto signaling state, depending on the amount of stETH locked in the Veto Signaling escrow. |
| RageQuitExtensionPeriodDuration | 7 days | In addition to the Rage Quit state, this addition ensures that even if a user locks their withdrawal NFT in the veto signaling contract, they will still have at least 7 days to claim ETH. |
| RageQuitEthWithdrawalsMinDelay | 60 days | The minimal delay during which withdrawn ETH could not be claimed after Rage Quit. This prevents system abuse by performing cyclical rage quits. |
| RageQuitEthWithdrawalsMaxDelay | 180 days | Maximum delay during which withdrawn ETH could not be claimed after Rage Quit. |
| RageQuitEthWithdrawalsDelayGrowth | 15 days | Added to RageQuitEthWithdrawalsMinDelay after each Rage Quit in a row, but not more than RageQuitEthWithdrawalsMaxDelay. Once the system gets back to Normal state, the delay also gets back to RageQuitEthWithdrawalsMinDelay |

### How parameters are connected and affect each other

 ![](https://europe1.discourse-cdn.com/flex013/uploads/lido/original/2X/b/b1c7a0493449a3d334406a306e2f055b5a964737.png)

Strictly speaking, the parameters within Dual Governance form a single system, meaning they are all interconnected. However, some parameters can be considered “isolated” (i.e., changes to these parameters will not significantly affect others). For example, _VetoCooldownDuration_—the only requirement for this parameter is that it must be long enough to allow pending executions to be enacted. On the other hand, changes to certain parameters can have a significant impact on the entire system. Below, we highlight some of these interconnections:

- _ProposalExecutionMinTimelock_ – _FirstSealRageQuitSupport_: The higher the _ProposalExecutionMinTimelock_, the higher _FirstSealRageQuitSupport_ might need to be (and vice versa). However, since _ProposalExecutionMinTimelock_ affects all voting processes, it should remain low enough to prevent governance from becoming too slow.

- _FirstSealRageQuitSupport_ – _SecondSealRageQuitSupport_ – _DynamicTimelockMinDuration_ – _DynamicTimelockMaxDuration_: These four parameters are strongly interconnected because they determine the duration of timelocks and regulate how much additional stETH extends the dynamic timelock. For example, if _SecondSealRageQuitSupport_ is set to 5%, each additional stETH will prolong the timelock by twice as many seconds compared to when _SecondSealRageQuitSupport_ is set to 10%. There are many such interdependencies, but the key takeaway is that any change to one of these four parameters should also trigger adjustments to the other three.

- _SecondSealRageQuitSupport_: This parameter also plays a role in triggering rage quits—the higher it is, the more difficult it becomes to accumulate the required amount for a rage quit (and vice versa). However, if this parameter is set too low, it becomes easier to execute a rage quit cycle attack (where a malicious actor intentionally triggers multiple rage quits in succession to halt Lido governance). Additionally, this parameter defines the “negotiation space,” i.e., how much stETH must be deposited into the Veto Signaling Escrow before a rage quit can commence.

Also existing committees as well as newly added committees would affect Dual Governance :

[Gate Seal](https://github.com/lidofinance/dual-governance/blob/develop/docs/mechanism.md#gate-seal)  
[Reseal Committee](https://github.com/lidofinance/dual-governance/blob/develop/docs/mechanism.md#gate-seal)  
[Tiebraker Committee](https://github.com/lidofinance/dual-governance/blob/develop/docs/mechanism.md#tiebreaker-committee)

## Research Overview

[20[] report](https://github.com/20squares/dual-governance-public)  
[CollectifDAO report](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf)

Both research projects tested proposed parameter values, with different approaches to modeling. This section will provide a short overview of both research projects, with links to specific parts of the research reports. Please remember that this overview does not represent all the efforts and work put into the research, so we strongly recommend reading the reports.

### Base assumptions

Before diving into the research reports, it is also important to present initial assumptions, which were taken during the research process. One of the main assumptions was the stETH holder wallet distribution and reaction speed (i.e., the speed of information spreading) among stETH holders. Here is a breakdown of these assumptions:

_stETH holder wallet distribution_ - responsible for answering the questions “How much stETH can actually be used to trigger Veto signaling?” and “How much stETH could be sent to the Veto Signalling contract within a certain timeframe?”. For this assumption, the actual distribution of stETH among wallets was taken. Then, wallets representing nearly 80% of the total supply were labeled as either “private”, “CEX”, “Contract”, or “Custody” using publicly available labels. Private wallets are holders who hold stETH in their wallets and can vote relatively fast. Note that Multisig contracts (such as Gnosis Safe) also fall into this category. CEX, Contract, and Custody wallets represent holders who do not actually hold stETH in their wallets but rather some token based on stETH (for contracts) or their stETH is under external management (CEX and Custody). Such holders obviously cannot use their stETH immediately and require some time to withdraw or claim their stETH and put it into the Veto signaling contract.

Reaction speed - represents how fast stETH holders react to a proposal and put their stETH into a veto signaling contract. For both research efforts, different cases of such reactions were tested; you can read more in the [CollectifDAO report](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf) and the [20[] report](https://github.com/20squares/dual-governance-public?tab=readme-ov-file#improve-the-functioning-of-the-protocol-as-a-safety-hatch).

Without this assumption, it is impossible to perform any analysis since Dual Governance relies on stETH holders and would not work as intended without stETH holder actions. The boundaries of this assumption were also tested; you can read [more about this in Chapter 4.2.1](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf).

### CollectifDAO research

Agent-based modeling (ABM) simulation was developed to simulate the protocol’s mechanisms, user behavior, and dynamic governance processes with the novel Health Points (HP) framework, which was developed specifically for this Lido DG research grant. The HP framework allows for the parameterization of each agent’s inclination to stay with or leave the protocol due to various conditions, such as misalignment of governance decisions, ongoing attacks, or accumulated dissatisfaction. ([Chapters 3.1-3.2](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))

Simulation was tested in several clusters representing goals of Dual Governance implementation ([Chapter 2, Chapter 3.3](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf)), including:

- Foot voting efficiency
- Principal-agent problem (PAP) diminishment
- Security
- Stability
- Future-proofing

Addressing each cluster, parameter values were tested, as well as sensitivity analysis, which allows to understand the boundaries of the main parameters and assumptions ([Chapter 4.1, Chapter 4.2](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))

### 20[] research

The main framework for this research is game theoretic, with a 20-square compositional game theory engine, aiming to analyze the incentives of the different actors involved in the dual governance on-chain mechanism.

Research analyses 2 main objectives of dual governance implementation:

1. [Protection of (w)stETH holders and arbitration vehicle](https://github.com/20squares/dual-governance-public?tab=readme-ov-file#objective-1-of-dual-governance-mechanism-protection-of-wsteth-holders-and-arbitration-vehicle)
2. [Avoiding new vectors of attack introduced through the dual governance mechanism](https://github.com/20squares/dual-governance-public?tab=readme-ov-file#objective-2-of-dual-governance-mechanism-avoiding-new-vectors-of-attack-introduced-through-the-dual-governance-mechanism)

As well as [Parameters choice and tradeoffs](https://github.com/20squares/dual-governance-public?tab=readme-ov-file#objective-2-of-dual-governance-mechanism-avoiding-new-vectors-of-attack-introduced-through-the-dual-governance-mechanism)which also provide boundaries for parameters values.

## Results

### Overall design

#### 20[]:

- For evidently malicious proposals, the mechanism works mostly as intended.
- In the case of proposals whose consequences are less clear; its proper functioning is not certain.
- Dependence on the Ecosystem:
  - DAO: The mechanism’s effectiveness relies on the working of the DAO; i.e. proposal introduction, evaluation, and information dissemination.
  - Liquidity & Congestion: During critical periods, high demand to lock tokens can lead to congestion and elevated costs, potentially weakening the mechanism when it is most needed.

#### CollectifDAO:

- Simulations verified the functionality of the proposed DG thresholds, timelocks, and other design decisions under both normal and adversarial conditions.
- The 1% Veto Signalling threshold and the 10% Rage Quit threshold were confirmed to be well suited for stakeholder participation, safeguarding against governance abuse while ensuring operational efficiency

### New attack vectors

#### 20[]:

- No critical vulnerabilities were identified
- Increased Complexity: The mechanism’s added complexity introduces new risks, such as exploiting state oscillations (e.g., toggling veto-signaling) to delay or block decisions.
- Manipulation Risks: Attackers might leverage ambiguous proposal assessments or manipulate committee actions( [Tiebraker Committee](https://github.com/lidofinance/dual-governance/blob/develop/docs/mechanism.md#tiebreaker-committee) ), which could lead to prolonged protocol halts or harmful proposals being pushed through.

#### CollectifDAO:

- Simulated scenarios provided in the GitHub [repo](https://github.com/collectif-dao/dg-research/tree/c6f6f7df885abf99651cbe216581951b5bf361e4/experiments/notebooks) encompassed regular governance flows, coordinated attacks, malicious exploitation, and extreme stress scenarios
- Results demonstrated the ability of DG to deter most attack vectors, including bribery and Veto Signalling loops, given sufficient participation and decentralization

### Parameters values and boundaries

#### 20[]:

| Parameter | Default | Min | Max | Unit | Adaptable? |
| --- | --- | --- | --- | --- | --- |
| FirstSealRageQuitSupport R1 | 1 | 0.15 | 1.36 | % | x |
| SecondSealRageQuitSupport R2 | 10 | 10 | 30 | % | |
| ProposalExecutionMinTimelock | 3 | 2 | 7 | days | x |
| DynamicTimelockMinDuration Lmin | 5 | 3 | 7 | days | |
| DynamicTimelockMaxDuration Lmax | 45 | 30 | 75 | days | |
| SignallingEscrowMinLockTime | 5 | 4 | 6 | hrs | x |
| VetoSignallingMinActiveDuration | 5 | 3 | 9 | hrs | x |
| VetoSignallingDeactivationMaxDuration | 3 | 1 | 3 | days | |
| VetoCooldownDuration | 5 | 4 | 12 | hrs | x |
| RageQuitExtensionPeriodDuration | 7 | 7 | 14 | days | |
| RageQuitEthWithdrawalsMinDelay | 60 | 45 | 90 | days | |
| RageQuitEthWithdrawalsMaxDelay | 180 | 150 | 240 | days | |
| RageQuitEthWithdrawalsDelayGrowth | 15 | 15 | 45 | days | |
| TiebreakerExecutionTimelock | 1 | - | - | month | |
| TieBreakerActivationTimeout | 1 | - | - | year | |

_Default_ refers to values proposed in the initial spec. Adaptable? parameters are ones which should be monitored in practice - they are possibly used even though it does not come to a rage quit event. E.g. if FirstSealRageQuitSupport is chosen too small and a repeated invoking and thereby halting of the protocol is observed, the parameter can be adapted upwards.

#### CollectifDAO:

The Lido Dual Governance (DG) simulation model used the following parameters for an Agent-Based Modeling environment, unless specified differently in particular simulations.

| Parameter | Value |
| --- | --- |
| First Seal Veto Signalling Threshold\* | 1% |
| Second Seal Rage Quit Threshold | 10% |
| Dynamic Timelock minimum duration | 5 days |
| Dynamic Timelock maximum duration | 45 days |
| Veto Signalling Minimum Active Duration | 5 hours |
| Veto Signalling Deactivation Duration | 3 days |
| Veto Cooldown Duration | 5 hours |
| Rage Quit Withdrawals Minimum Timelock | 60 days |
| Rage Quit Withdrawals Maximum Timelock | 180 days |
| Rage Quit Withdrawals Delay Growth Factor | 15 days |
| Rage Quit Extension Period Duration | 7 days |
| Proposal Execution minimum timelock | 3 days |
| DAO Single Governance objections stage | 2 days |

\*Note that “First Seal Veto Signaling Threshold” is another name for _FirstSealRageQuitSupport_.

**“Reliable” parameter range estimations:**

- Veto Signalling “reliable” threshold range is 0.75% - 1.5%
  - From auxiliary calculation in [4.2.2](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf) Impact of Wallet Distribution Assumptions [Notebook](https://github.com/collectif-dao/dg-research/blob/actor_reaction_reworked/experiments/notebooks/clean_notebook_future_proof.ipynb), starting from an R1=0.75% veto threshold, the number of wallets that could support coordinated attacks drops significantly
  - From [Cluster A](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf) - Varying Veto Thresholds: success rate of reaching veto signaling drops sharply past an R1=1.5%

- Rage Quit “reliable” threshold range is 7.5% - 12.5%
  - From auxiliary calculation in [Cluster D](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf) Long-Term Lock of Dual Governance with Constant Rage Quit, R2=5% significantly decreased the capital required for Rage Quit Loop attack without providing significant upside for achieving Rage Quit in time, and R2=7.5% is the next relatively stable step from it
  - From auxiliary calculation in [4.2.1.](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf), Impact of Slow Actor Reaction Assumptions [Notebook](https://github.com/collectif-dao/dg-research/blob/actor_reaction_reworked/experiments/notebooks/clean_notebook_ragequit_slowactors_delay_sweep.ipynb), starting from an R2=12.5% Rage Quit threshold, the ability of slow actors starts to reach Rage Quit decays significantly already at 30 day slow actor max delay, which poses significant model risks from DG participation assumptions

### Recommendations

#### 20[]:

- Parameters cannot be pinned down by the game theoretic model alone; hence auxiliary analyses to restrict parameter bounds
- Parameters should balance protecting (w)stETH holders against preventing harmful proposals and unnecessary delays.
- Suggested directional adjustments:
  - Lower the trigger threshold for veto-signaling.
  - Increase the minimum time-lock duration to give token holders more time to react.
  - Raise the rage quit threshold to make attacks more expensive and provide time for token holds to get into the contract.

- Overall Goal: Ensure the mechanism functions primarily as a last-resort safety measure rather than a negotiation tool, avoiding prolonged limbo states.

#### CollectifDAO:

1. Parameter Monitoring and Adjustment:

- Maintain the current Veto Signalling (1%) and Rage Quit (10%) thresholds, but establish processes for regular monitoring of governance participation and explore solutions for reaction time dynamic updates ([2.5, 4.3.1](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))
- Establish pipelines to effectively engage with large token holders to improve the speed of reactions during critical governance decisions and ensure timely participation ([4.2.1, 4.3.1](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))

1. Mitigation of Exploitation Risks:

- Consider extending signalling escrow minimal lock times towards days, as it could significantly help to reduce vulnerabilities in quick-actor bribery scenarios with “last minute” bribing swings before proposal scheduling. Additional withdrawal lock on escrow during the last 12+ hours before potential proposal scheduling could significantly constrain bribing attacks without major problems to regular actors ([Cluster C, 4.3.3](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))
- Increase transparency of proposal impacts to deter malicious influence and enhance stakeholder trust in the system ([4.3.3](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))

1. Ensuring Long-Term Governance Stability:

- Consider developing flexible thresholds to adapt to future changes in token distribution and potential centralization risks ([4.2.2, 4.3.3](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))
- Evaluate timelock durations periodically to ensure they align with evolving token holder dynamics and governance requirements ([4.2.2, 4.3.2](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf))

## Next steps

1. Setup Framework and tools for parameter value adjustment.

While the proposed values are effective under current market conditions, it is crucial to establish a method for evaluating and adjusting these values in response to significant structural changes in market conditions (including new stETH sources, [presented in Lido v3](https://v3.lido.fi/)) and/or stETH holder reactions.

1. Approach to cost of attack evaluation.

While research is held under the conservative assumption that an attack on the protocol through Dual Governance is economically rational, such an attack still does not give the attacker direct access to users’ funds. However, it could be profitable by leveraging volatile market conditions that would be caused by the attack. Another area of research is to understand the cost of liquidity for the attacker and how much such an attacker could earn by abusing the Dual Governance mechanism.

## Analytics workstream opinion on the research results

1. Both of research show:

2. Regarding 20[] recommendation: “Ensure the mechanism functions primarily as a last-resort safety measure rather than a negotiation tool, avoiding prolonged limbo states.” Dual governance design went through many iterations ([Link 1](https://research.lido.fi/t/ldo-steth-dual-governance/2382), [Link 2](https://research.lido.fi/t/ldo-steth-dual-governance-continuation/5727), [Link 3](https://research.lido.fi/t/lido-dual-governance-explainer-research-distillation/7132)), during which it was stated that one of the guiding objectives is: “Allow for the possibility of negotiation and de-escalation between stETH and LDO holders,” which was then [approved by DAO](https://snapshot.box/#/s:lido-snapshot.eth/proposal/0x3bdf528b31956e029e867ebf79b02ee07e9a973987b34c5cffc14392e8b4480c). Since there is also a requirement to not introduce new significant attack vectors, the proposed design is a compromise between safety and initial goals. This compromise allows limbo states but ensures that other goals are fulfilled.

3. There exists a trade-off between withdrawing and putting stETH into a veto signaling contract. If an stETH holder observes a malicious proposal early enough to have enough time for withdrawal, such a user will most likely withdraw stETH through the regular process; however, such action will decrease the amount of “fast available” stETH, which is needed for triggering FirstSealRageQuitSupport. Within the researches, this was solved by not taking into account the long tail of wallets that hold less than around 50 stETH, representing 20% of total stETH supply (it was assumed that such wallets would withdraw stETH through the regular process), but the “withdrawal/putting into veto signaling” compromise should be taken into account when creating a framework for parameter value adjustments.

## Conclusion

After careful consideration by the analytics team, we can conclude that even though the chosen values might not be perfect, they maintain the main role of Dual Governance implementation: It serves all Dual Governance goals while not adding new significant attack vectors. **We recommend using the proposed values** in the initial implementation while still introducing frameworks and tools for market monitoring and value adjustment.

We extend our sincere appreciation to the [20[] team](https://20squares.xyz/) and [CollectifDAO](https://collectif.finance/) team for their extensive and thorough research efforts.

## Links

[Dual governance proposal](https://research.lido.fi/t/dual-governance-design-and-implementation-proposal/7131)  
[Mechanism design](https://github.com/lidofinance/dual-governance/blob/develop/docs/mechanism.md)  
[20[] report](https://github.com/20squares/dual-governance-public)  
[CollectifDAO report](https://github.com/collectif-dao/dg-research/blob/main/Lido%20Dual%20Governance%20Simulation%20Report.pdf)

## Appendix A

Below, you will find a list of all deploy parameters. Some of them are related to particular addresses or values discussed above. Another type of value that should be explained is sanity check params. These parameters protect the DAO from accidental mistakes and are based mostly on common sense. They do not allow particular parameters to be set higher or lower than certain values. In cases where we need a value that is higher or lower than the sanity check allows, we will need to redeploy the Dual Governance contract through the DAO process.

_TBD addresses will be filled later_

> UPD 14.05.25 some parameters related to sanity checks and committees were changed; however, **the “main” parameters, whose values were obtained during research, remain unchanged**. Please [proceed to the comments for a more detailed explanation](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/10)

| Parameter | Comment |
| --- | --- |
| [dual\_governance] | |
| admin\_proposer = “0x2e59A20f205bB85a89C53f1936454680651E618e” | DAO Voting |
| proposals\_canceller = “0x2e59A20f205bB85a89C53f1936454680651E618e” | DAO Voting |
| reseal\_committee = “0x0000000000000000000000000000000000000000” | Gnosis Multisig TBD |
| sealable\_withdrawal\_blockers = [ | |
| “0x889edC2eDab5f40e902b864aD4d7AdE8E412F9B1”, | Withdrawal queue |
| “0x0De4Ea0184c2ad0BacA7183356Aea5B8d5Bf5c6e”], | VEBO |
| tiebreaker\_activation\_timeout = 31536000 | 1 year |
| | |
| [dual\_governance.signalling\_tokens] | |
| st\_eth = “0xae7ab96520DE3A18E5e111B5EaAb095312D7fE84” | stETH token |
| wst\_eth = “0x7f39c581f595b53c5cb19bd0b3f8da6c935e2ca0” | wstETH |
| withdrawal\_queue = “0x889edC2eDab5f40e902b864aD4d7AdE8E412F9B1” | Withdrawal queue |
| | |
| [dual\_governance.sanity\_check\_params] | |
| max\_min\_assets\_lock\_duration = 4147200 | 48 days |
| max\_sealable\_withdrawal\_blockers\_count = 255 | |
| max\_tiebreaker\_activation\_timeout = 63072000 | 2 years |
| min\_tiebreaker\_activation\_timeout = 15768000 | 6 months |
| min\_withdrawals\_batch\_size = 4 | |
| | |
| [dual\_governance\_config\_provider] | |
| first\_seal\_rage\_quit\_support = 100 | 1 % |
| second\_seal\_rage\_quit\_support = 1000 | 10% |
| min\_assets\_lock\_duration = 18000 | 5 hours |
| rage\_quit\_eth\_withdrawals\_delay\_growth = 1296000 | 15 days |
| rage\_quit\_eth\_withdrawals\_min\_delay = 5184000 | 60 days |
| rage\_quit\_eth\_withdrawals\_max\_delay = 15552000 | 180 days |
| rage\_quit\_extension\_period\_duration = 604800 | 7 days |
| veto\_cooldown\_duration = 18000 | 5 hours |
| veto\_signalling\_deactivation\_max\_duration = 259200 | 3 days |
| veto\_signalling\_min\_active\_duration = 18000 | 5 hours |
| veto\_signalling\_min\_duration = 432000 | 5 days |
| veto\_signalling\_max\_duration = 3888000 | 45 days |
| | |
| [timelock] | |
| after\_schedule\_delay = 86400 | 1 days |
| after\_submit\_delay = 259200 | 3 days |
| | |
| [timelock.sanity\_check\_params] | |
| max\_after\_schedule\_delay = 864000 | 10 days |
| max\_after\_submit\_delay = 2592000 | 30 days |
| max\_emergency\_mode\_duration = 31536000 | 1 year |
| max\_emergency\_protection\_duration = 94608000 | 3 years |
| min\_execution\_delay = 259200 | 3 days |
| | |
| [timelock.emergency\_protection] | |
| emergency\_activation\_committee = “0x0000000000000000000000000000000000000000” | Gnosis Multisig TBD |
| emergency\_execution\_committee = “0x0000000000000000000000000000000000000000” | Gnosis Multisig TBD |
| emergency\_governance\_proposer = “0x0000000000000000000000000000000000000000” | Gnosis Multisig for Dry run TBD |
| emergency\_mode\_duration = 2592000 | 1 month |
| emergency\_protection\_end\_date = 1781913600 | Sat Jun 20 2026 00:00:00 GMT+0000 |
| | |
| [timelocked\_governance] | |
| governance=“0x2e59A20f205bB85a89C53f1936454680651E618e” | DAO Voting |
| timelock=" \< TIMELOCK \>" | Fills after main deploymen |

---

<div class="post-metadata">

**Author:** ![kadmil](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/kadmil/32/1958_2.png) [@kadmil](https://research.lido.fi/u/kadmil)\
**Post date:** [April 11, 2025, 11:02am UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/2 "2025-04-11T11:02:10Z")

</div>

Massive thank you to Lido Analytics, 20 and CollectifDAO teams putting a lot of work and thought into researching mechanics and charting the “feasibility ranges” for the Dual Governance params!

---

<div class="post-metadata">

**Author:** ![DeuceeDeuce](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/deuceedeuce/32/5577_2.png) [@DeuceeDeuce](https://research.lido.fi/u/DeuceeDeuce)\
**Post date:** [April 11, 2025, 3:03pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/3 "2025-04-11T15:03:47Z")

</div>

Wonderful work by me brothas & sistas at Collectif and 20(twenty). For that, me say thank you for your hard work & dedication ❤

The framework/tools me would like to see, when it comes to designing and improving the parameters, is relate to taking the Human factor out of the decision making for the veto & rage quit parameters.

In the age of AI we should be looking at building an adaptive Veto Threshold Module that is autonomous. Where the module can adjusts veto & rage quit parameters as market conditions shift.

Here’s me thinking (ruff formula), where we create a base threshold and a dynamic adjustment factor:

R1=BaseR1 + f(Price Factor, Volatility Factor, etc.) f = formula placeholder  
R2=BaseR2 + g(Price Factor, Volatility Factor, etc.) g = formula placeholder

Where the fixed starting points are as proposed:

- BaseR1 = 1%
- BaseR2 = 10%

follow by a relative price ratio = P avg/P  
​  
If price ratio \> 1, stETH is trading above its historical average, this signals that stETH is costlier for new stakers to buy stETH to sabotage governance. OTOH, if price ration is \< 1, the cost to buy stETH is cheaper, the DAO can then raise the threshold. The idea is to automate it, no human involvement.

As you know me brothas and sistas, the value of using stETH as a Governance Asset is not the same when market conditions are favourable and unfavourable. Hence, during favoruable market conditions, stETH owners might not get involved, as their assets might be tied up doing what mercenary capital does. Holding 1% or 10% of the total stETH supply is very different when ETH is at 5k vs. 1.5k, for the many Whales that can degen.

Me idea is to stop 🛑 the reliance on the DAO to manually vote, in order to raise or lower thresholds every few months. Instead, let’s use an on-chain or oracle based formula. Because if we keep the human factor in, it will only lead to a bureaucratic stalemate, in me opinion.

Which leads me to the next thought. Does this two-token governance system diminish the value of LDO? We have seen so many platforms, forks, forks of forks, protocols, frontends, and even memecoins that don’t need a token.

And lastly, will this inspire and create an opportunity for activist investors to disrupt Lido DAO alignment? Because if you don’t have DAO alignment, then you don’t have anything.

Bureaucracy is the mother of inertia me brothas & sistas.

One love.  
Respekt.

---

<div class="post-metadata">

**Author:** ![Leuts](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/leuts/32/4427_2.png) [@Leuts](https://research.lido.fi/u/Leuts)\
**Post date:** [April 16, 2025, 7:56am UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/4 "2025-04-16T07:56:38Z")

</div>

Took a while to get through this and the reports.

I have both a million questions and none at all.

After reading through both reports it seems the likelihood of a significant “attack” is extremely low as the requirements and coordination is very challenging.

Regarding new vector attacks → It would take me a lot more time to discern attack vectors. But all of the noted seem very reasonable and low likelihood.  
Regarding the params: The param picks seem good, I ran some very basic numbers. You’ve opted for fitting roughly in the middle of the band which I guess is a good place to start as any! I always think leaning more conservative to start makes sense unless you are trying to balance efficiency and safety like a timelock.

I guess one question:

What is the ongoing process to adjust parameters as both stETH and LDO evolves and changes over time. Will this same process be redone on a regular, albeit slow cadence? Is there live tracking and trigger warnings when/if certain parameters are breached? Monitoring tools used?  
I understands it’s next steps, but curious on the plan. 🙂

Thank you

---

<div class="post-metadata">

**Author:** ![Izzy](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/izzy/32/320_2.png) [@Izzy](https://research.lido.fi/u/Izzy)\
**Post date:** [April 16, 2025, 3:56pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/5 "2025-04-16T15:56:06Z")

</div>

Incredible work by all parties in every way: the scoping of which parameters to assess, how, and the analytical methods used (it was very interesting to see the different approaches), the synthesis of the different suggestions and research results by the analytics team, and the thoroughness of approaches are really exemplary.

---

<div class="post-metadata">

**Author:** ![Greg\_S](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/greg_s/32/1988_2.png) [@Greg\_S](https://research.lido.fi/u/Greg_S)\
**Post date:** [April 17, 2025, 7:16pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/6 "2025-04-17T19:16:57Z")

</div>

Hello, thank you for your ideas. I have several comments (but please remember, I am not speaking on behalf of the DAO—this is my personal opinion):

> > [@DeuceeDeuce](#):
> >
> > In the age of AI we should be looking at building an adaptive Veto Threshold Module that is autonomous. Where the module can adjusts veto & rage quit parameters as market conditions shift.

This is ideally what we would like to have. However, in the beginning, I suppose it will still be a semi-automated process that requires a DAO vote. One of the challenges the “parameter value changing formula” should address is how we can effectively measure the speed of information spread and stETH holders’ reaction time. Both of these factors mostly rely on human behavior. It is theoretically possible to train an AI/ML model to predict this, but currently, we don’t have any data to train such a model. So initially, there will likely be a number of research efforts to understand which factors we should consider and how those factors should influence each parameter.

> > [@DeuceeDeuce](#):
> >
> > Which leads me to the next thought. Does this two-token governance system diminish the value of LDO? We have seen so many platforms, forks, forks of forks, protocols, frontends, and even memecoins that don’t need a token.

This is a tough question, but I lean towards “No.” If we measure the value of LDO by its price, I believe there are many other market conditions that could influence it more significantly. If we measure LDO’s value as a governance token, it still holds value as long as the DAO is aligned with stETH holders. DG (dual governance) diminishes LDO’s value only in situations where the DAO is misaligned with holders—which, in my opinion, is actually healthy for the DAO. I understand this answer isn’t perfect, and I personally see arguments for both “No” and “Yes,” but at least for now, I would say the answer is “No.”

> > [@DeuceeDeuce](#):
> >
> > And lastly, will this inspire and create an opportunity for activist investors to disrupt Lido DAO alignment? Because if you don’t have DAO alignment, then you don’t have anything.

I’m not sure I fully understand the question, but I’ll try to answer from both angles:

**If we’re talking about LDO activist investors:**  
DG reduces such opportunities. Without DG, activist investors only need LDO to create disruptions. With DG implemented, malicious LDO holders have significantly less power to misalign the DAO, because DG reduces LDO’s influence when the DAO is not aligned with stETH holders.

**If we’re talking about stETH activist investors:**  
DG does give these investors the ability to halt DAO decisions. However, if the DAO is aligned with holders, such actions could delay—but not prevent—decision-making. So yes, it could cause temporary halts, but the decision would still eventually be made.

---

<div class="post-metadata">

**Author:** ![Greg\_S](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/greg_s/32/1988_2.png) [@Greg\_S](https://research.lido.fi/u/Greg_S)\
**Post date:** [April 17, 2025, 7:19pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/7 "2025-04-17T19:19:09Z")

</div>

Hello, thank you for your comment.

> > [@Leuts](#):
> >
> > What is the ongoing process to adjust parameters as both stETH and LDO evolve and change over time? Will this same process be redone on a regular, albeit slow, cadence? Is there live tracking and trigger warnings when/if certain parameters are breached? Monitoring tools used?

From part 4.2.2 of the Collectif research, we now understand the boundaries of the stETH holding structure—i.e., where the suggested parameters stop being effective. The low-hanging fruit here would be to monitor the share of stETH held in contracts or known CEX/DEX addresses and to alert when we approach those boundary values.

However, we still need to research which other metrics should be tracked. I suppose we will end up monitoring things like:

- The price of acquiring 1%, 5%, or 10% (these numbers are just examples) of the total stETH supply on the market
- The share of stETH held in contracts / known CEX and DEX addresses
- Entry and exit queue size
- The amount of stETH used in short positions

**This is definitely not a full list, but just some examples.** Additionally, we need to understand how changes in these metrics should affect specific parameters and their values.

Also, I believe that after Lido v3, we’ll definitely need to reconsider the parameter values, as vaults could significantly change the stETH holding structure.

**So, to summarize:**

- **Short term:** Monitor selected market metrics and trigger alerts when we approach conditions where current values no longer hold.
- **Mid term:** Continue alerting, but introduce a framework that defines which parameters should be adjusted and how, based on market changes.
- **Long term:** A fully automated system, where values adjust autonomously in response to market conditions (though I’m not sure this is fully achievable—but we’ll try our best).

Please remember these are just my personal thoughts, and everything is subject to change. But this is how I currently see the next steps.

---

<div class="post-metadata">

**Author:** ![Leuts](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/leuts/32/4427_2.png) [@Leuts](https://research.lido.fi/u/Leuts)\
**Post date:** [April 18, 2025, 9:49am UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/8 "2025-04-18T09:49:34Z")

</div>

Makes total sense, especially regarding how V3 impacts this. People often misunderstand the trade-offs of liquidity.

Thanks for the response and amazing work.

---

<div class="post-metadata">

**Author:** ![Reaktornano](https://avatars.discourse-cdn.com/v4/letter/r/e79b87/32.png) [@Reaktornano](https://research.lido.fi/u/Reaktornano)\
**Post date:** [April 21, 2025, 9:37pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/9 "2025-04-21T21:37:38Z")

</div>

Plus, the goal was never to produce an exhaustive list of attacks and valuations, but rather to understand the main vectors and estimate what the costs of an attack are and how much “damage” it could make.  
Ultimately, making a design that balances makes the cost close to or larger than the damage dealt to reduce the economic sense of such attacks on DG.

---

<div class="post-metadata">

**Author:** ![Greg\_S](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/greg_s/32/1988_2.png) [@Greg\_S](https://research.lido.fi/u/Greg_S)\
**Post date:** [May 14, 2025, 3:41pm UTC](https://research.lido.fi/t/dual-governance-analytics-note-on-parameters-values/9905/10 "2025-05-14T15:41:32Z")

</div>

During testnet, it turned out that some values related to sanity checks and committees needed to be changed. These changes do not affect the main parameters determined through research. Sanity checks are boundaries for certain parameters. Their values do not dictate the parameter’s actual value but rather set limitations for its adjustment. The key point is that adjusting a parameter’s value beyond the sanity check limits would necessitate a redeployment of the entire Dual Governance system. Therefore, we need flexibility within these sanity checks for future parameter adjustments. All changes will still undergo the regular governance process and can be vetoed by Dual Governance. Here is a list of the parameters, their descriptions, and the reasons for the changes:

_max\_min\_assets\_lock\_duration_

- Previous value: 86400 # 24 hours
- New value: 4147200 # 48 days
- Description: This parameter defines the maximum possible time during which a stETH holder will be unable to withdraw stETH from the Veto Signaling contract once stETH has been deposited. Please note that the actual value remains 5 hours; this parameter defines the extent to which the DAO can change it without requiring a Dual Governance redeployment.
- Reason for change: Increased the allowable range for this value to provide more flexibility in case of a large stETH holder rage quit cycle attack (where a malicious actor uses a significant amount of stETH to trigger consecutive rage quits, preventing the DAO from executing proposals). The value is defined as the maximum veto signaling duration (45 days) plus the deactivation duration (3 days). While a 48-day mandatory stETH locking period does not entirely prevent such an attack, it makes it significantly more difficult.

_max\_tiebreaker\_activation\_timeout_

- Previous value: 31536000 # 1 year
- New value: 63072000 # 2 years
- Description: The upper bound for the time the Dual Governance must spend in the “locked” state before the tiebreaker committee is allowed to schedule (execute) proposals.
- Reason for change: The previous 1-year value was equal to the actual value, which did not provide any flexibility for parameter adjustment if the DAO needed it.

_min\_withdrawals\_batch\_size_

- Previous value: 1
- New value: 4
- Description: The minimum number of withdrawal requests allowed to create during a single call of the `Escrow.requestNextWithdrawalsBatch(batchSize)` method.
- Reason for change: Technical optimization; previously, all withdrawal requests were created with a batch size of 1. Now, requests will be packed by 4 per each `requestNextWithdrawalsBatch` call.

_after\_schedule\_delay_

- Previous value: 259200 # 3 days
- New value: 86400 # 1 day
- Description: This parameter defines the time that should pass after a proposal is scheduled. To clarify, in Dual Governance research documents, “Proposal execution” actually refers to “Proposal scheduling.” The process is as follows: after the DAO votes for a proposal submitted to Dual Governance, it waits for the `after_submit_delay` (ProposalExecutionMinTimelock in the documentation). During this time, the proposal can still be vetoed. Once this time has passed and veto signaling is no longer active, the proposal is scheduled for execution. From the DG perspective, “schedule” is equivalent to “execution,” since once a proposal has been scheduled, it cannot be vetoed by DG, but it can still be stopped by the emergency committee (which was outside the scope of the research). Therefore, this parameter effectively defines how much time the emergency committee will have to react.
- Reason for change: The emergency committee is intended for emergency situations (code hacks, day-one bugs, etc.) and will be deprecated in the future. However, this value still affects the overall proposal execution time, so it was decided to lower it. Please note that this parameter does not affect the “stETH holders’ time for reaction,” which was investigated during research.

_max\_after\_submit\_delay_

- Previous value: 864000 # 10 days
- New value: 2592000 # 30 days
- Description: This is the upper bound required for proposal submission. This value allows for changes to the ProposalExecutionMinTimelock within these boundaries.
- Reason for change: Current research indicates that 3 days is sufficient for stETH holders to react, but this parameter allows for increasing this timeframe in the future without requiring a Dual Governance redeployment.

_max\_emergency\_mode\_duration_

- Previous value: 7776000 # 3 months
- New value: 31536000 # 1 year
- Description: This is the upper bound for the time the timelock can remain in emergency mode. You can read about[emergency mode here](https://github.com/lidofinance/dual-governance/blob/develop/docs/plan-b.md). In essence, the initial deployment of Dual Governance allows for switching to emergency mode in case critical vulnerabilities are found, acting as a form of “insurance” that lasts for a defined period.
- Reason for change: This change provides more flexibility for prolonging emergency mode if needed.

_max\_emergency\_protection\_duration_

- Previous value: 31536000 # 1 year
- New value: 94608000 # 3 years
- Description: This is the upper bound for the time the emergency protection mechanism can be activated.
- Reason for change: Similar to `max_emergency_mode_duration`, this change gives the DAO more flexibility should emergency mode be required.

_Emergency\_protection\_end\_date_

- Previous value: 1778878800 # Fri May 15 2026 21:00:00 GMT+0000
- New value: 1781913600 # Sat Jun 20 2026 00:00:00 GMT+0000
- Description: This parameter defines the end timestamp (in seconds since the Unix epoch) for the emergency protection period, during which the Emergency Activation Committee retains its powers.
- Reason for change: Changed to reflect the current Dual Governance release schedule.