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.