Signal Request: Add Spell Expiration to Proposals

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.

Proposed Solution:
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.

Technical Detail:
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.

Security Considerations:
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

0 voters

1 Like

So I assume that, when this feature is implemented, there’ll essentially be a known (if not fully closed) list of potential proposals that won’t expire, rather than many piling up and up. This would make it much easier to keep track of and mitigate accidentally activating them. Out of interest roughly how many such proposals are there currently?

Also just to be clear, when you say: “If the spell becomes stale after 30 days, nothing prevents a new spell with the same parameters from being deployed and submitted for election.” would this apply only to the spells that have not passed the executive, or would currently ruling executives also expire after 30 days, and so even if no parameters were changed, a new executive would have to be voted in? is a great resource illustrating the number of proposals we have had (approximately 100) and that only 8 of those remain uncast. So yes, the number of proposals that remain that will live on without an expiry will be known and viewable to all. Correct, having the expiry will make it easier to prevent old proposals from accidentally coming into force.

The purpose of my “If a spell becomes stale after 30 days…” statement was to state that there is nothing preventing us making a new spell with the same parameters if we want to give the community another opportunity to vote in something that didn’t pass the first time around.

Once an executive is voted in, it essentially becomes inert because the proposed changes have already been applied to the system and remain in effect until a new proposal is desired by the community.


@Derek thank you for putting this together, I think it is a great step forward!

I’m curious if there has been any discussion about what would be required to enforce this in the DSChief? Is this something being considered for the future?

Thanks @dawson We briefly discussed this alternative, however making the change in the spell itself was deemed more elegant and flexible for the future. If DSChief were to strictly enforce the existence of an expiration variable, we would need additional code which would require a new Chief - to maintain a registry storing the conditions needed to be met in order to propose a new spell.

It appears as though this has become the norm for new executives, and that seems reasonable given the lack of opposition to the idea. Setting this thread up to be closed.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.