1. Overview:

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

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

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.