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

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.
5 Likes

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.

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.

1 Like

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

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.

We would be submitting today, if it was not for the advice received.
We would like to lock that 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.

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.

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…

4 Likes

As mentioned:

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

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.

3 Likes

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)
5 Likes

Quick question - How many people are included in this proposal? The team spreadsheet has approx 20 ppl, and then the incubation program budget cap shows various estimations - are these included or in addition?

3 Likes

Thanks, @Derek. I just made the spreadsheet clearer, as I realize that it didn’t communicate that point effectively.

Our proposal has these main components:

Limit

To be voted by Governance:

  • Total Budget Cap

Transfers

Based on the Report generated each month.

  • Permanent Team Budget
  • Incubator Program Budget
  • Grants Program Budget

We will update the team spreadsheet on an ongoing basis as we define the participants of the program.

3 Likes

The SES team would like to formally submit this subproposal.

Would SES be a possible incubator for LendCo’s that Matt has called for: Calling all large scale secured off-chain lenders (e.g. future "competitors")

1 Like

Thanks for suggesting this. I don’t have enough insight into the matter to say what the role of SES can be, but we’ll reach out to Matt to gain a better understanding.

1 Like

Auditors Wallet Signers

In the meantime, we have confirmed with a number of trusted Maker DAO members that they will be taking up the role of Auditors Wallet signers. The confirmed signers are:

  • @SebVentures (RWF Core Unit) who is also our self-accountability auditor.
    Address: 0x0D61C8b6CA9669A36F351De3AE335e9689dd9C5b

  • @prose11 (GovAlpha Core Unit)
    Address: 0xf3ED2bdeBa77940E6759B806cd55CE20cAE369BE

  • @Aaron_Bartsch (trusted community member)
    Address: 0x30f7A5441eBdB77dD741ea52923ed5033d63aC07

  • @hexonaut (Protocol Engineering Core Unit)
    Address: bellwoodstudios.eth (0x18CaE82909C31b60Fe0A9656D76406345C9cb9FB)

Auditor Responsibilities

The auditors are tasked with (1) reviewing the monthly budget statements that we will submit to them together with the requests for payment, (2) asking questions or providing feedback in case anything is unclear or out of order, and ultimately (3) sign the multisig payment transactions to top up our operational wallets once everything is correct.

Should there be any issue with the payment request that does not get resolved, the auditors will block the payment for the time being, and can escalate the matter to bring it to the attention of the governance community. As such, the process does not depend on the bandwidth of the governance community as a group, making it more scalable than the assumption that for example MKR holders will check everything themselves.

Total Budget Cap

There is one important aspect we need to highlight in absence of a production-ready keg module: the current process relies on the auditing process to keep the budget within its Total Budget Cap.

This is because it is flexible enough to top up the operational wallets with up to 3 months worth of expenses to replenish the runway. While this is very useful to cover exceptional circumstances such as front-loaded or unforeseen temporary expenses, clearly this flexibility must not be used to exceed the budget cap.

We will additionally highlight the Total Budget Spent in the monthly budget statements so that it can be readily checked by the auditors. Once the keg module can be used in production, we will submit a proposal to put it as a guard between the surplus buffer and the Auditor Wallet so that this check is enforced on the smart contracts level.

Thank you!

I’d like to extend our sincere gratitude to the Auditor Wallet signers in this list, for the responsibility that they’re willing to take up. We believe that the practice of a monthly budget statement review will greatly contribute to the improved transparency and scrutiny of the expenses of the Maker Protocol’s funds, by SES and hopefully by the other core units in the future. Big thank you for that!


@SebVentures, @Aaron_Bartsch, @prose11, @hexonaut: if you could double-check the address and confirm in this thread, that would be greatly appreciated. I’ll be waiting for this confirmation to add the addresses to the wallet.

5 Likes

Address looks good. Thank you for this privilege! I’m watching you :eye: :lips: :eye: .

5 Likes

Confirming my address is accurate.

4 Likes

Address looks good.

4 Likes

The setup of the auditor wallet has now been completed:
https://gnosis-safe.io/app/#/safes/0x87AcDD9208f73bFc9207e1f6F0fDE906bcA95cc6

The addresses of the owners can be compared to the auditor addresses in the post. The quorum is already set to 3 out of 4.

2 Likes