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?
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.
From the glossary in https://docs.makerdao.com/other-documentation/system-glossary#vat-vault-engine "
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.