The Celo hotfix path is closed today. Governance.hotfixExecutionTimeWindow is 0, and prepareHotfix checks that value before anything else, so it reverts for every caller with Hotfix execution time window not set, even for a hotfix already approved by both the approver multisig and the Security Council. No hotfix can be prepared or executed on Celo L2 at the moment, and only a full governance proposal can change this. This CGP sets the window to 86,400 seconds (24 hours), which opens the path; it does not widen it.
Flow since CGP-0175: approver multisig (0x41822d8A191fcfB1cfcA5F7048818aCd8eE933d3, 3-of-14) and Security Council (0x51a3a77baF58fef0309452CeaCB09221e556f223, L2 alias of the L1 Safe) each call approveHotfix; anyone calls prepareHotfix, which stamps executionTimeLimit = now + hotfixExecutionTimeWindow; anyone calls executeHotfix while executionTimeLimit >= now. After the limit passes, anyone calls resetHotFixRecord, both approvals are cleared, and the hotfix must be re-approved.
Why 24 hours: approvals are collected before prepare, so the window only has to cover prepare-to-execute coordination. A day is enough for that and short enough that an unexecuted payload lapses quickly. 24 hours is also the value used throughout the Governance test suite. Approver set and thresholds are unchanged.
0xD533Ca259b330c7A88f74E000a3FaEa2d63B7972), setHotfixExecutionTimeWindow(uint256)864000x745407c80000000000000000000000000000000000000000000000000000000000015180See mainnet.json.
Current state (block 80,178,000, Governance v1.5.1.0):
RPC=https://forno.celo.org
G=0xD533Ca259b330c7A88f74E000a3FaEa2d63B7972
cast call $G "hotfixExecutionTimeWindow()(uint256)" --rpc-url $RPC
# 0
cast call $G "prepareHotfix(bytes32)" 0x0000000000000000000000000000000000000000000000000000000000000001 --rpc-url $RPC
# execution reverted: Hotfix execution time window not set
cast call $G "owner()(address)" --rpc-url $RPC
# 0xD533Ca259b330c7A88f74E000a3FaEa2d63B7972 (Governance owns itself; setter is onlyOwner)
cast calldata "setHotfixExecutionTimeWindow(uint256)" 86400
# 0x745407c80000000000000000000000000000000000000000000000000000000000015180
After execution: hotfixExecutionTimeWindow() returns 86400, and prepareHotfix on an approved hash passes.
Fork test: test-cgp-0255.sh forks mainnet with anvil, shows prepareHotfix still reverts after both parties approve, runs the full propose/dequeue/approve/vote/execute lifecycle on mainnet.json, then replays the hotfix flow: approval gating, prepare, execute at exactly the limit, revert at limit+1s, reset after lapse. 43 checks, all passing at block 80,179,966.
Fork replay reported in the forum thread (window set to 24h): approveHotfix passes for the approver multisig and the Security Council alias and reverts for anyone else; prepareHotfix passes once both approvals exist; executeHotfix passes at +1h and at +24h, reverts at +24h+1s. Matches executeHotfix's executionTimeLimit >= block.timestamp check.
Source: Governance.sol, prepareHotfix (window check first), executeHotfix, setHotfixExecutionTimeWindow, resetHotFixRecord.
celocli governance:view --proposalID <ID> -n https://forno.celo.org
Low. One storage write, no new permissions, no change to who approves. The only new capability is the one CGP-0175 already intended: an approved hotfix can be executed. A window too long would leave an approved payload executable longer than needed; 24 hours bounds that, and a lapsed record needs fresh approvals from both parties.