MIP40c3-SP7: Modify Protocol Engineering Core Unit Budget

MIP40c3-SP7: Modify Protocol Engineering Core Unit Budget

Preamble

MIP40c3-SP#: 7
Author(s): Smart Contract Domain Team
Contributors: N/A
Status: Formal Submission (FS)
Date Applied: 2021-03-03
Date Ratified:

Sentence Summary

MIP40c3-SP7 adds the budget for the Protocol Engineering Core Unit.

Specification

Motivation

I am proposing this budget for the Protocol Engineering Core Unit to be able to succeed in its mandate, specifically; to extend the functionality of the Maker protocol, assist with the maintenance and operation of existing smart contracts and ensure the safety and correctness of protocol design and implementation.

The team’s scope involves a significant level of responsibility and exposure, demonstrated by over $7 billion of total value locked in the Maker Protocol. This is coupled with the constant and necessary addition of collateral types, executive votes and code reviews to ensure protocol safety and growth.


New Information: The title of the team has been updated from Smart Contracts Core Unit to Protocol Engineering Core Unit to better reflect the longer-term growth and our mandate to support ongoing protocol implementation, growth, and safety/security.

As per the recently updated Protocol Engineering Core Unit MIP (specifically; Motivation, Team Structure and Layer2 Development sections), this proposal has been updated to include two additional senior engineers focusing on growth and innovation, specifically Layer2 development. All data has been updated to reflect this addition below.


Core Unit Name

Protocol Engineering Core Unit

Budget Considerations

The following considerations have been taken into account when building the budget to ensure a competitive package that allows the DAO to retain and attract talent by providing:

  • A competitive salary in-line with industry standards
  • Healthcare to compete with traditional company offerings
  • Travel budgets to promote team visibility and speaking at industry events
  • A sign-on bonus to attract new employees

There is also recognition to support the team by removing blockers and covering overhead costs involved in daily work, including:

  • Hardware for smart contract deployment and independent testing
  • A bug bounty to promote engagement with community whitehat hackers
  • Funds to support audit activities and code reviews for security awareness
  • Funds to cover gas and contract deployments
  • Overhead support for team filing, accounting, legal and reporting
  • A buffer to accommodate unforeseen costs

Compiling the above considerations along with market/competitor research has helped define the following budget.

Budget

The yearly budget request for the Protocol Engineering Core Unit is $6.12m. This equates to a $510k monthly expense to support the team mandate.

This budget secures a team of 11 - 16 full-time and part-time smart contract engineers, including a team facilitator. It also includes coverage for all operational costs, audits and overheads as presented below;

Summary
Salaries $4,240,250
Healthcare $228,000
Travel $180,000
Hardware $45,000
Referral & Sign-on Expense $100,000
Audits $375,000
Bug Bounty $100,000
Gas Costs $150,000
SC Verification & Quality Assurance $376,000
Legal and Operating expenses $28,500
Contingency Buffer $297,250
Total $6,120,000

Illustrating these details as a percentage of the total budget request for overall comparison:

Budget Details:

Providing additional detail with regards to the above line items;

Salaries: The current team has 9 full-time smart contract engineers, 1 part-time smart contract engineer, and 1 proposed Team Facilitator (for a total of 11 members). The team is seeking to grow this by 5 members to a total of 16 members. This opportunity to scale will enable us to better meet the demands of the community.

Healthcare: In order to align with traditional company offerings, this proposal includes a healthcare supplement averaging $1188 p/month for full-time employees, based on residency to account for local cost variations.

Travel: Engineers may travel to present at industry events or participate in a team offsite.

Hardware: In order to ensure we are able to run multiple ETH nodes to support testing and contract deployment, a supplement for a Dev machine (e.g. Intel Quad Core i7-8565U, 40GB RAM, 512GB NVMe) and test node (e.g. Intel NUC; i5-7300U 2.6 - 3.5 GHz Dual Core, 32GB RAM, 2TB NVMe M.2.) will ensure the team has the hardware in place to achieve this.

Referral & Sign-on Expenses: Provided at the discretion of the Facilitator to attract top talent to the team.

Audits: We have accounted for approximately 5 audits (depending on the size of the code base being assessed we may need to revisit the budgeted allowance - to be approved by Governance). Typically we work with Gauntlet, PwC, Certora, Quantstamp, Trail of Bits, Consensus, OpenZepplin and Peckshield.

Bug Bounty: Bug Bounties allow us to support whitehat involvement in the work we do. Payout amounts will be assessed and determined by the team. $100k is a conservative number for this line item, any increase will be discussed and assessed with Governance.

Gas Costs: Based on our deployer addresses in 2020, we spent $36,367 in gas. The 2021 budgeted amount has been extrapolated from the last quarter of gas usage which has seen significantly higher gas congestion.

SC Verification & Quality Assurance: Part of the team’s focus is on protocol security by verifying high-level properties of the system along with low level bytecode verification. This involves; full year engagement with a 3rd party, dedicated resources and the use of external tooling, to ensure repeatable quality assurance across smart contracts and the development of new tooling.

Legal and Operating Expenses: Coverage for managing general operational overhead, legal costs including entity creation, legal officer/company insurance, as well as monthly and annual financial reporting.

Contingency Buffer: Approximately 5% of budgeted costs to be sidelined in the event that we underestimated this budget cycle.

MKR Vesting

The Protocol Engineering Team is proposing to award 0.1% of the existing MKR supply to each full-time team member, (equivalent to 995 MKR) vested over 4 years.

Example payout:
Each person staying with the project for the full first year will be entitled to 25% of their award - the equivalent of 248.75 MKR. For our team of 16 (including both full and part-time employees) this is a total of 3855.625 MKR to be awarded at the end of the first year.

For reference, our current annual MKR burn is 34,054 MKR or 3.54% of remaining MKR.

Details:

Protocol:
Current MKR supply: ~995,000 MKR
Current annual MKR burn: 3.54% (equivalent to 34,054 MKR)
Proposal:
MKR minting: Governance using DssVest will mint MKR
Allocation per full-time individual over 4 years: 0.1% (equivalent to 995 MKR)
Allocation per part-time individual over 4 years: 0.05% (equivalent to 497.5 MKR)
1 year cliff for full-time individual: 25% of allocation (equivalent to 248.75 MKR)
1 year cliff for part-time individual: 25% of allocation (equivalent to 124.375 MKR)
Total vesting period: 4 years.
Vesting schedule: 25% at the end of the 1st year, 75% at equal increments over the remaining 3 years.
Number of team members: 16
Total team MKR over 4 years (15 full-time and 1 part-time member) 15,422.50 MKR
Total team MKR at the end of 1 year (15 full-time and 1 part-time member) 3,855.625 MKR

What the budget does not include:

Additional Audits: We have budgeted for up to $375k in audits, each audit typically costs between $50-$100k. If we exceed this amount, we will request further funding and approval from Governance.

Increased Gas Expenses: We have budgeted up to $150k in gas costs. If we exceed this amount, we will request further funding and approval from Governance.

Keeper costs: We expect a technical/operations domain team to maintain Keepers, including chief keeper, cage keeper, auction kickers and more. As a result, we have not accounted for maintenance or gas costs of keeping keepers operational.

Conditions - Continuous Operation

To ensure 3 months of continuous operation in the event of emergency shutdown or protocol issues, the Protocol Engineering Team will be requesting an upfront lump-sum of $1.3m to sit in a protocol owned multisig.

Calculation:

The lump sum is the equivalent of 3 months of budgeted salaries and essential team expenses.

Detail:

  • The lump-sum will be held outside of the surplus buffer in a protocol owned multisig
  • If normal protocol operation is not possible due to emergency shutdown or other protocol failure, these funds will be used to ensure employment resources get the system back up and functional
  • At the conclusion of the year, the lump sum will remain in the multisig for the following year and may be increased at that point in time due to team growth or the desire for an increased runway.

Updated multisig details for clarity - Smart Contract Implementation

Protocol Engineering Core Unit Multisig:
0xe2c16c308b843eD02B09156388Cb240cEd58C01c

  • Implementation: Initial distribution to the Core Unit multisig will be manual until the Keg is in place.
  • Ownership: This multisig will be anonymous individuals selected by the Protocol Engineering Team.
  • Frequency: Protocol distributions to the multisig will occur during the last week of the month.

Protocol Engineering Continuous Operation Multisig: 0x83e36aAA1c7b99E2D3d07789F7b70FCe46f0d45E

  • Implementation: This multisig will be funded in full upon successful onboarding of the Protocol Engineering Core Unit.
  • Access: In order for funds to be accessed from this multisig, the Maker protocol must be in a state where it is unable to pay team salaries due to protocol error, shutdown and/or under governance attack.
  • Ownership: The Continuous Operation Multisig will require 3 of 6 signatures from the following keyholders. This may be expanded to other critical Core Units as they are formed:

Derek (Protocol Engineering): 0xe3a76328edE8Fd61d5fA7840b878Dd69cdfD67d8
Nadia (Growth CU): 0xc8E6c287F6c127AFE5e4CB30bC440607b44c35f8
LongForWisdom (GovAlpha) : 0x66f40F044E0e2F77bB746e3275E82e88dCBA2D69
Primoz (Risk CU): 0x5d67d5B1fC7EF4bfF31967bE2D2d7b9323c1521c
SebVentures (RWF): 0x0D61C8b6CA9669A36F351De3AE335e9689dd9C5b
Cmooney (Protocol Engineering): 0xEeF3026eF864C9398c008195E65d16D9cb42a512

For transparency: I had previously identified keyholders as CU multisigs (namely: Protocol Engineering, the Interim DAO Multisig and the Growth CU), however due to complexity of using nested multisigs, I updated this to individuals.

26 Likes

Salaries look great. Couple questions about the MKR vesting. I assume this is related to MIP42: Proposed Compensation Addendum for MakerDAO Contributors. I don’t know how others feel in this regard but would it not make sense to have the amount of MKR vested to you be in relation to your salaries as opposed to a flat MKR rate? Also I’m having trouble clarifying whether this is new MKR minted or MKR bought from the market with DAI at time of vesting or some other implementation. Thanks in advance.

6 Likes

@Aaron_Bartsch It looks like this MIP is going with a different implementation of MKR vesting. I’d like to believe MIP42 sparked a conversation about vesting. I think each team can / should decide how to vest each member on an individual basis. Doesn’t need to adhere to a strict % of the salary per se.

Thanks Aaron! Yes, it is directly related to Brian’s comment in that thread, utilizing the DssVest module.

This module would allow the minting of new MKR - so as long as the amount of MKR minted is less than the burn rate, MKR would remain in a state of net deflation.

I chose an absolute MKR value as a percentage of existing supply due to simplicity and the ability to provide all members with an equal incentive. Looking at VC’s this seemed to be an industry standard approach to equity sharing.

6 Likes

Oh, we would be minting new MKR? but only if it’s less than burn?
Why not take out a portion of the MKR before burning it?
(Maybe there’s some technical reason why this other implementation is better)

1 Like

Thanks for the quick reply. That is what I assumed from the wording. My intuition is saying that this seems a bit high but if other’s think it’s fair then I won’t complain. People with more knowledge on industry comparables and competitive retention can further weigh in.

It would be great if this new MKR could somehow contribute to positive price appreciation.

1 Like

@Aaron_Bartsch The space is really competitive right now. Retaining talent when other protocols are paying so much is hard.

I think the proposed vesting amounts are fair.

2 Likes

I cannot give enough hearts to this. The deflationary narrative of $MKR must be preserved! We aren’t the printer-happy $YFI crew (shoutout @banteg). MKR should only be inflationary if this system is acting poorly.

Other than that, I cannot agree more with the SC dev package. Maker is one of 3-4 CORE Pillars on Ethereum, and we must incentives our talent enough to avoid distractions. If we had this earlier maybe we wouldn’t have lost @nanexcool and @cyrus to the farmers… the world will never know

5 Likes

I 1000% support this SC Core Unit Budget. And before you start thinking about the minting of MKR, we should be thankful that they are showing a long-term commitment via 4 year vesting, broken into 25% per year (in-case they leave–which I hope they won’t)–honestly this is a bargain for the Maker Community.

And don’t forget-- the most underrated and best kept secrets in the entire DeFi Universe is the MakerDAO Smart Contract Team. Let’s give them our support as one unified community. We are lucky to have them at these low rates. I’m being 100% genuine.

10 Likes

I assume this is a first offer in somewhat good faith, giving the community a chance to negotiate and get these numbers back into the realm of the real world. I am all for fair compensation but this goes beyond that and gives it a multiplier. If we need to look elsewhere for talent what is the process for that? thank you!

Also if we the community are going to pay 850k (if MKR goes back to 3k and it looks like its going higher) per dev (i assume all these people are devs — i would hope so) — then this should go out as a wider job offering. For that money every dev should be a legitimate rock star.

5 Likes

Love your badges <3

1 Like

What about a system built on more incentive bonuses? Like if MKR 4k is hit a certain bonus is unlocked, and then at 5k and so on. That might better align the interests of the different parties in the protocol.

Thanks everyone for your comments! Indeed, this space is super competitive - we’ve all personally seen the challenge to retain and attract high quality developers. I fully expect and welcome the discussion that this will generate on both sides of the fence as we agree on a sustainable approach over the long term - we’re not here for farming, interim or short-lived solutions. Sustainability and growth is crucial.

2 Likes

The great thing with the DAO in general is that any individual or team can propose their services to Governance, so in theory with the right knowledge and skillset, anyone can put forward a (competing) proposal - in the case of Smart Contracts, the high personal exposure/risk, responsibility/being on call does come at a premium which I believe is a leading factor in why we’ve recently seen such high turnover.

1 Like

Great points @textrapper yeah, vesting structure is a tough one to settle on, some thoughts:

  • I can’t/don’t want to predict the MKR price as a mechanism to unlock bonuses because in theory it could promote pumping just to unlock bonuses. It would also be unlikely to offer a long-term incentive once the bonus is paid.
  • Tangential to this, I settled on an absolute MKR bonus number instead of a dollar value because I wanted a transparent absolute incentive regardless of MKR price - bear/bull markets could offer a variable bonus and therefore potentially a different incentive model. I would ideally like to look beyond the crypto cycles.
2 Likes

Just a question about where the MKR are coming from. Is there a reason they should be newly-created tokens, rather than bought for Dai at the start of the process (which should provide a better deal for the Protocol assuming MKR goes up in value, albeit by a different route). I get that it reduces the cost in the short-term but 1) down the line new supply is created and 2) there’s a scenario in which the team doesn’t get its MKR vesting because not enough tokens are burned, perhaps because the Surplus needs to rise rapidly due to growth, or because MKR are created for another reason. (Aside from a debt auction, you can imagine a scenario where multiple teams adopt the same model, and only one or two actually get the MKR.)
Also, minor point, but weighting the vesting towards the end of the period (e.g. 10-20-30-40%) would help retain talent for the full term.

1 Like

The short answer is that minting is a much more efficient mechanism and is not exposed to the fluctuations of the surplus buffer or the price of MKR.

In a bit more detail: Minting MKR tokens from the protocol can occur regardless of whether the surplus buffer is positive or negative. Minting MKR tokens increases the supply, yes, but - what is critical (in the eyes of MKR holders) is for MKR to retain its deflationary narrative and therefore increase in value over time. This occurs when burning > minting. Whatever vesting mechanism is chosen, this needs to remain the case.

If, as you suggest, we flip the model and instead have tokens collected from the existing supply, we would decrease the current buy/burn rate in favour of splitting it into burn/allocate amounts. This would expose us to fluctuations in the price of MKR which means it would be unwise to offer an absolute MKR award because you have no idea of knowing the dollar value of what that might actually be - hence a $ value would be more suitable in such a scenario - but then I think this removes the appeal of a vested interest in the appreciation of the MKR token.

Interesting, I’ll explore the variable weighting over time idea you mentioned.

Maybe the Foundation should use some of their treasury to actually properly compensate the employees that made this all possible. :thinking:

3 Likes

Thanks Derek. Those reasons do make good sense.
In an ideal world, though, I would hope/expect that everyone who worked for the DAO on any kind of longer-term basis would be rewarded with some MKR. It’s not just about the financial reward; it incentivises them to help MakerDAO succeed and grow Dai adoption, gives a sense of loyalty, ownership and agency, and critically enables people to vote for proposals they think will do that as well as what they do in their day jobs.
Obviously, there’s a limit to how much MKR it will be possible to mint without causing inflation. Should multiple groups suggest what you have (which seems quite likely), there are risks they would not get their rewards or that governance would have to take some kind of action.
Perhaps people have other ideas about how demand for MKR from Core Units could be met most effectively.

1 Like

I’d almost prefer MKR that would go to burn from FLAP auctions instead go into a vesting treasury that can then be paid out to core units. That way it still takes the MKR off the market but also gives it to protocol participants and aligns incentives for everyone.

3 Likes