MIP40c3-SP10: Modify Core Unit Budget, SES-001

[juan]

Preamble

MIP40c2-SP#: 10
Author(s): @wouter, @juanjuan
Contributors:
Status: Accepted
Date Applied: 2021-04-07
Date Ratified: <yyyy-mm-dd>

Sentence Summary

MIP40c3-SP10 adds the budget for Core Unit SES-001: Sustainable Ecosystem Scaling.

Paragraph Summary

MIP40c3-SP10 adds the budget for Core Unit SES-001: Sustainable Ecosystem Scaling. It contains:

• Total Budget Cap: the hard limit voted by Governance
• Breakdown of Permanent Team for the expected first payment (June)
• The breadowns for the Incubation and Grant programs
• The MKR Compensation Expectation

Specification

Motivation

Going by the critical nature of the work done by the Sustainable Ecosystem Scaling Core Unit, sufficient funds need to be provisioned in order to guarantee the success of the Maker ecosystem in the long run.

The proposed budget comprises three parts:

Permanent Team Budget

The Permanent Team Budget is covering salaries and operational costs for the permanent team members of the Sustainable Ecosystem Scaling Core Unit. This is a standard budget based on the breakdown of actual costs. It will evolve over time in a relatively slow and predictable way.

Incubator Program Budget

The Incubator Program Budget is not based on a breakdown of actual costs, but rather acts as a spending limit for a financial buffer that will be used for funding incubation projects at the discretion of the SES Facilitator and multisig co-signers.

A big part of the Incubator Program’s value lies in this ability to quickly allocate budgets without having to wait for governance approval. This is to avoid a situation where promising teams have to wait in great uncertainty, typically 3 months or longer, before potentially receiving the first DAO payment for their Core Unit. This is seen as a requirement that is an unreasonable barrier to entry for new teams joining the ecosystem.

Grants Program Budget

The Grants Program Budget is a similar budget based on prior experience with the Governance Communications’ grants program that has now been sunset.

Core Unit ID

SES-01

Budget Cap Breakdown

Dai Expenditure

Total Budget Cap

We’re asking for a Total Budget Cap of $1,153,480, spanning a 3-month runway.

Group	Monthly Total	3 Months
Permanent Team	$154,493	$463,480
Incubation	$200,000	$600,000
Grants	$30,000	$90,000
Grand Total	$384,493	$1,153,480

Permanent Team Budget Cap

Type	Monthly Total
Salaries (9.23 FTEs)	$120,083
New hires’ Salaries (2 FTEs)	$19,708
Buffer	$8,333
Software Development	$4,167
Software	$1,785
Gas	$417
Grand Total	$154,493

See our Team Spreadsheet for more details about the included FTEs.

Incubation Program Budget Cap

The limit for the Incubation Program was estimated based on a number of team configuration scenarios that we want to support, as outlined in the table below. The requested limit is the (rounded) maximum amount needed for any of these scenarios.

	Teams	Avg Team Size	People Total	Avg Salary	Annual Cost	Monthly Cost
Sr. Engineers	3	4	12	$155,000	$1,860,000	$155,000
Non-technical	5	4	20	$120,000	$2,400,000	$200,000
Mix	3	6	18	$137,500	$2,475,000	$206,250

Estimations of different incubation costs at industry standards.

Grants Program Budget Cap

The details for the Grants Program are still being worked out. To avoid having to update the budget MIP soon, a budget is included that will be sufficient to get the program up and running. Once the program is active, more detailed estimates will be included in the Monthly Budget Statement.

MKR Expenditure

Permanent Team

For the Permanent Team, a budget proposal amendment will be submitted that proposes a detailed MKR incentive model.

While this leaves the details undefined for now, the expectation of the team is threefold:

1. That the MKR incentive structure is reasonably defined by the time the team starts working for the SES Core Unit.
2. That the vesting schedule starts no later than this starting date.
3. That the commitment and therefore risk that the team is taking will be reflected in this structure, for example by taking the MKR price into account at the moment of the formal submission of this MIP40c3-SP10.

Incubation Program

For the Incubation Teams, MKR incentives will be included in the respective budget MIPs as they are published. This may include a back pay amount for the incubation time, but these details too, are still being discussed.

Budget Implementation

Goals

The budget implementation is based on a monthly reporting and top-up cycle that is described in the sections below. Our goals with this implementation are the following:

• Continuously fund the SES core unit. Ensuring that SES has enough money available for business continuity and minimal job security.
• Provide full transparency and be kept in check by a group of governance-appointed auditors.
• Fully separate cashflows on the Core Unit and budget category level for transparency.
• Reduce governance overhead to a minimum.

Total Budget Cap

The Total Budget Cap, specified in the Budget Cap Breakdown, will be transferred to the Auditors Wallet, who will keep the funds and transfer them as needed. This amount aims to maintain a 3-month runway for the Core Unit.

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.

Multi-sig Wallets

The budget is split up in three separate categories: Permanent Team, Grants Program, and Incubation Program. The following multi-sigs are involved:

1. The Auditors Wallet – A 3-out-of-4 multi-sig, controlled by trusted Maker DAO members that are not a member of SES. This multi-sig will hold the Total Budget Cap in DAI. All funds pass through this wallet before any are sent to the operational wallets. One of the signers is the Self-Accountability Auditor of the SES Core Unit.

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

2. The Operational Wallets – One wallet for each budget category. These are 2-out-of-3 multi-sigs controlled by SES. Signers include the facilitator, the team lead, and one other SES member from the permanent team, responsible for the associated budget category.

   • The Permanent Team Wallet
   • The Grants Program Wallet
   • The Incubation Program Wallet

Monthly Budget Statement

Within the first 5 days of each month, SES will submit a Monthly Budget Statement to the signers of the Auditors Wallet with the following sections:

1. The Budget Forecast, based on the latest available information, of the budget (in DAI) that is required to maintain a 3 month runway for the team.
2. The Last Month Actuals, i.e. the actual expenses (DAI and MKR) of the month that just ended.
3. The MKR Vesting Overview – this is a schedule that has the expected MKR vesting amounts for the current team configuration, grouped by the pay-out month.
4. The Transaction Amounts
   • The required DAI amount for each Operational Wallet to replenish the 3 month runway
   • Any excess DAI amount that will be returned to the Auditors Wallet

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

Monthly Top-up Cycle

Seeding the Auditors Wallet

As preparation for the Monthly Top-up Cycle, the Auditors Wallet first needs to be seeded with the Total Budget Cap from the surplus buffer. This seeding transaction will be included in the executive vote on the initial SES Core Unit MIPs.

Monthly Cylce

1. Monthly Budget Statement Submission – Within the first 5 days of the month, SES submits the Monthly Budget Statement to the Auditors Wallet signers. This report is also available for the rest of the community to review.

2. Transaction Requests Submission – In parallel, SES submits the necessary transaction requests for the Auditor Wallet signers to sign:

   • DAI Top-up Transactions – One DAI transaction for each Operational Wallet that has a balance below the 3-month runway forecast. The top-up transaction adds enough funds to the operational wallet to replenish this runway.

3. Returning Excess Funds – SES creates and signs any transactions for excess funds that should be returned to governance:

   • Excess DAI Transactions – DAI transactions for Operational Wallets that have a balance above the 3-month runway forecast.

4. Auditors’ Review – The Auditors Wallet signers review the Monthly Budget Statement. They check that the transaction request amounts are the ones mentioned in the report and that they make sense. If there are any irregularities or other questions or comments, they discuss this with SES and allow for resubmission if any corrections are required.

5. Transaction Approvals – Three of the Auditors Wallet signers sign the submitted transactions, sending the DAI top-up amounts to the Operational Wallets. SES can now use the funds for expenses.

6. Auditors Wallet Top-up – In the next executive vote, SES submits a PR to top up the Auditors Wallet to the Total Budget Cap. The cycle can now start again from step 1.

---

Transfers

Seed Transfer

• What: Initial transfer of the total budget cap for the 3-month runway.
• When: Automatically, upon executive vote approval (spell cast).
• Amount: 1,153,480 DAI
• Sender: Maker Protocol Surplus Buffer
• Recipient: Auditors Wallet: 0x87AcDD9208f73bFc9207e1f6F0fDE906bcA95cc6

June 2021 Transfer

• What: Operational wallets top-up for June 2021 expenditures.
• When: Manually, upon June 2021 Budget Statement review.
• Amount: Determined by the June 2021 Budget Statement
• Sender: Auditors Wallet: 0x87AcDD9208f73bFc9207e1f6F0fDE906bcA95cc6
• Recipients:
  • Permanent Team Wallet: 0xb5eB779cE300024EDB3dF9b6C007E312584f6F4f
  • Incubation Program Wallet: 0x7c09Ff9b59BAAebfd721cbDA3676826aA6d7BaE8
  • Grants Program Wallet: 0xf95eB8eC63D6059bA62b0A8A7F843c7D92f41de2

[LongForWisdom]

@juan

Below is the breakdown of the first transfer that will happen on June 1, 2021

We don’t have executives on Tuesdays. The budget implementation is supposed to communicate the method by which the budget is distributed to the core unit.

@MIP40c2-Template

• Is it a smart contract Budget Implementation, or manual Budget Implementation?
  • If it is a smart contract Budget Implementation:
    • what is the ethereum address that the smart contract is deployed to?
    • what kind of authorization does it need (suck authorization, authorization to draw funds from other smart contracts, etc.)
• What is the amount of Dai or other assets per month that the Budget Implementation will pay out (if any)?
  • If it is a manual Budget Implementation, at which week of the month will the executive vote to pay out the budget for the month be submitted?
• What are other circumstances that the Budget Implementation will pay out Dai or other assets, and how are the amounts determined?
• Any additional notes and clarification about how the Budget Implementation works.

I’m assuming this is manual and distributed on the last week of the month? Where are the funds going? Is governance going to own the budget multisig or will the Core Unit own it?

[juan]

Thanks, @LongForWisdom .

@LongForWisdom

We don’t have executives on Tuesdays. The budget implementation is supposed to communicate the method by which the budget is distributed to the core unit.

Agreed. We do underatand the technical limitations. Meant to say “first week”.

@LongForWisdom

I’m assuming this is manual and distributed on the last week of the month? Where are the funds going? Is governance going to own the budget multisig or will the Core Unit own it?

We’ll update the details with the multisig soon.

[juan]

Since we’re nearing our freezing deadline tomorrow, we just edited the OP with an update for those who want to start reading. Tomorrow we put in the last details and clarify how we calculated the MKR incentives.

[Aaron_Bartsch]

Seems reasonable. Link to how you got those numbers isn’t working (yet). Does this mean the MKR Vesting Working Group has some preliminary results?

[wouter]

No, we developed this model ourselves because the working group is still discussing things internally. We are in touch with the working group to provide it as our input, and receive feedback ourselves.

Our own model may later be replaced with one that will be based on a broader consensus in the community.

We will add the details of the model we created tomorrow. That link does indeed not work yet… I’ll remove it for now.

[Aaron_Bartsch]

Ah cool. Thanks!

[LongForWisdom]

Adding significant new content just before the freeze period starts isn’t exactly using the RFC period in the spirit it was intended.

In an ideal world the MIP / Subproposal is content complete for the start of the RFC period, and any changes are in response to feedback. In practice deadlines have been tight, and often authors have used the RFC period to make tweaks or to add polish or clarifications. This has generally been fine.

What we haven’t really seen before is authors adding non-trivial new content just before the freeze period begins. The reason this is problematic is because it leaves zero time for any edits to be made based on feedback from the community (which implies that the author doesn’t actually intend to accept any feedback from other parties at all.)

I don’t think it’s a good idea to accept this MIP into the May cycle given the above. It sets a bad precedent: That it’s okay to add additional logic / content at the eleventh hour such that there is no time for feedback. It’s especially problematic in this case given that the minting of MKR has been a heavily debated issue.

Are you willing to delay til June to allow for feedback on this? If not, are you willing to separate the MKR incentive portion into its own budget proposal?

---

On top of the actual process issues, I don’t feel that the section on MKR Expenditure actually provides enough clarity on the planned expenditure. Are the amounts shown by vesting dates per FTE or in total? What is the total amount of MKR minted per year? What is the methodology, how is this split between employees, etc?

[juan]

Thanks for the feedback, @LongForWisdom. We see your point about the MKR incentives being added close to the freezing deadline, which would indeed make it impossible to incorporate additional changes based on feedback in the coming weeks.

It may be reasonable to split off the MKR incentive part if we can set clear expectations that this will be taken care of by the time the Core Unit starts working. This is something that we need to discuss with the team first.

One question for clarification: who is ultimately making the call if this (or any, really) proposal can be formally submitted? We would like to understand our options as we discuss them with the team.

[LongForWisdom]

Week 1, Thursday

• Governance Facilitators do the Submission Review as part of the governance meeting and determine which of the proposed MIPs are in accordance with guidelines (defined in the MIP0 Framework) and should be included in the inclusion poll.

The reference to guidelines here isn’t super specific, nor does it go into detail over the relevant circumstances under which the Governance Facilitator should not allow MIPS to move forwards. But there is clearly some discretion here on behalf of the Governance Facilitator.

MIP0 says the following on RFC:

3. Request for Comments (RFC): This phase is when a MIP goes through a formal review period, including feedback from the community, further drafting and additions. The timeline for the RFC phase is defined by its Feedback Period and Frozen Period. In order to move to the next phase, it needs to satisfy the transition criteria listed below:

• MIP Author finalizes changes of the MIP, based on community feedback.
• MIPs have a Feedback Period of 3 months. The RFC phase lasts at least 3 months before the MIP can move to the next phase.
• MIPs have a Frozen Period of 1 month. MIPs must not have had any changes for the last 1 month before they move to the next phase.

Strictly speaking, the subproposal follows the transition criteria defined in MIP0 (though the reference to changes based on community feedback is perhaps ambiguous here), so it’s certainly not an obvious decision on my part. There is nothing I can point to that says ‘you are breaking this rule, and therefore I have justification to prevent it from moving forwards.’

That said, I’ll repeat what I said earlier. I don’t think it’s taking the RFC period in the spirit that it was intended and I think if others take similar actions in the future, it would have a negative affect on the process. I would be uncomfortable forcing a delay on this given the somewhat sketchy justification. However, regardless of whether or not you do end up delaying, I do intend to put up an amendment to MIP0 that makes this situation more clear and would provide that justification in future situations on this sort.

I’d love to get some input from @charlesstlouis and / or @Davidutro on this.

[juan]

About the Process

Is the MIP Process Broken?

We were allowing one whole week before the Formal Submission. We have followed the MIP process and its deadlines. We were under the impression that the Freeze Period (and its deadline) ensures no one changes something before it goes into voting. Yet, the feedback received suggests that SES shouldn’t include this MIP in the next cycle because we are not allowing enough time. There’s still one week of RFC where we could receive feedback (granted, not modify anything based on it). We could, however, decide to make the Formal Submission or not based on that feedback.

If being too close to the deadline is a no-go, maybe we should move the deadline (or make it more precise).

About the Proposal

Good Intentions

We indeed had this framework prepared when we published the subproposal. We did not want to post it to avoid swaying the MKR Compensation Working Group (in a way or another). We honestly presumed that some framework would be drafted by now (at least in an early form).

Future-Proof MKR Compensation Framework

Our MKR Compensation Proposal is based on the 180-day price average of MKR’s price (we want to use this Framework when MKR is $40,000 as well as $400,000). We held it for three weeks and ended reviewing our MKR proposal down (because the price of MKR went up). I don’t think anyone is thrilled about waiting any longer.

Less Contentious?

Arguably, our MKR Compensation Plan is less aggressive than the one proposed by Protocol Engineering.
We’re proposing, on average, about a third of the MKR per FTE, compared the Protocol Engineering’s proposal.

Critical for our Team

Many people in SES will not go ahead without the MKR Compensation within the Compensation Package. We hold that this (similarly to the Dai Compensation) is vital for the team’s development. I cannot stress this point enough.

Next Steps

That said, we don’t want to alienate you (or anyone in Governance) and show goodwill on our side:

• We will split the MKR Compensation Implementation Budget from the Dai Compensation Budget.
• Since this is a “new” Budget Implementation (more from a technical than a practical point of view) it will fall into the next cycle. We will review it and publish it before the deadline.
• We will lock the amount of MKR to the price already calculated in our proposal. We think this is a good compromise.

[Davidutro]

I’m of the opinion that if there are substantial material changes, extra RFC time is appropriate. In this particular case I think it’s right to leave off the MKR compensation piece, to be amended-in later, and to get the CU into the May cycle.

Remember, budgets of recently passed CUs that are under 3 months old can be amended using the weekly governance cycle. So there is flexibility to change things pretty quickly if needed.

One thing we want to avoid is a month of unnecessary delay if everything else is good to go.

[Davidutro]

@juan

We will lock the amount of MKR to the price already calculated in our proposal. We think this is a good compromise.

Does this mean CUs that launch later will have significantly different MKR payouts? Does it make sense to lock in a price? Should all the year 1 CUs agree to lock in a common price?

All questions for the compensation working group.

[juan]

@Davidutro

substantial material changes

It’s hard to quantify that. Drawing the line is not that simple.

[juan]

@Davidutro

Does this mean CUs that launch later will have significantly different MKR payouts?

Yes. It depends on the MKR price at the time of submission.

Under our proposal, the amount of MKR is based on your market value and the value of MKR at the time of submission. If you submit when MKR is $40,000 you would get 10% of the MKR you would get if the price was $4,000.

@Davidutro

Does it make sense to lock in a price?

We would be submitting today, if it was not for the advice received.
We would like to lock that price.

@Davidutro

Should all the year 1 CUs agree to lock in a common price?

No. Why would you establish an arbitrary time range? The difference between month 1 and month 12 is much larger than from month 12 to month 13.

Our proposal fixes this. ; )

We’ll be sharing it soon.

[Davidutro]

@juan

No. Why would you establish an arbitrary time range? The difference between month 1 and month 12 is much larger than from month 12 to month 13.

Personally, I just don’t like this idea of locking in a price. The price is so volatile, why would you tie rewards to it? It will incentivize CUs to propose themselves before they are ready just to lock in a favorable/low price. Or the opposite, CUs may decide to wait a month in anticipation a lower MKR price. Or in general, it just creates a weird variable that has a huge long-term effect on the amount of USD$ denominated compensation one receives and is based almost fully on luck. I imagine we want CUs that begin in the same time range to have similar locked prices if the DAO decided to use this model for everyone.

An alternative approach could be to do what PE did in their budget proposal and allocate based on % of total supply. Besides not relying on price, this would give the advantage of having a less volatile reference point and common standard for everyone to measure themselves against.

If a full time engineer is getting 0.1%, perhaps a full time member of SES gets the same 0.1% or 0.075% if that’s what’s decided.

All in all, I just don’t like the model you guys are going with.

[Aaron_Bartsch]

Anyone else concerned about all these MKR vesting proposals going through without a framework? As an MKR holder and not a DAO employee I’m concerned that we don’t yet know the scope of what we’re paying for and when all is said and done could be paying out a lot more MKR than we efficiently need to. Not targeting this Core Unit specifically but this conversation has brought this idea forward.

Like, we really should have paused on the Protocol Engineering Core Unit to get this fleshed out but since they’re kind of necessary we didn’t really have a choice I get that but still…

[juan]

As mentioned:

@juan

We’ll be sharing it soon.

[amyjung]

Yes that’s why I went around and asked the various core units. “Yes” = willing to wait for a framework.

Framing a Framework for MKR Compensation - Wednesday, March 31 17:00 UTC

As a follow up, Operational Support has been reaching out to Core Units in RFC, Public Draft , and Approved to get the sentiment on if they’re willing/how they want to move forward with incentives/MKR while the overarching framework is being defined. Below is the summary of current sentiments. This ongoing document outlines more detailed answers. This comment thread will be updated with more core unit responses. Questions Are/were you planning to include vesting in your core unit? What are so…

This might warrant a different thread…

The tension I see is there seems to be little trust in timing. Core units want a solution locked in, and the MKR Compensation working group is on its way, but it will take time. According to @longforwisdom the WG plans on posting some guidance documentation in May for starters, but at minimum, that framework will also need to go into 2 month (RFC / Vote).

Another thing to try to balance this is that the RWF has been working on a budget framework that will allow the DAO to see operational burn / runway as well as tie into MKR valuation. @Aes is working on the budget and already in the MKR Compensation WG.

[wouter]

The OP has now been updated and is ready for the freeze period.

Changes compared to the original RFC:

• Budget Implementation mechanic was defined in detail
• Multi-sig wallet addresses were added
• Expectations around MKR incentives were added
• Salary changes
  • Adding 2 legal roles (2 x 0.4 FTE)
  • Moved 3 Integrations Engineers from the Incubation Program to permanent team (3 FTEs total)