MIP26: DssGov - Governance Contract Redesign

Will creating the gas token or delegation (or any of the new design) require extra fees that were not present before? That is going to be a drag on people participating in a process that already looks like it could use more participation (not hating on MKR…that seems to be a problem for many governance tokens).

That is really clever to borrow a flash loan and use it to purchase a whole bunch of MKR and use that newly purchased MKR to vote - also clever of MKR to use a snapshot from the block before the proposal to avoid this issue. But does that introduce anything else that could be exploited - if the snapshot is always from one block before a user’s vote on a proposal, could you send your MKR to another wallet during the same block in which you vote (since it would be based on the prior block’s snapshot) and then use that MKR to vote again and again and again (kind of like a double spend)? I might be misunderstanding because i am not a dev.

1 Like

I was not talking about removing someone’s balance, but about breaking/changing mechanism of storage refund - making gas tokens not/less usable for reducing transaction’s gas costs.


1 Like

Just going to go through and leave feedback as usual. Looking forward to this being deployed.

I mentioned these in the DC-IAM thread, but will do so again here. ‘Smart Contracts Domain Team’ might get confusing in the future, names and forum / github users would be preferred. The ‘Replaces’ field is meant to refer to MIPs that are being replaced, rather than contracts or anything else. It should probably change to N/A.

I think this would be bad for regular usage. If there is a maximum threshold then it means that less than the chosen percentage of MKR voting can pass a proposal. Is it possible to set a maximum value that decreases over time and resets with every successfully passed executive? We could set it very high to start, and if we ever accidently locked ourselves out, this mechanism would lower the threshold until access was once again possible. I’m imagining something roughly akin to a dutch auction where the amount decreases over time according to a simple linear curve.

A downside to this is that we might be required to pass ‘heartbeat’ type proposals every month or so to reset the decreasing count and prevent system security from decreasing. With the right settings I don’t think this would be very much of a downside though.

Is it possible to define stale MKR according to a similar linear decrease I’ve described above? Instead of making it a sudden ‘this is now stale’ (which could risk system security if a large amount of MKR becomes stale at once), you could track the last time the MKR interacted with the contract (which you may already be doing with snapshots?) and calculate the resulting status-quo vote according to a linear decrease since the time that MKR was last active.

Bold part above does concern me quite a bit with the current proposed system.

Honestly, this system strikes me as overly complicated. There is already an incentive for clearing stale MKR, if too much becomes stale, it’s harder to pass proposals. Anyone who is in favour of any proposal is incentivised to clear any stale MKR blocking it. Yes, you have a diffusion of responsibility issue here, but we have this issue currently with casting spells, calling drip and a host of other smart contract methods. Going forward, by default domain actors should be able to call these and to expense the gas costs to the protocol, failing that, the methods are permissionless anyway.

I would like to see some system of executive votes themselves minting a set number of gas tokens into DssGov in order to make voting itself cheaper. Reimbursement for the gas cost for these mints could be sucked to the address that casts the spell.

I’m not sure how this is setup, but it might be more gas efficient to do this keyed by timestamp rather than by proposal (if it isn’t setup that way already)? I’m imagining that we’ll be creating multiple proposals at set times (weekly or monthly.) If they can all share snapshots via timestamp that might make things cheaper for deployment?

Yay! I’d also note that the snapshotting system incentivises MKR holders to keep their MKR locked in DssGov because they can’t add more later if they want to vote on a specific proposal. Actually, this might be a downside, there is at least one Whale that keeps the majority of their MKR in Balancer pools, and only votes with a smaller percentage regularly and pulls in more if necessary. I’m not sure that snapshots will change that behaviour positively (will just make it so that whale can’t vote with the external MKR.)

Sad about this, but I know it’s a non-trivial problem. Thinking about cycles in the delegation graph makes my head hurt.

I don’t love this part. I’d much prefer if voters could remove vote-weight from their delegate at any time, preventing a vote from passing. The way I see this playing out in the general case is that the delegate supports something that their voters disagree with, but isn’t actively malicious. In this case I think it’s very unlikely that a drop spell will be organised in sufficient time to prevent the initial proposal from passing given that it’s unwanted but not obviously malicious, especially given the 12 hour GSM delay.

Most of the time it’s possible to reverse a proposal after it passes (changing stability fees back, changing debt ceilings back, etc.) However it is not possible to pull DAI back into the protocol if it is sent to a certain address. I can see situations where a delegate could abuse their power to suck DAI to legitimate projects that their voters disagree with in a way which was not easily reversible.

I’m not sure I understand this system, and the diagram doesn’t help me too much. Can you try to explain it more comprehensively. When can governance use 0-delay spells and what powers do they have? Cancelling a queued spell is fine and makes sense to me, I am much more concerned about the other things mentioned. What do FlipperMom and OSMMom have the power to change in their respective systems? You mention being able to protect against malicious variables, I’m not sure I understand how this isn’t already covered by intercepting a queued proposal.

Is there any way this system can be used to enforce a MKR lockup prior to voting in an executive. In my view, this is a key part of the system that is missing right now. The system is based on the idea that MKR Holders are ‘on the hook’ for their decisions, but this is not currently the case. There is nothing stopping MKR Holders voting for a proposal, then withdrawing their MKR and selling before the full effects are felt on the MKR price. Having a configurable delay to withdrawing MKR after voting would make me very happy. Since we’re already keeping user action snapshots, it feels like this should be within reach for this upgrade.

I think this is a reasonable solution to the problem, but I’m worried that setting the right value will be difficult. How much capital will be required to submit a governance proposal outside the regular channels? Would having the bond only released if the proposal is successful allow us to reduce the bond amount to something within reach for smaller holders?

You could also make it such that the bond is explicitly releasable by governance in the case of a failing, but ultimately non-malicious proposal.

Perhaps another option is to make it such that bonded MKR cannot be used to vote in any proposal. This would mean that in a spam attack, the attacker would have to trade-off voting power against number of spam proposals.

Is this mechanism reusable for future transitions?

Not sure I fully understand how this would work, but I probably don’t need to know the details at this point.

Relieved to hear this. Can you provide any further details? Will we be doing 3 audits given what happened with DSChief?

I think that covers everything. Apologies for the brain-dump on the subject. Would just like to say again that despite my criticisms I am so excited for us to get this upgrade. Thanks for all the hard work that has gone into it so far.


We’re currently targeting 3 audits and a bug bounty very similar to the MCD launch security roadmap. However this is still being worked on, so still subject to change potentially.

More definitive announcements should follow soon.


I had a couple of loose thoughts regarding voting delegation.

Part of me feels that delegations may introduce undesirable politics into our system. I can see wasted efforts, energy, time, resources, etc. going towards convincing some MKR holders to pass their delegations to a given voter.

This may or may not be a real threat, but I think it’s worth considering. In seeing the debauchery of the current US election cycle, I think it would be best to avoid any of that.

I think we should disincentivize persuasion.

Delegated votes could have some kind of tapering off weight to them, a kind of diminishing returns. 100 MKR delegated may be worth 100, while 1000 MKR could be worth 500, and 10,000 is worth 3,000. There can be some kind of asymptotic function for this. Full weights may misalign incentives.

Also, I feel like there should be a cap on how much MKR can be delegated to a given voter. Someone voting with 100 MKR should not be able to have 10,000 MKR delegated to them. They don’t have enough skin in the game. There can be a certain multiple, but there should be a cap.

1 Like

This is really not a good comparison. The democratic system in the US was not well designed from the outset. The senate over-represents small states. There are structural issues that entrench a two-party system. We have single-candidate districts instead of rank-choice voting and proportional representation (multi-person districts). Funding is a mess. The system is suppose to represent voters, not money, but private money (both personal and corporate) is in the driver’s seat. Seattle’s new democracy voucher system looks promising. Also, the internet has crushed independent journalism. We need investigative journalism funded by journalism vouchers, similar to Seattle’s democracy vouchers.

Governance of the Maker protocol is not really similar. It’s democracy, but not to represent unique people but MKR tokens (investment).


I think this is a key weakness of Maker governance right now. Allowing voters to withdraw their MKR immediately after voting and sell makes fork-based governance infeasible in an emergency shutdown - there would be little benefit to burning attacking MKR if it had already been dumped on unsuspecting MKR LPs. I think it would make sense to require at least ~2 weeks cooldown period before MKR can be withdrawn from governance, or whatever is the minimum amount of time necessary to organize a fork of the protocol.


I’m glad to see much needed changes proposed in this MIP. I’ll try to provide my thoughts in the coming days so please bear with me. :slight_smile: Discussion is more than welcome!

There’s two “wants” of our parapolitical system when it comes to voting:

  1. We want as little “bad” MKR on-chain voting as possible

  2. We want as many MKR holders voting and involved with the governance process as possible

What I define as bad voting is uninformed, reward-oriented (e.g., voting to take advantage of a system like DssGovRewards), or exploitative (working against the process of decision-making itself).

The rationale for wanting to see as many MKR holders vote (both off- and on-chain) is the “supremacy of an ordinary multitude” as Aristotle put it:

“The principle that the multitude ought to be supreme rather than the few best is one that is maintained, and, though not free from difficulty, yet seems to contain an element of truth. For the many, of whom each individual is but an ordinary person, when they meet together may very likely be better than the few good, if regarded not individually but collectively, just as a feast to which many contribute is better than a dinner provided out of a single purse. For each individual among the many has a share of virtue and prudence, and when they meet together, they become in a manner one man, who has many feet, and hands, and senses; that is a figure of their mind and disposition.” (Politics, book 13, part 11)

In terms of practical application within our governance system, the two initial “wants” should ideally be seen in:

  1. off-chain voting, where the greatest number of opinions can be expressed and discussed on an equal footing. The democratic “marketplace of ideas” then decides which change warrants on-chain voting and a change to the protocol.
  2. on-chain voting, where a plutocracy decides on proposals previously passed by off-chain governance.

How does DSSGov encourage/discourage good voting?

It encourages good voting by introducing delegation, a much needed feature that allows holders to put their voting powers in hands of trusted actors, saving the holder time and effort, while passively remaining in the governance system. In addition, this tool can serve as an “equalizer” for under-represented (due to low MKR holdings), but active, community members. With the forum serving as a hub for those voters, they’d be able to consolidate their opinions and power via delegates.

In the current proposal, the following solution discourages good voting:

The dilemma we have to solve here is this:

Do we prefer inactive MKR to be utilized in the system by delegates (who the inactive holders have previously trusted)?


Do we prefer to require all MKR voters to remain active, regardless of delegation?

We know that one of the incentives for people delegating would be to put trust in a delegate and not be required to think about voting anymore. It seems counterintuitive to remove those good votes using the same rules as for the undelegated MKR. Should they be removed at some point? Yes, otherwise we risk leaving delegates unchecked, especially those who were able to amass large numbers of delegated MKR early on. Should they be treated differently than undelegated active MKR? Also yes. (Further thought is warranted here, the process needs to be based on the specifics of how inactivity is measured.)


I completely missed that, thanks @Elihu. Fixing this seems worth a medium technical complexity cost increase.

1 Like

The foremost reason requiring MKR holders to be active, (whether they are delegating or not) is to insure that the threshold at which votes pass is set at an appropriate level. This threshold needs to reflect the amount of MKR that is actively participating in Governance and not include old, forgotten or lost MKR. Without this check of active owners and MKR, the system could become locked. As Elihu states, this problem also extends itself to leaving delegates unchecked in the same way over time.

I think this check on ‘activity’ is needed to accurately reflect the threshold, but you do raise a valid point of needing to define how inactivity is measured and what time periods make sense for the different participants.


I’m a little confused, how could the system become locked if the delegate still uses the votes of the inactive delegator? As to “leaving delegates unchecked” I do sense a vague feeling of risk around that but I fail to see a specific scenario where it’s really a problem. And any issue that might arise from that should be weighed again the lost indirect participation from MKR holders who forget to renew their delegation once in a while.

Ahh, yeah, you’re right, I should clarify that. The system wouldn’t necessarily be locked however the problem comes about when we want to implement L2 contracts for delegation that could have voting control of MKR for life if they failed to implement the expiry of their own voting usage.

A large amount of MKR being delegated to a single actor (and becoming inactive afterwards) results in unchecked voting power for that delegate.

Best case scenario, the delegate may have deviated from their initial agenda the MKR holders agreed to. Worst case scenario, the delegate has unchecked voting power without financial incentive, as they don’t own the MKR they’re voting with, and are free to make decisions that are potentially detrimental to the network.

I hope this clears things up, @swakya.


I agree about the scenario and on net it may be worth having this activity check even on delegated MKR.

Still I want to point out that there are then 3 possibility for a delegator :

  1. The delegator refreshes their MKR regularly
  2. The delegator disengages because they don’t want to be bothered refreshing their vote
  3. The delegator transfers their MKR to an intermediate contract, owned by the delegate, which the delegate can ping at any time to ‘refresh’ the MKR within it, and with a withdraw function for the delegator. The intermediate contract delegates its votes to the delegate.

This last possibility recreates the scenario of a delegate having unchecked power because they found a way around the activity check of DssGov so their delegator could be lazy. In a nutshell: “it may be easy to fake activity”.


Regarding voting quorums

The more grave and important the questions discussed, the nearer should the opinion that is to prevail approach unanimity. Jean-Jacques Rousseau, The Social Contract

The main weakness of bundling proposals was putting for vote non-controversial and non-essential changes along with high-impact and sometimes-controversial ones. It’s obvious that some changes to the system are more fundamental than others, e.g., amending MIP0 versus onboarding a domain team member.

It’s the task of governance to protect the fundamentals of the protocol from hasteful changes. In constitutional democracies, amendments to the constitution, i.e., the fundamentals of a political system, are governed by special measures for this reason. A supermajority, e.g., ⅔ of all eligible votes, is required for these most impactful changes to take place.

Those fundamental-level protocol changes should also be given special consideration in the deliberation process. They should serve as an opportunity for the governance system to assemble in greater numbers for the proposals that can reasonably be expected to have large and long-lasting consequences.

Having rid ourselves of the proposal bundling and for the two reasons above, I’d like to put up for discussion the idea of weight-dependent MIP voting thresholds. Governance would need to distinguish between weight categories of different MIPs and their respective voting requirement thresholds.

The upside of such a solution would be three-fold:

  1. The cornerstones of the Maker Protocol will be safeguarded by a higher voting threshold, ensuring that a fundamental change to the system can never happen “on a whim”.
  2. Lighter MIP’s can be passed with relative ease, i.e., an easily-achievable threshold.
  3. The differentiation between weight categories of MIP’s enables a clear-cut overview for the governance community. The large number of different MIP’s in the forums (and consequently, to some extent, in on-chain voting), without satisfactory explanations for the occasional voter, means they’re unable to distinguish crucial changes which may have otherwise caught their attention, encouraging them to vote.

About to dump some thoughts on this thread but wanted to take a moment to thank you for your contributions @Elihu! Particularly this last point on requiring more agreement for more cruicial decisions

This is a really neat idea, and while it may be difficult to define exactly which types of proposals should have greater thresholds, I do think we would be able to come to some general consensus. What’s particularly exciting about this in regards to this MIP is that it would be pretty simple to require a certain threshold percentage for general changes and a higher percentage for ones changing critical protocol components. I have been tossing around the idea of what should require more than a simple majority of voters for a little bit now, so it was neat to see that idea showcased while reverencing DssGov

1 Like

I have some questions regarding potential risks associate with switching over to DssGov and thought I’d post them here for transparency and too see what are legitimate concerns and what is just classic brain worrying about new thing:

  1. Should there be a “floor” in place (35k MKR as an arbitrary number) to prevent motions from being passed based on a low percentage of locked MKR? My main concern is that a malicious actor could cause their MKR to go stale, or otherwise incentivize MKR holders to lock their tokens elsewhere and then rely on market liquidity of MKR to borrow enough to make a malicious play.

  2. On a similar vain, will the “snapshot” capture inactive MKR as well? The main worry here is that someone could purposefully park a large amount of MKR in governance, have it go stale, and then use it to influence a major decision of malicious proposal.

  3. Would I be correct in stating that DssGov would remove our ability to distinguish between token holders signaling opposition, not paying attention, or being generally ambivalent about a proposal? I think there’s some value in knowing the differences there and if there were a way to easily add that to the contract I would be greatly in favor of doing so.

  4. Should there be restrictions on the amount of MKR that can be delegated to someone? Adding to some of the misalignment concerns above, if we let any one person/entity control a vast amount of voting rights without the economic downside of poor decision making we could find ourselves in a dangerous position

  5. Is a 12 hour delay enough? We are currently set to further delays, and even with making spamming more expensive, I worry that having multiple contracts to monitor may make it so 12 hours is not enough time to discover and take action against a malicious proposal.

  6. How much safer does requiring MKR to be bonded for new proposals make the system? Here I am worried about accessibility (are we trying to say if you don’t have X amount of MKR you shouldn’t be offering on0chain proposals?), but also questioning how much safer this makes us from malicious attacks. If someone has borrowed the MKR they are using for malicious attacks will they care if it is locked up/destroyed if their actions crater the token value anyway?



Hi @prose11 , great questions, thank you! My responses below:

  1. Should there be a floor in place to prevent motions from passing?

A floor, or quorum was considered in the pre-MIP discussion however it was removed due to the risk of freezing the system if it became incorrectly set over time. It was felt that the threshold (determined by the amount of MKR locked in DssGov) should be sufficient in normal operations. A quorum equal to the existing hat should still be used when transferring authority from the current Chief to DssGov.

  1. On a similar vain, will the “snapshot” capture inactive MKR as well?

Snapshots only capture active MKR as counting towards the threshold and any ongoing votes. Yes, someone could place their MKR in DssGov to increase the threshold thereby preventing a proposal from passing - much like what we see today, when someone increases the MKR on the existing hat to prevent a new proposal from passing.

  1. Would…DssGov… remove our ability to distinguish between token holders signalling opposition, not paying attention, or being generally ambivalent about a proposal?

Today participants signal approval by voting on a proposal, or they show disapproval by adding MKR to the existing hat to make it harder to pass the new proposal. Signalling opposition is essentially asking to have the system enable a ‘no’ vote. This would imply adding a window of voting (3 days for example) to each vote. This is not a technical challenge but it does make it challenging (without additional changes) to pass proposals where immediate action is required.

  1. Should there be restrictions on the amount of MKR that can be delegated to someone?

Interesting question, I hadn’t considered that…but wouldn’t it be preferable to allow MKR holders to naturally free-market-style determine what is safe/optimal when they delegate?

  1. Is a 12 hour delay enough?

Good point, this is a variable number so we can adjust as needed. When initially proposed the protocol had a 12hr delay that has since seen increases, so yeah it does feel too short. I think a delay matching what we have at the time of transition will be a sensible initial value.

  1. How much safer does requiring MKR to be bonded for new proposals make the system?

Not sure I understand this question. In terms of malicious actions - it is not possible to use flashloans or atomic actions to participate in votes due to the snapshot.

  1. Referencing @Elihu ’s idea of weight-dependent MIP voting thresholds…

The existing code has not considered various threshold levels, this would need to be explored further. For anything else other than MIPs like e.g. risk variables I think Instant Access Modules that could require for example 1000 MKR to make a change would be lighter weight and move such logic outside of DssGov.

  1. Referencing @swakya comments…

Delegation is done within the DssGov contract so there is no need for an external contract to manage delegation. This is safer than multiple external contract interactions. Note however that it is not possible for delegates to further delegate to another entity (aka chained delegation).

Re: Mitigating against fake activity: Faking voter activity is technically possible by delegating to a smart contract that could automatically call DssGov to show that it is ‘falsely’ active. This periodic call would however incur gas costs. Also confirming that this would not be the sole reference point for rewards so other data points would be required. (an alternative for example would be to reward on the number of votes participated in - but I leave that to the external rewards MIP that others are working on).
In terms of increasing the threshold, indeed this would make it harder to pass votes, however it may be worth thinking of this in reverse, whereby an increase in threshold acts as a protective measure against low-MKR proposals.


Thank for your comments! re:faking activity, I am not concerned about rewards.

Fake activity means that it is possible for a big delegate to offer a ‘delegate-and-forget’ service. Their delegators would have an incentive to use the service, because it would let them be lazy. The delegate would also have an incentive to offer the service, because it would reduce delegator churn, and thus increase the voting power of the delegate. So I expect the value of the whole activity-checking logic to be very low.

1 Like

Comment/question on MIP26c1:

Is anyone concerned about this time threshold being hit automatically and a legitimate MKR holder not noticing? This could open us up to a governance attack if a MKR holder thinks they’re defending the protocol but their MKR actually has no weight. Would it work better to have the MKR become “eligible” to be considered stale but require an executive vote to actually trigger that mechanism?

1 Like