Pre-MIP discussion: The MKR Compensation Guidelines

Recent Core Unit budget proposals have included MKR to be able to recruit and retain personnel. This prompted a forum discussion which quickly distilled into a choice for the protocol as a whole. Either the core units make separate proposals involving MKR, or there would be an overall guideline for the whole community.

As a response members of the community initiated a working group with two core unit facilitators, Derek and LongForWisdom, as well as two representatives for the MKR holders Aes and Planet_X. The group initiated discussions to produce a guideline for MKR compensation for the Core Units.

The advantage of guidelines
The time and effort of Core Units are highly valuable to the community and while budget proposals involving MKR could be customized for each Core Unit, such an approach has the downside of consuming considerable time. There is also the aspect of avoiding creating diverging incentives as these could lessen the cohesion of the community. Additionally, the discrete yes/no nature of voting meant that some units might get everything they ask for while others end up with nothing. Given these considerations, the MKR Compensation Group believes a common guideline for MKR compensation to be highly preferable.

The necessity of a system
The simplest compensation system would be to give the same amount of MKR to everyone. However, the amounts necessary would make MKR an inflationary asset. Additionally, this structure would not aid retention or recruitment in critical core units while likely creating a tsunami of applications and proposals for most other units. The expectations for future MKR distribution as the organization grows would be enormous. Last but not least, such a distribution proposal would likely be impossible to sell to MKR holders.

With uniform distribution scrapped, we needed a way to evaluate the Core Units; ultimately deciding on the parameters of maintenance, growth, security, and market demand for personnel.

Maintenance. Peg stability, continued operation, evaluation, engagement
Growth. Awareness, education, promotion, presentation, content, integrations, scaling, collateral onboarding
Security. Assessment of risks, audits, regulation
Staffing. Difficulty to attract, retain, or replace team members

The group researched the bonus structures of world-leading technology companies. The results showed that there were huge differences in the bonuses offered to different groups of employees with software engineers offered compensation packages more substantial than even senior managers of other categories. This meant that any compensation plan taking staffing issues into account is bound to be heavily skewed in favour of the leading software developers. This is a basic fact of life which the Maker community will need to take into account. Proposed compensation for other Core Units were taken from ballpark corresponding positions at world leading tech companies or investment banks. Rounding was upwards.

Additional research revealed that positions could be grouped roughly into four tiers, which matched fairly well with the discussed evaluation made of the Core Units.

The net result was a compensation guideline that both fulfills the requirement of offering globally competitive compensation for critical Core Units, but also seeks to reward all contributors with a share of the Maker protocol.

How it would work
Different structures of compensation were discussed. The group converged on that MKR would be used for the guideline, not DAI or the dollar value of MKR. This was both due to the high degree of alignment with protocol as well as the low governance overhead involved.

The guideline proposes that MKR is transferred to the Core Unit Facilitator based on the number of full-time equivalent contributors in the unit. The Facilitator will then distribute the compensation to their team based on the situation that is most applicable to that specific unit. A small team with limited plans for growth could choose to divide the compensation equally, while a team with plans to recruit substantially with high demand for training and uncertain individual performance could choose a tiered system. This method was chosen to allow for simplicity for the Community as well as flexibility for the Core Units.

Any funds not spent should be returned to the community.

The MKR will be transferred to the Core Unit a full year after ratification of the guideline and once per year after that until the last transfer in 2025.

Proposed Compensation
NB: Some listed Core Units have yet to be approved. Others have yet to formally apply for approval. Unit sizes uncertain in some cases.

Recommended best practice for Core Units
Based on internal discussions the MKR Compensation Group has the following list of best practices for Core Units seeking to apply for MKR compensation.

  • Core Units receiving MKR are advised to adhere to this guideline when possible.
  • The MKR compensation proposal should be placed in a separate proposal, not combined with the initial budget request. This allows a new team to start working for Maker and pay salaries to the team members.
  • There should be a minimum 3-month gap between core unit approval and the application for MKR compensation. This will allow the community a chance to evaluate the core unit before compensating the unit with MKR.

The MKR Compensation Guideline towards 2025
It is the intention to inspect and if necessary revise the guideline annually towards 2025 while maintaining the core principles of the document to provide a firm foundation for recruitment and retention.

Periodic revisions will also enable the community to include lessons learned both from inside and outside the Maker community. Do note that as the protocol progresses, working for the various Core Units will most likely increasingly resemble a normal job with proportionally less risk and also less compensation.

For the purpose of establishing a DAI value to the MKR used for compensation, the price is set to DAI 2250 per MKR, which was the price of MKR on 3 March 2021 when the Protocol Engineering group submitted their budget proposal.

Team composition
All participants have been critical for the creation of this guidelines. With internal discussions largely concluded and recommendations made, Planet_X will promote the guideline towards the community, due to concerns around neutrality and conflict of interest for LFW and Derek. The presented proposal, including all argumentation, ranking, and figures, is therefore considered the work of Planet_X. Questions, comments, praise, or criticism should be directed there.

Team composition for future revisions of the guideline will be up to the community.

Feedback appreciated.

Further work
Based on this Pre-MIP and community feedback, a MIP will be formalized for RFC on 12 May 2021, intended for the June governance cycle.


Great work guys. A couple questions.

You state that it is your intention to inspect this guideline annually up until 2025 and you used the DAI price of 2250 per MKR for your calculation. Can we then assume that based on job risk/function and a price appreciation of MKR by 10x to 22500 in one year for illustrative purposes, that this compensation guideline would also go down by 10x?

As the price of MKR has already increased by 2x since the PECU Budget Proposal, what do you see as the implications going forward for them and all successive core unit vesting structures?

The PECU has a 4 year MKR compensation plan. Do you see most of the other Core Units also having similar vesting schedules? How do we structure MKR compensation so that if we approve budget proposals for MKR vesting of 4 years and MKR appreciates 5-10x each year that the amount of MKR minted would reduce? Is it a feature to lock in a MKR compensation price per DAI for 4 years?


Many thanks to all involved for this work. Having a common framework and a planned reevaluation at a set time in the future will help avoid recurring discussions on the topic.

Could you expand on what you learned by looking at existing compensations plans? I would have naively expected compensation to be denominated in absolute USD amounts or as a % of salary, with MKR:DAI updated bi-yearly (say March&September 3rd of each year). Otherwise, whether MKR price is multiplied or divided by e.g. 4 between now and next year, sticking to the price as of March 3rd, 2021 would not make much sense for next year’s compensation.

This is pretty standard for how tech companies structure RSUs. In your employment contract you get “x amount of USD in stock” at a price that is some trailing historical price, distributed over a number of years. At that moment the amount of stock that will be distributed to that individual is locked regardless of whether the price of the stock goes up or down.

It’s tricky to set the weighting for this canonical price, especially during a bull-run when price is expected to decrease substantially when the market cycle reverses. A grant amount that looks extremely high at $5K MKR/USD looks quite poor at $1.5K MKR/USD.


No argument there. I’m just curious as to how we plan to account for these types of market changes from a procedural level.

1 Like

Thank you for the work that went into this and the relative quick result since this working group was formed. These incentive models are extremely tricky and difficult to design, so kudos for this.

It’s no secret that SES is exploring an alternative model that we will be posting for feedback soon, too. We made very different choices so it will be interesting to compare the two.

I have two questions for clarification:

  • Since legal, UX/FE, integrations, but also Smart Contracts 2 are on the list: does this mean that we’re assuming there will be one legal, integrations, etc., core unit? Or would multiple, for example, legal core units, fall in the same tier?

  • The 50 team members in SES, is this counting members in the incubation program, or what is this number based on?

1 Like

Good job to the working group. Happy to follow those guidelines.

I still have two questions:

  • Why is Tier 1 so different from Tier 2. I understand the PE precedent, but that doesn’t mean we should coerce to what is already approved (we can keep what we approved and change moving forward).
  • Why is Smart Contracts 2 tier 3. Are we expecting PE to employ peoples 8x more useful/hard to hire on an ongoing basis?

Just looking at show that Product Designers gets as much as Software/Hardware Engineers for the same level. For Amazon, Software get 3x more than Sales not 8x. It is the opposite for Microsoft where sales are more important.

I wonder if the guys developing Tinlake SC at a big investment bank would be getting more than the salesman bringing deals by having a nice network and reputation.

But mainly, I’m really wondering about Smart Contracts 2. I can be fine with the rest.


And 3 and 4…

Let me take this moment to apply to any CU that will take me. I don’t even need DAI, after looking at this MKR schedule.

Not joking.

This is a tough thing to put together. Props to the folks that took this on. It’s a pretty impossible and unpopular job. I’ll buy any of you a beer/coffee as soon as gift cards hit blockchain (the true use case of NFTs)

1 Like

Thanks for taking this initiative! It’s definitely not an easy guideline to figure out and propose. I’m grateful for all the work.

I echo the same questions by Seb.

I also think if we’re talking absolute critical to the Protocol based on the parameters, Governance and Risk should also be Tier 1.

1 Like

Thanks to this team for putting in the work. Obviously, I’m going to be biased in this scenario but I can’t say I’m happy with these results.

  1. Distributing MKR is just as much about distributing power in MakerDAO governance as it is about compensating individuals for working for MKR. It’s not apparent that this has been considered in this framework.

  2. Given that Content Production is, and MarComms is proposing to, engage in marketing activities, I’m curious to hear the logic by which my Core Unit is valued at 1/3 of theirs. I’ll also echo the question about why Smart Contracts 2 would be in Tier 2. These questions about which Core Units belong in which tiers is the reason I’ve previously suggested having less tiers and since I’ve heard several people echo the sentiment, I’d like to know why the working group chose to settle on four?

  3. Part of the reason we set up this working group is to avoid conflicts of interest. I won’t deny that the compensation plan should skew towards developers but it’s apparent that the interests of developers have been represented far better than others. I’d like to see transparency regarding the research into bonus structures and compensation packages that suggest top engineers receive 8-9x (or 25x) the value of top marketing professionals.


Thanks for taking the time to put this together

Just to confirm, Oracle and Protocol Engineers will make $1,250,000 annually in MKR tokens at current prices?

I’d also mention MKR is currently extremely cheap on nearly every metric. For example, at $200M in annual fees (just 6% growth from current $189M), and trading at a conservative 2% RR FCF yield (still far cheaper than any early stage growth company), MKR is $10k/token, or a $2.5 million salary / year, which I’d argue is conservative. This 900 annual MKR dilution is not cheap by any measure.

I’m all for compensating loyal and incentivized team members well, just want to make sure it’s transparent and everyone is on the same page. We have a great team and community, and want to make sure we don’t attract bad actors or let greed get involved.

Also, if compensation is going to be this lucrative, I’d advocate for some form of lock-up to make sure incentives are aligned (i.e., bad actors don’t free-ride and then dump MKR tokens immediately upon receipt). This comp package appears far better than just about every top tech firm, and all those involved should be incentivized to help grow the protocol for the long-term.


I do have one quick question that maybe I missed the answer to and wanted to confirm:

If some of these CUs don’t materialize, we wouldn’t be recommending those MKR be allocated elsewhere, right? This is designed from the needs out and not from a total pool of MKR in, right? The reverse is also true – if more CUs appear that aren’t on here, they’re not getting MKR from some fixed pool available for compensation?

I’m certain we all know the answer to this, but setting expectations for everyone on the same details ahead of time can be important.

No. The number of MKR is fixed.

PECU had 4 years and accordingly the MKR compensation plan has a 4-year horizon to reflect this. A four-year horizon is really long in crypto and is approaching the maximum of what can be planned for while allowing reasonable stability for onboarding personnel.

There could be multiple teams, I see no problem with that. Would they fall under identical tier? Maybe, but probably not. If we onboard a Smart Contracts Team 2 straight from university I doubt they would be placed in Tier 1 with Protocol Engineering.

That is based on the SES budget proposal, I took the liberty of adding the numbers together and that resulted in 50. I hope you are not planning to add all those people right away as that would likely lead to onboarding and training difficulties.

1 Like

Tier 1 is so different from Tier 2 because the real world compensation packages are really very different. It is not that Tier 2 have substandard compensation, far from it, it is just that A-grade devs are compensated on a level that no other group can compare with.

Smart Contracts 2 (and 3,4,…n) are placed in Tier 3 to ease recruitment. In this way we can (most likely) recruit teams and spend time training them and then see if they produce code that does not result in billion dollar losses. If yes - good, after a year or two or three we can use the compensation guidelines to see if they can maybe be leveled up. Starting a team in Tier 3 should be much more doable compared to finding a PE equivalent. That is the intention at least - we will see if it works out.

1 Like

Thanks for the work in here, Working Group. We’ll be writing some comments and post them soon.

This is the link I provided when @Derek asked for the number of team members. I hope it helps.

Either smart contract engineers are hard to hire or they are not. And we still haven’t seen evidence of that. I suggested data that anyone can check (regarding the software engineer claim, You can also check the job listing of Element Finance.

I feel that judgment on perceived value is used. It feels like you expect everyone on the PE team to be A performers but peoples on SC2 to be “average” players. What if SC2 is @rain (the biggest contributor in Maker MCD repo), @equivrel and @banteg ?

In the discussions (not this WG), I heard at least twice that my team should be lower-tier but as the team does a good job it could go in a better tier (and probably because I was in the chat as well). So I understand that content production is not important for the DAO. Yet, a few tweets lead me to a meeting with the CEO of a $70+B asset manager tomorrow.

Is Governance Communication Tier 4 if they bring great family offices to invest billions in MakerDAO, be active in the governance, and secure the hat?

We might end up with a Pygmalion effect where non-Tier 1 teams see their job as not really important for MakerDAO anyway and do an average job. Excluding SES, 2 teams get 80% of all MKR, meaning governance assume they will create 80% of the future value.

Maybe MKR compensation should be based on team merits and credentials and not just on the team name. It’s not far from what is being proposed here. That might lead to good teamwork to go to higher tiers.

For sure, this is not an easy topic.


I have not yet formed any firm opinions yet, but given the looser immediate oversight the DAO has over CUs, a case can be made for paying what are known as “efficiency wages” to PE.

We need PE to not just be competent, but also to not insert some exploit themselves. I’m not saying anyone there would do that, but if someone is guarding the bank and has the keys to the vault, it makes sense to pay enough that it’s not worth taking any risks to rob the bank themselves.

Anyway, I was not part of drafting this and so can’t speak for those who did, but that was my immediate thought with regard to PE in particular.

Where do we get the idea from that it’s impossible to onboard competent smart contract teams and need to train them for years before they’re any good at all?

There is plenty of work that can be done in parallel to improve the protocol’s architecture so that we no longer have such a bottleneck. Without risking critical failure. On the contrary, starting to work in parallel will improve the dangerous situation where a single heavily burdened team is solely responsible for the protocol’s security. And if we don’t do it, competing protocols soon will and Maker will start lagging behind.

I really see no reason not to compensate new teams based on their competency. A cliff vest can hold them accountable until the point where they start delivering the results.