diff --git a/MIP101/MIP101.md b/MIP101/MIP101.md index dd59b1ef5..79b8a9fd9 100644 --- a/MIP101/MIP101.md +++ b/MIP101/MIP101.md @@ -315,7 +315,7 @@ Scope Mutable Alignment Artifacts (Scope Artifacts) are important tools in enabl #### 2.3.1 -Scope Artifacts are continuously updated on a quarterly basis through the AVC process, based on the Aligned Scope Proposals produced by the AVCs. Their updates must always be aligned with the specifications of the Atlas. +Scope Artifacts are continuously updated. Their updates must always be aligned with the specifications of the Atlas. #### 2.3.2 @@ -335,7 +335,7 @@ Active Elements are mutable elements that need to change as a part of the normal 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: Template Elements +##### 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. @@ -357,11 +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 four critical roles: -- Aligned Voter Committee Member +Alignment Conservers can have two critical roles: + - Aligned Delegate + - Facilitator -- Budget Allocator. ##### 2.4.1.1 @@ -395,186 +395,9 @@ In severe cases that can be described as Governance Attacks, in addition to bein Alignment Conservers are encouraged to be anonymous. Some Alignment Conserver roles are required to be anonymous, and their identities must be derecognized from acting as Alignment Conservers in general, in case their privacy is breached. -### 2.5: Aligned Voter Committees - GOV5 - -AVCs are standardized Voter Committees made up of Alignment Conservers that hold MKR and participate in the Maker Governance process as actors that are deeply aligned with MKR holders. They are subject to specific requirements, and receive various benefits, resources, and support from the Support Scope. They have significant formal powers, but no direct physical power, making them well-suited to be in control and making key decisions during normal conditions. - -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 - -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. - -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. - -###### 2.5.1.1.1 - -It is important that AVCs always act with proper importance towards safeguarding and optimizing long term alignment artifact strength, as it is their most critical duty. Deprioritizing this duty for the benefit of other aims is severe misalignment. - -##### 2.5.1.2 - -As a general rule, AVCs are restricted from being prescriptive and self-justifying in their approach to Alignment Artifact strengthening. This is to prevent them from micromanaging and using the guise of Alignment Artifact strengthening to cause misalignment. GOV5 must specify principles and processes for FacilitatorDAOs to review and act if AVCs are at risk of micromanagement and misalignment. - -###### 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. - -###### 2.5.1.2.2 - -The Alignment Artifact strengthening work of AVCs must properly take into account and justify its impact on Future Alignment Risk of the AVC. - -#### 2.5.2: Aligned Governance Strategies and Aligned Scope Proposals - -The core task of AVCs is the quarterly creation of an up to date ratified Aligned Aligned Governance Strategy and up to date ratified Aligned Scope Proposals for each of the 5 Scopes. - -##### 2.5.2.1 - -The Aligned Governance Strategy is a document that instructs ADs in how to vote with the votes of their Governance Strategy Link to the specific AVC. - -###### 2.5.2.1.1 - -The first paragraph of the Aligned Governance Strategy is the AVC Profile, which can be up to 280 characters long. The AVC Profile is displayed in the EGF and other important Maker Governance interfaces when describing the AVC. AVCs must have easy to understand Profiles, and their governance actions must be congruent with their AVC Profile. The AVC Profile must, as its first sentence, describe where the AVC aims to be on the Hawk, Dove, Balanced spectrum. - -###### 2.5.2.1.1.1 - -Hawkish AVCs tend to prefer higher spreads and lower budgets, focusing more on short term income and asset accumulation. Dovish AVCs tend to prefer lower spreads and higher budgets, focusing more on long term growth and innovation. Balanced AVCs try to find a middle ground between the two. The Hawk, Dove, Balanced spectrum is a continuous spectrum, so many different hawkish or dovish AVCs can exist that are more or less Balanced. - -##### 2.5.2.2 - -The Aligned Scope Proposals are documents that describe the desired updated state of each of the Scope Artifacts. The Aligned Scope Proposals are often created based on a starting point developed by Scope Advisory Councils, where the AVCs then apply and communicate their unique strategic perspective. - -##### 2.5.2.3 - -For Aligned Governance Strategy and Aligned Scope Proposals to be valid, they must be posted on the AVCs communication channels, and have a hash of its contents ratified through a successful AVC Decision. - -##### 2.5.2.4 - -AVCs must always be able to articulate their Strategic Perspective in their AVC Profile in a simple enough way that EGF users can reasonably understand what delegating their votes to the strategy of the AVC means. This is in terms of the Aligned Governance Strategy and the Aligned Scope Proposals that the AVC will create. - -#### 2.5.3: Aligned Voter Committee Recognition Process - -New AVCs can become recognized as Active AVCs by the Governance Scope if they fulfill the AVC eligibility requirements for participation and internal governance for at least one full quarterly governance cycle. If at any time after becoming recognized as an Active AVC, the AVC no longer completely fulfills all of the eligibility requirements, it immediately loses its recognition as an active AVC and all associated benefits. - -##### 2.5.3.1 - -Before creating an AVC, an Alignment Conserver must verify as an unaffiliated Alignment Voter Committee Member through a process specified in GOV5. - -#### 2.5.4 - -To remain Active, an AVC must follow a standardized internal governance process for determining membership, creation of Aligned Governance Strategy, Aligned Scope Proposals and other decisions. - -##### 2.5.4.1 - -AVC Members vote on AVC decisions based on their relative ownership of verified MKR. A vote takes one week and resolves with acceptance or rejection based on the amount of verified MKR that votes for each option, unless a simple majority is reached in which case the decision is accepted or rejected instantly. - -##### 2.5.4.2 - -New AVC Members are included based on an application that is either accepted or rejected through an AVC decision. The effective verified MKR of members is specified in their application, and can only be increased or decreased through another application that must be accepted by another AVC decision. The effective verified MKR of the creator of an AVC is determined when they create the AVC. If an AVC Member’s blockchain account has MKR in excess of their effective verified MKR, they don’t gain additional voting power in the AVCs internal governance process, but it does count towards AVC rewards qualification. If an AVC member's blockchain account has less MKR than their verified amount, they are automatically removed from the AVC. - -##### 2.5.4.3 - -Existing AVC Members can be removed through an AVC decision. - -##### 2.5.4.4 - -A minority quorum of AVC Members based on verified MKR can trigger an AVC split. GOV5 must specify the minority quorum to ensure it serves its role well. All AVC Members then vote to support one of two new AVCs, with the naming rights and infrastructure inherited by the side with more MKR in support. The AVC Members of each of the two new AVCs is determined based on who voted to support each side. The Aligned Governance Strategy Links from ADs are divided proportionally into two new Protocol Delegation Contract, each containing an amount of delegated MKR that is proportional to the MKR in support for each side of the AVC split. - -##### 2.5.4.5 - -AVC Subcommittee Meetings must be scheduled through an AVC Decision. - -#### 2.5.5 - -An AVC must, through an AVC decision, create a legitimate Aligned Scope Proposal for each of the 5 Scopes, each quarterly governance cycle. AVCs must also convene 2 scheduled AVC Subcommittee Meetings to discuss the creation of the Aligned Scope Proposals for each of the 5 Scopes, each quarterly cycle. - -##### 2.5.5.1 - -The AVC Subcommittee Meetings must be held during the first ten whole weeks of each quarter, in the following order: - -- Week 1: Governance Scope -- Week 2: Support Scope -- Week 3: Protocol Scope -- Week 4: Stability Scope -- Week 5: Accessibility Scope -- Week 6: Governance Scope -- Week 7: Support Scope -- Week 8: Protocol Scope -- Week 9: Stability Scope -- Week 10: Accessibility Scope - -In the event of technical issues or other unforeseen circumstances that impede the AVC Subcommittee from holding a scheduled meeting, the meeting can be postponed for a duration of up to 7 days. Such postponement is contingent upon an announcement being made on the Maker forum, which must tag a governance facilitator. Additionally, this announcement must be in the form of an AVC decision. This rescheduling can be implemented within the same week or extended to the subsequent week, ensuring that the total duration of all meetings does not surpass an 11-week period within the quarter. - -#### 2.5.6 - -AVCs must represent the interest of MKR holders, and cannot represent or be closely affiliated with an external entity. AVCs must always operate with awareness of members’ conflict of interest and take all reasonable steps to make sure that their alignment is preserved. GOV5 must specify ways to deal with this risk. - -#### 2.5.7 - -AVCs must vote according to their strategic perspective. Clearly voting against the stated strategic perspective is misalignment and GOV5 must specify ways to detect and deal with this possibility. - -##### 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. - -#### 2.5.8 - -AVCs must limit their participation in Maker Governance to the creation of Aligned Governance Strategy and Aligned Scope Proposals that function resiliently based on open, objective processes and stay at a high enough level to ensure micromanagement isn't possible. AVCs must not attempt to create biased or unfair conditions for specific Ecosystem Actors, or attempt to put in place unjustified, granular decisions directly, or indirectly through biased processes. GOV5 must specify processes in which AVCs are deactivated and their members derecognized in case there is clear misalignment risk. - -##### 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. - -#### 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 - -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. - -##### 2.5.10.1 - -The AVC Member participation compensation is paid out based on full participation within each scope every quarter. To qualify for the participation reward for a particular Scope the AVC Member must: - -###### 2.5.10.1.1 - -Have attended the two AVC Subcommittee Meetings and be co-author on the AVC Aligned Scope Proposals. - -###### 2.5.10.1.2 - -Be a co-author on the Aligned Governance Strategy. - -###### 2.5.10.1.3 - -GOV5 must specify minimum standards of work and contribution based on best practice to prevent spam or inferior outlier AVCs from qualifying for rewards. - -##### 2.5.10.2 - -The yearly total AVC Member participation rewards is 20 million NewGovToken. This amount is broken into tranches of 1 million NewGovToken for each Scope per quarterly governance cycle, and shared across the reward slots for that Scope. - -##### 2.5.10.3 - -The number of rewards slots for each tranche is equivalent to the total amount of PDs and RDs. - -##### 2.5.10.4 - -The reward slots of a tranche are awarded to the AVC Members that have fulfilled the participation requirements for the tranche and have the highest verified MKR balances. - -#### 2.5.11: Display of AVCs in EGFs - -AVCs are shown on a ranked list on the landing page of the EGFs, with name and AVC Profile displayed alongside their logo. The ranked list is determined based on the highest total voter weight of the AVCs. - -##### 2.5.11.1 - -Total voter weight is calculated based on total undelegated or self-delegated, verified MKR holdings of members of the AVC plus total amount of MKR delegated to GSLs to the AVC - ### 2.6: Aligned Delegates (ADs) - GOV6 -ADs are Alignment Conservers that have registered based on the processes specified in the Governance Scope Artifact. ADs operate Governance Strategy Links (GSLs), and receive various benefits while being subject to specific requirements in addition to the general Alignment Conserver requirements. ADs have significant physical power over the Maker Protocol as they control votes obtained from the Governance Participation Rewards. As a result their focus is to protect the Maker Ecosystem against abuse of this power by themselves or others, and to use the power to protect the Maker Ecosystem in case other parts of the Governance Process take misaligned actions. To avoid politicization of their power, ADs must not become involved in day to day marginal governance decisions or have their own strategic perspectives. +ADs are Alignment Conservers that have registered based on the processes specified in the Governance Scope Artifact. ADs receive various benefits while being subject to specific requirements in addition to the general Alignment Conserver requirements. ADs have significant physical power over the Maker Protocol as they control votes obtained from delegation of voting power. As a result their focus is to protect the Maker Ecosystem against abuse of this power by themselves or others, and to use the power to protect the Maker Ecosystem in case other parts of the Governance Process take misaligned actions. #### 2.6.1: Protocol Delegation Modules (PDMs) @@ -592,53 +415,21 @@ PDMs are Seasonally Active from the moment they are created, until the Season th Delegating to Seasonally Active PDMs will qualify Lockstake Engine users for Governance Participation Rewards throughout the entire Season, until the monday of the 12th full week of the first quarter of the year for PDMs of the earlier overlapping season. -#### 2.6.2: Aligned Governance Strategy Links (GSLs) - -A PDM can be upgraded to an AD PDM through a user action. AD PDMs are split up into multiple delegation submodules, called GSLs, that each can receive delegated votes separately. Each GSL specifies one AVC, and the AD is required to vote according to the Aligned Governance Strategy of the AVC, unless doing so would result in misaligned actions. - -##### 2.6.2.1 - -GSLs are Seasonally Active in the same way as normal PDMs, and this determines whether the ADs qualify for income. - -##### 2.6.2.2 - -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 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. +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 delegation contracts, 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. ##### 2.6.3.1 -The Governance Scope Artifact specifies the number of PD slots, and the number of RD slots. There is always an equivalent amount of both. The number of slots must be increased over time if the income level of PDs and RDs increase above their baseline. The number of slots must be decreased over time if the income level of PDs and RDs decreases below their baseline. The baseline should generally increase over time if the number of PD and RD slots are increasing, ensuring that the internal operations of PDs and RDs also grows larger over time as the number of PDs and RDs increase. - -###### 2.6.3.1.1 - -The process for modifying the number of PD and RD slots must generally aim to have changes in the number of slots happen at the end of the Election Season, but in extraordinary circumstances, which must be specified by the Governance Scope, they can be done with 1 month warning. - -##### 2.6.3.2 - -The top qualified ADs by total amount of MKR delegated to their Seasonally Active GSLs at the end of the Election Season are the PDs, with the amount of PDs corresponding to the number of PD slots. The next top qualified ADs by total amount of MKR delegated to their Seasonally Active GSLs are the RDs, with the amount of RDs corresponding to the number of RD slots. - -##### 2.6.3.3 - -The Election Season is a period of time that begins on the Monday of the 11th full week of the first quarter of the year, and ends on the Friday of the 12th full week of the first quarter of the year. At the beginning of the election season, all ADs can deploy new GSLs that will be Seasonally Active for the coming season, and that Lockstake Engine users can redelegate to in order to keep their Governance Participation Reward before it expires on the Monday of the 12th full week of the first quarter of the year. - -###### 2.6.3.3.1 - -At the end of the election season, the PD slots are determined directly based on the top ranking of the total amount of MKR delegated to the later Seasonally Active GSLs of the ADs. - -###### 2.6.3.3.2 - -Outside of the Election Season, a PD can only lose their slot if an RD achieves twice as much total delegated MKR to their Seasonally Active GSLs compared to the incumbent PD. +The Governance Scope Artifact specifies the number of PD slots, and the number of RD slots. ###### 2.6.3.3.3 -The available RD slots change in real time based on the top ranking of ADs that aren’t PDs by total amount of MKR delegated to their Seasonally Active GSLs. +The beneficiaries of the available PD and RD slots change in real time based on the top ranking of ADs that aren’t PDs by total amount of MKR delegated to their delegation contract(s). ##### 2.6.3.4: AD Buffer -The AD Buffer is an account of MKR that builds up when an AD achieves an income rank of either PD or RD. The initial income that the AD earns accumulates in the AD buffer, until it contains 1 month's worth of income. At that point, the AD income starts paying out the to account that controls the AD-PDM. +The AD Buffer is an account of NGT and NST that builds up when an AD achieves a budget rank of either PD or RD. The budget that an AD is responsible for accumulates in the AD buffer. It cannot be spent until it contains at least 1 month's worth of budget. Once monthly, all ADs can request payments from their buffers. An AD's monthly payment request can be any amount as long as there is still at least one month worth of budget remaining after the payments are made. Payments can be requested to multiple addresses at once and can include the address that controls the AD's PDM. ADs can include descriptions of what the payments are for, which can include personal compensation, compensation to team contributors, research expenses, and more. The Governance Facilitators then include the payments in the next Executive Spell. PDs must only use the full amounts of their budgets if they are contributing significant, best in class work towards the development of the Atlas, and their budget use must generally be scaled according to their level of Atlas contributions. ###### 2.6.3.4.1 @@ -652,35 +443,25 @@ The AD Buffer is used as collateral for a whistleblower bounty in case the AD ac Each of the PD and RD slots earns up to an equal share of the total compensation available to their level each month, paid out continuously in real time. The income that gets paid out can be reduced if the ADs don’t fully comply with participation requirements -##### 2.6.3.6 - -Actual AD income payouts are modified based on the requirement to have a minimum amount of participation in AVC Subcommittee Meetings. PDs must participate in at least 85% of the AVC Subcommittee Meetings hosted by AVCs whose strategies they follow each quarter to qualify for their full share of AD income. RDs must participate in at least 50% of the AVC Subcommittee Meetings hosted by AVCs whose strategies they follow each quarter to qualify for their full share of AD income. If ADs participate in less than the minimum amount of AVC Subcommittee Meetings, accounted for on a monthly basis, they receive a proportionally reduced amount of the total AD income they are eligible for the following month. If ADs participate in all the AVC Subcommittee Meetings of a month, they always receive the full amount of their AD income. Participation in AVC Subcommittee Meetings that the ADs have a broken GSL with does not count towards participation for the purposes of calculating AD income. - -Participation in a Subcommittee involves a reasonable and meaningful amount of contribution with useful research and information that must be specified in the Governance Scope. - ##### 2.6.3.7 -Actual AD income payouts are also modified by voting activity metrics for the last 12 months, which includes overall voting activity in all of the votes that the ADs are able to vote on. If an AD is active in less than 95% of all votes over the last 6 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% voting activity. If an AD falls below 75% voting activity over the last 6 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their Seasonally Active GSLs. A PD can lose their PD status this way, and even if their activity metric recovers they do not automatically become a PD again, except through the regular process of becoming a PD outside of the Election Season. +Actual AD income payouts are modified by voting activity metrics for the last 3 months, which includes overall voting activity in all of the votes that the ADs are able to vote on. If an AD is active in less than 95% of all votes over the last 3 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% voting activity. If an AD falls below 75% voting activity over the last 3 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their delegation contract. A PD can lose their PD status this way, and even if their activity metric recovers they do not automatically become a PD again, except through the regular process of becoming a PD outside of the Election Season. ##### 2.6.3.8 -Actual AD income payouts are modified by AD communication metrics for the last 12 months, which requires the ADs to write an explanation for each vote that ties it to the Aligned Governance Strategy and their independent strategy, to help the MKR holders that delegated to them to understand the logic they use when executing the chosen Governance Strategies. If the AD actively communicates on less than 95% of all votes over the last 6 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% communication activity over the last 6 months. If an AD falls below 75% communication activity over the last 6 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their Seasonally Active GSLs. A PD can lose their PD status this way, and even if their activity metric recovers they do not automatically become a PD again, except through the regular process of becoming a PD outside of the Election Season. +Actual AD income payouts are modified by AD communication metrics for the last 3 months, which requires the ADs to write an explanation for each vote that demonstrates its universal alignment. If the AD actively communicates on less than 95% of all votes over the last 3 months, they receive a reduced amount of AD income. The reduction in income is proportionally linear until it reaches 0 AD income at 75% communication activity over the last 3 months. If an AD falls below 75% communication activity over the last 3 months, it loses qualification for AD income and any AD income rank they may be eligible for is passed on to the next highest AD by total amount of MKR delegated to their delegation contract​​​​​​​. A PD can lose their PD status this way. ##### 2.6.3.9 -The PD slots share a total of 60 million NewGovToken per year amongst them. +The PD slots each have a continually accruing budget equating to 650,000 NST and 3,960,000 NGT per year. ##### 2.6.3.10 -The RD slots share a total of 20 million NewGovToken per year amongst them. - -#### 2.6.4: Default Display of Aligned Delegates (ADs) in the Easy Governance Frontend (EGF) - -ADs are displayed by default in randomized order in the EGFs, if they have at least two active GSLs to two active AVCs. +The RD slots each have a continually accruing budget equating to 100,000 NST and of 360,000 NGT per year. #### 2.6.5: Aligned Delegate Alignment Risk Mitigation -ADs are generally not allowed to engage directly with Ecosystem Actors and other counterparties to the DAO, or in other ways engage in operational activities. They must remain focused on their job of using their physical voting power over the protocol to safeguard its alignment. Additionally, they must publicly provide governance information and research material to AVCs, and can interact with ecosystem participants for this purpose. They are also not allowed to provide “kickbacks” from their compensation to MKR holders that delegate to them. Any violation of these requirements constitutes breaching the Alignment Conserver requirements. +Delegates are not allowed to provide “kickbacks” from their compensation to MKR holders that delegate to them. Any violation of these requirements constitutes breaching the Alignment Conserver requirements. ##### 2.6.5.1 @@ -706,17 +487,13 @@ 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.6.7: Aligned Delegate Charity - -While ADs are not allowed to be involved in operational activities, or allocate their AD income towards operational activities that goes beyond their task of providing research and information to AVCs, the one exception is using a portion of their AD income for donations to charity. It is encouraged that ADs compete and campaign on their ability to achieve some level of charitable impact with the resources available to them, in order to demonstrate alignment with the public good purpose of the DAO. - ### 2.7: FacilitatorDAOs and Facilitators FacilitatorDAOs are a type of SubDAO that can be given responsibility over MakerDAO Scopes and SubDAO Scopes in return for tokenomics rewards. #### 2.7.1 -When a FacilitatorDAO has responsibility for an Alignment Artifact, they are fully required to follow all instructions and rules of the Alignment Artifact elements. If they fail to follow the instructions and rules correctly, they can be penalized by the Governance Scope. The penalties and process for penalizing must be specified in the Article 6 of the Governance Scope. +When a FacilitatorDAO has responsibility for an Alignment Artifact, they are fully required to follow all instructions and rules of the Alignment Artifact elements. If they fail to follow the instructions and rules correctly, they can be penalized by the Governance Scope. The penalties and process for penalizing must be specified in the Article 7 of the Governance Scope. #### 2.7.2: Assigning Responsibility of MakerDAO Alignment Artifacts to FacilitatorDAOs @@ -800,6 +577,7 @@ In some cases Budgets will have specified an adjusted weight inside the Budget E 40 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 @@ -874,122 +652,22 @@ Professional Ecosystem Actors are external actors that are paid through the Scop Advisory Council Member Ecosystem Actors perform research and publish advice for the DAO to use in improving the Scopes Artifacts and their contained processes. Often, this is used as a check for choosing the best Active Ecosystem Actors available to supply a need defined in a Scope Artifact. The work of Advisory Council Members is implemented exclusively through modifications to the Scope Artifacts, and can also be used to receive advice regarding the specific interpretation of Scope Artifacts (which, if followed, must then be included in the Scope Artifact). -The Scope Artifact improvements researched and suggested by the Advisory Council Members are presented to the AVCs who then determine to what extent they want to follow their suggestions for designing their Aligned Scope Proposals. +The Scope Artifact improvements researched and suggested by the Advisory Council Members are presented to the ACs who then determine to what extent they want to follow their suggestions for designing MIP102s. #### 2.8.2: Active Ecosystem Actors 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, 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. - -#### 2.9.1: AVC and AD Aligned Governance Strategy Links (GSLs) - -A GSL is a submodule of a PDM controlled by an AD. When delegating to the AD using the EGF, MKR holders use one of the ADs Seasonally Active GSLs. - -##### 2.9.1.1 - -ADs must create GSLs to at least 2 AVCs when applying for AD recognition. - -##### 2.9.1.2 - -AVCs and ADs can choose to Break a GSL at any time, if they deem that the other party has acted misaligned. When a GSL is broken, the votes delegated to the broken GSL count as having been delegated to the ADs Neutral GSL. - -##### 2.9.1.3 - -An AD creating a GSL is permissionless, and ADs can create new GSLs at will to AVCs they do not have a broken link with. - -##### 2.9.1.4 - -If an AD has less than 2 GSLs, either because an AVC they had a GSL with became inactive, or they had a link broken, then the AD becomes unranked, and will not be shown at the top of the EGF. - -##### 2.9.1.5 - -It is permitted for AVCs to set participation requirements for PDs and RDs that have a GSL to them, and break the GSL if the participation requirements aren't being met. - -###### 2.9.1.5.0 - -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 - -Aligned Delegates are expected to provide crucial support to AVCs in the domains where they are the most aligned actors. - -##### 2.9.2.1 - -ADs can help with the design and improvement of the Scope Improvement Articles, which are the first Articles of each of the Scope Alignment Artifacts. - -###### 2.9.2.1.1 - -ADs can support AVCs in proposing specific elements that provide unambiguous and objective constraints on which types of Advisory Council Members will be most in the interest of MKR holders for Facilitators to propose to onboard. - -###### 2.9.2.1.2 - -ADs can support AVCs in proposing specific elements that provide unambiguous and effective boundaries on what advisory council projects the Facilitators can fund, and how to prioritize them and choose which Advisory Council Member to perform the project. - -##### 2.9.2.2 - -ADs can do research and knowledge gathering about relevant things in the Maker ecosystem and how it relates generally to governance or to specific AVCs and their strategic perspective, and present it publicly to AVCs - -###### 2.9.2.2.0 - -*It is important that this activity doesn't create risk of politicization, which is why the transparency and the strict focus on objective fact finding is the central element of ADs interactions with Ecosystem Actors.* - -##### 2.9.2.3 - -ADs can help AVCs write and shape elements and sets of elements for Scope Aligned Scope Proposals, ensuring that they are congruent with best practice for writing elements and that they maximally capture the intent of the AVC and the Advisory Councils. - -###### 2.9.2.3.0 - -As they work closely with the Alignment Artifacts and the correct interpretation thereof, and are generally deeply involved in core governance, ADs are well positioned to provide this kind of neutral, governance-technical support to AVCs. - -##### 2.9.2.4 - -ADs can help AVCs craft the language of the AVC Aligned Governance Strategy to ensure that it gives them the flexibility and the directions that properly reflect the AVCs intention. - -###### 2.9.2.4.0 - -ADs can give AVCs feedback on how they will interpret different drafts of the AVC Governance Strategies, and the AVCs can then use that to fine tune the result they want to get. +### 2.9: Interaction of Aligned Delegates, FacilitatorDAOs, and Advisory Council - GOV9​​​​​​​ #### 2.9.3: FacilitatorDAOs and Scope Advisory Councils -A critical governance interaction is AVCs getting professional input from Advisory Council Members about specific improvements that are possible in the Scope Alignment Artifacts. This happens with the FacilitatorDAOs following the instructions defined in the Advisory Council Articles. FacilitatorDAOs can also provide input directly to AVCs. - -##### 2.9.3.1 - -AVCs must ensure that their Aligned Scope Proposals describe in as much detail as possible the kind of advice they consider most important, and how to prioritize it and allocate resources. +A critical governance interaction is ACs getting professional input from Advisory Council Members about specific improvements that are possible in the Scope Alignment Artifacts. This happens with the FacilitatorDAOs following the instructions defined in the Advisory Council Articles. FacilitatorDAOs can also provide input directly to ACs. ##### 2.9.3.2 FacilitatorDAOs follow the instructions in the Advisory Council Articles to propose the onboarding of new Advisory Council Members, and to allocate resources for Advisory Projects to existing Advisory Council Members. -##### 2.9.3.3 - -AVCs must not micromanage the membership of the Advisory Councils, but must define objective requirements that the FacilitatorDAOs can follow to ensure the best and most suitable potential members are proposed for onboarding. - -###### 2.9.3.3.0 - -*There's significant risk of misalignment in how the AVCs choose Advisory Council Members. All relevant Alignment Conservers can reduce this risk by making potential conflicts as transparent as possible and create a culture where conflicts can be openly disclosed, while secrecy is discouraged.* - -##### 2.9.3.4 - -FacilitatorDAOs can directly provide advice to AVCs, but this is restricted to only governance-technical implementation of the intention of the AVCs into a Aligned Scope Proposal, and alignment analysis. - -###### 2.9.3.4.1 - -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 - -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. - -The methodology is relevant when AVCs can identify and formulate areas for improvement in the Scopes, and possibly even potential solutions. Instead of jumping towards a quick fix, the AVCs should instead, if possible, always move slowly and aim to sustainability identify and solve the generalizable underlying challenge rather than just focus on a straightforward one-off fix. This means breaking down and identifying the recurring patterns that point to shortcomings and opportunities for improvement, and then optimizing the Advisory Council Article to ensure that the Facilitators are instructed to find the right Advisory Council Members to perform projects that target the biggest opportunities for improvements. The goal should be that AVCs do not need to actively intervene in the long term when things are generally going well. The specifications of the Advisory Council Article in each Scope should ensure that it automatically improves itself over time and AVCs just have to review and make final adjustments to the Self-Sustainable Continuous Improvement process. - -##### 2.9.4.1 - -As per *2.9.2.1* ADs are expected to support AVCs in translating their intentions and ideas for how to achieve self-sustainable continuous improvement of the Scopes into actionable elements that can be proposed through the Aligned Scope Proposals of the AVCs. - ### 2.10: Core Governance Security - GOV10 GOV10 must cover Governance Security processes for deploying and reviewing executive votes. This must include multiple types of security review and automated tests. @@ -1020,26 +698,6 @@ The Support Scope must have a specialized Advisory Council that is able to propo The Support Scope must have a customized strategy towards its display and interaction through the DAO Toolkit to make it maximally user friendly. -### 3.2: Governance Process Support - SUP2 - -SUP2 must cover the Support Scopes role in ensuring the Maker Governance processes function smoothly and reliably, making governance participation attractive and user friendly. - -#### 3.2.1 - -AVC internal governance process support, including communication channels and internal tools. - -#### 3.2.2 - -Facilitating the support necessary for the quarterly Scope Proposal process to ensure that the Scope Artifacts are reliably improved over time. - -#### 3.2.3 - -Ensuring that all Scope defined processes are monitored and properly covered. - -#### 3.2.4 - -Rules for prioritization of resources in case of scarcity to prevent overload or spam. - ### 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. @@ -1426,10 +1084,6 @@ Prime Delegates receive 60 million NewGovToken per year paid out through the AD Reserve Delegates receive 20 million NewGovToken per year paid out through the AD PDMs. -###### 4.3.11.2.5: 20 million NewGovToken to Aligned Voter Committees - -Aligned Voter Committee Members with the highest number of verified NewGovTokens receive 20 million NewGovToken per year paid out through the AVC Module system. - #### 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. @@ -1505,6 +1159,7 @@ The Genesis emissions of Facilitators are 4.6 billion tokens over 10 years, with ###### 4.3.13.2.1.1 For the first 2 years, the rate of Genesis farming is 1 billion FacilitatorDAO tokens per year + ###### 4.3.13.2.1.2 For the following 2 years, the rate of Genesis farming is 500 million FacilitatorDAO tokens per year. @@ -1521,270 +1176,6 @@ For the final 4 years, the rate of Genesis farming is 125 million FacilitatorDAO The workforce bonus pool starts with 600 million FacilitatorDAO tokens. The Workforce bonus pool can be further topped up through the permanent emissions. -##### 4.3.13.3: FacilitatorDAO Permanent Emissions - -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 - -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% of the total supply is emitted per year as farming 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. - -#### 4.3.14: MiniDAO Emissions - -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 - -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 - -The Genesis emissions of MiniDAOs are 1.84 billion tokens over 10 years, with the following breakdown. - -###### 4.3.14.2.1: Genesis Farming Emissions - -1.6 billion MiniDAO tokens are for Genesis farming. - -###### 4.3.14.2.1.1 - -For the first 2 years, the rate of Genesis farming is 400 million MiniDAO tokens per year - -###### 4.3.14.2.1.2 - -For the following 2 years, the rate of Genesis farming is 200 million MiniDAO tokens per year. - -###### 4.3.14.2.1.3 - -For the following 2 years, the rate of Genesis farming is 100 million MiniDAO tokens per year. - -###### 4.3.14.2.1.4 - -For the final 4 years, the rate of Genesis farming is 50 million MiniDAO tokens per year. - -###### 4.3.14.2.2 - -The workforce bonus pool starts with 240 million MiniDAO tokens. The Workforce bonus pool can be further topped up through the 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 - -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 - -6.5% of the total supply is emitted per year as farming 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. - -#### 4.3.15: Elixirs - -Elixirs are 50/50 LP tokens of the native AMM engine on NewChain. They have a prominent role in the Neural Tokenomics. - -##### 4.3.15.1: Maker Elixir - -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. - -##### 4.3.15.2: FacilitatorDAO Elixir - -FacilitatorDAO Elixir is an LP token of 50/50 FAC/MKR - -It is held by FacilitatorDAO Dendrites. - -##### 4.3.15.3: AllocatorDAO Elixir - -AllocatorDAO Elixir is an LP token of 50/50 ALL/MKR - -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. - -It is held by MiniDAO Dendrites. - -#### 4.3.16: Axons - -Axons are modules of the Neural Tokenomics that distribute tokens of a parent DAO to its SubDAOs, split based on the SubDAO holdings of the parent's Elixir. - -##### 4.3.16.1: AllocatorDAO Axon - -The AllocatorDAO Axon receives a total of 460 million NewGovToken per year that it splits across all active AllocatorDAOs proportional to their Maker Elixir holdings and sends to their AllocatorDAO Dendrite. - -##### 4.3.16.2: FacilitatorDAO Axon - -The FacilitatorDAO Axon receives a total of 120 million NewGovToken per year that it splits across all active FacilitatorDAOs proportional to their Maker Elixir holdings and sends to their FacilitatorDAO Dendrite. - -##### 4.3.16.3: MiniDAO Axon - -The MiniDAO Axon of an AllocatorDAO receives a total of 5% of the AllocatorDAO tokens per year that it splits across all active MiniDAOs proportional to their AllocatorDAO Elixir holdings and sends to their MiniDAO Dendrite. - -#### 4.3.17: Dendrites - -Dendrites are modules of the Neural Tokenomics that receive incoming tokens from a parent DAO and converts it either to its own Elixir or to the parent's Elixir, based on an Economic Resilience Model determined by the Stability Scope. Dendrites work identically for all types of SubDAOs. - -##### 4.3.17.1: Economic Resilience Switch - -The Economic Resilience Switch receives the incoming Parent DAO tokens, and at a regular pulse interval, sends the tokens onwards after checking the price of the SubDAOs token compared with the Economic Resilience Model. - -##### 4.3.17.2: Native Elixir Accumulator - -If the price of the SubDAO token is lower, then the parent DAO tokens are sent to immediately accumulate the SubDAOs native Elixir. Once accumulated in the Dendrite the native Elixir tokens can never leave. - -##### 4.3.17.3: Reverse Burn Engine - -If the price of the SubDAO token is higher, the parent DAO tokens are sent to the Dendrites Reverse Burn Engine. The Reverse Burn Engine converts the parent DAO tokens into the parent DAO Elixir if the parent DAO token price is above the parent DAO Economic Resilience Model, and the rate of conversion depends on the gap between the price and the ERM. The obtained Parent Elixir is sent to the Parent Elixir Burn Engine. - -When new Major SubDAOs are incubated, the Incubator Reverse Burn Engine may still have leftover NewGovToken. The leftover NewGovToken is then transferred directly to the Dendrite Reverse Burn Engine of the SubDAO. - -##### 4.3.17.4: Parent Elixir Burn Engine - -Parent Elixir accumulated in the Dendrite’s Parent Elixir Burn Engine is a central element of the Neural Tokenomics. It is slowly used to burn SubDAO tokens, and also determines the distribution of tokens from its parent’s Axon. - -The parent Elixir Burn Engine receives Elixir from multiple sources. - -###### 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. - -###### 4.3.17.4.2 - -All Maker Elixir accumulated in the Incubator is sent to the newly intubated SubDAOs Parent Elixir Burn Engine. - -###### 4.3.17.4.3 - -SubDAOs can at any time use assets from their treasury to buy more Parent Elixir. This is the only method a SubDAO has of returning value from their assets to their own token holders - -###### 4.3.17.4.3.1 - -Enforcing the exclusivity of parent Elixir accumulation as the only way for a SubDAO to return value to its token holders is a core assumption of the economic resilience of the Neural Tokenomics. The relevant Scopes must describe detailed processes and principles for detecting attempts to circumvent the requirement of parent Elixir accumulation being the only permitted way of returning value to token holders, as this is a severe risk of misalignment. - -###### 4.3.17.4.4 - -If the total market cap of the SubDAO token is less than the total value of the contents of the parent Elixir Burn Engine, the Parent Elixir Burn Engine begins to use its Elixir contents to buy and burn the SubDAO token at a fixed rate of 0.5% of its contents per month. - -#### 4.3.19: The Budget System - -The Budget System is a protocol module that enables token holders to set up budgets associated with Scopes, based on the specifications in the relevant Scope. The budgets that can both be controlled manually by the token holders through executive votes, but also can be accessed by FacilitatorDAOs that have been assigned FacilitatorDAO Responsibility to the Scope that covers the budget, and the FacilitatorDAO is able to delegate access to the budget to smart contracts that can in turn be controlled by Facilitators and be given specific restrictions and security measures. - -##### 4.3.19.1 - -When multiple FacilitatorDAOs have assigned Responsibility for the same Scope, their control of its fixed budgets are split in half. Additionally, each FacilitatorDAOs budget access can be increased through the Budget Allocation System, which will increase the accessible budget only for the specific FacilitatorDAO that is receiving Allocated Budget. - -#### 4.3.20: FacilitatorDAO Responsibility System - -The FacilitatorDAO Responsibility System is a module that lets MKR holders assign Responsibility for specific Scopes and its associated budgets. The weight of the Scope and the size of the budgets determine the rewards earned by the FacilitatorDAO from the FacilitatorDAO Responsibility Rewards. - -#### 4.3.21: Budget Allocation System - -The Budget Allocation System is a mechanism that can be turned on and off by Maker Governance or SubDAO governance. It allows Maker to set an Allocated Budget, which can be either fixed or relative to the average income of the system. It is a flexible system that allows Budget Allocators to flexibly and quickly distribute budgets to specific FacilitatorDAOs that have good performance or are doing things that are strategically or tactically important. - -##### 4.3.21.1: Budget Allocator Module - -The Budget Allocator Module is a protocol module that can be created by a Budget Allocator. FacilitatorDAOs can recognize the Budget Allocator as an Aligned Budget Allocator and activate their Budget Allocator Module as an Aligned Budget Allocator-Budget Allocator Module, which gives the Budget Allocator a fee of all Budget they control. - -##### 4.3.21.2: Budget Power Assignment - -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 - -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 - -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. - -##### 4.4.1.1 - -The Validators have the ability to send funds out of the bridge, and to confirm reception of incoming funds on NewChain. - -##### 4.4.1.2 - -The Validators have the ability to modify the Validator Set, and must use this power to update it based on the latest stake weightings on NewChain. - -##### 4.4.1.3 - -The Validators have the ability to update the Fallback Multisig, and must use this power to follow the instructions of the Maker Governance based on *4.4.3.1*. - -##### 4.4.1.4 - -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: 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. - -##### 4.4.2.1 - -When using the Trigger Mechanism, the MKR holders become vulnerable to slashing in case they abuse the power to attack the system with no legitimate reason. - -#### 4.4.3: The Fallback Multisig - -The Fallback Multisig is a simple multisig consisting of DAOs with fully decentralized and mature governance on the target blockchain, and physical Arranged Structures separate from those that interact with Legal Recourse Assets. - -##### 4.4.3.1 - -PRO4 must specify a process for researching, monitoring and developing the best strategies for keeping the bridge and its fallback multisig secure, including monitoring physical or misalignment risks. The output of this process is used to direct the Bridge Validators when and how to modify the Fallback Multisig. - -##### 4.4.3.2 - -Depending on the situation that led to the Fall Multisig taking control of the Bridge, it can either restart the bridge by returning control to the Validator Set, Define a new Validator set according to the specifications of PRO4 and hand over control to it, or it can manually settle the assets contained in the bridge in case of complete and irreversible failure of the Maker Ecosystem. - -#### 4.4.4 - -PRO4 must specify processes for actively monitoring, maintaining and upgrading the active Two-Stage Bridge implementations. - -#### 4.4.5 - -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 - -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. - -#### 4.5.1 - -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 - -NewChain can be halted, which stops the blockchain entirely, requiring a hard fork to restart it. - -#### 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. - -#### 4.6.2 - -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 - -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 - -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. - -### 4.8: The Dai Stablecoin - PRO8 - -The Dai Stablecoin is a native implementation on NewChain that must always remain permissionless. It cannot contain any blacklisting functionality or otherwise prevent users from using it, and Dai Stablecoin assets cannot be seized or frozen, even through a hard fork of NewChain. PRO8 must specify processes that research and monitor risks of misalignment with these requirements. - ### 4.9: Scope Bootstrapping - PRO9 Before NewChain launch the Protocol Scope must be adapted to accommodate the bootstrapping of the ecosystem. This allows parts of the Atlas to be temporarily overridden when needed to ensure a smooth launch and bootstrapping phase. This ends with the launch of NewChain. @@ -1805,26 +1196,10 @@ 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 - -The Dai Stablecoin is stable relative to a reference asset. - -#### 5.2.1 - -The Dai Stablecoin must have predictable stability relative to a suitable reference asset, which can be a widely adopted world currency or a diversified basket representing the cost of goods or other relevant metrics of stability and utility as a currency. STA2 must specify processes relevant for monitoring and ensuring this requirement is fulfilled. - -#### 5.2.2 - -Any change to the reference asset of Dai by Maker Governance must be done to protect the value of the users and be carried out in a way that minimizes harm and maximizes stability and reliability for the Maker Ecosystem. STA2 must specify processes for doing this in the safest and most secure possible way. - ### 5.3: Core Stability Parameters - STA3 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: The Base Rate - -The Base Rate is the base yearly increase in debt on Allocator Vaults and Lockstake Engine Vaults. The Base Rate is determined algorithmically based on the Dai Price Oracle and the Price Deviation Sensitivity algorithm. - #### 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. @@ -1833,33 +1208,13 @@ The Dai Savings Rate is the rate Dai holders can earn on their Dai in the Dai Sa 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: 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. - -### 5.4: Allocator Vaults - STA4 - -Allocator Vaults are native protocol modules that all Allocators are incubated with. The allocator can use them to generate Dai, by accruing debt that increases over time at the Base Rate. The Dai can be used for specific purposes defined by the Stability Scope, with some restrictions encoded directly into the Allocator Vaults, while most of the restrictions are enforced by Maker Governance. +### 5.5: Real World Assets - STA5 -#### 5.4.1: Allocator Vault Standard Valve - -For standard operations that aren’t otherwise specifically defined in STA4, the Allocator Vaults have a maximum Valve Rate, meaning amount of Dai that can be generated per time interval. The Valve Rate is an adjustable parameter determined by Maker Governance based on a process specified in STA4. - -#### 5.4.2: Allocator Vault Special Valves - -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: Funnel Modules - -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. +Real World 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: 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. +Arranged Structures are special legal structures set up by Ecosystem Actors to secure Real World 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. ##### 5.5.1.1 @@ -1873,78 +1228,6 @@ 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: 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. - -### 5.6: AllocatorDAO Junior Capital - STA6 - -AllocatorDAOs depend on having Junior Capital to use most of the functionality of their Allocator Vaults. Their Effective Junior Capital is determined based on processes that must be specified in STA6. - -#### 5.6.1 - -The AllocatorDAO Surplus Buffer counts as Junior Capital. - -#### 5.6.2 - -The AllocatorDAO Maker Elixir Pool counts as Junior Capital, with a modifier determined by STA6. - -#### 5.6.3 - -Additional reserves held by the AllocatorDAO can also count as Junior Capital, this must be specified in STA6. - -#### 5.6.4 - -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 - -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. - -#### 5.7.1: Capitalization Requirements - -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 - -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 - -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 - -STA7 must specify a model of Capitalization Requirements based on physical concentration risk. - -#### 5.7.2: Market Requirements - -AllocatorDAOs are required to use funds generated from their AllocatorDAO vault to perform certain market actions. - -##### 5.7.2.1: Required Minimum Liquidity Provision - -AllocatorDAOs are required to use a fraction of their asset portfolio to market make Dai at specific spreads, provide Dai liquidity, or have a specific amount of low duration assets available on short notice. STA7 must specify the conditions for this to ensure it maximizes the Stability and Efficiency of Dai. Failure to follow these requirements result in penalties. - -##### 5.7.2.2: Dai Price Deviation Reaction Requirement - -If Dai is undervalued or overvalued, AllocatorDAOs are required to use a portion of their assets to acquire Dai and correct the price deviation, specified by STA7. If an AllocatorDAO uses less than the required amount of assets, it is penalized according to STA8. - -### 5.8: Allocator Penalties - STA8 - -AllocatorDAOs can suffer penalties for different reasons that must be managed and specified by STA8. - -#### 5.8.1: Penalty Rates - -Penalty Rates are the most common form of penalties that AllocatorDAOs can get. It is acceptable for an AllocatorDAO to deliberately take actions that accrue some penalty rates for technical or practical reasons, as long as they quickly return to proper capitalization requirements. This must be clearly specified in STA8. - -#### 5.8.2: Forced Dilution - -If an AllocatorDAO becomes severely undercapitalized, or doesn’t return to proper capitalization within a timeframe, as specified in STA8, Stability FacilitatorDAOs must activate Forced Dilution of the AllocatorDAO. Forced Dilution causes the AllocatorDAO to emit tokens at a high rate that are sold to accumulate Maker Elixir. - -#### 5.8.3: Forced Liquidation - -If an AllocatorDAO remains undercapitalized after having Forced Dilution activated, the Stability FacilitatorDAOs must directly liquidate their assets to bring them back to proper capitalization. This also results in an additional severe liquidation penalty for the AllocatorDAO. STA8 must specify a secure process for Forced Liquidation. - ### 5.9: Surplus Buffer and Smart Burn Engine - STA9 STA9 must cover the processes for setting various economic parameters related to Maker Protocol Surplus. @@ -1953,30 +1236,6 @@ STA9 must cover the processes for setting various economic parameters related to The Surplus Buffer Upper Limit determines when the Surplus Buffer sends its funds to the Smart Burn Engine. -#### 5.9.2: Smart Burn Engine Dai Algorithm - -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: 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: 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. - -#### 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: Maker Decentralized Asset Reserve - -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 If the Dai Stablecoin becomes undercollateralized, the Maker Protocol will automatically generate and sell MKR to recapitalize the system. @@ -2001,50 +1260,6 @@ 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 - -The Dai Stablecoin must maintain the ability to shift its collateral assets into decentralized collateral in case of physical threats. - -#### 5.12.1 - -When there is no immediate physical threat the protocol should maximize income in order to accumulate decentralized assets through the Maker Decentralized Asset Reserve - -#### 5.12.2 - -In case of an immediate physical threat, Maker Governance can determine a Legal Recourse Asset penalty parameter that applies an additional penalty rate to all Legal Recourse Assets, in order to encourage an immediate or gradual shift to decentralized collateral backing. STA12 must cover the process for this adequately. - -#### 5.12.3 - -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: Lockstake Engine Dai Generation Risk Parameters - STA13 - -The Lockstake 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: Hard liquidation Ratio - -Hard liquidation Ratio of 200%. At this collateralization level, vaults will be instantly liquidated. - -#### 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. - -#### 5.13.3: Sticky Oracle - -The MKR oracle for the Lockstake Engine Vaults has sticky upwards price movement. It works by operating both on a market price measured from Maker Elixir, and a Sticky Price. The Sticky Price is what is actually used for calculating Liquidation Ratio and Soft Liquidation Ratio. - -Whenever the real price is below the Sticky Price, the Sticky Price instantly adjusts down to be equal to the real price. - -When the real price is above the Sticky Price, the Sticky Price adjusts upwards at a throttled rate of at most 5% per month. - -#### 5.13.4: Debt Ceiling - -The Debt Ceiling of 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 Lockstake Engine while also protecting the stability of the Maker Ecosystem. - -#### 5.13.5: Stability Fee - -The Stability Fee of the Lockstake Engine Vaults is equal to the Base Rate. - ### 5.14: Scope Bootstrapping - STA14 STA14 must cover all necessary measures to ensure the Stability Scope is properly bootstrapped before NewChain is launched and the Endgame State is reached. During the bootstrapping phase other Atlas Articles may be temporarily overridden if necessary for ensuring the success of the bootstrapping, until NewChain is launched. @@ -2079,24 +1294,4 @@ ACC4 must specify principles and processes for managing the accessibility assets ### 6.5: Accessibility Campaigns - ACC5 -ACC5 must specify principles and processes for managing accessibility campaigns. - -### 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 - -The EGFs are the standardized and regulated applications that most users will use to access the 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. - -#### 6.6.1: Design of the Easy Governance Frontend (EGF) - -The EGF must be simple and gamified in order to lower the barrier of meaningful contribution enough to enable MakerDAO to benefit from the wisdom of the crowd of all the incentivized voters that receive the MKR voter incentives, and are expected to have minimal alignment. - -#### 6.6.2: Delegation to Aligned Governance Strategies - -The user experience of the EGF reduces the central governance decision MKR holders have to make down to picking a Delegate and an Aligned Governance Strategy that the Delegate must vote according to. - -#### 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. +ACC5 must specify principles and processes for managing accessibility campaigns. \ No newline at end of file diff --git a/MIP104/MIP104.md b/MIP104/MIP104.md index d7e8ffbc3..af09c5c85 100644 --- a/MIP104/MIP104.md +++ b/MIP104/MIP104.md @@ -209,31 +209,13 @@ Advisory Council project budget: The Stability Scope DAO Toolkit module must be built to give a full and accessible overview of all data and processes relevant to the Stability Scope. -## 2: Dai Stablecoin Reference Asset - -This Article must be strengthened to ensure balanced and appropriate funding of proactive research into future reference assets. - ## 3: Core Stability Parameters -Before the launch of AllocatorDAO Vaults, the Core Stability parameters are fixed to help bootstrap the system. - -### 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. - -#### 3.1.1A - -¤¤¤ - -The Base Rate is: - -- **4.05%** - -¤¤¤ +Before the launch of AllocatorDAO Vaults and development of a new Rate System, all Core and Spark related Stability parameters are defined by the Stability Facilitators through the weekly governance process or out-of-schedule executive votes, based on the advice from the Stability Advisory Council. ### 3.2: The Dai Savings Rate -The Dai Savings Rate is regularly updated to be equal to (Base rate - 0.25%). The up to date Dai Savings Rate is contained in *3.2.1A*. Whenever an update to the Dai Savings Rate occurs, the Stability Facilitators must trigger an executive vote to update the on-chain Dai Savings Rate. +The Dai Savings Rate can be modified through the weekly governance process, or directly through executive votes, by the Stability Facilitators. #### 3.2.1A @@ -241,175 +223,21 @@ The Dai Savings Rate is regularly updated to be equal to (Base rate - 0.25%). Th The Dai Savings Rate is: -- **3.80%** - -¤¤¤ - -#### 3.2.2: Enhanced Dai Savings Rate - -The Enhanced Dai Savings Rate is a system to temporarily increase the effective DSR available to users in the early bootstrapping stage when DSR utilization is low. The EDSR is determined based on the DSR and the DSR utilization rate, under the control of the Stability Facilitators, and decreases over time as the utilization increases, until it eventually disappears when utilization gets high enough, when triggered by the Stability Facilitators. EDSR is a one-time, one-way temporary mechanism, which means that the EDSR can only decrease over time, it cannot increase again even if DSR utilization goes down. - -The Stability Facilitators can take actions related to the EDSR through forum posts signed by their approved Ethereum address. - -Other parameters and mechanisms that are dependent on the DSR, such as Native Vault Engine Collateral Stability Fees (SFs) and the Spark D3M Borrow APY, are affected by the EDSR. - -When NewGovToken and SubDAO farming comes into effect, DSR utilization will count both DSR use and NewGovToken and SubDAO farming use. - -Spark Protocol has a borrow rate spread that follows the Exposure Model methodology (14.3.1.3) and is defined as: - -Spark DAI Effective Borrow APY = Dai Savings Rate (EDSR while active) + Liquidation Ratio Spread + Asset Spread. - -##### 3.2.2.1A: Current EDSR - -¤¤¤ - -The EDSR is currently set to: - -- **13.00%** - -¤¤¤ - -##### 3.2.2.2A - -¤¤¤ - -Spark: - -- `SR` = 0.00% -- `K` = 15.53% -- `Ka` = 0.00% -- `Kb` = 30.00% -- `KFa` = 6.00% -- `KFb` = 34.00% - -¤¤¤ - -##### 3.2.2.3A - -¤¤¤ - -Spark DAI Effective Borrow APY: `Dai Savings Rate (EDSR while active) + Spark LR Spread + Asset Spread` - -¤¤¤ - -##### 3.2.2.4A - -¤¤¤ - -Spark Spread: - -- LR Spread is 0.50% -- Asset Spread is 0.96% +- **10.00%** ¤¤¤ ##### 3.2.2.5 -As long as Spark Protocol remains near its maximum borrow limit, the Stability Facilitators can use the weekly governance cycle to propose to increase its Debt Ceiling to attract more users. If Spark Protocol falls below 200 million active borrowing for an extended period of time, the Stability Facilitators can use the weekly governance cycle to propose a decrease to the borrow rate spread to attempt to incentivize usage to increase above 200 million. - -When NewGovToken and SubDAO farming comes into effect, DSR utilization will count both DSR use and NewGovToken and SubDAO farming use. - -##### 3.2.2.6: EDSR Upper Limit - -The EDSR Upper Limit acts as an effective limit to the EDSR, meaning that it can not exceed it even if the formula outputs a number above the limit. The EDSR Upper Limit can be altered by the Stability Facilitators via the weekly governance cycle. - -##### 3.2.2.6.1A - -¤¤¤ - -EDSR Upper Limit is: - -- 15% - -¤¤¤ - -#### 3.2.2.7: EDSR Utilization-Based Multipliers +As long as Spark Protocol remains near its maximum borrow limit, the Stability Facilitators can use the weekly governance cycle to propose to increase its Debt Ceiling to attract more users. -Each of the following EDSR multiplier tiers can be triggered by the Stability Facilitators 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 for a different tier for a continuous period of more than 24 hours, the Stability Facilitator can choose to trigger the new tier, if doing so is not deemed harmful to user adoption, and a manual DSR adjustment must then be included in the next executive vote to account for the new tier. +## 5: Real World Assets -###### 3.2.2.7.1A: EDSR tier 1 - -¤¤¤ - -Multiplier: 5x DSR - -Utilization: 0-35% - -¤¤¤ - -###### 3.2.2.7.2A: EDSR tier 2 - -¤¤¤ - -Multiplier: 5x DSR - -Utilization: 35-50% - -¤¤¤ - -##### 3.2.2.8 - -EDSR can be ended permanently by the Stability Facilitators once DSR utilization crosses above 50% for a continuous period of more than 24 hours. - -##### 3.2.2.9 - -The Stability Facilitators can at any time use the weekly governance cycle to disable the EDSR permanently, or modify any of its parameters or logic in *3.2.2* or its subelements, if there are indications that it is not cost-effectively achieving its objectives. - -### 3.3: Dai Savings Rate and Base Rate Changes in Demand Shocks - -The Stability Facilitators can use the urgent governance cycle to propose non-standard changes to the Dai Savings Rate and the Base Rate in case of risks to the peg stability of Dai. Once the risks have subsided, the Dai Savings Rate and Base Rate must be reverted to their ordinary values, according to *3.1.1A* and *3.2.1A*. - -### 3.4: Core Stability Parameters Update Frequency - -This element and subelements define the minimum frequency of when they must be updated and implemented in the protocol. All parameters which are derived from the Core Stability Parameters must be updated at the same time, such as Native Vault Engine. Any other element which is more specific to a set of parameters or describes unique instances such as emergencies overrides this element. - -The Core Stability Parameters update is subject to three different conditions defined in the subelements - -#### 3.4.1: Duration Based Condition - -Core Stability Parameters must be updated at a minimum of 2 months since the last spell execution which included previous update in the next available executive spell - -#### 3.4.2: Stability Fee (SF) Change Condition - -Core Stability Parameters and Spark DAI Effective Borrow APY must be updated when the Stability Fee or Spark DAI Effective Borrow APY change is greater than +/-8% in the next available executive spell. - -#### 3.4.3: Stability Scope Language Amendment - -Core Stability Parameters must be updated when the language of the Core Stability Parameters or elements containing definitions and formulas for parameter setting which depend on the Core Stability Parameters are amended in the next available executive spell - -## 4: AllocatorDAO Vaults - -Before the launch of SubDAOs, AllocatorDAO Vaults function in a bootstrapping mode. They are controlled by AllocatorDAO Advisors, which are special Ecosystem Actors with the ability to advise the Stability Facilitators - -### 4.1: AllocatorDAO Vaults Stability Fee - -The AllocatorDAO Vaults have a Stability Fee equal to the Base Rate specified in *3.1.1A*. - -### 4.2: AllocatorDAO Advisors - -The Stability Facilitator can use the weekly governance cycle to propose to onboard AllocatorDAO Advisors and set up a new AllocatorDAO Vault, based on AllocatorDAO Advisor Proposals made on the Maker Forum. The AllocatorDAO Advisor will be tasked with publishing advice related to the use of their AllocatorDAO vault. The current active AllocatorDAO Advisers and their individual Debt Ceiling Limits are specified in *4.2.2A*, and must be updated by the Stability Facilitators when applicable. - -#### 4.2.1 - -The AllocatorDAO Vaults share a total debt ceiling limit equivalent to the Dai Supply, minus all legacy collateral. Each AllocatorDAO Vault has an individual debt ceiling limit of its proportional amount of the total debt ceiling limit. - -#### 4.2.2A - -¤¤¤ - -Current active AllocatorDAO Advisors: - -N/A - -¤¤¤ - -## 5: Legal Recourse Assets - -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. +Real World 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.1: Arrangers -Arrangers are Ecosystem Actors that specialize in sourcing, negotiating, structuring of, and reporting on, Legal Recourse Assets and maintaining and monitoring the underlying Arranged Structures used by the Maker Protocol. They must never be able to operate or influence the arranged legal and operational structure’s asset operations in a way that can cause any significant harm or losses to Dai’s stability, after the structures have been built and assets allocated hereto. Arrangers are approved directly by MKR voters, and all LRA collateral exposure must be structured by an approved Arranger. +Arrangers are Ecosystem Actors that specialize in sourcing, negotiating, structuring of, and reporting on, Real World Assets and maintaining and monitoring the underlying Arranged Structures used by the Maker Protocol. They must never be able to operate or influence the arranged legal and operational structure’s asset operations in a way that can cause any significant harm or losses to Dai’s stability, after the structures have been built and assets allocated hereto. Arrangers are approved directly by MKR voters, and all LRA collateral exposure must be structured by an approved Arranger. #### 5.1.1: Active Arranger Management @@ -426,14 +254,6 @@ List of current active Arrangers: ¤¤¤ -#### 5.1.2: Arranger Standard Fees - -Temporarily, no arranger maximum fees are enforced. - -#### 5.1.3: Arranger Concentration Risk Management - -The Stability Facilitators must take action to search and propose onboarding of additional Arrangers when it is economically feasible to do so, in order to help reduce the concentration risk to individual Arrangers. Strict limits to the amount of assets that each Arranger services for must be developed and implemented in this section over time. - #### 5.1.4: Arranger Reports and Stress Tests Arrangers must publish monthly reporting on each Arranged Structure they have arranged, and must every six months also publish stress test analysis that shows how the structures would perform based on historical financial crisis scenarios and other example scenarios. The Stability Facilitators must periodically fund independent Ecosystem Actors to review and verify the quality and the results of the stress tests. Should an independent review produce an unfavorable result, the Responsible Facilitators must propose a governance poll for warning, temporarily deactivating, or permanently offboarding the Arranger and/or the Asset Managers connected to the discovered issue. @@ -445,7 +265,7 @@ Monthly reports must satisfy *5.1.4.1* or *5.1.4.2* or *5.1.4.3* to be considere The following information should be included in the monthly Arranger report. Each item should be provided for at least the beginning and ending date of the reporting period (the first business day after beginning date and last business day before the ending date may be used if the beginning and ending dates fall on days markets are closed): - Cash balance. -- Cash income over the reporting period. Any income over $20,000 in value should be broken out as its own line item, and an explanation provided for any non-recurring or non-ordinary expensesi. +- Cash income over the reporting period. Any income over $20,000 in value should be broken out as its own line item, and an explanation provided for any non-recurring or non-ordinary expenses. - Cash expenses over the reporting period. Any expense over $20,000 in value should be broken out as its own line item, and an explanation provided for any non-recurring or non-ordinary expenses. - Market value of publicly traded equities, ETFs, and mutual funds. - Market value (the closing price) of publicly traded debt securities. Debt securities that are investment grade and less than 12 months from maturity may alternatively be reported at cost basis + linearly recognizing scheduled interest income. @@ -462,8 +282,11 @@ The Scope Facilitator must publicly state on the MakerDAO forum that they have r The following information should be included in the monthly Arranger report: Copies of original statements for all bank, brokerage, exchange, custodial, or other accounts. The Arranger may redact the names for non-Arranger service providers if and only if that is a requirement of confidentiality agreements with the non-Arranger service providers. + DAI inflows from the Maker protocol during the reporting period. + Total repayments on-chain to the Maker protocol either to a vault or for surplus. If repayments are derived from multiple sources, they should be broken out into line items for each source. + Vault debt to the Maker protocol. ##### 5.1.4.3 @@ -476,22 +299,6 @@ The following information must be provided through public read-only access to al In addition, [Makerburn.com](https://makerburn.com/#/), [Daistats.com](https://daistats.com/#/), or another dashboard must be publicly available to summarize DAI inflows and outflows from the Maker vault. -### 5.2: Legal Recourse Asset Budget - -The Stability Facilitators have a budget available to pay costs related to stress test review, legal research and first time setup of legal structures for arrangers, and other expenses relevant to Legal Recourse Assets. Arrangers that are supported this way must publish all research and conclusions related to the Arranged Structure, to help other arrangers replicate the work and strengthen the Maker Arranger ecosystem. The Legal Recourse Asset Budget is specified in *5.2.1B*. - -#### 5.2.1B - -¤¤¤ - -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. - -¤¤¤ - ### 5.3: Perpetual yield strategies The Stability Facilitators can implement various perpetual yield strategies, including on-chain and off-chain mechanisms, that enable the protocol to take advantage of high risk-adjusted return on perpetual yield strategies in the crypto markets. Exposure targets specified in this section overrides requirements defined by other Articles of the Stability Scope. @@ -540,161 +347,59 @@ Current target exposure of Morpho sUSDe or USDe vault is: 0 The parameters of the Metamorpho vault is managed through the multisig controlled by Facilitator JanSky, and must be managed based on instructions by the Stability Facilitator based on advice by the Stability Advisor. -## 6: AllocatorDAO Effective Junior Capital - -The Stability Facilitators and Stability Advisory Council Members must research and develop a framework for determining adequate multipliers for the different sources of AllocatorDAO Effective Junior Capital. - -## 7: AllocatorDAO Collateral and Market Requirements - -AllocatorDAO Advisory teams are subject to requirements for how they deploy Dai generated from their AllocatorDAO Vault. - -### 7.1: AllocatorDAO Capitalization Requirements - -AllocatorDAOs will have Capitalization Requirements of their Effective Junior Capital based on what kind of exposure they have from their AllocatorDAO Vaults. Before the launch of SubDAOs, AllocatorDAO Advisory Teams can use this framework to deploy collateral that has no Effective Junior Capital Requirement. - -#### 7.1.1: ALM Capitalization Requirements - -##### 7.1.1.1: ALM Tier 1 Collateral - -###### 7.1.1.1.1 - -No slippage is allowed for ALM Tier 1 Collateral. - -###### 7.1.1.1.2 - -ALM Tier 1 Collateral must be able to instantly convert to Cash Stablecoins within 30 minutes with no slippage. - -###### 7.1.1.1.3 - -ALM Tier 1 Collateral or higher can be used for 100% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement. - -###### 7.1.1.1.4 - -There are no additional Effective Junior Capital Requirements. - -##### 7.1.1.2: ALM Tier 2 Collateral - -###### 7.1.1.2.1 - -ALM Tier 2 Collateral must be able to convert to Cash Stablecoins within at most 2 weeks with expected slippage and realized loss of at most 1%. - -###### 7.1.1.2.2 - -ALM Tier 2 Collateral must be able to convert to Cash Stablecoins within at most 6 months with no slippage. - -###### 7.1.1.2.3 - -ALM Tier 2 Collateral or higher can be used for 70% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement. - -###### 7.1.1.2.3.1 - -Temporarily before the launch of SubDAOs, the following ALM requirement overrides conflicting specifications in this Article: The Arranged Structures holding ALM Tier 2 Collateral must have standing instructions to immediately convert to Dai and repay the necessary amount of ALM Tier 2 Collateral to bring total exposure of the Dai Collateral Portfolio to ALM Tier 2 Collateral or higher to 75%, whenever the total exposure of the Dai Collateral Portfolio to collateral of ALM Tier 2 or higher exceeds 80%. The necessary amount that must be converted is split proportionally between all Arranged Structures holding ALM Tier 2 Collateral based on their relative holdings of ALM Tier 2 Collateral. When ALM Tier 2 Collateral falls below 70% of the total Dai Collateral Portfolio, the Arranged Structures may use Dai to increase exposure to US Treasuries, until it brings the total exposure of the Dai Collateral Portfolio to 70%. +## 7: Collateral Portfolio -###### 7.1.1.2.4 +### 7.1: Stablecoin collateral -If the exposure limit is exceeded, the excess ALM Tier 2 Collateral has an additional 5% Effective Junior Capital Requirement. +MakerDAO must maintain a reserve of at least 20% of the total Dai and NewStable Supply held as Cash Stablecoins, or assets and exposure that can rapidly be converted to Cash Stablecoins. -###### 7.1.1.2.5 +#### 7.1.1: USDC PSM and Coinbase Custody -Crypto-collateral counts as ALM Tier 2 Collateral, and Debt Ceilings for Crypto Collateral cannot increase if it would cause an overexposure to ALM Tier 2 Collateral. Additionally, if ALM Tier 2 Collateral is overexposed, the Stability Facilitators may choose to use the weekly cycle to propose extraordinary increases in Stability Fees to crypto-collateral in order to incentivize the exposure to go below the permitted amount of ALM Tier 2 Collateral. Perpetuals exposure counts as ALM Tier 2 Collateral, but exposure can exceed the ALM Tier 2 requirements if specified so by the Stability Facilitator. +Whenever the total amount of USDC in the PSM, plus the total amount of USDC in GUNI pools falls below 400 million, USDC must be transferred from Coinbase Custody to the PSM to bring the total amount of USDC in the PSM, plus the total amount of USDC in the GUNI pools, to 550m USDC. Whenever the total amount of USDC in the PSM, plus the total amount of USDC in GUNI pools exceeds 700 million, USDC must be transferred from the PSM to Coinbase Custody to bring the total amount of USDC in the PSM, plus the total amount of USDC in the GUNI pools, to 550m USDC. This mechanism can be fully replaced with an upgraded PSM that obsoletes the Coinbase Custody solution. The Stability Facilitator can directly trigger an executive vote to implement an upgraded PSM. -##### 7.1.1.3: ALM Tier 3 Collateral +#### 7.1.2: Cash Stablecoin Definition -###### 7.1.1.3.1 +A Cash Stablecoin is a stablecoin listed in *7.1.2A* 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.1.2A* through the weekly cycle to react to changing market conditions, opportunities or risks. This can include adding or removing Cash Stablecoins, or changing the terms of existing Cash Stablecoins on the list. -No slippage is allowed for ALM Tier 3 Collateral. +#### 7.1.2A: List of Cash Stablecoins -###### 7.1.1.3.2 - -ALM Tier 3 Collateral must be able to convert to Cash Stablecoins within at most 12 months with no slippage. - -###### 7.1.1.3.3 - -ALM Tier 3 Collateral or higher can be used for 45% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement. - -###### 7.1.1.3.4 - -If the exposure limit is exceeded, the excess ALM Tier 3 Collateral has an additional 10% Effective Junior Capital Requirement. - -##### 7.1.1.4: ALM Tier 4 Collateral - -###### 7.1.1.4.1 - -No slippage is allowed for ALM Tier 4 Collateral. - -###### 7.1.1.4.2 - -ALM Tier 4 Collateral must be able to convert to Cash Stablecoins within at most 3 years with no slippage. - -###### 7.1.1.4.3 - -ALM Tier 4 Collateral or higher can be used for 10% of the AllocatorDAOs collateral portfolio with no Effective Junior Capital requirement. - -###### 7.1.1.4.4 - -If the exposure limit is exceeded, the excess ALM Tier 4 Collateral has an additional 20% Effective Junior Capital Requirement. - -#### 7.1.2: Risk Capitalization Requirements - -##### 7.1.2.1: Risk Tier 1 - -Risk tier 1 assets have no Effective Junior Capital Requirement. Approved Risk Tier 1 Collateral are specified in the subelements of this element. - -###### 7.1.2.1.1 - -US Government Treasury Bonds, Notes and Bills. - -###### 7.1.2.1.2 - -Money Market Instruments defined as investment-grade, highly liquid, short-term debt instruments that can be exchanged for cash within 5 business days. Allowed Money Market instrument types include: term certificates of deposit, interbank loans, money market funds/ETF, commercial paper, Treasury bills, and securities lending and repurchase agreements (“repos”). - -###### 7.1.2.1.3 - -Overcollateralized ETH and Staked ETH vaults with at least 125% collateral ratio and automated liquidations. - -###### 7.1.2.1.4 - -Overcollateralized major crypto asset vaults with at least 150% collateral ratio and automated liquidations. - -###### 7.1.2.1.5 - -Cash Stablecoins. +¤¤¤ -### 7.2: AllocatorDAO Market Requirements +List of Cash Stablecoins: -AllocatorDAOs are required to take specific market actions or be penalized. AllocatorDAO Advisor teams must follow these instructions to the best of their ability. +- USDC and USDC in Coinbase Custody -#### 7.2.1: Cash Stablecoin Liquidity Requirements +¤¤¤ -##### 7.2.1.1: Cash Stablecoin Reserve Requirements +#### 7.1.3: Cash Stablecoin Peg Stability Module Upgrades -AllocatorDAOs must have a reserve of Cash Stablecoins of at least 20% of their total portfolio. +The mechanism for holding and making Cash Stablecoins available to support the liquidity of Dai can be upgraded to a superior technical, financial or legal solution by a proposal from the Stability Facilitators through the weekly cycle. -##### 7.2.1.2: Cash Stablecoin Market Making Requirements +AllocatorDAO Advisory teams are subject to requirements for how they deploy Dai generated from their AllocatorDAO Vault. -MakerDAO must maintain a reserve of at least 20% of the total Dai Supply held as Cash Stablecoins, or assets and exposure that can rapidly be converted to Cash Stablecoins. Whenever the total amount of USDC in the PSM, plus the total amount of USDC in GUNI pools falls below 400 million, USDC must be transferred from Coinbase Custody to the PSM to bring the total amount of USDC in the PSM, plus the total amount of USDC in the GUNI pools, to 550m USDC. Whenever the total amount of USDC in the PSM, plus the total amount of USDC in GUNI pools exceeds 700 million, USDC must be transferred from the PSM to Coinbase Custody to bring the total amount of USDC in the PSM, plus the total amount of USDC in the GUNI pools, to 550m USDC. This mechanism can be fully replaced with an upgraded PSM that obsoletes the Coinbase Custody solution. The Stability Facilitator can directly trigger an executive vote to implement an upgraded PSM. +#### 7.2: Asset Liability Management -##### 7.2.1.3: Cash Stablecoin Definition +To ensure adequate liquidity, Cash Stablecoins are managed through a simple ALM framework that allocates excess Cash Stablecoins into low-risk RWA assets, and draw on these assets to replenish the Cash Stablecoins when they fall too low. -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. This can include adding or removing Cash Stablecoins, or changing the terms of existing Cash Stablecoins on the list. +#### 7.2.1: Excess Cash Stablecoins -###### 7.2.1.3.1A +If the Dai Collateral portfolio contains more than 30% of Cash Stablecoins as defined above, then any Cash Stablecoins above the 30% mark must be allocated towards the collateral defined in *7.2.3* -¤¤¤ +##### 7.2.2: Lack of Cash Stablecoins -List of Cash Stablecoins: +If the Dai Collateral portfolio contains less than 20% Cash Stablecoins, the assets defined in *7.2.3* must be sold off to return the Cash Stablecoin exposure to 25%. -- USDC and USDC in Coinbase Custody +##### 7.2.3: Low Risk RWA -¤¤¤ +Clydesdale and Andromeda are two RWA Arranged Structures that can allocate capital into Low-Risk RWA (LRR), safe, short term treasury strategies of less than 1 year duration. Whenever excess Cash Stablecoins must be allocated into LRR, or whenever LRR must be sold to replenish Cash Stablecoins, the amounts allocated or sold are split equally among the two RWA Arranged Structures. As a result, the two RWA Arranged Structures should generally always track the same amount of exposure into LRR, although short term discrepancies for operational reasons are acceptable. -###### 7.2.1.3.2: Cash Stablecoin Peg Stability Module Upgrades +##### 7.2.4: Optimizations -The mechanism for holding and making Cash Stablecoins available to support the liquidity of Dai can be upgraded to a superior technical, financial or legal solution by a proposal from the Stability Facilitators through the weekly cycle. +The Stability Facilitators can use the weekly governance cycle to modify the Asset Liability Management approach in order to make it more efficient, or more resilient. This involves changing any of the logic defined in *7.2*. -## 8: AllocatorDAO Penalties +#### 7.3: Legacy RWA -The Stability Facilitators and Stability Advisory Council Members must research a framework for applying penalties to AllocatorDAOs in alignment with ATL5.8. +Old RWA exposure that was added before Endgame must stay for as long as necessary, and optimized for yield if possible. When it is possible the Stability Facilitators should take action to wind down and offboard all Legacy RWA. Governance actions related to optimizations, wind down and offboardings can be done directly in executive votes with no prior poll needed. ## 9: Surplus Buffer and Smart Burn Engine @@ -710,9 +415,7 @@ The Surplus Buffer Upper Limit determines the amount of Dai necessary for the Sm ¤¤¤ -The Surplus Buffer Upper Limit is: - -50 million Dai +The Surplus Buffer Upper Limit is: 55 million Dai ¤¤¤ @@ -746,15 +449,13 @@ DssFlapper is the current implementation of contract which processes Smart Burn Determines maximum allowed frequency of transactions taking place. -Maximum `hop` must be set to equal the approximate Effective Rate of MKR Accumulation defined in 9.1 depending on the corresponding configuration of `bump` parameter. +Maximum `hop` must be set to equal the approximate Effective Rate of MKR Accumulation defined in *9.1* depending on the corresponding configuration of `bump` parameter. ##### 9.1.3.1A ¤¤¤ -The `hop` parameter is: - -11,826 +The `hop` parameter is: 11,826 ¤¤¤ @@ -792,9 +493,7 @@ The `bump` parameter is: 75,000 ¤¤¤ -The `pip` parameter is: - -0xdbBe5e9B1dAa91430cF0772fCEbe53F6c6f137DF +The `pip` parameter is: 0xdbBe5e9B1dAa91430cF0772fCEbe53F6c6f137DF ¤¤¤ @@ -828,72 +527,19 @@ The Stability Facilitators and Stability Advisory Councils must develop adequate The MKR Backstop is temporarily limitless. -## 12: Dai Stablecoin Decentralization - -AllocatorDAOs must be subsidized to ensure they have an incentive to allocate collateral to decentralized assets. - -### 12.1: AllocatorDAO Decentralized Collateral Rebate - -A Decentralized Collateral Rebate must be implemented if the Maker Community deems it necessary to protect the resilience of Dai. +## 13: Lockstake Engine Dai Generation Risk Parameters -## 13: Sagittarius Engine Dai Generation Risk Parameters - -The Stability Facilitators must research how to set the adjustable risk parameters of the Sagittarius Engine Vaults. +The Stability Facilitators must research how to set the adjustable risk parameters of the Sagittarius Engine Vaults. The Lockstake Engine and its NewStable Generation Risk Parameters can be implemented using the weekly governance cycle. ## 14: Scope Bootstrapping During the bootstrapping phase, the Stability Scope is modified to override the Atlas requirements in some places. -### 14.1: Yield Benchmarks - -#### 14.1.1 - -The Stability Collateral Yield Benchmark is contained in *14.1.1.1A* and is approximately based on the average yield earned on all Cash Stablecoins. The Stability Facilitators must periodically update the number by computing the latest value and modify relevant on-chain parameters through an executive vote when it is relevant. - -##### 14.1.1.1A - -¤¤¤ - -The Stability Collateral Benchmark Yield is: - -- **0.87%** - -¤¤¤ - -#### 14.1.2 - -The Yield Collateral Yield Benchmark is contained in *14.1.2.1A* and is approximately based on the 3-month US Government Treasury Bill. The Stability Facilitators must periodically update the number by computing the latest value and modify relevant on-chain parameters through an executive vote when it is relevant. - -##### 14.1.2.1A - -¤¤¤ - -The Yield Collateral Benchmark Yield is: - -- **5.45%** - -¤¤¤ - -### 14.2: Protector Advisors - -Before the AllocatorDAO Vault system is ready, Protector Advisors help advise the Stability Facilitators on deploying vaults and modifying risk parameters for Legal Recourse Assets in alignment with the spirit of the articles of the Stability Scope Artifact. The Stability Facilitators can trigger a weekly governance poll to onboard or offboard Protector Advisors. The active Protector Advisors are specified in *14.2.1A*. - -#### 14.2.1A - -¤¤¤ - -List of active Protector Advisors: - -- Spring -- Viridian - -¤¤¤ - ### 14.3: Native Vault Engine The Native Vault Engine is controlled by Maker Core temporarily, and will be upgraded to support SubDAO ownership and transferred to the first AllocatorDAO incubated from the Incubator when NewChain launches. While it is under the control of Maker Core it will have a limited set of collateral types and risk parameters that the Stability Facilitators must implement according to the following subelements. -If not otherwise specified, The Stability Facilitators have the ability to trigger an executive vote to update any of the parameters defined in article “14.3.1: Native Vault Engine Parameter Definitions” for any of the Vault Types contained in article “14.3.2: Maker Core Vault Types”. +If not otherwise specified, The Stability Facilitators have the ability to trigger an executive vote to update any of the parameters defined in article “14.3.1: Native Vault Engine Parameter Definitions” for any of the Vault Types contained in article *14.3.2: Maker Core Vault Types*. #### 14.3.1: Native Vault Engine Parameter Definitions @@ -907,47 +553,9 @@ The Debt Ceiling Limit is numerically provided and acts as an upper limit. The S ##### 14.3.1.3: Stability Fee (SF) -The SF parameter is an annual percentage fee charged on the DAI generated on Vaults. It is expressed as an annual percentage yield but it is charged on a per-block basis in DAI. The DAI from this fee is minted, added to the DAI debt for the vault, and then transferred into the Surplus Buffer which is under the control of Maker Governance. Each vault type has its own Stability Fee that can be adjusted by the Stability Facilitators.The Stability Facilitators must regularly update Vault Type’s Stability Fee according to the following subelements. Stability Fee is determined through an exposure based model which slightly differs between vault types and Effective Spark APY Borrow Rate. The model works as follows: +The SF parameter is an annual percentage fee charged on the DAI generated on Vaults. It is expressed as an annual percentage yield but it is charged on a per-block basis in DAI. The DAI from this fee is minted, added to the DAI debt for the vault, and then transferred into the Surplus Buffer which is under the control of Maker Governance. Each vault type has its own Stability Fee that can be adjusted by the Stability Facilitators.The Stability Facilitators must regularly update Vault Type’s Stability Fee according to the following subelements. -`Stability Fee = Initial Rate + Liquidation Ratio Spread + Exposure Spread + Asset Spread` - -Initial Rate is defined as the rate on top of which additional spreads are layered and is equal to Dai Savings Rate (EDSR while active) for Native Vault types and Yield Collateral Yield Benchmark for Non-Native vault types. If the Yield Collateral Yield Benchmark is lower than the Dai Savings Rate (EDSR while active), then the Initial Rate in the Stability Fee formula for Non-Native Vault Types is changed from Yield Collateral Yield Benchmark to the Dai Savings Rate (EDSR while active). - -Liquation Ratio Spread is defined based on specified Liquidation Ratios of vault types which are divided into three tiers, namely normal (0.25%), low (0.00%), and high (0.75%). - -Exposure Spread (ES) represents the total exposure as percentage of total DAI minted of a specific core asset and is currently used for ETH (calculated by summing up ETH and wstETH) and WBTC vault types. It is a piecewise function calculated as: - -`ES = SR+(K-Ka)*KFa*H(K-Ka)*[1-H(K-Kb)] + [(Kb-Ka)*KFa+(K-Kb)*KFb]*H(K-Kb)` - -With Parameters: - -- `SR` equal to a starting rate -- `K` equal to the Current %Exposure (rounded to two decimal places) -- `Ka` equal to the First Kink -- `Kb` equal to the Second Kink -- `KFa` equal to the Linear increase after the First Kink -- `KFb` equal to the Linear increase after the Second Kink - -1. When 0% ≤ `K` < `Ka`, both `H(K - Ka)` and `H(K - Kb)` are 0, so the equation reduces to `ES= SR`. -2. When `Ka` ≤ `K` < `Kb`, `H(K - Ka)` is 1 and `H(K - Kb)` is 0, so the equation becomes `ES = SR + (K - Ka) * KFa`. -3. When `Kb` ≤ `K` ≤ 100%, both `H(K - Ka)` and `H(K - Kb)` are 1, so the equation becomes `ES = SR + (Kb - Ka) × KFa + (K - Kb) x KFb`. - -Asset spread (`AS`) represents individual asset exposure as percentage of total DAI minted and is currently used for Liquid Staking Tokens (WSTETH-A, WSTETH-B) and to calculate the Spark DAI Borrow Effective APY. It is a piecewise function calculated as: - -`AS = SR+(K-Ka)*KFa*H(K-Ka)*[1-H(K-Kb)] + [(Kb-Ka)*KFa+(K-Kb)*KFb]*H(K-Kb)` - -With Parameters: - -- `SR` equal to a starting rate -- `K` equal to the Current %Exposure (rounded to two decimal places) -- `Ka` equal to the First Kink -- `Kb` equal to the Second Kink -- `KFa` equal to the Linear increase after the First Kink -- `KFb` equal to the Linear increase after the Second Kink - -1. When 0% ≤ `K` < `Ka`, both `H(K - Ka)` and `H(K - Kb)` are 0, so the equation reduces to `AS = SR`. -2. When `Ka` ≤ `K` < `Kb`, `H(K - Ka)` is 1 and `H(K - Kb)` is 0, so the equation becomes `AS = SR + (K - Ka) * KFa`. -3. When `Kb` ≤ `K` ≤ 100%, both `H(K - Ka)` and `H(K - Kb)` are 1, so the equation becomes `AS = SR + (Kb - Ka) * KFa + (K − Kb) * KFb`. +The Stability Advisory Council must develop a Rate System for defining various rates in the system, including Core Crypto vaults and future AllocatorDAOs lending engines minimum rate. It must be based on external benchmarks; the risk free rate and currently highest sustainable rate in crypto financial markets, which act as the lowest and highest base rate on which various additional spreads can be attached in order to better reflect the risks involved with the specific lending facility. The Rate System must be dynamic, based on the state of Cash Stablecoins in the system and naturally move the state towards the target Cash Stablecoins defined in *7.2*. ###### 14.3.1.3.1A @@ -1328,7 +936,3 @@ WBTC-A, WBTC-B and WBTC-C are defined in *14.3* only for the purpose of Stabilit #### 14.3.5 All other collateral types must be offboarded when the Stability Facilitators considers it appropriate, and when there are new mechanisms in place that can take over the role the offboarded collateral covered. - -### 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. diff --git a/MIP106/MIP106.md b/MIP106/MIP106.md index d158eb55c..8d6d9b3cc 100644 --- a/MIP106/MIP106.md +++ b/MIP106/MIP106.md @@ -168,7 +168,7 @@ The current approved Governance Advisory Council Members are recorded in *1.1.1. Current list of Advisory Council Members: -* N/A +- N/A ¤¤¤ @@ -280,44 +280,12 @@ The Support Facilitators and Advisory Council Members must develop ways to displ ### 2.1: Governance Process Definition -Maker Governance uses various core governance processes to manage its core decision making processes, including the Endgame MIP process, AVC and Scope Framework modification processes, and AVC and Delegate processes. The Support Scope is only responsible for facilitating routine processes that clearly follow the rules and instructions of the Atlas and the Scope Artifacts. As soon as something is ambiguous or is appealed, it is covered by the Governance Scope instead. - -#### 2.1.1 - -The Support Facilitators must balance and prioritize the resource allocated to AVC support. If resource constrained, the Responsible Facilitators must prioritize resources to focus on providing support to the AVCs that are most valuable to governance security. Governance security value is primarily determined by the size of the AVC, but also by the focus of the AVC - this means that smaller AVCs that introduce significant diversification benefits and increase voter choice must be prioritized above their size. +Maker Governance uses various core governance processes to manage its core decision making processes, including the Endgame MIP process, Scope Framework modification processes, and Delegate processes. The Support Scope is only responsible for facilitating routine processes that clearly follow the rules and instructions of the Atlas and the Scope Artifacts. As soon as something is ambiguous or is appealed, it is covered by the Governance Scope instead. #### 2.1.2: Pregame MIP Process The Support Facilitators must facilitate MIP processes and ensure they are followed according to the rules. -### 2.2: AVC Internal Governance Process Support - -#### 2.2.1: AVC Internal Governance Processes - -The Support Scope is responsible for tracking AVC internal governance proposals, AVC internal governance votes and resulting AVC Decisions. As the Support Facilitators track AVC internal governance processes, they must publish the activity to enable the broader community to follow - -##### 2.2.1.1 - -AVC internal governance proposals are messages sent by an AVC Member that is cryptographically signed by their verified Ethereum Account. - -##### 2.2.1.2 - -AVC internal governance votes are "for" or "against" messages sent by an AVC member that are cryptographically signed by their verified Ethereum Accounts. - -##### 2.2.1.3 - -The Support Facilitators must ensure that the necessary infrastructure and services are available for AVCs to function as intended by the Atlas, making participation in Maker Governance as convenient and streamlined as possible for AVC Members. A particular focus is the ease of transition from ordinary MKR holder to fully participating AVC Member. - -##### 2.2.1.4 - -The AVC must have their own forums with categories for each of the Scopes to be able to collaborate in public on the AVC Scope Framework Position Documents and the AVC Aligned Governance Strategy Position Documents. - -### 2.3: Quarterly Scope Process - -#### 2.3.1: AVC Quarterly Scope Process - -AVCs must have the necessary support to hold quarterly AVC Subcommittee Meetings for each Scope. The meetings must be recorded and published on the Maker Forum. - ### 2.4: Scope Defined Processes #### 2.4.1: Arbitrary Scope Framework Processes @@ -336,7 +304,7 @@ The Responsible Facilitators of the Ecosystem have resources available to procur ##### 2.5.1.1 -The budget for the tasks described in the Governance Process Support Article is defined in *2.5.1.1B*. The Active Element can be proposed to be modified urgently by the Responsible Facilitators using a weekly cycle governance poll, or through the standard AVC process. +The budget for the tasks described in the Governance Process Support Article is defined in *2.5.1.1B*. The Active Element can be proposed to be modified urgently by the Responsible Facilitators using a weekly cycle governance poll. ##### 2.5.1.1B @@ -344,7 +312,7 @@ The budget for the tasks described in the Governance Process Support Article is The budget available to fund Governance Process Support tasks is: -* 0 Dai per quarter +- 0 Dai per quarter ¤¤¤ @@ -352,20 +320,6 @@ The budget available to fund Governance Process Support tasks is: The DAO Toolkit is a unified governance software system that is used to simplify, organize and standardize all of the governance processes and information of Maker Governance and the Scope Artifacts. Each Scope must, over time, be implemented using the DAO Toolkit as it is developed to make them interactive and make it easier for newcomers to understand how Maker Governance works. -### 3.1: DAO Toolkit Core Development - -The Support Facilitators must fund the development of the core underlying software and modules of the DAO Toolkit that is used to implement the Scope Frameworks as software. DAO Toolkit Core Development is funded through the budget defined in *3.1.1B*. This Active Element is modified using the standard AVC process. - -#### 3.1.1B - -¤¤¤ - -The budget available to fund DAO Toolkit Core Development tasks is: - -* 0 Dai per quarter - -¤¤¤ - ### 3.2: Standardized DAO Toolkit Patterns The DAO Toolkit must be developed and used across all of the Scope Framework to unify the user experience of all aspects of Maker Governance as much as possible. @@ -428,7 +382,7 @@ Provide suggested actions to Facilitators for a given situation, and provide Ali #### 4.1.4 -Generate Scope Artifacts from scratch or do complete overhauls of existing Scope Artifacts based on ideas from SubDAO communities. With enough computing power, data and reinforcement learning of the results obtained from performing the functions in *4.1.1*, *10.1.2* and *4.1.3* the GAIT will be able to fully generate or redesign and populate complete sets of Scope Artifacts and all associated processes and DAO Toolkit functionality for any kind of economic opportunity a SubDAO wants to explore. This allows existing SubDAOs to rapidly iterate on their business focus with just a few active community members using AI tools, and it allows brand new SubDAOs to become fully functional and fully “populated” in an extremely short amount of time, as almost no humans need to be involved in the normal functioning of a SubDAO. +Generate Scope Artifacts from scratch or do complete overhauls of existing Scope Artifacts based on ideas from SubDAO communities. With enough computing power, data and reinforcement learning of the results obtained from performing the functions in *4.1.1*, *4.1.2* and *4.1.3* the GAIT will be able to fully generate or redesign and populate complete sets of Scope Artifacts and all associated processes and DAO Toolkit functionality for any kind of economic opportunity a SubDAO wants to explore. This allows existing SubDAOs to rapidly iterate on their business focus with just a few active community members using AI tools, and it allows brand new SubDAOs to become fully functional and fully “populated” in an extremely short amount of time, as almost no humans need to be involved in the normal functioning of a SubDAO. #### 4.1.5 @@ -450,30 +404,6 @@ As much as possible of the core GAIT stack should be open source, and there must The GAIT must be optimized for safety and corrigibility as it scales in power, utilizing advanced solutions such as automatic shutdown of the hardware if an on-chain heartbeat signal isn’t detected. The Maker Ecosystem must ensure adequate funding for AI safety research and methods for ensuring decentralization of AI power and detecting collusion between AI systems. -### 4.3: Governance Artificial Intelligence (GAIT) Tools Development Budget - -The GAIT needs to be bootstrapped with significant initial funding, and must continuously be improved to maintain its edge for Maker Core and the SubDAO ecosystem. The budget is broken down into multiple the bootstrapping budget for research, development and operation, and the hardware and maintenance budget for hardware related costs. - -#### 4.3.1 - -The GAIT bootstrapping budget is for work related to bootstrapping the first version of the GAIT, including designing, configuring, deploying and fine-tuning the first models, and setting up long term reinforcement learning and do initial monitoring and adjustments. The GAIT bootstrapping budget can also be used on other AI projects than the GAIT. The GAIT bootstrapping budget is specified in *4.3.1.1B*, and is allocated to relevant projects through a manual governance poll and executive vote using the weekly cycle. It is a one time budget and a relative budget that can only be increased or renewed through the regular AVC process. This element is meant to eventually be transitioned into a long term automatically renewing budget. - -##### 4.3.1.1 - -A relative budget means a budget that is only available if the Maker Protocol is generating enough income to actively burn, and the budget can then at most spend a smaller amount of what’s being burned, ensuring that the burn continues. - -###### 4.3.1.1.1B - -¤¤¤ - -The GAIT bootstrapping budget is: - -- 4,000,000 DAI relative budget that only becomes available as DAI is being burned in the Smart Burn Engine. The conditions are: At least 20 million DAI must have been sent to the Smart Burn Engine before the relative budget begins to unlock. Once the minimum requirement has been met, the relative budget unlocks at a rate equivalent to 25% of the DAI that is sent to the Smart Burn Engine. This means that the full 4,000,000 DAI will be available once 16,000,000 DAI has been transferred to the Smart Burn Engine. - -¤¤¤ - ---- - #### 4.3.2 The GAIT hardware and maintenance budget can be accessed directly by the Support Facilitators, and must be spent on hardware and continuous maintenance of the GAIT deployments. Initially, before the GAIT has been bootstrapped and is ready to be activated, the GAIT hardware and maintenance budget is inactive, and is not available to access. The budget can be activated and modified using the Weekly Governance Cycle by a proposal triggered by the Support Facilitators. The GAIT hardware and maintenance budget is specified in *4.3.2.1B*. @@ -565,8 +495,9 @@ Spark has a special token pre-farming program based on usage of its lending plat The pre-farming period is active from Ethereum block 17956537 [AUG 20 2023 14:25 UTC] and ends at the earlier of two events: - Start of SubDAO token farming OR MAY 20 2024 14:25 UTC. -- 30m SPK tokens allocated if full 9 months pass. Pro-rated if earlier. -- SPK portion sourced from SubDAO workforce bonus pool, available within 1 month after SubDAO farming starts. +- 30m SPK tokens allocated for the first 9 months. +- Following the end of the initial 9 month period, an additional pre-farming period will continue until the launch of Spark. Rewards are calculated on a per-block basis according to the Anti-cheat formula, at a rate of 3.33m SPK tokens per month. +- SPK portion sourced from SubDAO workforce bonus pool, available immediately at token and Spark launch. - Final airdrop calculated for each account, based on each block within the valid timeframe. Only for Ethereum Mainnet. No other chain included. @@ -577,11 +508,11 @@ Anti-cheat formula: #### 6.4.1: Special SPK Token Pre-farming -The Support Facilitators can activate a new SPK token pre-farming airdrop program to incentivize adoption of overcollateralized perpetual yield exposure in new markets. +The Support Facilitators can activate a new SPK token pre-farming airdrop program to capture other growth opportunities. -The program can last until the moment SPK launches, or a shorter duration, which must be declared by the Support Facilitators. The exact details of the special pre-farming airdrop program is specified in *6.4.1.1A*, which the Support Facilitators can modify at will, as long as it conforms the specifications of *6.4.1*. +The program can last until the moment SPK launches, or a shorter duration, which must be declared by the Support Facilitators. The exact details of the special pre-farming airdrop program are specified in *6.4.1.1A*, which the Support Facilitators can modify at will, as long as it conforms the specifications of *6.4.1*. -The SPK tokens for the future Spark Airdrop are allocated between all borrowers on the designated markets. The rate of SPK tokens being earned is 1.66 million SPK per month, distributed on a per block basis proportional to the amount of dai borrowed from the eligible markets specified in *6.4.1.1A*. +The SPK tokens for the future Spark Airdrop are allocated between all borrowers based on a formula announced by the Support Facilitators and specified in *6.4.1.1A*. The rate of SPK tokens being earned is 1.66 million SPK per month, distributed on a per block basis proportional to the formula specified in *6.4.1.1A*. ##### 6.4.1.1A @@ -624,41 +555,6 @@ Other useful services including legal services, economic and risk advice, commun The Support Facilitators have two budgets available to support the tasks described in this section, the incubation overhead budget and the incubation budget. -#### 7.2.1 - -The Incubation Overhead budget is contained in *7.2.1.1B* and is modified through the regular AVC process. - ---- - -##### 7.2.1.1B - -¤¤¤ - -The Incubation Overhead budget is: - -* 0 Dai per quarter. - -¤¤¤ - ---- - -#### 7.2.2 - -The Incubation budget is contained in *7.2.2.1B* and is modified through the regular AVC process. - -— - -##### 7.2.2.1B - -¤¤¤ - -The Incubation budget is - -* 0 Dai per quarter -* Up to 0 MKR per quarter. - -¤¤¤ - ### 7.3: Incubation Proposal Process #### 7.3.1: Incubation Proposal Submission Process @@ -727,10 +623,10 @@ The list of Incubating Ecosystem Actors must follow the template contained in *7 ¤¤¤ -* **.x:** [Incubating Ecosystem Actor name and short description] -* **.1:** [Budget information] -* **.2:** [Deliverables and focus areas] -* **.3:** [Team information, including headcount grouped by skill sets] +- **.x:** [Incubating Ecosystem Actor name and short description] +- **.1:** [Budget information] +- **.2:** [Deliverables and focus areas] +- **.3:** [Team information, including headcount grouped by skill sets] ¤¤¤ @@ -760,14 +656,16 @@ 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 -The ecosystem communication infrastructure, as well as the AVC communication infrastructure and the Incubating SubDAO communication infrastructure budgets are covered in this section. The budget is contained in *8.3.1B*. +The ecosystem communication infrastructure, as well as the AC communication infrastructure and the Incubating SubDAO communication infrastructure budgets are covered in this section. The budget is contained in *8.3.1B*. #### 8.3.1B @@ -837,7 +735,6 @@ 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. @@ -886,7 +783,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.6A +###### 10.1.1.2.2.6 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. @@ -952,7 +849,6 @@ Current Structure: - Active MKR or SubDAO Token Holders that participate regularly in governance (e.g., voting, writing proposals) - Alignment Conservers - - Aligned Voter Committee Members (AVCs) - Aligned Delegates (ADs) - Scope Facilitators - The Guardians (SUP *10.1.4*) or actors that fulfill an equivalent role @@ -1008,7 +904,7 @@ Valid PoE: - If no PoE is available, a verified Beneficiary must attest eligibility on behalf of the applicant. - This PoE will be used exceptionally if no other Proof is available and will be assessed individually by the Resilience Fund Technical Committee. -###### 10.1.1.4.1.1T Applications for the RF must follow this template: +###### 10.1.1.4.1.1T: Applications for the RF must follow this template - .x: [Application RF] - .x.1: [PoE] @@ -1020,7 +916,7 @@ The application form template will be integrated into the DAO Toolkit’s user-f ###### 10.1.1.4.1.2: Digital Signature -The Applicant must sign additionally an application message from the Ethereum Address (Digital Signature) used as PoE (10.1.1.4.1.1) +The Applicant must sign additionally an application message from the Ethereum Address (Digital Signature) used as PoE (*10.1.1.4.1.1*) ###### 10.1.1.4.1.3: Terms and Conditions @@ -1443,7 +1339,7 @@ Applications for Resilience Research projects must follow this template: - .x: [Project Name] - .x.1: [Project Abstract: In 3-5 sentences, what problem are you trying to solve?] - .x.2: [Objectives: What are you hoping to accomplish? How do you define and measure success for this project?] -- .x.3: [Outcomes: How does this project benefit the Maker ecosystem? How does this project help fulfill one of the Legal Resilience Objectives in SUP *10.1*-*10.8*?] +- .x.3: [Outcomes: How does this project benefit the Maker ecosystem? How does this project help fulfill one of the Legal Resilience Objectives in SUP *10.1*-.*10.8?*] - .x.4: [Scope: What will you research/build /design/implement? What is the expected output?] - .x.5: [Project Team: How many people are working on this project? Please list their names and roles for the project and how many hours per month each person will work on this project?] - .x.6: [Background: Relevant links, reference to other projects or research papers] diff --git a/MIP108/MIP108.md b/MIP108/MIP108.md index 027905b47..01cd44554 100644 --- a/MIP108/MIP108.md +++ b/MIP108/MIP108.md @@ -412,6 +412,8 @@ The Launch project must fund security and other critical infrastructure needs fo The Launch Project must explore options to help bootstrap the Purpose System and can request governance votes to allocate MKR from the Pause Proxy as grants or donations to relevant causes. Such payments must be approved through an MKR vote, and if they occur are separate from and in addition to the Launch Project Budget. +During Launch Season, the Launch Project must prepare for its dissolution and replacement, and must also implement significant transparency improvements once the new brand has been revealed. + ### 9.1: Launch Project Budget The budget available for the Launch Project is specified in *9.1.1B*. It is a one time budget that doesn’t renew over time, and payouts from the budget can be triggered by a message in the Maker Core forum specifying the amount to pay out (for lump sum payments) or the dssvest parameters (for dssvest payments), and the recipient address. The payment is bundled directly into the next weekly Executive Vote without requiring a Governance Poll. Every time a payout is done, the remaining budget in *9.1.1B* must be reduced to reflect the spent amount. Spending cannot exceed the total budget one-time budget. @@ -422,14 +424,14 @@ The budget available for the Launch Project is specified in *9.1.1B*. It is a on **Initial one-time budget for the Launch Project:** -20,000,000 DAI +40,000,000 DAI -5,000 MKR - The MKR can at most be spent at the rate of 500 MKR per month. +10,000 MKR - The MKR can at most be spent at the rate of 1000 MKR per month. **Remaining available one-time budget for the Launch Project:** -10,358,006.99 DAI +30,358,006.99 DAI -3,469.17 MKR - The MKR can at most be spent at the rate of 500 MKR per month. +8,469.17 MKR - The MKR can at most be spent at the rate of 1000 MKR per month. -¤¤¤ +¤¤¤ \ No newline at end of file diff --git a/MIP113/MIP113.md b/MIP113/MIP113.md index 2ee6540e4..55942675d 100644 --- a/MIP113/MIP113.md +++ b/MIP113/MIP113.md @@ -238,7 +238,7 @@ This section contains the processes for proposing and settling Atlas Interpretat #### 2.2.1 -Any Maker Governance participant can request an Atlas Interpretation from the Governance Facilitators by submiting a post on the Maker Forum. ​​​​​​​In order for the Governance Facilitators to be bound to comply with the interpretation request, it must be endorsed or supported by at least one AVC Member or Aligned Delegate. In all cases the Facilitator can voluntarily proceed with the interpretation.​​​​​​​ +Any Maker Governance participant can request an Atlas Interpretation from the Governance Facilitators by submitting a post on the Maker Forum. In order for the Governance Facilitators to be bound to comply with the interpretation request, it must be endorsed or supported by at least one AVC Member or Aligned Delegate. In all cases the Facilitator can voluntarily proceed with the interpretation.​​​​​​​ #### 2.2.2 @@ -284,34 +284,6 @@ The Governance Facilitators will review the request, engage the community, and p ## 3: Scope Bounded Mutable Alignment Artifact (Scope Artifact) -### 3.1 Scope Artifact Appeals - -Scope Artifact appeals are a process that allows any Maker Governance participant to trigger a review of a Scope Artifact. This can be in connection with the Scope Artifact failing to follow the Atlas Boundaries, or if it contains biased or otherwise conflicted elements. It can either be a general misalignment of the language of the Scope Artifact, or a specific situation where the Scope Artifact is being misinterpreted or otherwise violated. - -#### 3.1.1 Scope Artifact Appeals Process - -Scope Artifact appeal proposals are submitted by AVC Members, and can be accepted or rejected by a majority of the Governance Facilitators. If a Scope Artifact appeal is accepted, the Governance Facilitators must review it. Governance Facilitators can also directly choose to review a Scope Artifact for adherence with Scope boundaries and Atlas alignment. - -##### 3.1.1.1 - -When a request for an Scope Artifact Appeal is submitted to the Maker Forum, Governance Facilitators have up to 30 days for review and provide the answer.The Governance Facilitators may extend this deadline, if necessary, by 15 days, provided that they have published the justification in the Maker Forum. - -##### 3.1.1.2 - -Following the conclusion of the review period, the Governance Facilitators are required to publicly post their response to the Atlas Appeal request on the Maker Forum. This response must include a detailed rationale for the decision reached, reflecting a comprehensive review of the request. The post must also transparently indicate the voting results among the Facilitators, listing which Facilitators were in favor of or against the decision. This process is designed to ensure accountability and transparency in the decision-making process. - -##### 3.1.1.3 - -If the Governance Facilitators cannot reach a majority decision regarding an Atlas Appeal Request, a vote shall be triggered involving Maker Governance in the final decision. - -##### 3.1.1.4 - -The Governance Facilitators can by consensus directly edit a Scope Artifact to align its content with the Scope boundaries and other Atlas requirements such as neutrality. - -##### 3.1.1.5 - -A majority of the Responsible Facilitators can trigger an MKR governance poll to implement an edit to the appealed Scope Artifact that will align it with the Scope boundaries and other Atlas requirements such as neutrality. - ## 4: Alignment Conservers The Governance Facilitators must ensure the rules of Alignment Conservers specified in *ATL2.4* are followed. Governance Facilitators must act against Alignment Conservers if they break rules specified in the Atlas or the Scope Artifacts, or act misaligned. Any Governance Facilitator may do this directly. @@ -367,226 +339,11 @@ List of formally warned Alignment Conservers: ## 5: Aligned Voter Committees (AVCs) -AVCs are standardized Voter Committees made up of Alignment Conservers that hold MKR and participate in the Maker Governance process as actors that are deeply aligned with MKR holders. They are subject to specific requirements, and receive various benefits, resources and support from the Support Scope. They have significant formal powers, but no direct physical power, making them well suited to be in control and making key decisions during normal conditions. - -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. - -The Stability Facilitators must ensure that the processes related to Aligned Voter Committees specified in *ATL2.5* are followed. - -### 5.1: Aligned Voter Committee Decisions - -AVC splits are disabled until the launch of NewChain. - -#### 5.1.1 - -AVCs can elect one member as an AVC moderator via an AVC decision. The vote for this AVC decision excludes the current moderator if there is one. The moderator has the authority to unilaterally confirm a limited subset of AVC decisions. However, to consider a decision valid, the moderator must tag all other AVC members in the decision message. These decisions are deemed valid after a period of 72 hours without a veto by any other member of the AVC. Vetoes are posted to to the forum via a signed message. - -Moderators are elected at the beginning of each quarter. - -If a vote is not performed in a given quarter, the current moderator is automatically reconfirmed moderator for the next quarter. - -The AVC decisions that moderators have elected authority to make without the official AVC decision process are limited to- publishing or altering the meeting schedule, publishing the AVC's quarterly position documents. - -### 5.2: Aligned Voter Committee Member Recognition - -#### 5.2.1 - -To become recognized as an Unaffiliated AVC Member, an Ecosystem Actor must post a recognition submission message publicly on the Maker Governance Forum, as described in *5.2.1.1*, *5.2.1.2*, *5.2.1.3*, and *5.2.1.4*. - -A recognized AVC member can lose their recognized role by either failing to fulfill the requirements, as described in *5.2.4.4*, or by submitting a written relinquishment as described in *5.2.1.5*. - -##### 5.2.1.1 - -A recognition submission message must be cryptographically signed by an Ethereum address containing at least 1 MKR, or that has delegated at least 1 MKR. - -##### 5.2.1.2 - -The cryptographically signed AVC Member Recognition Message must contain the information specified in *5.2.1.2.1* and *5.4.1.2.2*. The information specified in *5.2.1.2.3* and *5.2.1.2.4* is optional. - -###### 5.2.1.2.1 - -The following text must be included: "AVC Member Recognition". - -###### 5.2.1.2.2 - -A timestamp recording the time and date that the message was signed. - -###### 5.2.1.2.3 - -The desired name of the AVC Member. - -###### 5.2.1.2.4 - -The AVC that the AVC Member wishes to join, if applicable. - -##### 5.2.1.3 - -A recognition submission message must use the format described in *5.2.1.4*. - -##### 5.2.1.4 - -``` -Title: AVC Member Recognition submission -AVC member recognition submission -[Ethereum address] -[Cryptographically signed AVC Member Recognition Message] -``` - -##### 5.2.1.5 - -An AVC member may voluntarily relinquish their recognized status at any time by submitting a cryptographically signed message. This message must include a timestamp indicating the time and date of signing, and should be formatted as follows: - -``` -Title: AVC Member Relinquishment announcement -AVC member Relinquishment announcement -[Ethereum address] -[Cryptographically signed AVC Member Recognition Message] -``` - -Once the message's authenticity is confirmed, the AVC member should no longer be considered recognized. - -The applicant may explicitly request in their signed message that all references to their past affiliation with any AVC (including nickname, Ethereum address, etcetera) be removed from MIP113. This request must be promptly fulfilled by the Governance Facilitators. - -#### 5.2.2 - -The Governance Facilitators must maintain the list of Unaffiliated AVC Members contained in *5.2.2.1A*. - -##### 5.2.2.1A - -¤¤¤ - -List of Unaffiliated AVC Members: - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | -|---|---|---|---|---:| -| TRUEMAKER | [0x4eFb12d515801eCfa3Be456B5F348D3CD68f9E8a](https://etherscan.io/address/0x4efb12d515801ecfa3be456b5f348d3cd68f9e8a) | [Link](https://forum.makerdao.com/t/growth-cvc-membership-submission-request/20349) | [Link](https://etherscan.io/verifySig/16549) | 5.016 | -| anathem.eth | [0xa2fC3b7A5dA35D0418Ec46A9CcFc7f4a53084841](https://etherscan.io/address/0xa2fC3b7A5dA35D0418Ec46A9CcFc7f4a53084841) | [Link](https://forum.makerdao.com/t/cvc-member-recognition-anathem-eth/20558/2) | [Link](https://etherscan.io/verifySig/16935) | 0.313 | - -¤¤¤ - -#### 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*. - -#### 5.2.4: AVC Management - -The Governance Facilitators must monitor and record the status of each AVC. - -##### 5.2.4.1 - -An AVC is marked as _active_ status if it has fulfilled every requirement under *4.3* in the previous quarter. - ---- - -##### 5.2.4.2 - -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.3 - -An AVC is marked as _pending_ status if it has been in existence for less than one full quarter. - ---- - -##### 5.2.4.4 - -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.6.1A*. - ---- - -##### 5.2.4.5 - -The list of all AVCs is contained in *5.2.4.6.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.6.1A - -¤¤¤ - -List of active AVCs and their members: - -[**KISS AVC**](https://forum.makerdao.com/t/cvc-creation-kiss-cvc/20346) - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | Approved to Join AVC | -|---|---|---|---|---:|---| -| IamMeeoh | [0x47f7A5d8D27f259582097E1eE59a07a816982AE9](https://etherscan.io/address/0x47f7A5d8D27f259582097E1eE59a07a816982AE9) | [Link](https://forum.makerdao.com/t/cvc-member-recognition/20305) | [Link](https://etherscan.io/verifySig/16252) | 1| [AVC Creator](https://forum.makerdao.com/t/cvc-creation-kiss-cvc/20346) | -| DAI-Vinci | [0x9ee47F0f82F1A6F45C4E1D25Ce95C321D8C8356a](https://etherscan.io/address/0x9ee47F0f82F1A6F45C4E1D25Ce95C321D8C8356a) | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-dai-vinci/21555) | [Link](https://etherscan.io/verifySig/22586) | 1 | [Link](http://forum.makerdao.com/t/avc-member-recognition-submission-dai-vinci/21555/2) | -| twblack88 (Feedblack Loops LLC) | [0x80882f2A36d49fC46C3c654F7f9cB9a2Bf0423e1](https://etherscan.io/address/0x80882f2A36d49fC46C3c654F7f9cB9a2Bf0423e1) | [Link](http://forum.makerdao.com/t/avc-member-recognition-submussion-fbl/22318/3) | [Link](https://etherscan.io/verifySig/25520) | 1 | [Link](http://forum.makerdao.com/t/avc-member-recognition-submussion-fbl/22318/2) | -| opensky | [0xf44f97f4113759E0a57756bE49C0655d490Cf19F](https://etherscan.io/address/0xf44f97f4113759E0a57756bE49C0655d490Cf19F) | [Link](http://forum.makerdao.com/t/avc-member-recognition-opensky/22266/7) | [Link](https://etherscan.io/verifySig/32036) | 1 | [Link](http://forum.makerdao.com/t/avc-member-recognition-opensky/22266/4) | -| stefdelev | [0xaAA1D204D78De81a6EfF5264928A6B49eE748050](https://etherscan.io/address/0xaAA1D204D78De81a6EfF5264928A6B49eE748050) | [Link](http://forum.makerdao.com/t/avc-member-recognition-submission-stefdelev/22317/12) | [Link](https://etherscan.io/verifySig/26131) | 1 | [Link](http://forum.makerdao.com/t/avc-member-recognition-submission-stefdelev/22317/11) | -| billybob | [0x47298a5369806c8974CA9B7848c401bE24038BDA](https://etherscan.io/address/0x47298a5369806c8974CA9B7848c401bE24038BDA) | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-billybob/23897) | [Link](https://etherscan.io/verifySig/38110) | 1 | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-billybob/23897/5) | - ---- - -[**Regenerative Finance AVC**](https://forum.makerdao.com/t/cvc-creation-regenerative-finance-cvc/20354) - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | Approved to Join AVC | -|---|---|---|---|---:|---| -| ACRE DAOs | [0xBF9226345F601150F64Ea4fEaAE7E40530763cbd](https://etherscan.io/address/0xBF9226345F601150F64Ea4fEaAE7E40530763cbd) | [Link](https://forum.makerdao.com/t/cvc-member-recognition-acre-daos/20319) | [Link](https://etherscan.io/verifySig/22051) | 2.180 | [AVC Creator](https://forum.makerdao.com/t/cvc-creation-regenerative-finance-cvc/20354) | -| fhomoney.eth | [0xdbD5651F71ce83d1f0eD275aC456241890a53C74](https://etherscan.io/address/0xdbD5651F71ce83d1f0eD275aC456241890a53C74) | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-fhomoney-eth/21666) | [Link](https://etherscan.io/verifySig/23243) | 6.000 | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-fhomoney-eth/21666/6) | - ---- - -[**Resiliency AVC**](https://forum.makerdao.com/t/cvc-creation-resiliency-cvc/20353) - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | Approved to Join AVC | -|---|---|---|---|---:|---| -| Res | [0x8c5c8d76372954922400e4654AF7694e158AB784](https://etherscan.io/address/0x8c5c8d76372954922400e4654AF7694e158AB784) | [Link](https://forum.makerdao.com/t/cvc-membership-recognition-res/20352) | [Link](https://etherscan.io/verifySig/16492) | 4.173 | [AVC Creator](https://forum.makerdao.com/t/cvc-creation-resiliency-cvc/20353) | -| Harmony | [0xE20A2e231215e9b7Aa308463F1A7490b2ECE55D3](https://etherscan.io/address/0xE20A2e231215e9b7Aa308463F1A7490b2ECE55D3) | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-harmony/21352) | [Link](https://etherscan.io/verifySig/21630) | 2.00 | [Link](http://forum.makerdao.com/t/avc-member-recognition-submission-harmony/21352/2) | -| Libertas | [0xE1eBfFa01883EF2b4A9f59b587fFf1a5B44dbb2f](https://etherscan.io/address/0xE1eBfFa01883EF2b4A9f59b587fFf1a5B44dbb2f) | [Link](https://forum.makerdao.com/t/avc-member-recognition-libertas/22309) | [Link](https://etherscan.io/verifySig/25503) | 1.00 | [Link](http://forum.makerdao.com/t/avc-member-recognition-libertas/22309/2) | -| elbuddy | [0xc779545b7721ac97C00ce9ea472646bB65BF417D](https://etherscan.io/address/0xc779545b7721ac97C00ce9ea472646bB65BF417D) | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-elbuddy/23289) | [Link](https://etherscan.io/verifySig/32415) | 1.02 | [Link](https://forum.makerdao.com/t/avc-member-recognition-submission-elbuddy/23289/2) | - ---- - -[**Sovereign Finance AVC**](https://forum.makerdao.com/t/cvc-creation-sovereign-finance-cvc/20868/) - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | Approved to Join AVC | -|---|---|---|---|---:|---| -| seedlatam.eth | [0xd43b89621fFd48A8A51704f85fd0C87CbC0EB299](https://etherscan.io/address/0xd43b89621fFd48A8A51704f85fd0C87CbC0EB299) | [Link](https://forum.makerdao.com/t/cvc-member-recognition-submission-seedlatam-eth/20836) | [Link](https://etherscan.io/verifySig/18891) | 6.800 | [AVC Creator](https://forum.makerdao.com/t/cvc-creation-sovereign-finance-cvc/20868/) | -| 0xRoot | [0xC74392777443a11Dc26Ce8A3D934370514F38A91](https://etherscan.io/address/0xC74392777443a11Dc26Ce8A3D934370514F38A91) | [Link](https://forum.makerdao.com/t/avc-member-recognition-0xroot/22267) | [Link](https://etherscan.io/verifySig/25450) | 5.01959484 | [Link](https://forum.makerdao.com/t/avc-member-recognition-0xroot/22267/2) | - ---- - -List of pending AVCs and their members: - -[**RISK AVC**](https://forum.makerdao.com/t/cvc-application-risk-cvc/20948) - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | Approved to Join AVC | -|---|---|---|---|---:|---| -| HKUST_EPI_BLOCKCHAIN | [0xE4594A66d9507fFc0d4335CC240BD61C1173E666](https://etherscan.io/address/0xE4594A66d9507fFc0d4335CC240BD61C1173E666) | [Link](https://forum.makerdao.com/t/cvc-member-recognition-hkust-epi-blockchain/20939) | [Link](https://etherscan.io/tx/0xc11f93b290673c5348400adfdab516f08b2fb7f3197dd024a2cc94a301243216) | 1.007 | [AVC Creator](https://forum.makerdao.com/t/cvc-application-risk-cvc/20948) | - ---- - -List of inactive AVCs and their members prior to becoming inactive: - -[**Composable AVC**](https://forum.makerdao.com/t/cvc-registration-submission-composable-cvc/20348) - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | Approved to Join AVC | -| --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | -------------------------------------------- | -------------------------------: | ------------------------------------------------------------ | -| LDF | [0xC322E8Ec33e9b0a34c7cD185C616087D9842ad50](https://etherscan.io/address/0xC322E8Ec33e9b0a34c7cD185C616087D9842ad50) | [Link](https://forum.makerdao.com/t/cvc-member-recognition-composable-cvc/20350) | [Link](https://etherscan.io/verifySig/16614) | 1.020 | [AVC Creator](https://forum.makerdao.com/t/cvc-registration-submission-composable-cvc/20348) | -| stefdelev | [0xaAA1D204D78De81a6EfF5264928A6B49eE748050](https://etherscan.io/address/0xaAA1D204D78De81a6EfF5264928A6B49eE748050) | [Link](https://forum.makerdao.com/t/avc-member-recognition-stefdelev/21681) | [Link](https://etherscan.io/verifySig/23668) | 1.000 | [Link](https://forum.makerdao.com/t/avc-member-recognition-stefdelev/21681/7) | - -[**Growth AVC**](https://forum.makerdao.com/t/cvc-creation-growth-cvc/20363) - -| AVC Member Name | AVC Member Address | Forum Verification | Verified Signature | Verified MKR Holding (MKR) (3dp) | Approved to Join AVC | -|---|---|---|---|---:|---| -| StableLab | [0xbDE65cf2352ed1Dde959f290E973d0fC5cEDFD08](https://etherscan.io/address/0xbDE65cf2352ed1Dde959f290E973d0fC5cEDFD08) | [Link](https://forum.makerdao.com/t/cvc-member-recognition-growth-cvc/20311) | [Link](https://etherscan.io/verifySig/16253) | 11.999 | [AVC Creator](https://forum.makerdao.com/t/cvc-creation-growth-cvc/20363) | -| flipsidegov | [0x300901243d6CB2E74c10f8aB4cc89a39cC222a29](https://etherscan.io/address/0x300901243d6cb2e74c10f8ab4cc89a39cc222a29) | [Link](https://forum.makerdao.com/t/cvc-member-registration-submission-growth-cvc/20308/33) | [Link](https://etherscan.io/verifySig/16730) | 0.100 | [Approved](https://forum.makerdao.com/t/cvc-creation-growth-cvc/20363/13) | - ---- - -¤¤¤ - -### 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. +AVCs are disabled until the launch of the Easy Governance Frontend when Voter Incentives are turned on. ## 6: Aligned Delegates (ADs) -The Governance Facilitators must ensure that all the rules of ADs are followed as specified in *ATL2.6* +The Governance Facilitators must ensure that all the rules of ADs are followed. ### 6.1: Aligned Delegate Recognition @@ -598,7 +355,7 @@ The current state of ADs is maintained by the Governance Facilitators. #### 6.1.2 -The list of all current recognized ADs is maintained in *6.1.2A*. +The list of all current recognized ADs is maintained in *6.1.2A*. Following the temporary removal of AVCs, Governance Facilitators must remove the Delegation Contract 2 when feasible, and use Delegation Contract 1 as the main Delegate Contract #### 6.1.2A @@ -606,12 +363,12 @@ The list of all current recognized ADs is maintained in *6.1.2A*. List of current ADs: -| Delegate Name | EA Address | Delegation Contract 1 | Delegation Contract 2 | Neutral Contracts (if present) | Forum Post | +| Delegate Name | EA Address | Delegation Contract 1 | Forum Post | |---|---|---|---|---|---| -| vigilant | [Address](https://etherscan.io/address/0x2474937cB55500601BCCE9f4cb0A0A72Dc226F61)
[Signature](https://etherscan.io/verifySig/16682) | [Contract](https://etherscan.io/address/0x51f3067cB6a1185d1e8316332921d9501FC4c006#readContract)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/21510) | [Contract](https://etherscan.io/address/0xde08aef2b221274231b3547491ec8f0fc80917e1)
**KISS AVC**
[Signature](https://etherscan.io/verifySig/40792) | - | [Link](https://forum.makerdao.com/t/cd-recognition-submission-vigilant/20457) | -| QGov | [Address](https://etherscan.io/address/0xB0524D8707F76c681901b782372EbeD2d4bA28a6)
[Signature](https://etherscan.io/verifySig/16763) | [Contract](https://etherscan.io/address/0x0a907fe3adb890db7db27a7f21e188a4127b2e7c)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/40048) | [Contract](https://etherscan.io/address/0x1dd6c65e6e22f196d5c2209f439d1f07d02ba7a4)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/26528) | - | [Link](https://forum.makerdao.com/t/qgov-cd-recognition-submission/20494) | -| Bonapublica | [Address](https://etherscan.io/address/0x167c1a762B08D7e78dbF8f24e5C3f1Ab415021D3)
[Signature](https://etherscan.io/verifySig/21271) | [Contract](https://etherscan.io/address/0x452a7626f587d6811509dc071768168ea763ea3c)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/16766) | [Contract](https://etherscan.io/address/0xFE61acc408b63a5a03507A224398fa1FE8143F28)
**KISS AVC**
[Signature](https://etherscan.io/verifySig/21270) | - | [Link](https://forum.makerdao.com/t/bonapublica-constitutional-delegate-recognition-submission/20451) | -| PBG | [Address](https://etherscan.io/address/0x8D4df847dB7FfE0B46AF084fE031F7691C6478c2)
[Signature](https://etherscan.io/verifySig/16773) | [Contract](https://etherscan.io/address/0x69b576a7e193a15a570ee5bb2149deb3f03537a2)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/21570) | [Contract](https://etherscan.io/address/0xeb1764cc9577c52f430794e9044f64f1c49dd395)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/40131) | - | [Link](https://forum.makerdao.com/t/pbg-constitutional-delegate-communication-platform/20471) | +| vigilant | [Address](https://etherscan.io/address/0x2474937cB55500601BCCE9f4cb0A0A72Dc226F61)
[Signature](https://etherscan.io/verifySig/16682) | [Contract](https://etherscan.io/address/0x51f3067cB6a1185d1e8316332921d9501FC4c006#readContract)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/21510) | [Contract](https://etherscan.io/address/0xC2DAea14891Fc47Ee76368Ce7c54C7b200FbA672)
**KISS AVC**
[Signature](https://etherscan.io/verifySig/16681) | - | [Link](https://forum.makerdao.com/t/cd-recognition-submission-vigilant/20457) | +| QGov | [Address](https://etherscan.io/address/0xB0524D8707F76c681901b782372EbeD2d4bA28a6)
[Signature](https://etherscan.io/verifySig/16763) | [Contract](https://etherscan.io/address/0x0a907fe3adb890db7db27a7f21e188a4127b2e7c)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/16765) | [Contract](https://etherscan.io/address/0x1dd6c65e6e22f196d5c2209f439d1f07d02ba7a4)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/26528) | [Formerly Growth AVC](https://etherscan.io/address/0xca0c8bedc85c2ec9b0dfb42b3f2763486ddea1b6) | [Link](https://forum.makerdao.com/t/qgov-cd-recognition-submission/20494) | +| Bonapublica | [Address](https://etherscan.io/address/0x167c1a762B08D7e78dbF8f24e5C3f1Ab415021D3)
[Signature](https://etherscan.io/verifySig/21271) | [Contract](https://etherscan.io/address/0xe2bfDa5e1f59325E4b8dF5feaA30e4aB6516bf28)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/16766) | [Contract](https://etherscan.io/address/0xFE61acc408b63a5a03507A224398fa1FE8143F28)
**KISS AVC**
[Signature](https://etherscan.io/verifySig/21270) | - | [Link](https://forum.makerdao.com/t/bonapublica-constitutional-delegate-recognition-submission/20451) | +| PBG | [Address](https://etherscan.io/address/0x8D4df847dB7FfE0B46AF084fE031F7691C6478c2)
[Signature](https://etherscan.io/verifySig/16773) | [Contract](https://etherscan.io/address/0x69b576a7e193a15a570ee5bb2149deb3f03537a2)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/21570) | [Contract](https://etherscan.io/address/0xc3b85930deca88e5bcb48fa8ebe935f97d5e412b)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/16771) | [Formerly Growth AVC](https://etherscan.io/address/0x952dc79bcee652aad8cc9268d9c614fa166d0c1d) | [Link](https://forum.makerdao.com/t/pbg-constitutional-delegate-communication-platform/20471) | | Pf | [Address](https://etherscan.io/address/0x94A388BEC0769c3394A48dB4DaBE5F29994100B3)
[Signature](https://etherscan.io/verifySig/16824) |

| No current active Contract 2 - banned by KISS AVC
[Link](https://forum.makerdao.com/t/pf-recognition-submission/20520) | [Formerly Growth AVC](https://etherscan.io/address/0x62060879dfBB6dEf3B73CFC48f1f0595c0FeD505) | | | UPMaker | [Address](https://etherscan.io/address/0xbb819df169670dc71a16f58f55956fe642cc6bcd)
[Signature](https://etherscan.io/verifySig/16997) | [Contract](https://etherscan.io/address/0xc241a035bc98128ac3983812a67dfc52ddeae09a)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/38946) | [Contract](https://etherscan.io/address/0x27194176525A0088E3Dc96973b22b01b15376eBd)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/16998) | - | [Link](https://forum.makerdao.com/t/upmaker-cd-recognition-submission/20577) | | WBC | [Address](https://etherscan.io/address/0xeBcE83e491947aDB1396Ee7E55d3c81414fB0D47)
[Signature](https://etherscan.io/verifySig/17927) | [Contract](https://etherscan.io/address/0x58dc40b5f9f0758ee43b0a208fe362c90fdfad4d)
**ReFi AVC**
[Signature](https://etherscan.io/verifySig/17929) | [Contract](https://etherscan.io/address/0x5b0a4932dc9e253f9b15fd69f07b68e9874ea794)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/21557) | [Formerly Growth AVC](https://etherscan.io/address/0xb086ec4303dc1514c09618c6c68ee444d6eee041) | [Link](https://forum.makerdao.com/t/wbc-aligned-delegate-communications/20828) | @@ -628,7 +385,6 @@ List of current ADs: | Pipkin | [Address](https://etherscan.io/address/0x0E661eFE390aE39f90a58b04CF891044e56DEDB7)
[Signature](https://etherscan.io/tx/0x99a7580b90425e54958f56bd56c2018042b0cdbe9de407d4f693409b166c4d2a) | [Contract](https://etherscan.io/address/0x45C52826EFA13A6DE713528BF42B520C9fA50081)
**Resiliency AVC**
[Signature](https://etherscan.io/tx/0x63e9e44ad849c806f870800898e76ee47f96982946c1b44e447667e7cdab67eb) | [Contract](https://etherscan.io/address/0x47EcD8e9f8F299cE47E3aB891a874707d70A3aF9)
**Sovereign Finance AVC**
[Signature](https://etherscan.io/tx/0x4b2f349419e3eadce8dee7ba5f300499d7a9ce8a5e8701a65a131738b3a08b39) | - | [Link](https://forum.makerdao.com/t/pipkin-ad-recognition/23448) | | JuliaChang | [Address](https://etherscan.io/address/0x252abAEe2F4f4b8D39E5F12b163eDFb7fac7AED7)
[Signature](https://etherscan.io/verifySig/34622) | [Contract](https://etherscan.io/address/0x7938b304F1c28e85b6A021251C8CeefF20370f38)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/34620) | [Contract](https://etherscan.io/address/0x117B58Cc89156b48c302aAa4832A19C1c1Aa124C)
**Sovereign Finance AVC**
[Signature](https://etherscan.io/verifySig/34621) | - | [Link](https://forum.makerdao.com/t/juliachang-ad-recognition-submission/23507) | | StoneWill | [Address](https://etherscan.io/address/0x72779c76bcC8DF6B7082f736f2C2BFba2db588f3)
[Signature](https://etherscan.io/verifySig/37256) | [Contract](https://etherscan.io/address/0x204A2B6ab6A675D1f82634F92799Ced2bDD641A2)
**Regenerative Finance AVC**
[Signature](https://etherscan.io/verifySig/37254) | [Contract](https://etherscan.io/address/0x911682CB21d7e5bdc75544fB1FCf0Fb8E9635AcF)
**KISS Finance AVC**
[Signature](https://etherscan.io/verifySig/37253) | - | [Link](https://forum.makerdao.com/t/stonewill-ad-recognition-submission/23782) | -| Rocky | [Address](https://etherscan.io/address/0xc31637bda32a0811e39456a59022d2c386cb2c85)
[Signature](https://etherscan.io/verifySig/40946) | [Contract](https://etherscan.io/address/0x2070cd766ba0d258081c0d3d027461dd3f6d2fa3)
**Sovereign Finance AVC**
[Signature](https://etherscan.io/verifySig/40938) | [Contract](https://etherscan.io/address/0x5FaC03E07447C1A3f4aD9A5f778f23C9e1fC4255)
**Resiliency AVC**
[Signature](https://etherscan.io/verifySig/40939) | - | [Link](https://forum.makerdao.com/t/rocky-aligned-delegate-recognition-submission/24148) | ¤¤¤ @@ -644,7 +400,7 @@ An Ecosystem Actor must publicly post a AD Recognition Submission Message on the ##### 6.2.1.2 -An Ecosystem Actor must deploy exactly 2 Protocol Delegation System smart contracts and specify which AVC Governance Strategy each of them follows as part of the submission message. +An applicant must deploy at least 1 Protocol Delegation System smart contract. ##### 6.2.1.3 @@ -652,7 +408,7 @@ The submission message must be cryptographically signed by the deploying Ethereu ###### 6.2.1.3.1 -Since an Ethereum address may only control a single Protocol Delegation System smart contract, Aligned Delegates should cryptographically demonstrate that they control the Ethereum address that controls each of their deployed Protocol Delegation System smart contracts. +Aligned Delegates should cryptographically demonstrate that they control the Ethereum address that controls their deployed Protocol Delegation System smart contract(s). ##### 6.2.1.4 @@ -668,22 +424,25 @@ A timestamp recording the time and date that the message was signed. ##### 6.2.1.5 +¤¤¤ +The Governance Facilitators must rework this document to be in line with the removal of AVCs. A single edit of this kind can be done at will by consensus of the Governance Facilitators, executed through directly modifying the content of this Document (6.2.1.5) + The submission message must follow this template: ``` Title: AD Recognition Submission AD Recognition Submission [Ecosystem Actor Ethereum address] -[Ethereum address of Delegation Contract 1]:[Followed AVC 1] -[Ethereum address of Delegation Contract 2]:[Followed AVC 2] -[Cryptographically signed AD Recognition Submission Message from the Ethereum address controlling Delegation Contract 1] -[Cryptographically signed AD Recognition Submission Message from the Ethereum address controlling Delegation Contract 2] -[Cryptographically signed AD Recognition Submission Message from the Ecosystem Actor Ethereum address, where this address is not one of the addresses controlling a Delegation Contract] +[Ethereum address of Delegation Contract +[Cryptographically signed AD Recognition Submission Message from the Ethereum address controlling Delegation Contract +[Cryptographically signed AD Recognition Submission Message from the Ecosystem Actor Ethereum address, where this address is not an address controlling a Delegation Contract] ``` +¤¤¤ + ### 6.3: Prime Delegate and Reserve Delegate Slots -The number of PD and RD slots is modifiable over time, and must be increased or decreased as the income of PDs increases or decreases, in accordance with the Atlas. The current number of PD and RD slots is specified in *6.3.1A*. This single number applies separately to the number of PDs, and RDs, and also determines (by taking its double) the amount of AVC Member reward slots. The Governance Facilitators can unanimously, directly increase or decrease the number with 1 every 3 months. The Governance Facilitators can trigger a weekly governance poll to change the number to a new arbitrary number. +The number of PD and RD slots is modifiable over time, and must be adjusted to align with the talent available. The current number of PD and RD slots is specified in *6.3.1A*. This single number applies separately to the number of PDs and RDs. The Governance Facilitators can unanimously, directly increase or decrease the number with 1 every 3 months. The Governance Facilitators can trigger a weekly governance poll to change the number to a new arbitrary number. #### 6.3.1A @@ -691,14 +450,10 @@ 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): -- 4 +- 3 ¤¤¤ -#### 6.3.2: Temporary Prime Delegate, Reserve Delegate, and AVC Member Compensation Modifications - -As a temporary measure, Prime Delegate, Reserve Delegate, and AVC Member Compensation is reduced by 20% from the amounts specified in the Atlas. - ## 7: FacilitatorDAOs and Facilitators The Governance Facilitators must ensure that all the rules of FacilitatorDAOs and Facilitators are followed as specified in *ATL2.7* @@ -707,13 +462,13 @@ The Governance Facilitators must ensure that all the rules of FacilitatorDAOs an Before the Launch of SubDAOs, Maker Governance directly chooses the Facilitators that are responsible for each of the Scopes. -#### 7.1.1: Core Units and Facilitator Management +#### 7.1.1: Facilitator Management -During the pregame, the Governance Scope manages and provides the budget for Core Units and Facilitators, while designating their responsible Scopes. +During the pregame, the Governance Scope manages and provides the budget for Facilitators, while designating their responsible Scopes. ##### 7.1.1.1 -The Ecosystem Actor name, Ethereum address and budgets are contained in *7.1.1.1.1A*. The Active Element is changed through the ordinary AVC process. Facilitator budgets are paid out even if the recipients are not active Facilitators, as long as they are using the budget to perform useful work for the Maker Ecosystem. +The Ecosystem Actor name, Ethereum address and budgets are contained in *7.1.1.1.1A*. The Active Element is changed through the ordinary MIP102 process. Facilitator budgets are paid out even if the recipients are not active Facilitators, as long as they are using the budget to perform useful work for the Maker Ecosystem. ###### 7.1.1.1.1A @@ -721,7 +476,7 @@ The Ecosystem Actor name, Ethereum address and budgets are contained in *7.1.1.1 List of Facilitator budgets: -| Facilitator | ETH Address | DAI per Month | MKR per Month | One Time Lump Sum (if applicable, only applies to March/April 2023) | +| Facilitator | ETH Address | DAI per Month | MKR per Month | | |---|---|---|---|---| | JanSky | 0xf3F868534FAD48EF5a228Fe78669cf242745a755 | 42,000 | 18 | N/A | | Endgame Edge | 0x9E72629dF4fcaA2c2F5813FbbDc55064345431b1 | 42,000 | 18 | N/A | @@ -733,7 +488,7 @@ 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. +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 MIP102 process. ##### 7.1.2.1A @@ -772,9 +527,9 @@ The Governance Facilitators can propose expedited onboarding of Reserve Facilita The Governance Facilitators must put in place processes to monitor the Ecosystem Actors for risks of conflict of interest between Advisory Council Members and Active Ecosystem Actors, and ensure that the Scope Artifacts and the checks they place on Active Ecosystem Actors are in Universal Alignment with the Atlas. -## 9: Interaction of Aligned Voter Committees (AVCs), Aligned Delegates (ADs), FacilitatorDAOs and Advisory Council +## 9: Interaction of Aligned Delegates (ADs), FacilitatorDAOs and Advisory Council -The Governance Facilitators must ensure to follow and enforce the principles described in *ATL2.9* to prevent misalignment of the core governance decision process. +The Governance Facilitators must ensure to follow and enforce the principles described in the Atlas to prevent misalignment of the core governance decision process. ## 10: Core Governance Security @@ -957,19 +712,11 @@ In case of unintended consequences or mistakes in the Atlas and Scope Artifacts The Governance Facilitators can at any time propose to edit any content of a Scope Artifact through a Governance Poll. -### 12.2: Aligned Delegate Privacy Transition - -As a one-time event, in the moment this version of the Scope Artifact is accepted by Maker Governance, all existing PDs and RDs receive one months payout at their prior rate of compensation, based on their ranking at the moment the Scope Artifact is accepted. - -### 12.3: Aligned Delegate bootstrapping Seasons - -The first Aligned Delegate season lasts from the moment this Scope Artifact is accepted, until the first deployment of the Sagittarius Engine. After the first deployment of the Sagittarius Engine, the next Aligned Delegate season then lasts until Q2 of the following year. - ### 12.4: Alignment Conserver (AC) Bootstrapping 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. +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. -Additionally, all ACs must devote significant work and resources towards the development of an AI-enabled Next Generation Atlas that is machine readable and has improved consistency and data quality. PDs, RDs and Facilitators must all generate and publish output that brings the community closer to being able to properly adopt a Next Generation Atlas solution. PDs have the highest such responsibility, followed by Facilitators, and then RDs. If an AC in a particular category is not outputting work that is up to the same standard, and at the same frequency and volume, as the majority of the ACs in their category, they can be considered misaligned and derecognized by the Governance Facilitators after a warning. AVCs must devote the majority of their time and energy towards discussing and understanding how the Next Generation Atlas will work and how to incorporate AI efficiently into long term governance and AVC operations, as well as assisting in the creation of the Next Generation Atlas. This priority supersedes their other responsibilities, and if an AVC Member has been deeply involved in Atlas creation and improvement, they can be made completely exempt from other AVC duties, when qualifying for AVC Member compensation. This exemption is determined retroactively by a Governance Facilitator when calculating AC compensation, and guidance for obtaining the exemption can be provided in advance given specific, Atlas-related KPIs, published by a Governance Facilitator. +All ACs must devote significant work and resources towards the development of an AI-enabled Next Generation Atlas that is machine readable and has improved consistency and data quality. PDs, RDs and Facilitators must all generate and publish output that brings the community closer to being able to properly adopt a Next Generation Atlas solution. PDs have the highest such responsibility, followed by Facilitators, and then RDs. If an AC in a particular category is not outputting work that is up to the same standard, and at the same frequency and volume, as the majority of the ACs in their category, they can be considered misaligned and derecognized by the Governance Facilitators after a warning. ### 12.5: Multiple Conflicting Atlas Edit Proposals