Logo

MIP107: The Protocol Engineering Scope Framework

MakerDAO

MIP107: The Protocol Engineering Scope Framework

Preamble

MIP#: 107
Title: The Protocol Engineering Scope Framework
Author(s): @rune
Contributors:
Tags: endgame, scope-framework
Type: General
Status: Accepted
Date Proposed: 2023-02-06
Date Ratified: 2023-03-27
Dependencies:
Replaces:
Forum URL: https://forum.makerdao.com/t/mip107-the-protocol-engineering-scope-framework/19693
Ratification Poll URL: https://vote.makerdao.com/polling/Qmbndmkr#vote-breakdown

Sentence Summary

The Protocol Engineering Scope Framework provides the core principles, rules and regulation regarding Protocol Engineering in the Endgame.

Paragraph Summary

MIP107 establishes the Protocol Engineering Scope Framework. This includes all principles and processes related to the maintenance and development of the core Maker Protocol and its critical components that are not considered collateral components. All rules for Protocol Engineering for the DAO are contained in this framework, including the procedures of the Protocol Engineering Scope Framework Advisory Council.

Component Summary

MIP107c1: Preamble
Contains the Preamble to the Protocol Engineering Scope Framework.

MIP107c2: Scope Framework Articles
Contains the Scope Framework Articles for the Protocol Engineering Scope Framework.

MIP107c3: Responsible Facilitators
Contains details on the Responsible Facilitators for the Protocol Engineering Scope Framework.

MIP107c4: Scope Framework Articles Modification Subproposal Process
Contains details of how the Protocol Engineering Scope Framework can be amended.

Motivation

The Protocol Engineering Scope Framework is necessary to define the Scope as per the Maker Constitution.

Specification

MIP107c1: Preamble

The Protocol Engineering Scope deals with all principles and processes related to the maintenance and development of the core Maker Protocol and its critical components that are not considered collateral components.

MIP107c2: Scope Framework Articles

1: The Protocol Engineering Scope Framework Advisory Council

1.1: The Protocol Engineering Scope Framework Advisory Council definition

The Protocol Engineering Scope Framework 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 Engineering Scope Framework.

1.2: Protocol Engineering Scope Framework 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.2.1: The Protocol Engineering Facilitators must ensure that potential Advisory Council Members can apply to be approved by Maker Governance, using an open process with clear instructions.
  • 1.2.2: Advisory Council Members must be Protocol Engineering 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 Engineering Scope is covering.
  • 1.2.3: The Protocol Engineering 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.2.4: The Protocol Engineering Facilitators may, if they deem it necessary, hold 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.2.5: The current approved Advisory Council Members are recorded in the soft element 1.2.5.1.

    • 1.2.5.1:

    ¤¤¤

    Current list of Advisory Council Members:
    * N/A

    ¤¤¤

1.3: Protocol Engineering Scope Framework 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.3.1: Each Quarter, if they deem it necessary, the Protocol Engineering Facilitators must solicit proposals and find one or more suitable Advisory Council Members to perform a project that will result in output that can be used to improve the Scope Framework. This work output will be presented to the CVC Subcommittee Meetings as the starting point for the CVC Scope Framework Position Documents. As many CVCs as possible should be supported this way, prioritized by the Protocol Engineering Facilitators.
  • 1.3.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.3.3: The Advisory Council may not produce work output that is directly compatible with the formatting of the Scope Framework. In this case the Protocol Engineering Facilitators must either transcribe it themselves, or hire an Protocol Engineering Actor to perform the transcription. This role does not require preapproval by Maker Governance.
  • 1.3.4: The Protocol Engineering Facilitators may also produce advisory input on the content of the Scope Framework 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.3.5: The Protocol Engineering 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 be transparently be accounted for in a forum post at least a week before any transaction occurs.

    • 1.3.5.1:

    ¤¤¤

    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

    ¤¤¤

2: Protocol Engineering DAO Toolkit module

2.1: Protocol Engineering DAO Toolkit module overview page

The Protocol Engineering 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.

3: Core Protocol maintenance and upgrades

3.1: Core Protocol maintenance tasks

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, summarising 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 ontop 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)
3.2: Core Protocol smart contract specifications

This section contains a complete overview of all smart contracts inside the Core Maker Protocol, and all available context.

3.3: Core Protocol maintenance budget

The Protocol Engineering Facilitators have a budget available to fund projects that meet the objectives of the Core Protocol Maintenance Article.

4: Core Protocol Expansion

4.1: Core Protocol Expansion tasks

Core Protocol Expansion involves developing and deploying the latest upgraded version of the Maker smart contracts on new L2 blockchains. The L2 contracts that are currently being built will eventually solidify into core contracts and exist side-by-side with them due to similar security risk assumptions.

L2 expansion (10.5.2 from the Maker Constitution):

  • Existing Optimistic and ZK rollups
  • Unbiased research to support Governance decision making
  • Ongoing monitoring to ensure trust assumptions have not changed or are within thresholds of expectations
  • Future expansion and partnerships based on integration pack completion
4.2: Core Protocol Expansion handover

Once a Core Protocol Expansion project has finished, the final handover is done by designating the new smart contracts as a part of the Core Protocol and adding their specification to 3.2.

4.3: Core Protocol Expansion budget

The Protocol Engineering Facilitators have a budget available to fund projects that meet the objectives of the Core Protocol Expansion Article.

5: Core Protocol Innovation

5.1: Protocol Innovation definition

Protocol Innovation covers the design, development and deployment of the final Endgame Products that are designated in the Maker Constitution. The Endgame Products must be specified in the highest possible detail, as early as possible, to ensure stability of the roadmap and to prevent scope creep and an increase in complexity over time.

5.2: Endgame Product Specifications

Each of the Endgame Products are specified in this section with as much detail as possible.

  • 5.2.1: Elixir module. The Elixir module is a smart contract system that manages a pool of Dai and MKR used in automated market makers to generate liquidity for the 2 assets. It is funded from excess Dai in the Surplus Buffer, regulated by the Finance Scope Framework. 5.2.1.1A Contains a technical drawing of the design that can be updated directly by the Protocol Engineering Facilitators. The feature requirements of the Elixir module smart contracts are described in the Subelements of this clause.

    • 5.2.1.1A:

    ¤¤¤

    [Technical drawing of Elixir module design]

    ¤¤¤

    • 5.2.1.1: An automatic, keeper triggered function that uses Dai from the Surplus Buffer, when it contains Dai above a governance-determined parameter, and uses it to accumulate MKR from the UniV2 MKR/DAI pool. The rate of accumulation must be limited and determined by Maker Governance
    • 5.2.1.2: An automatic, keeper triggered function that takes Dai from the Surplus Buffer and combines it with MKR accumulated by 5.2.1.1 to join the UniV2 MKR/DAI pool. The accumulated UniV2 tokens must be sent to the Pause Proxy. The two functions may be combined.
  • 5.2.2: Sagittarius Engine. The Sagittarius Engine is the fundamental governance incentive smart contract system of the Maker Protocol. It is a system that allows users to delegate MKR, generate Dai with MKR as collateral, and farm tokens. When the MKR holder withdraws their MKR out of the Sagittarius Engine, they must pay an exit fee of 15% of their deposited MKR. 5.2.2.1A Contains a technical drawing of the design that can be updated directly by the Protocol Engineering Facilitators. The feature requirements of the Sagittarius Engine smart contracts are described in the subelements of this clause.
    • 5.2.2.1A:
      ¤¤¤
      [Technical drawing of Sagittarius Engine design]
      ¤¤¤
    • 5.2.2.1: A combined token farming and collateral adapter module that enables users to deposit RMKR to act simultaneously as farming principal and collateral, on the condition that the unwrapped MKR gets delegated to a Protocol Delegation System smart contract.
    • 5.2.2.2: The user must specify a Protocol Delegation System Smart Contract for the RMKR deposit to succeed, and their MKR will be delegated to this target as a part of the transaction.
    • 5.2.2.3: Seamlessly, as a part of the deposit transaction, the user is able to specify one of multiple ERC20 tokens to farm.
      • 5.2.2.3.1: This functionality is launched with support only for the Simple Dai Farm, but it will be compatible with SubDAO launch as more ERC-20 tokens must also be possible to add without having to change the smart contract.
    • 5.2.2.4: The user must be able to complete the actions of depositing RMKR to the Sagittarius Engine, delegating MKR through it, specifying and initiating token farming using 3 transactions: Setting up a proxy contract, approving MKR to the proxy contract, and carrying out all the actions.
    • 5.2.2.5: The user is able to generate Dai with the MKR as collateral, as in a normal Maker Core Vault.
    • 5.2.2.6: The oracle for the MKR prices of Sagittarius Engine Vaults has constrained upwards movement, enabling Maker Governance to throttle the speed at which its reported price increases, regardless of how fast the price is actually increasing. This constraint does not apply to downwards price movement. The oracle constraint parameter is controlled through the Decentralized Collateral Scope.
    • 5.2.2.7: If the users Sagittarius Engine Vault is liquidated, the Collateral Adapter automatically ends the token farming and undelegates the MKR, and puts the MKR up for an auction. Initially, the MKR is not wrapped into RMKR if this occurs.
    • 5.2.2.8: If the user wishes to withdraw their RMKR after paying down their Vault Debt, the MKR is automatically undelegated, the token farming ends, and the MKR is wrapped to RMKR and 85% of the RMKR is returned to the users wallet. The other 15% RMKR is burned as an exit fee.
    • 5.2.2.9: The user must be able to change their delegation target, and change the token they are farming, without having to withdraw their RMKR and pay the exit fee.
  • 5.2.3: Simple Dai Farm. This is a system that enables the token farming functionality of the Sagittarius Engine by drawing Dai from the Surplus Buffer. 5.2.3.1A Contains a technical drawing of the design that can be updated directly by the Protocol Engineering Facilitators. The feature requirements of the Sagittarius Engine smart contracts are described in the subelements of this clause.
    • 5.2.3.1A:
      ¤¤¤
      [Technical drawing of Simple Dai Farm design]
      ¤¤¤
    • 5.2.3.2: Dai is funneled from the Surplus Buffer to the Sagittarius Engine, where it is made available for farming by MKR depositors. The total rate of Dai is determined by Maker Governance Vote and is specified as a fixed amount of Dai per time unit.
    • 5.2.3.2: A smart contract that regulates the amount of Dai funneled from the Surplus Buffer to Sagittarius Engine Farming, targeting 25% of the average accrued surplus over the last month.
  • 5.2.4: MKR redenominator. A system for wrapping (two-way conversion) of MKR into a new ERC-20 token of a different denomination, temporarily denoted RMKR. The Existing MKR token must remain forever, and RMKR can always be unwrapped back to MKR.
5.3: Core Protocol Innovation handover

When Endgame Products detailed in 5.2 are completed and fully deployed, including testing and ramping up their parameters to production status the final step is to hand them over to Core Protocol Maintenance by adding the specification to 2.2.

5.4: Core Protocol Innovation budget

The Protocol Engineering Facilitators have a budget available to fund projects that meet the objectives of the Core Protocol Innovation Article.

MIP107c3: Protocol Engineering Facilitators

The Responsible Facilitators of the Protocol Engineering Scope Framework are defined in MIP113c2.6.1.2.1A.

MIP107c4: Scope Framework Articles modification Sub Proposal process

During the pregame the Scope Framework articles can be modified through the Monthly Governance Cycle using a MIP102c2 subproposal.

Protocol:MakerDAO
Date:February 6, 2023
Author:rune
ABOUTGitHub logo