As per this week’s Governance call (5th March 2020), we discussed a proposal for introducing Spell Expiration. This post will document the thinking behind introducing this change as derived from the Maker Document Spell Expiration Proposal by @Kenton and @brianmcmichael.
tl;dr Add a spell expiration period of one month, so that proposals older than one month will be considered “dis-armed”.
Motivation & Rationale:
Maker Governance uses the DSChief contract as part of an append-only approval voting system. In this system, proposals that lack ratification by the community are still considered active and can be cast at any point in time if they acquire the necessary amount of MKR. Similarly, accidental casts of archaic proposals, such as changing the SCD stability fee to 22.5% as seen in 2019, could become more commonplace. As a result, Community and Foundation members have expressed concern that these previously deployed and un-executed proposals (spells) could be lifted and cast in an unintended sequence, and are therefore a liability to the governance system.
To mitigate this risk as more executive proposals are introduced, we propose an expiration variable be included in the spell, set to one month from the time of introduction into the DSChief. It is important to note that the one month expiration period is an initial proposition and can be revised after community discussion or for individual circumstances of each proposal.
One month was deemed to be a suitable time period for expiry since most of the spells that are cast are expected to be voted upon and scheduled within a week of deployment, this feature will effectively clean up proposals that have not passed a governance executive vote by preventing them from being scheduled at some unexpected time in the future. If the spell becomes stale after 30 days, nothing prevents a new spell with the same parameters from being deployed and submitted for election.
We are adding a public
expiration variable that is checked in the
schedule() function. In units of seconds from Unix epoch, this variable will be hardcoded into the spell for approximately one month after the contract has been added to DSChief. The expiration variable is initialized during contract construction and not when it is added to the DSChief through
vote() - we do not expect much delay between these two actions. If the proposal were to be given the
hat in DSChief,
schedule() would revert if
expiration <= now.
This is a format that would be adhered to and deployed by the Maker Foundation; however, there is no technical restriction against adding non-compliant proposals to the Chief. In terms of backward compatibility this would only apply to new spells that include the expiration variable. Unexecuted proposals deployed prior to the adoption of this standard will maintain their existing functionality and will continue to represent a risk to the system. Keepers which are designed to expect the presence of an expiration variable on a Foundation Proposal will need to be able to handle older contracts in the DSChief that do not include the expiration variable.
In summary, adding vote expiration is an elegant and valuable security addition to Maker Governance that does not require any changes to DSChief. Please signal your agreement or disagreement, knowing that the value of one month can be amended as we evolve Maker Governance.
- I am in favor of implementing vote expiration
- I am NOT in favor of implementing vote expiration