MIP26: DssGov - Governance Contract Redesign

MIP26: DssGov - Governance Contract Redesign

Preamble

MIP#: 26
Title: DssGov - Governance Contract Redesign
Author(s):  Smart Contracts Domain Team
Type: Technical
Status: conception
Date Proposed: 2020-10-06
Dependencies: 
Replaces: DSChief

Sentence Summary

This MIP defines DssGov, a contract replacement for DSChief that comes with improved security, usability and functionality for holders of the Maker governance token (MKR).

Paragraph Summary

The Governor Contract, or DssGov for short, is a Dai Stablecoin System Contract that authorises Maker governance to make changes to the Maker protocol by supporting on-chain proposals. Unlike the existing DSChief, DssGov introduces security enhancements to prevent flashloan actions, usability improvements to enable multiple concurrent executive votes, as well as delegation functionality to allow holders to delegate their vote. This contract will also support integration with Layer 2 solutions to enable off-chain vote participation.

Executive Summary - the proposed DssGov contract supports:

  • Multiple concurrent proposals
  • A threshold that must be exceeded for proposals to pass
  • Delegation
  • Flashloan risk prevention

The technical complexity and impact of this MIP is considered HIGH due to it being a critical part of the Maker protocol.

Motivation

This Maker Improvement Proposal initially stemmed from a need to make the existing governance contract more secure and user friendly, however it quickly became apparent that a new contract must also introduce additional functionality such as delegation to meet community needs and ecosystem evolution.

For a summary of the existing Governance system please refer to the Governance Chief Contract Redesign: A Pre-mip Discussion and the Chief - Detailed Documentation for a detailed view of the DSChief smart contract.

From a security perspective the above pre-MIP discussion revealed a number of motivations for change, including:

  • The current governance contract implementation is exposed to transition risk when moving votes from one proposal to another because a reduced amount of MKR could be used to elect a random (and potentially malicious) proposal.
  • When a new proposal gains a majority of MKR, the action of lifting a new hat is not an automatic/instant action, meaning that alternative proposals can sneak in to introduce unexpected changes.
  • Stray spells can exist without expiry, potentially posing an ongoing threat to the system.
  • There is no pause duration between user lock/free actions leading to a potential flashloan risk.
  • Migration risk when moving to a new Chief contract (such as DssGov), where authority must be transferred which introduces a coordination problem to ensure that there is enough MKR on the new contract’s hat while also ensuring there is enough MKR in the old chief to pass the proposal.
  • MKR distribution across proposals potentially weakens the current HAT and exacerbates the above transition/migration risks.

From a usability perspective, motivations include:

  • That the current system is only able to support a single executive at a time which is unmanageable and doesn’t scale with the addition of more collateral types and risk parameters.
  • That the use of the hat mechanism (the transition from one proposal to another) would not allow multiple concurrent proposals to exist.

Discussion of the above, also introduced motivations for additional functionality:

  • Support for Layer 2 integration to facilitate off-chain voting and reduce/eliminate rising gas costs
  • Support for Delegation thereby allowing users to help secure the system even through they may not be weekly participants

Taking the above motivation as inspiration, it is evident that much of the complexity stems from the existing hat paradigm. Rethinking this design gives the Maker community an opportunity to explore more secure and usable methods of governance.

Specification

The new design utilises a threshold mechanism that, alongside snapshotting, enables multiple concurrent executives as well as support for delegation and protection against flashloans. These features and capabilities will be described in the specifications below.

MIP26c1 Utilizing a threshold that must be exceeded for a proposal to pass

This new design uses a variable threshold based on the amount of active MKR locked in DssGov. This threshold must be exceeded in order for a spell to be cast and make protocol changes. This is a departure from the Hat paradigm currently used, which requires users to shift their MKR from one proposal to another. In addition to the security motivations mentioned above, this design improvement also allows for the support of multiple concurrent proposals once voters have locked their MKR in DssGov.

It will be the responsibility of governance to define the threshold as a percentage of the amount of active MKR locked in DssGov. This value will be a percentage value as opposed to an absolute number because a fixed number may introduce an unreachable amount causing the system to cease to function if that value is unable to be reached.

Voter engagement in 2020 illustrates the following levels of participation:

Further risk analysis and research will be conducted to determine the correct threshold level, however initial review indicates that a level higher than 50k MKR would have been sufficient for all but one of this year’s executive votes. This design is also considering an upper boundary to the threshold to prevent accidental locking of the system if an unattainable level were to be set. This would be a constant value and if included would be voted on by Governance when accepting the design.

The concept of a threshold introduces the need to ensure that the MKR in DssGov is ‘active’ MKR, i.e. not stale or forgotten MKR which is something expanded upon below.

MIP26c2 Using active/inactive MKR to define the threshold

Due to the threshold relying on the amount of active MKR locked in DssGov, it becomes necessary to ensure that the locked MKR is not old, forgotten, or lost. This is important to prevent the “stale” MKR from skewing the threshold value and make it impossible for actual participating MKR to reach the required numbers to pass a proposal.

If MKR has remained inactive for a period of time as defined by governance it will be considered stale and will no longer count towards the total active amount of MKR. It is expected that this period of time will be defined as a number of weeks or months pending further analysis. Inactivity can be influenced both by the inactivity of the owner, and if the owner has delegated their MKR, then also the inactivity of the delegated address. Both periods of inactivity can have different time values as defined by governance.

It is expected that the period at which a delegate becomes inactive will be much shorter than the point at which an MKR owner becomes inactive. This is to ensure that delegates are acting in the interest of the MKR delegated to them, while the MKR owner doesn’t have to interact with the system as often to confirm their continued involvement.

If a delegate becomes inactive this means that the voting rights delegated to them will also become inactive and likewise no longer count towards the total active amount of MKR (which influences the threshold calculation). If however a delegate becomes active again after being inactive, they can reactivate the MKR delegated to them unless the owner has since removed their delegation.

Inactivity of an owner means that their delegation will be removed from any delegated address. In the event that an owner’s MKR becomes inactive, it will be possible for the MKR owner to return the MKR back to their original account as a separate transaction. Alternatively, they will be able to delegate once again if desired.

The ability to make a user’s MKR inactive is made possible through the following gas mint/burn mechanism explained in the next section.

MIP26c3 Mint/burn function to facilitate accurate counting of MKR balances

When an MKR owner locks their MKR in DssGov, they will be minting a gas token. This gas token will allow any bot or altruistic participant to remove that user’s MKR from the total amount of active MKR if it becomes stale. Due to the existence of the gas token there will not be any cost to a bot/altruistic user for undertaking this action, which will maintain a fresh state for the threshold to reference.

Minting a gas token occurs in two instances:

  1. When an owner delegates to themselves or to a delegate address they will be minting a gas token and,
  2. When a delegated address begins its period of activity it will also mint a gas token.

These operations will ensure that it is possible for third parties to unwind inactive MKR from the system. Keeping the protocol updated with the correct amount of active MKR is not only important for managing the threshold, but also for a new function that we will introduce now, called snapshotting.

MIP26c4 Using snapshots to record MKR account balances participating in governance

Snapshotting is the process of calculating MKR account balances locked in DssGov at the point in time that a proposal was created. The system will therefore only allow that maximum amount of MKR recorded at the time of the snapshot to vote on the respective proposals.

If a user adds or removes MKR after a proposal has been created, the amount of MKR recorded as part of the snapshot will not be altered for those proposals. Future proposals will use a new snapshot that will record a new MKR balance calculated at the time of the proposal’s creation.

Snapshotting is important because it eliminates the gas intensive nature of unvoting MKR from old proposals to vote for new proposals. This mechanism coupled with the threshold optimises user governance interaction with the protocol. In order to make this solution function correctly, it is important to know that in the background there are two explicit snapshots:

User Action Snapshot - captures the amount of voting rights a user has since they made their last action. An action could include any kind of change in their voting rights; locking, freeing, delegating their MKR, or having their MKR declared inactive due to it not being used as per MIP26c3 (the mint/burn function).

Proposal Creation Snapshot - records the total active MKR amount in DssGov at the moment of proposal creation based on the user action snapshots. This value will be used to determine the threshold and quorum values. It is not possible for the proposal creation snapshot to record all user voting rights in one go - as one might do with a traditional database, instead it must reference the user action snapshot to check the user’s corresponding voting rights.

MIP26c5 Supporting multiple proposals

Although multiple concurrent proposals are made possible through the aforementioned threshold and snapshotting mechanisms, it is worth calling this out independently as a new capability because it is the main pain point for governance participants today. Currently, users are unable to participate in multiple concurrent proposals without locking/freeing MKR from one proposal to another as part of the continuous approval voting system.

This redesign removes the need to shift MKR weights and also eliminates the need for bundling proposals as users will be able to interact with multiple concurrent proposals. As previously mentioned, these proposals will only pass if the amount of MKR in the snapshot exceeds the defined threshold.

The voting experience retains the existing ‘yes’ voting in support of a proposal, where there is no explicit ‘no’ vote. This again reinforces the importance of the threshold. This design decision has been chosen to facilitate faster voting. An alternative design would require a voting window in which yay/nay votes would contribute towards an outcome at the end of a time period. Such a time period of e.g. 3 days would prevent quick changes to risk parameters, as such the time-window solution along with the use of explicit ‘no’ votes was dropped in favor of continuous approval voting.

One can imagine the frontend implementation surfacing multiple proposals, each of which can now pass on their own independent merit. These proposals will continue to function as part of a continuous approval voting process that now references the amount of MKR in a users account at the time of snapshotting. The system will continue to use spell expiry limits and system pauses as implemented today, which will be covered further below.

MIP26c6 Delegation

Delegation is the process of enabling another individual to vote on the owner’s behalf, whereby they are given voting rights in MKR weight, while the owner retains custody of the MKR tokens and is free to transfer them at any time. At a high level the user will lock their MKR in DssGov and either vote themselves or delegate to another address as shown below:

This mechanism ensures that tokens do not rely on the security of third party delegation addresses, including Layer 2 solutions that may want to participate as a delegate. Locking and delegating directly from the Chief contract is a safe way to participate in delegation as tokens can only ever be returned to the MKR owner’s address.

This solution does not allow delegates to forward delegated votes to other addresses. This design decision was made due to the complexities of recording voter balances and changes across a hierarchy of potential delegates.

It is worth mentioning that snapshot rules also apply for delegates. Therefore, if a user delegates their MKR to another address, a snapshot will be created that a proceeding proposal will reference as part of it’s MKR calculation. This will ensure that the delegate is able to vote with the correct amount of MKR weight given to them.

Although the snapshot capability will not let an MKR owner vote for a proposal if they have delegated their MKR to another address, governance is always able to remove (drop) a prior proposal if it is deemed malicious by creating a new proposal which will not have a delay.

Note: it will not be possible for delegate addresses to stake (and burn) MKR through the Emergency Shutdown Module. Delegate addresses would however be able to participate in a governance vote that chooses to shutdown the system through normal governance voting that goes through the standard system delay (like any other governance executive).

MIP26c7 System pauses

In the existing design, Maker requires delays to protect itself from ecosystem risks and attacks. Currently the Maker protocol relies on a 12hour delay between the time a spell is passed and when it takes effect. Similarly, the new design will rely on an executive (GovExec) with a 12hour delay to pass proposals.

However, if proposals are deemed malicious, governance can vote on a zero delay spell to cancel a previously actioned proposal. Likewise, proposals can also be created to protect against malicious variables, auction and oracle attacks with zero delay. This is illustrated below:

MIP26c8 Flashloan Protection

The advent of flashloans allows individuals to borrow large sums of cryptocurrency and action multiple transactions within a single block without having to post any collateral. This problem has become more evident as liquidity pools have formed around governance tokens including MKR. Flashloans are prevented by ensuring that a user’s snapshot will always be at least one block older than the proposal’s snapshot.

Similarly, proposal creation avoids flashloan risks by requiring the locking of a small amount of MKR as detailed in the following section.

MIP26c9 Decentralizing the submission of proposals

To promote decentralization yet protect the system against spam proposals, it is necessary to approve certain known addresses, such as domain teams, governance facilitators and other governance mandated actors, yet still allow all other addresses to submit proposals provided that they hold a defined amount of MKR in their account to prevent spamming.

With this feature it will be possible for approved addresses to post proposals as needed. For all other addresses, a Governance defined amount of MKR from the submitting address will be held as a bond to prevent the submission of spam proposals. Once the defined duration has elapsed, the MKR bond shall be returned to the user’s address.

Currently, no punishment has been defined for the staked MKR in the event a malicious proposal is posted. The governance community should explore whether an explicit mechanism is deemed necessary. Currently it is only possible to drop (remove) a malicious proposal by voting on a proceeding executive. The locking up of MKR when creating a proposal is however useful as previously mentioned to prevent the use of flashloans and the creation of multiple spam proposals.

MIP26c10 One time defensive quorum to migrate from DSChief to DssGov

Transition risk surfaced as a key security motivator in the current design of the DSChief, not only when transitioning to a new proposal but also when transitioning to this new version of the governance contract and the executive proposals that it will generate.

Therefore, to ensure a smooth transition from DSChief to the New DssGov a minimum quorum will be used as a one-off defensive mechanism that protects the protocol by only enabling DssGov if the minimum quorum is exceeded. For the transition, Governance will elect a spell in DSChief which will give authority in all core contracts to DssGov and will also remove the DSChief authority from them. It is at that point that the transfer to the new governance contract will be complete, however the new DssGov will not be able to generate proposals until enough MKR has moved to it. This should be set relatively close to the existing Chief’s Hat value in order to confirm that we have buy-in from the Maker Governance community.

MIP26c11 Layer 2 Integration

DssGov is being built independently and decoupled from any particular Layer 2 solution. Even though a Layer 2 solution is not part of this MIP, it warrants being mentioned as a capability that will be supported through DssGov and associated features. This will provide an ideal opportunity for governance voters to vote and/or delegate to an off-chain address while reducing their exposure to gas cost fluctuations.

MIP26c12 3rd party audits and formal verification

No audit or code review has taken place yet. DssGov will however undergo 3rd party audits and formal verification prior to an executive vote for use by the Maker Protocol.

MIP26c13 Licensing

AGPL3+

25 Likes

Excellent work!

1 Like

Can I delegate to more than one address? For example, I might split my voting weight 50/50 between two of my favorite community members?

I’m not sure if this would be a feature in demand, but at least the spec should be clarified.

1 Like

Hi Joshua, in this iteration it is not possible to split your voting weight across multiple addresses. This would require some additional complexity in the form of an intermediary contract to handle the internal accounting logic to determine a % split across addresses. It is certainly something that could be added later as a capability in addition to DssGov once it has been deployed.

5 Likes

Unless I’m missing something, this can easily be achieved by distributing one’s MKR over 2 separate addresses to begin with?

Not sure if the complexity of implementing this as a feature will ever be worth the minor improvement in convenience. And if it were implemented, this may well be how it would happen behind the scenes.

6 Likes

Yes, exactly - the owner could distribute their MKR across two (or more) addresses and then delegate from those addresses as a manual solution to the problem.

4 Likes

I don’t know if it is the right place to raise it. But if a change is done, it is an opportunity to remind the need for a registry to makerdao smart contracts that is controlled by the MakerDAO governance.
Currently there is a registry that is controlled by the makerdao deployer (at least the last time I checked), and seems to have very limited update capabilities.

Thank you for this MIP! I’m eager to see a new governance contract in action.

Here are some random comments

I’m surprised the solution has to introduce one more parameter for governance to tune (and one that seems a little hard to reason about). What prevents having simultaneous vote on multiple proposals + new proposals point to a “last passed proposal” when they are created, and their threshold is the amount of MKR on that last proposal?

This is one more parameter to tune, but I guess it’s unavoidable. Even the current contract is vulnerable to an inactivity attack, right?

Not sure I get the mechanics. Will it provide enough gas token to exactly cover the cost over multiple future transactions by the altruistic sender?

Suppose there wasn’t that technical requirement. Would it have been dangerous to have no snapshotting and just let freshly locked MKR vote on an existing proposal?

That’s too bad but I’m still very much looking forward to delegation (& multiple concurrent proposals!).

I like that a lot. Could this be an instance of a more general class of authorized 0-delay proposals, and new 0-delay proposal types can be voted in/out by governance?

In the current system, there is no need for spam protection, people just come to a common frontend which does the filtering. Why was spam protection at the contract level needed in the version of the governance contract?

I’m very excited about this redesign, great work :slight_smile:

2 Likes

Hi Swayka, thanks for your comments! In response:

Re: Introducing one more parameter (variable threshold) for governance to tune

The rationale for using a threshold is to prevent low-bid proposals from passing. Your reference to a previous proposal is essentially what we have now, which isn’t flexible enough to support multiple proposals. (we could discuss slates as part of the current design but there is still transition risk when moving votes from one proposal to another).

Re: Vulnerability to inactivity attack - current DSChief vs DssGov Contract

Correct, the current contract is vulnerable to inactivity which could cause delays if voters are unable to exceed the amount of MKR on the existing hat (usually the most recent winning proposal). This is why the amount of MKR on the hat is very important to secure the current system. The DssGov design makes sure that the threshold is always referencing an active amount of MKR. If we didn’t have this mechanism in place we would run the risk of having such a high threshold that would be difficult to exceed.

Re: Gas cost mechanics

Once a user locks their MKR in DssGov, a gas token will be created. The gas token will enable an altruistic user to update the owner’s MKR from active to inactive MKR only once if the owner (or delegate) becomes inactive - only one transaction is required to make this change. This will also update the total amount of active MKR in DssGov, and the amount counting towards the threshold.

Re: Dangers of allowing fresh MKR to vote without relying on a snapshot

If we let all MKR vote and didn’t have snapshotting, the system may be exposed to flashloan risks (without additional controls that snapshotting resolves). Also, the threshold is based off of a snapshot value so that mechanism would have to change too. In this way one can see that snapshotting and thresholds are really closely tied as related functions.

Re: Not allowing delegates to forward delegated votes to others

This would be an ideal feature however it introduces additional complexity when users add/remove MKR and this accounting needs to travel up the hierarchy of delegated addresses - which makes for a more expensive and difficult to manage delegation system. In this first iteration, it makes sense to see what the demand for delegation is, and then for the community to also explore L2 solutions that may be more scalable in this area.

Re: Supporting 0-delay executives

0-delay executives need to be very specific due to the risk of introducing immediate changes. They are therefore restricted to oracle and auction threats as well as dropping previous executives that do have a delay.

Re: Why include spam protection

Spam protection became a feature because the community requested multiple concurrent executives. In theory, an individual could spam the system with a multitude of executives, which has the potential to be disruptive. It was therefore decided to introduce address whitelisting for domain teams and mandated actors, and to prevent any spamming a simple bond mechanism could be employed. This could be set very low to still allow anyone to vote but unlikely to spam.

Feel free to ask any clarifying questions and I’ll sync with the Smart Contracts Team for detail if needed, thanks!

3 Likes

Hi Yaronvel, good point, yes, I am aware that the smart Contracts team is working on an onchain registry for the addition of collateral types (ILKs) as well as improvements to the current contract address changelog.

2 Likes

Thank you very much for the answers :slight_smile:. Here are some additional questions and comments!

Current state

Is the code considered ‘done’ pending modifications for security reasons?

Re: Introducing a variable threshold parameter

A combination of 1) a tree of proposals (must have more votes than parent to pass), 2) the ability to vote on any number of current proposals, and 3) sweeping out inactive MKR, that looks like it could work without a threshold. I don’t know if development of the new contract is mostly done or not, so a vague suggestion like this may not be relevant.

Anyway since governance should be more nimble in the future, the price of an additional parameter could be much lower than I thought.

Re: Vulnerability attack / Gas costs / Danger of not having snapshots / No redelegation / 0-delay executives

Thanks, that clarifies things :slight_smile:

Re: Spam protection

I don’t understand, unless some operations have gas costs that depend on the number of current executives? Is there a difference between the impact executive spam would have on the new contract vs. the current one? If yes, in what way?

1 Like

Is the code available for review somewhere?

@swakya and @xvwx code for the DssGov contract is written based on the above concepts, however it still requires additional testing and review. I will leave it up to the Smart Contract Team to determine when is the right time to share and if/how the bug bounty will play a role here too.

@swakya re: Your idea of having more votes than a parent to pass + support multiple proposals + sweep out inactive MKR. It’s definitely not too late for ideas! Although I think this idea (if I understand it correctly) has some problems because the ‘parent’ or any other proposal essentially becomes a threshold that must be exceeded but it isn’t particularly manageable because it depends on voter participation which at times could leave the system exposed or unreachably high. If you really don’t like the threshold idea, the alternative as I mentioned above would be to have a timed window of voting, where people can explicitly vote against a proposal over a period of e.g. 3 days. This however doesn’t let us react as quickly to market/ecosystem changes.

Re: Spam protection: In today’s world the Governance Portal only displays executives deployed by the Smart Contracts team - they are the only individuals deploying proposals. Now, with an eye on decentralization, with more domain teams and more mandated actors potentially responsible for their own executives, also potentially across multiple sites (collateral/stability fee/DSR etc), this exposes a potentially malicious vector. The domain team wanted to reduce this exposure by whitelisting specific addresses and reducing the ability for other participants to spam the system (even though it is true that we haven’t see such behavior to-date). This isn’t so much a gas cost problem, it’s more about the disruption of having thousands of proposals flood the system.

Thanks again for the extended response!

Re: parents/multiproposals/inactive MKR, the idea is that as long as all MKR in the parent are active any child proposal must exceed or equal a high amount, but as time passes and parent MKR becomes inactive, the next proposal becomes easier to pass. The other side of the issue (having the system too exposed) does mean that after a long enough period of complete MKR inactivity, any proposal could pass with a dust amount of MKR voting for it, but that sounds like there would already be a huge governance problem if that were to happen.

In the normal course of operations, voters would just copy their vote from the parent to the child (no transition risk), and then either wait for excess MKR in the parent to become inactive or remove their vote from the parent in order to lower the child threshold.

I agree that having time windows is not a good idea.

Re: spam protection, I’m having trouble understanding whether this spam protection is a hard requirement due to properties of the new contract, or just something you consider “nice to have”. In the current system, having thousands of proposals flood the system is a) 0 cost when it comes onchain interactions, b) just a matter of filtering more events for frontends, but we aren’t talking about high CPU requirements here. So for now I don’t have a clear picture of why it is worth the code complexity & risk cost of adding spam protection by bonds + whitelisting if it is possible to have 0 smart contract code related to that and let frontends do the work.

Hmm I’m still thinking through your parent/multi-proposal idea. Regarding your spam protection point:

I would classify the spam protection as nice to have, because the system can certainly function without it, however I think it is important not to be overly reliant on front-ends (scams etc), as well as removing opportunities for potentially malicious activities.

In terms of code complexity, it’s not too bad - we are talking about confirming whether the user’s address is a whitelisted address:

  • IF; yes, and they haven’t exceeded the amount of allowed proposals, they they can submit a proposal.
  • IF; no, and they haven’t made another proposal recently, and they have a minimum amount of MKR for creating a proposal, they can submit a proposal. After which we update the MKR locked time required. (preventing flashloaned proposals/spam etc)
2 Likes

Regarding the spamming protection. The main problem has to do with a malicious source getting enough MKR (temporary) to schedule a proposal. In this scenario good governance could recover the power during the 12 hours delay and they could drop this malicious proposal.
If there isn’t a spam protection, the malicious source could elect thousands of malicious spells making harder to governance to drop all of them in 12 hours.
IMO, this is a security function, more a must have/should have than a nice to have.

2 Likes

Ha I think this answer made me more confused :stuck_out_tongue: What do you mean by “dropping” a proposal? My understanding was that spam protection was for introducing new proposals. If a malicious source has eonugh MKR to pass a proposal, they certainly have enough to introduce it in the first place, no?

1 Like

Yes, the spam protection is for creation.
So this protection won’t avoid a malicious address creating a proposal, but what this will do is avoiding to create a big amount of them.
The main problem is not having them created, but the malicious address also having enough power to make them pass. Then we will have a big amount of proposals to be dropped by good governance (which might be a much more complex task).
We haven’t gas profiled exactly yet how many proposals a proposal can drop, but there is a limit.

Definition of drop: Get a proposal (that was already scheduled to be executed) cancelled by another proposal.

So let’s put an example.

Actual MKR locked in DssGov is 70K MKR. Threshold: 50%. Min MKR to make a proposal: 5K MKR.

A malicious holder (or a group of them) has 35.1K MKR.

So in theory with this spam protection they could only create 7 malicious proposals and make them all pass.
When that happens, good MKR holders can react loking their MKR and proposing a new proposal which drops these 7 (they have 12 hours to do so).

However if we do not have the spam protection, this group could create let’s say 50K malicious proposals.
In order to react to that, governance will need to create several drop proposals (and coordinate to get them all voted) to be able to drop these 50K malicious proposals. All that in 12 hours.
So it is certainly much more secure to have a controlled number than unlimited one.

2 Likes

OK that makes sense! But if we consider accepted proposals as still potentially malicious, then the problem is symmetric and another attack is the inverse of what you’re describing: the malicious holder can cancel any regular proposal passed by good MKR holders.

Well yes, but if an important amount of MKR is malicious then there is probably not other chance than Emergency Shutdown.
This case has more to do with moments where the governance module might not have enough MKR deposited and active in the system protecting it.

1 Like