diff --git a/MIP101/MIP101.md b/MIP101/MIP101.md index a9f31d0b1..f813cc798 100644 --- a/MIP101/MIP101.md +++ b/MIP101/MIP101.md @@ -28,7 +28,7 @@ Organizational alignment is a traditional business concept and can be described Ecosystem Intelligence is a way to look at a decentralized ecosystem as a single entity that acts with a greater or lesser amount of intelligence. Ecosystem Intelligence isn't just determined by the sum of the intelligence of each of its constituent parts, but also of the alignment of them. Counterintuitively, very intelligent, but spiritually misaligned participants in a decentralized ecosystem will actually lower its Ecosystem Intelligence. -### Aligned structure +### Aligned Structure An aligned structure is a network, ecosystem, entity, organization that actively employs alignment engineering. @@ -70,7 +70,7 @@ Imagine a large corporation discovers a loophole in the environmental regulation By exploiting the "letter of the rule," the corporation complies with the regulations on paper but continues to harm the environment and public health in practice. -A universally aligned actor in this situation, such as an environmentally conscious competitor, would interpret the regulations based on their "spirit" or underlying purpose – protecting the environment and public health. Recognizing that exploiting the loophole contradicts the regulations' intent, the universally aligned actor would voluntarily choose not to emit the harmful pollutant, even though doing so might be profitable and technically legal. A universally aligned actor would also actively work with the government and other stakeholders to close the loophole and strengthen the regulations to ensure that they effectively serve their intended purpose, and to protect themselves from misaligned competitors. +A universally aligned actor in this situation, such as an environmentally conscious competitor, would interpret the regulations based on their "spirit" or underlying purpose — protecting the environment and public health. Recognizing that exploiting the loophole contradicts the regulations' intent, the universally aligned actor would voluntarily choose not to emit the harmful pollutant, even though doing so might be profitable and technically legal. A universally aligned actor would also actively work with the government and other stakeholders to close the loophole and strengthen the regulations to ensure that they effectively serve their intended purpose, and to protect themselves from misaligned competitors. ### Incentivized Alignment @@ -88,13 +88,13 @@ Understanding Slippery Slope Misalignment means understanding that any misalignm ### Scope -Scope is a particular focus area of Maker or a SubDAO. There are 5 scopes: +Scope is a particular focus area of Maker or a SubDAO. There are five scopes: - **Stability**, focusing on financial stability and the core Dai stablecoin product - **Accessibility**, focusing on frontends and distribution -- **Protocol**, focusing on technical development, maintenance and security +- **Protocol**, focusing on technical development, maintenance, and security - **Support**, focusing on ecosystem support, tools and activities -- **Governance**, focusing on Alignment Artifact interpretation and balance of powers. +- **Governance**, focusing on Alignment Artifact interpretation and balance of powers ### Alignment Artifact @@ -229,7 +229,7 @@ The final technical and Alignment Engineering state of MakerDAO where all aspect ### Easy Governance Frontend -The Easy Governance Frontend is a standardized decentralized frontend for participating in MakerDAO governance that all SubDAOs must make available for MKR holders to access. It is the standard way to access the Governance Participation Incentives defined in the Maker Atlas. +The EGF is a standardized decentralized frontend for participating in MakerDAO governance that all SubDAOs must make available for MKR holders to access. It is the standard way to access the Governance Participation Incentives defined in the Maker Atlas. ### Governance Participation Incentives @@ -237,7 +237,7 @@ The Governance Participation Incentives are a set of rewards available to users ### Lockstaking -Lockstaking is a form of governance participation used by the governance tokens in the Maker Ecosystem. When a user Lockstakes, they immediately begin to earn significant rewards, but must pay an exit fee to access their governance tokens again. This makes it a lot more beneficial to lockstake if the user expects to remain in the system for a long term. Because there's a penalty for exiting, Lockstaking helps generate additional skin in the game and makes incentivized alignment more long term aligned. +Lockstaking is a form of governance participation used by the governance tokens in the Maker Ecosystem. When a user Lockstakes, they immediately begin to earn significant rewards, but must pay an exit fee to access their governance tokens again. This makes it a lot more beneficial to lockstake if the user expects to remain in the system for a long term. Because there's a penalty for exiting, Lockstaking helps generate additional skin in the game and makes incentivized alignment more long-term aligned. ### Farming @@ -259,7 +259,7 @@ The incentives that an actor can estimate through the letter of the rules interp Incentive Slack means that there's a gap between the explicit incentives and the implicit incentives in an Aligned Structure. Incentive Slack can occur if coded rules aren’t enforced, or if they are made to be overly restrictive or unworkable, and thus necessarily setting precedence of bypassing the rules. High Incentive Slack creates a perception that rules are likely to be ignored generally, without regards for the spirit of the rules. Incentive Slack means significant risk of widespread misalignment because it cannot occur if the aligned structure contains universally aligned actors enforcing the rules. -### Whole weeks +### Whole Weeks The Alignment Artifacts defines quarterly and yearly cycles that determine fixed points in time by counting whole weeks from the beginning of a quarter. The first whole week of a quarter is defined as the first week that contains all of its days, starting with Monday, inside the quarter. Another definition would be “the week starting with the first Monday of the quarter”. @@ -293,13 +293,21 @@ The information contained in the Atlas is the most important for determining the GOV2 contains the structure for Maker Governance to scrutinize and disambiguate the elements and other contents of the Atlas Immutable Alignment Artifact and define the effects and consequences in practical situations. -#### 2.2.1: The principles for when Atlas interpretation is necessary, and how it is initiated. +#### 2.2.1 -##### 2.2.1.1: This must cover the delineation between when Atlas interpretation can be used to cover shortfalls or gaps in the Atlas that are congruent with the spirit of the Atlas, and when interpretations are reaching too far and are going against the spirit of the Atlas and as a result, are misaligned. +The principles for when Atlas interpretation is necessary, and how it is initiated. -#### 2.2.2: Principles and processes that must be followed when deliberating and deciding on Atlas interpretations. +##### 2.2.1.1 -#### 2.2.3: List of all settled Atlas interpretations with all necessary context. +This must cover the delineation between when Atlas interpretation can be used to cover shortfalls or gaps in the Atlas that are congruent with the spirit of the Atlas, and when interpretations are reaching too far and are going against the spirit of the Atlas and as a result, are misaligned. + +#### 2.2.2 + +Principles and processes that must be followed when deliberating and deciding on Atlas interpretations. + +#### 2.2.3 + +List of all settled Atlas interpretations with all necessary context. ### 2.3: Scope Bounded Mutable Alignment Artifacts - GOV3 @@ -313,23 +321,21 @@ Scope Artifacts are continuously updated on a quarterly basis through the AVC pr GOV3 must cover a ruleset for ossification of mutable elements, ensuring that significant changes to the Scopes take a long time and provide a lot of time for input. -#### 2.3.3 +#### 2.3.3: Types of Scope Elements -There are multiple types of Scope elements: - -##### 2.3.3.1 +##### 2.3.3.1: Strengthening Elements Strengthening Elements are regular elements that ossify over time and are meant to eventually never change as they reach a sufficient strength that the Letter of the Rules remain Universally Aligned. Every update to a Strengthening Element must make it stronger, more future proof and long term focused, and less likely to be changed in the future. -##### 2.3.3.2 +##### 2.3.3.2: Active Elements Active Elements are mutable elements that need to change as a part of the normal operations of Governance. An example are lists of active state or parameters. The rules for changing an Active Element are codified in adjacent Strengthening Elements. -##### 2.3.3.3 +##### 2.3.3.3: Budget Elements Budget Elements are elements that contain budgets and that can trigger valid executive votes for deploying smart contracts that can perform payments controlled by FacilitatorDAOs. -##### 2.3.3.4 +##### 2.3.3.4: Template Elements Template Elements are elements that specify templates used for other elements. Template Elements don’t have to follow the regular Alignment Artifact formatting standards for its subelements. @@ -351,7 +357,11 @@ Alignment Conservers are external entities that play a fundamental role in facil #### 2.4.1: Roles of the Alignment Conservers -Alignment Conservers can have 4 critical roles: Aligned Voter Committee Members, Aligned Delegate, Facilitator and Budget Allocator. +Alignment Conservers can have four critical roles: +- Aligned Voter Committee Member +- Aligned Delegate +- Facilitator +- Budget Allocator. ##### 2.4.1.1 @@ -391,11 +401,13 @@ AVCs are standardized Voter Committees made up of Alignment Conservers that hold AVCs focus on making sure that the day-to-day Letter of the Rules of the scopes are aligned with the spirit of rules and Universal Alignment. The AVCs impact on Maker Governance is to make marginal improvements to the Alignment Artifacts that strengthen them. As AVCs make detailed Universal Alignment interpretations, they must all follow a particular Strategic Perspective that informs their subjective definition of Universal Alignment. -#### 2.5.1: Aligned Voter Committee (AVC) Role in the Governance process +#### 2.5.1: Aligned Voter Committee (AVC) Role in the Governance Process AVCs are the actors in the broader aligned structure that have the most direct alignment with MKR holders, and thus Dai holders and the broader key stakeholders of the ecosystem. This makes AVCs able to act as an important check on the governance process by monitoring the Spiritual Alignment of the Aligned Structure, and identify and act to deal with inner alignment deviations between Universal Alignment and Incentivized Alignment. -##### 2.5.1.1: AVCs act through proposing modifications to the Scope Artifacts +##### 2.5.1.1 + +AVCs act through proposing modifications to the Scope Artifacts. This gives them the most impactful input on how to correct alignment gap or incentive slack issues in the Alignment Artifacts, by modifying the Scope elements to ensure incentivized alignment maps as closely as possible to Universal Alignment. @@ -409,7 +421,7 @@ As a general rule, AVCs are restricted from being prescriptive and self-justifyi ###### 2.5.1.2.1 -There must always be clear justification for all Alignment Artifact strengthening proposed by AVCs, ensuring that the processes and mechanisms they put in place are Universally Aligned, open, neutral, fair and long term beneficial to MakerDAO. +There must always be clear justification for all Alignment Artifact strengthening proposed by AVCs, ensuring that the processes and mechanisms they put in place are Universally Aligned, open, neutral, fair, and long-term beneficial to MakerDAO. ###### 2.5.1.2.2 @@ -504,7 +516,7 @@ AVCs must vote according to their strategic perspective. Clearly voting against ##### 2.5.7.1 -- A key objective of AVCs is to act as reliable, aligned sources of opinions about which decisions are in MKR holders’ interest, given a particular strategic perspective of Maker Governance. This allows them to enfranchise MKR voters that are participating through the EGF to earn governance participation incentives. +A key objective of AVCs is to act as reliable, aligned sources of opinions about which decisions are in MKR holders’ interest, given a particular strategic perspective of Maker Governance. This allows them to enfranchise MKR voters that are participating through the EGF to earn governance participation incentives. #### 2.5.8 @@ -512,13 +524,13 @@ AVCs must limit their participation in Maker Governance to the creation of Align ##### 2.5.8.1 -*Any attempt by AVCs to micromanage governance significantly increases the risk of misalignment as there could easily be a hidden conflict of interest behind the attempt at micromanagement. +Any attempt by AVCs to micromanage governance significantly increases the risk of misalignment as there could easily be a hidden conflict of interest behind the attempt at micromanagement. #### 2.5.9: Aligned Voter Committee Support and Infrastructure A AVC receives support and infrastructure from the Support Scope, specified in SUP2 -#### 2.5.10: AVC Member participation rewards +#### 2.5.10: AVC Member Participation Rewards AVC Members that participate in an AVC can be eligible for AVC Member participation reward that recognizes the time they are spending to support Maker Governance. @@ -590,7 +602,7 @@ GSLs are Seasonally Active in the same way as normal PDMs, and this determines w An AD PDM also has a Neutral GSL, which is a special GSL that is not linked to any AVC, but that the AD must instead use to vote for a balanced strategy that achieves the mean of the positions of all AVCs and is Universally Aligned. -#### 2.6.3: Aligned Delegate (AD) Income and Participation Requirements +#### 2.6.3: Aligned Delegate Income and Participation Requirements ADs are eligible to receive significant income from the Maker Protocol if they are among the top ADs based on total votes delegated to their Seasonally Active GSLs, and they fulfill specific participation requirements. There are two income levels for ADs: Prime Delegates (PDs) that receive the highest level of income and have a degree of income security, and Reserve Aligned Delegates (RDs) that receive a lower level of income. @@ -684,9 +696,13 @@ If FacilitatorDAOs fail to take action against misaligned ADs, they must be seve ADs must maintain a high level of operational security, and follow best practice for privacy, security and physical resilience. This must be done at a level that adequately protects the Maker Ecosystem from physical risk posed by the potential for attacks against ADs. If there’s clear evidence or significant suspicion that the operational security of an AD has been compromised, or that they have failed to follow best practice or otherwise made operational security errors, FacilitatorDAOs must immediately derecognize the AD. Half of the AD Buffer can be confiscated and used as a whistleblower bounty in case an ecosystem actor responsibly provided useful information for determining that the operational security of an AD was compromised. GOV6 must specify sufficient safety mechanisms around the payment of the whistleblower bounty. -2.6.6.1: FacilitatorDAOs must err on the side of caution and act in case there is any kind of real possibility that the operational security of an AD is compromised. They are afforded a significant autonomy in making judgement calls related to operational security standards for ADs, but if there is clear indications that they are abusing this power for misaligned ends, then the FacilitatorDAO must be penalized for open misalignment. +##### 2.6.6.1 + +FacilitatorDAOs must err on the side of caution and act in case there is any kind of real possibility that the operational security of an AD is compromised. They are afforded a significant autonomy in making judgement calls related to operational security standards for ADs, but if there is clear indications that they are abusing this power for misaligned ends, then the FacilitatorDAO must be penalized for open misalignment. -2.6.6.1.1: All FacilitatorDAOs must immediately either support the action or propose overturning it and penalizing the FacilitatorDAO when an operational security breach derecognition is initiated. Failing to act is itself misalignment and results in penalties for all the FacilitatorDAOs that failed to act. +###### 2.6.6.1.1 + +All FacilitatorDAOs must immediately either support the action or propose overturning it and penalizing the FacilitatorDAO when an operational security breach derecognition is initiated. Failing to act is itself misalignment and results in penalties for all the FacilitatorDAOs that failed to act. #### 2.6.7: Aligned Delegate Charity @@ -704,7 +720,9 @@ When a FacilitatorDAO has responsibility for an Alignment Artifact, they are ful The Governance Scope must specify a process used by Maker Governance to assign responsibility of a particular MakerDAO Alignment Artifact to a particular FacilitatorDAO. A process must be in place to enable FacilitatorDAOs to request responsibility of a MakerDAO Alignment Artifact, and in ordinary times Maker Governance should only assign responsibility of a Scope based on a request by the FacilitatorDAO. -##### 2.7.2.1: All FacilitatorDAOs always have responsibility for the Governance Scope. +##### 2.7.2.1 + +All FacilitatorDAOs always have responsibility for the Governance Scope. ##### 2.7.2.2 @@ -736,7 +754,9 @@ A total of 150 million NewGovToken are distributed to all FacilitatorDAOs per ye 60 million goes to responsibility for MakerDAO Scopes -###### 2.7.4.1.1: 20 million is distributed proportionally to Scope Weight. Scope Weight is as follows: +###### 2.7.4.1.1 + +20 million is distributed proportionally to Scope Weight. Scope Weight is as follows: | Scope | Scope Weight | |---|---:| @@ -747,7 +767,9 @@ A total of 150 million NewGovToken are distributed to all FacilitatorDAOs per ye When multiple FacilitatorDAOs are responsible for the same Scope their Scope Weight is divided between them. -###### 2.7.4.1.2: 20 million NewGovToken is distributed according to Budget Weight +###### 2.7.4.1.2 + +20 million NewGovToken is distributed according to Budget Weight Budget Weight is calculated by determining the relative amount of budget each FacilitatorDAO controls, including both fixed budgets and Allocated Budgets. When multiple FacilitatorDAOs are responsible for the same Scope, the fixed budgets of the Scope are divided between them. @@ -776,18 +798,17 @@ In some cases Budgets will have specified an adjusted weight inside the Budget E 20 million NewGovenToken proportionally for any FacilitatorDAO that is actively Responsible for at least 1 AllocatorDAO Scope, or at least a fraction of total MiniDAO Weight equivalent to one divided by the total amount of SubDAO FacilitatorDAOs. #### 2.7.5: Facilitators - Facilitators are anonymous Alignment Conservers that can be engaged by FacilitatorDAOs to directly access governance processes and smart contracts that the FacilitatorDAOs control, to help ensure the FacilitatorDAO fulfills their responsibility under the Alignment Artifacts. ##### 2.7.5.0 -*Facilitators allow a FacilitatorDAO to scale up its ability to be responsible for multiple Alignment Artifacts, but also create the risk of misaligned Facilitators attacking the system or stealing funds.* +Facilitators allow a FacilitatorDAO to scale up its ability to be responsible for multiple Alignment Artifacts, but also create the risk of misaligned Facilitators attacking the system or stealing funds. ##### 2.7.5.1 The FacilitatorDAOs are responsible for any wrongdoing by their chosen Facilitators, and will be penalized for any theft or abuse of budgets or protocol access. The FacilitatorDAOs have to manage this risk through carefully set, limited permissions and fallback mechanisms that ensure the FacilitatorDAOs cannot take a significant loss in the worst case scenario. -##### 2.7.5.2: Facilitator Operational Security +##### 2.7.5.2 Facilitator Operational Security Facilitators must maintain a high level of operational security, and follow best practice for privacy, security and physical resilience. This must be done at a level that adequately protects the Maker Ecosystem from physical risk posed by the potential for attacks against Facilitators. If there’s clear evidence or significant suspicion that the operational security of a Facilitator has been compromised, or that they have failed to follow best practice or otherwise made operational security errors, FacilitatorDAOs must immediately derecognize the Facilitator. The FacilitatorDAO that chose a Facilitator that is found to have inadequate operational security must be penalized unless they act immediately to derecognize the Facilitator. @@ -799,7 +820,7 @@ FacilitatorDAOs must err on the side of caution and act in case there is any kin All FacilitatorDAOs must immediately either support the action or propose overturning it and penalizing the FacilitatorDAO when an operational security breach derecognition is initiated. Failing to act is itself misalignment and results in penalties for all the FacilitatorDAOs that failed to act. -#### 2.7.6: Decision making powers of FacilitatorDAOs +#### 2.7.6: Decision-Making powers of FacilitatorDAOs FacilitatorDAOs can make interpretations and take discretionary decisions based on the language of the Alignment Artifacts. *2.2* and *2.3* of The Atlas and GOV2 and GOV3 place significant checks and restrictions on how FacilitatorDAOs can do this. FacilitatorDAOs are not meant to be experts on how to run ordinary business operations, but instead must follow the instructions and make judgment calls based on the language contained in the Scopes. @@ -857,7 +878,7 @@ The Scope Artifact improvements researched and suggested by the Advisory Council Active Ecosystem Actors work according to the specifications of Scope Alignment Artifacts to receive funding for performing specific projects such as developing new features, performing data collection or analysis, performing marketing, growth, outreach or educational activities, legal work, government outreach, and other operational activities that benefit the Maker Ecosystem. Active Ecosystem Actors are the only type of actor that interacts with the Scopes that is allowed to do “real work” that isn’t strictly defined in, and bounded by, the Alignment Artifacts. -### 2.9: Interaction of Aligned Voter Committees (AVCs), Aligned Delegates (ADs), FacilitatorDAOs and Advisory Council - GOV9 +### 2.9: Interaction of Aligned Voter Committees, Aligned Delegates, FacilitatorDAOs, and Advisory Council - GOV9 The interactions between AVCs, ADs and FacilitatorDAOs define how Maker Governance operates from the highest level of informing long term AVC strategic perspectives, to the lowest level of reactively modifying risk parameters or funding individual projects. @@ -889,7 +910,7 @@ It is permitted for AVCs to set participation requirements for PDs and RDs that The threat of a link break may in some situations be an important tool for AVCs being able to keep ADs productive and acting aligned. -#### 2.9.2: Aligned Delegate support for Aligned Voter Committees +#### 2.9.2: Aligned Delegate Support for Aligned Voter Committees Aligned Delegates are expected to provide crucial support to AVCs in the domains where they are the most aligned actors. @@ -957,7 +978,7 @@ FacilitatorDAOs can directly provide advice to AVCs, but this is restricted to o FacilitatorDAOs can also inform AVCs how they believe the implementation of a particular element should be interpreted, and based on this feedback the AVCs can ratify or change their Position Documents in order to ensure that the actual implementation will be as intended. -#### 2.9.4: Prioritization of Self-Sustainable Continuous Improvement based on strong Advisory Council Scopes +#### 2.9.4: Prioritization of Self-Sustainable Continuous Improvement Based on Strong Advisory Council Scopes Unless prevented by an urgent challenge, AVCs should prioritize improving the Scopes towards a state of Self-Sustainable Continuous Improvement based on highly detailed Advisory Council Scopes. This means focusing on a careful and long term-oriented methodology for improving the Scopes, that may initially move slowly, but will automate its own improvement over time and become more resilient to the short term whims of the AVCs. @@ -1017,21 +1038,33 @@ Ensuring that all Scope defined processes are monitored and properly covered. Rules for prioritization of resources in case of scarcity to prevent overload or spam. -### 3.3: DAO Toolkit core development - SUP3 +### 3.3: DAO Toolkit Core Development - SUP3 The DAO Toolkit is a unified system for displaying the Alignment Artifacts and all of the data, processes and interaction necessary for Maker Governance and internal SubDAO governance to function optimally. It is distributed by all AllocatorDAOs and FacilitatorDAOs as a part of their SubDAO Frontend. SUP3 must cover all necessary processes to ensure its underlying technology develops appropriately. -#### 3.3.1 Core development and maintenance management and strategy. +#### 3.3.1 -#### 3.3.2: Identification and development of standardized, common reusable modules. +Core Development and Maintenance Management and Strategy. -#### 3.3.5: Research and specification of best practice for using the DAO Toolkit by Scopes. +#### 3.3.2 -#### 3.3.6: Monitoring of adherence with best practice and flagging to governance in case of issues. +Identification and development of standardized, common reusable modules. -#### 3.3.7: Development of the client side Tookit AI systems for using the DAO Toolkit and interacting with the CAIS. +#### 3.3.5 -#### 3.3.8: Contributor and Alignment Conserver privacy tools and support. +Research and specification of best practice for using the DAO Toolkit by Scopes. + +#### 3.3.6 + +Monitoring of adherence with best practice and flagging to governance in case of issues. + +#### 3.3.7 + +Development of the client side Tookit AI systems for using the DAO Toolkit and interacting with the CAIS. + +#### 3.3.8 + +Contributor and Alignment Conserver privacy tools and support. ### 3.4: Core Artificial Intelligence System (CAIS) - SUP4 @@ -1133,7 +1166,7 @@ SUP9 must cover dispute resolution and the appeals process. SUP10 must cover the Resilience Fund, including relevant definitions and a secure claims process. -### 3.11: Resilience research and preparedness - SUP11 +### 3.11: Resilience Research and Preparedness - SUP11 SUP11 must cover the resilience research and preparedness efforts. @@ -1169,13 +1202,11 @@ The Protocol Scope must have a specialized Advisory Council that is able to prop The Protocol Scope must have a customized strategy towards its display and interaction through the DAO Toolkit to make it maximally user friendly. -### 4.2: NewChain protocol specification, maintenance and upgrades - PRO2 +### 4.2: NewChain Protocol Specification, Maintenance and Upgrades - PRO2 NewChain contains the complete Endgame specification and its deployment causes the Maker Ecosystem to reach the Endgame State. PRO2 must cover the required preparatory and development work to enable Maker Governance to activate NewChain and reach the Endgame State. -#### 4.2.1 - -General blockchain requirements: +#### 4.2.1: General Blockchain Requirements ##### 4.2.1.1 @@ -1205,13 +1236,13 @@ Native ZK rollups built into the protocol. Neural Tokenomics and core governance processes built natively into the NewChain protocol. Specified in more detail in *4.3*. -### 4.3: NewChain native Governance mechanics and neural tokenomics - PRO3 +### 4.3: NewChain Native Governance Mechanics and Neural Tokenomics - PRO3 NewChain implements as native protocol modules all of the internal governance mechanics, incubation mechanics and tokenomics of MakerDAO and SubDAOs. PRO3 must cover the required preparatory and development work relevant for these concepts to enable Maker Governance to activate NewChain and reach the Endgame State. #### 4.3.1 -The Core Pause Proxy of MakerDAO has a governance delay defined by PRO3 and is used to hold external assets and perform forced liquidation or forced actions on SubDAOs. +The Core Pause Proxy of MakerDAO, has a governance delay defined by PRO3 and is used to hold external assets and perform forced liquidation or forced actions on SubDAOs. #### 4.3.2 @@ -1253,17 +1284,19 @@ The Native token standard allows NewGovToken and SubDAO tokens, and other tokens The parameters for extracting NewGovToken and SubDAO tokens from NFTs are 1% of the total embedded supply that can be extracted per day, and users willing to pay the highest penalty are extracted first. -#### 4.3.6: Native NewStable farms for farming NewGovToken and SubDAO tokens. Supports 4 modes of farming: +#### 4.3.6 + +Native NewStable farms for farming NewGovToken and SubDAO tokens. Supports 4 modes of farming: -##### 4.3.6.1: Free token farming +##### 4.3.6.1: Free Token Farming This mode of farming gives the user tokens that are not lockstaked in the relevant lockstaking engine. The amount of tokens farmed are reduced by an amount equivalent to half of the relevant lockstaking exit fee. -##### 4.3.6.2: Free NFT farming +##### 4.3.6.2: Free NFT Farming This mode of farming embeds tokens into the users free NFT that is not lockstaked in the relevant lockstaking engine. The amount of tokens embedded are reduced by an amount equivalent to half of the relevant lockstaking exit fee. -##### 4.3.6.3: Lockstaked token farming +##### 4.3.6.3 Lockstaked Token Farming This mode of farming gives the user tokens that are lockstaked in the tokens native lockstaking engine. @@ -1343,11 +1376,13 @@ When lockstaked, the embedded MiniDAO tokens self-farm additional MiniDAO tokens The MiniDAO Lockstake Engine has an exit fee of 40%, when MiniDAO tokens exit the MiniDAO Lockstake Engine 40% of the tokens are transferred to a yield boost pool that increase the self- farming of the MiniDAO Lockstake Engine by transferring 1% of its contents per day as extra self-farming to the MiniDAO Lockstake Engine users. -#### 4.3.11: NewGovToken emissions +#### 4.3.11: NewGovToken Emissions The Neural Tokenomics emits up to 1 billion NewGovTokens per year to power all of the tokenomics of the Maker Ecosystem. Up to 900 million per year of the NewGovTokens are recaptured, while 100 million per year of the NewGovTokens are for governance upkeep that cannot be recaptured. -##### 4.3.11.1: 900 million NewGovToken emissions that are recaptured +##### 4.3.11.1 + +900 million NewGovToken emissions that are recaptured. Recapturing the value of the emissions means that the emissions directly drive users or income to the protocol in some form. @@ -1371,7 +1406,9 @@ Recapturing the value of the emissions means that the emissions directly drive u 70 million NewGovToken per year accumulate in the Incubators reserve burn engine, and are used to fund the next SubDAO that launches. -##### 4.3.11.2: 100 million Governance upkeep emissions that are not recaptured. +##### 4.3.11.2 + +100 million Governance upkeep emissions that are not recaptured. ###### 4.3.11.2.1: 30 million NewGovToken for Prime Delegates @@ -1393,19 +1430,19 @@ Reserve Delegates receive 10 million NewGovToken per year paid out through the A Aligned Voter Committee Members with the highest number of verified NewGovTokens receive 10 million NewGovToken per year paid out through the AVC Module system. -#### 4.3.12: AllocatorDAO emissions +#### 4.3.12: AllocatorDAO Emissions AllocatorDAOs have a genesis token emission that occurs over the first 10 years of its existence, and an additional permanent emission that continuously occurs forever. -##### 4.3.12.1: AllocatorDAO Farm distribution +##### 4.3.12.1: AllocatorDAO Farm Distribution 70% of all AllocatorDAO tokens emitted for farming are for Dai farming, and 30% of all AllocatorDAO tokens emitted for farming are for Sagittarius Engine users. -##### 4.3.12.2: AllocatorDAO Genesis emissions +##### 4.3.12.2: AllocatorDAO Genesis Emissions The Genesis emissions of Allocators are 2.3 billion tokens over 10 years, with the following breakdown. -###### 4.3.12.2.1: Genesis farming emissions +###### 4.3.12.2.1: Genesis Farming Emissions 2 billion Allocator tokens are for Genesis farming. @@ -1419,54 +1456,55 @@ For the following 2 years, the rate of Genesis farming is 250 million AllocatorD ###### 4.3.12.2.1.3 -For the following 2 years, the rate of Genesis farming is 125 million AllocatorDAO tokens per year. +For the following 2years, the rate of Genesis farming is 125 million AllocatorDAO tokens per year. ###### 4.3.12.2.1.4 For the final 4 years, the rate of Genesis farming is 62.5 million AllocatorDAO tokens per year. -###### 4.3.12.2.2: The workforce bonus pool starts with 300 million AllocatorDAO tokens. The Workforce bonus pool can be further topped up through the permanent emissions +###### 4.3.12.2.2 + +The workforce bonus pool starts with 300 million AllocatorDAO tokens. The Workforce bonus pool can be further topped up through the permanent emissions. -##### 4.3.12.3: AllocatorDAO permanent emissions +##### 4.3.12.3: AllocatorDAO Permanent Emissions The permanent emissions of AllocatorDAOs are a total of 10% tokens emitted per year. -###### 4.3.12.3.1: Permanent MiniDAO Axon emissions +###### 4.3.12.3.1: Permanent MiniDAO Axon Emissions 5% of the total supply is emitted per year for the MiniDAO Axon. -###### 4.3.12.3.2: Permanent farming emissions +###### 4.3.12.3.2: Permanent Farming Emissions 3.75% of the total supply is emitted per year as farming emissions -###### 4.3.12.3.3: Permanent workforce bonus pool emissions +###### 4.3.12.3.3: Permanent Workforce Bonus Pool Emissions 1% of the total supply is emitted per year as workforce bonus pool emissions, if the workforce bonus pool contains less than 5% of the total supply of AllocatorDAO tokens. -###### 4.3.12.3.4: Permanent purpose system emissions +###### 4.3.12.3.4: Permanent Purpose System Emissions 0.25% of the total supply is emitted per year for the Purpose System. -#### 4.3.13: FacilitatorDAO emissions +#### 4.3.13: FacilitatorDAO Emissions FacilitatorDAOs have a genesis token emission that occurs over the first 10 years of its existence, and an additional permanent emission that continuously occurs forever. -##### 4.3.13.1: FacilitatorDAO Farm distribution +##### 4.3.13.1: FacilitatorDAO Farm Distribution 70% of all FacilitatorDAO tokens emitted for farming are for Dai farming, and 30% of all FacilitatorDAO tokens emitted for farming are for Sagittarius Engine users. -##### 4.3.13.2: FacilitatorDAO Genesis emissions +##### 4.3.13.2: FacilitatorDAO Genesis Emissions The Genesis emissions of Facilitators are 2.3 billion tokens over 10 years, with the following breakdown. -###### 4.3.13.2.1: Genesis farming emissions +###### 4.3.13.2.1: Genesis Farming Emissions 2 billion FacilitatorDAO tokens are for Genesis farming. ###### 4.3.13.2.1.1 For the first 2 years, the rate of Genesis farming is 500 million FacilitatorDAO tokens per year - ###### 4.3.13.2.1.2 For the following 2 years, the rate of Genesis farming is 250 million FacilitatorDAO tokens per year. @@ -1487,15 +1525,15 @@ The workforce bonus pool starts with 300 million FacilitatorDAO tokens. The Work The permanent emissions of FacilitatorDAOs are a total of 12.5% tokens emitted per year. -###### 4.3.13.3.1: Permanent Lockstake Engine self-farm emissions +###### 4.3.13.3.1: Permanent Lockstake Engine Self-Farm Emissions 7.5% of the total supply is emitted per year for self-farming rewards for FacilitatorDAO Lockstake Engine users. -###### 4.3.13.3.2: Permanent farming emissions +###### 4.3.13.3.2: Permanent Farming Emissions 4% of the total supply is emitted per year as farming emissions -###### 4.3.13.3.3: Permanent workforce bonus pool emissions +###### 4.3.13.3.3: Permanent Workforce Bonus Pool Emissions 1% of the total supply is emitted per year as workforce bonus pool emissions, if the workforce bonus pool contains less than 5% of the total supply of FacilitatorDAO tokens. @@ -1503,15 +1541,15 @@ The permanent emissions of FacilitatorDAOs are a total of 12.5% tokens emitted p MiniDAOs have a genesis token emission that occurs over the first 10 years of its existence, and an additional permanent emission that continuously occurs forever. -##### 4.3.14.1: MiniDAO Farm distribution +##### 4.3.14.1: MiniDAO Farm Distribution 15% of all MiniDAO tokens emitted for farming are for Dai farming, 35% of all MiniDAO tokens emitted are for regular farmers of the parent AllocatorDAO token, and 50% of all MiniDAO tokens emitted are for parent AllocatorDAO Lockstake Engine users. -##### 4.3.14.2: MiniDAO Genesis emissions +##### 4.3.14.2: MiniDAO Genesis Emissions The Genesis emissions of MiniDAOs are 920 million tokens over 10 years, with the following breakdown. -###### 4.3.14.2.1: Genesis farming emissions +###### 4.3.14.2.1: Genesis Farming Emissions 800 million MiniDAO tokens are for Genesis farming. @@ -1535,19 +1573,19 @@ For the final 4 years, the rate of Genesis farming is 25 million MiniDAO tokens The workforce bonus pool starts with 120 million MiniDAO tokens. The Workforce bonus pool can be further topped up through the permanent emissions. -##### 4.3.14.3: MiniDAO permanent emissions +##### 4.3.14.3: MiniDAO Permanent Emissions The permanent emissions of MiniDAOs are a total of 12.5% tokens emitted per year. -###### 4.3.14.3.1: Permanent Lockstake Engine self-farm emissions +###### 4.3.14.3.1: Permanent Lockstake Engine Self-Farm Emissions 5% of the total supply is emitted per year for self-farming rewards for MiniDAO Lockstake Engine users. -###### 4.3.14.3.2: Permanent farming emissions +###### 4.3.14.3.2: Permanent Farming Emissions -6.5% of the total supply is emitted per year as farming emissions +6.5% of the total supply is emitted per year as farming emissions. -###### 4.3.14.3.3: Permanent workforce bonus pool emissions +###### 4.3.14.3.3: Permanent Workforce Bonus Pool Emissions 1% of the total supply is emitted per year as workforce bonus pool emissions, if the workforce bonus pool contains less than 5% of the total supply of MiniDAO tokens. @@ -1557,7 +1595,7 @@ Elixirs are 50/50 LP tokens of the native AMM engine on NewChain. They have a pr ##### 4.3.15.1: Maker Elixir -Maker Elixir is an LP token of 50/50 MKR/DAI +Maker Elixir is an LP token of 50/50 MKR/DAI. It is held by the Maker Smart Burn Engine, the Incubator, the AllocatorDAO Dendrites and the FacilitatorDAO Dendrites. @@ -1575,7 +1613,7 @@ It is held by AllocatorDAO Dendrites and MiniDAO Dendrites. ##### 4.3.15.4: MiniDAO Elixir -MiniDAO Elixir is an LP token of 50/50 MIN/ALL +MiniDAO Elixir is an LP token of 50/50 MIN/ALL. It is held by MiniDAO Dendrites. @@ -1619,7 +1657,7 @@ Parent Elixir accumulated in the Dendrite’s Parent Elixir Burn Engine is a cen The parent Elixir Burn Engine receives Elixir from multiple sources. -###### 4.3.17.4.1: +###### 4.3.17.4.1 All parent Elixir from the Reverse Burn Engine specified in *4.3.16.3* is sent to the Parent Elixir Burn Engine. @@ -1663,11 +1701,11 @@ The Budget Allocator Module is a protocol module that can be created by a Budget Delegates can use their PDMs to assign Budget Power, based on their delegated MKR, to Budget Allocator Modules. Each Budget Allocator Module will control a fraction of the total Allocated Budget, based on their relative level of Budget Power. -### 4.4: Two-stage bridge - PRO4 +### 4.4: Two-Stage Bridge - PRO4 The two-stage bridge is a blockchain bridge system that is designed to be able to withstand a malicious majority of NewGovToken holders attacking the protocol and NewChain. It works based on a normal operating model where it is controlled by the NewChain validators, but can then have a fallback mode triggered by the NewGovToken holders (not delegates or validators) that turns over its control to a Fallback Multisig of external centralized and decentralized entities. -#### 4.4.1: Normal bridge operation by NewChain Validator Set +#### 4.4.1: Normal Bridge Operation by NewChain Validator Set During the normal operation of a two-stage bridge it runs as a weighted multisig on the target blockchain that is connected with a smart contract on NewChain. The Validators of NewChain control the weighted multisig with their weight determined by their voting power, just like on NewChain. @@ -1687,7 +1725,7 @@ The Validators have the ability to update the Fallback Multisig, and must use th If a Validator does not instantly follow the instructions from the Scopes, all other Validators must slash their stake on NewChain rapidly. -#### 4.4.2 +#### 4.4.2: The Trigger Mechanism The Trigger Mechanism is a technically isolated smart contract on the target chain that uses zero knowledge proofs to allow MKR holders from NewChain to prove they are “end-holders” (not delegates or validators) of MKR. A minority of MKR end-holders from NewChain can delay the actions of the Validators, or trigger the Fallback Multisig. The parameters for delaying actions and triggering Fallback are determined by PRO4, and must be continuously updated and reassessed. @@ -1715,7 +1753,7 @@ PRO4 must specify processes for actively monitoring, maintaining and upgrading t PRO4 must specify processes for selecting and prioritizing the development of new Two-Stage Bridges, or the deprecation of existing Two-Stage Bridges. The costs and benefits of having many bridges must be considered to minimize risk to the Maker Ecosystem. -### 4.5: Developer tools and support - PRO5 +### 4.5: Developer Tools and Support - PRO5 PRO5 must specify detailed principles and processes for supporting developers building on NewChain, and developers building for SubDAOs on relevant target chains. The tools must include secure code generation systems, and standardized libraries of reusable code. Rules for SubDAOs to use standard code systems must also be developed and enforced to maximize security of the Maker Ecosystem. @@ -1723,11 +1761,11 @@ PRO5 must specify detailed principles and processes for supporting developers bu NewChain must maintain a set of Protocol Standard Modules, that are popular smart contracts that get turned into native protocol code for better performance and security. If a bug occurs in a Protocol Standard Module it is considered a bug in NewChain and must be solved through a Chain Halt and hard fork. -### 4.6: NewChain halt - PRO6 +### 4.6: NewChain Halt - PRO6 NewChain can be halted, which stops the blockchain entirely, requiring a hard fork to restart it. -#### 4.6.1 +#### 4.6.1: The Emergency Halt Module The Emergency Halt Module is a Protocol Module of NewChain that allows a minority of NewGovToken holders to trigger a Chain Halt in case governance attacks or misalignment occurs. After an Emergency Halt occurs, the new hard fork may need to remove NewGovTokens from accounts involved in the Governance Attack. This could also be the NewGovTokens of the accounts that triggered the Emergency Halt, if the Emergency Halt itself was considered an attack. It could also be a legitimate situation where no one is at fault and the Chain is just restarted with its state intact. @@ -1735,11 +1773,11 @@ The Emergency Halt Module is a Protocol Module of NewChain that allows a minorit The Chain Halt process is used to upgrade NewChain with hard forks. In the long run this can include protocol security and efficiency upgrades, and also include addition of new Protocol Standard Modules as defined in PRO5. -#### 4.6.3: Emergency halt scheduled tests +#### 4.6.3: Emergency Halt Scheduled Tests To test and verify the security of Maker Governance against dangerous edge cases, the Emergency Halt feature should be periodically tested. PRO5 must detail processes for competently testing the Emergency Halt feature in a way that maximizes security of the Maker Ecosystem without disrupting its efficiency. A scheduled Emergency Halt test must occur at least once every 10 years. A bounty must be provided for those who participate in the Emergency Halt test, and if the test fails, the bounty must be increased until the test succeeds. -### 4.7: SubDAO Frontend client diversity - PRO7 +### 4.7: SubDAO Frontend Client Diversity - PRO7 PRO7 must specify principles and processes for ensuring that the SubDAO Frontends contribute to client diversity of NewChain, and apply penalties to SubDAOs that cause client concentration risk. @@ -1755,7 +1793,7 @@ Before NewChain launch the Protocol Scope must be adapted to accommodate the boo The Stability Scope covers the management of the Dai Stablecoin. The Dai Stablecoin must be a permissionless and useful currency available to anyone. Its stability and risk must be managed to generate as much value for MakerDAO and public good as possible. -### 5.1: Stability Scope improvement - STA1 +### 5.1: Stability Scope Improvement - STA1 STA1 must cover the key specifications and processes necessary for the Scope to reliably improve itself long term without risk of misalignment. @@ -1767,7 +1805,7 @@ The Stability Scope must have a specialized Advisory Council that is able to pro The Stability Scope must have a customized strategy towards its display and interaction through the DAO Toolkit to make it maximally user friendly. -### 5.2: Dai Stablecoin reference asset - STA2 +### 5.2: Dai Stablecoin Reference Asset - STA2 The Dai Stablecoin is stable relative to a reference asset. @@ -1783,19 +1821,19 @@ Any change to the reference asset of Dai by Maker Governance must be done to pro The Dai Stablecoin is stabilized with the help of the core stability parameters. STA3 must specify principles and processes for optimizing these core stability parameters to be Universally Aligned with their purpose. -#### 5.3.1 +#### 5.3.1: The Base Rate The Base Rate is the base yearly increase in debt on Allocator Vaults and Sagittarius Lockstake Engine Vaults. The Base Rate is determined algorithmically based on the Dai Price Oracle and the Price Deviation Sensitivity algorithm. -#### 5.3.2 +#### 5.3.2: The Dai Savings Rate The Dai Savings Rate is the rate Dai holders can earn on their Dai in the Dai Savings Rate smart contracts. It is determined algorithmically based on the Base Rate and the DSR Spread parameter. -#### 5.3.3 +#### 5.3.3: Price Deviation Sensitivity Price Deviation Sensitivity is an algorithmic parameter set by Maker Governance that uses the Dai Price Oracle to determine if Dai is above or below its target price. If Dai is above the target price, the Base Rate is reduced. If Dai is below the target price, the Base Rate is increased. The rate of increase or decrease is determined by the algorithm chosen by Maker Governance with the aim of maximizing the Stability of Dai. -#### 5.3.4 +#### 5.3.4: The DSR Spread The DSR Spread is a parameter that determines how to calculate the DSR. The DSR is calculated as Base Rate - DSR Spread. @@ -1811,15 +1849,15 @@ For standard operations that aren’t otherwise specifically defined in STA4, th STA4 can define certain Special Bandwidth conditions, where separate, higher bandwidth Dai generation is enabled for preprogrammed actions that are verified to be secure through STA4. AllocatorDAOs have unlimited Special Bandwidth for deploying Dai to SubDAO farms. -#### 5.4.3 +#### 5.4.3: Funnel Modules -Funnel modules are smart contracts that are connected to an Allocator Vault Valve, and use it to perform automated operations. +Funnel Modules are smart contracts that are connected to an Allocator Vault Valve, and use it to perform automated operations. ### 5.5: Legal Recourse Assets - STA5 Legal Resource Assets are assets used as collateral for the Dai Stablecoin that are enforced through legal recourse by Arranged Structures. They have unique risks that must be safeguarded against. -#### 5.5.1 +#### 5.5.1: Arranged Structures Arranged Structures are special legal structures set up by Ecosystem Actors to secure Legal Recourse Assets to help stabilize the Maker Ecosystem. PRO5 must define strict and detailed standards for how to properly establish, fund, interact with, monitor, improve and wind down Arranged Structures. Each Arranged Structure has a Conduit system that is automatically connected to all AllocatorDAOs, and allows them to send and receive Dai or other assets. @@ -1827,7 +1865,7 @@ Arranged Structures are special legal structures set up by Ecosystem Actors to s Arranged Structures must have an AllocatorDAO owner. The owner assigns instructions to the Arranged Structure on behalf of MakerDAO, and determines if and how other AllocatorDAOs can access the Conduit of the Arranged Structure. -#### 5.5.2 +#### 5.5.2: Arrangers Arrangers are Ecosystem Actors that assist in the design and operation of Arranged Structures. They are generally prohibited from ever being in a position where they can cause damage or loss to the Maker Ecosystem, beyond delays or annoyance. They advise in the creation of Arranged Structures, and Arranged Structures must always have an Arranger attached to it, to perform reporting on it. All details related to this must be covered in PRO6. The Arrangers manage a restricted function on the Arranged Structure Conduit that allows them to send assets onwards to the predetermined blockchain account of the Arranged Structure. @@ -1835,7 +1873,7 @@ Arrangers are Ecosystem Actors that assist in the design and operation of Arrang The AllocatorDAO owner of the Arranged Structure can change the blockchain account of the Arranged Structure and change the Arranger. -#### 5.5.3 +#### 5.5.3: Advanced Asset Managers Advanced Asset Managers are Ecosystem Actors that manage and deploy advanced assets as collateral to help stabilize the Maker Ecosystem. Arrangers to help set up opportunities for AllocatorDAOs to deploy assets to Advanced Asset Managers. Arrangers and Advanced Asset Managers must be kept separate to prevent conflict of interest, and STA5 must specify principles and processes for ensuring this and preventing misalignment. @@ -1859,7 +1897,7 @@ Additional reserves held by the AllocatorDAO can also count as Junior Capital, t Unencumbered assets are any assets that either don’t conform to the requirements in *5.6.1*, *5.6.2* and *5.6.3*, or that the AllocatorDAO has specifically marked as being unencumbered. Unencumbered Assets do not count towards the AllocatorDAOs Junior Capital, but in return can be freely deployed for any Universally Aligned purpose the AllocatorDAO wants. -### 5.7: AllocatorDAO collateral and market requirements - STA7 +### 5.7: AllocatorDAO Collateral and Market Requirements - STA7 AllocatorDAOs are subject to requirements for how they deploy Dai generated from their Allocator Vault Standard Valve. The requirements do not apply to Special Valves, that instead have any requirements built into their smart contracts. @@ -1867,15 +1905,15 @@ AllocatorDAOs are subject to requirements for how they deploy Dai generated from AllocatorDAOs are subject to Capitalization requirements based on their Effective Junior Capital and the assets they are deploying their Dai to. All of the individual Capitalization Requirements for each of the asset allocations are added together, and if the AllocatorDAO does not have enough Effective Junior Capital to meet the requirement they are penalized with penalty rates as specified in STA8. Multiple Capitalization Requirements can overlap for the same assets, in which case they are added together. -##### 5.7.1.1: Capitalization Requirements for ALM categories +##### 5.7.1.1: Capitalization Requirements for ALM Categories STA7 must specify a model of Capitalization Requirements for AllocatorDAOs based on the ALM categorization of the assets in their portfolio. -##### 5.7.1.2: Capitalization Requirements for Risk categories +##### 5.7.1.2: Capitalization Requirements for Risk Categories STA7 must specify a model of Capitalization Requirements for AllocatorDAOs based on the financial risk of the assets in their portfolio. -##### 5.7.1.3: Capitalization Requirements for physical concentration risk +##### 5.7.1.3: Capitalization Requirements for Physical Concentration Risk STA7 must specify a model of Capitalization Requirements based on physical concentration risk. @@ -1911,35 +1949,35 @@ If an AllocatorDAO remains undercapitalized after having Forced Dilution activat STA9 must cover the processes for setting various economic parameters related to Maker Protocol Surplus. -#### 5.9.1 +#### 5.9.1: Surplus Buffer Upper Limit -The Surplus Buffer upper limit determines when the Surplus Buffer sends its funds to the Smart Burn Engine. +The Surplus Buffer Upper Limit determines when the Surplus Buffer sends its funds to the Smart Burn Engine. -#### 5.9.2 +#### 5.9.2: Smart Burn Engine Dai Algorithm -Smart Burn Engine Dai Algorithm is the algorithm for determining when and how the Smart Burn Engine will use received Dai to buy Maker Elixir, based on the Maker Economic Resilience Model. +The Smart Burn Engine Dai Algorithm is the algorithm for determining when and how the Smart Burn Engine will use received Dai to buy Maker Elixir, based on the Maker Economic Resilience Model. -#### 5.9.3 +#### 5.9.3: Elixir Burn Algorithm The Elixir Burn Algorithm determines when and how the Smart Burn Engine will use accumulated Maker Elixir to buy and burn MKR, based on the Maker Economic Resilience Model. -#### 5.9.4 +#### 5.9.4: Maker Reverse Burn Engine Algorithm -The Maker Reverse Burn Engine algorithm determines when and how the Maker Reverse Burn Engine will use MKR to accumulate Elixir and send it to the Smart Burn Engine, based on the Maker Economic Resilience Model. The Maker Reverse Burn Engine algorithm is replicated in the AllocatorDAO and FacilitatorDAO Dendrite Reverse Burn Engines. +The Maker Reverse Burn Engine Algorithm determines when and how the Maker Reverse Burn Engine will use MKR to accumulate Elixir and send it to the Smart Burn Engine, based on the Maker Economic Resilience Model. The Maker Reverse Burn Engine algorithm is replicated in the AllocatorDAO and FacilitatorDAO Dendrite Reverse Burn Engines. -#### 5.9.5 +#### 5.9.5: Maker Economic Resilience Model The Maker Economic Resilience Model is a mechanism that sets a target price for MKR based on monitoring various onchain factors such as asset reserves and average income. STA9 must specify principles and processes for researching and development of the Maker Economic Resilience Model to be Universally Aligned and help support stability of the Maker Ecosystem. -#### 5.9.6 +#### 5.9.6: Maker Decentralized Asset Reserve -Maker decentralized asset reserve, a system for accumulating strategically important decentralized assets to help overcollateralize Dai. STA9 must specify the model used to determine which assets to accumulate. +The Maker Decentralized Asset Reserve is a system for accumulating strategically important decentralized assets to help overcollateralize Dai. STA9 must specify the model used to determine which assets to accumulate. ### 5.10: SubDAO Economic Resilience Models - STA10 The SubDAO Dendrites require Economic Resilience Models to function. These Economic Resilience models are mechanisms that set a target price for the relevant SubDAO token based on monitoring various on-chain factors such as asset reserves and average income. STA10 must specify principles and processes for researching and development of the Economic Resilience Models for FacilitatorDAOs, AllocatorDAOs and MiniDAOs to be Universally Aligned and help support stability of the Maker Ecosystem. -### 5.11: MKR backstop - STA11 +### 5.11: MKR Backstop - STA11 If the Dai Stablecoin becomes undercollateralized, the Maker Protocol will automatically generate and sell MKR to recapitalize the system. @@ -1963,7 +2001,7 @@ The protocol must contain an MKR backstop halt mechanism that immediately halts In case the backstop limit is reached and not overridden, or in case the backstop is halted during the event, the Dai target price receives a haircut to settle the remaining bad debt of the system. STA11 must cover this worst case scenario and research ways the damage can be mitigated. -### 5.12: Dai Stablecoin decentralization - STA12 +### 5.12: Dai Stablecoin Decentralization - STA12 The Dai Stablecoin must maintain the ability to shift its collateral assets into decentralized collateral in case of physical threats. @@ -1979,15 +2017,15 @@ In case of an immediate physical threat, Maker Governance can determine a Legal When there is no immediate physical threat, there must still be a small scale subsidy program in place to subsidize decentralized collateral based generation of Dai, to ensure a market is available that can be quickly ramped up if it becomes necessary. This must be specified by STA12. -### 5.13: Sagittarius Engine Dai generation Risk Parameters - STA13 +### 5.13: Sagittarius Engine Dai Generation Risk Parameters - STA13 The Sagittarius Engine enables MKR holders to generate Dai based on the surplus owned by the Maker Protocol. It has the following risk parameters, most of them unchangeable my Maker Governance to prevent misalignment. -#### 5.13.1 +#### 5.13.1: Hard liquidation Ratio -Hard liquidation ratio of 200%. At this collateralization level, vaults will be instantly liquidated. +Hard liquidation Ratio of 200%. At this collateralization level, vaults will be instantly liquidated. -#### 5.13.2 +#### 5.13.2: Soft Liquidation Ratio Soft Liquidation Ratio of 300%. At this collateralization level, vaults will be marked for soft liquidation, and if they don’t increase their collateralization level above 300% again within a week, they are liquidated. New Vaults cannot be opened with less than 300% collateralization. @@ -2003,7 +2041,7 @@ When the real price is above the Sticky Price, the Sticky Price adjusts upwards The Debt Ceiling of Sagittarius Lockstake Engine Vaults is determined based on the surplus and reserves owned by the Maker Protocol. The total value of the debt ceiling is adjusted automatically through an algorithm that must be defined by STA13 to incentivize users to lock their MKR in the Sagittarius Lockstake Engine while also protecting the stability of the Maker Ecosystem. -#### 5.13.5: Stability fee +#### 5.13.5: Stability Fee The Stability Fee of the Sagittarius Lockstake Engine Vaults is equal to the Base Rate. @@ -2027,7 +2065,7 @@ The Accessibility Scope must have a specialized Advisory Council that is able to The Accessibility Scope must have a customized strategy towards its display and interaction through the DAO Toolkit to make it maximally user friendly. -### 6.2: Brand identity - ACC2 +### 6.2: Brand Identity - ACC2 ACC2 must specify the brand identity of Maker, and processes for refining and improving the details and examples of the brand identity to ensure it is as good as possible. The brand should be reliable and stable over the long term. @@ -2035,19 +2073,19 @@ ACC2 must specify the brand identity of Maker, and processes for refining and im ACC3 must specify accessibility reward systems for third party frontends and SubDAOs to incentivize them to attract NewStable users, DSR users and SubDAO farm users. ACC3 must also specify an accessibility reward uniquely available to SubDAOs that bring MKR holders to Lockstake into the Sagittarius Lockstaking Engine. -### 6.4: Accessibility assets - ACC4 +### 6.4: Accessibility Assets - ACC4 ACC4 must specify principles and processes for managing the accessibility assets, such as communication channels and communication presence on external websites. -### 6.5: Accessibility campaigns - ACC5 +### 6.5: Accessibility Campaigns - ACC5 ACC5 must specify principles and processes for managing accessibility campaigns. -### 6.5: SubDAO frontend standards - ACC6 +### 6.5: SubDAO Frontend Standards - ACC6 ACC6 must specify best practice for SubDAO frontend standards in terms of security, user experience and required features. -### 6.6: Easy Governance Frontend (EGF) requirements - ACC7 +### 6.6: Easy Governance Frontend (EGF) Requirements - ACC7 The EGFs are the standardized and regulated applications that most users will use to access the Sagittarius Lockstake Engine and its Governance Participation Rewards. It is critically important for the resilience of Maker Governance and must be treated as such by Alignment Conservers. It is designed to withstand attempts by individuals to manipulate the contents or design of the EGF in order to give them an advantage in the political dynamic of Maker Governance. @@ -2061,4 +2099,4 @@ The user experience of the EGF reduces the central governance decision MKR holde #### 6.6.3: Importance of Immutability -Because the design of the EGF has an outsized impact on the outcome of Maker Governance, the design must be near-immutable and rigorously defined to ensure all attempts at manipulation will be impossible. +Because the design of the EGF has an outsized impact on the outcome of Maker Governance, the design must be near-immutable and rigorously defined to ensure all attempts at manipulation will be impossible. \ No newline at end of file diff --git a/MIP104/MIP104.md b/MIP104/MIP104.md index 22c47347f..f34b5620a 100644 --- a/MIP104/MIP104.md +++ b/MIP104/MIP104.md @@ -34,25 +34,62 @@ Members of the Advisory Council are directly approved by Maker Governance throug ##### 1.1.1.1 -The Stability Facilitators must ensure that potential Advisory Council Members can apply to be approved by Maker Governance, using an open process with clear instructions. +The Stability 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 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 Stability Scope is covering. +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 Stability Scope is covering. ##### 1.1.1.3 -The Stability 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.1.5.1A*. +The Stability 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 Stability 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 Stability 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 Stability 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 Stability 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 Stability Facilitators may, if they deem it necessary, trigger a vote to remove an Advisory Council Member. If an Advisory Council Member has not done any paid work for the Scope for at least 1 year, then the Stability Facilitators can choose to remove them at will, if they deem it necessary. -##### 1.1.1.5 +##### 1.1.1.5: Stability Advisory Council Requirements + +###### 1.1.1.5.1 + +Stability Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Stability Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. + +###### 1.1.1.5.2 -The current approved Stability Advisory Council Members are recorded in *1.1.1.5.1A*. +Desired competencies for members of the Stability Advisory Council, as many of the following as possible: -###### 1.1.1.5.1A +1. Expertise in capital markets, bonds, equities. +2. Experience as a market analyst or economist. +3. Expertise in tokenomics. +4. Expertise in fund management and risk profiles. +5. Deep knowlege of decentralized collateral accounting and finance. +6. Experience in credit risk, market risk, liquidity risk, and operational risk. +7. Deep understanding of principles of portfolio construction, asset allocation, diversification strategies, and performance measurement. +8. Experience in smart contract and DeFi risk management. +9. Experience in economic modeling of high-volatility portfolios. +10. Expertise in Value at Risk analysis with detailed knowledge about the limitations of the method. + +##### 1.1.1.6 + +The current approved Stability Advisory Council Members are recorded in *1.1.1.6.1A*. + +###### 1.1.1.6.1A ¤¤¤ @@ -64,31 +101,89 @@ Current list of Advisory Council Members: ¤¤¤ -#### 1.1.2: Stability Advisory Council Projects and Funding +#### 1.1.2: Stability Advisory Council Recognition + +##### 1.1.2.1 + +In order to be eligible for the Stability 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 Stability 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] Stability 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] Stability Advisory Council Recognition Submission + - [Ecosystem Actor Ethereum address] + - [Cryptographically signed Advisory Council Recognition Submission Message] + - Applicant's name: [Company, team, or individual] + - Any other relevant identifying details: + - Twitter: + - Website: + - Email: + - Maker Forum: + - Telegram: + - LinkedIn: + - Discord: + - Github: + - Other: + - Presentation: [Introduction] + - Ethos and Vision: + - Team: [Founders and team members. Brief description of their skills and backgrounds] + - Services: [What is your company specialized in? What kind of services do you offer?] + - Experience: [A detailed history of relevant previous experience] + - Client References: [Who are your clients, what projects have you done and can you show the results of any of them?] + - Explain how your skills will contribute to improving the selected Scope: [Which specific aspect of the Scope do you intend to enhance, and what is the rationale behind your choice? How do you plan to improve the chosen aspect? Provide milestones, if applicable]. + - Payment Details: [How shall the compensation for your contributions be structured? How many hours shall the work entail? Detail as much as possible] + - Emergency Availability: [Would you be available on short notice to provide advisory support in the event of an unforeseen emergency? How short of a notice? What would be your hourly rate for emergency advisory services rendered?] +``` + +#### 1.1.3: Stability Advisory Council Projects and Funding The Advisory Council is paid on a project basis to do specific work that improves all or specific parts of the Scope Framework. -##### 1.1.2.1 +##### 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. The Stability 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 Stability Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Stability Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Stability 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 Each Quarter, if they deem it necessary, the Stability Facilitators must solicit proposals and find one or more suitable Advisory Council Member to perform a project that will result in output that can be used to improve the Scope Artifact. This work output will be presented to the AVC Subcommittee Meetings as input for their Aligned Scope Proposals. As many AVCs as possible should be supported this way, prioritized by the Stability Facilitators. -##### 1.1.2.2 +##### 1.1.3.3 In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Stability Facilitators may publicly notify the Advisory Council Members to submit proposals for projects that aim to reactively specify the language of the Scope Framework to take into account the specific situation. The Stability Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll. -##### 1.1.2.3 +##### 1.1.3.4 The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Stability 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 +#### 1.1.4 The Stability Facilitators may produce advisory input on the content of the Scope Artifacts themselves, as long as it is focused on improving process and governance content. They are prohibited from providing unilateral input on expert subject matter content. -#### 1.1.4 +#### 1.1.5 -The Stability Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in *1.1.4.1B*. +The Stability Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in *1.1.5.1B*. -##### 1.1.4.1B +##### 1.1.5.1B ¤¤¤ @@ -116,7 +211,7 @@ Before the launch of AllocatorDAO Vaults, the Core Stability parameters are fixe ### 3.1: The Base Rate -The Base Rate is regularly updated by the Stability Facilitator to approximate ((Yield Collateral Yield Benchmark - 0.5%) * 0.78 + Stability Collateral Yield Benchmark * 0.22). The up to date Base Rate is contained in *3.1.1A*. Whenever an update to the Base Rate occurs, the Stability Facilitator must trigger an executive vote to update the on-chain Stability Fees of the AllocatorDAO Vaults +The Base Rate is regularly updated by the Stability Facilitator to approximate ((Yield Collateral Yield Benchmark - 0.5%) * 0.78 + Stability Collateral Yield Benchmark * 0.22). The up to date Base Rate is contained in *3.1.1A*. Whenever an update to the Base Rate occurs, the Stability Facilitator must trigger an executive vote to update the on-chain Stability Fees of the AllocatorDAO Vaults. #### 3.1.1A @@ -156,7 +251,7 @@ When NewGovToken and SubDAO farming comes into effect, DSR utilization will coun The EDSR cannot exceed 5%. If the EDSR formula outputs a number above 5%, the actual effective EDSR implemented in the protocol will be 5% instead. -##### 3.2.2.2: EDSR Utilization-based Multipliers +##### 3.2.2.2: EDSR Utilization-Based Multipliers Each of the following EDSR multiplier tiers are triggered based on the utilization rate. When first adopted, the EDSR begins at tier 1. If at any point in time the DSR utilization stays above the level needed to trigger the movement to a new tier for a continuous period of more than 24 hours, the tier is changed, and a manual DSR adjustment must be included in the next executive vote. @@ -170,7 +265,7 @@ Each of the following EDSR multiplier tiers are triggered based on the utilizati - Multiplier: 1.15x DSR - Utilization: 35-50% -##### 3.2.2.3: +##### 3.2.2.3 EDSR ends permanently once DSR utilization crosses above 50% for a continuous period of more than 24 hours. @@ -292,7 +387,6 @@ The Stability Facilitators have a budget available to pay costs related to stres ¤¤¤ The Legal Recourse Asset budget is: - - Up to 1,000,000 DAI available per year. The full amount is immediately available at the start of the calendar year, and parts of it can be paid out through executive vote bundling when requested by the Stability Facilitators. @@ -435,7 +529,7 @@ AllocatorDAOs must be actively market making Cash Stablecoins against Dai with a A Cash Stablecoin is a stablecoin listed in *7.2.1.3.1A* or a technically secure DeFi token that can be instantly converted to a listed stablecoin, or a custody solution that can be converted into a listed stablecoin within 30 minutes. The Stability Facilitators can modify *7.2.1.3.1A* through the weekly cycle to react to changing market conditions, opportunities or risks. -###### 7.2.1.3.1A +###### 7.2.1.3.1A: ¤¤¤ @@ -624,4 +718,4 @@ All other collateral types must be offboarded when the Stability Facilitators co ### 14.4: Legacy Legal Recourse Assets -Legacy Legal Recourse Assets are LRA collateral types that were onboarded based on the governance process prior to the Alignment Artifacts going into force. Legacy LRA should be offboarded when it is possible to do so, but in some cases existing LRA can be maintained and even onboarded to preserve business relationships and reputation, as determined by the Stability Facilitators. All Legacy Legal Recourse Assets must be offboarded prior to NewChain Launch. The Stability Facilitators must expand this article to detail all Legacy Legal Recourse Assets and detailed, specific plans for when and how they will be offboarded. \ No newline at end of file +Legacy Legal Recourse Assets are LRA collateral types that were onboarded based on the governance process prior to the Alignment Artifacts going into force. Legacy LRA should be offboarded when it is possible to do so, but in some cases existing LRA can be maintained and even onboarded to preserve business relationships and reputation, as determined by the Stability Facilitators. All Legacy Legal Recourse Assets must be offboarded prior to NewChain Launch. The Stability Facilitators must expand this article to detail all Legacy Legal Recourse Assets and detailed, specific plans for when and how they will be offboarded. diff --git a/MIP106/MIP106.md b/MIP106/MIP106.md index 76fce0eb2..f86cfe7df 100644 --- a/MIP106/MIP106.md +++ b/MIP106/MIP106.md @@ -26,35 +26,143 @@ The Support Scope covers rules that regulate various tasks of ecosystem support, ### 1.1: The Support Advisory Council -#### 1.1.1: The Support Advisory Council Definition +#### 1.1.1: Support Advisory Council Membership Management -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. +Members of the Advisory Council are directly approved by Maker Governance through a governance poll, and must fulfill specific criteria. -#### 1.1.2: Support Advisory Council Membership Management +##### 1.1.1.1 -Members of the Advisory Council are directly approved by Maker Governance through a governance poll, and must fulfill specific criteria. +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.2.1 +##### 1.1.1.2 -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. +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.2.2 +##### 1.1.1.3 -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. +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.2.3 +###### 1.1.1.3.1 -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:*. +The Support Facilitators can extend this deadline, if necessary, by 15 days, provided they posted the justification in the Maker Forum. -##### 1.1.2.4 +###### 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.2.5 +##### 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 Advisory Council Members are recorded in *1.1.2.5.1A*. +The current approved Governance Advisory Council Members are recorded in *1.1.1.6.1A*. -###### 1.1.2.5.1A +###### 1.1.1.6.1A ¤¤¤ @@ -64,39 +172,97 @@ Current list of Advisory Council Members: ¤¤¤ +#### 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?] + - Experience: [A detailed history of relevant previous experience] + - Client References: [Who are your clients, what projects have you done and can you show the results of any of them?] + - Explain how your skills will contribute to improving the selected Scope: [Which specific aspect of the Scope do you intend to enhance, and what is the rationale behind your choice? How do you plan to improve the chosen aspect? Provide milestones, if applicable]. + - Payment Details: [How shall the compensation for your contributions be structured? How many hours shall the work entail? Detail as much as possible] + - Emergency Availability: [Would you be available on short notice to provide advisory support in the event of an unforeseen emergency? How short of a notice? What would be your hourly rate for emergency advisory services rendered?] +``` + #### 1.1.3: 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. +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. 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 -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. +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.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. +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.4 +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.3.5 +##### 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 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.3.5.1B +###### 1.1.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 | +|Maximum Monthly Amount (DAI)|Maximum Monthly Amount (MKR)|Implementation|Start Date|Notes| +| --- | --- | --- | --- | --- | +|50,000|N/A|Manual|2023-08-01|| ¤¤¤ @@ -380,6 +546,12 @@ Incubating SubDAOs can request support for high quality conference call capacity 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 + +5 of the 6 incubating SubDAOs do not have a brand identity and are referred to with the following code names: FacilitatorDAOs: ZERO, ONE, AllocatorDAOs: THREE, FOUR, FIVE. + +One incubating AllocatorDAO has an established brand: Spark. To promote its community development Spark can have stand alone communication channels managed by the Support Facilitators and their infrastructure. + ## 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. @@ -548,11 +720,9 @@ List of Incubating Ecosystem Actors: 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 @@ -627,9 +797,10 @@ This section covers the resources available for legal defense. Over time, it can 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. +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 @@ -675,7 +846,7 @@ Members must not be involved in any business activity outside Maker DAO or in an Members must have at least three years of experience in the cryptocurrency, DeFi, Web3, or emerging technology sectors. -###### 10.1.1.2.2.6 +###### 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. @@ -1132,15 +1303,15 @@ List of current active Policyholders: ¤¤¤ -**10.3 Privacy and Operational Security** +### 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** +### 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** +### 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. @@ -1150,7 +1321,7 @@ Responses will be structured as Standard Operational Protocols (SOPs). The categ - Reactive responses that reduce the severity of consequences if the risk event materializes. - Emergency Responses and Contingency Plans. -**10.6 Public Procurement Framework** +### 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: @@ -1160,11 +1331,11 @@ This section will define a Public Procurement Framework for contributors and act - Performance evaluation and reporting - Terminating involvement and resolving disputes -**10.7 Atlas Amendment and Audit** +### 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** +### 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. @@ -1237,8 +1408,8 @@ Applications for Resilience Research projects must follow this template: - .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. +- .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.] --- @@ -1270,4 +1441,4 @@ To implement this in practice the Atlas codifies a *Purpose System* that allocat ### 12.2: 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. +The Purpose Fund will directly allocate 33,333 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. \ No newline at end of file diff --git a/MIP107/MIP107.md b/MIP107/MIP107.md index 3ca50be37..3c9e9989c 100644 --- a/MIP107/MIP107.md +++ b/MIP107/MIP107.md @@ -1,6 +1,7 @@ # Protocol Scope Bounded Mutable Alignment Artifact ## Preamble + ``` MIP#: 107 Title: Protocol Scope Bounded Mutable Alignment Artifact @@ -49,7 +50,7 @@ Once the review period is ended, the Protocol Facilitators must publish the resp ###### 1.1.1.3.3 -Upon a successful vote, the Protocol Facilitators must arrange a service contract with the Advisory Council member, which must be made public. Approved Advisory Council Members are added to *1.1.1.6.1A*. +Upon a successful vote, the Protocol Facilitators must arrange a service contract with the Advisory Council member, which must be made public. Approved Advisory Council Members are added to *1.1.1.6.1A*. ###### 1.1.1.3.4 @@ -63,7 +64,7 @@ The Protocol Facilitators may, if they deem it necessary, trigger a vote to remo ###### 1.1.1.5.1 -Protocol Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be anonymous, pseudonymous, or known entities. Protocol Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. +Protocol Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Protocol Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. ###### 1.1.1.5.2 @@ -155,7 +156,7 @@ The Advisory Council is paid on a project basis to do specific work that improve ##### 1.1.3.1 -Entities are encouraged to submit applications with the intention of enhancing a specific portion of the Scope Framework. Any can entity notice a problem in the Scope or something that can and should be improved and apply to undergo a process to suggest improvements. The Protocol Facilitators should diligently encourage participants possessing relevant areas of expertise to actively engage in this process to the fullest extent possible. Accordingly, once this MIP is successfully passed, it is imperative that the Protocol Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Protocol Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Protocol Advisory Council budget to incentivize ecosystem participants and community members to actively seek out applicants, providing comprehensive explanations of the process. +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. The Protocol Facilitators should diligently encourage participants possessing relevant areas of expertise to actively engage in this process to the fullest extent possible. Accordingly, once this MIP is successfully passed, it is imperative that the Protocol Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Protocol Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Protocol Advisory Council budget to incentivize ecosystem participants and community members to actively seek out applicants, providing comprehensive explanations of the process. ##### 1.1.3.2 @@ -183,9 +184,9 @@ The Protocol Facilitators have a budget available to pay for Advisory Council Pr The Advisory Council project budget is as follows: -| Maximum Monthly Amount (DAI) | Maximum Monthly Amount (MKR) | Implementation | Start Date | Notes | -|---|---|---|---|---| -| 50,000 | N/A | Manual | 2023-08-01 | | +|Maximum Monthly Amount (DAI)|Maximum Monthly Amount (MKR)|Implementation|Start Date|Notes| +| --- | --- | --- | --- | --- | +|50,000|N/A|Manual|2023-08-01|| ¤¤¤ diff --git a/MIP108/MIP108.md b/MIP108/MIP108.md index bf51c3aea..f5b373023 100644 --- a/MIP108/MIP108.md +++ b/MIP108/MIP108.md @@ -1,6 +1,7 @@ # Accessibility Scope Bounded Mutable Alignment Artifact ## Preamble + ``` MIP#: 108 Title: Accessibility Scope Bounded Mutable Alignment Artifact @@ -33,25 +34,62 @@ Members of the Advisory Council are directly approved by Maker Governance throug ##### 1.1.1.1 -The Accessibility Facilitators must ensure that potential Advisory Council Members can apply to be approved by Maker Governance, using an open process with clear instructions. +The Accessibility 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 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 Accessibility Scope is covering. +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 Accessibility Scope is covering. ##### 1.1.1.3 -The Accessibility Facilitators must periodically, when it is relevant, review the Advisory Council Applications, and if they find applications that are suitable, bring them to a vote through an MKR governance poll. Approved Advisory Council Members are added to 10.2.3.1. +The Accessibility 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 Accessibility 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 Accessibility 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 Accessibility 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 Accessibility 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 Accessibility Facilitators may, if they deem it necessary, trigger a vote to remove an Advisory Council Member. If an Advisory Council Member has not done any paid work for the Scope for at least 1 year, then the Accessibility Facilitators can choose to remove them at will, if they deem it necessary. -##### 1.1.1.5 +##### 1.1.1.5: Accessibility Advisory Council Requirements + +###### 1.1.1.5.1 + +Accessibility Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Accessibility Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. -The current approved Accessibility Advisory Council Members are recorded in *1.1.1.5.1A*. +###### 1.1.1.5.2 -###### 1.1.1.5.1A +Desired competencies for members of the Accessibility Advisory Council, as many of the following as possible: + +1. Marketing expertise with a focus on web3 communities, governance, and growth. +2. Proven ability to devise strategies to expand user bases and increase adoption. +3. Experience in managing and engaging web3 communities. +4. Proven ability to create user-friendly and visually appealing interfaces. +5. Deep technical expertise of decentralized, resilient technologies that can be used to serve frontends. +6. Growth marketing acumen with a proven track record of growing mature Web3 products. +7. Great commmunication skills with a proven ability to explain complex technical concepts in simple, easy to grasp terms. +8. Expertise in Stablecoin or DeFi Marketing. +9. Deep understanding of the Maker Ecosystem and its endgame goals. +10. Solid understanding of various social media and communication platforms, as well as best practices for engaging with audiences on these platforms. + +##### 1.1.1.6 + +The current approved Accessibility Advisory Council Members are recorded in *1.1.1.6.1A*. + +###### 1.1.1.6.1A ¤¤¤ @@ -61,37 +99,97 @@ N/A ¤¤¤ -#### 1.1.2: Accessibility Advisory Council Projects and Funding +#### 1.1.2: Accessibility Advisory Council Recognition + +##### 1.1.2.1 + +In order to be eligible for the Accessibility 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 Accessibility 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] Accessibility 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] Accessibility Advisory Council Recognition Submission + - [Ecosystem Actor Ethereum address] + - [Cryptographically signed Advisory Council Recognition Submission Message] + - Applicant's name: [Company, team, or individual] + - Any other relevant identifying details: + - Twitter: + - Website: + - Email: + - Maker Forum: + - Telegram: + - LinkedIn: + - Discord: + - Github: + - Other: + - Presentation: [Introduction] + - Ethos and Vision: + - Team: [Founders and team members. Brief description of their skills and backgrounds] + - Services: [What is your company specialized in? What kind of services do you offer?] + - Experience: [A detailed history of relevant previous experience] + - Client References: [Who are your clients, what projects have you done and can you show the results of any of them?] + - Explain how your skills will contribute to improving the selected Scope: [Which specific aspect of the Scope do you intend to enhance, and what is the rationale behind your choice? How do you plan to improve the chosen aspect? Provide milestones, if applicable]. + - Payment Details: [How shall the compensation for your contributions be structured? How many hours shall the work entail? Detail as much as possible] + - Emergency Availability: [Would you be available on short notice to provide advisory support in the event of an unforeseen emergency? How short of a notice? What would be your hourly rate for emergency advisory services rendered?] +``` + +#### 1.1.3: Accessibility Advisory Council Projects and Funding The Advisory Council is paid on a project basis to do specific work that improves all or specific parts of the Scope Framework. -##### 1.1.2.1 +##### 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. The Accessibility 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 Accessibility Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Accessibility Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Accessibility 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 Each Quarter, if they deem it necessary, the Accessibility Facilitators must solicit proposals and find one or more suitable Advisory Council Member to perform a project that will result in output that can be used to improve the Scope Artifact. This work output will be presented to the AVC Subcommittee Meetings as input for their Aligned Scope Proposals. As many AVCs as possible should be supported this way, prioritized by the Accessibility Facilitators. -##### 1.1.2.2 +##### 1.1.3.3 In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Accessibility Facilitators may publicly notify the Advisory Council Members to submit proposals for projects that aim to reactively specify the language of the Scope Framework to take into account the specific situation. The Accessibility Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll. -##### 1.1.2.3 +##### 1.1.3.4 The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Accessibility 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 +#### 1.1.4 The Accessibility Facilitators may produce advisory input on the content of the Scope Artifacts themselves, as long as it is focused on improving process and governance content. They are prohibited from providing unilateral input on expert subject matter content. -#### 1.1.4 +#### 1.1.5 -The Accessibility Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in *1.1.4.1B*. +The Accessibility Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in *1.1.5.1B*. -##### 1.1.4.1B +##### 1.1.5.1B ¤¤¤ -Advisory Council project budget: +The Advisory Council project budget is as follows: -N/A +| Maximum Monthly Amount (DAI) | Maximum Monthly Amount (MKR) | Implementation | Start Date | Notes | +|---|---|---|---|---| +| 50,000 | N/A | Manual | 2023-09-01 | | ¤¤¤ diff --git a/MIP113/MIP113.md b/MIP113/MIP113.md index 07737ffe8..5cb9f8149 100644 --- a/MIP113/MIP113.md +++ b/MIP113/MIP113.md @@ -54,7 +54,7 @@ Once the review period is ended, the Governance Facilitators must publish the re ###### 1.1.1.3.3 -Upon a successful vote, the Governance 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*. +Upon a successful vote, the Governance 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 @@ -68,7 +68,7 @@ The Governance Facilitators may, if they deem it necessary, trigger a vote to re ###### 1.1.1.5.1 -Governance Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be anonymous, pseudonymous, or known entities. Governance Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. The Governance Scope Advisory Council is crucial in this stage of changes that Maker Governance is going through. This council should be composed of highly skilled entities who can quickly adapt to constant changes. They should have or be willing to attain a deep understanding of the Maker Ecosystem and its endgame goals. They should also be aligned with the Atlas and Scope Artifacts. +Governance Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Governance Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame. The Governance Scope Advisory Council is crucial in this stage of changes that Maker Governance is going through. This council should be composed of highly skilled entities who can quickly adapt to constant changes. They should have or be willing to attain a deep understanding of the Maker Ecosystem and its endgame goals. They should also be aligned with the Atlas and Scope Artifacts. ###### 1.1.1.5.2 @@ -98,6 +98,7 @@ Current list of Advisory Council Members: N/A + ¤¤¤ #### 1.1.2: Governance Advisory Council Recognition @@ -160,7 +161,7 @@ The Advisory Council is paid on a project basis to do specific work that improve ##### 1.1.3.1 -Entities are encouraged to submit applications with the intention of enhancing a specific portion of the Scope Framework. Any can entity notice a problem in the Scope or something that can and should be improved and apply to undergo a process to suggest improvements. The Governance 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 Governance Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Governance Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Governance Advisory Council budget to incentivize ecosystem participants and community members to actively seek out applicants, providing comprehensive explanations of the process. +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. The Governance 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 Governance Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Governance Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Governance 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 @@ -188,9 +189,9 @@ The Governance Facilitators have a budget available to pay for Advisory Council Advisory Council project budget: -| Maximum Monthly Amount (DAI) | Maximum Monthly Amount (MKR) | Implementation | Start Date | Notes | -|---|---|---|---|---| -| 50,000 | N/A | Manual | 2023-08-01 | | +|Maximum Monthly Amount (DAI)|Maximum Monthly Amount (MKR)|Implementation|Start Date|Notes| +| --- | --- | --- | --- | --- | +|50,000|N/A|Manual|2023-08-01|| ¤¤¤ @@ -223,7 +224,6 @@ Atlas Interpretation precedent made directly by the Governance Facilitators is c ¤¤¤ List of direct Atlas Interpretations: - 1. Payments denominated in NewGovToken in the Atlas or the Scopes will be made in MKR prior to the launch of NewGovToken at the proscribed conversion rate listed in The Atlas. ¤¤¤ @@ -260,7 +260,7 @@ Derecognition notices are issued publicly and justification and reasoning must b Derecognitions are recorded by adding the identity and known aliases or associated entities to **4.1.3A** -#### 4.1.3A +#### 4.1.3A: ¤¤¤ @@ -348,7 +348,6 @@ AVC member recognition submission [Ethereum address] [Cryptographically signed AVC Member Recognition Message] ``` - #### 5.2.2 The Governance Facilitators must maintain the list of Unaffiliated AVC Members contained in *5.2.2.1A*. @@ -366,6 +365,7 @@ List of Unaffiliated AVC Members: ¤¤¤ + #### 5.2.3 An Unaffiliated AVC Member may join an AVC through the process described in 4.5 or start a new AVC through the process described in 4.4. @@ -380,34 +380,29 @@ The list of all AVCs is contained in *5.2.4.1A*, broken down by current status. ##### 5.2.4.2 -An AVC is marked as *active* status if it has fulfilled every requirement under *4.3* in the previous quarter. +An AVC is marked as _active_ status if it has fulfilled every requirement under *4.3* in the previous quarter. --- - ##### 5.2.4.3 -An AVC is marked as *inactive* status if it has failed to fulfill the requirements under *4.3* for the most recent quarter, but has fulfilled the requirements for one or more prior quarters. +An AVC is marked as _inactive_ status if it has failed to fulfill the requirements under *4.3* for the most recent quarter, but has fulfilled the requirements for one or more prior quarters. --- - ##### 5.2.4.4 -An AVC is marked as *pending* status if it has been in existence for less than one full quarter. +An AVC is marked as _pending_ status if it has been in existence for less than one full quarter. --- - ##### 5.2.4.5 An AVC that has failed to fulfill the requirements under *5.2.4* for two consecutive quarters is no longer considered an AVC and is removed from the list in *5.2.4.7.1A*. --- - ##### 5.2.4.6 The list of all AVCs is contained in *5.2.4.7.1A*, broken down by current status. The Arbitration Facilitators must keep the list current based on AVC creation, adherence with requirements, and AVC Decisions. --- - ##### 5.2.4.7.1A ¤¤¤ @@ -481,16 +476,17 @@ List of inactive AVCs and their members prior to becoming inactive: ¤¤¤ + ### 5.3: Aligned Voter Committee Activation If 2 or fewer AVCs are active, then newly created AVCs are instantly Active from the moment of creation. If 3 or more AVCs are active, then new AVCs have to comply with the activation requirements for a full quarterly governance cycle before becoming Active. + ## 6: Aligned Delegates (ADs) The Governance Facilitators must ensure that all the rules of ADs are followed as specified in *ATL2.6* ### 6.1: Aligned Delegate Recognition - The Governance Facilitators must maintain a list of Recognized Aligned Delegates, and maintain the process for applying for Recognition as an Aligned Delegate #### 6.1.1 @@ -590,7 +586,6 @@ The number of PD and RD slots is modifiable over time, and must be increased or ¤¤¤ The current number of Prime Delegate and Reserve Delegate slots (applies separately to both): - * 5 ¤¤¤ @@ -627,7 +622,6 @@ List of Facilitator budgets: ¤¤¤ --- - #### 7.1.2 The Scopes and their responsible Facilitators, or Responsible Facilitator Core Units, are contained in *7.1.2.1A*. The Active Element is changed through the ordinary AVC process. @@ -656,7 +650,6 @@ List of Responsible Facilitators: If all Facilitators of a Scope are unresponsive and not taking care of their duties, a majority of the remaining Facilitators can choose amongst themselves an interim Facilitator, that will then temporarily become the Responsible Facilitator for the Scope. --- - #### 7.1.4 Reserve Facilitators can help protect the continuity of Maker Governance in case other Facilitators become unavailable. If the main Facilitators of a scope become unresponsive or otherwise unavailable, the Reserve Facilitators can initiate a take over as interim Facilitators by posting their observations of inactivity or unavailability to the Maker Core forum. If the take over is not disputed by the existing Facilitators within 48 hours, the Reserve Facilitators are changed to Facilitators in *7.1.2.1A*, and must take care of the duties of the role until a new Facilitator is selected using the ordinary AVC process. @@ -705,4 +698,4 @@ The first Aligned Delegate season lasts from the moment this Scope Artifact is a ### 12.4: AVC Advisory Council Focus -During bootstrapping, until the Scope Improvement Articles of each Scope Artifact are well developed, AVCs must focus on making Aligned Scope Proposals that improve the Scope Improvement Articles. ADs must not follow instructions by AVCs, through Aligned Governance Strategies or Aligned Scope Proposals, that cover subjects other than improvements to the Scope Improvement Articles and/or Scope Advisory Councils. Instead, for matters not related to Scope Improvement Articles and/or Scope Advisory Councils, ADs must vote according to their own understanding of Universal Alignment and the spirit of the Atlas in a way that best pushes forward the Maker Ecosystem towards the Endgame State and strengthens the Alignment Artifacts. ADs must make use of the ability of MIP102 edits to distinguish between Article 1 edits and General edits of Scope Artifacts, to make sure they follow their AVCs GSL instructions for Article 1 edits, and treat General edits separately. \ No newline at end of file +During bootstrapping, until the Scope Improvement Articles of each Scope Artifact are well developed, AVCs must focus on making Aligned Scope Proposals that improve the Scope Improvement Articles. ADs must not follow instructions by AVCs, through Aligned Governance Strategies or Aligned Scope Proposals, that cover subjects other than improvements to the Scope Improvement Articles and/or Scope Advisory Councils. Instead, for matters not related to Scope Improvement Articles and/or Scope Advisory Councils, ADs must vote according to their own understanding of Universal Alignment and the spirit of the Atlas in a way that best pushes forward the Maker Ecosystem towards the Endgame State and strengthens the Alignment Artifacts. ADs must make use of the ability of MIP102 edits to distinguish between Article 1 edits and General edits of Scope Artifacts, to make sure they follow their AVCs GSL instructions for Article 1 edits, and treat General edits separately.