Delaying this week's executive vote (Originally scheduled for June 25, 2021)

Hello everyone!

As briefly discussed in today’s Governance and Risk Call we were considering delaying this week’s executive vote.

After conversations with @Protocol-Engineering and @GovAlpha-Core-Unit we made the call to not post an executive spell this week. The reasons for doing as are as follows:

In short, the change we would be voting on is minimal and not of an urgent nature, so given the other factors, it seems more prudent to bundle the change with other proposals, most likely in next Friday’s executive. The poll that approved the DC-IAM for the PSM-USDC-A Vault delivered expectations that it would be voted on within 30 days of passing the poll stage, and that is still the expectation following this delay.

We welcome any questions and concerns in this thread and my DMs are always open.


we do have a bit of headroom on the USDC-PSM (about 1.2B) so with some luck that will be sufficient :wink:


I am supportive of this particular time, but can we get some guidelines about this kind of thing going forward?

This looks like it’s up to the discretion of GovAlpha whether to provide a competing executive. Any chance we can get some standardized rules for this in next week or two? I don’t personally have a lot of opinion about what they should be, but would like to see rules set in advance.


Very good initiative, weekly spells are too resource intensive ( probably 10% of the dev time). We should have 2 weeks rolling with exceptional spell. You will never find 1 week sprint in any agile project.

Although, we should use more the exceptional spell. I would expect to have one every two months.

There’s no requirement that we do a weekly exec. The vote on this particular change implied that it would be entered into the system within 30 days, so barring any other urgent reasons we’re pushing this back for the reasons mentioned above. Hopefully this will relieve some voter fatigue as well.


@brianmcmichael mostly covered it, but ultimately it’s always up to GovAlpha (or whatever core unit is running governance) to put votes into the front end. In general, we try to package as much into the weekly spell cycle as the Protocol Engineering team can handle. We’re currently in an odd situation where there has been a lot of stuff passed, but we are still waiting back on audits and final reports (Sushi-LPs and RWA vaults to name a couple big ones).

I’ll be open to correction from @LongForWisdom on this part, but the general rule is that we follow the will of the voters and what was committed to during the polling and forum process. When exceptions happen we make a post (like this one) explaining why we made the call we did. It’s hard to get more specific than that because any number of circumstances could cause an item, or even an entire spell, to be delayed. The PE team will not put in anything they are not 100% confident on for the code, and likewise GovAlpha will not force anything to the front end when circumstances dictate a better course of action is available.


The spell has been done for a couple of days, so from a technical perspective it’s a non-issue. There’s a pretty big lift from a bunch of teams, and from MKR holders getting their tokens to bear, to get one of these successfully out the door, so we need to consider the soft factors of pulling all of these resources together for a minimal change.


So I agree with all of that in this case.

Just wondering what prevents GovAlpha from simply not allowing a vote on something they don’t like? Or if there’s a controversial executive that’s not passing and they don’t want to put another one out to compete with it?

I get that there’s always the human factor and the ability to go rogue, but seems like there should be some rules about how this is decided. And I’d prefer to find out now when it doesn’t matter than in the future when it might.

Do you have a time estimate on how long it takes you to do the spell + testing + check list etc … Plus check after the executive pass?

Nothing. Mandated actors have always reserved the right to hold a red card veto against changes that are believed to be dangerous. Governance could then signal to have the mandated actor removed if the behavior became problematic or recurrent.

To be clear though, that’s not happening here, the PSM change will go into a future executive according to the guidelines described in the poll.

1 Like

Uh… how could governance remove a mandated actor if that actor could prevent that from happening?

Seems like a bug. Surely that’s not the intended structure?

This is the correct answer.

While I appreciate the desire to lock this down (so to speak) we’ve seen in the past that having rules that are too strict can cause more harm than good.

The general rule is that the Governance Facilitators (note this is not limited to GovAlpha facilitators) determine the contents of the weekly governance cycle (which includes the executive vote) and allow other mandated actors veto + inclusion rights within their domain of expertise.

Someone needs to make this determination, because there is often not a ‘correct’ answer - stuff gets delayed, governance can vote for conflicting outcomes, urgent / emergency processes displace non-urgent and non-emergency processes. This is true even if you attempt to implement fixed rules because there will always be a situation that breaks them, and in that situation some entity / group needs to have the authority to decide how to move forward.

That said, I’m aware of the issues that ambiguity can cause as well, which is why each poll contains an outcomes section that clearly explains what the outcome should be to MKR Holders. If that outcome is not met, then they can and should make an issue of it.

In this case the outcomes section reads:

Note that the 30 day clause was specifically added because at some point in the past, an outcome had stated ‘this will be included in the next executive’ and due to some combination of circumstances that wasn’t possible - so I adjusted the default outcome text to allow us more flexibility in the future.

TL;DR: Flexibility is good in this case. If a Governance Facilitator is viewed as malicious due to the misuse of this flexibility, they should be removed as soon as possible.


Violently (so to speak.) If a mandated actor does not want to go quietly, it will get messy. Unfortunately there is no way to avoid that.

To be clear, if governance put up a MIP to remove a mandated actor, Governance Facilitators aren’t going to let the actor in question veto it. The only real issue takes place when the Governance Facilitators go rogue themselves. And even in this case is covered here: MIPs Portal

A governance facilitator emergency vote encodes one or more website URLs into an on-chain voting contract (spell), as well as containing logic that stops any payment stream to the existing governance facilitators. If the executive vote gets the most MKR votes and becomes the active proposal the existing Governance facilitators are then removed. The list of website URLs then corresponds to a list of one or more new Interim Governance facilitators and their governance platforms that will replace the current governance facilitators. The current governance cycle is canceled, and the new Interim Governance Facilitators initiate a new governance cycle on the following 1st Monday of the month.

Anyone is able to create an on-chain executive vote with the above properties, and there is nothing an existing Governance Facilitator can do to stop it getting voted on.


Most executives are able to pass with roughly 75k MKR, which is a small minority of the outstanding supply. In addition to the reasons stated above by @LongForWisdom, you might consider this part of the system’s checks and balances against a minority governance attack.

Well it’ll be nice if we can add some new PSMs at the same time as adjusting the USDC PSM parameters and DC.

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