# \[SIP4.3\] Extend the Voting Period to 7 Days

**URL:** https://forum.summer.fi/t/sip4-3-extend-the-voting-period-to-7-days/908
**Category:** Summer Improvement Proposals \[SIPs\]
**Tags:** governance, sip4, security, voting
**Created:** [August 7, 2026, 2:00pm UTC](https://forum.summer.fi/t/sip4-3-extend-the-voting-period-to-7-days/908 "2026-08-07T14:00:57Z")
**Posts on this page:** 1
**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: [August 7, 2026, 2:00pm UTC](https://forum.summer.fi/t/sip4-3-extend-the-voting-period-to-7-days/908/1 "2026-08-07T14:00:57Z")

</div>

### 1. Overview:

Extend the governance voting period from **3 days to 7 days** , leaving the voting delay and timelock queue unchanged.

| Parameter | Current | Proposed |
| --- | --- | --- |
| Voting delay | 86400 (1 day) | unchanged |
| **Voting period** | **259200 (3 days)** | **604800 (7 days)** |
| Timelock queue (`minDelay`, all chains) | 86400 (1 day) | unchanged |
| Satellite execution | +1 day | unchanged |
| Quorum | 30% | unchanged (SIP4.2) |

**End-to-end:** 1 day delay + 7 days voting + 1 day queue = **9 days** on the hub, **10 days** including satellite relay, compared to 5 and 6 days today.

* * *

### 2. Motivation:

**Review capacity is shrinking; scrutiny time should grow to compensate.** The Labs Co. is winding down, BA Labs has stepped down as risk curator, and the [Summer.fi](http://Summer.fi) UI sunsets on 31 August 2026. SIP4.2 raised quorum to 30% and the proposal threshold to 100,000 stSUMR on the reasoning that safeguards should track the protocol’s risk profile. The same reasoning applies to time: the DAO is moving to a caretaker posture where proposals are reviewed by a smaller set of delegates, less continuously.

**The voting window is the right one to extend.**

- It is where scrutiny actually happens. Delegates read, discuss and vote during this window. The queue is a passive wait that nobody monitors by default.
- **Three days is tight for a 30% quorum** once delegates disperse. Seven days guarantees every proposal stays open across a full calendar week (surviving weekends, holidays and part-time attention) and should _reduce_ failed-quorum risk rather than add friction.
- **Extending the queue instead would compound across chains for no extra review.** Every satellite action already passes the hub’s full voting and queue windows before being relayed; the satellite leg is pure execution of something already approved. A 7-day queue on all chains would push cross-chain execution to 20 days while adding no window that anyone is actually watching.

> A guardian can cancel a proposal directly on Governor V2. Extending the voting period widens the window in which a problem is _noticed_; the cancel path is what allows it to be _stopped_.

**Nothing remaining is time-critical.** No Ark onboarding, no rebalancing, no emissions tuning. Withdrawals are permissionless ERC-4626 redemptions unaffected by any governance parameter, and emergency pausing runs through the Guardian Module rather than a vote, so this does not slow incident response.

* * *

### 3. Specification:

The Governor’s clock is timestamp-based (`SummerToken.clock()` returns `block.timestamp`; `CLOCK_MODE()` returns `mode=timestamp`), so `votingPeriod` is denominated in **seconds**.

| Parameter | Value |
| --- | --- |
| Function | `setVotingPeriod(uint32)` |
| Target | `SummerGovernorV2` (Base) — `0x4cEeE1b6289624d381383C1Bb42B118d5f2c3274` |
| Value | `0` |
| Argument | `604800` (7 days) |
| Selector | `0xe540d01d` |
| Calldata | `0xe540d01d0000000000000000000000000000000000000000000000000000000000093a80` |
| Authority | `onlyGovernance` → executes via the Timelock |
| Risk level | Low (single settings update; no funds move, no role changes) |

Proposals are created and voted on exclusively on Base; satellites are execute-only, so no satellite calls are needed.

* * *

### 4. Risk Assessment:

- **Technical.** One settings update on an OZ `GovernorSettings` extension. No funds move, no roles change. The clock unit is confirmed as seconds, removing the only real encoding risk.
- **Reduced agility.** Proposal-to-execution moves from 5 → 9 days on the hub, 6 → 10 days cross-chain. Acceptable given nothing remaining is time-critical, and emergency response does not run through governance.
- **In-flight proposals.** Applies to proposals created after execution; open votes keep their original schedule.
- **External expiry constraint.** Actions with short external validity cannot survive governance delay at all — Merkl claims, whose proofs expire in ~4 hours, are the live example. These must be structured as governance-approved authorizations executed by a fast actor.
- **Reversible.** A future SIP can restore a shorter period.
- **No effect on user funds.** Withdrawals are permissionless and ungated by governance parameters.

* * *

### 5. Voting:

> If **YES** - extend the voting period from 3 days to 7 days.

> If **NO** - keep the voting period at 3 days.

* * *

Tagging [@Recognized\_Delegates](https://forum.summer.fi/groups/recognized_delegates) for review as always.

–jensei