MIP13: Declarations of Intent

MIP13: Declarations of Intent


MIP#: 13
Title: Declarations of Intent
Author(s): @LongForWisdom
Contributors: n/a
Type: Process
Status: Request for Comments (RFC)
Date Proposed: 2020-05-12
Date Ratified: <yyyy-mm-dd>
Dependencies: MIP0
Replaces: n/a



Sentence Summary

MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community.

Paragraph Summary

MIP13 introduces declarations of intent, which allow Maker Governance to signal an intention to the wider community. MIP13 defines a list of Active declarations, and the processes required to declare, revoke and modify declarations. These declarations can help to inform DAO members or the Maker Foundation as to the issues and priorities that Governance considers to be important.

Component Summary

MIP13c1: What is a Declaration of Intent?
Describes the desireable properties of a Declaration of Intent, and the considerations that should be made when creating or modifying one.

MIP13c2: List of Active Declarations
A list component which contains a list of the currently active declarations of intent.

MIP13c3: Declaration of Intent Process
A process component that allows Maker Governance to create, replace or amend-through-replace a declaration of intent.

MIP13c4: Revocation of Intent Process
A process component that allows Maker Governance to revoke a declaration of intent.


MIP13 is designed to formalize and expand on a pattern of behavior that has appeared consistently in the Maker Governance community. This pattern of behaviour tends to look like this:

  1. Recognise that something should be done.
  2. Discuss the problem.
  3. Vote in some form to ensure that a majority wants to do something.
  4. Hope someone does the thing.

We’ve seen this pattern come up multiple times, across multiple different subjects. Three examples that come to mind are:

  1. The shutdown of SCD.
  2. The introduction of ranked on-chain voting.
  3. Compensation of vaults that lost money on Black Thursday.

In each of these cases, there was no formal record of the declaration of intent beyond an on-chain poll and the various forum threads that led to the decision. By formalizing this process in MIPs, anyone wishing to interact with Maker Governance can easily discover what has been agreed on various topics in one place. In addition there will be a record of when each declaration took place, and the described reasons for it to have been declared.

Specification / Proposal Details

MIP13c1: What is a Declaration of Intent?


A declaration of intent is a statement that declares an intention Maker Governance has to the wider ecosystem. Such declarations should be made with the aim of prompting action in a certain area.

There may be other ways to use ‘Declarations’ outside of intention, this system could be generalized to declaring other concepts, such as beliefs, or goals. However, based on the principles of specificity and brevity, it is suggested that these variations are defined as separate MIPs if they are determined to be needed.


Declarations should be worded carefully to capture the intention of Maker Governance as precisely as possible, however, that does not mean that declarations must always be specific and precise.

There may be times when Maker Governance does not care about the implementation details used to solve a problem, only that the problem is solved. There may also be times where Maker Governance has already discussed possible solutions to a problem and already aligned on an implementation to a point where they would accept only that specific implementation.

Declarations of both types (and anything inbetween) should be considered legitimate, but Maker Governance should take care to make it clear where each declaration lies on the scale between these two extremes.

MIP13c2: List of Active Declarations

This list can be amended through subproposals created under MIP13c3, MIP13c4 and MIP13c5.

Entries into this list should follow the following template:

Declaration Statement:
Sub-proposal Number: #
Date Ratified: (yyyy-mm-dd)

Note that the subproposal code should link to the relevant subproposal.

Active Declarations List
There are currently no active declarations. Below is an example declaration which should be removed (as should this paragraph) when the first ratified declaration is added to this list. If there are no active declarations, the example declaration and this paragraph should be restored.

Declaration Statement: All Governance Facilitators should be given chocolate on the 30th of February each year.
Sub-proposal Number: MIP13c3-SP0
Date Ratified: 2020-02-30

MIP13c3: Declaration of Intent Process

MIP13c3 is a Process MIP component that allows MKR Governance to create, replace or amend-through-replace a declaration of intent through a subproposal.

If a declaration of intent is ratified through a MIP13c3 subproposal, it should be added to the MIP13c2 list by a MIP Editor.

If the subproposal defines a declaration to be replaced then:

  • That declaration should be removed from the MIP13c2 list by a MIP Editor
  • The replaced declarations subproposal status should be changed to ‘revoked’ by a MIP Editor

MIP13c3 subproposals have the following parameters:

  • Feedback Period: 4 full weeks
  • Frozen Period: 1 full week

MIP13c3 subproposals must use the template located at MIP13c3-Subproposal-Template.md. This template is considered ratified if this MIP moves to Accepted status.

MIP13c4: Revocation of Intent Process

MIP13c4 is a Process MIP component that allows MKR Governance to revoke a declaration of intent through a subproposal.

If a declaration of intent is revoked through a MIP13c4 subproposal then:

  • That declaration should be removed from the MIP13c2 list by a MIP Editor.
  • The revoked declarations subproposal status should be changed to ‘revoked’ by a MIP Editor

MIP13c4 subproposals have the following parameters:

  • Feedback Period: 4 full weeks
  • Frozen Period: 1 full week

MIP13c4 subproposals must use the template located at MIP13c4-Subproposal-Template.md. This template is considered ratified if this MIP moves to Accepted status.


Links to externals don’t go anywhere (because this was written for the mips folder structure in github) https://github.com/makerdao/mips/pull/30 for the pull request into the github conception branch, in which you can see the initial versions of the other files.

On the whole MIPX thing, I’ll update this once it’s assigned a MIP number.

1 Like

I really want to see this MIP move so I am just adding a post to bump it.

Does anyone have any objections to the above MIP?
Does anyone have a better idea or ways to improve the above because I feel at this point given the offloading of Foundation Maker stuff we are going to need tons of the MIPX’s to deal with all kinds of operational issues we currently only have the Foundation for.

1 Like

Wierd question LFW. I see nothing regarding closure of a Declaration of Intent, nor whether we also will maintain a complete list not just of active DOI’s but ones that are formally closed and what the actual payment was vs. what the bounty offered was.

Example: Poll for compensation for Black Thursday people had a DOI in effect for someone to do a compensation report that included a bounty of up to 2000DAI. I took on that bounty in effect and was paid 4000DAI. I think we should record stuff like this somewhere and think at least with the DOI’s perhaps a


That looks like (excuse the formatting my time is limited here)

Declaration Statement:
Sub-proposal Number: #
Date Ratified: (yyyy-mm-dd):
Date Completed: (yyyy-mm-dd):
Bounty Offered:
Bounty Paid:
Closure Comments:

Now I am thinking we are going to have to have governance close these or can we have a DOI manager being some EPC to do it?

All of this is making me think perhaps we need a

MIPXc7: DOI closure, payment disbursal, recording via MIPc7-Subproposal-Template.md. but I honestly can’t think straight atm to write up something.

I do see the above is somewhat covered in submitting a MIPc5 for closure listed in MIPc6. I was thinking here more of the formal MIPX: DOI closure process and then recording the payment and closure date and creating a dataset of formally closed MIPX’s generally as a record of work. We may also want to record revoked DOIs as well as rejected DOIs.

Ok. I am just reading through this carefully and adding comments.

MIPXc4 DOI revokation

Do we need a section regarding partial Bounty compensation if someone is working on a revoked MIP i.e. MIPXc4? Or at least how this is handled?

I think some predefined terms in MIPXc5 regarding acceptance and bounty paid if revoked or at least terms of acceptance need to be somewhere. Regarding making contracts there has to be some sort o severability clauses or contractual obligations. I am not sure if we can just treat these DOIs as ‘bounties’ where one completes or gets nothing. Maybe. But in that case should we just set the revokation release terms up front? I am unsure here just jotting down my thoughts.

I see some of this is handled in MIPXc6 so perhaps add something regarding above there? Anyway beyond my comments here which should help tighten this MIP up a bit it really looks good and we should try to move on this after comment period ends.

1 Like

I think this is covered by MIPXc4 and MIPXc5? Both contain a statement like:

  • The fulfilled declaration should be removed from the MIPXc2 list by a MIP Editor.
  • That declaration should be removed from the MIPXc2 list by a MIP Editor.

Good point. I did think about adding this, but talked myself out of it on grounds of length. We certainly could have a list of ‘completed’ and/or ‘revoked’ declarations.

I’m not sure we would need an additional subproposal for those lists though. Maybe just amend to them and link to the MIPXc4 and MIPXc5 subproposals?

As written, it isn’t really handled. I added a point in MIPXc6 along the lines of ‘Make sure the thing you want to work on isn’t going to get revoked.’ I think this is probably something that can be handled using the Protocol DAI Transfer generic MIP?

I’m not entirely sure either, but it struck me as a good first-pass version of this MIP. In the future I’d hope to have some sort of escrow system and more details. Would want to get more feedback from others on this. Adding more detailed logic here will require a more complex MIP, which is the downside.

MIPXc6 is probably the weakest section. Once this moves to RFC I’d be happy for people to contribute changes to this or other components in the MIPs github.

1 Like

Perhaps the whole contractual details can just boil down to DOI Bounty deposit. Meaning if someone decides to take on the MIP the deposit is held in escrow for them in case the DOI is revoked and this is why the bounty hunter needs to make sure the DOI is not revoked.

Basically then IF governance approves the DOI request they also have to put up the non-refundable deposit for someone to take on the bounty and then governance has to approve not just the MIP DOI but also accepting a particular bounty hunter. Arrgh. Not really a simple solution here except to leave these as bounties and put the onus on the bounty hunter(s). I feel like we may not get too much work done here or it will not be well co-ordinated so there is no duplication of effort. i.e. what if two people take on a DOI? etc. What if one starts and another finishes? This is particularly true of large projects that likely will require multiple individuals or a team to be assigned and someone act as the DOI project manager to account for and disburse funds as well as take on repsonsibility for completion.

Do we literally need a manager to mange the bounty hunters efforts? Deal with bounty hunters bailing on a project, assigning new ones, etc. All sounds ugly - like middle management.

1 Like

Yeah, this is the direction I was thinking this could evolve into in a future iteration.

Pretty much. This was the simplest method of incentivisation I could think of for this sort of thing.

This one is at least answerable. Whichever finishes it creates a MIPXc5 subproposal and puts both his address and the other guys address in, with a split he thinks is reasonable. If they end up arguing about it, Governance can just not payout to either until they come up with something that both can agree on.

I think that ideally someone would keep track. In some respects it can be approached from the low maintenance angle of ‘see if someone presents something that meets the criteria and is worth paying for, if so, pay them the bounty. If it doesn’t end up getting done, increase the bounty until it does.’

Part of the hope is that whomever authors the MIPXc3 subproposal wants to see ‘their’ intention get realised, and so will work with bounty hunters working on it.

1 Like

Updated with assigned MIP number and moved to RFC.

1 Like

I have made some minor changes here to aid clarity (changing feedback and frozen period units.)

Github RFC branch can be found here: https://github.com/LongForWisdom/mips/tree/DeclarationsOfIntentRFC/MIP13

Free free to make PR’s, leave comments here or hit me up to discuss.

I would also like to draw attention to the Subproposal Templates located here:

These will also be considered ratified if the MIP is accepted.

I have yet to add any additional list components for completed or revoked Declarations. Does anyone else have input on this? Should these be included?

I’d also love to get more input on MIP13c6.

My main concern with the whole structure as proposed is about adjudication and the inherent fuzziness in the term “Maker Governance”. I helped run Status Open Bounties for some time, and then our work on Gitcoin, and it really requires a point-person with the technical knowledge required to judge whether a given piece of work satisfies the declaration of intent. This person needs to be responsible for review and testing, otherwise it becomes a mess, in my experience. This “Overseer” should be a part of MIP13c3 imo. Otherwise, this is a good proposal.


Can we not overcome this somehow? It’s a deeply unattractive feature imo. I feel like, if we had an “Overseer” role defined, then greenlight from them could release 50% of the funds immediately, followed by full Gov greenlight for the rest of the funds. Hungry devs aren’t going to take up bounties if they have to wait a minimum of 5 weeks, after review, to get paid.


Really appreciate the time you’re taking to provide feedback on this @andytudhope . To address your points:

Hm, I think it would make sense if the person that authored the initial Declaration of Intent did this in some cases? MIP13c5 allows the division of the bounty between multiple addresses.

I’m unsure whether to include this as a requirement in the MIP though, it adds complexity and length and I’m not sure it is necessary in all situations. Furthermore, I think it may prove to disincentivise people from running them if they are required to overseer the work.

One of the advantages to having the system be as open and non-restrictive as it is currently defined is that these structures can evolve naturally. A project manager type person can take on the role of delivering the Intention to the satisfaction of governance and award themselves a share of the bounty from doing so.

I agree, but I think this can be overcome by just offering larger bounties. The issue with putting funds under the control of an overseer is that that overseer needs to be trusted. Ideally some smart contract can be in control of the funds, and they can be released partially as milestones are completed. Unfortunately this adds technical complexity to this MIP, which I’m not sure its desirable in this initial version.

I really want to just get something workable ratified, and leave room for iteration and improvement in later versions of the MIPs.

If you can think of a way of adding an overseer role in such a way that is:

  • Safe (with regards to funds)
  • Incentivised (so people want to do the overseer job)
  • Does not add too much technical complexity (as few smart contracts as possible)
  • Does not add a barrier to entry.

I’d be happy to discuss and work on an improved version of this with you in the future. That said, I don’t think that should stop us from ratifying this version as soon as possible.

In combination with MIP14, I think there is enough flexibility here that we should be able to handle most cases with what we have. MIP13c3 can be used to amend-by-replace declarations of intent to reflect agreements between bounty hunters and someone in the ‘overseer’ role. Any additional payments (for example for audits) can be covered by MIP14.

Worst case scenario from ratifying this asap is that we decide on a bunch of intents and no one does them because the terms are too unfavourable. Anything else should be able to be solved with the tools available in MIP13 and MIP14.

The MIP could recommend this structure without mandating any specific scheme.

That’s true, I may make that change and add a suggestion along those lines to MIP13c1.

Can recommend https://github.com/Bounties-Network/StandardBounties#3-development as a long-time user of these contracts. Milestones, again, require technical oversight.

In principle, I agree that MIPs should be kept as straightforward as possible and adding an overseer role complicates things here. However, if we just specify that the author of the Declaration of Intent is responsible for reviewing and testing the submission, and that the DAI drawn to fund any DoI is sent to a StandardBounties contract which the author can release (or not), then I think that improves things massively. We would likely need to add that, if the Gov Community is happy with the work, they can optionally choose to reward the author with ~10% of the bounty as a separate payment in the next cycle, which will take longer (but is less of an issue as the author is likely to be more embedded in the gov community than any bounty hunter).

I have also sent this link to the Gitcoin team to see if they have any input they’d like to add.

1 Like

Also, much as I appreciate the awesome work you’re doing, I would be careful with this style of thinking. While iterative improvement is baked into our community, inertia is also a real thing and we don’t want to introduce too much into the gov community so early on just because we want to “get things working”, imo. Don’t let this stop you though - just a small and largely insignificant note from a pedant.

1 Like

Believe me, I’m aware. I was banging that drum hard while working on the first set of MIPs. I think there is a middle ground though and we’re already at a point where we are seeing declarations of intent occurring through the signalling process. I want to get them formalized as soon as possible. The bounty part is a tag-on that seemed to me to be an improvement on having no bounty system at all, but it isn’t meant to be the central part of the MIP.

Hmmm, using externally produced contracts isn’t something I’d considered, nor was I aware of these specifically. If you want to work on integrating these into this MIP, I’d be happy to work with you on it (though again, probably for a v2 relplacement.) At first glance it seems a little complex due to the 5 different user groups thing.

Again, I want to avoid this because I worry it will disincentivse people from doing subproposals if they are required to operate the entire process. I can see two groups that optimize for different things, one that optimizes for figuring out and consensus gathering on what the DAO wants. And another that fills more of a project management role.

Giving the author power to release the grant seems risky, but perhaps I haven’t understood how the contracts work. What stops them from releasing it to themselves maliciously?

Sure, happy to have a go at v2 with you including bounties. Often you find, in practice, that Issuer and Approver are the same. No-one really Contributes (more funds, though it’s a nice-to-have for community signalling of the import of certain bounties). The Fulfiller and Submitter are generally the same too - so only two real roles to worry about.

My experience is that this is actually a bonus in the long-term because it ensures accountability and responsibility. Barriers are sometimes good to have. Happy to just agree to disagree here though.

The funds in a given bounty can only be released to the address(es) listed as Fulfiller. In practice, being marked as fulfilled often requires some provable event, such as the merging of a GitHub PR. Not sure how well this maps onto this more general process tbh.

1 Like