Hello, this is the Analytics workstream. In this post, we would like to summarize the research done by 20[ ] and CollectifDAO on Dual Governance parameter values and give our recommendations for the next steps.
TL;DR
The Dual Governance mechanism relies on parameters whose values should be chosen before deployment. This note summarizes research done by external research teams: 20[ ] and CollectifDAO. 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. Value parameters used in the research were taken from this mechanism description. 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. 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”:
- 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.
- Allow for the possibility of negotiation and de-escalation between stETH and LDO holders.
- Introduce an extended timelock on DAO decisions that can be triggered by an active minority of stakers and prolonged as more stakers participate.
- Improve foot voting efficiency by allowing stakers to exit the protocol without being subject to new and pending DAO decisions.
- 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:
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
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
Reseal Committee
Tiebraker Committee
Research Overview
20[] report
CollectifDAO report
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 and the 20[] report.
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.
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)
Simulation was tested in several clusters representing goals of Dual Governance implementation (Chapter 2, Chapter 3.3), 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)
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:
- Protection of (w)stETH holders and arbitration vehicle
- Avoiding new vectors of attack introduced through the dual governance mechanism
As well as Parameters choice and tradeoffs 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 ), which could lead to prolonged protocol halts or harmful proposals being pushed through.
CollectifDAO:
- Simulated scenarios provided in the GitHub repo 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 Impact of Wallet Distribution Assumptions Notebook, starting from an R1=0.75% veto threshold, the number of wallets that could support coordinated attacks drops significantly
- From Cluster A - 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 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., Impact of Slow Actor Reaction Assumptions Notebook, 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:
- 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)
- 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)
- 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)
- Increase transparency of proposal impacts to deter malicious influence and enhance stakeholder trust in the system (4.3.3)
- 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)
- Evaluate timelock durations periodically to ensure they align with evolving token holder dynamics and governance requirements (4.2.2, 4.3.2)
Next steps
- 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) and/or stETH holder reactions.
- 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
-
Both of research show:
- DG allows stETH holders effectively participate in Governance
- Does not introduce significant new attack vectors
- Requires monitoring of distribution/market/ecosystem to update parameters as needed
- The parameters we chose work as expected under a variety of conditions
-
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, Link 2, Link 3), 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. 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.
-
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 and CollectifDAO team for their extensive and thorough research efforts.
Links
Dual governance proposal
Mechanism design
20[] report
CollectifDAO report
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
| 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 = 86400 | 24 hours |
| max_sealable_withdrawal_blockers_count = 255 | |
| max_tiebreaker_activation_timeout = 31536000 | 1 year |
| min_tiebreaker_activation_timeout = 15768000 | 6 months |
| min_withdrawals_batch_size = 1 | |
| [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 = 259200 | 3 days |
| after_submit_delay = 259200 | 3 days |
| [timelock.sanity_check_params] | |
| max_after_schedule_delay = 864000 | 10 days |
| max_after_submit_delay = 864000 | 10 days |
| max_emergency_mode_duration = 7776000 | 3 months |
| max_emergency_protection_duration = 31536000 | 1 year |
| 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 = 1778878800 | Fri May 15 2026 21:00:00 GMT+0000 |
| [timelocked_governance] | |
| governance=“0x2e59A20f205bB85a89C53f1936454680651E618e” | DAO Voting |
| timelock=" < TIMELOCK >" | Fills after main deploymen |
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.