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: 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.1.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 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 Support Scope is covering.

1.1.1.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. When Advisory Council Applications are posted on the Maker Forum, which must follow the template as per 1.1.2.4.1A, the Support 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 Support 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 Support 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 Support 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 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.1.5: Support Advisory Council Requirements

1.1.1.5.1

Support Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Support Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. The Support Scope is the broadest and most diverse of all the Scopes as it encompasses all governance topics. The council should be composed of versatile individuals with diverse knowledge and skills, who enjoy challenges, are solution-oriented, and can quickly adapt to changes. Members of the Advisory Council should have or be willing to attain a deep understanding of the Maker Ecosystem and its Endgame goals. Desired competencies for members of the Support Advisory Council are split into sections of the Scope to be improved.

1.1.1.5.2

Desired competencies for members of the Support Advisory Council, as many of the following as possible in the relevant section(s):

Governance Process Support - SUP2

1. Demonstrable experience of at least 1 year working or actively participating in governance.

2. Experience in game theory and consensus.

3. Experience in human resources management.

4. Expertise in governance processes.

5. Expertise in general operations and management, to streamline scope input.

6. Expertise in social choice theory and knowledge of how to increase active participation.

DAO Toolkit core development - SUP3

1. Demonstrable experience in system infrastructure and database management.

2. Experience in a range of programming languages such as Python, Java, JavaScript, C++, and Solidity.

3. Proven experience in data science.

4. Expertise in knowledge presentation.

5. Expertise in collaborative work. Examples include Wikipedia and Twitter community notes.

6. Experience as an intranet builder.

7. Expertise and experience in archival systems or documentation.

8. Experience facilitating workshops for information sharing or consensus building.

Core Artificial Intelligence System (CAIS) - SUP4

1. Specialty in data science and AI. Expertise with AI alignment is a plus.

2. Expertise in LLMs with extensive knowledge, particularly including knowledge about LLM limitations.

3. Demonstrable knowledge of system infrastructure, server management, and DevOps.

4. Expertise in cybersecurity, network security, and server security. Experience as a white hat hacker is preferred.

Budgets, Milestones, and Results Reporting Standardization - SUP5

1. Experience in data analysis.

2. Knowledge of accounting or economics.

3. Experience in business management.

4. Experience in on-chain research.

SubDAO Incubation - SUP6

1. BizDev experience.

2. Experience in growth strategies.

3. Startup or similar managerial experience.

4. Entrepreneurial vision.

5. Financial expertise.

6. Experience with founding or building a DAO.

7. Expertise in community management.

8. Expertise in DAO theory.

Ecosystem Actor Incubation - SUP7

1. BizDev experience.

2. Business development and contract expertise.

3. Expertise in auditing companies.

4. Experience as a commercial manager.

5. Expertise in public grants and tender processes.

6. Experience with contractor onboarding and management.

Ecosystem Communication Channels - SUP8

1. Communication skills

2. Community management experience.

3. Specialty in communication processes for diverse or integrated enterprises.

Ecosystem Agreements - SUP9

1. Contract law expertise.

2. Regulatory specialist.

3. Corporate lawyer with experience in large corporations.

4. Public tender process expertise.

5. Contractor management and deliverable tracking expertise.

Resilience Fund & Resilience Research and Preparedness - SUP10 & SUP11

1. Strong reputation as a law firm.

2. Resilience research and preparedness expertise.

3. Crypto law specialty. Strong legal background and deep familiarity with decentralized finance.

4. Expertise in regulations or lobbying.

5. Experience equivalent to working for a world leading insurance broker, insurance company or risk management company.

6. Experience in management of Self Insurance instruments.

7. Professional Degree in law, management, risk, or insurance.

Purpose System - SUP12

1. Treasury management skills.

2. Experience in AI alignment research or GFM development.

3. Experience in non-profit foundations.

4. Strong aligned values, including emphasis on public goods AI and environmentalism.

5. Expertise in philanthropy, preferably from experience with family offices or other actors that don’t follow political agendas.

1.1.1.6

The current approved Governance 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: Support Advisory Council Recognition

1.1.2.1

In order to be eligible for the Support 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 Support 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] Support 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] Support 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?]
        - 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: 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

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 Support 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 Support Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Support Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Support 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 Support Advisory Council Members

• Develop a standard process for executing legal defense.

• This Scope defines a Legal research and preparedness budget of 2 million DAI a year. An Advisory Council member can be hired to detail and prioritize pertinent legal research that this budget can be spent on. Requirements for this Advisory council member would include a strong legal background and deep familiarity with decentralized finance. It is of paramount importance to find a profile with a proven track record in the field.

1.1.3.3

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.

1.1.3.4

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

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

Maximum Monthly Amount (DAI)	Maximum Monthly Amount (MKR)	Implementation	Start Date	Notes
83,000	N/A	Manual	2023-08-01

¤¤¤

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, Scope Framework modification processes, 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.2: Pregame MIP Process

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

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

2.5.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.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: Governance Artificial Intelligence Tools (GAIT)

The GAIT 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: Governance Artificial Intelligence Tools (GAIT) Overview

The GAIT 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 GAIT is its power and scale, and the fact that it is optimized for the most critical use case of directly operating and strengthening the Self-Aligning Data Structure of 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: Governance Artificial Intelligence Tools (GAIT) Functional Objectives

The GAIT 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 GAIT 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 GAIT to determine credit risk and business potential, this functionality also allows Ecosystem Actors to use the GAIT 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: Governance Artificial Intelligence Tools (GAIT) Technical Principles

The GAIT 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 GAIT 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 GAIT stack should be open source, and there must always be contingency plans for resilience against closed source access denial.

4.2.3

The GAIT 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.2

The GAIT hardware and maintenance budget can be accessed directly by the Support Facilitators, and must be spent on hardware and continuous maintenance of the GAIT deployments. Initially, before the GAIT has been bootstrapped and is ready to be activated, the GAIT 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 GAIT hardware and maintenance budget is specified in 4.3.2.1B.

4.3.2.1B

¤¤¤

The GAIT 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 occurring 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: SubDAO Forum

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

—-

6.2.2.2: SubDAO Chat

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.

6.3: Incubating SubDAO Brands

Some of the incubating SubDAOs do not have a brand identity and are referred to with the following code names: FacilitatorDAOs: ZERO, ONE, AllocatorDAOs: QUAL, QUANT. Support Facilitators and their infrastructure can provide limited support to the community development of these incubating SubDAOs.

Two incubating AllocatorDAOs have established brands: Spark and Sakura. To promote their community development Spark and Sakura can have stand alone communication channels managed by the Support Facilitators and their infrastructure.

6.4: Incubating SubDAO Token Pre-farming

Spark has a special token pre-farming program based on usage of its lending platform. Users of the platform will receive an airdrop, depending on how much and how long they have used the platform during the pre-farming period.

The pre-farming period is active from Ethereum block 17956537 [AUG 20 2023 14:25 UTC] and ends at the earlier of two events:

• Start of SubDAO token farming OR MAY 20 2024 14:25 UTC.

• 30m SPK tokens allocated for the first 9 months.

• Following the end of the initial 9 month period, and additional pre-farming period will continue until the launch of Spark. Rewards are calculated on a per-block basis according to the Anti-cheat formula, at a rate of 3.33m SPK tokens per month.

• SPK portion sourced from SubDAO workforce bonus pool, available immediately at token and Spark launch.

• Final airdrop calculated for each account, based on each block within the valid timeframe.

Only for Ethereum Mainnet. No other chain included.

Anti-cheat formula:

Airdrop = 80% * (Dai Borrows - sDAI Supplies * sDAI Liquidation Threshold) + 20% * (ETH Supplies - ETH Borrows / ETH Liquidation Threshold)

6.4.1: Special SPK Token Pre-farming

The Support Facilitators can activate a new SPK token pre-farming airdrop program to capture other growth opportunities.

The program can last until the moment SPK launches, or a shorter duration, which must be declared by the Support Facilitators. The exact details of the special pre-farming airdrop program is specified in 6.4.1.1A, which the Support Facilitators can modify at will, as long as it conforms the specifications of 6.4.1.

The SPK tokens for the future Spark Airdrop are allocated between all borrowers based on a formula announced by the Support Facilitators and specified in 6.4.1.1A. The rate of SPK tokens being earned is 1.66 million SPK per month, distributed on a per block basis proportional to the formula specified in 6.4.1.1A.

6.4.1.1A

¤¤¤

The details of the special SPK token pre-farming program are: N/A

¤¤¤

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

¤¤¤

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.
Chronicle Labs	310,150 DAI and 184.7 MKR for full team provided monthly as a linear dssvest stream for a 12 month period beginning July 1st 2023.	Launch a sustainable, secure, and decentralized oracle protocol and infrastructure service provider which supports the needs of SubDAOs Raise private capital and cease any further direct funding from MakerDAO.	1x General Manager 3x Smart Contract Engineer, 3x Backend Engineer, 1x Fullstack Engineer, 1x DevOps Engineer, 1x Operations Manager, 1x Business Development Lead, 1x Marketing Strategist, 1x DevRel / Account Manager

¤¤¤

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: Forum

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

8.2: Chatroom

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 AC 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 Agreements 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.

9.4: Active Ecosystem Agreements List Controller

The Subdocuments of this documents records active Ecosystem Agreements that are enforceable by the parties and must be adhered to by Maker Governance.

9.4.1: Spark Protocol Aave Revenue Share

Spark Protocol must pay out 10% of the income it generates from operating the borrowing and lending functionality of the protocol that is based on the Aave codebase. The payment must be calculated manually at the end of each quarter by the SparkDAO Facilitators and manually paid as DAI to a smart contract under the control of Aave Governance from the SparkDAO Surplus Buffer. The payments must occur for the revenue share duration of 2 years, starting from the moment this amendment is approved by Maker Governance. If at any point in time after the launch of SubDAO tokens, Spark Protocol is generating less than 1 million DAI per year in income for SparkDAO, accrual towards the revenue share payments are paused (unpaid revenue share that already accrued is still paid out at the end of the quarter), and the counting down of the revenue share duration is paused. The revenue share payments and the counting down of the remaining revenue share duration is resumed when Spark Protocol is generating more than 1 million DAI per year in income again.

Before the launch of SubDAO tokens, Maker Governance is temporarily responsible for paying out a "virtual revenue share" on behalf of Spark Protocol. It is calculated by taking the total amount of Dai borrowed from Spark Protocol, and then assuming a "virtual income" equivalent to 1% of this supply, and calculating a revenue share of 10% on that behalf. The calculations and payments must be done manually by the Support Facilitators at the end of each quarter. As an example, if before the launch of SubDAO tokens, 200 million DAI is borrowed on Spark Protocol, then the virtual income is 1% of 200 million DAI, which gives 2 million DAI, and of that 2 million DAI the virtual revenue share is 200,000 DAI, which must be paid out in incremental payments each quarter directly by Maker Governance from the Maker Surplus Buffer to a smart contract under the control of Aave Governance. If, before the launch of SubDAO tokens, less than 100 million DAI is borrowed from Spark Protocol by the Maker Protocol, accrual towards the virtual revenue share payments are paused (unpaid virtual revenue share that already accrued is still paid out at the end of the quarter), and the counting down of the revenue share duration is paused. The virtual revenue share payments and the counting down of the remaining revenue share duration is resumed when at least 100 million DAI is again borrowed from Spark Protocol by the Maker Protocol.

Once SubDAO tokens launch, the virtual revenue share system stops being in effect and instead the standard rules of the Spark Protocol Aave Revenue Share Ecosystem Agreement go into effect.

10: Legal Resilience

This section defines the general framework for legal resilience, legal risk management, and legal governance.

10.1: Legal Defense Resources

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 the “Resilience Claims Process” (10.1.1.4.2).

10.1.1.1 Resilience Fund Budget

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

10.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.1.1.1.1 Transition Funding

Legal defense expenses directly related to the DAO may be temporarily financed using the resources of the Resilience Fund. However, a separate Claim Protocol and Standard Operational Procedure will be developed if the DAO is the target of a legal or regulatory action (SUP 10.1.3). The Resilience Technical Committee will assist in elaborating the ruleset.

10.1.1.2 The Resilience Technical Committee

The Resilience Technical Committee is a group of Ecosystem Actors authorized by Maker DAO to provide operational support such as onboarding new beneficiaries to the RF, approving quotes, assessing claims to be supported by the RF, and additionally providing general advice on the further development of the fund, amendments to the claim procedure, resilience measures and other risk management topics.

10.1.1.2.1

The Resilience Technical Committee is selected and paid for services on a project basis by the Support Facilitator. The budget for this is included in 10.1.1.1A. This is later intended to move to a separate budget.

10.1.1.2.2

The individual members of the Resilience Technical Committee directly involved on behalf of the organization must fulfill the following requirements:

10.1.1.2.2.1

Members must have experience equivalent to or currently working for a world-leading insurance broker, insurance company, risk management company, or legal role.

10.1.1.2.2.2

Members must have at least three years of experience managing Self- Insurance instruments or experience in legal or regulatory risk analysis.

10.1.1.2.2.3

Members must have a law, management, risk, or insurance professional degree.

10.1.1.2.2.4

Members must not be involved in any business activity outside Maker DAO or in any role within MakerDAO that could result in a conflict of interest, either directly or indirectly.

10.1.1.2.2.5

Members must have at least three years of experience in the cryptocurrency, DeFi, Web3, or emerging technology sectors.

10.1.1.2.2.6A

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

10.1.1.2.2.6A

¤¤¤

List of active Resilience Technical Committee Members:

Gallagher

¤¤¤

10.1.1.3 : Resilience Fund Policy

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

10.1.1.3.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 defendant or respondent in 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 is described in the following subelements.

10.1.1.3.1.1: Official Requirements, or Communications, from a Regulatory Body, Governmental Authority, or a Court

10.1.1.3.1.2: Subpoenas

10.1.1.3.1.3: Lawsuit

10.1.1.3.1.4: Writs

---

10.1.1.3.2: Exclusions

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

10.1.1.3.2.1: Prior or Pending Claims

10.1.1.3.2.2: Claims between Persons Involved in the Maker Ecosystem

10.1.1.3.2.3: Loss Covered by Other Insurance

10.1.1.3.2.4: Willful Criminal Offenses, Fraud, or Dishonesty.

10.1.1.3.2.5: Conflict of Interest

---

10.1.1.3.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 the following roles:

Previous Structure:

• Recognized Delegates

• Core Unit Facilitators

• Core Unit Contributors

• DAI Foundation Board Members

Current Structure:

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

• Alignment Conservers

  • Aligned Delegates (ADs)

• Scope Facilitators

• The Guardians (SUP 10.1.4) or actors that fulfill an equivalent role

10.1.1.3.3.12

Persons qualified as beneficiaries do not have any acquired right or claim. The claim decision process is described in 10.1.1.4, and the payout of a claim is subject to the approval of the Resilience Technical Committee (at their sole and absolute discretion) and further contingent on an MKR vote endorsing payment of the claim.

10.1.1.3.4: Geographical Coverage

Geographical coverage is worldwide.

10.1.1.3.5: Effective Date

A Beneficiary’s eligibility for coverage under this Artifact will start after ratification of MIP106: 2023-03-27. (“Effective Date”) and expire twenty-four (24) months after cessation of their role as a Beneficiary.

10.1.1.3.6: Base of Coverage

Coverage is “Claims made”. This means the Loss Event (10.1.1.3.1) must occur after the Effective Date (10.1.1.3.5).

The facts and circumstances that originated the Loss Event may have occurred in the past for a maximum period of up to twenty-four (24) months before the date representing the later of (a) the Effective Date and (b) the date the Beneficiary is first eligible for coverage under this Artifact (the “Retroactivity Period”).

10.1.1.4: Resilience Fund Processes and Principles

Overview of the related processes and principles:

• Application process

• Claim management process

• Caps and Exclusions

• Refund of amounts to the Resilience Fund

10.1.1.4.1: Application Process

10.1.1.4.1.1: Proof of Eligibility (PoE)

To become recognized as a Beneficiary, an Applicant must first select an Ethereum address that is linked to their activity at MakerDAO (“Proof of Eligibility:) Each Beneficiary type will have specific Proofs of Eligibility that are suitable for their role.

Valid PoE:

• Address set as owner and used to sign transactions from MakerDAO multisigs, such as Core Unit operational wallets, auditor wallets or SPFs (old structure), or a Facilitator multisig (Endgame Structure)

  • PoE valid for former Core Unit Contributors, Core Unit Facilitators, and Scope Facilitators.

• Address that voted directly or through delegation in at least ten governance polls or executive votes.

  • PoE valid for active MKR holders, former Recognized Delegates (Old structure), and Aligned Delegates (Endgame structure)

• Address that received compensation from MakerDAO, with the following conditions:

  • at least six payouts spread over at least six months in DAI OR

  • DAI DssVest stream spanning at least six months OR

  • 3 MKR payouts spread over at least three months OR

  • MKR DssVest stream spanning at least three months

  • PoE valid for former Core Unit Contributors and Facilitators

• Address that holds >1 MKR

  • PoE valid for AVC members

• Attestation

  • If no PoE is available, a verified Beneficiary must attest eligibility on behalf of the applicant.

  • This PoE will be used exceptionally if no other Proof is available and will be assessed individually by the Resilience Fund Technical Committee.

10.1.1.4.1.1T Applications for the RF must follow this template:

• .x: [Application RF]

• .x.1: [PoE]

• .x.2: [Active Period]

• .x.3: [Relevant Executive Proposal: Governance decision ratified by a governance vote]

• .x4: [ Signature hash]

The application form template will be integrated into the DAO Toolkit’s user-friendly frontend.

10.1.1.4.1.2: Digital Signature

The Applicant must sign additionally an application message from the Ethereum Address (Digital Signature) used as PoE (10.1.1.4.1.1)

10.1.1.4.1.3: Terms and Conditions

By signing this message, the Applicant accepts and agrees:

• To comply with the terms and rules of SUP 10 (the “SUP 10 Terms”).

• That participation in the program is opt-in and voluntary and can be waived anytime by the Beneficiary.

• That SUP 10 Terms can be amended at any time through the established governance processes.

• That being registered as Beneficiary does not give rise to any right, benefit, entitlement, or claim, nor creates an obligation on any party to pay the Beneficiary.

Additionally, the Beneficiary declares that:

• No situation currently involves or appears to involve a conflict of interest, and any emerging potential conflict of interest shall be disclosed as soon as it happens.

• Any role change in MakerDAO or termination of active engagement will be immediately communicated to the Resilience Technical Committee.

The Resilience Technical Committee will elaborate a user-friendly onboarding manual for the RF.

10.1.1.4.1.4

The Applicant will additionally send an encrypted message to the Resilience Technical Committee Member in charge of the onboarding process to confirm the application.

10.1.1.4.1.5: Approval Process and Verifiability

PoEs rely on a governance decision that was ratified by an executive vote.

The Resilience Technical Committee Member must identify this governance decision by verifying the spell that enacted the executive vote ratifying the respective governance decision. This spell contains the hash of the respective executive vote. Exceptional circumstances where no direct governance decision is available or difficult to assert will be handled case by case.

The Resilience Technical Committee Member will confirm the onboarding decision via an encrypted message to the Applicant.

10.1.1.4.2: Claim Management Process

Overview of the claim management processes:

• Legal Counsel Pre-approval

• Claim approval / Advance Payment

• Reimbursement

10.1.1.4.2.1: Legal Counsel and Quote Pre-approval

The first step in the claim management process is to approve the Legal Counsel to undertake legal defense or 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 request must indicate at least the following:

• Name of Legal Counsel

• Name of Law Firm

• If not in the Lawyer Registry, Proof of Eligibility

• Quote

• 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 fixed fee OR monthly retainer fee

10.1.1.4.2.1.1

If the Legal Counsel is RF-qualified in the Lawyer Registry (10.1.2), the claim is automatically submitted to the Claim Approval process (10.1.1.4.2.2).

10.1.1.4.2.1.2

If Legal Counsel is NOT RF-qualified in the Lawyer Registry (10.1.2), then the Support Facilitators or alternatively the Resilience Fund Technical Committee Member verify if the Legal Counsel complies with requisites in 10.1.2.1 (Lawyer Registry Acceptance Criteria) and 10.1.2.2 (LR Resilience Fund Acceptance Criteria).

If the Legal Counsel of the quote is determined by the Resilience Technical Committee to comply with the requirements of this Artefact, the quote is pre-approved and the legal counsel is added to the LR.

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.1.1.4.2.2: Claim Approval

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

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

• The Payout Reimbursement Claim must contain the 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.1.1.4.2.2.2

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

10.1.1.4.2.2.3

The Support Facilitators will review the Payout Claim and if it contains all required elements and supportive documentation, will immediately transmit it to the Resilience Fund Technical Committee (10.1.1.2).

10.1.1.4.2.2.4

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

• Absence of Exclusions

• Identity and Role of Beneficiary

• Time scope

• Authenticity of writ/lawsuit

• Reasonability of lawyer fees, which must take into account market rates in the respective jurisdiction

10.1.1.4.2.2.5

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 made in their sole and absolute discretion, are definitive, and are not subject to appeal.

10.1.1.4.2.2.6 Quorum and Decision Majorities

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

10.1.1.4.2.2.7

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

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

10.1.1.4.2.3: Payout / Reimbursement

If the governance poll for paying out a claim is successful, an executive vote must be created and approved through MakerDAO governance processes 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.1.1.4.3: Caps and Exclusions

Unless otherwise approved by a governance vote of MakerDAO, claim funds approved under this Artifact:

10.1.1.4.3.1

Will be subject to an aggregate cap for all claims in relation to a Claim Event determined by the risk models elaborated by the Resilience Technical Committee.

10.1.1.4.3.2

Can only be used to reimburse Beneficiaries for their and disbursements directly arising from a Claim Event, and reasonable legal expenses. “Reasonable legal expense” is a variable amount that will be determined taking into account the average market rates of the respective jurisdiction.

10.1.1.4.3.3

Must not be used to reimburse the payment of government or regulatory fines or damages awarded by the court.

10.1.1.4.4: Refund of Amounts to the Resilience Fund

10.1.1.4.4.1

Where Beneficiaries receive financial benefit or reimbursement of any type as a result of orders of a court, governmental or investigative body or regulatory agency that results in a windfall to the Beneficiary, these windfall amounts will be returned by the Beneficiary to the Resilience Fund within 14 days of receipt.

10.1.1.4.4.2

By way of example only and without limiting the generality of the principle described in 10.1.1.4.4.1, such amounts include, without limitation:

• Amounts awarded by a court towards the Beneficiary’s legal fees or disbursements;

• An award of damages to a Beneficiary in relation to a Claim Event;

• Monies or digital assets located by police or other investigative bodies that were identified as the property of MakerDAO; and

• Interest payable to a Beneficiary in relation to a Claim Event.

10.1.1.4.5: Litigation/Defense Management

Beneficiaries and their legal teams must, in the conduct of the litigation and as a condition of receiving reimbursement from the Resilience Fund:

10.1.1.4.5.1

Act honestly, consistently, and fairly in handling claims and litigation;

10.1.1.4.5.2

Make an early assessment of the prospects of success and deal with claims promptly;

10.1.1.4.5.3

Keep costs to a minimum and avoid reliance on technical defenses which have low probability of success; and

10.1.1.4.5.4

Consider alternative dispute resolution (ADR) options at all times.

10.1.2: The Lawyer Registry (LR)

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

Lawyers covering at least the following areas will be onboarded in the Lawyer Registry:

Category	Areas of Law	Examples
Disputes/Investigations	Regulatory Enforcement – Securities/Finance Law	SEC/FinCEN/CFTC/Central Bank matters
Tax authority actions
OFAC Orders, Sanctions
	Securities Law Disputes (private party claims, class actions etc)	MKR investor claims

Lawsuits against Maker CORE actors| ||Intellectual Property|Patent Claims/Trolls Trademark Claims/Trolls| ||General Litigation – Any other Party-Party Disputes|Disputes between Maker DAO and 3rd party suppliers Breach of contract disputes Employment law disputes Disputes between Maker DAO and Ecosystem actors| |Commercial Matters (non-litigious)|Commercial and Contracts|Commercial transactions (Audits, listing agreements, inter Sub-DAO agreements affecting Maker Core etc.) Contracts and Procurement (includes contract management) Competition/Anti-Trust Law Data protection and Privacy Insurance Law| ||Intellectual Property, Information Technology|IT procurement, licenses, and contracts Convergent technologies Intellectual property rights Data protection and privacy Trademark/Patent applications| ||Corporate Structuring, Entity Formation/Reporting, Corporate Financing and Tax|Entity formation assistance provided to Maker Core. Annual Reporting/Filings Company Law Corporate Finance Tax Law|

10.1.2.1: Lawyer Registry Acceptance Criteria

To be included in the Lawyer Registry, lawyers must satisfy the requirements described in the following subelements.

10.1.2.1.1

Licensed legal professionals in their respective jurisdiction.

10.1.2.1.2

Proven experience with MakerDAO, crypto, or emerging technologies.

10.1.2.1.3

No Conflict of Interest in the matter over which they have carriage.

10.1.2.1.4

Lawyers must have internal processes to conduct conflict checks prior to any engagement under this Artefact.

10.1.2.1.5

Where conflicts arise within the lawyer’s firm, the firm must:

1. In the case where a Beneficiary is handling the claim, cease all further work and immediately notify the Resilience Technical Committee in writing and cooperate with the Resilience Technical Committee to avoid a continuing conflict or, where this is not practicable, transferring the matter to another LR registered Lawyer, and

2. In the case where the Guardian is handling the claim, cease all further work and immediately notify the Guardian in writing and cooperate with the Guardian to avoid a continuing conflict or, where this is not practicable, transfer the matter to another LR registered Lawyer.

---

10.1.2.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.1.2.2.1

Lead Counsel, lead Barristers, and lead Trial Attorneys, (as applicable) to each have ten years of relevant legal experience, including demonstrable experience in the relevant area of law, type of process and jurisdiction in which they have been included on the Lawyer Registry.

10.1.2.2.2

In relation to lawyers included on the Lawyer Registry for litigious categories, they have been Lead Counsel in at least 15 cases in the relevant area of law, type of process, and jurisdiction for which they are listed or, in relation to non-litigious matters, having demonstrable experience in the relevant area of law, type of process and jurisdiction indicated in the table set out under 10.1.2.

---

10.1.2.2.3T: 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.1.2.3

The current approved legal counsels in the LR are recorded in 10.1.2.3A. The Resilience Technical Committee will verify the eligibility criteria of new candidates and submit a list of approved candidates to the Support Facilitator, who can directly edit the Active Element to include new legal counsel

10.1.2.3A

¤¤¤

List of active legal counsel in the Lawyer Registry:

¤¤¤

10.1.3: Legal Defense Standard Operational Processes

This section defines the Standard Operational Processes (SOPs) for reacting against legal or regulatory actions against a participant of the Maker ecosystem or against an unincorporated DAO.

10.1.4: The Guardian

The Guardian is a specialized Ecosystem Actor that will be exclusively mandated to retain and instruct counsel to assist with the legal defense of actors in the Maker ecosystem that, due to their organizational structure or circumstances, may be unable to obtain legal representation when pursuing or defending claims against adversarial parties.

10.2 : Legal Risk Management

This section defines the framework for managing, retaining, transferring, and structuring legal risk through instruments such as self-insurance and insurance.

10.2.1 Legal Risk Management Bodies

10.2.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 risk coverage for participants of the Maker Ecosystem, DAOs, and SubDAOs.

The object of the Policyholder is to

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

• Act as a 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

  • Managers, Directors, and other executive staff of the legal vehicle. The 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.1A). This is intended to move later to a separate budget.

10.2.1.2: Policyholder management

This section handles the logic of adding and removing Policyholders.

MKR holders must previously approve the structure and costs of the Policyholder based on a governance poll by MKR voters that the Facilitators initiate if they deem it necessary. The active state of current approved Policyholders is maintained in 10.2.1.3A.

10.2.1.3A

¤¤¤

List of current active Policyholders:

¤¤¤

10.3 Privacy and Operational Security

This section will define the policies for operational security, privacy, and pseudonymity to be implemented in the DAO toolkit (SUP 3). The general purpose of this framework is to maximize security and safety for contributors and users and minimize potential attack vectors for the Ecosystem.

10.4 Advocacy and Public Policy

This section will define the framework and processes for public policy, advocacy, and governmental relations, The general purpose of this framework is to develop innovative regulatory frameworks and standards that protect open source resources and position the Public Good Purpose of the Maker ecosystem.

10.5 Legal and Regulatory Risk Monitoring

This section will define the general framework and standard processes for monitoring and assessing risk and implementing responses. Risk assessment will include external/jurisdictional risk monitoring and internal risk monitoring.

Responses will be structured as Standard Operational Protocols (SOPs). The categories of Legal and Regulatory Risk Monitoring responses are:

• Preventive responses that reduce the likelihood of occurrence of a risk event

• Reactive responses that reduce the severity of consequences if the risk event materializes.

• Emergency Responses and Contingency Plans.

10.6 Public Procurement Framework

This section will define a Public Procurement Framework for contributors and actors involved in the Maker Ecosystem. The purpose is to develop a standard framework that rules the entire lifecycle of service providers, which includes the following processes:

• Application process

• Selection process (Scoring / evaluating proposals or applications)

• Hiring and payment process

• Performance evaluation and reporting

• Terminating involvement and resolving disputes

10.7 Atlas Amendment and Audit

This section will define the standard processes for amending the nonimmutable provisions of the Atlas and ex-performing post legal and technical audit. The general purpose of these processes is to ensure internal consistency and alignment of new provisions and to police the integrity of the Atlas.

10.8 Technical and Legal Standards

This section will define the required techno-legal standards and tools such as, but not limited to, legal agreements (SUP 9), templates, and legal structures required to perform specific functions or roles in the Maker Ecosystem. The general purpose of this framework is to minimize trust assumptions and dependencies on specific actors, minimize personal exposure, and increase the accountability and predictability in their behavior.

11: Legal resilience research and preparedness

The Support Facilitators must ensure that resilience research and preparedness work is covered continuously to ensure the ecosystem is well-positioned to deal with any legal uncertainty or risk that should arise. These projects 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.

¤¤¤

11.2 Resilience Research Objectives

Resilience research and preparedness projects must fulfill at least one of the following objectives:

• Bootstrap necessary infrastructure to develop one of the high-order legal resilience objectives as defined in SUP 10.1 - 10.8:

  • Legal Defense

  • Legal Risk Management

  • Privacy and Operational Security

  • Advocacy and Public Policy

  • Legal and Regulatory Risk Monitoring

  • Public Procurement Framework

  • Atlas Amendment and Audit

  • Technical and Legal Standards

• Design and implement processes that contribute directly to one of the high-order legal resilience objectives defined in SUP 10.1 - 10.8.

• Implement specific preventive or reactive legal risk mitigation tools.

• Execute specific activities or tasks necessary to fulfill one of the high-order legal resilience objectives defined in SUP 10.1 - 10.8.

1.3: Application Process

Ecosystem Actors can apply for a Resilience Research Project by submitting a proposal to be processed by the Support Scope. To submit a Resilience Research Proposal, the Ecosystem Actor must make a post on the Maker Forum following the template provided in 11.3T and comply with all requirements described in this section.

11.3.1

Resilience Research Proposals must clearly detail their direct and indirect costs and the results and benefits concerning the Resilience Research Objectives.

11.3.2

Resilience Research Proposals must detail their headcount, team skill set composition, and reliance on third parties.

11.3.3

Resilience Research Proposals must provide a clear timeline with detailed, granular milestones and the KPIs to review at each milestone.

11.3.4

Resilience Research Proposals must justify how the project will mitigate a specific risk or help bootstrap resources necessary to improve legal resilience.

11.4T: Application Template

Applications for Resilience Research projects must follow this template:

• .x: [Project Name]

• .x.1: [Project Abstract: In 3-5 sentences, what problem are you trying to solve?]

• .x.2: [Objectives: What are you hoping to accomplish? How do you define and measure success for this project?]

• .x.3: [Outcomes: How does this project benefit the Maker ecosystem? How does this project help fulfill one of the Legal Resilience Objectives in SUP 10.1-.10.8?]

• .x.4: [Scope: What will you research/build /design/implement? What is the expected output?]

• .x.5: [Project Team: How many people are working on this project? Please list their names and roles for the project and how many hours per month each person will work on this project?]

• .x.6: [Background: Relevant links, reference to other projects or research papers]

• .x.7: [Methodology: How do you plan to achieve your objectives?]

• .x.8: [Timeline: Please include a brief explanation of the milestones/roadmap, along with expected deliverables and KPIs. Also, outline how the funds will be used for the project and or members of the team.]

• .x.9: [Budget: Requested grant amount and how this will be used. Please provide the requested amount and outline of how the funds will be used.]

---

11.5: Resilience Research Proposals Review Process

The Support Facilitators must use the Resilience Research budget to ensure the highest quality Research Proposals are thoroughly reviewed, with the final review published in the Maker Forum before the Support Facilitators decide to fund a proposal or trigger a governance vote to fund a proposal.

11.5.1

Proposals should only be reviewed if there is an available budget in the Legal Research budget.

11.5.2

Multiple factors should be considered holistically when reviewing Resilience Research Proposals, including the amount of remaining budget, the potential impact on the Resilience Research Objectives, and, whether the Resilience Research Proposals help improve legal resilience as described in SUP 10.

11.5.3: De Minimus Rule

Resilience Research Projects with a total cost under 15k DAI, can be directly approved by the Support Facilitator. Projects with a total cost above 15k will require a governance vote on the weekly cycle that can be triggered by the Support Facilitator.

11.6A: Active Resilience Research Projects

¤¤¤

List of current active resilience research projects:

¤¤¤

12: Purpose System

13: Ecosystem Security Infrastructure

13.1: Bug Bounty Program for MakerDAO Critical Infrastructure

This section specifies the budget and processes of a bug bounty program, which serves to protect the Maker Protocol and its users from hacks and exploits. The MakerDAO Bug Bounty Program is conducted on the Immunefi platform.

13.1.1: Introduction

As one of the most important DeFi protocols with a high TVL, the Maker Protocol is a honeypot for hackers and other nefarious actors. Due to this fact, the Maker Protocol should always be covered under an active bug bounty program. The program aims to create incentives for hackers to contribute to the resilience of the Maker Protocol as opposed to exploiting vulnerabilties for personal gain. The setup and operations of the bug bounty program is based on the standard set by Immunefi, which is the party responsible for conducting the bug bounty program.

Besides a bug bounty program for the Maker Protocol, another bug bounty program should be maintained for SparkLend until the launch of the Spark SubDAO.

13.1.2: Scope

13.1.2.1: Assets to be Covered

The assets considered as in-scope of the bug bounty program will be those that are identified as critical infrastructure to the Maker ecosystem. The scope of assets accepted for this Bug Bounty Program is specified on the MakerDAO listing of the Immunefi platform, which can be found here. Assets in scope include smart contracts and frontend applications, data infrastructure and oracles.

For SparkLend, the scope of assets for the Bug Bounty Program is specified on the Spark Lend listing of the Immunefi platform, which can be found here. For SparkLend the scope only includes smart contracts. The scope Facilitator is responsible for coordinating with the relevant stakeholders to define and maintain this list of assets.

13.1.2.2: Severity Classification

The Immunefi Vulnerability Severity Classification System is used for both bug bounty programs. A specification of this system can be found here.

13.1.2.3: Impacts in Scope

The scope of impacts accepted for this Bug Bounty Program is specified on the MakerDAO listing of the Immunefi platform, which can be found here. The impacts are categorized into 'smart contract' and 'websites and applications.'

For SparkLend, the scope of impacts for the Bug Bounty Program is specified on the Spark Lend listing of the Immunefi platform, which can be found here.

The scope Facilitator is mandated to choose a new severity system if it deems it to be better for the bug bounty program, based on consulting the relevant technical stakeholders.

13.1.2.4: Out of Scope and Rules

A selection of vulnerabilities are deemed out of scope for the bug bounty program. An overview of these out of scope vulnerabilities can be found on the MakerDAO listing of the Immunefi platform, which can be found here. Feasibility limitations also apply, which can be found in the aforementioned listing on the Immunefu platform website. Certain rules apply to the bug bounty program. These can be found on the aforementioned MakerDAO listing of the Immunefi platform, listed under the following categories:

• Repeatable attack limitations

• Restrictions on security researcher eligibility

• Public disclosure of known issues

• Proof of Concept (PoC) requirements

• Other terms and information

• Prohibited activities

For SparkLend, the rules, terms and exceptions can be found on the Spark Lend listing of the Immunefi platform, which can be found here.

13.1.3: Rewards

13.1.3.1: Rewards per Threat Level

13.1.3.1.1: Smart contract vulnerabilities

The Rewards per Threat Level, including related terms, conditions and exceptions are specified in the MakerDAO listing of the Immunefi platform, which can be found here. For SparkLend, Rewards per Threat Level, including related terms, conditions and exceptions are specified on the Spark Lend listing of the Immunefi platform, which can be found here.

13.1.3.1.2 :Websites and Applications Vulnerabilities

The Rewards per Threat Level, including related terms, conditions and exceptions are specified in the MakerDAO listing of the Immunefi platform, which can be found here.

13.1.3.1.3: Reward Payment Terms

13.1.3.1.3.1: Reward Denomination

Payments are denominated in USD. However, payouts are done in DAI assuming a full 1:1 ratio with the USD. However, if the price of DAI deviates from the USD value by more than 1%, the amount of DAI will be adjusted.

13.1.3.1.3.2: Payout Process

All bounty payouts are handled by MakerDAO governance. Upon confirmation, bug bounty payouts should be included in the next possible 'executive spell', which is a governance vote with an onchain payload attached to it. This would involve sending DAI directly from the protocol's buffer to the whitehat hacker.

Immunefi will publicly contact one of the Governance Facilitators with the request, including a specification of the respective vulnerability report, the requested amount and the Ethereum mainnet addresses of the beneficiaries. This should also include the payment details of the Immunefi fee, if it applies. Immunefi and the Maker Governance Facilitators should make sure the payout occurs up to one full calendar month after the report was approved.

For bug bounty rewards over USD 1,000,000, after the first million is paid out, the remaining amount is paid out over time with up to USD 1,000,000 per consecutive month until the determined amount for payout is reached.

13.1.3.1.3.3: Budget

The bug bounty programs incur fixed and variable costs.

• Variable costs: Bug bounty payouts including related fees to Immunefi are considered variable costs and are covered by the process described in the Rewards section above.

• Fixed costs: Fixed costs comprise of service fees for the Immunefi Premium Triaging Service, and compensation of a part-time bug bounty program steward. These costs are funded by the Launch Project budget, as specified in MIP108 section 9.