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

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

Address confirmed and added to multi-sig :slight_smile:

2 Likes