MIP52: Dispute Resolution

That would be additional governance overhead though, 2 votes instead of 1. Are there drawbacks to answering both questions at the same time?

I think you might be conflating the second component of the MIP with the first. The first component, which I anticipate would be used in 95% of situations, requires minimal governance overhead and it would not be a challenge to have dozens in one governance cycle (barring gas fees, but that’s being worked on anyway). The second component, which would be used rarely and only when an aggrieved party has some serious skin in the game (i.e. they “can not wait” until the end of the month for a resolution and also cannot convince the governance facilitator that they deserve an immediate resolution), requires the user to burn MKR. They have no guarantee of getting this MKR back and can basically just ask nicely if they want it back. But I don’t think we should be considering this second component with such complexity - it’s a tax on impatience, not a game-theoretic solution to unfairness, the user has several other options to achieve resolution and is forcing the MKR holders to convene outside of the normal governance cycle.

1 Like

Yes agreed that this is about the 2nd component! But the purpose of the tax on impatience is to reduce governance overhead I think. If there’s an additional vote later on whether to return the MKR, that’s yet one more item to look at for voters instead of the entire being resolved once and for all on that initial 4-options vote. I do see your point that it is much less cumbersome than an emergency poll though.

Overall forcing skin in the game is fine and deciding on the ultimate fate of the bond at dispute resolution time or later is not very important unless I’m missing something, so I’ll stop bikeshedding and agree with the proposal with the caveat that the MKR does not go to 0x0 but to a contract that obeys governance and can send MKR back. The bond size can always be reduced to 0 later.

But there’s really no difference in sending it to 0x0 or to a governance contract, the MKR holders have the exclusive right to mint MKR so it’s just an accounting trick. Regarding having two votes, I think it’s a bit different than that because the “second vote” would just be a poll in the monthly governance cycle when the MKR holders are already convening to vote. Much less overhead than an immediate vote in-between governance cycles.

1 Like

It is but I think it’s one of those things that matter for humans. I’d expect more votes in favor of returning MKR vs. votes in favor of minting back MKR. Yes it does not make sense :slight_smile: Also easier for people who keep a record of their assets, for accounting, tax, whatever purpose. Easier to read and explain an etherscan transaction log and see n MKR going in and out of an escrow contract than to manually match the amounts going into 0x0 and coming from the MKR contract.

edit: thinking back on this, @g_dip’s version has less new code. So I’m OK with the 0x0 parameterized burn.

Yeah: let’s say you decide MakerDAO’s new official color should be blue and I say it should be green. You think I’m an idiot for going with green and I think you’re a dummy for going with blue.

Naturally, both of us are going to rush to file a dispute because whoever files the dispute gets to choose how it’s worded.

You could ask: “Should blue be the new official color” and leave out the fact that green is even an option or you could say “Should blue be the new official color and not green,” and make the subtle implication that blue is better than green.

Either way, I’d dispute the way that dispute was handled.

1 Like

I think these weird edge cases can be handled by the Governance Facilitators. There’s just no way to solve for every potential event and I think the likelihood that there are competing disputes is relatively low.


Edge cases? If that example of a dispute constitutes an “edge case,” how are you defining “dispute” in the context of this proposal.

1 Like

Examples of actual historical disputes:

  1. Prioritization of collateral types by domain teams
  2. Quorum required to turn a Signal Request into an urgent on-chain vote
  3. Outcome of a poll that would change the stability fee on a collateral type

In all three of those cases the dispute was over a single binary choice and this MIP would have offered resolution.


Hey Greg, will start off by saying I definitely think we need something along these lines. That said, I have some comments :slight_smile:

So I agree completely on the binary nature of these, that makes sense. That said, I don’t think it’s a good idea to have the community member determine the contents of the poll itself, I worry that this will end up with polls that are presented as very one-sided issues, where the truth is likely to be more nuanced. There are a couple of options there.

  1. Allow both parties to add their PoV to the poll (there should be a fairly strict word-count limit.
  2. Have the Governance Facilitator write the poll itself and present it as objectively as possible.
  3. Put very little information in the poll, and instead link to forum thread(s) in which the issue is debated.

Inclusion polls are changing to ‘Ratification Polls.’ But otherwise this is doable.

Simple majority is fine, but there should be something similar to the positive participation threshold as proposed for Ratification Polls. Otherwise you risk a tiny amount of MKR swinging a poll that no one else wanted / was bothered to vote on.

This is tricky, and potentially dangerous. What exactly is the poll author allowed to demand in terms of resolution? Like, is it reasonable to have a dispute poll lead to the immediate firing of a Core Unit, for example? As written this MIP leaves it a bit up in the air as to what the possible resolutions are to a dispute.

Again, what does this mean in practice? I’m sure I and others have breached our mandates accidently in the past, none of us are perfect. What does a ‘breach of mandate’ mean in this MIP? What actions does that trigger?

Might be easier to just leave spam-control up to Governance Facilitators. Realistically facilitators control the processes anyway, if a Governance Facilitator is refusing to put up a dispute that they disagree with that’s already grounds for removal.

I would also suggest that you return the MKR in the event of the community member ‘winning’ the dispute. This is more or less how we handle stuff like the ESM, and should become common practice. You shouldn’t be penalized for doing something the majority of MKR Holders end up agreeing with.

This should happen in the next weekly cycle, at the usual polling time, and this should be written into the MIP. I know this is intended to be immediate, but:

  • 3 days isn’t immediate enough to actually have much of an affect in an emergency.
  • Larger holders already have trouble voting in 3 day long polls.
  • Having 3 day long polls at times voters aren’t expecting them is asking for minimal participation, which is not what you want when you’re trying to resolve a dispute.

I would rather this wasn’t here, personally. There shouldn’t be any regular governance actions happening to disagree with during the calendar exception periods. If there are, then they’re likely to be emergency actions that need to be done swiftly. In the event MKR Holders disagree with the emergency measures, they can vote them down in whichever emergency executive takes place.

In the event that Governance disagrees with a successful emergency action, dealing with the dispute probably doesn’t need to be done in the immediate aftermath (presumably everyone involved will still be dealing with the emergency.)

If this is a process component from which subproposals can be triggered, it requires a feedback and frozen period.

I would also say it makes more sense to set this amount in dollars and require a dollar-denominated amount of MKR burned.

Though again, I would recommend against using MKR burn as an anti-spam measure for governance processes of this nature. This is more or less why we have Governance Facilitators.

Don’t love this. It’s basically saying ‘breach of mandate means governance is invalid and someone should sort that out.’ Someone needs to presume on appropriate further action. If you want to leave this strictly up to Governance Facilitators, then make that clear in the MIP. Alternatively, make it clear in the MIP what outcomes should be expected with a successful dispute. Otherwise you’ll end up causing more confusion and issues if a dispute like this is successful.

In what ways were existing governance process unsuitable for these situations, and how would this governance process have changed things?

On 1: That was dealt with using a signal request, I’m not sure having a dispute mechanism would have been easier? Indeed it would have taken longer to use the monthly cycle versus a signal request.

On 2: This doesn’t make a lot of sense to me. In almost all examples of us needing an urgent on-chain vote we have had less than 3 days to take an action. That’s why we used the urgent process. Also, like how does this help in this situation? Also (assuming I’m the one that set the quorum) and the outcome of the dispute is ‘I set the quorum wrong’ how do I fix that without being in breach of mandate? The urgent vote may have happened and that couldn’t be easily reverted.

On 3: Again, I don’t think a 3 days dispute would have prevented the issues you’re referring to, and I’m not sure why putting up a dispute is more effective than just starting a signal request to reverse the decision (and optionally consider the facilitator in ‘breach of mandate’.) Like, we can’t stop doing what we’re doing while waiting for the dispute to resolve, which means it’s always going to be used to send a message over decision-making after the decision has been made. In this case I’m not sure how having a 3 day dispute process helps versus having a month long (or signal request length) process.


Thank you for the (as always) extensive feedback :slight_smile:

I’d like to cross suggestion (2) off the list as it seems as though the governance facilitator themselves may be party to the dispute. As for the other two, I would lean towards a hybrid. I think (1) is a fair compromise considering (3) would struggle to remain binary, but (3) is likely necessary for additional context given the word count limit.

Fine with this. Should I amend it in the MIP? If so, do you have a preference for a minimum threshold?

I think I addressed this in another post but I can find it. The concept of “binding” is very loose in the sense that no outcome of this MIP can ever achieve anything without the follow-on actions of the DAO. I consider it binding in that it should be very clear that those asked to act are now in breach of their mandate (which I see you address below and I’ll reply in line).

A breach of mandate, in the specific context of this MIP, means that you are not abiding by the actions requested to you from the MKR holders. This is why the poll needs to be objective - if the author leaves any subjectivity as to the desired outcome, then they’ll be deferring to the interpretation of the governance facilitator.

This is the exact scenario I am trying to avoid. I do not like how in the current system, disagreements with a core unit are ultimately resolved with “well if you don’t like it, vote me out.” The explicit purpose of this MIP is to put a check on the powers of DAO members by eliminating ambiguity in the desired outcome (by polling the MKR holders already). I think the ability to circumvent the governance facilitator in placing a poll is critical to the efficacy of the proposal, as once again I believe the governance facilitator may find themselves the counterparty of the dispute.

I have no objection to leaving the return of funds at the discretion of the governance facilitator, but I wouldn’t want it to be automatic and therefore expected. One should expect to never see this MKR again and can rely on the goodwill of the governance facilitator to get it back.

This is fair, will integrate it.

The goal of the burn amount is to create a sufficient deterrent to using this MIP for “immediate” recourse. But some things, that the governance facilitator may not find critical, are critical to other parties. Again, this is more in line with having a concrete way to bypass the governance facilitator. I don’t think there should be any limitations on it as it can be increasingly diluted if that happens.

[quote=“LongForWisdom, post:37, topic:7845”]
If this is a process component from which subproposals can be triggered, it requires a feedback and frozen period.

Can you elaborate?

Agreed, will integrate.

I think you might be overthinking it. Any ambiguity is explicitly left to the governance facilitator. So I feel this is already covered?

If I recall, this signal request did not produce the result the party wanted as the dev team just told them “thanks for the feedback but we have our own prioritization framework”. I’d argue it’s a good example of the process not working. If this MIP were used, it would have been the next collateral type onboarded and it would have been binding (as defined above).

Perhaps it’s a bad example. In this proposal the window was 3 days, so if the urgent request was 5 days this would have worked, but I am making changes that nullify this based on your other comments.

I’m referring to when Cyrus wanted the USDC rates lowered. In this case I agreed with your decision, but I do think Cyrus may have elected to use the second component of this MIP (which as drafted would have resolved the issue in three days and likely saved a significant amount of his principal).


I used 10k for the ratification polls, matching that is probably reasonable. I would amend it, yes.

In that case, can we use a different term for this? Mandates are general aims we’ve agreed to (and most don’t actually include ‘do exactly what MKR Holders say.’) Not sure what term would make the most sense. ‘Censured’ or ‘Reprimanded’ or something?

I think you may have misunderstood me here. Governance Facilitators control what polls go up on the frontend. You can’t get around this without either:

  • Replacing the frontend
  • Convincing tech-ops that the Governance Facilitator has gone rogue.

Just saying ‘The Governance Facilitator must put this poll up as directed’ doesn’t solve for the situation where there is a malicious Governance Facilitator. The situation where the Governance Facilitator refuses to put up a non-spam dispute poll when they themselves are one of the parties, is a malicious governance facilitator and they should not remain in their position.

I agree we want to avoid the ‘if you don’t like it, vote me out’ where possible, but if the Governance Facilitator is refusing to put up and honour valid dispute polls, then you need to remove them immediately, there is no middle ground there.

I don’t think that’s the right way to go about this. It should be expected that disputing parties get their MKR back if they have a valid dispute. The expectation should be that if the dispute is upheld then the MKR is returned.

Yeah… again, this MIP doesn’t address that in the least, not unless you give another party the ability to put up polls on the official frontend.

Check like any other MIP with subproposal components. They lay out requirements that the subproposals has to meet, and they include a template for a subproposal of that type.

Technically yes, but it makes my life a lot easier if I can point to a MIP that says ‘Yes the Governance Facilitator deals with confusion or ambiguity in this situation.’

I don’t think that’s true at all. The response was more along the lines of ‘yes we have our own prioritization framework, but, message received we’ll push up RWA’ The signal in question directly led to SIXs and NS-DROP becoming a priority.

What? The MIP doesn’t define that at all. Does ‘please prioritize RWA’ in a binding form become ‘The next collateral you onboard must be RWA’, who decides that? That’s why I’m saying it needs to be more explicit. Also, the original onboarding MIPs explicitly give the domain teams decision-making power over which collaterals they work on, which rolls back around to the ‘breach of mandate’ thing.

Mmm, that’s sort of what I mean though. I don’t think the emergency version would have helped him much because any parameter change wouldn’t have materialized within 3 days. The time-to-implementation is still pretty long.

  • +1 to 3 days waiting for the next weekly cycle.
  • +3 days polling.
  • +1 day for exec to be written.
  • +x days for executive to pass.
  • +2 days for GSM delay.

Like, it would have been faster to use the urgent signal functionality, which already exists (though that comes with the caveat that you need to get it past the community in addition to MKR Holders). I’m not sure if that functionality existed at the time.

In conclusion it feels like we’re missing two things:

  1. The ability for anyone to put up MKR polls without going through the governance facilitator (though we probably don’t want this on the main governance portal).
  2. A general purpose framework for objecting to decisions made by Core Units or elected actors.

I’m hoping we can bring snapshot online for #1 (which is in the works). I think that this MIP is already pretty close to solving #2, so I’m really happy you proposed it. Its worth considering we can modify the process as we see it work as well, the MIP can be amended in the future if necessary, so it doesn’t have to be perfect first time.


By the way, what’s the correct format for making amendments?

Sure I suppose we can say “acting against of the will of MKR holders” to be more literal.

I know, but this MIP serves to cure ambiguity in binary disputes. There can be a situation where the governance facilitator is doing something wrong (not gone completely rogue) and the impacted party does not want to rely on a signal request as that is just a way to gauge community sentiment – the purpose of this MIP is to ask a question directly to the MKR holders without the intermediary of the community.

Sorry I still don’t know what you’re talking about. Do I need to do something to this MIP to be compliant?

Sorry I thought it was in the MIP already but that was a further comment - I will add it.

I’m saying that the author of the Signal Request should have been more specific, but that even if they said “it will be the next collateral onboarded,” there was no MIP to send an explicit Signal that the (at the time) domain teams were overtly acting against the will of the MKR holders. I am saying that there’s currently ambiguity around the expectations of core units to comply with the will of MKR holders - this MIP removes that ambiguity.

Thanks for saying this. I agree that it’s hard to field all issues with a conceptual MIP like this up-front but I think we’ll be able to modify it intelligently as we see how it’s used in practice.

1 Like

Sure, that works.

Yep, makes sense. I think snapshot will solve for this issue more cleanly, but I think this is fine in the meantime. I wanted to clarify intent, and it looks like we’re on the same page.

Depends on your intent. Let me grab an example. So here. You see this:

If you want to make this explicitly a process component, you need something like the above. Otherwise the MIP can still be modified, but it requires an amendment using MIP4. The advantage to making it it’s own subproposal is that it signals to governance that the subproposal is only affecting stuff related to this MIP, whereas an amendment subproposal under MIP4 can modify any MIP.

This means it’s reasonably safe for MKR Holders that don’t care about this dispute process to ignore an amendment to the MKR burn amount if it’s defined in this MIP. It’s never safe for MKR Token Holders to ignore a subproposal under MIP4.

I appreciate the intent here, but I do worry that this is an ambiguity that’s actually helpful. I don’t think that Core Units currently feel like they are required to comply with the will of MKR Holders, and moreover, I’m not sure that they should.

To take the example we were talking about, would it have benefitted to signal unequivocally to domain teams that they’d done something wrong? What did they do wrong in this scenario? Because in my mind, absent signals from governance to the contrary, the only thing anyone did wrong in this scenario was to prioritize differently from an (uncommunicated) set of priorities held by MKR Holders. If you start calling people out for this, everyone will be reluctant to show initiative in the future.

I would say it’s much easier for people to throw up disputes after the fact, and second guess decisions made by Core Units, but ultimately Core Units are making those decisions because they haven’t received prior guidance / instruction from MKR Holders. I don’t feel that the RWA prioritization signal was an example of bad governance. MKR Holders determined that they had a priority that hadn’t been expressed, they expressed the priority, and Core Units prioritized the thing.

So, in conclusion, I’m slightly worried that this process will end up being misused to communicate priorities after the fact when they should have been communicated beforehand. Also concerned that it’ll be used to tie hands, for example: ‘force’ Core units to do Y immediately, which gets you Y slightly faster, but also delays X and Z with the aggregate result being that everything takes longer than X, Y and Z would have if done in the originally planned order.

Thanks again for the thorough replies. How do I amend the MIP in a way that’s compliant with the process? Do I just edit it or should I track the changes somewhere?

I don’t think that Core Units currently feel like they are required to comply with the will of MKR Holders, and moreover, I’m not sure that they should.

Yes, this is the core issue at play. As we become increasingly more dependent on Core Units, I worry that MKR holders will lose control they currently believe they have. Perhaps that’s what some MKR holders want and perhaps it’s even better for the DAO as a whole, and if they feel that way they should reject this MIP. Personally, I think MKR holders need total control over the DAO and I think that this MIP offers a nice middle ground between Core Unit independence and micromanagement.


You can edit it here and on github (or let one of the @MIP-Editors know and they can transfer the updates.) It’s usually good to make a reply on the thread drawing attention to the changes you’ve made as well.


@g_dip Let me know once it’s updated and I can make the changes on Github :+1:


Thanks! Will do.

1 Like

I’ve integrated most of the feedback that was received, please let me know if I missed anything. I would like to submit this MIP for ratification in this coming governance cycle. @charlesstlouis @Davidutro would one of you mind assisting me on the Github front?


I can help you tomorrow morning Greg! :slight_smile:

1 Like