Is Maker complete? Are we done improving the Protocol? Should we burn the admin keys and let Maker run its course?
Some of us believe that we are just getting started, that Maker is ripe for hypergrowth, precisely what we want to achieve. The MKR we’re asking for is no different than a startup raising Series A. Yes, it will dilute the token holders, but the goal of that dilution is the sought hypergrowth.
The Slippery Slope Argument
“Minting MKR is a slippery slope.” Governance will (arguably) always have the power to mint more tokens. A Decentralized Maximalist might argue that having the admin key to change the code is the beginning of the slippery slope.
The slippery slope argument sounds more like a motion of no-confidence towards Governance. And it’s by no means invalid. But if we do not trust Governance, we should frame it that way.
The Social Contract
MKR is burnt when things are going well and minted when needed.
These needs might vary:
- recover bad debt (we’ve seen this in the past)
- raise funds to grow (we’ve also seen this in the past; that’s why we have investors)
It seems that we have forgotten the second need.
The Market Value of Valuable Contributors
Every single worker has a market value. Right now, the industry dictates that a given person will earn a given amount that might seem fair or not. For example, there is no shortage of projects that will take any Maker developer without blinking before lunchtime.
Should every contributor get MKR tokens? Maybe not. We will need to decide as a Community how much we want to align to the industry and how much we choose to override.
Base Salary versus Bonus
Most have agreed that the “base salary” should come from the surplus buffer to provide job security for the Maker contributors; some argue that any “bonus” should not.
Usually, a worker will look at their total compensation package and decide if that is competitive or not. You can name each piece of the compensation however you want, but removing certainty to any of those parts will make the deal less attractive.
An extreme implementation of that argument could hold that we should only pay minimum wage to our employees. Anything above that is a bonus that the contributor should only get if the Protocol is faring well.
Making the total compensation package less certain will make our offers less competitive and hinder our capacity to attract talent. We should be worried about attracting the wrong talent: that is the actual slippery slope.
If they are only here for the money, then…
I have also heard that money should not be the primary factor for hiring someone. I think we all agree on that one. However, this should not mean that we need to underpay our contributors — much less not pay them at all. I don’t want any core contributor to consider an external offer because we are not competitive.
How about if instead of minting we…
We need MKR that is readily available to compensate people. Minting seems to be the easiest, direct answer to solve this need.
Any other creative solution seems to carry risks of slippage, front-running, or both. What’s more, there might be risks attached to using elements such as the Surplus Buffer for things that are not intended.
Things To Agree
Should we burn the admin keys?
First, we will need to agree on what type of project we are. Is this it? Have we achieved maturity? Do we let the burn bring value to the token holders? Should we consider burning the keys and ensure that Governance cannot change this (the code is the law) ?
Do we want (hyper)growth?
We need to decide if we want hypergrowth. To raise the required capital (MKR), we will need to mint.
As an option, we might want to choose to be a bootstrapped project and only use the money we get from revenues. If that is the case, we need to be clear upfront about it and let contributors decide if they want to stay in a project with this constraint.
Do we want an overarching framework?
We probably don’t want to have this same discussion every time a Core Unit comes up with some compensation scheme. Ideally, we can agree on something that we can reuse (and review from time to time).
Framing a Framework
Do we align with the industry and compensate with tokens (MKR)?
What is the best way of obtaining these tokens? (reduce slippage, avoid front-running, etc.)
Do we want to include a vesting period, a cliff, and weighting (you get more on your fourth year than in your first)?
How often should we review this framework?
Which teams/contributors get MKR tokens?
How much MKR should they get?
What happens when a contributor changes Core Units?
We will have a Community Call on Wednesday, 31st, to discuss these topics.
We will probably need to form a working group to tackle this issue and present a decent framework to the Community and teams. Please write to me if you’re interested.
Bonus: a diagram
How much are we minting?
- 100 contributors (will we have that many?)
- at the suggested 0.1% rate (most will get less)
- stay for four years (turnover suggests it will be less)
Then we would be minting 10% of the total supply.
Edit: added link to the call.