Optimizing Lido On-chain Voting Timelines for Inclusive Governance

[Tane]

Overview

We suggest optimizing Lido’s on-chain voting durations to encourage broader governance participation. The existing 72-hour voting period—split into a 48-hour main phase for Yes and No votes and a 24-hour objection phase for No only—strains contributors. The current process can be found here. Lido DAO Governance

We propose to change it as below.

• Main Phase (120 hours): Tuesday to Saturday
• Objection Phase (72 hours): Sunday to Wednesday

Motivation

• Removing participation hurdles is key to maximizing governance inclusion.
• As # of delegates increases and their various situations from each delegate exist, the DAO should foster an accommodating environment that will bolster overall governance engagement.

Challenges

• Lido’s condensed 2-day voting risks unintended non-participation, while recognizing each on-chain vote is set to start on Thursday and can be found in the calendar. For instance, one can miss an opportunity to vote just because he/she was in a conference and could not check the forum nor voting for 2 days.

• Quorum is often unattained, with 5 of the last 12 on-chain votes failing to pass due to insufficient turnout, which could have resulted from the shorter voting time. This is slowing down the improvement of Lido DAO in an unnecessary way.

• Comparable DAOs like Optimism, Arbitrum and Uniswap allocate more time for proposals, discussions, and voting. Lido DAO doesn’t have to follow what other DAOs do, but it could be indicated that 2 days for on-chain voting is too short especially for delegates who are familiarized with processes in those DAOs.

  • Optimism (detail)
    • (Feedback and Review : 14 days)
    • On-chain vote: 7 days
  • Arbitrum (detail)
    • Snapshot: 7 days
    • On-chain vote: 14 days
  • Uniswap (detail)
    • Snapshot: 5 days
    • On-chain vote: 7 days

Proposal

• Updated voting timeline
  • Main Phase (120 hours): Tuesday to Saturday
  • Objection Phase (72 hours): Sunday to Wednesday
• Though extended voting might decelerate governance and delay execution, expanding from 3 to 8 days appears workable. It is essential to avoid governance processes becoming redundant. On the other hand, having processes that are too short, which leads to revotes, is unacceptable as it causes severe slowdowns. Moreover, even if it doesn’t result in revotes, we have determined that if a delay of a few days increases governance participation, that is sufficiently meaningful.
• As this requires a certain amount of work including redeploying related components (e.g. GateSeal), we suggest merging this change with the dual governance upgrade, planned to be in the next half-year, to minimize the effort involved.

Changelog

• Sep 5, 2024: Changed the Objection phase to 72 hours based on the community’s feedback. Also added a potential timing of this change to be applied.

Let us know if you have any feedback or comments. Alongside other active delegates and contributors, we are looking forward to improving the Lido governance further and providing more inclusive structures where delegates can engage with the governance.

[kadmil]

Wowza, thank you for the proposal! Couple things to note: 1) I’d propose having longer objection phase (7 days total, 4 main / 3 objection); 2) the change in vote timing would most likely require to tweak gateseals timing (read: redeploy some things), so that’s non-trivial amount of work. In general totally support the motion, though can’t orient the timing

[TheDZhon]

Thank you for the proposal!

In my view, voting timings should be revised based on the recently implemented on-chain delegation availability, so aligned on this completely.

However, for the same purpose, I’d suggest extending the objection window duration from 24 hours to 48-72 hours to mitigate the risks of the narrowly coordinated governance vote takeover (see the recent dramatic events chain: Compound Governance Attack Reveals Inherent Vulnerabilities Of DAOs - "The Defiant")

[irina_everstake]

Thanks for the proposal!

Have you considered to increase the main phase to 144 hours, rather than 120? Then in total with the 24-hour objection (or 120 for the main and 48 for the objection) we will have 7 day both for the Snapshot and on-chain, so no confusion for voters at all?

In case we do increase from 3 to 6 days (2 times), I believe to extend for 1 day won’t won’t make a difference.

[ujenjt]

Lido technical lead here. Thank you for the proposal. I fully support this initiative as it addresses a key aspect of improving governance participation across the DAO. Here are a few points I’d like to highlight:

1. Objection Phase Importance: The current 24-hour objection phase is insufficient, especially with larger delegates who may push a proposal through. It’s essential to give token holders enough time to react if they disagree with how their delegated tokens were used. Extending this phase to 72 hours seems like a good balance.

2. Gate Seal Committees: Extending the voting period will also require adjusting the gate seal committees’ reaction time (currently 6 days) to ensure governance processes remain aligned.

3. Practical Considerations: Voting should ideally start on a Tuesday, allowing contributors to finalize any preparations on Monday. Additionally, we should avoid enacting votes late on a Friday to prevent potential operational challenges (following the “don’t deploy on Fridays” rule).

To accommodate these factors, extending the voting duration beyond 3 days would require a total of at least 7 days (to ensure enough time for both objection and enactment during the business week). I suggest structuring the extended voting window as follows:

• Main Phase (120 hours): Tuesday to Saturday

• Objection Phase (72 hours): Sunday to Wednesday

Lastly, with the upcoming dual governance upgrade, it might be worth merging this adjustment with the upgrade, expected sometime in the next half-year.

[azat_s]

This change will definitely require GateSeal redeployment since currently the seal duration is 518400 seconds (6 days). This duration covers a buffer period of 3 days (governance decision-making, coordination, voting script preparation) and the 3-day on-chain vote duration.

If the vote duration is extended to n days, we would need to extend the seal duration to n+3 days to include the buffer period.

Also, worth mentioning that the maximum possible seal duration is 14 days. If we want to extend that, we will have to redeploy the GateSeal blueprint.

[jengajojo]

Thank you for the proposal @Tane I like that this proposal emphasizes the need for inclusivity and broader participation in Lido’s governance by extending voting periods

@ujenjt

• Main Phase (120 hours): Tuesday to Saturday

• Objection Phase (72 hours): Sunday to Wednesday

I’m in favor of this amendment as well as merging this with the upcoming dual governance amendment as opposed to having this as a standalone proposal.

[SEEDOrg]

Definitely supporting this!

The 3 day period wasn’t very flexible on top of the quorum issues. We also stand by prior comments regarding practical considerations, extension of the objection phase and incorporating this update with the Dual Governance one.

[Nneoma_StableLab]

Thanks for this proposal. I support the extension of Lido’s onchain voting period to 120 hours for the main phase and further extending the 24-hour objection window to 72 hrs as suggested above. The current voting timeframe split between the voting and objection phases inadequately accommodates the diverse schedules and commitments of Lido’s new and existing delegates. I think with this we will see less onchain proposals missing quorum, with less need for vote reruns, and a more efficient governance structure overall.

[Leuts]

It makes sense to have a discussion regarding optimizing the governance flow as there is a change in how the DAO will govern & operate.

Typically i’d like to see proposals for adjustments begin rolling out after we have evidence of a need for change, i.e. what implications will the new delegate program actually have and how can we adjust based on that, but, overall it makes sense if there are no concerns with the entire Lido DAO train slowing down. Personally I do find this always concerning depending on the type of proposal. We certainly shouldn’t be optimizing to mimic other DAOs as most have proven to be far less effective than Lido’s current setup. Not reaching quorum often on a 21 day voting period can’t be compared to not reaching quorum on a voting period of 7 days for example as you have 3 opportunities to reach the same speed. Nor should not reaching quorum always be viewed as a bug, but in some instances a feature.

@ujenjt

• Objection Phase Importance: The current 24-hour objection phase is insufficient, especially with larger delegates who may push a proposal through. It’s essential to give token holders enough time to react if they disagree with how their delegated tokens were used. Extending this phase to 72 hours seems like a good balance.
• Gate Seal Committees: Extending the voting period will also require adjusting the gate seal committees’ reaction time (currently 6 days) to ensure governance processes remain aligned.

+1

Overall the suggestions in the comments make sense under the circumstances and without any more information on how the new program is impacting delegates, voters, and the Lido DAO as a whole.

[Tane]

Thanks @kadmil @TheDZhon @irina_everstake @ujenjt @azat_s @jengajojo @SEEDOrg @Nneoma_StableLab @Leuts for your comments. Especially for the core Lido contributors to be aware of the GateSeal related considerations.

After reading all the comments, we would like to incorporate @ujenjt‘s idea, which should be aligned with most of the comments.

• Main Phase (120 hours): Tuesday to Saturday
• Objection Phase (72 hours): Sunday to Wednesday

As @Leuts pointed out, we also wanted to avoid a lengthy voting process that would slow down Lido, and this idea seems to be spot on.

Regarding timing, we agree with merging this change with the dual governance upgrade, which is expected sometime in the next half-year.

As @kadmil responded like below, it turned out to be a burdensome operation.

@kadmil

the change in vote timing would most likely require to tweak gateseals timing (read: redeploy some things), so that’s non-trivial amount of work.

While having an updated voting timeline would definitely enhance governance engagement, we do not see the need to rush this by delaying other developments such as the implementation of the dual governance upgrade.

We have updated the original post by incorporating those changes, but we are still looking forward to feedback from other community members!

[Jenya_K]

Thanks for the discussion, I’d like to add my two cents.

Contributors from the DAO Ops workstream have discussed the idea of extending the voting durations several times, and the conversation usually boils down to two key points:

1. Impact on Decision Speed: Extending the duration from 3 to 7/8 days slows down critical decision-making. While this allows more time for deliberation, it reduces agility in urgent situations.

2. Potential Risk: If low participation isn’t due to the 2-day response window, a longer cycle could delay re-runs and quorum achievement, making governance even slower.

I appreciate @Tane initiative and believe the next step should be to clarify the goals (e.g., increasing security with a longer objection period, increasing active voting participation) and assess the risks.
We should then compare potential voting configurations to find an optimal balance between achieving these goals and minimizing risks. With this clear option and outlined drawbacks, we can proceed to a Snapshot vote. I think it’s realistic to complete this before the next voting slot.

[Tane]

Thanks @Jenya_K for the comment and here’s the note for consideration.

Goals and Desired Outcomes

Through this proposal, Tané aims to achieve two main results:

• Increase active participation in the governance
• Eliminate cases of not reaching quorum due to simple oversights such as forgetting (or being unable) to vote, thereby resolving the slowdown in the governance speed

Problems

• Quorum is often not being reached
  • As pointed out in the original post, 5 of the last 12 on-chain votes failed due to lack of participation
• The 2-day main phase is short enough to easily miss voting
  • It’s much shorter than the ones utilized for other prominent DAOs

Current Discussion Points

Essentially, there’s a trade-off between these two points:

• The longer the voting period, the higher the probability of reaching quorum
• The longer the voting period, the longer it takes to make a single decision, and thus agility decreases

However, prioritizing agility too much can paradoxically decrease agility by not reaching a quorum, so the probability of achieving a quorum should be increased to maximize agility.

Policy for Proposing Voting Period Changes

• As a premise, shorter periods are preferred
• Given that, the period should be extended to the minimum necessary in accordance with the above goals
• The objection phase should not be longer than the main phase
  • Extending the objection phase too much doesn’t contribute to the current objectives
• If the Main phase + Objection phase becomes 10 days or more, it becomes no different from repeating the current vote twice. Under the current system, if a vote fails once and a second vote is immediately held and approved the following week, the total period is 10 days.

Options

		Agility	Voting Participation	Safety
Option1 (Current)	Main: 2d - Objection: 1d	high*	low	low
Option2	Main: 4d - Objection: 2d	high	mid	mid
Option3	Main: 5d - Objection: 3d	mid	high	high

*Even though it technically takes 3 days to pass a vote, due to the inefficient voting participation, currently it takes 5.92 days on average to pass a vote.

We chose these two (options 2 and 3) as desirable candidates, but, if you have a specific reason to pick another option (e.g. 3 days main + 1 day objection) on the table, we are open to discussing it.

Factors

• Agility: This refers to the number of days required for a vote to pass. A higher agility means Lido has very quick decision-making. If it’s low, it delays Lido DAO’s operations.
• Voting Participation: This relates to the number of votes cast for a proposal. High voting participation indicates high engagement in voting activity. If it’s too low, it can lead to decreased decentralization of Lido DAO’s governance and reduced agility.
• Safety: This concerns the length of time available to cast votes against a proposal. If this period is too short, there’s a risk that proposals might pass unintentionally.

[Option 1 (Current)] Main Phase: 2 days, Objection Phase: 1 day

• Agility: High
  • 3 days required for decision-making
  • However, currently, 5 of the last 12 on-chain votes failed due to lack of participation
  • As a result, it’s taking 5.92 days on average to pass a vote
    • Basic voting rules:
      • 3 days are required for a vote to pass
      • Voting usually starts on Tuesday
    • Voting process:
      • If the first vote fails due to lack of participation, a revote is held from the following Tuesday.
      • If a revote passes, it takes a total of 10 days (from the initial Tuesday to Thursday of the following week)
    • Calculation of average days:
      (Cases passed on first vote × days) + (Cases passed on revote × days) ÷ Total number of votes
      = (3 days × 7 times) + (10 days × 5 times) ÷ 12 votes
      = 5.9166… days
• Voting Participation: Low
  • 5 out of 12 votes couldn’t reach quorum
• Safety: Low
  • 1 day is relatively very short for DAO participants to detect any risks and change their votes

[Option 2] Main Phase: 4 days, Objection Phase: 2 days

The main Phase starts on Tuesday and the Objection Phase starts on Saturday, following @ujenjt ‘s comment above to avoid enacting votes on Fridays or weekends.

• Agility: High
  • 6 days required for decision-making
• Voting Participation: Mid
  • With the current voting period being doubled, the participation is expected to increase.
• Safety: Mid
  • Compared to the current situation, both the main and the objection phases are doubled, so safety can be said to have increased

[Option 3] Main Phase: 5 days, Objection Phase: 3 days

The main Phase starts on Tuesday and the Objection Phase starts on Sunday, following @ujenjt‘s comment above to avoid enacting votes on Fridays or weekends.

• Agility: Mid
  • 8 days are required for decision-making
  • About 3 day difference compared to the current actual value of 5.92 days and Option 2
• Voting Participation: High
  • The main phase voting period is 2.5 times the current period
• Safety: High
  • The objection phase is 3 times the current period

Conclusion

Here are the factors to be considered when making a decision.

We propose to take a vote on which option to take from the three listed above, while we prefer option 3, the same as the original proposal, believing that the increased voting participation and safety should be worth an additional 3 days.

• Main Phase (120 hours): Tuesday to Saturday
• Objection Phase (72 hours): Sunday to Wednesday

We are looking forward to receiving comments for further improvement. We will update the original post accordingly based on the feedback on this before moving to a vote.

[cp0x]

It’s great that you started thinking about the quality of voting.
At the moment there are only 3 days to vote for on-chain changes (in many other DAOs it’s weeks).
You made a good proposal to increase the voting period to 8 days.

In my opinion, there should be at least 7 days for this type of voting, since most delegates do not look at new votes every day, but check them on a specific day of the week.
The 8-day voting model allows for all days of the week to be covered and allows as many people as possible to vote.

[zuzu_eeka]

Let me summarize the options currently on the table:

1. Extend Voting Duration (Multiple options)

• 120 hours main phase + 72 hours objection phase:
  • Pros: Increases participation, reduces missed quorum
  • Cons: Slows decision-making, requires infrastructure changes​
• 96 hours main phase + 48 hours objection phase:
  • Pros: Extends participation while being faster than 120+72
  • Cons: Less inclusive than the longer option.
• 120 hours main phase + 96 hours objection phase:
  • Pros: Provides more time for stakeholders to react during the objection phase​
  • Cons: Further delays final decisions, reducing agility​

Big-big drawback for all these options: slow response in the case of emergency

2. Keep Current Duration

• Pros: Fast decisions, minimal complexity, and no additional changes or redeployments are necessary
• Cons: difficulties in gathering a quorum

With the introduction of on-chain delegation and advance voting announcements, reaching quorum may become easier, but this remains to be seen as more data accumulates

3. Merge with Dual Governance Upgrade

Voting timings will change with the Dual Governance release, so it makes sense to discuss duration during that upgrade to avoid making changes twice. Discussions about voting phase lengths can and should happen in the Dual Governance thread

• Pros: ​no additional changes or redeployments are necessary
• Cons: Delays the change until the Dual Governance release, which is optimistically expected in Q1​

Conclusion:

My personal opinion:

1. I don’t see the value in changing the duration of the main phase right now. I would wait to observe progress on quorum collection after the on-chain delegation release. We are currently seeing the first vote with delegation in progress, and so far, it seems to be going better than before. I would review the results from this vote and two further before making a decision on the main phase duration.
   The biggest downside of extending the overall voting duration is that in case of an emergency, the DAO would be forced to wait through the entire vote duration to make an on-chain decision.
2. Regardless of the decision on the first point, I see value in extending the objection phase. Token holders only have 24 hours to object in the event of a governance attack, so I would extend this phase. And at the same time the release of Dual Governance will bring new measures and mitigations against governance attacks.

Thus, the only immediate change I would suggest is to extend the objection phase (e.g., to 3 days) to mitigate governance attacks before the release of Dual Governance. I would defer the decision on extending the main phase until December when we have data from 2-3 completed votes.

[Ignas]

I don’t think the low participation and quorum unmet are solely due to the short onchain voting period. Instead, we should take action to notify people when an onchain proposals go live, like setting alerts or keeping active. I understand it’s tough for those busy with conferences, but the operation team has done a great job managing the community and keeping everyone updated on upcoming proposals.

I agree with @zuzu_eeka that the DAO might be forced to wait out the full voting duration in case of an emergency. What we really need now is to encourage quicker and better participation. Simply extending the voting time may not be the solution.

[Tane]

Thank you for your insightful comments, @zuzu_eeka. We would like to propose the next step based on your comment!

Summary

We appreciate your concerns about the potential drawbacks of extending the voting period, particularly the risk of a slow response in emergencies. While we understand that longer voting periods can hinder agility, we still believe that the current main phase duration of 2 days is too short to ensure adequate participation and quorum achievement and some community members also agree with the point.

Therefore, we believe it is appropriate to find the right option by conducting a Snapshot vote to gauge the community’s stance.
We wanted to reflect the opinions of both side and propose these options below to choose from.

Option 1: Main Phase — 2 days, Objection Phase — 1 day (Current)
Option 2: Main Phase — 2 days, Objection Phase — 3 days (Zuzu’s suggestion)
Option 3: Main Phase — 3 days, Objection Phase — 2 days (Our recommendation)

Option 1 is the current, the options 2 is what @zuzu_eeka proposed as reasonable option, and the option 3 is the shortened version of what was originally proposed at the beginning of the discussion.

We dismissed options with voting periods longer than six days, as they could cause delays in emergency responses. These balanced options should be acceptable even to those who prioritize rapid emergency response.

We welcome further comments and look forward to collaboratively improving this.

---

Below are the detailed comments on the points made in your comment.

Objectives of the proposal

Our primary goals with this proposal are to:

• Safely reach quorum by increasing participation.
• Reduce the burden of continuous governance participation on community members.

We initially suggested options with a longer main phase than the objection phase to align with these objectives.
Also, having enough response time for malicious proposals is another factor to be considered when determining this voting period.

Extending only the objection phase

@zuzu_eeka

Thus, the only immediate change I would suggest is to extend the objection phase (e.g., to 3 days) to mitigate governance attacks before the release of Dual Governance.

We have some concerns about extending only the objection phase:

Development complexity: Adjusting only the objection phase also requires some development work, comparable to changing both phases. It might not be efficient to invest resources in this change separately, especially if it could delay the deployment of Dual Governance.

Security considerations: The risk of malicious proposals passing is influenced by the total voting period, not just the objection phase. This is because we can see if a proposal is malicious or not when proposed. Extending the main phase provides the same amount of time for the community to detect and respond to such proposals from the outset.

Additional benefits of extending the main phase:

• Increases the likelihood of reaching quorum.
• Reduces the participation burden by providing a more flexible timeframe for voters.

In the extreme case when the malicious proposal supporters cast votes at the end of main phase, Lido DAO will have 2 days to respond, which is 1 day shorter than having voting period of 2 days main phase and 3 days objection phase.
However, we believe this 1 day difference is not going to give us more value than those listed as “Additional Benefits of Extending the Main Phase”.

Given these factors, if we consider a total voting period of 5 days, Main Phase: 3 days + Objection Phase: 2 days might be more beneficial than Main Phase: 2 days + Objection Phase: 3 days.

Timing with Dual Governance Upgrade

@zuzu_eeka

Voting timings will change with the Dual Governance release, so it makes sense to discuss duration during that upgrade to avoid making changes twice. Discussions about voting phase lengths can and should happen in the Dual Governance thread

We agree that coordination with the Dual Governance upgrade is important, and we believe it should be proposed in the thread of dual governance after we agree on which option to take.

First, reach a community consensus on the preferred voting period option through discussion and a Snapshot vote. Then, integrate the chosen changes with the Dual Governance upgrade, ensuring a smooth transition without unnecessary delays.

[zuzu_eeka]

Thank you to @Tane for pushing this initiative forward. After careful consideration and weighing different options, I am currently leaning toward the view that 3 days for the main phase and 2 days for the objection seems reasonable. Here’s why I believe the 3-2 option (72 hours main phase + 48 hours objection phase) is the most balanced approach:

1. Extended Main Phase to Encourage Participation: With a 72-hour main phase, we add an extra day compared to the current duration, which should better accommodate diverse schedules and help meet quorum.
2. 2 days Objection Phase: If a vote perceived as malicious appears, I believe contributors, delegates, and token holders would mobilize quickly to vote against it from day one. This means that the main phase would effectively act as an initial objection period. However the 48-hour objection phase, up from 24 hours, provides more time to evaluate the main phase outcomes and to respond to any issues that may arise.

Thus, we seem to have arrived at a feasible option for making an adjustment. I would propose offering two options for the Snapshot vote:
3-2 voting duration (72-hour main phase + 48-hour objection phase) and
keeping the current 2-1 setup (48-hour main phase + 24-hour objection phase).

However, several additional points need to be settled before proceeding:

1. Voting Schedule. A schedule could start voting on Wednesday at 14:00+ UTC, allowing the main phase to conclude by Saturday at 14:00+ UTC, with enactment on Monday at 14:00+ UTC. The main phase would cover Wed-Sat in CET and nearby time zones. The objection phase would span the weekend and a part of Monday, which isn’t ideal as most of the time would fall on the weekend but could also be an advantage: in case of an emergency need to object to a vote, token holders would not be occupied with primary work commitments.

   Unfortunately, with the 3-2 option, I don’t see other comfortable scheduling options: launching over the weekend is suboptimal, starting on Monday or Tuesday would lead to enactment over the weekend, Thursday or Friday start would push even more of the main phase into the weekend, which could impact quorum.

   The on-chain contracts don’t impose a specific schedule for votes and the schedule itself doesn’t need a further vote. But the tokenholders should keep in mind that by choosing the 3-2 option, they are effectively adopting a ‘start on Wednesday, end on Monday’ pattern. This is why I believe it’s important to reach a consensus on this here as well.

   Additionally I want to note, having the enactment on Monday allows for smoother coordinated releases, enabling the contributors to release off-chain or UI components alongside with on-chain enactments and related communications in a cohesive rollout.

2. GateSeal Reconfiguration: Currently, the GateSeal pauses the WithdrawalQueue and ValidatorExitBus contracts for six days, so it would require adjustment to fit this new 5-day voting cycle. This setup would require deployment of a new GateSeal contract and replacement the current one via on-chain vote.
   To determine the optimal GateSeal duration, I propose an initial calculation, pending technical teams and community input:

   • assume 3 days are needed as a buffer to prepare a vote and communications,
   • 3 days for the main phase,
   • and an additional 5 days if a re-vote is necessary in case the first vote fails to meet quorum.

   This results in an estimated 11 days.

Next Steps: If there are no objections to the 3-2 option and an 11-day GateSeal, the proposal will then be put forward for tokenholder voting on Snapshot in the November slot. Following Snapshot approval, an on-chain vote will be held to officially implement the new voting phases and adjust the GateSeal duration.

[Tane]

Thank you @zuzu_eeka for the comment! We appreciate your continuous effort on this constructive discussion, and designing a few critical details, including additional thoughts on the voting schedule with the 3-2 setup, for the Snapshot voting.

We fully support both of the points proposed;

• Voting Schedule: start voting on Wednesday at 14:00+ UTC, ending on Monday at 14:00+ UTC.
• GateSeal Reconfiguration: an 11-day GateSeal duration.

[zuzu_eeka]

Today on one of the calls with Lido technical contributors, during the discussion of the proposal, it became clear that we’ll need a technical research effort to identify what components of the protocol might be affected by this change. For instance, this one came to @George’s mind.

There’s a non-zero chance that the Snapshot vote might be pushed from the November slot. There’s no certainty on this, but consider me waving my hand as a heads-up.