# Set the Governance hotfix execution window to 24 hours

**URL:** <https://forum.celo.org/t/set-the-governance-hotfix-execution-window-to-24-hours/13810>\
**Category:** Governance\
**Created:** [September 16, 2026, 2:00pm UTC](https://forum.celo.org/t/set-the-governance-hotfix-execution-window-to-24-hours/13810 "2026-09-16T14:00:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![pahor](https://avatars.discourse-cdn.com/v4/letter/p/4af34b/32.png) [@pahor](https://forum.celo.org/u/pahor)\
**Post date:** [September 16, 2026, 2:00pm UTC](https://forum.celo.org/t/set-the-governance-hotfix-execution-window-to-24-hours/13810/1 "2026-09-16T14:00:59Z")

</div>

## Context

With [CGP-0175](https://github.com/celo-org/governance/blob/main/CGPs/cgp-0175.md) the Security Council became the hotfix co-approver on Celo L2. The hotfix flow is: the approver multisig and the Security Council both call `approveHotfix`, anyone calls `prepareHotfix`, and anyone calls `executeHotfix` within the execution window that starts at prepare time.

## Proposal

Set `hotfixExecutionTimeWindow` on the Governance contract to 86,400 seconds (24 hours). The window is currently 0, which leaves no time between preparing a hotfix and executing it. A day makes sure an approved and prepared hotfix can be executed, with room for coordination, without letting a prepared payload linger.

- Destination: Governance (`0xD533Ca259b330c7A88f74E000a3FaEa2d63B7972`)
- Data: `setHotfixExecutionTimeWindow(86400)`
- Value: 0

## Why 24 hours

Approvals are collected before prepare, and execution is allowed immediately after prepare, so the window only has to cover the time between those two steps. A day is enough for the approvers and executors to coordinate, and short enough that an unexecuted hotfix expires quickly; once it lapses, anyone can reset the record and both approvals must be given again. It is also the value used throughout the [Governance contract’s](https://github.com/celo-org/celo-monorepo/blob/master/packages/protocol/contracts/governance/Governance.sol) test suite. Nothing changes about who can approve a hotfix.

---

<div class="post-metadata">

**Author:** ![ttghi](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/ttghi/32/12212_2.png) [@ttghi](https://forum.celo.org/u/ttghi)\
**Post date:** [September 28, 2026, 4:06pm UTC](https://forum.celo.org/t/set-the-governance-hotfix-execution-window-to-24-hours/13810/2 "2026-09-28T16:06:26Z")

</div>

@pahor what are next steps to get this into production?

---

<div class="post-metadata">

**Author:** ![Spap](https://sea2.discourse-cdn.com/flex020/user_avatar/forum.celo.org/spap/32/12346_2.png) [@Spap](https://forum.celo.org/u/Spap)\
**Post date:** [October 13, 2026, 4:06pm UTC](https://forum.celo.org/t/set-the-governance-hotfix-execution-window-to-24-hours/13810/3 "2026-10-13T16:06:59Z")

</div>

**With the window at 0, the hotfix path is closed, not merely tight. A fully approved hotfix cannot even be prepared today.**

Thanks @pahor for raising this. I read Governance (0xD533…7972, version 1.5.1.0) at Celo block 79,901,880, then replayed the whole flow on a fork with the window set to 24h:

| call | from | at the block | on the fork, window 24h |
| --- | --- | --- | --- |
| approveHotfix | approver multisig | passes | passes at 3 confirmations, not 2 |
| approveHotfix | Security Council alias | passes | passes |
| approveHotfix | random address | reverts | reverts |
| prepareHotfix | anyone, approvers included | reverts: “Hotfix execution time window not set” | passes once both approved |
| executeHotfix | anyone | needs prepare | passes at +1h, reverts at +24h 1s |

• The window check runs before the approval checks, and it has read 0 at every block I looked at since April 2025. A full CGP alone can set it, so the path cannot open itself.  
• Once open, two seats sign: the approver multisig 0x4182…33d3 (3 of 14) and the Security Council. 0x51a3…f223 has no code on Celo: it is the L2 alias of the Ethereum Safe 0x4092…E112, a 2 of 2 of two 6 of 8 Safes. On an Ethereum fork, its OptimismPortal deposit did arrive as 0x51a3…f223.  
• The multisig still lists 0xFD74…9aba and not 0xC856…77bF, as t/13798 describes.

Same test on other contracts, with the calls to rerun: [The holder of a role is not always the one who executes it: one measured case](https://realspap.github.io/oracle/roles/)

Small suggestion, and a question: would it help voters if the CGP said plainly that prepareHotfix reverts for everyone today, so they read it as opening the path rather than widening it? And is the Council’s L1 deposit step (who submits, which gas limit) written down anywhere I could read?