MIP107: Protocol Scope

Protocol scope updates to new token denominations

1: Scope improvement

1.1: The Protocol Advisory Council

The Protocol Advisory Council is a group of Ecosystem Actors that have been approved by Maker Governance to carry out advisory work related to improving the content of the Protocol Scope Artifact.

1.1.1: Protocol Advisory Council Membership Management

Members of the Advisory Council are directly approved by Maker Governance through a governance poll, and must fulfill specific criteria.

1.1.1.1

The Protocol Facilitators must ensure that potential Advisory Council Members can apply to be approved by Maker Governance, using an open process with clear instructions.

1.1.1.2

Advisory Council Members must be Ecosystem Actors that are not involved in any business activity that could result in a conflict of interest, either directly or indirectly. They must also have relevant skills for providing professional expert input on the content that the Protocol Scope is covering.

1.1.1.3

The Protocol Facilitators must periodically, when it is relevant, review the Advisory Council Applications, and if they find applications that are suitable, bring them to a vote through an MKR governance poll. Approved Advisory Council Members are added to 10.2.3.1.

1.1.1.4

The Protocol Facilitators may, if they deem it necessary, trigger a vote to remove an Advisory Council Member. If an Advisory Council Member has not done any paid work for the Scope for at least 1 year, then the Protocol Engineering Facilitators can choose to remove them at will, if they deem it necessary.

1.1.1.5

The current approved Protocol Advisory Council Members are recorded in 1.1.1.5.1A.

1.1.1.5.1A

¤¤¤

Current list of Advisory Council Members:

• N/A

¤¤¤

1.1.2: Protocol Advisory Council Projects and Funding

The Advisory Council is paid on a project basis to do specific work that improves all or specific parts of the Scope Framework.

1.1.2.1

Each Quarter, if they deem it necessary, the Protocol Facilitators must solicit proposals and find one or more suitable Advisory Council Member to perform a project that will result in output that can be used to improve the Scope Artifact. This work output will be presented to the AVC Subcommittee Meetings as input for their Aligned Scope Proposals. As many AVCs as possible should be supported this way, prioritized by the Protocol Facilitators.

1.1.2.2

In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Protocol Engineering Facilitators may publicly notify the Advisory Council Members to submits proposals for projects that aim to reactively specify the language of the Scope Framework to take into account the specific situation. The Protocol Engineering Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll.

1.1.2.3

The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Protocol Facilitators must either transcribe it themselves, or hire an Ecosystem Actor to perform the transcription. This role does not require pre approval by Maker Governance.

1.1.3

The Protocol Facilitators may produce advisory input on the content of the Scope Artifacts themselves, as long as it is focused on improving process and governance content. They are prohibited from providing unilateral input on expert subject matter content.

1.1.4

The Protocol Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in 1.1.4.1B.

1.1.4.1B

¤¤¤

The Advisory Council project budget is as follows:

Quarterly Budget (DAI) Method of Distribution Maximum Limit (DAI)

0 Keg - streamed at a linear rate over 3 months 0

¤¤¤

1.2: Protocol Scope DAO Toolkit Integration

The Protocol Scope DAO Toolkit module must be built to give a full overview of all smart contracts, code and other technical items and parameters that are relevant to understand the security and technical architecture of the Maker Ecosystem. The Protocol Scope must continue to develop ways to integrate access to the Scope into the DAO Toolkit.

2: NewChain Protocol Specification, Maintenance, and Upgrades

The Protocol Facilitators and all relevant Ecosystem Actors must use their resources to support the early stages of research and development of NewChain, when relevant.

2.1: NewChain Bootstrapping Budget

The NewChain bootstrapping budget is available to be used on work related to the NewChain project. The NewChain bootstrapping budget is specified in 2.1.2B, and is allocated to relevant projects through a manual governance poll and executive vote using the weekly cycle, when triggered by the Protocol Facilitators posting a message to the Maker Core forum containing the relevant information. It is a one time budget that can only be increased or renewed through the Aligned Scope Proposal process. Some of the budget is immediate and some of it relative.

2.1.1

A relative budget means a budget that is only available if the Maker Protocol is generating enough income to actively burn, and the budget can then at most spend a smaller amount of what’s being burned, ensuring that the burn continues.

2.1.2B

¤¤¤

The NewChain bootstrapping budget is:

• 1,000,000 DAI immediate budget available for use through the manual process using the Weekly Governance Cycle

• 9,000,000 DAI relative budget that only becomes available as DAI is being burned in the Smart Burn Engine. The conditions are: At least 20 million DAI must have been sent to the Smart Burn Engine before the relative budget begins to unlock. Once the minimum requirement has been met, the relative budget unlocks at a rate equivalent to 25% of the DAI that is sent to the Smart Burn Engine. This means that the full 9,000,000 DAI will be available once 36,000,000 DAI above the minimum requirement has been transferred to the Smart Burn Engine.

¤¤¤

3: NewChain Native Governance and Neural Tokenomics

The Protocol Facilitators and all relevant Ecosystem Actors must use their resources to support the early stages of research and development of the Native Governance and Neural Tokenomics modules of NewChain, when relevant.

4: Two-stage Bridge

The Protocol Facilitators and all relevant Ecosystem Actors must use their resources to support the early stages of research and development of the Two-stage bridge system, when relevant.

4.1: Multichain Engineering Budget

The Multichain Engineering budget is specified in 4.1.1B. It is implemented as a DssVest stream that is controlled by the Protocol Facilitators, and paid out to Ecosystem Actors in order to do work necessary for Multichain Engineering to function properly. The Multichain engineering budget should eventually be replaced by a permanent budget. Prior to the launch of NewChain, the multichain engineering budget can be used for limited bootstrapping purposes of other technologies in addition to the Two-Stage Bridge.

4.1.1B

¤¤¤

The current Multichain Engineering budget is:

• 2,300,000 DAI per year implemented through DssVest streaming linearly, expiring May 2024.

¤¤¤

5: Developer Tools and Support

The Protocol Facilitators and all relevant Ecosystem Actors must use their resources to support the early stages of research and development of Developer tools and support, when relevant.

6: NewChain Halt

The Protocol Facilitators and all relevant Ecosystem Actors must use their resources to support the early stages of research and development of NewChain halt and restart procedures, when relevant.

7: SubDAO Frontend Client Diversity

The Protocol Facilitators and all relevant Ecosystem Actors must use their resources to support the early stages of research and development of NewChain client diversity, when relevant.

8: The Dai Stablecoin

The Protocol Facilitators must ensure that no development of Dai or NewStable occurs that is misaligned with the permissionlessness and unseizability requirements specified in ATL4.8. When NewStable is launched, it must be possible to wrap from Dai to NewStable 1:1 in unlimited amounts.

8.1: Stablecoin Recovery

The Protocol Facilitators must facilitate the development of a system for returning stuck and accidentally burned Dai and NewStable in situations where it can be proven that they are guaranteed to be permanently stuck.

9: Scope Bootstrapping

Before the launch of NewChain, some Articles have been modified to override their Atlas requirements, and additional Articles have been added.

Before the launch of NewChain, the key concerns that these articles cover must be taken over by other parts of the Scope Artifacts.

10: Ethereum Core Protocol Development

Before the launch of NewChain, the Ethereum Core Protocol must be developed to support bootstrapping efforts. Facilitators and the relevant Ecosystem Actors must work together to develop, launch and maintain these

10.1: Ethereum Core Protocol Features

A number of Ethereum Core Protocol features must be developed and launch as a prerequisite to the development of NewChain. The different features must be developed to coordinate around multiple launch phases. After the delivery of Launch Phase 3, all resources must be focused on the complete launch of NewChain which marks the end of the bootstrapping period and the beginning of the Endgame State.

10.1.1

Launch Phase 1

10.1.1.1

NewStable with a 1:1 wrap from and to Dai available.

10.1.1.2

NewGovToken with a 1:12000 wrap from and to MKR available.

10.1.1.3

Smart Burn Engine for NewStable/NewGovToken pair.

10.1.1.4

Savings Rate for NewStable with referral code system.

10.1.1.5

NewGovToken farm for NewStable with referral code system.

10.1.1.5.1

Emissions of 100 million NewGovTokens per year.

10.1.1.6

AllocatorDAO Vaults

10.1.2

Launch Phase 2

10.1.2.1

6 Core SubDAO proxies.

10.1.2.2

Dssvest of 40 million NewGovToken per year for the 4 AllocatorDAO proxies and 50 million NewGovToken per year for the 2 FacilitatorDAO proxies.

10.1.2.3

6 farms with a referral code system that enables users to farm the 6 SubDAO tokens with NewStable. Tokenomics as per the Atlas.

10.1.3

Launch Phase 3

10.1.3.1

Ethereum Core Sagittarius Lockstake Engine.

10.1.3.1.1

A 6 month launch bonus period where the yield farming is boosted with an amount of SubDAO tokens equivalent to the amount of SubDAO tokens that would have been farmed by Lockstaked users if the Sagittarius Lockstake Engine had launched already in Launch Phase 2.

10.1.3.2

6 farms that enable users to farm 4 million NewGovToken per year with each SubDAO token.

11: Governance Security Engineering Work

Governance Security Engineering work includes development and deployment of spells in a secure manner.

• Writing Spells

• Developer checklists for governance security handover

• Writing Governance Security rulesets

• Developing other related materials

11.1: Governance Security Engineering Budget

The Governance Security Engineering budget is specified in 11.1.1B. It is implemented as a DssVest stream that is controlled by the Protocol Engineering Facilitators, and paid out to Ecosystem Actors in order to do work necessary for Governance Security Engineering to function properly. The Governance Security engineering budget should eventually be replaced by a permanent budget.

11.1.1B

¤¤¤

The current Governance Security Engineering budget is:

• 2,200,000 DAI per year implemented through DssVest streaming linearly, expiring May 2024.

¤¤¤

12: Ethereum Core Protocol Maintenance and Upgrades

Core work involves any engineering efforts that lead to smart contract additions in the Maker MCD system and/or related repos beyond spell development. Without listing all the Core contracts, summarizing the scope of this area as:

Core engineering code:

• The bulk of all 113 Maker solidity repos and associated modules

• Maintenance - rolling tasks:

  • Integrations and implementation updates

  • Keepers

  • Supporting Infrastructure updates (compilers etc)

  • Keeping on top of L1 and any EIP changes, and e.g. gas optimization opportunities

Tooling:

• On-chain automation and integration tools

• Reusable command line tools

• Developer and internal scripts and maintenance

• Inheritable testing and interface modules

• External tooling support as needed to meet core unit objectives (i.e. foundry support)