MIP40c3-SP7: Modify Protocol Engineering Core Unit Budget

Yes, that’s one potential option. Probably a pretty good way of dealing with the problem.

Thanks Guy, I wholeheartedly agree that value comes from across the spectrum of integrations, business development, marketing, HR and community development to name only a few. How we ensure they are incentivised is equally essential - is there a higher treasury function or some allocation model? I’m not sure. I would be happy to join any group that is tackling this broader incentive question for the DAO.

Aaron’s point about FLAP auctions could be a big part of the puzzle. It dollar-cost-averages into MKR as a routine function of the Protocol. So long as it wasn’t all spent, e.g. 50% was always burned, then the rest could be distributed proportionally, or by some other means?

1 Like

I would personally love to see a 50/50 (or some other non-absolute percentage) split of surplus instead of this all or nothing approach to filling the surplus buffer to full before any type of price appreciation. Having the different flappers siphoning vat DAI to different causes would be awesome. It’s just a matter of the Smart Contract team making all that possible lol. So they just have to create the code to pay themselves! :laughing:

The current smart contract team is the same one that helped build the MCD protocol and put it in the number 1 spot.

We’re not rock stars, we’re professional Smart Contract devs who built this system to throw off $100m a year (and growing). Our skills are highly sought after and other protocols are trying to recruit us. By lunchtime I’ll have a handful of linkedin messages trying to poach me, this happens every day. Others on the team have the same experience. Many SC team devs have succumbed to this siren song in the past year, and we need to compensate to dampen that. We’d all thrive in both tech and quantitative finance, and these numbers were adapted from leading firms in those industries.

Anyways yes, Maker, by virtue of it’s reputation, does attract the best, we just have a hard time keeping them. This should help with that.

8 Likes

Regarding the MKR part, it would make sense to just buy them on the market with a MakerDAO-owned multisig. MKR is a fairly liquid token, not a share of a private startup that has no liquidity.

Giving MKR tokens is an expense like any other. If the conversion happens today, the yearly budget of the SC Core Unit is $12.85M.

How to finance those MKR is a financial decision that has nothing to do with the budget asked for.

6 Likes

Trying to buy $12.85 MKR on the market would push the price through the roof on it’s own, but by the time this proposal is run through governance the markets would front-run and re-price the token for the event, only to tank again afterward.

The proposed solution avoids market manipulation.

The SC team has little control over whether governance chooses to burn MKR or not, so minting isolates the team from getting involved in the politics around use of surplus funds.

2 Likes

I wouldn’t worry so much about the mint. We are talking about ~1.5% of supply to cover the whole team for the full 4 years, and we are in a completely irrational bull market. For comparison YFI minted 20% of their supply for treasury and the price went up. Also keep in mind this is not new supply on the market - this is locked up for years.

5 Likes

I wasn’t suggesting to buy it in one go in a day. But we can mint it and limit the surplus buffer to have the same impact. Against that’s how to finance those MKR. I just see that community isn’t keen to the minting.

My main point was to treat is like $ at the time of the acceptance of the proposal as it’s the most logical way to account for it. If the community doesn’t want to hedge the exposure that’s a community problem, not a SC Core Unit one.

I agree wholeheartedly with everything you have said. I guess this just brings up ways we can make MKR vesting/accrual more efficient for all market participants.

Scenario #1: Maker mints 1000 MKR that sits in a vesting contract for 4 years with occasional payouts.

Scenario #2: Half of vat DAI accrued goes to FLAP auctions but instead of the MKR being burned it goes to the vesting contract until it accrues 1000 MKR which goes to occasional payouts over 4 years (in this circumstance).

Although I think that in the wash, Scenario #1 is probably more efficient, Scenario #2 is probably more digestible by all MKR holders because they get some immediate benefit from it. Would love to hear your thoughts on this.

1 Like

The original system was designed to be constantly minting and burning MKR, which we see in flap and flop auctions. If the protocol was to be considered successful, MKR would be net deflationary. It’s just worked so well that we rarely see flops, so I think MKR holders aren’t as accustomed to seeing mints.

To clarify, the dss-vest solution only mints MKR when the vest amount is claimed, so there wouldn’t be an inital increase of ~1000 MKR to total supply. It’s also the simplest technical solution to implement that doesn’t involve rewriting core system components.

2 Likes

That’s a very valid point. It’s difficult to account in the short term for tokens that will only be released in the long term.
This is probably something for an unrelated/Pre-MIP discussion, but there is quite naturally interest in the idea of MKR being used as bonuses or part-payment for teams. Accounting for that as a one-off isn’t an issue. If it becomes the standard (as I think it should in some form) then that becomes a wider question for governance.

Quite a proposal we have here.
From this I sort of read the following:

  1. There is no MKR coming from the foundation. Otherwise MIP42 or the MKR incentive in this proposal would not really make sense.

  2. Interestingly this proposal does not in any way or form mention expanding the Core Unit. Slightly interesting considering the demand for devs. If the team plans to expand please detail this. And if you plan to remain at 14 just say so. EDIT: from 9 to 14. Sorry. Thanks @Aaron_Bartsch

  3. 300K annually per dev is a king’s ransom - but OK. What I would want to see are some golden handcuffs - stay the full 4 years and you get a big DAI bag. Right now it is a bit meh.

  4. My biggest issue with this proposal is the MKR print. I don’t like MIP42 and I do not like printing MKR for any reason whatsoever except when the protocol needs refinancing. Once MKR is printed for any other reason MKR prints will be proposed for practically all good causes.

  5. I am going to be utterly rude and dare to suggest that if you make 300k you are allowed to buy your own MKR.

5 Likes

The danger here is that governance might want a standard that conflicts with the previous agreements that have been made under budgets like this one.

Aligning incentives and getting more governance tokens into the hands of those that will use them to govern Maker are critically important, but I am slightly worried that if there isn’t a standardized system up-front then it could lead to friction between contributors.

In an ideal world we should maybe attempt to handle vested MKR incentives at a wider level than individual core units.

7 Likes

He says they currently have 9 and plan to expand to 14.

1 Like

I’m not sure what’s normal, but 250k base per year + 995 MKR over 4 years is a breathtaking amount of compensation. I’m not sure what I think about that.

I’m still in shock. Okay, I’ll come back to this in half an hour. :sweat_smile:

1 Like

I’d almost rather they just double their salaries than add the MKR. Then they can just buy MKR with the extra salary (if they wish).

1 Like

Is there a spreadsheet that aggregates individual compensation levels across all core units / roles? How do other people (not smart contract engineers) on Maker payroll feel about these compensation levels?

Yes

Yeah, it is proper to include some approximate value of the tokens in the budget.

I think that is the idea

This is pretty average compensation for high tier tech & fintech

7 Likes