MIP101: Maker Atlas Immutable Alignment Artifact
0: Definitions
Organizational Alignment
Ecosystem Intelligence
Aligned structure
Universal Alignment
Universal Alignment Assumption
Alignment Artifact Strength
Inner Incentive
Alignment Engineering
Letter of the rule vs spirit of the rule
Incentivized Alignment
Misalignment
Slippery Slope Misalignment
Scope
Alignment Artifact
Scope Bounded Mutable Alignment Artifact (Scope Artifact)
Atlas Immutable Alignment Artifact (The Atlas)
Alignment Conserver
Aligned Voter Committee (AVC)
Aligned Governance Strategy
Scope Advisory Councils
Aligned Scope Proposal
Aligned Delegate (AD)
Governance Strategy Link (GSL)
Facilitator
SubDAO
FacilitatorDAO
AllocatorDAO
MiniDAO
Aligned Voter Committee (AVC) Subcommittee Meeting
Communication Channel
Governance Scope (GOV)
Support Scope (SUP)
Protocol Scope (PRO)
Stability Scope (STA)
Accessibility Scope (ACC)
SubDAO Scope Bounded Mutable Alignment Artifacts
Governance Equilibrium
Endgame State
Easy Governance Frontend
Governance Participation Incentives
Lockstaking
Farming
Neural Tokenomics
Explicit Incentives
Implicit Incentives
Incentive Slack
Whole weeks
Strategic Perspective
Major and Minor SubDAOs
1: The Atlas
2: The Governance Scope - GOV
2.1: Scope Improvement - GOV1
2.1.1: The Governance Scope must have a customized strategy towards its display and interaction through the DAO Toolkit.
2.2: Atlas Immutable Alignment Artifact - GOV2
2.2.1: The principles for when Atlas interpretation is necessary, and how it is initiated.
2.2.2: Principles and processes that must be followed when deliberating and deciding on Atlas interpretations.
2.2.3: List of all settled Atlas interpretations with all necessary context.
2.3: Scope Bounded Mutable Alignment Artifacts - GOV3
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.
2.3.2: GOV3 must cover a ruleset for ossification of mutable elements, ensuring that significant changes to the Scopes take a long time and provide a lot of time for input.
2.3.3: There are multiple types of Scope elements:
2.3.4: The Article must contain a process for ecosystem participants to petition for an appeal where they believe a Scope is misaligned, and the process for the Governance Scope to accept and process appeals, including fees and conditions.
2.3.5: The Article must contain processes for how the outcome of appeals are recorded in Scope Artifacts
2.3.6: The Article must cover specific rules related to Ecosystem Agreement appeals.
2.4: Alignment Conservers - GOV4
2.4.1: Roles of the Alignment Conservers
2.4.2: Alignment Conservers Eligibility Requirements
2.4.3: Alignment Conservers may never collude or secretly organize to change the Alignment Artifacts or the governance dynamic of MakerDAO in general, except within the clearly delineated processes and frameworks of the Maker Core Alignment Artifact.
2.4.4: If an Alignment Conserver is discovered to act against the requirements outlined in 2.4.2 and its subelements their Alignment Conserver status must immediately be derecognized by the FacilitatorDAOs. GOV4 must specify the processes for derecognition so that they are fair and minimize risk for the Maker Ecosystem.
2.4.5: Alignment Conserver Anonymity and Privacy
2.5: Aligned Voter Committees - GOV5
2.5.1: Aligned Voter Committee (AVC) Role in the Governance process
2.5.2: Aligned Governance Strategies and Aligned Scope Proposals
2.5.3: Aligned Voter Committee Recognition Process
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.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.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.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.9: Aligned Voter Committee Support and Infrastructure
2.5.10: AVC Member participation rewards
2.5.11: Display of AVCs in EGFs
2.6: Aligned Delegates (ADs) - GOV6
2.6.1: Protocol Delegation Modules (PDMs)
2.6.2: Aligned Governance Strategy Links (GSLs)
2.6.3: Aligned Delegate (AD) Income and Participation Requirements
2.6.4: Default Display of Aligned Delegates (ADs) in the Easy Governance Frontend (EGF)
2.6.5: Aligned Delegate Alignment Risk Mitigation
2.6.6: Aligned Delegate Privacy
2.6.7: Aligned Delegate Charity
2.7: FacilitatorDAOs and Facilitators
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.
2.7.2: Assigning Responsibility of MakerDAO Alignment Artifacts to FacilitatorDAOs
2.7.3: Assigning Responsibility of SubDAO Scopes to FacilitatorDAOs
2.7.4: FacilitatorDAO Responsibility Rewards
Scope
Scope Weight
2.7.5: Facilitators
2.7.6: Decision making powers of FacilitatorDAOs
2.8: Professional Ecosystem Actors - GOV8
2.8.1: Advisory Council Member Ecosystem Actors
2.8.2: Active Ecosystem Actors
2.9: Interaction of Aligned Voter Committees (AVCs), Aligned Delegates (ADs), FacilitatorDAOs and Advisory Council - GOV9
2.9.1: AVC and AD Aligned Governance Strategy Links (GSLs)
2.9.2: Aligned Delegate support for Aligned Voter Committees
2.9.3: FacilitatorDAOs and Scope Advisory Councils
2.9.4: Prioritization of Self-Sustainable Continuous Improvement based on strong Advisory Council Scopes
2.10: Core Governance Security - GOV10
2.11: SubDAO Governance Security - GOV11
2.12: Scope Bootstrapping - GOV12
3: The Support Scope
3.1: Scope improvement - SUP1
3.1.1: The Support Scope must have a specialized Advisory Council that is able to propose improvements to the language of the Scope Artifact that increases its Alignment Artifact Strength and increase efficiency and security of the Maker Ecosystem.
3.1.2: 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
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
3.3.1 Core development and maintenance management and strategy.
3.3.2: Identification and development of standardized, common reusable modules.
3.3.5: Research and specification of best practice for using the DAO Toolkit by Scopes.
3.3.6: Monitoring of adherence with best practice and flagging to governance in case of issues.
3.3.7: Development of the client side Tookit AI systems for using the DAO Toolkit and interacting with the CAIS.
3.3.8: Contributor and Alignment Conserver privacy tools and support.
3.4: Core Artificial Intelligence System (CAIS) - SUP4
3.4.1: SUP4 must define a robust and aligned solution for the core model to ensure it will have the greatest possible positive impact on the ability of Maker Governance to strengthen the Alignment Artifacts and monitor all governance processes for alignment and efficiency. The Core Model must also be a powerful tool for the incubation and growth of the SubDAOs.
3.4.2: The CAIS must use a technical approach that is diversified, and continuously improved based on the latest science and practical experience of operating and using the CAIS.
3.4.3: SUP4 must maintain a well balanced model for token gating access to CAIS, weighted in favor of MKR holders but ensuring that SubDAO token holders can also access and unleash the benefit of CAIS for SubDAO governance, innovation and growth.
3.5: Budgets, Milestones and results reporting standardization - SUP5
3.5.1: SUP5 must develop and maintain best practices for how to ensure budgets are tightly connected to results and milestones, and that this connection is easy to understand and it is possible to comprehend whether a budget is performing or not.
3.5.2: SUP5 must ensure that there is adequate research into hidden risks that may compromise transparency over time or hide inadequate results.
3.5.3: SUP5 must ensure processes are in place for monitoring and flagging of failure to properly implement best practice to prevent risks.
3.5.4: SUP5 must contain a real time, up to date overview of all data and information relevant to understand budgets and the results they are producing.
3.6: SubDAO Incubation - SUP6
3.6.1: SUP6 must specify Genesis Scope template elements designed for FacilitatorDAOs, AllocatorDAOs and MiniDAOs, to ensure that they have everything they need from the moment they are incubated to function properly and carry out their specific roles.
3.6.2: There is always a Major SubDAO incubating, and as it is incubating the communication channels for its future community must be maintained and moderated, based on specifications provided in SUP6.
3.7: Ecosystem Actor Incubation - SUP7
3.7.1: Clear Incubation Objectives must be specified that describe what gaps and opportunities exist in the ecosystem that Maker Governance wants to promote new companies to inject innovation for.
3.7.2: SUP7 must specify a strong proposal review process that describes how Facilitators must review and choose Incubation Proposals. AVCs or MKR holders must not interfere or micromanage with the selection process beyond setting objective guidelines, as this creates significant risk misalignment.
3.7.3: A high quality milestone and budget review process must be defined that applies specifically to Incubating Ecosystem Actors, in addition to the regular requirements specified in SUP5.
3.7.4: Infrastructure for monitoring and recording currently incubating Ecosystem Actors.
3.7.5: Maker Governance is allowed to have a relatively granular influence on the long run development of the ecosystem through SUP7, and as a result it must be monitored for misalignment risks, and must develop checks and balances that are as robust as possible over time.
3.8: Ecosystem communication channels - SUP8
3.9: Ecosystem Agreements - SUP9
3.9.1: SUP9 must specify a standardized way to publish and formally agree to Ecosystem Agreements.
3.9.2: SUP9 must specify a process for Ecosystem Agreement standardization that ensures that recurring patterns are dealt with uniformly, and that deviations from established standard patterns will incur proportional penalties and still be treated in the standardized way.
3.9.3: SUP9 must cover the methods for Ecosystem Agreement enforcement.
3.9.4: SUP9 must cover dispute resolution and the appeals process.
3.10: Resilience Fund - SUP10
3.11: Resilience research and preparedness - SUP11
3.12: Purpose System - SUP12
3.12.1 The Maker Protocol emits 3 million NewGovToken per year for the Purpose System from the moment NewChain is launched.
3.12.2 SUP12 must cover the long term Purpose System and the process for allocating purpose funds to SubDAOs in the yearly purpose contest, from the moment NewChain is launched.
3.12.3: SUP12 must also cover the short term Purpose Fund process. This includes setting up an advisory group that can help allocate 40 million NewGovToken towards public good open source AI, with at least 10% going to more directly impactful public good initiatives. The Purpose Fund must be fully spent before 2033.
4: The Protocol Scope
4.1: Scope Improvement - PRO1
4.1.1: The Protocol Scope must have a specialized Advisory Council that is able to propose improvements to the language of the Scope Artifact that increases its Alignment Artifact Strength and increase efficiency and security of the Maker Ecosystem.
4.1.2: The Protocol Scope must have a customized strategy towards its display and interaction through the DAO Toolkit to make it maximally user friendly.
4.2: NewChain protocol specification, maintenance and upgrades - PRO2
4.2.1: General blockchain requirements:
4.3: NewChain native Governance mechanics and neural tokenomics - PRO3
4.3.1: The Core Pause Proxy of MakerDAO, has a governance delay defined by PRO3 and is used to hold external assets and perform forced liquidation or forced actions on SubDAOs.
4.3.2: The SubDAO proxies are core governance contracts that enable SubDAOs to take actions to create and control smart contracts. They have a security delay, and Maker Governance can veto their actions during this security delay. The safety measures around using the veto must be specified in PRO3.
4.3.3: NewGovToken and SubDAO tokens are covered by a protocol native token standard. As they are permanently inflationary, SubDAO tokens have a migration standard as they will need to migrate to new tokens in the long run when their supply gets too high.
4.3.4: The Incubator system creates new AllocatorDAOs and FacilitatorDAOs based on a fixed algorithm.
4.3.5: The Native token standard allows NewGovToken and SubDAO tokens, and other tokens made with the Native token standard, to embed their tokens into an NFT following the native NFT standard, or mint a new NFT and embed into it. A token standard NFT can have its tokens extracted from the NFT again through the NFT marketplace simulation which penalizes extracting tokens from the NFT if a lot of users are extracting at the same time. The income from the penalties are then earned by the remaining NFT holders, increasing the amount of tokens embedded in their NFT.
4.3.6: Native NewStable farms for farming NewGovToken and SubDAO tokens. Supports 4 modes of farming:
4.3.7: Maker Lockstake Engine
4.3.8: Facilitator Lockstake Engine
4.3.9: Allocator Lockstake Engine
4.3.10: MiniDAO Lockstake Engine
4.3.11: NewGovToken emissions
4.3.12: AllocatorDAO emissions
4.3.13: FacilitatorDAO emissions
4.3.14: MiniDAO Emissions
4.3.15: Elixirs
4.3.16: Axons
4.3.17: Dendrites
4.3.19: The Budget System
4.3.20: FacilitatorDAO Responsibility System
4.3.21: Budget Allocation System
4.4: Two-stage bridge - PRO4
4.4.1: Normal bridge operation by NewChain Validator Set
4.4.2: 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.3: The Fallback Multisig
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
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
4.6.1: 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
4.7: SubDAO Frontend client diversity - PRO7
4.8: The Dai Stablecoin - PRO8
4.9: Scope Bootstrapping - PRO9
5: The Stability Scope
5.1: Stability Scope improvement - STA1
5.1.1: The Stability Scope must have a specialized Advisory Council that is able to propose improvements to the language of the Scope Artifact that increases its Alignment Artifact Strength and increase efficiency and security of the Maker Ecosystem.
5.1.2: The Stability Scope must have a customized strategy towards its display and interaction through the DAO Toolkit to make it maximally user friendly.
5.2: Dai Stablecoin reference asset - STA2
5.2.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
5.3.1: The Base Rate is the base yearly increase in debt on Allocator Vaults and Sagittarius Lockstake Engine Vaults. The Base Rate is determined algorithmically based on the Dai Price Oracle and the Price Deviation Sensitivity algorithm.
5.3.2: The Dai Savings Rate is the rate Dai holders can earn on their Dai in the Dai Savings Rate smart contracts. It is determined algorithmically based on the Base Rate and the DSR Spread parameter.
5.3.3: 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 is a parameter that determines how to calculate the DSR. The DSR is calculated as Base Rate - DSR Spread.
5.4: Allocator Vaults - STA4
5.4.1: Allocator Vault Standard Valve
5.4.2: Allocator Vault Special Valves
5.4.3: 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
5.5.1: 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.
5.5.2: Arrangers are Ecosystem Actors that assist in the design and operation of Arranged Structures. They are generally prohibited from ever being in a position where they can cause damage or loss to the Maker Ecosystem, beyond delays or annoyance. They advise in the creation of Arranged Structures, and Arranged Structures must always have an Arranger attached to it, to perform reporting on it. All details related to this must be covered in PRO6. The Arrangers manage a restricted function on the Arranged Structure Conduit that allows them to send assets onwards to the predetermined blockchain account of the Arranged Structure.
5.5.3: 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
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
5.7.1: Capitalization Requirements
5.7.2: Market Requirements
5.8: Allocator Penalties - STA8
5.8.1: Penalty Rates
5.8.2: Forced Dilution
5.8.3: Forced Liquidation.
5.9: Surplus Buffer and Smart Burn Engine - STA9
5.9.1: 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 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: 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: 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: 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, 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
5.11: MKR backstop - STA11
5.11.1: STA11 must define an emissions rate for the MKR backstop function that prevents risk of sudden failure. This must be continuously assessed and improved to maximize stability of the system in worst case scenarios.
5.11.2: STA11 must define a maximum level of MKR emission per undercollateralization event. This must be continuously assessed and improved to maximize stability of the system in worst case scenarios.
5.11.3: The protocol must contain an override mechanism that allows Maker Governance to continue emitting MKR beyond the maximum level. STA11 must cover processes for research and principles for which situations it should and can be safely used.
5.11.4: The protocol must contain an MKR backstop halt mechanism that immediately halts the backstop event in case of severe risk of total failure.
5.11.5: In case the backstop limit is reached and not overridden, or in case the backstop is halted during the event, the Dai target price receives a haircut to settle the remaining bad debt of the system. STA11 must cover this worst case scenario and research ways the damage can be mitigated.
5.12: Dai Stablecoin decentralization - STA12
5.12.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: Sagittarius Engine Dai generation Risk Parameters - STA13
5.13.1: Hard liquidation ratio of 200%. At this collateralization level, vaults will be instantly liquidated.
5.13.2: 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
5.13.4: Debt Ceiling
5.13.5: Stability fee
5.14: Scope Bootstrapping - STA14
6: The Accessibility Scope
6.1: Scope improvement - ACC1
6.1.1: The Accessibility Scope must have a specialized Advisory Council that is able to propose improvements to the language of the Scope Artifact that increases its Alignment Artifact Strength and increase efficiency and security of the Maker Ecosystem.
6.1.2: The Accessibility Scope must have a customized strategy towards its display and interaction through the DAO Toolkit to make it maximally user friendly.
6.2: Brand identity - ACC2
6.3: Accessibility Reward System - ACC3
6.4: Accessibility assets - ACC4
6.5: Accessibility campaigns - ACC5
6.6: SubDAO frontend standards - ACC6
6.7: Easy Governance Frontend (EGF) requirements - ACC7
6.7.1: Design of the Easy Governance Frontend (EGF)
6.7.2: Delegation to Aligned Governance Strategies
6.7.3: Importance of Immutability
Last updated