MIP40: Budget Framework

MIP40: Budget Framework


MIP#: 40
Title: Budget Framework
Author(s): @juanjuan
Contributors: @elprogreso, @iammeeoh
Type: Process
Status: Formal Submission
Date Proposed: <2021-01-18>
Date Ratified: <yyyy-mm-dd>
Dependencies: MIP38, MIP39, MIP41, MIP4c2-SP10, MIP4c2-SP12
Replaces: n/a



Sentence Summary

MIP40: Budget Framework contains a framework for managing budgets and modifying them in the DAO Primitives State MIP.

Paragraph Summary

MIP40: Budget Framework contains a framework for managing budgets and modifying them in the DAO Primitives State MIP. The Framework includes features to provide transparency and clarity for Governance when making decisions around budgets and a design that enables a high degree of flexibility in implementing payment structures for the Core Units.

Component Summary

MIP40c1: Budget Framework
Gives an overview of the most critical characteristics of Budgets.

MIP40c2: Composition of a Budget
Describes the components of a Core Unit Budget proposal.

MIP40c3: Adding/Modifying Core Unit Budget Process
Describes the process for adding a budget to a new Core Unit or modifying the Core Unit’s existing budget.

MIP40c4: Budget Implementation Details
Provides clarity on how the budget payouts are addressed from a practical perspective once approved.


The Budget Framework MIP allows Governance to manage and prioritize Core Units in a standardized way, promoting transparency and reducing Governance overhead and minimizing abuse and increase fairness in the budget process.
The budget system gives Facilitators the flexibility to modify their plans away from the initially submitted budget breakdown if conditions were to change. If they need to allocate the money differently, this would be possible but never exceeding the aggregate amount defined by their Budget Implementation code.
The Framework can help Governance guide a given Core Unit, as they could vote (or not) to attach multiple budgets to a Core Unit, each with a different, more specific objective.

Specification / Proposal Details

MIP40c1: Budget Framework

Budgets are used to fund the work defined by the Core Units chosen by Maker Governance. A budget is attached to a Core Unit and is meant to be used only for that Core Unit.

The Facilitators of each Core Unit administer core Unit budgets.

The Core Unit Facilitators must ensure that transparency and accountability exist as the budget is spent.

If a Facilitator is offboarded from their Core Unit, quits, or goes missing, the budget will continue to be available to pay out according to its Budget Implementation to allow the Core Unit to continue with long-term operations as much as possible. See MIP41c6 for details on this process.

MIP40c2: Composition of a Budget

Core Unit Budgets can have multiple entries. Each entry has both a Budget Breakdown and a Budget Implementation.

Having multiple budget entries, each with its implementation and breakdown, enables more advanced compensation and funding structures to be created if desired.

Once a budget is approved, the Core Unit’s Facilitators can begin drawing payments to fund their Core Unit according to their Budget Implementation.

Budget Breakdown

The Budget Breakdown component consists of the Core Unit Facilitators’ best guess breakdown of spending for their Core Unit during the budget period.

The Budget Breakdown component is non-binding and is intended to encourage transparency and communication between the Core Unit Facilitators and Maker Governance. The breakdown allows Maker Governance to make a more informed decision when deciding whether to approve the budget.

Budget Implementation

The Budget Implementation defines when and how the Core Unit Facilitators will receive the funds that make up their budget.

Unlike the breakdown, the Budget Implementation is binding. It should be understood to directly authorize the proposed funds to be drawn from the funding source (either the Maker Protocol or a treasury contract controlled by Maker Governance).

MIP40c3: Adding/Modifying Core Unit Budget Process

This subproposal process modifies the Budget Implementations and Budget Breakdowns entries of a Core Unit in the DAO Primitives State.

Once a MIP40c2-SP subproposal passes, the Governance Facilitators or the MIP Editors will update the domain state MIP (MIP38) accordingly.

This is a technical process component that can have on-chain effects that alter the Maker Protocol’s state. When subproposals generated from this component reach the executive vote stage of the MIPs cycle, the executive vote must include a technical state change to authorize the budget implementations specified in the subproposal to draw funds from the Maker Protocol.

The proposal parameters are:

  • Minimum feedback period: 1 month.
  • Minimum frozen period: 1 week.

MIP40c4: Budget Implementation Details

Core Unit Budgets are paid out through Budget Implementations, which are smart contracts authorized by Maker Governance to draw funds from the Protocol. It can also be a manual (not smart contract-based) pre-approval by Governance.

Facilitators can propose simple, manual or advanced Budget Implementations that will control their access to the Core Unit’s budget.

Maker Governance can explicitly turn a budget implementation off.

Simple Budget Implementations

Simple Budget Implementations create a fixed rate of funds taken from the Protocol and given directly to the Core Unit’s Facilitators.

Simple Budget Implementations can be used for reliable base expenses, even if MKR has to be diluted to fund them. This feature makes them useful for creating job security and attracting talent.

Manual Budget Implementations

Manual Budget Implementations are discouraged but exist as a backup solution that can stand in if a Simple Budget Implementation isn’t available for any given reason.

Manual Budget Implementations aren’t based on a smart contract but rather on Governance, giving a Facilitator the power to use the governance cycle to draw funds at the rate specified in the DAO Primitives State.

Manual Budget Implementations should be replaced by smart contract-based solutions as soon as possible to reduce Governance overhead.

Advanced Budget Implementations

Advanced Budget Implementations cover any mechanism beyond the Simple and Manual Implementations described above.

Advanced Budget Implementations can be used for more innovative cases, such as incentive payments or unpredictable expenses. They can be implemented in various ways, such as relying on multi-sig access or dependent on system variables such as Protocol auctions, Dai supply or Stability Fees.

Advanced Budget Implementations can also be used to hard-code payment streams to long-term contributors or other automated distribution mechanisms that bypass Core Unit Facilitators and send funds directly to contributors.

Different Fund Types

The Budget Implementation could draw funds from the Protocol in various ways, depending on the implementation’s objective. It could draw Dai from the Surplus Buffer and other sources, such as Governance owned smart contracts or reserves that are compatible with Budget Implementations, or by getting authorization to print MKR directly.

Printing MKR through this MIP is only allowed if the MKR is to be distributed with a programmed time-lock of at least 12 months. Budget Implementations that don’t verifiably distribute MKR with at least a 12-month time lock cannot be proposed through this MIP.

Edit: Incorporated feedback for clarity, added to my github (accepting PRs) and also PRed the Maker Github.
Thanks to @blimpa, @Deimos, @LongForWisdom, and everyone else that helped with the revision.
Edit2: removed the MIP4c2-SP11 from dependencies, moved to formal submission.


MIP40c3: Modify Core Unit Budget (Subproposal Process) Template


MIP40c3-SP#: #
Date Applied: <yyyy-mm-dd>
Date Ratified: <yyyy-mm-dd>



  • Why are you proposing this Core Unit Budget modification?

Core Unit ID

  • Specify the Core Unit ID.
  • This element specifies which Core Unit you are proposing to attach the Budget to.

List of Budget Implementations

  • This element must contain a list of at least one Budget Implementation. Each Budget Implementation must follow this format:

  • Is it a smart contract Budget Implementation, or manual Budget Implementation?
    • If it is a smart contract Budget Implementation:
      • what is the ethereum address that the smart contract is deployed to?
      • what kind of authorization does it need (suck authorization, authorization to draw funds from other smart contracts, etc.)
  • What is the amount of Dai or other assets per month that the Budget Implementation will pay out (if any)?
    • If it is a manual Budget Implementation, at which week of the month will the executive vote to pay out the budget for the month be submitted?
  • What are other circumstances that the Budget Implementation will pay out Dai or other assets, and how are the amounts determined?
  • Any additional notes and clarification about how the Budget Implementation works.

List of Budget Breakdowns

  • This element must contain a detailed Budget Breakdown for each of the Budget Implementations in the element above. Budget Breakdowns aren’t binding, but should provide as much clarity as possible to governance about how the monthly amount or other circumstances for payouts where determined, and what the current plan for their use is.

This may need to be amended if MIP34: Keg Streaming Payments Module is implemented. I imagine the flights, which are a list of target addresses along with the relative weights of how much each address should get, would correspond to Core Units and Domain Team budget addresses.

Or maybe not, and the flights are reserve pools, one being for Operational Expenses, which then each Budget Implementation can “suck()” or whatever the payout mechanic is.

1 Like

Thanks for all your feedback, @Davidutro.

The idea of this budget framework is to link any implementation of a budget to a Core Unit.
If the Keg is not ready, we might need to start with manual suck() (less ideal) and potentially use a Simple Budget Implementation (such as the Keg).
In the future, I can see other implementations being used with this MIP.

The main idea is to link any given implementation with a Core Unit to make it future-proof.

I hope I’m clear.
PS, you gave me a couple of good ideas to make the MIP clearer. Thanks.


Again, should go more in-depth if possible. Why this implementation over some other implementation.

Bullet points are maybe not the best way of formatting this. Again, better than wall of text, but could use better formatting to be more reader-friendly.

I don’t think this should be included. It’s a value judgement that may not be true for all Core Units, or all budgets.

Also not sure that this belongs in this MIP. Why are we defining what contributors are in a budget MIP?

I’m also not sure that it’s true that all contributors will be funded by Core Unit budgets. Some contributors aren’t paid, some will be paid by outside interests, etc.

What does this mean? Multiple versions?

This should be structured better. Key parts of this component are Budget Implementations and Budget Breakdowns. They deserve subheadings. Also, this is a bad explanation of what a Budget Implementation actually is. There should be a sentence that says something like ‘A budget implementation is a method and agreement of how to deliver the agreed funds into the control of the Core Unit Facilitator from the Maker Protocol’ (or something, I’m not 100% sure that is what this is.) Also, since sucks each require a governance vote to pass, they are not binding, even if the MIP wants them to be (and even though they should be.)

Again, we’re missing a sentence clearly stating ‘A budget breakdown is…’

This is stated weirdly. I think the target statements are

‘Facilitators have the authority to deviate from their stated budget breakdown as much as they feel is necessary as long as they can justify how it helps them achieve the goals of their Core Unit.’


‘Facilitators cannot exceed their aggregate amount defined by their budget implementation.’

Comments on why these statements are included belong in the motivation section.

Who updates this…

Defining the suck function here forces us to use that implementation method. This should be more general such that it can apply to the keg, or whatever other methods we use in the future.

This should come before MIP40c2. Also maybe just renamed to ‘Budget Implementations.’ Or maybe Budget Distribution or somesuch. Maybe avoid the word process given this isn’t a process component.

Also, same issue with wall-of-bulletpoints.

This does not take into account Advanced Budget Implementations that do not use suck.

I would probably split this section into ‘Manual, Simple and Advanced’ budget implementations.

Not a good idea (and something I’m not personally comfortable with,) funds should be held by a multisig.

Many will not understand the mechanism at play here, so it should be explained in more detail.

I have no idea why this is here or what it’s referring to. Is it referring to the print of MKR due to fixed suck calls with a zero surplus buffer. Is it referring to people being paid in MKR? I assumed this was locked to DAI, if it isn’t locked to DAI, maybe it should be? I would just fix this to payments in DAI, and if we want to budget in MKR we handle it in a different MIP.

1 Like

Edited incorporating feedback + PR in github.