MIP40c3-SP14: Modify Collateral Engineering Services Core Unit Budget

MIP40c3-SP14: Modify Collateral Engineering Services Core Unit Budget

Preamble

MIP40c3-SP#: 14
Author(s): @monkey.irish
Contributors:
Tags: collateral-eng, collateral-onboard, collateral-offboard, core-unit, mip-set, ces-001, cob-001
Status: Request for Comments (RFC)
Date Applied: 2021-05-12
Date Ratified: <yyyy-mm-dd>

Sentence Summary

MIP40c3-SP14 adds the budget for Core Unit CES-001: Collateral Engineering Services.

For more information on the changes to this MIP, please see:

Specification

Motivation

Building upon the theme of sustainability of the Collateral Engineering Services Core Unit (CES), the budget reflects support of the Mandates and business continuity in MIP39.

Any elements of this budget reflecting a likeness to other Core Units is a principle of building on the shoulders of giants. Much appreciation is given to all the trailblazers.

Core Unit ID

Collateral Engineering Services Core Unit

Budget Implementation

The CES budget is designed with the following in mind:

  • Paying for the operational costs to run the Core Unit
  • Building a reserve for sustainability
  • Building trust between CES, the DAO, and community, test then trust

Therefore, a vote to ratify this MIP means MKR holders make a commitment to:

  • An initial six month (Q1-Q2) budget for CES
  • A continuous funding model (after six months) that operates on a quarterly, semi-annual, or annual basis based upon achieving CES milestones
  • A MKR vesting schedule for CES based upon the SES and Oracles Core Unit proposal

Budget Responsibilities

  • Auditor’s multi-sig Wallet to honor and uphold MKR holders preference for the CES Budget Breakdowns
  • Operational multi-sig Wallet to run the operations of CES
  • CES commitment to the transparency and accounting of funds during all budget cycles

List of Budget Breakdowns

Team Structure

The initial team will consist of two types of members: permanent and new ecosystem engineers training on the Maker protocol. The permanent team members are full-time contributors within the Core Unit. The temporary team members are mainly engineers that will rotate through the Core Unit to help them with training on the Maker protocol. As an example, working in a feeder system where new smart contract engineers spend up to three months training on the protocol. The engineers could come from any of the Core Units.

Team Summary for 2021

Team Members
Permanent 6
Advisors 2
Temporary 2
Team Total 10
Governance
1 Core Unit Facilitator
  • Works with the DAO and community
  • Strategy for the Core Unit
  • Business entity leader
  • Team leader
Advisors
2 Core Unit Advisors
  • Advises macro-level strategy for the Core Unit and business entity
  • Signers on the 2 of 3 multi-sig Operational Wallet controlled by CES
  • Individuals with crypto and blockchain experience
Engineering
3 Smart Contract Engineers (perm)
2 Smart Contract Engineers (temp)
  • Engineering services relating to collateral on/offboarding
Product
1 Technical Product Manager
  • Product strategy
  • Roadmap owner
  • Manages backlogs
  • Reporting
Operations
1 Project/Operations Manager
  • Handles the 100’s of details needed to manage the operations of the Core Unit
  • Helps organizes the business formation activities

The numbers in this MIP represent a fully populated team and are included for comparison and completeness. CES is onboarding a completely new team and the goal is to ramp up within the first six months of the Core Unit formation.

Any other business functions (HR, Legal, DevOps, etc.) not listed here will be contracted on an hourly basis.

Team Hiring

The progression of team hires is as follows:

Phase 1

  • Core Unit Facilitator (Expert, Permanent)
  • Smart Contract Engineer (Lead/Senior, Permanent)
  • Smart Contract Engineer (Senior, Permanent)
  • Technical Product Manager (Senior, Permanent)
  • Project/Operations Manager (Mid/Senior Permanent)
  • Advisor1 (Permanent)
  • Advisor2 (Permanent)

Phase 2

  • Smart Contract Engineer (Jr/Mid, Permanent)

As Available

  • Smart Contract Engineer (Jr/Mid/Senior Temporary)
  • Smart Contract Engineer (Jr/Mid/Senior Temporary)

Team Responsibilities

As we populate the team, we will be able to take more responsibilities from a product and engineering perspective. On a meta-level, the following are a some guidelines of what CES plans to accomplish as we ramp up. This is based upon the Team Hiring plan and staring with a team size of three. Difficulties finding qualified people will impact our timeline.

Phase 1

  • Work with the stakeholders and community to assess the current collateral on/offboarding processes
  • Determine which technical responsibilities can be offloaded to CES once the Core Team is hired
  • Assume the coordination and collaboration responsibilities of collateral on/offboarding
  • Develop an overview of a product management process for our collateral
  • Hire and train the first permanent members of the Core Team
  • Form the CES business entity and setup the infrastructure
  • Work with SES on the parallelization initiative to enable our efforts

Phase 2

  • Continue/complete the training of permanent members
  • Hire the remaining permanent member of the Core Team
  • Work with stakeholders to uncover unmet needs relating to collateral engineering services
  • Build a product vision, roadmap, and backlog
  • Rollout the initial product management process
  • Manage the product and iteration backlogs
  • Determine KPIs, OKRs, and reporting for CES
  • Offload the initial technical responsibilities to the CES Core Team

Budget Breakdown

Total Budget Cap for the Cycle

The Total Budget Cap for the Cycle is $1,479,696, spanning a 6 month Cycle. The annual budget is projected at $3,191,861.

6 Months 12 Months
Budget $1,479,696 $3,191,861

Budget Detail

Summary Q1 - Q2 Q3 Q4 12 Months
Salary + Benefits + Taxes $960,781 $658,125 $658,125 $2,277,031
Travel $32,000 $24,000 $24,000 $80,000
Hardware $17,500 $3,500 $0 $21,000
IT & Subscriptions $25,000 $12,500 $12,500 $50,000
Referral & Sign-on Expense $125,000 $50,000 $0 $175,000
Audits $0 $0 $0 $0
Bug Bounty $0 $0 $0 $0
Gas Costs $11,250 $5,625 $5,625 $22,500
SC Verification & QA $0 $0 $0 $0
Professional Services $100,000 $25,000 $25,000 $150,000
Contingency Buffer $208,165 $104,082 $104,082 $416,330
Total $1,479,696 $882,832 $829,332 $3,191,861

A few notes about the Budget Detail:

  • The Budget Detail contains a provision for two temporary Smart Contract engineers for a period of up to 90 days. Until we implement a feeder system and training model, it is unclear which Core Unit will pay for the temporary engineers. I’ve included the salary and overhead for both engineers for completeness. For the Salary + Benefits + Taxes line, this amounts to $650,000 of the yearly budget. The actual number will vary based upon the agreement between the Core Units.

  • The Budget Detail in the first version of this MIP was $2,466,500. This has been revised to $3,191,861. The increase is primarily due to 1) Scaling Salary + Benefits + Taxes by 30% for benefits (including healthcare) and taxes, 2) Increasing the Contingency Buffer to 15%, and 3) Increasing Referral & Sign-on Expense and Professional Services.

Illustrating these details as a percentage of the total budget request for overall comparison (12 months):

Budget Details:

Providing additional detail with regards to the above line items:

Salary + Benefits + Taxes: The initial team has 3 full-time smart contract engineers, 1 full-time product manager, 1 full-time project/ops manager, 1 Facilitator/Team Lead, and 2 Advisors (for a total of 8 permanent members). The team will have up to 2 temporary smart contract engineers for a total of 10 members. This opportunity to scale will enable us to better meet the demands of the community.

The total cost of an employee includes salary, all benefits (including healthcare), and taxes. This has been calculated by scaling salaries by 30%. This premium is likely an overestimation, and the realized cost is expected to be lower. That being said, paying salaries to a a global remote team in a multitude of jurisdictions can be quite expensive without the proper legal infrastructure in place.

Travel: The team may travel to present at industry events or participate in a team offsite. The budgeted amount is $1000 per person per month.

Hardware: An allocation of $3,500 per new team member.

IT & Subscriptions: We anticipate a variety of costs relating to software subscriptions, cloud services, and contract service providers.

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

Audits: Initially, this work will be coordinated with the Protocol Engineering Core Unit. Budget modifications will be submitted when appropriate.

Bug Bounty: Initially, this work will be coordinated with the Protocol Engineering Core Unit. Budget modifications will be submitted when appropriate.

Gas Costs: Initially, this work will be coordinated with the Protocol Engineering Core Unit. A nominal amount has been allocated for administration. Budget modifications will be submitted when appropriate.

SC Verification & QA: Initially, this work will be coordinated with the Protocol Engineering Core Unit. Budget modifications will be submitted when appropriate.

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

Contingency Buffer: Approximately 15% of budgeted costs to be held in reserves for business continuity. The CES entity will be a business and this will represent a profit by tax standards. Therefore, the actual amount in reserves will be lower due to corporate tax rates in the United States.

MKR Vesting and Incentive Structure

The CES Core Unit supports the Sustainable Ecosystem Scaling Core Unit (SES-001) and Oracles Oracles Core Unit (ORA-001) proposal for MKR Vesting. This model has been proposed by the SES Core Unit along with the Oracle Core Unit modifications.

MKR Vesting Details

Property Value
MKR/USD lock-in Price (New Team) Trailing 6 month average or current market price, whichever is lower at time of hire
MKR/USD lock-in Price (OG Team/Advisors) MKR = $1956 (11/12/20 - 05/12/21) or current market price, whichever is lower at time of ratification
MKR Price Floor (New Team) -30% (Trailing 6 month average hire price)
MKR Price Floor (OG Team) -30% ($1,369)
Quarterly MKR Amount Initial Annual Incentive Value (USD) / MKR/USD lock-in Price / 2
Vesting Period 4 years
Cliff Vest 6 months
Vesting Transfer Schedule After the Cliff Vest has expired, the Quarterly MKR amount vests every 3 months and is distributed the day after vesting: Feb/May/Aug/Nov 1
Manual Repricing Yes
Auto-Renewal Yes
Estimated Max Total team MKR After 6 Months (6 FTE) 468.89
Estimated Max Total team MKR Quarterly (6 FTE) 234.44
Estimated Max Total team MKR After 1 Year (6 FTE) 937.77
Estimated Max Total team MKR After 4 Years (6 FTE) 3,751.08

MKR Forecast

Assuming a fully populated team today, this would result in the vesting transfer schedule below.

Vesting Transfer Date MKR Amount
01 Feb 2022 468.89 MKR
01 May 2022 234.44 MKR
01 Aug 2022 234.44 MKR
01 Nov 2022 234.44 MKR
01 Feb 2023 234.44 MKR
01 May 2023 234.44 MKR
01 Aug 2023 234.44 MKR
01 Nov 2023 234.44 MKR
01 Feb 2024 234.44 MKR
01 May 2024 234.44 MKR
01 Aug 2024 234.44 MKR
01 Nov 2024 234.44 MKR
01 Feb 2025 234.44 MKR
01 May 2025 234.44 MKR
01 Aug 2025 234.44 MKR
Total 3,751.08 MKR

A few notes about the MKR vesting schedule:

  • The estimated MKR incentives is the best guess of how much MKR will be used with the current team configuration. The number of MKR might decrease/increase rise due to raises, new hires (coming in at a much lower MKR price), resetting the price due to a market downturn, or delayed hiring for the Core Unit.
  • The Vesting Transfer Date is one day after that period’s vesting date. For example, a Jan 31 Vesting Date would have a Vesting Transfer Date of Feb 1.
  • The two temporary Smart Contract Engineers are not included in the CES MKR incentive plan. The hiring Core Unit would need to allocate the MKR incentive, not CES.
  • Manual repricing allows any contributor of CES to calculate a new MKR/USD lock-in price using the trailing 6 month average. This ensures that contributors who join during a bull market are not penalized relative to new contributors who join later during a bear market. In order to prevent abuse, manual repricing will reset the 6 month cliff vest period.

Budget Implementation

Goals

The CES budget implementation is architected to build and sustain a stable Core Unit in relation to the volatility in our industry.

  • Funding for the initial six months of the Core Unit with a contingency reserve
  • Thereafter, a continuous funding model operating on a quarterly, semi-annual, or annual basis
  • MKR vesting with a 6 month cliff and quarterly vesting
  • Provide full transparency and accounting of funds during all budget periods

Key Takeaway

The theme for this Core unit is Survivability, Sustainability, and Continuity.

Total Budget Cap for the Cycle

The Total Budget Cap and estimated MKR vesting for the Cycle, specified in the Budget Breakdown and MKR Forecast, will be transferred to the Auditor’s Wallet. This wallet will keep the funds and transfer them as requested by CES, per the below.

The Auditors Wallet balance will never exceed the upper limit voted by Governance. If this limit needs to be raised, or we’re no longer expecting to ever need it, an additional subproposal MIP will be submitted to adjust it.

CES Budgeting Cycle

Core Unit Ratification

When the CES Core Unit is ratified:

  1. Core Unit begins
  2. Six month budget & estimated MKR incentives transferred to Auditor’s multi-sig Wallet
  3. Initial requested budget transferred into the Operational multi-sig Wallet

Core Unit Monthly Budgeting Cycle

Within the first 5 days of each month, CES will submit a Monthly Budget Statement to the signers of the Auditor’s Wallet with the following sections:

  1. For each month, provide an accounting of funds spent in the prior month
  2. Provide an updated budget for the remaining cycle
  3. Provide a MKR vesting overview, by month
  4. Auditor verification of accounting
  5. Requested additional budget allocation & MKR incentives transferred into the Operational multi-sig Wallet

The Monthly Budget Statements will be added to the MakerDAO forum. The originals can be found in this git repository on Github.

Core Unit Summary Cycle

  1. Reconciliation of budget, actual vs. spent
  2. Review results & achievements
  3. Present new budget, MKR vesting, & goals
  4. Commit to length of next budgeting cycle
  5. Entire committed budget & estimated MKR incentives transferred to Auditor’s multi-sig Wallet
  6. Initial budget transferred into the Operational multi-sig Wallet

MKR Incentive Vesting Implementation

MKR will be transferred from the Auditor’s multi-sig Wallet into the Operational multi-sig Wallet no later than Core Unit Monthly Budgeting Cycle before the month the MKR actually vests. For example, if a Vesting Transfer Date is 01 Feb 2022, the MKR will be transferred into the Operational Wallet no later than Dec 2021 Core Unit Monthly Budgeting Cycle. Once DssVest is ratified and implemented, CES will investigate the use of automated MKR incentive vesting.

Wallets

The following wallets are involved:

  1. The Auditor’s Wallet – A 3-out-of-4 multi-sig, controlled by trusted Maker DAO members. This multi-sig will hold the Total Budget Cap in DAI. All funds pass through this wallet before any are sent to the Operational Wallet. One of the signers is the Facilitator of the CES Core Unit.

    The signers of the Auditor’s Wallet are still being confirmed and will be added to the MIP40c3-SP14 forum thread. No funds will be sent to this wallet before the signers’ addresses have been set in the wallet.

  2. The Operational Wallet – A 2-out-of-3 multi-sig, controlled by CES. This multi-sig will be used for Core Unit expenses. One of the signers is the Team Lead of the CES Core Unit.

    The signers of the Operational Wallet are still being confirmed and will be added to the MIP40c3-SP14 forum thread. No funds will be sent to this wallet before the signers’ addresses have been set in the wallet.

Transfers

Core Unit Budget Cycle Transfer

  • What: Initial transfer of the Total Budget for the 6-month Total Budget Cap Cycle.
  • When: Automatically, upon executive vote approval (spell cast).
  • Amount: 1,479,696 DAI
  • Sender: Maker Protocol Surplus Buffer
  • Recipient: Auditors Wallet: 0x25307aB59Cd5d8b4E2C01218262Ddf6a89Ff86da

Core Unit MKR Cycle Transfer

  • What: Initial transfer of estimated MKR for the CES MKR incentive plan.
  • When: Automatically, upon executive vote approval (spell cast).
  • Amount: 468.89 MKR
  • Sender: MakerDAO
  • Recipient: Auditors Wallet: 0x25307aB59Cd5d8b4E2C01218262Ddf6a89Ff86da

August 2021 Budget Transfer

  • What: Operational Wallet for initial requested budget.
  • When: Manually, based upon the August 2021 Budget Statement.
  • Amount: 787,855 DAI - August 2021 Budget Statement
  • Sender: Auditors Wallet: 0x25307aB59Cd5d8b4E2C01218262Ddf6a89Ff86da
  • Recipients: Operational Wallet: 0xD740882B8616B50d0B317fDFf17Ec3f4f853F44f

Related Documents

MIP39c2-SP12 Collateral Engineering Services Core Unit MIP

MIP41c4-SP14: Facilitator Onboarding, Collateral Engineering Services Core Unit

1 Like

Based on all assumptions being met successfully, what would be the (estimated) marginal cost for this CU to onboard a new collateral type?

I love the question and I wish I could answer it directly. :wink:

We’ll always have the fully burdened hard costs of the core unit. An allocation of cost is based upon the fine art of product and feature estimation. In the product development world, that means we are using iterative software development best practices and techniques to come up with our estimates. While we can calculate these costs based upon the development time a feature will take, there is a higher level we really need to take into consideration…opportunity cost. Or put another way, what is the impact to the protocol if we don’t do this collateral or collateral types? I’ll leave that point alone for now since that is an entire discussion in itself. If you want to geek out a little bit on a technique I use, have at it! WSJF - Scaled Agile Framework

To reduce bottlenecks, we’ll also need to use outside auditing firms and there is an additional cost with that.

There are varying levels of overhead with the other core units as well: Risk, Oracles, Protocol Engineering, SES (Integrations), and Growth. The dependencies on their resources will vary over time and based upon the complexity of the collateral and consumption.

Generally speaking, when we have a class or category of collateral where we’ve systematized it, a lot less cost. I think this is quantifiable in the near term. For complex collaterals, it’s unknown what the cost will be at the moment.

Once we start to consolidate the collateral onboarding functions within the core unit, the tools and best practices I use will give us a lot of visibility into estimated costs for onboarding a single piece of collateral or an entire category.

Personally, my opinion is that prioritizing jobs based on economics, which implies cost, is the most important data point. I’m unsure what value, other than budgeting, of what hard costs give us. I’m always open to feedback in this area.

My view is always one of looking at a project such as this as a “product” and providing incremental value each time we ship software. It’s what I’ve done my entire career and it works really well.

Governance doesn’t really appoint auditors in this way. Like, there are no processes to do this. In an ideal world, auditors would be presented as part of this proposal, and could be considered to be approved as this proposal passes. Maybe try to find some in advance (check they are willing!), and add them to the proposal.

This reads like a contradiction? Controlled by trusted members of MakerDAO that are not team members of the collateral onboarding core unit. But also one of the signers is the facilitator of the core unit.

We may not have this if MIP51 passes. Maybe amend to the next weekly executive vote.

1 Like

Hey @LongForWisdom. Not sure why I didn’t see the notification for your comment a while ago.

I revised the the Wallet and Transfers section to be a little clearer. I don’t think it addresses your comment though. I’d like to hear your suggestion on the signers of the wallet. My thought is that I am a trusted member of MakerDAO if I am onboarded as a facilitator and I’d like to be part of the budget process. Maybe it’s in the name “auditor” based upon your first comment. My thought right now it to change that to something like “The DAO Wallet” since CES Budgeting Cycle takes care of the auditing and accountability parts. I was trying to model it after SES budgeting and I’m not sure those labels apply accurately to CES.

MIP51 defines the Monthly Governance Cycle. How would I word the initial transfers of DAI & MKR to the wallets?

How many team members have been hired or have committed to starting assuming the CU is approved by Governance?

At this moment, myself and one advisor. I’m currently interviewing candidates for the product manager and smart contract engineering positions.

The total budget assumes a full permanent team of six, with two temporary smart contract engineers, for a full year. The first year budget will be lower given the ramp in hiring. At the end of the six month cycle, we will reconcile actual vs. spend and make any adjustments necessary.

There are one time expenditures allocated to business formation services and hiring that might appear to inflate the budget in Q1-Q2. These are necessary. The temporary engineers are also $650k of the salary budget which will be implemented only after a plan as been discussed and put in place between the PE, Oracles, & SES core units.

Going to be honest here - while I support the mandate and goals of the proposed CU I’m finding it quite difficult to support it in it’s current form. The CUs that have been passed have generally been existing teams coming over from the Foundation or teams that have grown organically within the DAO. Those that have followed the latter path have started with smaller budgets and team sizes and scaled up as they have established credibility with the community.

It concerns me that you’ve requested a $1.5M budget up front for a team that consists of solely an advisor and yourself. I would expect that you’ve built a network of experienced software engineers from your time at the Foundation and prior and would prefer to see a more measured approach in building the a base and scaling this CU given the lack of commitments at this stage.

I believe it is premature to be requesting MKR compensation, especially over a four year vesting period when the only person on the proposed 10 person team we know is yourself and the CU is unknown to the DAO. This is not comparable to the PE team at all given their high engagement and visibility working with the DAO and an existing fully functioning team. I would request any MKR compensation be postponed until after the CU DAI budget has been approved by Governance and be kept in a separate thread similar to SES and Growth’s recent proposals.

Regarding the proposal, couple questions:

CES is a business venture that becomes a profitable entity.

Could you explain what you mean by this quote?

I’d also like to make sure I am very clear on one point. This Core Unit is a highly-collaborative effort and it’s a partnership, not competition, with the key stakeholders in the DAO. CES will continuously work with Protocol Engineering, Oracles, Risk, Real World Finance, and other critical stakeholders to:

Could you also discuss how you have and are currently collaborating with these CUs? If not currently, how do you envision each CUs role, specifically, in working with CES?

Contingency Buffer: Approximately 15% of budgeted costs to be held in reserves for business continuity. The CES entity will be a business and this will represent a profit by tax standards. Therefore, the actual amount in reserves will be lower due to corporate tax rates in the United States.

Could you also explain how CES will be a profitable entity by tax standards?

1 Like

FYI, you can have MakerDAO still “own” the wallet and only withdraw (and realize income) when needed. Or at least, that’s my understanding. @prose11 can probably either correct me or cite the appropriate setup.

That is the idea behind MIP47: MakerDAO Multisignature Wallet Management. Basically the wallet can be considered protocol owned as it will be officially recognized in addition to the DAO having the ability to pull the DAI via the Pause Proxy at any time. I suggest you consult your own tax advisors for how this factors in to the corporate liability, however.

2 Likes

Thanks for the questions!

I’ve been with the Foundation for almost two years and have deep domain knowledge of Maker and how we’ve got to this point in our evolution. While I am new to many in the community, I’ve worked very closely with the core unit facilitators and contributors I’ll be interacting with and understand the issues, concerns, and roadblocks of collateral management.

Overall, the budget only gets spent when people are hired into roles that we’re trying to fill. I’d love to have a team to start but Nik and Derek cornered the market.:wink:

Right now in our industry, we’re not sitting with an abundance of smart contract engineers waiting to be hired so we need to create the opportunities. The CES core unit is an opportunity creator. Everyone we’re targeting are gainfully employed elsewhere. Sure, we can wait and try to grow organically. It’s my opinion that route isn’t what the protocol needs right now and it will prevent us from scaling the supply side in the short term.

MKR compensation is formulaic based upon the salary we’re offering. Engineers will have the competency and aptitude to deliver or they will not. It’s not just me watching this but the PE and Oracles core units as well as the community. If someone isn’t making the grade (including me), they will not be around for long and therefore the grant will not vest. I believe there are the safe guards in place to prevent the “friends and family” effect.

Switching gears… My belief is that businesses need to be profitable. Building an entity or company based upon a cost only model is a recipe for failure especially in an industry like ours due to the wild swings in crypto market caps. Initially, I’m proposing a cost plus model since we’re not mature enough to implement anything else. Over time, I’d like to explore other models and incentives that is more aligned with pay for performance. It’s just too early for that at the moment.

One aspect of profitability is to allow a business to decide how to invest in operating the business when there are challenging times. Let’s look at how companies survived the economic crisis last year. Generally speaking, most of them did that based upon cash reserves. Imagine all core units going back to governance when crypto markets get tough and asking for money to operate their core units. I’m not sure how that would work.

Is a 15% too much/little for a business to make? I’d say it’s quite low based upon looking comparable consulting firms providing like services. In the past, I would not choose to be involved with such an enterprise. In this case, I believe there are other viable business models, based upon performance, that will make it a win-win for the DAO and core units…not just CES.

In the US, the challenge is our taxation model. The first dollar of profit is taxable. Any excesses that are held by the core unit are technically considered profit. If a core unit holds the “Contingency Buffer” (as most core units have this allocation) then it’s taxable. Current tax law does not consider things like assets held in a multi-sig wallet as someone has to “own” it. We have to look at alternatives.

We’re breaking new ground here and either I’ll do it as the facilitator of the CES core unit or someone else will. The RWF post is a great example of the considerations for starting and running a core unit. And there are many more.

I’m sharing some of my opinions and beliefs based upon my experience. I believe I’ve identified the key issues and budget to effectively deal with them. You may or may not agree and that’s ok. For me, it’s a matter of when we do this core unit and who is going to lead the work.

Please keep the questions coming!

The CES auditor’s wallet is setup this way.

Hi, RoJo. I believe that if you execute properly on the mandate, this could help unblock a lot of the roadblocks and bottlenecks we’re facing right now.

Some detail from your proposal:

Isn’t this unfair for MKR holders? This means that a bear market “forgets” about the past glories, but a bull market “surfs the wave”.

Thanks in advance for your answer.

1 Like

I thought a lot about adding the “market price”. Being through several bear markets, I have no idea where the MKR price is going in the next six months. We could be at this price or lower for some time.

Given the critical hires of the CES core unit in the next three months, what seemed fair to add the market price into setting the incentive. It didn’t make sense to penalize new people with a price that could be artificially high for some time. I’m not trying to debate the future price of MKR. The past is the best predictor of the future right now and that is what I am going by. In a few months, we’ll be past the $6k spike the market price will be less or no impact.

I’ve also built the model around about $2k on the MKR price and I don’t think this will impact the amount of MKR I’m asking for.

I hope that helps explain my thinking. Thanks!

Thanks for the detailed answer, @monkey.irish .

My question is actually simpler. By saying “whichever is lower at time of hire” you’re introducing an asymmetry. Would you be willing to change it for “whichever is higher”? (Probably not, as this would be an asymmetry against your Core Unit instead of the MKR holders).

I personally think that choosing the average (regardless of the current price) is fairer, as you are averaging out all the tops and bottoms. Up to you. : )

Hopefully, it makes my point clearer.

Thanks for the clarification, Juan.

In most cases, I do believe the average price is the fairer calculation. Right now, I felt the best way to address the run up to $6k was to add the lessor of the two prices into the incentive. In the future, it may make sense to add a smoothing function where we drop the outliers beyond a standard deviation or two since I don’t see crypto volatility changing any time soon.

I really am trying to balance the needs of the core unit and MKR holders and I appreciate your feedback.

A bit concerned that a bulk of the discussion is on compensation / budget rather than how this proposal is much better than the existing system. Is there a reason why you can’t just join the existing system?

I just saw your other reply. It seems to answer some of my questions MIP39c2-SP12: Adding Collateral Engineering Services Core Unit - #35 by monkey.irish

@Doo_Nam, let me know if you have specific questions and I’ll be happy to answer them. Removing bottlenecks, increasing focus, and scaling onboarding collateral are at the heart of this core unit.

1 Like