MIP13: Declarations of Intent

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

Hi from Gitcoin.

DAI and SAI are top tokens on our platform so it is a particular pleasure to see this discussion and have the opportunity to chat about this MIP. Many thanks to @andytudhope for sending me this thread so I can provide some perspective.

Andy has provided some input/wisdom that I think is useful, in particular this portion.

It really requires a point-person with the technical knowledge required to judge whether a given piece of work satisfies the declaration of intent.

I think that the primary value add that Gitcoin could provide is liquidity of workers to dial in the work on the bounties. Of particular importance we’ve built up reputation about which workers are reliable and what skillsets each worker has. Here’s an example profile of one of our workers: https://gitcoin.co/iamonuwa - The Leaderboard ( https://gitcoin.co/leaderboard ) has a decent view into other workers on the platform.

Regardless of whether we pursue anything formal or not RE: the bounties portion of this MIP, I’m more than happy to keep an eye on this thread & provide a perspective. Perhaps we could do some sort of lightweight experiment to see if there’s any value we can provide. Let me know if theres any questions.


Nice to see you here! @owocki :robot:

On the topic of bounties platforms, I think it would be an interesting experiment to use a combination of a bounties platform and this MIP to shape a process for how a future open/decentralized workforce could operate.

For example, let’s say there exists an elected/dedicated white label solution of a bounties platform and a MIP is ratified that defines processes for how to propose requests for work, get elected, and paid. A possible process flow could look as follows:

  • Bounties for Maker Protocol or DAO work are proposed on the platform by community members or domain teams
  • The bounties go up for an approval vote
  • Bounties are approved
  • Workers apply to work on the approved bounties
  • Workers are approved (by domain team greenlight and governance)
  • Work begins
  • Once work is completed, the respective domain teams verify the work
  • Once verified, payment is sent out through the platform to the worker (done through governance, where the paying address would be the dedicated address that Dai is sent to from the Maker Protocol).

In terms of concerns with a process like this, I suppose the main one would be with the security of the funds being held in the platform and how they would get distributed upon the completion of work. What do you think? (cc @andytudhope @LongForWisdom)

1 Like

So I feel like there are a couple of options here with regards to the issues brought up by @andytudhope @MakerMan and others.

Option 1: Remove the bounty-related sections from this MIP, and have this stand as a way to declare intents without defined bounties. This avoids any potential downside from an inadequate bounty system. Add a bounty system in a future replacement of this MIP.

Option 2: Rewrite this MIP now to include a better defined bounty system, either integrating with gitcoin bounty contracts, developing something else, or defining additional roles that manage the process.

Option 3: Keep the MIP as is with regards to the bounty system, and hopefully get it ratified as a first pass version of a bounty process. Create a second, more robust version to replace this MIP in the future, using the usage of this initial version to inform changes.

Of these, I favour Option 3, but would be willing to go with Option 1 if there is widespread opposition to the bounty portion as written. Option 2 I dislike, because it will mean a greater delay to getting this MIP ratified. If we have to integrate a full bounty system, I would not expect this MIP to move into Formal Submission earlier than August, and possibly much later than that.

I would love to get people’s input on which route this should take. It’s hard for me to tell from feedback how strongly people oppose the MIP as currently written. Do people still view this as net-positive? Or do people think this will actually cause more problems than it will solve?

Here’s a poll to make feedback super easy.

  • Option 1 - Remove bounty-related sections of this MIP to avoid possible negative outcomes.
  • Option 2 - Rewrite this MIP to include a more robust bounty system (bearing in mind this will likely delay ratification by several months).
  • Option 3 - Keep the bounty system largely unchanged, and improve upon it in a future version of this MIP.

0 voters

@LongForWisdom voted for 1 because I’d be happier to avoid what I see as negative precedent just to get something out the door.

Hey @owocki - what do you think the lightest weight version would look like? The unique features here are:

  1. The Approval vote process Charles outlined, which I think would be really awesome to see. Anyone can propose bounties, and governance votes on relevant ones each cycle (i.e. month), and then funds them.
  2. Funds coming directly from the protocol itself, hence the concern over safety. We’re going to suck DAI and send it directly to a specified address. Should be easy enough to create the bounty first, then fund it like this, no?
  3. Potentially a group of reviewers/green-lighters. Should be easy to handle through multiple Approvers no?

@charlesstlouis I think approving workers can fall to MIP editors for now (i.e. it’s just an admin step that requires looking at reputation scores and browsing GH profiles to get a sense of real skills). Potentially can fall under the remit of others later on.


Worth noting that this process of voting + funding should probably be an atomic operation, as in the approval of the bounty comes in the form of funding for said bounty

I think I disagree with this, could you not make approval of a specific worker its own subproposal? This would give the opportunity for the worker to pitch themselves and their plan to complete the work to the community at large.

Would lead you to a process something like the following:

  1. Intention + Bounty proposed using subproposal.
  2. Intention + Bounty proposal accepted by governance.
  3. Interested workers submit subproposals to governance.
  4. One of these subproposals is accepted by governance (And this sets the target address in the bounty contract but does not yet release funds?)
  5. Work happens.
  6. Final subproposal submitted by worker which governance approves if they are happy that the work fulfils the intention.

You could potentially delegate one or more of these steps, but eh, delegating responsibility for any of these to a single party is risky, imo. Delegating choice of worker is open to abuse. Delegating when to release funds is potentially also abusable, but less so in that it requires two malicious parties to abuse.

Delegating to multiple parties in a multisig setup is probably secure enough though, and could be worth investigating.

Added quoted paragraph to MIP13c1 laying out the discussed model where a project manager more familiar with Maker and Make Governance processes takes on the role of making sure delivery matches the intention.

1 Like

I voted for Option 1 because I think there is a way to have MIP13 be written in such a way that it can be complimentary with a bounties platform or some UI gateway without mentioning it directly in the MIP itself. I’ll likely make a follow-up PR to further this thought.

1 Like

I am voting for Option 1 with the following thinking:

Lets make declarations of intent - just that - intent. Funding the intent means an ‘intention’ by governance to ACT. Let them fund intentions and figure out how to do it. In the loosest sense I am getting tired of wiping governances butts here trying to catch all and be all.

First rule of MIPs right. DO ONE THING. Declaration of Intent is just that - intent. How or whether governance chooses to fund intents - lets leave that for another MIP related to funding activities or some such.

I totally understand the desire to make this into Declaration TO be DONE but I think your Declaration of Intent as it stands without funding for the bounty amount is fine. WE DO want goverance to declare what they believe the bounty should be - they can argue these as they come - later use funding MIPs to fund the things.

Honestly your wonderful DOI MIP LFW really makes much more sense from this perspective than trying to deal with the money part of DOI’s. Lets baby step these in a way that keeps them simple. DOIs with a proposed bounty desperately needed. If governance doesn’t fund them - they basically sit DOA but who knows maybe someone will decide to take on a DOI simply because it was already within perview of other work they were doing and then once done solicit for bounty payment to release the work to the DAO.

As to MIP Editors dealing with the bounty and people side of this. I really have a concern MIP Editors are going to end up with a tremendous amount of power here if we start putting a lot of funding decisions or personnel choices within their domain.

I think the rest of the mechanics of how DOIs are dealt with are ok. Just leave a hook for DOI bounty funding to another MIPX DAI Funding or some such.

1 Like

In the absence of further votes, I’m leaning towards leaving this unchanged and waiting to see how it is used and using that to inform a v2.

Remember that we’ll always be able to vote down individual bounty declarations and/or payouts if we think the system is being used in a negative or malicious way.

Based on the feedback and the further votes in the poll (and given the fact that many of the votes were case by persons whose judgement I respect), I have removed the bounty-related portions of this MIP. The rest remains largely unchanged. I intend to submit MIP13 into the governance cycle for the month of June.

This meets with Option 1 in the poll above.

I deeply appreciate all the feedback from everyone involved, and I sincerely hope that we can get a more comprehensive implementation of bounties written up as soon as possible.