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

**1.1.1.2: Advisory Council Members must be Ecosystem Actors that are not involved in any business activity that could result in a conflict of interest, either directly or indirectly. They must also have relevant skills for providing professional expert input on the content that the Accessibility Scope is covering.**

**1.1.1.3: The Accessibility Facilitators must periodically, when it is relevant, review the Advisory Council Applications, and if they find applications that are suitable, bring them to a vote through an MKR governance poll. Approved Advisory Council Members are added to 10.2.3.1:.**

**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: The current approved Accessibility Advisory Council Members are recorded in&#x20;*****1.1.1.5.1A*****.**

**1.1.1.5.1A:**

¤¤¤

Current list of Advisory Council Members:

N/A

¤¤¤

#### 1.1.2: Accessibility Advisory Council projects and funding

The Advisory Council is paid on a project basis to do specific work that improves all or specific parts of the Scope Framework.

**1.1.2.1: Each Quarter, if they deem it necessary, the Accessibility Facilitators must solicit proposals and find one or more suitable Advisory Council Member to perform a project that will result in output that can be used to improve the Scope Artifact. This work output will be presented to the AVC Subcommittee Meetings as input for their Aligned Scope Proposals. As many AVCs as possible should be supported this way, prioritized by the Accessibility Facilitators.**

**1.1.2.2: In case an ambiguous, uncertain or challenging situation arises related to the Scope Framework, the Accessibility Facilitators may publicly notify the Advisory Council Members to submit proposals for projects that aim to reactively specify the language of the Scope Framework to take into account the specific situation. The Accessibility Facilitators can then directly propose the change to the Scope Framework in a weekly governance poll.**

**1.1.2.3: The Advisory Council may produce work output that is not directly compatible with the formatting of the Scope Artifact. In this case the Accessibility Facilitators must either transcribe it themselves, or hire an Ecosystem Actor to perform the transcription. This role does not require pre approval by Maker Governance.**

#### 1.1.3: The Accessibility Facilitators may produce advisory input on the content of the Scope Artifacts themselves, as long as it is focused on improving process and governance content. They are prohibited from providing unilateral input on expert subject matter content.

#### 1.1.4: The Accessibility Facilitators have a budget available to pay for Advisory Council Projects per quarter. All spending must be limited to only what is deemed necessary and with a high probability of producing clearly measurable value, and this must transparently be accounted for in a forum post at least a week before any transaction occurs. The budget is contained in *1.1.4.1B*.

**1.1.4.1B:**

¤¤¤

Advisory Council project budget:

N/A

¤¤¤

### 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.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.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.1.3: 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**](http://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.1.4: 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.1.4.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.1.4.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.1.5: The budget available for the new brand and associated educational campaigns is specified in&#x20;*****2.1.1.5.1B*****. The new brand project budget 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, and the recipient address. The payment is then put to a Governance Poll following the weekly cycle and paid out in a weekly Executive Vote. Every time a payout is done, the remaining budget in 2.1.1.5.1B must be reduced to reflect the spent amount.**

**2.1.1.5.1B:**

¤¤¤

Remaining available one-time budget for the new brand project:

5 million DAI

¤¤¤

**2.1.1.6: Dai and MKR must remain as valid tokens and products, with no maintained brand presence beyond community assets 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.

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