Attributes
- Author(s): @JackALaing
- Implementer(s): @JackALaing
- Category: Governance Upgrade
Summary
Because we can no longer reduce the UnstakingTime as planned in the original version of the DAO Constitution, we should remove the clause that delays upgrades by the UnstakingTime plus one day.
Abstract
A delay on PIPs was included in the Pocket DAO Constitution as a minority protection measure, inspired by Moloch rage quits, to give users the chance to exit the network if they disagree with the upgrade. This was complicated by the fact that the UnstakingTime was set to 21 days for legal reasons (enforcing a use restriction on token purchases), which we planned to resolve by reducing the UnstakingTime to 1h once sufficient decentralization had been achieved.
However, it has come to our attention that a longer UnstakingTime actually helps with protocol security for Quality of Service (QoS) mechanisms that are being worked on by the engineering team. We therefore can no longer reduce the UnstakingTime as we had planned and, if we want upgrades to be executed expeditiously (which may be critical during crises), we should instead remove the upgrade delay.
Motivation
Our relevant motivations are as follows:
- Protect minority interests in the DAO
- Ensure the DAO has the agility to make upgrades when necessary
These goals tradeoff with each other to a degree, however as explained in Rationale below, an upgrade delay is arguably unnecessary to protect minority interests. These rules are therefore significantly sacrificing 2 with less relative positive impact on 1.
Specification
Remove the following clauses from the DAO Constitution:
6.5. The execution of successful PIPs will be delayed by a period equal to the Unbonding Period plus one day, to give Bonded Users time to unbond and exit the network before the upgrade is executed, unless they are responses to MAEEs.
9.4. The App and Node UnstakingTime parameters will be changed from 21 days to 1 hour once Decentralization Day has been achieved, subject to Majority Approval.
Rationale
The formal delay is arguably unnecessary anyway. Upgrades won’t be executed immediately after a passing vote, because there will be a coordination delay in terms of nodes updating to the new version, and before a vote ends there should be a general indicator of the likelihood of the vote passing. As long as you’re able to submit the unstaking tx before the upgrade is executed, your stake won’t be affected by any changes because you’ll already be in the unstaking process.
Dissenting Opinions
TBD
Implementation
@JackALaing will amend the Constitution to remove the specified clauses.
Copyright
Copyright and related rights waived via CC0.