MIP106: Support Scope

0: The Support Scope

The Support Scope covers rules that regulate various tasks of ecosystem support, including governance process infrastructure and management, SubDAO and Ecosystem Actor support, Public Good Purpose System.

1: Scope Improvement

1.1: The Support Advisory Council

1.1.1: The Support Advisory Council Definition

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

1.1.2: Support 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.2.1: The Support 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.2.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 Support Scope is covering.

---

1.1.2.3: The Support 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 1.1.2.5.1A:.

---

1.1.2.4: The Support 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 Support Facilitators can choose to remove them at will, if they deem it necessary.

---

1.1.2.5: The current approved Advisory Council Members are recorded in 1.1.2.5.1A.

1.1.2.5.1A:

¤¤¤

Current list of Advisory Council Members:

• N/A

¤¤¤

1.1.3: Support 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: Each Quarter, if they deem it necessary, the Support 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 AVC Subcommittee Meetings as the starting point for the AVC Scope Framework Position Documents. As many AVCs as possible should be supported this way, prioritized by the Support Facilitators.

1.1.3.2: In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Support Facilitators may approach one or more Advisory Council Members to perform a reactive project that aims to specify the language of the Scope Framework to take into account the specific situation. The Support Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll, quickly resolving the challenge.

1.1.3.3: The Advisory Council can in some cases produce work output that is not directly compatible with the formatting of Scope Artifacts. In this case the Support 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.4: The Support 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.1.3.5: The Support Facilitators have a budget available to pay for Advisory Council Projects. 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 accounted for in a forum post at least a week before any transaction occurs.

1.1.3.5.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: DAO Toolkit integration

The Support Facilitators and Advisory Council Members must develop ways to display the Support Scope in the DAO Toolkit to make it as accessible as possible.

2. Governance Process Support

2.1: Governance process definition

Maker Governance uses various core governance processes to manage its core decision making processes, including the Endgame MIP process, AVC and Scope Framework modification processes, and AVC and Delegate processes. The Support Scope is only responsible for facilitating routine processes that clearly follow the rules and instructions of the Atlas and the Scope Artifacts. As soon as something is ambiguous or is appealed, it is covered by the Governance Scope instead.

2.1.1: The Support Facilitators must balance and prioritize the resource allocated to AVC support. If resource constrained, the Responsible Facilitators must prioritize resources to focus on providing support to the AVCs that are most valuable to governance security. Governance security value is primarily determined by the size of the AVC, but also by the focus of the AVC - this means that smaller AVCs that introduce significant diversification benefits and increase voter choice must be prioritized above their size.

2.1.2: Pregame MIP Process

The Support Facilitators must facilitate MIP processes and ensure they are followed according to the rules.

2.2 AVC Internal Governance Process Support

2.2.1: AVC internal governance processes

The Support Scope is responsible for tracking AVC internal governance proposals, AVC internal governance votes and resulting AVC Decisions. As the Support Facilitators track AVC internal governance processes, they must publish the activity to enable the broader community to follow

2.2.1.1: AVC internal governance proposals are messages sent by an AVC Member that is cryptographically signed by their verified Ethereum Account.

2.2.1.2: AVC internal governance votes are “for” or “against” messages sent by an AVC member that are cryptographically signed by their verified Ethereum Accounts.

2.2.1.3: The Support Facilitators must ensure that the necessary infrastructure and services are available for AVCs to function as intended by the Atlas, making participation in Maker Governance as convenient and streamlined as possible for AVC Members. A particular focus is the ease of transition from ordinary MKR holder to fully participating AVC Member.

2.2.1.4: The AVC must have their own forums with categories for each of the Scopes to be able to collaborate in public on the AVC Scope Framework Position Documents and the AVC Aligned Governance Strategy Position Documents.

2.3: Quarterly Scope Process

2.3.1: AVC Quarterly Scope Process

AVCs must have the necessary support to hold quarterly AVC Subcommittee Meetings for each Scope. The meetings must be recorded and published on the Maker Forum.

2.4: Scope Defined Processes

2.4.1.: Arbitrary Scope Framework processes

Scope Frameworks contain various customized processes, often related to submitting governance proposals or modifying Active Elements. The Support Facilitators are tasked with tracking and verifying that these processes are performed according to the rules. An action taken through a Scope Framework process is only valid if the Support Facilitators have been correctly notified.

2.4.2: Designation of Governance Process Support Ecosystem Actors

The Support Facilitators can publicly designate Ecosystem Actors, including individuals, companies or Forum or Chat pseudonyms, as Governance Process Support Ecosystem Actors. This is done alongside giving them moderation rights and other forms of administration rights on the relevant communication channels. Governance Process Support Ecosystem Actors can make edits and process updates according to the various Governance Process rules, and can interact with the MIP process as defined in MIP0. For the purposes of MIPs or other Governance related documents, anything that applies to MIP Editors also applies to Governance Process Support Ecosystem Actors, as they replace the MIP Editor role.

2.5: Governance Process Support Ecosystem Actors

2.5.1: Governance Process Support budget

The Responsible Facilitators of the Ecosystem have resources available to procure the necessary administrative support and services from Ecosystem Actors to assist in performing the duties contained in this article. When all duties cannot be fully met with the allocated resources, the Responsible Facilitators must thoughtfully prioritize and ensure that only the most critical processes and budgets are prioritized. Whenever the budget is used, its exact use must be reported clearly on the Maker Forum, and it can only be used to perform tasks described in this section.

2.5.1: The budget for the tasks described in the Governance Process Support Article is defined in 2.5.1.1B. The Active Element can be proposed to be modified urgently by the Responsible Facilitators using a weekly cycle governance poll, or through the standard AVC process.

2.3.1.1B:

¤¤¤

The budget available to fund Governance Process Support tasks is:

• 0 Dai per quarter

¤¤¤

3: DAO Toolkit core development

The DAO Toolkit is a unified governance software system that is used to simplify, organize and standardize all of the governance processes and information of Maker Governance and the Scope Artifacts. Each Scope must, over time, be implemented using the DAO Toolkit as it is developed to make them interactive and make it easier for newcomers to understand how Maker Governance works.

3.1: DAO Toolkit Core Development

The Support Facilitators must fund the development of the core underlying software and modules of the DAO Toolkit that is used to implement the Scope Frameworks as software. DAO Toolkit Core Development is funded through the budget defined in 3.1.1B. This Active Element is modified using the standard AVC process.

3.1.1B:

¤¤¤

The budget available to fund DAO Toolkit Core Development tasks is:

• 0 Dai per quarter

¤¤¤

3.2: Standardized DAO Toolkit patterns

The DAO Toolkit must be developed and used across all of the Scope Framework to unify the user experience of all aspects of Maker Governance as much as possible.

3.2.1: Similar concepts, items, modules and patterns that are implemented in DAO Toolkits for different Scope Frameworks, needs to be as consistent and easy to understand as possible.

3.2.2: The Support Facilitators must ensure that continuous processes are in place to detect, analyze and standardize repeating patterns that are implemented in the DAO Toolkit across the Scope Frameworks, and specify them in the subelements of this clause.

3.3: DAO Toolkit best practice

The Support Scope must cover the general management and organizational design learnings that occur as the Scope Frameworks operate and implement the DAO Toolkit. The best practice for how to use it in a way that creates the best results and is Universally Aligned with the Atlas must be documented in as much detail as possible, to make it possible to monitor compliance.

3.3.1: DAO Toolkit monitoring

The Support Facilitators must ensure that the use of the DAO Toolkit by other scopes is continuously monitored and reviewed.

3.3.1.1: The compliance with best practice and following of standardized patterns by other Scope Frameworks must be verified, and when failures to comply are found the Support Facilitators must notify Maker Governance.

---

3.3.1.2: The Responsible Facilitators must ensure there are continuous attempts to find new reusable patterns and organizational design learnings when monitoring implementation of new concepts of the DAO Toolkit.

4: Core Artificial Intelligence System (CAIS)

The CAIS consists of multiple redundant, diversified large-scale artificial intelligence models operating in remote data centers, trained to provide alignment engineering and business process optimization for MakerDAO, SubDAOs and Ecosystem Actors implemented as Scope Artifact generation and strengthening. They are accessible by Alignment Conservers, MKR holders and SubDAO token holders.

4.0: Core Artificial Intelligence System (CAIS) overview

The CAIS is hosted on rented supercomputers in redundant, diversified data centers and provides Alignment Conservers, MKR holders and SubDAO token holders access to powerful, scaled up AI models that can directly assist in operating, auditing and improving the Scope Artifacts of MakerDAO and SubDAOs, and the business processes of Ecosystem Actors.

The distinguishing feature of the CAIS is its power and scale, and the fact that it is optimized for the most critical use case of directly operating and strengthening the core governance logic of the MakerDAO and the SubDAOs. This necessarily also means that access to it is scarce, and as a result it has governance role-gated and token-gated access to use it.

The token-gating also provides utility for the MKR token as Ecosystem Actors may use it to improve their own business processes by accessing the data, fine-tuning and reinforcement learning that has already been bootstrapped by MakerDAO.

The Maker Ecosystem as a whole, and in particular the SubDAOs, benefit greatly from the economies of scale of an aligned ecosystem sharing the costs of renting and training high-powered AI models to do similar tasks (business process optimization). The ability of SubDAOs to cheaply tap into high-powered, cutting edge AI, will allow them to bootstrap and develop mature processes extremely quickly at launch, without any reliance on a centralized team.

4.1 Core Artificial Intelligence System (CAIS) functional objectives

The CAIS must be developed and optimized to enable Alignment Conservers, MKR holders and SubDAO token holders to perform key functions specified in the following subelements.

4.1.1: Generate creatively varied interpretative examples of edge cases from higher Scope elements, from the perspective of what actions a Facilitator would take. This allows Maker Governance to explore a wide range of possible outcomes and consequences of a given process or rule specified in an element, and Maker Governance can then manually label each interpretive example as good, neutral or bad, and also provide example penalty values in the cases of bad action. Overall, this gives rich data for Facilitators to use as a reference point for real events that interact with the element.

4.1.2: Generate higher Scope elements from examples and lower elements. This enables Maker to use AI to create better and more concise rules from the large dataset of labeled examples. This may result in rules becoming more generalized and be based more on common first principles that properly cover their intention. It also enables Maker Governance to better reorganize higher elements to make them more precise and coherent.

4.1.3: Provide suggested actions to Facilitators for a given situation, and provide Alignment Conservers and MKR holders a very accessible method of reviewing whether a Facilitator acted according to best practice in a given situation. Leveraging the data of the actual elements that define the rules, and the data from the interpretative examples, and then the actual data of the situation being contemplated, the AI can make a best guess based on all available data. By also including the Atlas in the context dataset this functionality also covers a very accessible method of reviewing the universal alignment of actions taken by Facilitators or other Alignment Conservers. Democratizing the ability to detect misalignment is crucial for maintaining long term community alignment and ensuring the proactive effect of the whistleblower process remains game theoretically sharp.

4.1.4: Generate Scope Artifacts from scratch or do complete overhauls of existing Scope Artifacts based on ideas from SubDAO communities. With enough computing power, data and reinforcement learning of the results obtained from performing the functions in 4.1.1, 10.1.2 and 4.1.3 the CAIS will be able to fully generate or redesign and populate complete sets of Scope Artifacts and all associated processes and DAO Toolkit functionality for any kind of economic opportunity a SubDAO wants to explore. This allows existing SubDAOs to rapidly iterate on their business focus with just a few active community members using AI tools, and it allows brand new SubDAOs to become fully functional and fully “populated” in an extremely short amount of time, as almost no humans need to be involved in the normal functioning of a SubDAO.

4.1.5: Generate detailed elements related to evaluating credit risk and business potential to support AllocatorDAOs in deploying collateral in a way that is maximally efficient and safe. By leveraging the same data that enables the CAIS to determine credit risk and business potential, this functionality also allows Ecosystem Actors to use the CAIS to generate improvements to their businesses, and directly implement them through Standard Operating Procedures that describe best practices to increase efficiency and reduce risk. This will also likely often involve providing strategies for integrating AI tools into businesses to make them resilient against AI disruption. As such, it means that when the technology has sufficiently matured, the Maker Ecosystem becomes a driver of impactful AI deployment and integration across the global economy.

4.2: Core Artificial Intelligence System technical principles

The CAIS should be developed using cutting edge components and services from a diverse set of Ecosystem Actors, and lead best practice in safe scaling of AI powered economic activity.

4.2.1: The starting point of the CAIS design should be based on LLMs chained with reflection (or similar functionality) and relevant plugins, and should be fine tuned on data curated by relevant Ecosystem Actors for the functionality described in 4.1.

4.2.2: As much as possible of the core CAIS stack should be open source, and there must always be contingency plans for resilience against closed source access denial.

4.2.3: The CAIS must be optimized for safety and corrigibility as it scales in power, utilizing advanced solutions such as automatic shutdown of the hardware if an on-chain heartbeat signal isn’t detected. The Maker Ecosystem must ensure adequate funding for AI safety research and methods for ensuring decentralization of AI power and detecting collusion between AI systems.

4.3: Core Artificial Intelligence System development budget

The CAIS needs to be bootstrapped with significant initial funding, and must continuously be improved to maintain its edge for Maker Core and the SubDAO ecosystem. The budget is broken down into multiple the bootstrapping budget for research, development and operation, and the hardware and maintenance budget for hardware related costs.

4.3.1: The CAIS bootstrapping budget is immediately available to be used on work related to bootstrapping the first version of the CAIS, including designing, configuring, deploying and fine-tuning the first models, and setting up long term reinforcement learning and do initial monitoring and adjustments. The CAIS bootstrapping budget can also be used on other AI projects than the CAIS. The CAIS bootstrapping budget is specified in 4.3.1.1B, and is allocated to relevant projects through a manual governance poll and executive vote using the weekly cycle. It is a one time budget, some of it immediate and some of it relative, that can only be increased or renewed through the regular AVC process. This element is meant to eventually be transitioned into a long term automatically renewing budget, if the results are satisfactory.

4.3.1.0: 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.

4.3.1.1B:

¤¤¤

The CAIS bootstrapping budget is:

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

• 4,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 4,000,000 DAI will be available once 16,000,000 DAI has been transferred to the Smart Burn Engine.

¤¤¤

---

4.3.2: The CAIS hardware and maintenance budget can be accessed directly by the Support Facilitators, and must be spent on hardware and continuous maintenance of the CAIS deployments. Initially, before the CAIS has been bootstrapped and is ready to be activated, the CAIS hardware and maintenance budget is inactive, and is not available to access. The budget can be activated and modified using the Weekly Governance Cycle by a proposal triggered by the Support Facilitators. The CAIS hardware and maintenance budget is specified in 4.3.2.1B.

4.3.2.1B:

¤¤¤

The CAIS hardware and maintenance budget is:

• Up to 150,000 DAI per month, available at the start of the month, paid out manually through bundling into weekly executive votes - Inactive

¤¤¤

5: Milestones and results reporting standardization

5.1: General guidelines on Milestones and results reporting of projects funded by the Maker Protocol

All funding of projects from resources provided by the Maker Protocol through the Scopes must report their milestone progress and results in a standardized way, eventually incorporating it into the DAO Toolkit. All Scopes must at minimum enforce the reporting and transparency requirements defined in the Support Scope Artifact.

5.1.1: It must be as easy as possible for Maker Governance to get an overview of the status and the success rate and probability of all ongoing and past projects.

5.2: Research and mitigation of transparency risks

The Support Facilitators must allocate resources towards long term research into the potential risks of transparency measures failing due to cultural or other issues.

5.2.1: Maker Governance must have a current understanding available about how transparency and misalignment can manifest itself in the short term and long term.

5.3: Monitoring of milestone and results reporting

The Support Facilitators must ensure that continuous monitoring of the reporting of milestones and results of project is occuring in a way that adequately mitigates the short term and long term risks of inadequate reporting and transparency.

5.4: Budget reporting

All budgets in the Maker Ecosystem must have detailed reports provided by the relevant Ecosystem Actors and Facilitators, either as forum posts or through the DAO Toolkit.

6: SubDAO incubation

6.1 Genesis Templates for FacilitatorDAOs, AllocationDAOs, and MiniDAOs

TBD

6.2 Community Communication Channels

6.2.1: Incubating SubDAO community support overview

During the Pregame, the Support Facilitators are tasked with incubating the communities for the 6 Launch SubDAOs, alongside the Incubating Ecosystem Actors that have potential to provide them with services. Incubation of communities focuses on communication, community building and cultural development.

6.2.2: Incubating SubDAO communication infrastructure

The Responsible Facilitators of the Support Scope must deploy resources to set up and maintain high quality communication and community infrastructure for Incubating SubDAOs.

6.2.2.1: Incubating SubDAOs require a SubDAO forum with a good user experience for both governance activities and community interaction.

—-

6.2.2.2: Incubating SubDAOs require a chat server for both governance activities and community interaction.

—-

6.2.2.3: Incubating SubDAOs can request support for high quality conference call capacity from the SupportScope, but this must only be provided if it is used at large scale commensurate with the costs and overhead of supporting it.

—-

6.2.2.4: The Support Facilitators are tasked with maintaining administrator rights to the SubDAO communication infrastructure, and select community moderators among the most active and aligned community members. Forum polls and community consultations can be used to ensure that there is broad representation of the SubDAO community among the community moderators. In case of moderation disputes the Support Facilitators must solve the dispute, or escalate it to the Governance Scope.

7: Ecosystem Actor Incubation

The Support Scope is responsible for incubating Ecosystem Actors alongside Incubating SubDAOs. Ecosystem Actors that are being prepared for the benefit of future SubDAOs are called Incubating Ecosystem Actors and are managed through this Article. While waiting for the incubating SubDAO launches, Maker Governance assigns Incubating Ecosystem Actors useful projects that can benefit the Maker Protocol, or work for developing protocols, products or services that can be adopted and are likely to be useful for the currently incubating SubDAO.

7.1: Incubation Objectives

The Incubation Objectives determine the types of projects that Maker Governance will consider for Incubating Ecosystem Actors, and how they will be weighted on their potential to generate specific desirable results. Each Incubation Objective is given a priority weight between 1 and 5, which determines how big and how relatively important the objective is.

7.1.1: Branding, marketing, user acquisition, user experience

SubDAOs should have cutting edge, innovative and experimental solutions available to help them grow their userbase and their SubDAO Frontends. Incubating Ecosystem Actors that can build integrated userbase focused solutions should be preferred, in particular if they can provide metrics and milestones related to long term sustainable user retention, cost per user, and can operate with flexible budgets. Priority: 5.

7.1.2: Referral marketing and revenue share systems

Products that provide self-funded user acquisition such as referrals, revenue share and similar mechanisms should be considered. Priority: 3.

7.1.3: Flexible smart contract development

Smart contract development companies that can build the most basic solutions such as kegs, and can successfully submit secure governance actions to the Maker Governance Security Scope are critical for the sustainability of a SubDAO. They should be funded to ensure there is a redundant supply of smart contract development companies available for SubDAOs, so that they do not get bottlenecked even if a single supplier suddenly disappears. Priority: 5.

7.1.4: Protocol development companies

Maker should fund companies that develop smart contract protocols, and help them bootstrap Plug and Play Protocol business models to provide a large range of available products and services to users that can be further improved through the use of innovative and experimental frontend concepts.

7.1.5: Other useful services including legal services, economic and risk advice, community development, and more.

7.2: Ecosystem Actor Incubation related budgets

The Support Facilitators have two budgets available to support the tasks described in this section, the incubation overhead budget and the incubation budget.

7.2.1: The Incubation Overhead budget is contained in 7.2.1.1B and is modified through the regular AVC process.

---

7.2.1.1B

¤¤¤

The Incubation Overhead budget is:

• 0 Dai per quarter.

¤¤¤

---

7.2.2: The Incubation budget is contained in 7.2.2.1B and is modified through the regular AVC process.

—

7.2.2.1B:

¤¤¤

The Incubation budget is

• 0 Dai per quarter

• Up to 0 MKR per quarter.

¤¤¤

7.3: Incubation Proposal process

7.3.1: Incubation Proposal submission process

Ecosystem Actors can apply to become Incubating Ecosystem Actors by submitting a proposal to be processed by the Support Scope. To submit an Incubation Proposal, the Ecosystem Actor must make a post on the Maker Forum following the template provided in 7.3.1.1T, and comply with all requirements described in this section.

7.3.1.1T:

TBD

7.3.1.2: Incubation Proposals must clearly detail their costs, both direct and indirect, and the results and benefits they provide to the Maker Ecosystem, in particular in relation to the Incubation Objectives.

---

7.3.1.3: Incubation Proposals must detail their headcount, team skill set composition, and reliance on third parties.

---

7.3.1.4: Incubation Proposals must provide a clear timeline with detailed, granular milestones, and the KPIs to review at each milestone to determine whether to continue funding.

7.3.2: Incubation Proposal review process

The Support Facilitators must use the Incubation Overhead budget to ensure the highest quality Incubation Proposals are thoroughly reviewed, with the final review published before the Support Facilitators decides to fund a proposal.

7.3.2.1: Proposals should only be reviewed if there is an available budget in the Incubation budget.

7.3.2.2: Multiple factors should be considered holistically when reviewing Incubation Proposals, including the amount of remaining budget, the potential impact on the Incubation Objectives, and, whether the Incubation Proposals help alleviate the gaps in the Incubation Objectives that currently aren’t filled by other Incubating Ecosystem Actors.

7.3.2.3: All Incubation Proposals must be thoroughly reviewed in terms of their results reporting commitments and their mechanisms to ensure results and progress can be easily assessed while the project is ongoing. In particular very clear and thoughtful milestones connected to the provision of additional funding must be well reviewed and compared to alternatives. These transparency results must be made public, and Incubation Ecosystem Actors that that do not have the highest levels of results transparency must be marked in advance with a clear justification for the reduced results transparency

7.3: Milestone review process

Incubating Ecosystem Actors commit to predetermined milestones where they will submit their results and meet specific requirements before receiving additional funding.

7.3.1: If a milestone result isn’t met, funding for the Incubating Ecosystem Actor can still continue, but only based on a thorough assessment by the Support Facilitators. If the failure to meet the milestone was caused by a risk that was understood and detailed as part of the proposal, and if there were already contingency plans in place in case the risk materialized, and it is generally a reasonable risk that was understood and accepted from the start of the project, then this should weigh in the favor of the Responsible Facilitators continuing to fund the Incubating Ecosystem Actor.

---

7.3.2: In situations where the broader economics of MakerDAO are constrained, only Incubating Ecosystem Actors that are clearly delivering on their milestones should have their funding continued, while those that do not meet their objectives and as a results are more risky, should have funding proactively discontinued to preserve ecosystem resources.

7.4: Currently incubating

This section contains the Active Element where all the current Incubating Ecosystem Actors are recorded. It is important that all relevant information to understand budgets, results, milestones, and overall performance is available in the Active Subelement of each Incubating Ecosystem Actor.

7.4.1: The list of Incubating Ecosystem Actors must follow the template contained in 7.4.1.1T for each recorded Incubating Ecosystem Actor.

7.4.1.1T:

¤¤¤

• .x: [Incubating Ecosystem Actor name and short description]

• .1: [Budget information]

• .2: [Deliverables and focus areas]

• .3: [Team information, including headcount grouped by skill sets]

¤¤¤

7.4.2: The list of Incubating Ecosystem Actors and their current key terms and data is provided in the Active Element 7.4.2.1A. The Support Facilitators must update the Active Element and populate all the relevant real time information in the Active Subelement of each Incubating Ecosystem Actor. Before NewChain launches this Active Element can also be used to generate budget payout spells and smart contracts.

7.4.2.1A:

¤¤¤

For the April Governance Cycle, if the edit is approved, a one-time Governance Poll is triggered upon approval of the edit that asks whether Maker Governance wishes to keep the PullUp Ecosystem Actor. If the result is yes, then the PullUp Ecosystem Actor remains in the list with the below parameters until further updates are made. If the result is no, then the PullUp Ecosystem Actor is removed from the list.

List of Incubating Ecosystem Actors:

Ecosystem Actor Name	Budget Allocation	Ecosystem Actor Goal	Team Members
Phoenix Labs	318,000 DAI paid out immediately in the beginning of May 2023.
127,833.33 DAI and 82.1875 MKR per month for all roles	Deliver the Spark Protocol and maintain it for 12 months, and support SubDAO launch	1 Business Development, 3 Smart Contract developers, 1 Developer Relations.
Viridian Protector Advisory Company	257,250 DAI provided immediately upon successful confirmation of the Incubating Ecosystem Actor in a Governance Poll.
85,750 Dai per month for full team.	Provide Protector Advisor work.	Business Development, Risk Analyst, Lawyer.
dewiz	150,000 DAI and 21 MKR per month.	General smart contract development and Collateral Onboarding Technical work (RWA focused).	5 Smart Contract developers.
Sidestream	70,912.5 DAI per month.	Full stack smart contract and frontend development.	3.5 FTE full stack developers.
PullUp	3,300,000 DAI over one year implemented as dssvest.
4000 MKR over two years implemented as dssvest. Full amount of MKR will not be drawn immediately, only as new contributors are onboarded	Innovation Engineering:
Smart Burn Engine
Sagittarius Engine
SubDAO launch
Maker Chain	Team member information will be kept private, instead detailed deliverable roadmap will be provided.

¤¤¤

8: Ecosystem communication channels

The Support Facilitators are tasked with maintaining an ecosystem wide forum and chat platform for SubDAO participants and Ecosystem Actors to interact with each other and discuss the Maker Protocol and ecosystem.

8.1: An ecosystem forum for business proposals to SubDAOs, SubDAO partnerships and interactions, and casual conversation for the broader Maker Ecosystem.

8.2: A chatroom, initially using discord, for broad discussion related to SubDAOs, Ecosystem Actors and Maker.

8.3: Communications infrastructure budget

The ecosystem communication infrastructure, as well as the AVC communication infrastructure and the Incubating SubDAO communication infrastructure budgets are covered in this section. The budget is contained in 8.3.1B.

8.3.1B:

¤¤¤

The ecosystem communication infrastructure budget budget is:

• 0 Dai per quarter.

¤¤¤

9: Ecosystem Agreements

Ecosystem agreements are partially binding decentralized agreements that can be made by SubDAOs and Ecosystem Actors. It involves making a formalized agreement and commitment from a single party or between two parties. This can cover for instance, binding revenue share deals (including plug and play protocol code with predetermined revenue share terms), binding commitments to pay a fee upon delivery of a specific work output (enabling milestone payments that also provide job security for the Ecosystem Actor).

9.1: Ecosystem Agreement Standardization

Many types of Ecosystem Agreements are based on standardized terms and relationships, and to protect participants these types of Ecosystem Agreements will be standardized in the Support Scope. All agreements that fall under the definition of a standardized agreement have their terms automatically overridden by the standardized terms. Participants are also penalized for failing to follow standardized terms.

9.1.1: List of standardized Ecosystem Agreement and their standardized terms:

9.1.1.1: Milestone-based payment. This is a common type of Ecosystem Agreement where a SubDAO commits to pay an Ecosystem Actor a predetermined amount of value upon delivery of a specified work product, such as code or research output. If the work product is delivered properly, verified by the Ecosystem Agreement Enforcement process, and the SubDAO is forced to pay the committed amount.

9.1.1.2: Plug and Play Protocol. PnP Protocols are finished codebases of smart contract protocols that are easily adopted and included in SubDAO Decentralized Frontends. The original publisher of the codebase can tag the codebase as a PnP Protocol codebase by including in the source code PnP terms that describe terms such as a minimum protocol, and revenue share of the protocol fee. Any SubDAOs that adopt PnP codebases are forced to comply with the PnP terms.

9.2 Ecosystem Agreement enforcement

The Support Facilitators can enforce Ecosystem Agreements when terms are unambiguously breached by a single participating party through bundled Maker executive vote payloads to seize assets from SubDAOs, bundled Maker executive vote payloads to seize collateral from collateralized Ecosystem Actors, or by blacklisting uncollateralized Ecosystem Actors. Seized assets are used as remedy for the harmed party.

9.2.1: Ecosystem Agreement Enforcement overhead budget

The Support Facilitators will have a budget available to maintain the capacity to monitor, analyze and interpret Ecosystem Agreement disputes.

9.3 Ecosystem Agreement dispute resolution prices

When a party to an Ecosystem Agreement wants to resolve a dispute, they must pay for the work of analyzing and resolving the dispute under the Support Scope. The principles and processes for this must be specified in this section.

9.3.1: Ecosystem Agreement dispute appeal process

A party to an Ecosystem Agreement dispute can choose to appeal the resolution to a dispute made by the Support Scope to the Governance Scope, based on GOV3.

10: Resilience Fund

This Article defines the process for funding legal defense and responding against a legal or regulatory action targeted against a participant of the Maker Ecosystem or against MakerDAO.

10.1: Resilience Bodies

This section covers the resources available for legal defense. Over time it can include both Maker Governance controlled assets and external third party resources, and may be used to cover additional risks.

10.1.1: The Resilience Fund

The Resilience Fund (RF) is a self-insurance instrument fully controlled by Maker Governance which will cover legal defense expenses in case of legal or regulatory action against the DAO or active participants in the Maker ecosystem. The RF will be the primary source for direct legal defense funding. The conditions of use are defined in “Resilience Claims Process” (10.4).

10.1.1.1 The budget of the Resilience Fund is defined in 10.1.1.1.1A. The Physical Resilience Facilitator can propose to pay out the budget manually through weekly cycle, according to the rules related to claims described in this Section. The Physical Resilience Facilitator can propose modifications to 10.1.1.1.1A through the weekly cycle.

10.1.1.1.1A:

¤¤¤

The current active budget for the Resilience Fund is: 5000000 Dai per year, with the full amount available at the start of each calendar year.

¤¤¤

10.2 The Resilience Technical Committee

The Resilience Technical Committee is a group of Ecosystem Actors that provide advice on assessing claims against the RF and advice on further development of the fund and risk management topics.

10.2.1: Members of the Resilience Technical Committee are selected and paid for services on a project basis by the Physical Resilience Facilitator. The budget for this is included in 10.1.1.1.1A. This is later intended to move to a separate budget.

---

10.2.2: The members of the Resilience Technical Committee must fulfill the following requirements:

10.2.2.1 Members must have experience equivalent to and / or currently working for a world leading insurance broker, insurance company or risk management company.

10.2.2.2 Members must have at least three years of experience in management of Self Insurance instruments.

10.2.2.3: Members must have law, management, risk, or insurance professional degrees.

10.2.2.4 Members may not be involved in any business activity that could result in a conflict of interest, either directly or indirectly.

10.2.3: Current approved Resilience Fund Technical Committees members are specified in 10.2.3.1A. The Support Facilitators can directly edit the Active Element to include new Resilience Technical Committee Members that fit the criteria.

10.2.3.1A:

¤¤¤

List of active Resilience Fund Technical Committee Members:

Gallagher

¤¤¤

10.3: The Lawyer Registry (LR)

The LR is a registry of specialized Ecosystem Actors who are qualified for performing legal work for MakerDAO or participants in the MakerDAO ecosystem, such as, and not limited to, legal representation or legal defense.

10.3.1: Lawyer Registry Acceptance Criteria. Lawyers that are included in the Lawyer Registry must fulfill the requirements described in the following subelements.

10.3.1.1 Licensed legal professional in their respective jurisdiction.

10.3.1.2 Proven experience with MakerDAO or crypto.

10.3.1.3 No Conflict of Interest.

---

10.3.2: Legal counsel providing services funded through the RF must fulfill additional requirements specified in the following subelements. Legal counsel qualified for RF will be listed as such in the Lawyer Registry.

10.3.2.1 20 years of relevant professional experience.

10.3.2.2 Lead Counsel in at least 15 cases in the relevant area of law, type of process and jurisdiction.

---

10.3.3: LR template. Entries in the LR must follow this template:

* .x: [Advisor name and short description]
  * .x.1: [Name of Firm]
  * .x.2: [Specialization Area]
  * .x.3: [Jurisdiction]
  * .x.4: [RF qualified (y/n)] 

---

10.3.4: The current approved legal counsels in the LR are recorded in 10.3.3.1A. The Physical Resilience Facilitator can directly edit the active element to include new legal counsel that fit the criteria.

10.3.3.1A:

¤¤¤

List of active legal counsel in the Lawyer Registry:

¤¤¤

10.4: Resilience Fund Claims Process

This section will govern the conditions and terms of use of the Resilience Fund.

10.4.1: Loss Event

The Resilience Process covers legal defense or legal representation expenses incurred by a participant of the Maker Ecosystem when they are the target of a legal or regulatory action (“The Loss Event”). There must be a direct relationship between the legal or regulatory action and the Beneficiary’s activity at MakerDAO. A (Non - exhaustive) list of legal or regulatory actions that may qualify are described in the following subelements.

10.4.1.1 Official requirements, or communications, from a regulatory body, governmental authority or a court

10.4.1.2 Subpoenas

10.4.1.3 Lawsuit

10.4.1.4 Writs

---

10.4.2: Exclusions

The cases specified in the following subelements will generally be excluded from coverage by the legal defense process.

10.4.2.1 Prior or pending claims.

10.4.2.2 Claims between persons involved in the Maker ecosystem.

10.4.2.3 Loss covered by other insurance.

10.4.2.4 Willful criminal offenses.

10.4.2.5 Conflict of Interest.

---

10.4.3: Beneficiaries

Eligible beneficiaries are persons who fulfill the following requirements:

a) act on their own behalf OR b) act on behalf of a legal entity OR c) act on behalf of a collective AND have one of following roles:

Previous Structure:

• Recognized Delegates

• Core Unit Facilitators

• Core Unit Contributors

Current Structure:

• Active MKR or SubDAO Token Holders that participate regularly in governance (e.g. voting, writing proposals)

• Alignment Conservers

• Aligned Voter Committee Members (AVCs)

• Aligned Delegates (ADs)

• Facilitators

10.4.3.1Beneficiaries can be identified through their own name or through a pseudonym.

10.4.3.2 Persons qualified as beneficiaries do not have any acquired right or claim. Claim decision process is described in 10.4.5 payout is contingent on a MKR vote.

10.4.4: Onboarding process Resilience Fund

Overview of the onboarding processes:

• Application.

• Approval.

• Registration. These processes are described in the following subelements.

10.4.4.1 Application process.

Applicant fills in the below registration form.

• [User Name / Pseudonym]

• [Verified Ethereum Address]

• [Proof of Eligibility]

  • Examples of Eligibility Lists

    • Core unit facilitators - The Maker Forum

    • Maker Governance - Delegates

    • https://expenses.makerdao.network/

• Contact point (e-mail, discord, etc.)

10.4.4.2 Approval Process.

The Physical Resilience Facilitators must work towards developing an automatic solution that enables eligible ecosystem participants to easily apply for the Resilience Fund Process.

If no automatic process is in place, or if the process doesn’t function correctly, the Physical Resilience Facilitator must process the request manually, and must publish an easy to understand guide for how to apply through the manual process.

10.4.5: Claim Management.

Overview of the claim management processes:

• Legal Counsel Pre- approval

• Claim approval / Advance Payment

• Reimbursement

10.4.5.1 Legal Counsel and quote Pre-approval

The first step in the claim management process is to approve the Legal Counsel that will undertake legal defense or legal representation and the quote presented to commence legal work. The Beneficiary must present the Quote from the law firm they selected for their legal defense / representation. The Quote must indicate, at least:

• Name of Legal Counsel

• Name of Law Firm

• If not in Lawyer Registry, Proof of Eligibility

• The Quote must include:

1. The initial payment required by Counsel to commence work immediately. This is the initial amount to be claimed against the Resilience Fund.

2. A global estimated fee based on an hourly rate OR fix fee OR retainer

10.4.5.1.1: If the Legal Counsel is RF qualified in the Lawyer Registry (10.3.2 ), the claim is automatically pre approved.

10.4.5.1.2: If Legal Counsel is NOT RF qualified in the Lawyer Registry (10.3.2 ), then the Physical Resilience Facilitators verifies if the Legal Counsel complies with requisites in 10.3.1 (Lawyer Registry Acceptance Criteria) and 10.3.2 (Resilience Fund Acceptance Criteria).

• 10.4.5.1.2.1: If the Legal Counsel of the quote is found to comply with the requirements, the quote is pre-approved and the legal counsel is added to the LR.

• 10.4.5.1.2.2: If the Legal Counsel doesn’t comply with the LR requirements, the claim is rejected and the Beneficiary must propose a different Legal Counsel.

10.4.5.2: Claim Approval

If a Beneficiary incurs in a Loss Event, they can submit a Reimbursement Payout Claim against the LD RF according to following process:

10.4.5.2.1: The Beneficiary submits a Payout Claim by sending an encrypted message to a Support Facilitator.

The Support Facilitator must review the Reimbursement Claim and decide whether to trigger a Governance Poll to perform a claims payout, by developing an internal model with input from experts and professionals.

• 10.4.5.2.1.1: The Payout Reimbursement Claim must contain following elements:

  • Description of Loss Event with relevant commentaries and context

  • Advance Payment or Reimbursement

  • Type of process

  • Date of writ / subpoena / lawsuit

  • Supportive Documentation

    • Law firm’s proposal and invoice OR Quote

    • Copy of the Lawsuit / writ/ communication OR official requirement issued by a Court or Governmental Agency Supportive documentation is highly sensible. It is required to use encryption tools.

• 10.4.5.2.1.2: The Recognized Physical Resilience Facilitators must develop with the Resilience Technical Committee (10.2) a framework for establishing limits and coverage amounts per case, and apply these limits to individual claims.

10.4.5.2.2: The Physical Resilience Facilitators will review the Payout Claim and if it contains all required elements and supportive documentation, will immediately transmit it to the Resilience TechnicalCommittee (10.2).

10.4.5.2.3: The Resilience Technical Committee will verify the merits of the claim according to following substantial criteria (non-exhaustive list):

• Absence of Exclusions (10.4.2)

• Identity and Role of Beneficiary (10.4.3)

• Time scope

• Authenticity of writ / lawsuit

10.4.5.2.4 From the moment the Payout Claim is filed, the Resilience Technical Committee will have five (5) working days to provide a payout recommendation. The recommendations of the Technical Committee are definitive and have no appeal.

10.4.5.2.5 Quorum and decision majorities.

Decisions related to claim payouts require a quorum of three (3) experts from the Resilience Technical Committee with simple majority (>50%).

10.4.5.2.6 The recommendations of the Resilience Technical Committee are non binding and will not give rise to any right or claim to the beneficiaries nor give rise to any obligation or responsibility.

10.4.5.2.7 Based on the recommendation of the Resilience Technical Committee, the Physical Resilience Facilitators will decide whether to trigger a Governance Poll through the weekly cycle to perform a claim payout.

10.4.5.3 Payout/reimbursement.

If the governance poll for paying out a claim is successful, an executive vote must be created to to draw the funds from the Surplus buffer and send them to the Beneficiary’s registered wallet. The spend must be accounted for in the active element of the relevant budget.

10.5: Legal Risk Management

This section defines the framework for managing, retaining and transferring legal risk.

10.5.1.1 Legal Risk Management Bodies

10.5.1.1.1 The Policyholder definition:

The Policyholder is a specialized Ecosystem Actor in charge of executing agreements with external entities with the exclusive purpose of structuring and transferring risk to third parties through instruments such as insurances, reinsurances, mutuals or other types of arrangements. These instruments will provide extended coverage for participants of the Maker Ecosystem.

The object of the PolicyHolder is to:

• Act as legal counterparty with insurance brokers, insurance, reinsurance, underwriters or risk management companies.

• Act as policyholder of insurance contracts which will have as beneficiaries participants of the Maker Ecosystem.

• Hire suppliers and contractors necessary for the operation of self insurance or insurance instruments, such as:

  • The Resilience Technical Committee for claim management (10.2)

  • Managers, Directors and other executive staff of the legal vehicle. Power of directors will be limited to administrative and operative roles.

Maker Governance will have all necessary control mechanisms over the Policyholder:

• Maker Governance can designate and remove Directors, Supervisor and Committees

• Maker Governance can instruct the entity to act and ratify decisions

• Power of directors is limited to administrative / operative roles

• The Policyholder will not manage MakerDAO’s assets nor will be legally affiliated with MakerDAO.

The setup and operational budget of the legal vehicle will be sourced initially from the Resilience Fund (10.1.1.1.1A:). This is intended to move later to a separate budget

10.5.1.1.2: Policyholder management

This section handles the logic of adding and removing PolicyHolders.

PolicyHolders are on boarded or off boarded based on a governance poll by MKR voters, that is initiated by the Physical Resilience Facilitators if they deem it necessary. The active state of current approved PolicyHolders is maintained in 10.5.1.1.2.1A

• 10.5.1.1.2.1A:

¤¤¤

List of current active PolicyHolders:

¤¤¤

11: Resilience research and preparedness

The Support Facilitators must ensure that resilience research and legal preparedness work is covered continuously to ensure the ecosystem is well positioned to deal with any legal uncertainty or risk that should arise. This must generally be broadly diversified across all jurisdictions where the Maker Ecosystem could be directly or indirectly exposed, but efforts and resources must be prioritized towards jurisdictions where risks are more likely to emerge.

11.1: Resilience research and preparedness budget

The resilience research and preparedness budget is specified in 11.1.1B. The Support Facilitators can trigger a payout from the budget to a relevant recipient address through an MKR vote with the weekly governance cycle.

11.1.1B:

¤¤¤

The resilience research and preparedness budget is:

Up to 2,000,000 DAI available per year.

The full amount is immediately available at the start of the calendar year.

¤¤¤

12: Purpose System

To protect the long term integrity of its governance community, Maker will always share financial success with the world through charity that is distributed broadly and with thoughtful and genuine consideration of its impact. This permanent, guaranteed, direct action locks in aspects of universal alignment, even in the face of community misalignment, by ensuring aligned community members are always attracted to participate in Maker Governance and are more likely to voluntarily deal with misalignment issues.

12.1: Long term purpose system

To implement this in practice the Atlas codifies a Purpose System that allocates token emissions to SubDAOs that use them on broad and diverse charitable causes chosen directly through community governance. The Purpose System is regulated through competition between the SubDAOs and checks and balances by the Support Scope Framework to ensure a lasting, verifiable and meaningful impact. It goes into effect with the launch of NewChain

12.1: Purpose Fund

The Purpose Fund will directly allocate 33333 MKR from the Pause Proxy MKR reserves towards charity and public good campaigns that promote responsible, open source AI development and public good impact of open AI software.