Signal Request: Should we have another executive vote regarding the Governance Security Module?

For people that don’t know the background on this, I’d suggest reading up on the gov-sec module tag.

The last executive to activate this failed to pass. There are a number of reasons why that could have been the case, whether it’s because MKR Token Holders didn’t want the gov-sec module activated, or because the bar set by MKR securing the previous executive was too high, or something else.


The basic trade-off for activating the governance security module is thus: Defence against theoretical crypto-economic attacks by a well-funded attacker vs. Defence against technical smart contract issues.

I don’t feel that I’m qualified to judge which of these is more severe. But I’ve heard differing opinions from various people that I would expect to be able to judge the level of these risks, enough so that I am still unsure whether it should be activated.

Personally I’m leaning towards yes, we should activate it with the 24 hour delay. This gives us a minimum level of defence against theoretical crypto-economic attacks while still potentially allowing reaction to a technical issue in the Maker Protocol smart contracts.

Such an attack only needs to happen once for everything to fall apart. Regardless of the relative likelihoods, the severity of such an attack would be very high especially considering we knew about the possibility and voted against mitigating it.

If anyone more able to speak to their judgement of risk here wishes to add their comments, I’d be happy to add them to this initial post.


  • Yes, we should have another executive vote now.
  • No, we should not have another executive vote yet.
  • Abstain (I just want to see results)
  • Abstain (I have no opinion)
  • Abstain (I don’t feel I am knowledgeable on the subject)
  • Abstain (I disagree with the poll options)
  • Abstain (I have a different objection)

0 voters


This poll will close on 20th February 2020 immediately after the Governance and Risk meeting, this will allow time for governance to take into account new information regarding the ‘darkfix vehicle.’

Previous statement: I will evaluate the progress of this request on 18th February 2020. At that time, this poll will either be closed, or extended if there has not been a reasonable amount of participation.

2 Likes

We should activate when @cyrus is ready. Executive votes are garnering 50k+ MKR. That’s a big improvement in security compared to before @MicahZoltu raised the alarm.

3 Likes

@cyrus is definitely one of the people whose input I’d value in making a decision here. I’d also appreciate input from @wouter as he is closer to the technical side of things.

I agree things are looking better in terms of ‘MKR level’ on the hat.

2 Likes

The development team is evaluating a solution that could mitigate the risk that we’re taking in terms of critical bug fixing, when the GSM delay will be set to a non-zero value.

We should be ready to present the results soon. I can discuss this with the team on our planning meeting later today. We can explain the mechanism on the governance call this or next week.

Once we’ve got that one cleared, it would be good to put the GSM activation up for another vote, from my point of view.

9 Likes

Good to know, thanks for sharing!

Definitely yes, we must not allow such severe risks to exist.

Instead of executive vote there should be a poll (Yes/No) and depending on result of that poll there should be executie vote implementing change or nor

1 Like

We could do that, it seems like a bit of an extra step that isn’t entirely necessary in this case. But I suppose it could lead to us bundling the GSM change in with the usual weekly stuff, which might be sub-optimal. What are people’s thoughts?

I think registering a poll is small ‘price’ to pay for keeping governance process transparent. There is a poll for any parameter of a system and winning option of that poll gets added to executive. I do not see reason why make an exception in governance process.

1 Like

This hasn’t been true in the past, not for all parameters. Debt ceilings and the last GSM executive come to mind. The price is approximately two weeks of extra time which, as you say, is a fairly small price.

I also don’t think this harms transparency, so long as everyone knows what is going to happen for any given signal. It is inconsistent though.

Would be good to get some more input on this.

Agree, It does not harm transparency, but harms authority of MKR holders
Introducing change again and possibly again until it passes.

I’m interested in seeing what type of stopgap solution the technical team has in mind.

So I talked to the team. The viability research is mostly done, with positive outcome. We’ll need a bit more time for nailing down the details and getting it in a presentable format which outlines pros and cons, though. We’ll be working on that the coming days and we would present the results at the governance call next week, assuming we can get a 20 min slot on the agenda?

3 Likes

MakerDAO, like it or not, is the defacto federal reserve for decentralized finance. In a space that currently has now locked in around 1 billion dollars of value, this is one of the biggest vulnerabilities that I’ve ever read about. Suffice to say this attack vector could end any confidence in defi for YEARS to come.

3 Likes

With the release of the idea of MetaCoin, this issue has become far more pertinent. Is there any more movement on this? Any more decisions to be made?

Yes, I believe the technical team will be presenting something on Thursday.

3 Likes

A new GSM vote should be had, but not “now”. First, MKR holders should be sufficiently rallied and educated so that the vote has a better chance of passing. Think of a campaign. Another failed vote could cement apathy towards this quite relevant issue, and Maker would be left with the implicit threat for a long time.

Nikolai recently provided new information (at least for me) about Maker’s approval voting system which is not supported by the UI. Attack during transition could be significantly harder if voting UI would expose it.

Since some voters were against enabling GSM (at least short term), to retain option of quickly ‘patching’ the system, UI changes could be discussed first/also.

1 Like

ETH Denver has slowed us down a little bit, but we’ll be posting the thread with the details around the dark fix mechanism by 10am PT.

Since this is closely related to the GSM delay activation, it would be great if we could extend this signal request poll a bit.

As mentioned on last week’s governance call, the foundation dev team will recommend to put up the second executive vote for the GSM activation, and recommend voting in favor of the proposal.

3 Likes

So, it’s now the 18th. Given the recent discussion of the darkfix in the last Governance and Risk meeting and the coming information drop from @Wouter I think it’s reasonable to extend this poll by a short amount of time to allow voters to take into account the new information.

That said, I am aware that we already have consensus for voting on the GSM once again. I don’t believe that a short extension until Thursday 20th February (post governance meeting) will impact implementation time, and it allows another governance meeting discussion and consumption of documentation.

I will update the initial post accordingly.

1 Like