# MIP107: Protocol Scope

## 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 as per *1.1.1.3*.

**1.1.1.2**

Advisory Council Members must be Ecosystem Actors that are not involved in any business, political, or other governance-related 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. When Advisory Council Applications are posted on the Maker Forum, which must follow the template as per *1.1.2.4.1A*, the Protocol Facilitators have a review period of 30 days. During this review period, the applicant must host a Community Q\&A and shall answer as many questions and doubts as possible.

**1.1.1.3.1**

The Protocol Facilitators can extend this deadline, if necessary, by 15 days, provided they posted the justification in the Maker Forum.

**1.1.1.3.2**

Once the review period is ended, the Protocol Facilitators must publish the response to the application on the Forum, along with a description of the reasoning behind the decision. If approved, the application will continue with the Governance Process and proceed to a vote as per *1.1.1.3*.

**1.1.1.3.3**

Upon a successful vote, the Protocol Facilitators must arrange a service contract with the Advisory Council member, which must be made public. Approved Advisory Council Members are added to *1.1.1.6.1A*.

**1.1.1.3.4**

Approved Advisory Council members have a term of service of 18 months from the time they are approved by Maker Governance. If desired, the Advisory Council Member can submit a new application for re-election when their term has between 60 and 30 days remaining. The re-election application must also fulfill *1.1.2* requirements and will open a new review period of 30 days where the Maker Community can provide feedback. The applicant shall again host a Community Q\&A and respond to as many questions and doubts as possible. If approved, the re-election application will continue with the Governance Process and proceed to a vote as per *1.1.1.3*.

**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: Protocol Advisory Council Requirements**

**1.1.1.5.1**

Protocol Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Protocol Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame.

**1.1.1.5.2**

Desired competencies for members of the Protocol Advisory Council, as many of the following as possible:

1. Proven experience as a smart contract developer or software architect in web3 and DeFi. Experience in building with COSMOS SDK is a plus.
2. Proven experience as a DevOps Engineer in node/client development.
3. Expertise in Layer 2 and Layer 3 technology.
4. Expertise in building and integrating cross-chain solutions.
5. Experience with processes that create high-impact, mission-critical software that has to perform under constant surveillance by possible attackers.
6. Expertise in smart contract security.
7. Knowledge of advanced cryptographic techniques, including Zero-Knowledge, Snark, and Stark.
8. Expertise in integrating and securing external data sources.
9. Experience in deploying, upgrading, and maintaining complex systems.
10. Passion for technology, innovation, and entrepreneurship.
11. Deep understanding of MakerDAO and the endgame. Intimate familiarity with the smart contracts that make up Maker Protocol is a plus.

**1.1.1.6**

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

**1.1.1.6.1A**

¤¤¤

Current list of Advisory Council Members:

* N/A

¤¤¤

#### 1.1.2: Protocol Advisory Council Recognition

**1.1.2.1**

In order to be eligible for the Protocol Advisory Council as per *1.1.1.3*, an Ecosystem Actor must post a recognition submission message publicly on the Maker Governance Forum.

**1.1.2.2**

The submission message must be cryptographically signed by the Ecosystem Actor address.

**1.1.2.3**

The cryptographically signed Protocol Advisory Council Recognition Submission Messages must contain the information specified in *1.1.2.3.1* and *1.1.2.3.2*.

**1.1.2.3.1**

The following text must be included: “\[Name] Protocol Advisory Council Recognition"

**1.1.2.3.2**

A timestamp recording the time and date that the message was signed.

**1.1.2.4**

The submission message must follow the template *1.1.2.4.1A*

**1.1.2.4.1A**

```
Title: [Name] Protocol Advisory Council Recognition Submission
        - [Ecosystem Actor Ethereum address]
        - [Cryptographically signed Advisory Council Recognition Submission Message]
        - Applicant's name: [Company, team, or individual]
        - Any other relevant identifying details:
            - Twitter:
            - Website:
            - Email:
            - Maker Forum:
            - Telegram:
            - LinkedIn:
            - Discord:
            - Github:
            - Other:
        - Presentation: [Introduction]
        - Ethos and Vision:
        - Team: [Founders and team members. Brief description of their skills and backgrounds]
        - Services: [What is your company specialized in? What kind of services do you offer?]
        - Experience: [A detailed history of relevant previous experience]
        - Client References: [Who are your clients, what projects have you done and can you show the results of any of them?]
        - Explain how your skills will contribute to improving the selected Scope: [Which specific aspect of the Scope do you intend to enhance, and what is the rationale behind your choice? How do you plan to improve the chosen aspect? Provide milestones, if applicable].
        - Payment Details: [How shall the compensation for your contributions be structured?  How many hours shall the work entail? Detail as much as possible]
        - Emergency Availability: [Would you be available on short notice to provide advisory support in the event of an unforeseen emergency? How short of a notice? What would be your hourly rate for emergency advisory services rendered?]
```

#### 1.1.3: 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.3.1**

Entities are encouraged to submit applications with the intention of enhancing a specific portion of the Scope Framework. Any entity can notice a problem in the Scope or something that can and should be improved and apply to undergo a process to suggest improvements. There are also sometimes specific pieces of advisory work listed in 1.1.3.2 that can be taken on by applicants. The Protocol Facilitators should diligently encourage participants possessing relevant areas of expertise to actively engage in this process to the fullest extent possible. Accordingly, once this MIP is successfully passed, it is imperative that the Protocol Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Protocol Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Protocol Advisory Council budget to incentivize ecosystem participants and community members to actively seek out applicants, providing comprehensive explanations of the process.

**1.1.3.2: Advisory Work for Protocol Advisory Council Members**

* Provide support on bridge design in the form of an audit / second look. This advisory work should not exceed a 100,000 DAI budget.
* Provide support on NewChain design / development principals in the form of an audit / second look. This includes a second opinion on the purpose and necessity of NewChain. This advisory work should not exceed a 400,000 DAI budget.

**1.1.3.3**

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. The Protocol Facilitators must communicate in the first 15 days of a quarter if they believe no Advisory Council work is needed for that quarter.

**1.1.3.4**

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.3.5**

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

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

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.5.1B*.

**1.1.5.1B**

¤¤¤

**Applicants should note that budgets for Advisory Councils are intentionally accommodative across the board in order to avoid having to delay by a full monthly governance cycle in unforeseen circumstances. They are not meant to be fully spent, and attempts to spend full budgets are less likely to be approved.**

The Advisory Council project budget is as follows:

**500,000 DAI available as a one-time only budget**

¤¤¤

### 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:24000 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 200 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 80 million NewGovToken per year for the 4 AllocatorDAO proxies and 100 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**

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 Lockstake Engine had launched already in Launch Phase 2.

**10.1.3.2**

6 farms that enable users to farm 80 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)
