Dual Governance: Analytic's note on parameters values

Proposals
10

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. 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.
6 Likes