Signaling Request: Should Maker make a Treasury to manage revenue?

That make sense. I agree with you.

Like you said it’s better to do it now , because time goes fast and this community grow even faster.

You have a very good opinion there and i support you into this direction.

This is the key part. Many people are currently spending their time on this project (myself included.) Personally speaking while I don’t think i would disappear were I no longer paid, I wouldn’t be able to justify spending the amount of time on this project that I do currently. I need to eat.

We will need to have a treasury, and it will need to be funded from the stability fee income (there is no other income stream generated by the system.) While we could mint and sell MKR to fund the treasury, this is functionally the same as using the stability fee income because otherwise that income stream burns MKR. My hope is that the treasury functionality will be on-chain and that we will not require a ‘Treasurer’ position.

Given that I’ve been thinking about this for a while, let me lay out what I see as the most probable future in terms of this subject.

  1. MKR Token Holders have already agreed that oracle fees should be paid out of the stability fee income generated by the system.
  2. Because of this prior agreement, it is likely that this will be the prototype case.
  3. Because oracles operate at least partially on-chain, I suspect that the functionality for paying other on-chain entities using the system debt buffer will be developed. This has the advantage that money will be taken from stability fees when available, and if not available the system will print MKR using the existing mechanisms.
  4. Because the oracle fees are an on-going cost, I suspect that whatever mechanism that is developed will be capable of paying a re-occurring ‘salary’ to on-chain entities. This will almost certainly require a vote by MKR Token Holders.
  5. With that proof of concept, we will have everything we technically need to pay arbitrary addresses for services supporting the Dai Credit System.
  6. At that stage I predict that either the Foundation or the community will start pushing for a ‘transfer’ of personnel from the Foundation to the Dai Credit System, probably starting with the Governance Facilitator (assuming MKR Token Holders ratify this.)
  7. At that stage ‘balancing the books’ becomes a thing that MKR Token Holders need to consider, I am doubtful that this will require a paid position as all data will be available on-chain.
  8. I actually think it is more likely that we will need a Human Resources type role before we require a treasurer role.

Yes, this is right @LongForWisdom

I must be too much enthusiasms about contribution here and forgot about the real life aspect.

1 Like

First with respect Planet_X and Sirlupinwatson1 the idea that everyone from the community is going to ‘donate’ their time to enrich large MKR holders for free is simply is unsustainable in the long run.

Yeah. Ahem. About that… I have had a change of mind. Maker governance is simply not going to work without incentives. There is going to be so much work that working for free is out of the question.

1 Like

I think this distinction is important and i agree with it. There is no need for a treasurer position in the foreseeable future.

On-chain would still required supervision, less of course but still.

After some rude test and deep evaluation it would be beneficial. But i think on the side that abusing could be a major factor.


I agree. I am also spending my time here w/o compensation but I have donated my time to other projects that I see I might be able to help move along. Not being compensated effectively means I can come and go as needed for my family etc. Which is the best thing about on-line work (in most cases ability to just meet deadlines vs. having a formal 9-5 type job)

Sounds like most of us are agreed we need a treasury and it will require a vote. I think you are right that probably first things to pay for are the oracles. I think peoples thinking here is that there are other positions we will need to pay for first other than a treasurer since everything will be on-chain and auditable. Like I said lets just go at this one step at a time and just drive through it with decent thought and care.

Agree to make a treasury, come up with consensus on when/how (much) to fund it from fees and then once we have funds and a means to disburse them we can start to think about how the treasury should act, and what recurring fees to take on.

In the end pretty much agree with all the subsequent comments here and your well done list above.

I’m not sure much more needs to be discussed at the moment other than what level we want the funding to start, and how to implement the mechanics of funding the treasury from SF fees. Once this starts rolling perhaps we start another thread regarding how the treasury should operate, what recurring fees we should be paying what positions to on-board first, what level of compensation for what responsibilities.

I do see that the community needs to pull back and pay for the domain names associated with Maker to put these in the IP/Trademark/community ownership hopper so we should put that in the list above as well.

I think the next step after formally authorizing the treasury as well as access/payment mechanics is to get some kind of list from the Foundation of what they see as the first things to off load to the Dai Credit System for management/payment.

One thing that came to mind is all this is going to have to go through governance cadence (i.e. authorizing MIPs, payments for work, etc.) So your right someone to handle governance issues, cadence, managing details of that is probably a key first position.


I make pizza for work now, so I eat. If maker could let me not eat pizza that would be swell. :crazy_face: :crazy_face: :money_mouth_face:

1 Like

This would definitely be interesting to see. @Derek does the Foundation have anything like this?

Hi @LongForWisdom, I do not believe we have created a list of responsibilities to offload for management/payment. I’ll start giving this some thought as well as a means for implementing this (MIPs?).

Also, above was mentioned ‘mechanics’ …fyi, there is a suck function built into the system as a mechanism that governance can call to fund projects/initiatives/payments etc.


Just read up on the suck function. Am I correct in understanding that this is currently usable via executive vote, or does it require an additional contract module that doesn’t currently exist?

1 Like

Yes, @LongForWisdom , it is existing and could be accessed via executive vote.

…Depending on how a treasury function is structured and any complexity that it introduces, there is no reason why we couldn’t have an additional contract module to delegate payments or have decision rights for certain sub-tasks.


If a volunteer stops volunteering then the role is not fulfilled and the project stalls. Therefore, large stakeholders will be the most financially incentivized to hire the appropriate resources for that position. Appointing people through a centralized treasury system is fraught with potential issues relating to social biases including outright bribery. For example, if I was ripple, I could financially incentivize the risk team directly and off the books to give XRP a much better risk profile than it otherwise deserves, especially if the risk team feels it’s not being adequately remunerated. Interfering with the incentives of large stakeholders to appoint the people they want to the project introduces further uncontrollable human biases into this project. This aspect should be carefully evaluated before any further steps are taken.

Fair in my mind an ‘account’ or ‘treasurer’ would be nessesary when the dao has many complex obligations or wanted to invest in other projects or take on debt. They wouldn’t have control they would just recommend budgets and whatnot.

A similar issue was extensively discussed for Ethereum’s EIP 2025, I suggest reading up on these discussions to benefit from the learnings. Pretty strong no from the Ethereum community.

Maker is a system structured completely different from ethereum. While studying the decisions they make and why will always be useful, by itself their decisions have no reasonable equability with Maker.

The buffer already exists, which is analogous to the concept of a treasury. The protocol already gives MKR governance the ability to pay DAO teams and oracles - a basic function which is necessary for survival of the system. Specifically this is called the “suck” function, which allows governance to do payments out of the buffer.

Now one thing that’s very important to understand is that it isn’t safe to increase the size of the buffer to hold a significant amount relative to the total Dai supply. This is why it started off at the low value of 500k. It is necessary because the buffer is distributed to Dai holders in an emergency shutdown (so Dai holders actually get slightly more than 1 USD in an ES under normal conditions). The problem is that if the buffer gets too large, this “ES premium” will become an actual incentive that skews the game theory. It could both impact the peg and make it harder to stabilize the price of Dai, or even worse, actually incentivize an ES to be triggered by Dai holders to harvest the buffer.

The best way to pay DAO teams and oracles given the constraints on the size of the buffer, is to do payment streaming - paying teams directly out of the buffer on a second by second basis, with the actual transactions happening at regular intervals to ensure that the buffer doesn’t hit its limit and that there aren’t unpredictable swings in buffer size which could impact the liquidity of surplus or debt auctions. This is achieved by using instant access modules, special submodules with a specific functionality that are given authorization to call critical functions like suck on the core system, but within hard constraints that are inherent to the instant access module itself. So e.g. if governance wanted to start paying a DAO team 300k Dai per year, they would set up an IAM with the authorization to call suck, but the IAMs logic itself would prevent it from doing more than 300k per year, on a continuous pro-rated basis.

A more difficult question is: How to handle compensation of DAO teams? Does governance choose to pay like wall street, paying top 1% salaries to hire, and retain, world class talent mostly out of financial centers, or like universities and governments paying public servants a lower rate than the private sector, with the understanding that it will be more junior candidates from all around the world, who will have a higher turnover but also be motivated by the prestige and career opportunities that a few years on a DAO team will give them - or a combination of both?


It’s a social issue that spans across technology systems.

1 Like

From the glossary in " suck : mint unbacked stablecoin (accounted for with vice )." Unless I’m misunderstanding The suck function mints unbacked Dai. I would need to be convinced that thats a safe and secure (from a social and risk perspective) way of funding labor. Wouldn’t mixing labor costs and a budget in general with the buffer complicate risk questions?

To me a simpler design of a treasury would be beneficial. I dont understand the system well enough, but shouldnt it be possible to just divert a set percentage of the value from value fees (not going to dsr) to an address that the chief controls.

The last question is definitely harder. I find it unlikely that there will be one mode of compensation. Different work can have different compensation structures. I’m writing more on this currently so I wont go in to it right now, but I suspect we will go towards a multidivisional structure where the elected head or facilitator of each group are under salary from the DAO and handle compsenation within their division (facilitators get a budget from the dao). This way community/gov stuff is under a different compensation mode than integrations or risk which have different needs/goals.

There needs to be debate on a fair capital/labor split of revenue if we are going to compensates anyone.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.