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

**URL:** <https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206>\
**Category:** Request for Comment \[RFCs\]\
**Tags:** rfc, governance\
**Created:** [May 8, 2025, 10:41am UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206 "2025-05-08T10:41:56Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![jensei](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/jensei/32/69_2.png) [@jensei](https://forum.summer.fi/u/jensei)\
**Post date:** [May 8, 2025, 10:41am UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/1 "2025-05-08T10:41:56Z")

</div>

**Status:** Request for Comment  
**Visibility:** [@Recognized\_Delegates](https://forum.summer.fi/groups/recognized_delegates) @chrisb @halaprix @0xtucks @Raphael_Anode

* * *

### 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

 ![Lazy Summer DAO_ Governance Flow](https://canada1.discourse-cdn.com/flex009/uploads/summer/original/1X/3f6ee922898b8d61e3ec38dd0315033a45047286.png)

* * *

### 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

---

<div class="post-metadata">

**Author:** ![chrisb](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/chrisb/32/28_2.png) [@chrisb](https://forum.summer.fi/u/chrisb)\
**Post date:** [May 8, 2025, 12:46pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/2 "2025-05-08T12:46:21Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![MasterMojo](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/mastermojo/32/8_2.png) [@MasterMojo](https://forum.summer.fi/u/MasterMojo)\
**Post date:** [May 8, 2025, 12:57pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/3 "2025-05-08T12:57:34Z")

</div>

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 😆

---

<div class="post-metadata">

**Author:** ![jensei](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/jensei/32/69_2.png) [@jensei](https://forum.summer.fi/u/jensei)\
**Post date:** [May 8, 2025, 2:15pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/4 "2025-05-08T14:15:41Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jensei](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/jensei/32/69_2.png) [@jensei](https://forum.summer.fi/u/jensei)\
**Post date:** [May 8, 2025, 2:27pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/5 "2025-05-08T14:27:08Z")

</div>

> [@MasterMojo](#):
>
> My comment is to be careful putting things to vote for on a Friday

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](https://forum.summer.fi/groups/recognized_delegates)

* * *

# Temp. Check:

\*_CET timezone_

_Poll ([view on site](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/5))_

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [May 8, 2025, 2:43pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/6 "2025-05-08T14:43:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![jensei](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/jensei/32/69_2.png) [@jensei](https://forum.summer.fi/u/jensei)\
**Post date:** [May 12, 2025, 2:30pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/7 "2025-05-12T14:30:01Z")

</div>

> [@Raphael\_Anode](#):
>
> Maker had all votes on Monday. Loved that. Super easy for everyone.

Something to consider here (besides the voting) is the permissonless nature of execution of the proposals. After discussion with @chrisb and others, it seem like **Wednesday** could be a good option to make sure that no execution happens during the weekend (in case of emergency troubleshooting).

This way the governance flow would look like:

**Post Tally Vote** → Wednesday  
**Tally Vote Opens for Voting** → Thursday - Friday - Saturday  
**Vote Execution Delay** → Sunday (Base Network) / Monday (Other Networks)

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [May 12, 2025, 3:16pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/8 "2025-05-12T15:16:22Z")

</div>

That would work well! The dependability is key, imo. Massive reduction in cognitive load.

---

<div class="post-metadata">

**Author:** ![techsqrt](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/techsqrt/32/389_2.png) [@techsqrt](https://forum.summer.fi/u/techsqrt)\
**Post date:** [May 15, 2025, 8:00pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/9 "2025-05-15T20:00:55Z")

</div>

I support this.  
How about opening Tally Voting **12h earlier**?  
This would shorten stage: **Post Tally Vote** → **Tally Vote Opens for Voting** from **24h** to **12h**  
and give voting **84h** flexibility (instead of 72h).

It would allow to vote Wednesday night - just in case someone is offline from Thursday this particular week 🙂

---

<div class="post-metadata">

**Author:** ![Raphael\_Anode](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/raphael_anode/32/476_2.png) [@Raphael\_Anode](https://forum.summer.fi/u/Raphael_Anode)\
**Post date:** [May 19, 2025, 9:07am UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/10 "2025-05-19T09:07:26Z")

</div>

Speeding up governance now is a good move. We’ve seen how responsive delegates and team are. We can do this.

---

<div class="post-metadata">

**Author:** ![jensei](https://yyz1.discourse-cdn.com/flex009/user_avatar/forum.summer.fi/jensei/32/69_2.png) [@jensei](https://forum.summer.fi/u/jensei)\
**Post date:** [March 11, 2026, 2:20pm UTC](https://forum.summer.fi/t/rfc-adjust-governance-parameters-reduce-execution-delay-voting-period/206/11 "2026-03-11T14:20:49Z")

</div>


