It’s no secret that the SES core unit has been working in parallel with the MKR compensation Working Group to document its own vision on what an MKR incentive plan could look like.
In preparation of tomorrow’s SES Budget MIP that we will propose, we want to present this alternative MKR compensation plan for the community to consider. The design decisions that we opted for are very different from the decisions that the Working Group has based their plan on. We hope that this will create a healthy debate that will benefit not just the core units that are directly involved, but the entire Maker ecosystem.
Since the full details of the plan comprise no less than 21 pages, we’re putting just the introduction and summary here, while everyone is invited to read the original document with all the details.
Note that while the model has a lot of detail, the parameters in the document aren’t necessarily final and we are still considering some changes.
Looking forward to everyone’s feedback and questions.
For those that don’t like reading, we explained how this Program works on a video in one of the SES Weekly Updates.
Maker today is uniquely positioned to take the next leap in crypto history by being the first DAO to start scaling up, ultimately to the size of a decentralized Google or Amazon; a vibrant ecosystem with dozens of teams developing the protocol in parallel and running decentralized financial services all over the world. To succeed, the one thing we need to do is keep attracting new top talent and retain it in the long run.
With the MKR Incentive model we propose, we want to attract the best talent in the industry and convince this talent to build a long-lasting career in the DAO. We want to retain their experience for years to come to keep growing the most substantial moat that Maker has: its human capital.
We provide a summary with the key points that characterize the proposed MKR Incentive Plan and set the stage for the more detailed explanation in the document. We encourage the reader to read at least the Design Principles section and understand the motivations that went into the design.
The plan has some abstracted metrics for governance to assess its cost quickly. For the contributor, a lot more detail is essential.
- A Total MKR Expenditure Cap metric is calculated, which captures the current cost plus potential increases in MKR expenditure due to new people joining, people getting promoted, or repricings in the case of a bear market. This metric can be used for budget allocation purposes and as a first metric to compare plans.
- The Estimated MKR Expenditure, in total or per person, that can be used as a second metric to compare programs. This metric is aggregated per month.
- The Estimated MKR Expenditure can never surpass the Total MKR Expenditure Cap without requiring a new Budget Subproposal to be submitted to Governance.
- Except in the case of promotions, any increases in MKR incentives trigger a new vesting cliff, which means that governance always gets a heads-up in case the Estimated MKR Expenditure moves significantly closer to the cap.
- The payment implementation has an escrow wallet as a mechanism to create sufficient guarantees for both governance and the core unit that commitments will be kept.
- The plan for each Contributor is calculated based on their Dai salary level, which gives the dollar-equivalent bonus amount by applying a formula.
- The nominal MKR amount is then calculated from that using the average MKR price at the moment of commitment. This is when the contributor commits to start working for the Maker project and, as such, starts sharing in the risks and rewards with the Protocol.
- Once the nominal MKR amount has been determined —based on the salary level and the average price of MKR— the nominal MKR amount remains fixed.
- The program from there is structured as a fairly standard vesting schedule with a cliff vest.
- A repricing mechanism ensures that existing members always get at least as good a deal as new joiners. (Down to the MKR price floor.)
- To deal with changes in FTEs, raises, etc., a modular system with tranches is proposed, which keeps the model consistent between different edge cases, removing as many loopholes as possible.