MIP40c3-SP55: Modify Core Unit Budget - Sustainable Ecosystem Scaling (SES-001)

MIP40c3-SP55: Modify Core Unit Budget - Sustainable Ecosystem Scaling (SES-001)


MIP40c3-SP#: 55
Author(s): @wouter, @juanjuan
Contributors: @Retro
Tags: core-unit, cu-ses-001, budget, dai-budget, 
Status: Formal Submission
Date Applied: 2021-12-08
Date Ratified: yyyy-mm-dd

Sentence Summary

MIP40c3-SP55 modifies the Dai budget implementation for Core Unit SES-001: Sustainable Ecosystem Scaling, replacing MIP40c3-SP31.

Paragraph Summary

MIP40c3-SP55 modifies the Dai budget implementation for Core Unit SES-001: Sustainable Ecosystem Scaling. It contains:

  • Changes against the previous version
  • The Quarterly Budget Cap: the hard limit voted by Governance
  • Breakdown of budgets:
    • Permanent Team
    • Incubation Program
    • Grants Program

Changes (compared to MIP40c3-SP31)

  • Automates payments from the Maker Protocol to the Auditor Wallet by putting a DssVest stream in place.
  • Reconfiguration of the Auditor Wallet to a nested multi-sig, modifying signers.
  • Configure Maker Protocol as Beneficiary on the Auditor Wallet.
  • Adjustments and additions to the Monthly Top-up Cycle.
  • Introduces DssBlow as a method of returning funds to the protocol.
  • Changes quarterly budget cap approval to annual budget cap approval by Governance.
  • Minor changes in the budget categories for better consistency with other Core Units.
  • Removed the MKR Compensation Expectation as it is now covered by a separate MIP: MIP40c3-SP17.



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

Core Unit ID


Budget Implementation

The budget is split into three separate categories: Permanent Team, Grants Program, and Incubation Program.

Multi-sig Wallets

The following multi-sigs are involved:

  1. The Auditor Wallet – A nested, 2-out-of-2 Auditor multi-sig, composed of 1-out-of-2 role based multi-sigs as signers. The Auditor Wallet will have 2 roles defined for its signers: Auditors and Accountants.

    The Accountant Role Multi-sig will have 2 signers, both SES permanent team contributors. The Auditor Role Multi-sig will also have 2 signers, both TBD. Both roles will conduct the monthly auditing process as described in the Monthly Top-up Cycle, increasing transparency of the auditing process for the community.

    The Maker Protocol (MCD_PAUSE_PROXY, 0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB) will be listed as a beneficiary on the Auditor Wallet. This allows the protocol to withdraw up to 1B DAI from the Auditor Multi-sig wallet, ensuring control over these funds and acting as a back-up.

    This multi-sig will hold funds up to the Quarterly Budget Cap in DAI and receive the DssVest stream. All funds pass through this wallet before any are sent to the Operational Wallets.

  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. Previous Month’s Actuals, i.e., the actual expenses (DAI and MKR) of the month that just ended.
  2. Budget Forecast, based on the latest available information, of the budget (in DAI) required to maintain a 3-month runway for the team.
  3. MKR Vesting Overview – this schedule has the expected MKR vesting amounts for the current team configuration, grouped by the pay-out month.
  4. Transaction Amounts
    • The required DAI amount sent from the Auditor Wallet to the Operational Wallets to replenish the 3-month runway as indicated in the Budget Forecast section.
    • Any excess DAI amount above the 3-month forecast in the Operational Wallets that will be returned to the Auditor Wallet.

The Monthly Budget Statements can be found in this git repository on Github.

Monthly Top-up Cycle

  1. Monthly Budget Statement Submission – Within the first 5 days of the month, SES submits the Monthly Budget Statement to the Auditor 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 Transaction – One DAI transaction for the Operational Wallets that adds enough funds to the Operational Wallets to replenish the forecast 3-month runway. Only applies if the Operational Wallets balance is below this forecast.
  3. Returning Excess Funds – SES creates and signs any transactions for excess funds that should be returned to the Auditor Wallet:

    • Excess DAI Transactions – DAI transactions for Operational Wallets that have a balance above the 3-Month Budget Forecast will be returned to the Auditor Wallet.
  4. DssVest Pull - The Auditor Wallet signers will pull available funds from the SES DssVest contract, replenishing the available funds in the Auditor Wallet.

  5. Auditors’ Review – The Auditor Wallet signers review the Monthly Budget Statement. First, Accountant Role signers will review the initial report submitted by SES to ensure data accuracy and report completeness. A consistent audit checklist will be followed. The Auditor Role will then receive the Accountant’s report generated from the checklist, and verify the Accountant’s findings.

    A summary of each audit cycle’s report will be made available to the Maker Community at the conclusion of the audit cycle on the SES’s transparency reporting repository on Github.

  6. Transaction Approvals – Upon acceptance of the Monthly Budget Statement audit, an Accountant Role signer, and an Auditor Role signer will sign the requested transactions, sending the DAI top-up amounts to the Operational Wallets.

  7. Auditor Wallet Returns – The Auditor Wallet signers will return any amount of DAI above 2x the Monthly Budget Cap. The Auditor Wallet, using the DssBlow contract described here, will return the excess DAI directly to the surplus buffer.

    As such, the Auditor Wallet will then hold up to 2x the Monthly Budget Cap at the start of the month, allowing DssVest to stream DAI up to the Quarterly Budget Cap over the course of the month.

Final Transaction According to MIP40c3-SP26

No additional governance transactions are needed to enable the transition from MIP40c3-SP31 to the new MIP40c3-SP55, other than putting the DssVest stream in place that is defined further down.

The last top-up transaction from the protocol to the Auditor Wallet according to MIP40c3-SP31 is expected to happen throughout the month of January, after acceptance of the December budget statement by the auditors.

Auditor Wallet Reconfiguration

To enable this payment flow, a modification in the configuration of the existing SES Auditor Wallet will be required. These changes will occur within the first month of the executive vote passing.

  • Add Accountant Role Wallet (0xA2A855Ac8D2a92e8A5a437690875261535c8320C) as a signer
  • Add Auditor Role Wallet (TBD) as a signer
  • Add MCD_PAUSE_PROXY as a beneficiary, with an allowance of 1B DAI withdrawal.
  • Remove existing 3 signers of wallet and reconfigure required confirmations from 2-out-of-3 to 2-out-of-2.


  • DssVest Stream

    A total of 5,844,444 DAI will be streamed to 0x87AcDD9208f73bFc9207e1f6F0fDE906bcA95cc6 starting 2022-2-1 and ending 2023-1-31.

    (5,844,444 DAI is calculated as Quarterly Budget Cap x 4 = 1,461,111 x 4).

Budget Breakdown

The proposed budget comprises three parts:

  1. Permanent Team Budget – The Permanent Team Budget covers Dai compensation 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 in a relatively slow and predictable way.

  2. 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 used for funding incubation projects at the discretion of the SES Facilitator and multi-sig co-signers.

    A big part of the Incubator Program’s value lies in this ability to allocate budgets without waiting for governance approval quickly. 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.

3 months no support

  1. 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.

Dai Expenditure

Quarterly Budget Cap

We’re asking for a Quarterly Budget Cap of $1,461,111, spanning a 3-month runway.

Group Monthly Total 3 Months
Permanent Team $177,037 $531,111
Incubation $250,000 $750,000
Grants $60,000 $180,000
Grand Total $487,037 $1,461,111

Permanent Team

Type Monthly Total
Dai Compensation (11.5 FTEs) $146,918
Travel Costs $3,333
Buffer $8,333
Software Development $4,168
Software $1,785
Payment Fees (gas & payment processor) $12,500
Grand Total $177,037

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

Incubation Program

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

Teams Avg Team Size People Total Avg Dai Compensation Annual Cost Monthly Cost
Sr. Engineers 4 4 16 $160,000 $2,560,000 $213,333
Non-technical 6 4 24 $125,000 $3,000,000 $250,000
Mix 4 5 20 $137,500 $2,750,000 $229,167

Estimations of different incubation costs at industry standards.

Grants Program

The details for the Grants Program are still being worked out. To avoid updating 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.

Related Documents


This budget update MIP is submitted by SES as part of our effort to help standardizing budget implementations, and to pave the way for further automation in terms of payments, reporting and auditing.

No changes were made to the total budget cap.

1 Like

Do you think you could just highlight the reason each of these were done in a sentence or two to provide rationale behind each change (where it makes sense to do so)? Overall the implementation looks superior to the previous but it helps provide context and illustrates SES’ thinking.


Wondering if you folks at SES have taken a look a Coinshift (formerly known as multisafe—Gnosis compatible) to automate this complex process?

Yes, sure. It’s a good question:

Automates payments from the Maker Protocol to the Auditor Wallet by putting a DssVest stream in place.

This is mainly to remove any auditing workload from GovAlpha’s plate (and the other CUs that need to put the executive spells for payments in place.)

In our previous model, the payment depended on the balance of the auditor wallet and GovAlpha had to either calculate themselves or just trust us with the number; this doesn’t scale up. The manual work also introduces potential errors, and the budget cap can be breached if the manual check fails.

With DssVest, it’s certain that no more than the budget cap will be sent to the auditor wallet. From the protocol’s pov, it’s also more transparent to have the DssVest streams in place that stream the budget cap (see makerburn.com )

Reconfiguration of the Auditor Wallet to a nested multi-sig, modifying signers.

This is a preparation to professionalize the roles of accountants and (finance) auditors of core units. The accountant role does the bulk of the work that’s so time-consuming: running all the checks on the monthly budget statement. The auditor reviews this output as a double-check: both roles need to sign. The auditor can also advise when complications arise or judgement calls need to be made.

By having nested role multisigs with 1:N quorum, the accountant and auditor roles can be executed by teams rather than single individuals. This increases scalability and redundancy. For example payments won’t get blocked because someone is on vacation.

(Today, SES is taking up both the accountant and auditor role of the core units we’re advising, even if the signers are already different individuals. We’d like to see this done by independent CUs in the future. For ourselves, we’ll look for another team to do the auditor check as a start.)

Configure Maker Protocol as Beneficiary on the Auditor Wallet.

Using this configuration, the Maker Protocol can unilaterally withdraw the funds from the Auditor Wallet (with an executive vote.) This is good for multiple reasons:

  • It emphasizes that the Accountant and Auditor roles work in a reviewer capacity. The funds are not owned by them but by the protocol.

  • This can also be important for tax liability reasons, depending on the jurisdictions where the Accountant and Auditor signers are located.

  • It’s consistent with MIP47 requirements.

Adjustments and additions to the Monthly Top-up Cycle.

These are modifications to keep the Monthly Top-up Cycle consistent with the other changes in the list.

Introduces DssBlow as a method of returning funds to the protocol.

The down-side of using DssVest, is that the entire budget cap is streamed, while the core unit will consistently use significantly less than the total cap. This difference can be especially large in the case of SES because the expenses for our incubation program and grants program may vary significantly from month to month.

Instead of relying on the CU to return the funds at the end of the year after they’ve accumulated unused budget all the time, the auditors will require a more exact, 3-month forecast (typically quite a bit lower than the budget cap) from the CU. This is done before funds are moved from the Auditor Wallet to the Operational Wallets, and the Operational Wallets will be topped up only with the difference between their current balance and the forecast.

So, this provides the CU with more exact funding than when the budget cap is used. And, any budget that still surpasses a buffer of 2 months budget cap in the Auditor Wallet (after the transfer was made to the Operational Wallet), will be returned immediately by the auditor to the protocol.

DssBlow is the technical tool needed to properly return funds to the protocol surplus buffer. (The surplus buffer cannot receive a normal ERC20 transaction for technical reasons.)

Changes quarterly budget cap approval to annual budget cap approval by Governance.

This applies a budget expiry of one year. After one year, a new budget MIP needs to be submitted. This further reduces governance overhead.

Minor changes in the budget categories for better consistency with other Core Units.

In order to support DAO-wide summaries of the CU budget statements, budget categories (line items) need to be consistent. For example: if one CU has a “Travel” line item and an “Events” line item while another lumps the two together, summarizing becomes difficult.

There’s still more work to be done here. But we’re already trying to apply the same naming convention and grouping when the opportunity arises.

Good timing too: @Retro will talk more about our transparency and quality control framework for core units later today on the SES Weekly Status Update: The Art of Core Unit Budgetting. Check it out :).


We are talking to a few teams building DeFi finance / accounting / treasury apps.

Coinshift I wasn’t aware of. Thanks for the tip, we’ll put them on the list :).


We’re formally submitting this MIP for the January cycle.