Extend Cycles to 21 Dayss
Synopsis
Align JuiceboxDAO's project and governance cycles with 00:00 UTC and extend them from 14 to 21 days.
Motivation
The Juicebox protocol and DAO operations are more stable than they have been in the past, meaning our cycles don't need to be as frequent.
A longer cycle:
- Simplifies DAO operations by reducing the number of transactions which have to be executed.
- Increases the temperature length, giving proposal authors more time to incorporate community feedback.
- Gives the multisig more time to implement proposals, reducing the risk of mistakes.
- Gives the community more time to verify queued transactions, improving trust.
Governance will be easier to follow if fully aligned with 00:00 UTC.
Specification
- Deploy a 4 day edit deadline contract.
- Next cycle, set JuiceboxDAO's project's cycle's duration to 1831227 seconds, and change its ballot to the newly deployed 4 day contract. This cycle is ~21.20 days long and will end on Sunday, September 3rd at 00:00 UTC (2023).
- The following cycle, set JuiceboxDAO's project's cycle's duration to 1814400 seconds (21 days).
- Update the Governance schedule as follows:
#### Governance Schedule
Days 1-5 **Temperature Check**: Sunday 00:00 UTC (8 days)
Days 6-10 **Snapshot Vote**: Friday 00:00 UTC (5 days)
Days 11-17 **Multisig Execution**: Wednesday 00:00 UTC (7 days)
Days 18-21 **Edit Deadline**: Wednesday 00:00 UTC (4 days)
During the slightly lengthened cycle described in step 2, the extra 0.2 days will be added to the multisig execution stage.
Also:
- Update other sections of the governance process accordingly.
- Update the Snapshot settings accordingly.
To keep payouts at roughly the same level: next cycle, increase all ongoing payouts by 50% (per cycle), and decrease their cycle duration by 33% (rounded to the nearest number). See the following table:
| Recipient | Proposal | Current Payout | Current Cycles Remaining | Updated Payout | Updated Cycles Remaining |
|---|---|---|---|---|---|
| Breadfruit | JBP-410 | $12,000 | 7 | $18,000 | 5 |
| Nance | JBP-405 | $11,000 | 4 | $16,500 | 3 |
| Peel | JBP-398 | $60,000 | 2 | $90,000 | 1 |
| WAGMI | JBP-395 | $5,000 | 2 | $7,500 | 1 |
zhape.eth | JBP-394 | $2,000 | 1 | $3,000 | 1 |
0xb045708e396E20071324C1aed2E4CFB90A0764FE (0xBA5ED) | JBP-393 | $8,000 | 1 | $12,000 | 1 |
Risks
JuiceboxDAO's project has payment terminal and controller migrations enabled, meaning the multisig can respond to known vulnerabilities from within those contracts at any time. In the case of an externally identified vulnerability in a non-migratable contract, JuiceboxDAO will not have time to mitigate the risk (as it would presumably be exploited without prior warning), making the cycle length irrelevant.
An increased cycle length may increase risk in a scenario where a vulnerability in a non-migratable contract is internally identified by increasing the amount of time available to leak information or coordinate an internal exploit.
An increased cycle length decreases operational risk by reducing the number of transactions which take place, thereby reducing the likelihood of mistakes.
Synopsis
State what the proposal does in one sentence.
Motivation
What problem does this solve? Why now?
Specification
How exactly will this be executed? Be specific and leave no ambiguity.
Rationale
Why is this specification appropriate?
Risks
What might go wrong?
Timeline
When exactly should this proposal take effect? When exactly should this proposal end?