With CGP-0175 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.
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 test suite. Nothing changes about who can approve a hotfix.
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.
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?