[RFC] Adjust Governance Parameters: Reduce Execution Delay & Voting Period

Status: Request for Comment
Visibility: @Recognized_Delegates @chrisb @halaprix @0xtucks @rspa_StableLab


Summary

This RFC proposes two updates to Lazy Summer DAO’s governance process:

  1. Reduce Voting Period from 5 days → 3 days
  2. Reduce Execution Delay from 2 days → 1 day for all networks

These changes aim to improve governance responsiveness without compromising participation or security.

What’s Changing?

Parameter Current Value Proposed Value
Voting Period 5 Days 3 Days
Execution Delay (Base Networks) 2 Days 1 Day
Execution Delay (Other Networks) 2 Days 2 Days

Note: The governance flow distinguishes between 1-day (Base network) and 2-day (other networks) execution delays.

Motivation

Lazy Summer’s governance has matured, with strong participation from active delegates and clear proposal standards. Reducing friction in the process will:

  • Enable faster execution of vault launches, strategy changes, and reward adjustments
  • Reduce “dead time” between DAO consensus and protocol action
  • Align Lazy Summer with faster-moving governance systems in other high-performance DAOs
  • Maintain a secure and reviewable window (1 or 2 days) for on-chain execution safety checks

A 3-day voting window strikes the right balance between participation and agility (majority of the votes are casted within the first 3 days of the vote publishing), and a 1 day delay provides a sufficient buffer for review before execution on Base Network.

New Governance Flow


Next Steps

  • Collect feedback on this RFC over the next 3 days
  • If there is broad support, a SIP4.X will be created and posted for vote on Tally
  • Subject to quorum and successful vote, the new parameters will be implemented

Let’s make governance more efficient.

–jensei

3 Likes

Strongly support this.

Now we are up to speed with things, and have a proper RFC flow too, I think this is good move as it has started to feel a long time once proposals eventually get to votes.

One thing I’d like to clarify, is the execution delay on other chains…

Right now, the other chain delay is after the base network delay. And I don’t see the Other Networks delay reduced. I would push to also have Other Networks value reduced to 1 day too, so there is a 2 day total from the voting period ending, to execution on all chains (1 day for base)

Thank you for proposing this @jensei

3 Likes

I support this, especially since Delegates might be getting compensation. My comment is to be careful putting things to vote for on a Friday just encase some folks are not around on the weekend :laughing:

1 Like

Yes–I see your point, this can be further improved and I agree that +1 day delay (after Base Network execution) should be enough for any additional checks.

Oh, this is a very good point!

I was already thinking about finding a specific day (during a week) that would be best fit to deploy onchain proposals. This would help with predictability and efficiency of the processes.

Maybe this is something we can explore within the context of delays and the time it takes for an SIP to go through gov. cycle. @Recognized_Delegates


Temp. Check:

*CET timezone

  • Monday (opens for vote Tue.)
  • Tuesday (opens for vote Wed.)
  • Wednesday (opens for vote Thu.)
  • Thursday (opens for vote Fri.)
  • Friday (opens for vote Sat.)
0 voters
1 Like

Voting over weekends leads to quorum misses. Aave had that issue, Maker had it. Reserve had it.

Maker had all votes on Monday. Loved that. Super easy for everyone.

4 Likes