MIP108: Accessibility Scope
0: The Accessibility Scope
The Accessibility Scope covers accessibility and distribution efforts, and regulates user-facing frontends of MakerDAO Core and SubDAOs. Operational rules are defined in the Accessibility Scope Artifact.
1: Scope Improvement
1.1: The Accessibility Advisory Council
The Accessibility Advisory Council is a group of Ecosystem Actors that have been approved by Maker Governance to carry out advisory work related to improving the content of the Accessibility Scope Artifact.
1.1.1: Accessibility Advisory Council Membership Management
Members of the Advisory Council are directly approved by Maker Governance through a governance poll, and must fulfill specific criteria.
1.1.1.1
The Accessibility Facilitators must ensure that potential Advisory Council Members can apply to be approved by Maker Governance, using an open process with clear instructions as per 1.1.1.3.
1.1.1.2
Advisory Council Members must be Ecosystem Actors that are not involved in any business, political, or other governance-related activity that could result in a conflict of interest, either directly or indirectly. They must also have relevant skills for providing professional expert input on the content that the Accessibility Scope is covering.
1.1.1.3
The Accessibility Facilitators must periodically, when it is relevant, review the Advisory Council Applications, and if they find applications that are suitable, bring them to a vote through an MKR governance poll. When Advisory Council Applications are posted on the Maker Forum, which must follow the template as per 1.1.2.4.1A, the Accessibility Facilitators have a review period of 30 days. During this review period, the applicant must host a Community Q&A and shall answer as many questions and doubts as possible.
1.1.1.3.1
The Accessibility Facilitators can extend this deadline, if necessary, by 15 days, provided they posted the justification in the Maker Forum.
1.1.1.3.2
Once the review period is ended, the Accessibility Facilitators must publish the response to the application on the Forum, along with a description of the reasoning behind the decision. If approved, the application will continue with the Governance Process and proceed to a vote as per 1.1.1.3.
1.1.1.3.3
Upon a successful vote, the Accessibility Facilitators must arrange a service contract with the Advisory Council member, which must be made public. Approved Advisory Council Members are added to 1.1.1.6.1A.
1.1.1.3.4
Approved Advisory Council members have a term of service of 18 months from the time they are approved by Maker Governance. If desired, the Advisory Council Member can submit a new application for re-election when their term has between 60 and 30 days remaining. The re-election application must also fulfill 1.1.2 requirements and will open a new review period of 30 days where the Maker Community can provide feedback. The applicant shall again host a Community Q&A and respond to as many questions and doubts as possible. If approved, the re-election application will continue with the Governance Process and proceed to a vote as per 1.1.1.3.
1.1.1.4
The Accessibility Facilitators may, if they deem it necessary, trigger a vote to remove an Advisory Council Member. If an Advisory Council Member has not done any paid work for the Scope for at least 1 year, then the Accessibility Facilitators can choose to remove them at will, if they deem it necessary.
1.1.1.5: Accessibility Advisory Council Requirements
1.1.1.5.1
Accessibility Advisory Council members can be individuals, groups of people, legal entities, or companies. They can be pseudonymous or known entities. Accessibility Advisory Council members must be aligned with the long-term goals of MakerDAO Endgame.
1.1.1.5.2
Desired competencies for members of the Accessibility Advisory Council, as many of the following as possible:
Marketing expertise with a focus on web3 communities, governance, and growth.
Proven ability to devise strategies to expand user bases and increase adoption.
Experience in managing and engaging web3 communities.
Proven ability to create user-friendly and visually appealing interfaces.
Deep technical expertise of decentralized, resilient technologies that can be used to serve frontends.
Growth marketing acumen with a proven track record of growing mature Web3 products.
Great commmunication skills with a proven ability to explain complex technical concepts in simple, easy to grasp terms.
Expertise in Stablecoin or DeFi Marketing.
Deep understanding of the Maker Ecosystem and its endgame goals.
Solid understanding of various social media and communication platforms, as well as best practices for engaging with audiences on these platforms.
1.1.1.6
The current approved Accessibility Advisory Council Members are recorded in 1.1.1.6.1A.
1.1.1.6.1A
¤¤¤
Current list of Advisory Council Members:
N/A
¤¤¤
1.1.2: Accessibility Advisory Council Recognition
1.1.2.1
In order to be eligible for the Accessibility Advisory Council as per 1.1.1.3, an Ecosystem Actor must post a recognition submission message publicly on the Maker Governance Forum.
1.1.2.2
The submission message must be cryptographically signed by the Ecosystem Actor address.
1.1.2.3
The cryptographically signed Accessibility Advisory Council Recognition Submission Messages must contain the information specified in 1.1.2.3.1 and 1.1.2.3.2.
1.1.2.3.1
The following text must be included: “[Name] Accessibility Advisory Council Recognition"
1.1.2.3.2
A timestamp recording the time and date that the message was signed.
1.1.2.4
The submission message must follow the template 1.1.2.4.1A
1.1.2.4.1A
1.1.3: Accessibility Advisory Council Projects and Funding
The Advisory Council is paid on a project basis to do specific work that improves all or specific parts of the Scope Framework.
1.1.3.1
Entities are encouraged to submit applications with the intention of enhancing a specific portion of the Scope Framework. Any entity can notice a problem in the Scope or something that can and should be improved and apply to undergo a process to suggest improvements. There are also sometimes specific pieces of advisory work listed in 1.1.3.2 that can be taken on by applicants. The Accessibility Facilitators should diligently encourage participants possessing relevant areas of expertise to actively engage in this process to the fullest extent possible. Accordingly, once this MIP is successfully passed, it is imperative that the Accessibility Facilitators promptly post a Request for Applicants to the forum within a period of 30 days. The Accessibility Facilitators may choose to utilize a Peer-to-Peer recruiting process, which involves allocating a portion of the Accessibility Advisory Council budget to incentivize ecosystem participants and community members to actively seek out applicants, providing comprehensive explanations of the process.
1.1.3.2: Advisory Work for Accessibility Advisory Council Members
None yet identified
1.1.3.3
Each Quarter, if they deem it necessary, the Accessibility Facilitators must solicit proposals and find one or more suitable Advisory Council Member to perform a project that will result in output that can be used to improve the Scope Artifact. This work output will be presented to the AVC Subcommittee Meetings as input for their Aligned Scope Proposals. As many AVCs as possible should be supported this way, prioritized by the Accessibility Facilitators. The Accessibility Facilitators must communicate in the first 15 days of a quarter if they believe no Advisory Council work is needed for that quarter.
1.1.3.4
In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Accessibility Facilitators may publicly notify the Advisory Council Members to submit proposals for projects that aim to reactively specify the language of the Scope Framework to take into account the specific situation. The Accessibility Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll.
1.1.3.5
The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Accessibility Facilitators must either transcribe it themselves, or hire an Ecosystem Actor to perform the transcription. This role does not require pre approval by Maker Governance.
1.1.4
The Accessibility Facilitators may produce advisory input on the content of the Scope Artifacts themselves, as long as it is focused on improving process and governance content. They are prohibited from providing unilateral input on expert subject matter content.
1.1.5
The Accessibility Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in 1.1.5.1B.
1.1.5.1B
¤¤¤
Applicants should note that budgets for Advisory Councils are intentionally accommodative across the board in order to avoid having to delay by a full monthly governance cycle in unforeseen circumstances. They are not meant to be fully spent, and attempts to spend full budgets are less likely to be approved.
The Advisory Council project budget is as follows:
¤¤¤
1.2: Accessibility Scope DAO Toolkit Integration
The Accessibility Scope DAO Toolkit module must be built to give a full and accessible overview of all data and processes relevant to the Accessibility Scope.
2: Brand Identity
The Accessibility Facilitators must populate this article with information, details and assets that cover all aspects of the brand identity.
2.1: New Brand
The Accessibility Facilitators are tasked with engaging with third party brand professionals to create a new brand for the Maker Ecosystem.
2.1.1
The new brand must be a complete overhaul that creates a unified brand identity.
2.1.2
The new brand must focus on the stablecoin product, and differentiate it based on its role in the AI-powered SubDAO ecosystem, which is enabled by blockchain technology and decentralization.
2.1.2.1
The rebrand must be used as an opportunity to level set the degree of decentralization possible in a scalable stablecoin, to avoid confusion with fully decentralized, unscalable stablecoins like rai or LUSD that have no exposure to Legal Recourse Assets or advanced governance.
2.1.2.2
The new brand must be developed alongside a new website and domain. The website must have a special funnel for users being redirected from MakerDAO.com focused on explaining the new brand to existing users. If the new brand is accepted, the IP rights of the website must be transferred to the Dai Foundation, or a similar entity.
2.1.2.3
The new brand must be launched alongside the launch of the NewStable and NewGovToken. They will be renamed according to the new brand.
2.1.2.3.1
When the new brand and associated website have been fully developed and are ready for launch, the Accessibility Facilitator must publish the relevant materials related to the new brand, and then trigger a governance poll following the Weekly Governance Cycle to ratify or reject the new brand.
2.1.2.3.1.1: If accepted, this governance poll will also instantly edit all Alignment Artifacts to modify the words used to be in line with the new brand. No changes to the logic of the Alignment Artifacts must be made, other than names and brand related descriptions and addition of brand-related descriptions. The rewritten Alignment Artifacts must be submitted alongside the other brand materials. This can also apply to the language of a proposal that is in the MIP102 process.
2.1.2.4
Dai and MKR must remain as valid tokens and products, with no actively maintained brand presence beyond community assets, educational material and their token names.
3: Accessibility Reward
The Accessibility Reward is a payment that SubDAOs and Ecosystem Actors can receive if they comply with the Accessibility brand guidelines and either hold NewStable directly or provide users access to NewStable or smart contracts that hold NewStable. There is no distinction between NewStable that is or isn’t earning DSR or SubDAO tokens.
3.1: Accessibility Reward Signup Process
Ecosystem Actors that hold NewStable or provide access to NewStable can sign up for the Accessibility Reward by posting a message on the Maker Core forum specifying the ethereum address for receiving the Accessibility Reward, and the means to independently, unambiguously track the amount of NewStable they hold or provide access to in real time, such as specifying wallets or smart contracts and proving the link to the receiving address, or using the built in referral code system of the DSR and SubDAO farms. The Ecosystem Actors that are actively earning the Accessibility Reward are specified in 3.1.1A. The Accessibility Facilitators can directly edit the active element at will and must update it when new Ecosystem Actors sign up. If an Ecosystem Actor that is signed up for the Accessibility Reward is found by the Accessibility Facilitators to not comply with the brand guidelines, they must be immediately removed.
3.1.1A
¤¤¤
List of Ecosystem Actors signed up for the Accessibility Reward:
N/A
¤¤¤
3.2: Accessibility Reward Parameters
3.2.1
Ecosystem Actors earn an Accessibility Reward equivalent to 0.15% per year of the NewStable they hold or provide access to while following the required brand guidelines.
3.2.1.1: Early Bird
The Accessibility Rewards are tripled to 0.45% until 5 million NewStable have been paid out as Accessibility Rewards to Ecosystem Actors.
3.2.2
SubDAOs earn an Accessibility Reward equivalent to 0.2% per year of the NewStable they hold or provide access to while following the required brand guidelines. This does not apply to NewStable held in Elixir.
3.2.3
The Accessibility Reward payouts are bundled into a weekly executive vote at the end of every quarter, after review by the Accessibility AVC Subcommittees.
4: Accessibility Communication Channels
Maker must maintain various communication channels to help with access and interaction of the Maker Ecosystem. These communication channels are distinct from the governance focused communication channels.
4.1: Accessibility Chat
The Accessibility chat is a chat platform that allows Maker and SubDAO community members to chat and interact, teaching newcomers about the system or discussing various technical details. It must be maintained as an external facing platform with tight moderation that preserves it as a friendly and safe space for interested outsiders, new and old users, community regulars, and ecosystem participants and businesses. To prevent the risk of exposing outsiders to politics, drama and toxic behavior, governance debate or emotional governance related statements must not be allowed, and would-be debaters must be referred to the AVC communication channels, or if necessary dealt with through moderation. “ELI5” governance discussion and communication related to onboarding into governance, AVCs and similar are considered relevant for accessibility and should be allowed.
4.2: Accessibility on External Platforms
MakerDAO must support the accessibility of the Maker Ecosystem by paying Ecosystem Actors to maintain accounts and channels on external platforms, such as Twitter and Telegram. These accounts may develop and share accessibility content that follows the brand guidelines.
4.3: Accessibility Communication Channel Budget
The Accessibility communication channel budget is used to maintain the tasks described in this Article.
4.3.1
The Accessibility communication channel budget is specified in 4.3.1.1A. It is a monthly recurring budget accessed through a keg. The Accessibility Facilitator can propose to modify the budget by posting a message in the Maker Core forum specifying the proposed new value, which triggers a Governance Poll in the Weekly Governance Cycle, that edits the value if it is accepted.
4.3.1.1A
¤¤¤
The Accessibility communication channel budget is:
0 Dai per month, implemented with dssvest.
¤¤¤
5: Accessibility Campaigns
The Accessibility Facilitators must research and develop a framework for long term Accessibility Campaigns.
6: SubDAO Frontend Standards
The Accessibility Facilitators must specify SubDAO frontend standards for security, user experience and required features.
SubDAO Frontends must always be available in fully decentralized, downloadable formats that can be run by users without reliance on a central intermediary.
7: Easy Governance Frontend Requirements
The Accessibility Facilitators must specify and enforce strict requirements for the Easy Governance Frontends that SubDAOs operate, to ensure they remain universally aligned with the Atlas.
8: Location Resilience
All frontends operated by Ecosystem Actors on behalf of SubDAOs, and all frontends operated by Ecosystem Actors that receive Accessibility Rewards are required to follow location filtering rules, or be penalized and/or lose access to the Accessibility Rewards.
Ecosystem Actors in the Maker Ecosystem are generally required to explore and execute options that are reasonably available to reduce exposure of their infrastructure to locations designated in this Article to be affected by filtering or blocking.
8.1: Limited Filtering
Limited filtering requires frontends operated by Ecosystem Actors to avoid displaying or describing features to users with IPs flagged for limited filtering.
8.1.1
Features that must be restricted from being displayed or described to users flagged for Limited Filtering:
8.1.1.1
SubDAO Farming
8.1.1.2
Dai Savings Rate
8.1.1.3
Governance Participation Rewards
8.1.1.4
Any other feature related to yield or rewards.
8.1.2
User IPs flagged for limited filtering are specified in 8.1.2.1A.
8.1.2.1A
¤¤¤
User IPs flagged for limited filtering:
USA
VPN users
¤¤¤
8.2: Full Block
Full block requires frontends operated by Ecosystem Actors to deny service of any kind to users with IPs flagged for Full Block.
8.2.1
User IPs flagged for Full Block are specified in 8.2.1.1A.
8.2.1.1A
¤¤¤
User IPs flagged for Full Block:
Cuba
Iran
Syria
North Korea
Crimea and Sevastopol
Donetsk People’s Republic
Luhansk People’s Republic of Ukraine
Kherson Oblast
Zaporizhzhia Oblast
¤¤¤
9: Launch Project
The Launch Project is a temporary bootstrapping effort led by the Accessibility Facilitators that must support the deployment of the early launch phases defined in PROXXX for 1.5 years, until the end of 2024.
The Launch Project must coordinate the development of the new brand with website, marketing and communications strategy, and effectively integrate the smart contract development of the ecosystem into the launch.
The Launch Project must develop key AI and governance technology, and secure partnerships with high value companies from relevant fields that can help rapidly anchor the ability of MakerDAO to use AI and governance technology.
The Launch Project must work to attract high-value advisory council members that are less traditionally prone to interact with the world of crypto.
The Launch Project is a one time exception to the requirements about maximum end-to-end transparency for all governance processes, Facilitator decisions and all budget spending defined by the Alignment Artifacts. The unique opportunity presented by the new brand and its coordinated and well-prepared release alongside the Beta Launch can have such an outsized impact on the long term potential of the overall ecosystem that the Launch Project must optimize for the best possible first impression. Additionally, the Launch Project must work to include key non-crypto partners and initially, during the earliest phases, shield them from the unfamiliar issues that exists uniquely in DAO governance and politics, so that they can successfully participate in the Beta Launch and learn to understand the system without distractions.
After the Beta Launch the Launch Project, when the first impression of the new brand and the overall launch process has been set, the Launch Project must follow higher standard of transparency with its future tasks. The long term focus must be on coordinating good marketing and launch processes around the next launch phases, while using communications and marketing to prepare the community for the increased governance participation potential of the Governance Participation Rewards launch, and driving growth to the Ecosystem, the SubDAOs, and Maker Governance.
The Launch Project may also deal with various initiatives related to regulatory outreach or legal resilience efforts in the ecosystem.
The Launch project must fund security and other critical infrastructure needs for the ecosystem, to the extent necessary during the bootstrapping phase.
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.
9.1.1B
¤¤¤
Initial one-time budget for the Launch Project:
40,000,000 DAI
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:
30,358,006.99 DAI
8,469.17 MKR - The MKR can at most be spent at the rate of 1000 MKR per month.
¤¤¤
Last updated