MIP40c3-SP11: GovAlpha Core Unit Budget - GOV-001

MIP40c3-SP11: GovAlpha Core Unit Budget - GOV-001


MIP40c3-SP#: 11
Author(s): @LongForWisdom
Contributors: Payton Rose (@prose11)
Status:  Accepted
Date Applied: 2021-05-12
Date Ratified: 2021-06-28

Sentence Summary

MIP40c3-SP11 adds the budget for Core Unit GOV-001: GovAlpha.

Paragraph Summary

MIP40c3-SP11 adds the budget for Core Unit GOV-001: GovAlpha. This budget proposal covers a total of 3 months (July, August, and September of 2021). It communicates three focuses for GovAlpha over the period: Delegation, Education, and Quality Assurance. GovAlpha is asking for a total of 520,000 DAI over 3 months - 370,000 DAI will cover operations while 150,000 DAI will remain in a GovAlpha administered multi-sig wallet to ensure emergency continuity.


We are proposing this Core Unit Budget modification because GovAlpha requires an operating budget in order to be able to fulfill its mandate.

Core Unit Name

GovAlpha (GOV-001)

Quarterly Focus


Delegation has always been a longer-term focus for the development of governance within MakerDAO. Given recent events and the need to have delegates operating effectively as soon as possible, this is something GovAlpha plans to focus on over the next quarter.

We are hoping to launch delegation at Maker in a structured and effective way that allows MKR Holders to choose one or more delegate that they feel is compatible with their views. GovAlpha aims to promote delegates that opt-in to a lightweight framework that sets some guidelines for delegates to follow. The aim here is to create a tradition of communication and transparency around delegates within MakerDAO - hopefully leading to a more predictable and efficient process for decision-making as governance evolves.

GovAlpha will also attempt to convince larger MKR token holders to delegate some portion of their MKR holdings to the public delegates that opt-in to this lightweight framework. We believe that this will lead to more MKR active in governance and more thorough debate.

Subsequent to the launch of delegation, we plan to continue to organize and deliver improvements and integration of delegate functionality into the voting portal.


Proper educational knowledge is essential for newer participants to vote and engage effectively in governance at MakerDAO. As such, we are prioritizing getting easily accessible educational materials out to the community this quarter. We will focus our educational efforts on three key areas:

  • Ongoing development of the Maker Operational Manual.
  • Expansion of Parameter Documentation for Liquidations 2.0 and RWA terms.
  • Adding educational content to the MIPs Portal.

We plan to work with the Content Productions Core Unit to create high-quality educational materials that are visually inviting and easy for newer users to engage with.

Quality Assurance

As the DAO grows and governance decisions become more meaningful and impactful, it is critical that governance continues both smoothly and effectively. To this end, we feel that we should spend some time and effort on ensuring quality across the governance processes that GovAlpha operates. It is easy to fall into habits and ‘grooves’ with certain processes which can lead to them to continue to operate in a sub-optimal manner past the point where they should be improved.

For the polling and executive processes, we aim to improve templates and voting portal user-interface to deliver information in the most intuitive and consumable way possible to voters.

For the signaling process, we want to improve accessibility and guidelines to make this process simple and easy for governance participants to use effectively.

For the MIPs process, we intend to make sure that MIP maintenance work is performed regularly by MIP Editors.

We’ve also noticed some opportunities for improvement in time management and prioritization within GovAlpha, and we will be making an effort to make improvements here as well. Our aim is to ensure that our time is spent effectively and that deliverables are met consistently and with high quality.

Team Membership

The GovAlpha Team will consist of at least the following members in the July/August/September budget period.

– Facilitators –
@LongForWisdom - Partial Commitment - Facilitator - Experienced
@prose11 - Full Commitment - Facilitator - Limited Experience*

–MIP Editors–
@blimpa - Full Time - MIP Editor**
@charlesstlouis - Part Time - MIP Editor

@Elihu - Part Time - Governance Core Unit Contributor
Unfilled - Part Time PM / Operations
Unfilled - Part Time Contributor
Unfilled - Part Time Contributor

* @prose11 is aiming to move to ‘Moderate Experience’ after 2 months.
** @blimpa is aiming to take on the role of MIP Editor in the next quarter.

Quarterly Budget - June/August/September

Facilitator Remuneration

There is no change to this section compared to the previous quarter

Remuneration for Facilitators of GovAlpha will be an annual salary paid monthly. The size of the annual salary will begin at a base rate that is equal for all facilitators and is then modified based on the level of the individual facilitator’s time commitment and experience.

The multiplier for partial commitment is higher than one might initially expect given the hours contributed compared to a full-time commitment. This is because facilitators with a partial commitment have the same requirements to be available in emergency situations and take an equal share of responsibility when fulfilling the GovAlpha mandate.

Base Pay 120,000 DAI
Multiplier Explanation
Commitment - Partial 0.80x Part Time commitment, 20 hours per week minimum.
Commitment - Full 1.00x Full Time commitment, 35 hours a week minimum.
Experience - Limited 0.65x New to the role, would not be able to fulfill responsibilities alone.
Experience - Moderate 1.00x Confident in the role, capable of fulfilling critical responsibilities alone.
Experience - Experienced 1.50x Experienced in the role, capable of fulfilling all responsibilities alone.
Partial Commitment Full Commitment
Experience - Limited 62,400 DAI 78,000 DAI
Experience - Moderate 96,000 DAI 120,000 DAI
Experience - Experienced 144,000 DAI 180,000 DAI

Budget Breakdown

Item Amount
Core Unit Facilitators (2) 59,000 DAI
MIP Editors (2) 24,500 DAI
Contributors (4) 41,250 DAI
SourceCred Payouts 85,000 DAI
SourceCred Customization/Support 6,500 DAI
SourceCred Feature Development 36,000 DAI
DaiStats Support 1,500 DAI
CatFlip Equivalent Development 6,000 DAI
DAI Backing Support 3,000 DAI
MIPs Portal 20,000 DAI
Forum Customization 4,000 DAI
Undetermined Software 1,900 DAI
Payroll Software 100 DAI
Other Costs
Contingency Buffer 70,000 DAI
Gas 5,000 DAI
Travel 6,000 DAI
Continuity Budget 150,000 DAI
Total 520,000 DAI

The full budget can be found here.



SourceCred has largely been a successful experiment within the community, however, it remains largely a manual, trustful process. The ‘Feature Development’ budget item here funds work on SourceCred that will help to move distribution payments on-chain such that it can operate in a more trustless manner and be administered directly by Maker Governance.

We will also maintain the current expenditures for SourceCred operation and support. We are asking for a slightly increased budget for payouts to accommodate the recent rise in opt-ins and active contributors within MakerDAO.

Contingency Buffer

Once again GovAlpha is including a not-insignificant contingency buffer. While we do feel slightly more confident about the operations of the Core Unit with a few months of experience gained, we remain concerned about the rapid pace of development within the DAO, and we wish to be prepared to take advantage of any opportunities that present themselves.


As in-person events once again become a regular occurrence, we wish to budget explicitly for any travel expenses that may arise in the next few months.

Continuity Budget

We are requesting a portion of this quarter’s budget allocation for the purpose of continued operation during a serious event that cuts off monthly budget transfers to GovAlpha. The DAI from this allocation will likely be swapped for an alternative stablecoin to further protect the Core Unit’s ability to pay for essential services during an event that makes spending DAI infeasible.

150,000 DAI would allow for us to continue paying essential salaries and core expenses without defaulting on payments for previous work. These funds will only be used when GovAlpha cannot receive monthly budget payments from the protocol.

Budget Implementation

GovAlpha has set up a Governance-owned multi-signature wallet that will be used to administer the funds allocated to fulfilling the GovAlpha mandate. The details of this multi-sig wallet are as follows:

Multi-sig Address:

@LongForWisdom - 0x66f40F044E0e2F77bB746e3275E82e88dCBA2D69
@prose11 - 0xf3ED2bdeBa77940E6759B806cd55CE20cAE369BE

For the next quarter, GovAlpha is proposing a manual budget implementation that will involve the transfers listed below. Transfers should be included in the first executive of the month. In the event of the first executive of the month failing to pass successfully, transfers should be included in the next available executive vote.

Payout Dates
Month of July - 273,334 DAI
Month of August - 123,333 DAI
Month of September - 123,333 DAI


I wanted to make a quick note on transparency, self-evaluation and stuff, as I’m aware GovAlpha hasn’t published anything along those lines yet.

The current plan is to do a quarterly review at the tail end of June where we will evaluate the progress and effectiveness of the unit over the first quarter.

Naturally that’s not terribly useful for governance when considering this budget, so we may consider a different setup in the future. However we’re going to give the quarterly frequency a go first, then depending on the reception, we’ll consider doing more frequent updates going forwards.


Just added some minor edits:

  • Slightly reduced budget due to clarifying the plans of a couple of contributors + external projects.
  • Clarified multi-sig plans (will comeback with addresses and details in a few days.)

TY for the update Long.

And circling back to the Contingency Buffer and Continuity Budget–if things fall apart and we hit a roadblock–how will both Buffers be used–or, should we just compare them to a Rainy Day Savings Account? Trying to get an easy and understandable clarification/examples of how they’ll be used–in different scenarios. When possible–no rush. TY in advance!

1 Like

Sure. I’m not sure if these are 100% the correct definitions, but this is how I’m using them here:

Contingency Buffer is something that you have in case you run over-budget, or want to take advantage of an opportunity that you did not budget for. This is mostly to cover things we haven’t thought about, and might need to pay for later.


Continuity Budget is the money we use when the shit hits the fan and for whatever reason the Protocol can’t fund the core unit for some amount of time. This will never be used outside of an emergency, and exists solely to ensure that the core unit can continue to operate for a limited amount of time in an emergency situation.



Completed the budget implementation section, adding details of the GovAlpha administered multi-sig wallet. No changes to budget amounts or meaningful changes to other parts of the proposal.


This has been moved to Formal Submission for the June governance cycle - @MIP-Editors


I will look at this more carefully when I have time but is probably one of the best Maker CU budget breakdowns I have seen yet.



FYI: @LongForWisdom of note is the complexity with which 1Hive SC distribution occurs has gotten them to work to automate much of the payout process as well. I am not sure if their work could help here but I think in general SC itself should look at doing this. Maker, 1Hive, and other DAOs are sending back funds perhaps some thought of all of us sending either part of some new funds into an escrow account with a SC payout automation bounty might be useful. This way everyone can have a hand in a requirements spec which then makes the funding and payouts easier all around and a growing bounty fund right there to payout once this work is completed to the DAOs satisfactions.

I see this as something the SourceCred team should do - with feedback on the implementation specification document by the DAOs until everyone is agreed and the implementation done.

As to the rest I looked over your budget a bit more carefully. Looks like SC is the biggest line item.

I don’t see anything in there regarding governance changes and delegation in particular or is that kind of buried in a line item? I expected to see a line item for that work.

I also really would like to see some more funding go to a full blown analytics portal there are still so many analytics missing. I am not going to list what I would like to see here.

BTW: Your GovAlpha is probably the most conservative CU budget I have seen. I want to congratulate you on keeping expenses down, on boarding some new talent, and just plain doing everything you do. I see you as one of a growing number of key Maker talents that I know we will miss if you ever move on…

I honestly want you to bump your pay because I think you are worth as much as a number of others asking for far greater salaries around here.


More CUs could learn from your example.

1 Like

So 1Hive’s automation is based on Discord bots. There is some automation for verifying Discourse handles (the Discord bot sends you a verification code and you temporarily change your Discourse handle to the code to verify). Not immediately useful, as Maker doesn’t currently use Discord. But could see using parts of this if we automate the opt-in flow. Also, FYI, our long-term solution for this generally is self-serve identity. This has been spec’d out by the devs, but apparently it’s a big lift and not sure the timeline on that. Could be a while depending on other priorities.

The part of the spec dealing with on-chain distribution is pretty high level at this point. Wary of too many cooks in the kitchen, but if this is funded, plan is to get further feedback from Maker to inform design decisions (e.g. L1 or L2, parameters selection). We generally try and communicate with other DAOs as well so features are widely useful, but admittedly this is an area we could use some improvement.

I’m expecting to work on this a bit, which would be covered under:
SourceCred Customization/Support 6,500 DAI

Proper governance of SourceCred is hard to scope without further feedback from the governance community. Many directions to go here. I’ve been hesitant to open that can of worms with bandwidth stretched as thin as it is with the larger transition to CUs (@LongForWisdom and @prose11 deserve a purple heart badge! :purple_heart: ). I expect those conversations to get rolling naturally when we propose some upcoming changes to the algorithm, but open to ideas on engaging the community more intentionally. Whatever governance structure we use, I think there’s a pretty clear path for progressive decentralization here. It could start out as simple as SourceCred and GovAlpha proposing parameters, then using polls or maybe the parameter working group to ratify? Just spitballing here.

1 Like

I only knew details peripherally and being on the team was hoping you would chime in here @s_ben
Understood there is a lot going on and I have not had time to pay attention to everything. Will leave that and move on.

Glad to hear this. Completely agree on the cooks in the kitchen thing. Having a spec document put out for review and comment I think would be useful. I mean it may not be changed or changeable but I think it is important however the review comes up to ‘be able’ to have it. Feedback might elicit a change, or maybe suggest a new important feature missed. Doubtful, but possible, and it doesn’t have to be a full blown communication cycle but really more of a ‘request for comment’ (RFC) style feed back mode. Too many things are spec’d out and then implemented I never even get to see much less comment on until ‘after the fact’ and I think that needs to change. Even if a specs RFC can’t be addressed or changed it would be nice to still collect comments so then in subsequent versions maybe those can be addressed. (leaving that topic)

This is hard without some kind of cycle and a bit of formalism, thinking about goals in the feedback is important. (leaving this topic as well)

Cool. That is cheap. 1Hive I think already passed a proposal for HNY to put into this so I think some kind of work will commence. Mostly relates to doing the Pollen distributions in a automated way on xDAI.

I think I was talking about the Maker Governance changes to add Governance delegation here - not SC governance. :smiley:
I just thought that work would come under the GovAlpha CU Budget and didn’t find a line item for that but perhaps that work is falling under Engineering or Smart Contracts group CU budgets?


Correct @MakerMan while we’re working on delegation there’s no line item as other units are taking on the more costly parts of it. The new DUX incubation team sponsored by SES just started this week and they’re the ones building out the front end for delegation.


Cool thanks.!

Thank you for the kind words both!

This work is largely covered by facilitator and contributors directly, so that’s why it’s not called out specifically. As I think Prose already mentioned, stuff like UI and Smart Contract work is being covered by other DAO (or future DAO) teams.

I think we are a good way there with https://beta.mcdgov.info/ from TokenFlow. Unless you mean analytics outside of governance? Either way, I hope @tmierzwa’s data core unit gets off the ground and can help provide more awesome stuff like this.