Skip to content

Commit

Permalink
Merge pull request #2 from makerdao/master
Browse files Browse the repository at this point in the history
update ref
  • Loading branch information
Niklas Kunkel authored Jul 25, 2020
2 parents 2ab1885 + 54fe85c commit 072c34f
Show file tree
Hide file tree
Showing 19 changed files with 679 additions and 111 deletions.
39 changes: 39 additions & 0 deletions .github/workflows/main.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
# This is a basic workflow to help you get started with Actions

name: IPFS

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
branches: [ master, RFC, Accepted ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
# This workflow contains a single job called "build"
build:
# The type of runner that the job will run on
runs-on: ubuntu-latest

# Steps represent a sequence of tasks that will be executed as part of the job
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2

- name: Upload to IPFS
uses: aquiladev/[email protected]
with:
# Directory path to upload
path: ../mips
# Type of target service to upload. Supported services [ipfs]
service: ipfs # optional, default is ipfs
# IPFS host
host: ipfs.komputing.org # optional, default is ipfs.komputing.org
# IPFS port
port: 443 # optional, default is 443
# IPFS protocol
protocol: https # optional, default is https
# Request timeout
timeout: 60000 # optional, default is 60000
# Level of verbosity
verbose: true
58 changes: 58 additions & 0 deletions MIP0/MIP0c12-Subproposals/MIP0c12-SP2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,58 @@
# MIP0c12-SP2: Subproposal for Core Personnel Onboarding (Governance Facilitator)

## Preamble
```
MIP0c12-SP#: 2
Author: LongForWisdom
Contributors: n/a
Status: Accepted
Date Applied: 2020-05-04
Date Ratified: 2020-05-28
---
Core Personnel Role: Governance Facilitator
Proposed applicant: LongForWisdom
```

## Application Form

### Motivation

My first impressions of this when Rich suggested it were ‘your job is horrible, why would I want to do it?’ That said, there are some fairly compelling reasons why I feel like I should do it.
- It’s a concrete step towards decentralization of the DAO.
- Rich is overworked, and is often not able to give the role his full attention (though to be fair, he does a great job of balancing it with his other responsibilities.) Having a second facilitator should help to increase coverage.
- At this stage, there don’t appear to be viable alternative candidates (this is not meant to throw shade on anyone/everyone, if you disagree, please make yourself known.)

The plan has always been to have multiple facilitators sharing the work and representing different geographic groups. My hope is that we can get there as quickly as possible, but ultimately someone has to be first.

So, with all this in mind, I’d be willing to take the role, if you’ll all have me. Once we have other Facilitators in place, I may re-evaluate and either decide to step down or aim to move into a different role.

To mitigate slightly the whole 'this job is horrible' thing above: that's a rather over-exaggerated view. I expect to enjoy the role in the general case (or I wouldn't be agreeing to it), and I am completely happy to take on the responsibility for the foreseeable future.

---

### Credentials
- Long(ish) standing member of the MakerDAO community.
- Started several initiatives with the aim to improve the long-term prospects of MakerDAO.
- [Producing a Collateral Onboarding Document](https://forum.makerdao.com/t/governance-initiative-collateral-on-boarding-process/1344)
- [Bringing SourceCred to Maker for a trial](https://forum.makerdao.com/t/governance-initiative-experimenting-with-sourcecred/1345)
- [Governance at a Glance](https://forum.makerdao.com/t/governance-at-a-glance/84)
- [Maintaining Forums](https://forum.makerdao.com/t/forum-navigation-index/648)
- [Governance Documentation](https://community-development.makerdao.com/governance/common-topics)
- [Collateral Status Index](https://forum.makerdao.com/t/collateral-status-index/2231)
- [Signal Requests](https://forum.makerdao.com/t/meta-governance-signal-requests/55)

- Worked on several initiatives meant to improve the long-term prospects of MakerDAO.
- [Project Managing Mkrgov.science](https://forum.makerdao.com/t/governance-initiative-maker-governance-analytics-dashboard/1346)
- [Cleaning up Executive Audit documentation](https://community-development.makerdao.com/governance/executive-audit)
- [The MIPs Framework](https://github.com/LongForWisdom/mips)

- This thread produced by current governance facilitator Rich Brown: https://forum.makerdao.com/t/its-time-for-a-second-governance-facilitator/1998

---

### Relevant Information
- GitHub Account: [@LongForWisdom](https://github.com/LongForWisdom)
- MakerDAO Forum Account: [@LongForWisdom](https://forum.makerdao.com/u/longforwisdom/)
- Reddit Account: [@LongForWisdom](https://www.reddit.com/user/LongForWisdom)

---
5 changes: 5 additions & 0 deletions MIP0/mip0.md
Original file line number Diff line number Diff line change
Expand Up @@ -289,6 +289,11 @@ Entries into this list should follow the following template:
- **Core Role:** Governance Facilitator
- **Date Added:** 2019-09-09 ([Poll: Ratify the Interim Governance Facilitator Mandate](https://vote.makerdao.com/polling-proposal/qmvh4z3l5ymqgtfs6tifq3jpjx5mxgdfnjy6alewnwwvba))

- **Person Name:** LongForWisdom
- **Sub-proposal Number (MIP0c12-SP):** 2
- **Core Role:** Governance Facilitator
- **Date Added:** 2020-05-28 [Ratification Vote: Officially Ratify the MIP0c12-SP2 Subproposal for Onboarding a Second Governance Facilitator](https://mkrgov.science/executive/0x9713187b6d7c8d54ac041efdbac13d52c2120fb9)

2. **MIP Editors:**

- **Person Name:** Charles St.Louis
Expand Down
4 changes: 2 additions & 2 deletions MIP10/MIP10c15-Subproposal-Template.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ Date Ratified: <yyyy-mm-dd>
- Is it likely given the information provided that there are individuals who could identify this person? What order of magnitude?

### Light Feeds
**Reputation*
**Reputation**
- Does the organization have a strong reputation in the crypto community?
- What contributions has this organization made to the crypto ecosystem?
- Would including the organization as a Light Feed instill a sense of trust in the Oracles?
Expand All @@ -50,7 +50,7 @@ Date Ratified: <yyyy-mm-dd>
- Given the applicant's major investors, is there a risk adding this Light Feed would give a single investor too much influence over the Oracle protocol?
- Given the incorporation and domicile location of the organization, is there a risk adding this Light Feed would give a single jurisdiction too much influence over the Oracle protocol?

**Identity*
**Identity**
- Did the Oracle Team get in contact with the organization to confirm their application?

### Cost-Benefit
Expand Down
48 changes: 25 additions & 23 deletions MIP12/mip12.md
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,8 @@ Type: Technical, Process
Status: Accepted
Date Proposed: 2020-04-06
Date Ratified: 2020-05-02
Dependencies: MIP0, MIP3, MIP7, MIP10, MIP11
Last Amended: 2020-06-25
Dependencies: MIP0, MIP3, MIP7
Replaces: n/a
```

Expand All @@ -22,41 +23,41 @@ MIP12 defines the domain team and documentation requirements for adding or chang

## Paragraph Summary

This proposal defines the documentation requirements for the onboarding of a new collateral type to the Maker Protocol, more specifically, the risk teams' objectives and requirements to deliver it in a unified package risk construct.
This proposal defines the documentation and work requirements for the onboarding of new collateral types to the Maker Protocol, specifically the domain teams' objectives and requirements to deliver it in a unified MIP12 subproposal (MIP12-SP).

## Component Summary

**MIP12c1: Domain Team Requirements for Onboarding Collateral Type to the Maker Protocol**
Lists the required and optional domain teams involved in onboarding a collateral type to the Maker Protocol.
Lists the required and optional domain teams involved in onboarding a collateral type to the Maker Protocol as well as a high-level overview of the domain work required.

**MIP12c2: Proposing New Risk Parameters, Oracles, and Collateral Adapters**
A process component that defines a method, a template and the requirements for proposing new risk parameters, oracles or collateral adaptors.
A process component that defines a method, a template, and the requirements for proposing new risk parameters, oracles, or collateral adaptors for collateral types.

**MIP12c3: Collateral Type Checklist (Governance)**
Defines a checklist of actions that must be completed before and after governance approval of a collateral type.

## Motivation

This proposal will focus on the collateral onboarding process blueprint for submitting MIP12 Subproposals (MIP12-SPs). The subproposals allow any community member to propose new risk parameters, oracles, and adapters for a new, or existing collateral type. Additionally, it will also define priority polls and the overall collateral onboarding process requirements. Furthermore, it allows domain teams to execute on collateral onboarding via the executive vote. This is the last step that needs to be completed when you have the risk construct with risk parameters based on a risk model ratified through MIP11.
This proposal will focus on the collateral onboarding process blueprint for submitting MIP12 Subproposals (MIP12-SPs). Submitting MIP12 Subproposals is the final step before collateral types go through the governance cycle and ultimately get added to or rejected from the Maker Protocol. The Subproposal process is reserved for domain teams to propose new risk parameters, oracles, and adapters for a new, or existing collateral type. This proposal also details the involvement of the community greenlight polls (MIP9) and the overall collateral onboarding process requirements. Furthermore, it allows domain teams to execute on collateral onboarding via the executive vote.

## Specification / Proposal Details

### MIP12c1: Domain Team Requirements for Onboarding Collateral Type to the Maker Protocol

- **A Risk team** (elected through MIP7) builds and approves their risk construct based on a ratified general model from MIP11 (Collateral Onboarding General Risk Model Management).
- **A Smart Contracts team** (elected through MIP7) builds and approves its collateral adapter, medianizer, oracle security module and executive vote code and the technical risk assessments of these smart contracts.
- **An Oracles team** (elected through MIP7), updates the oracle operations through MIP10 (Oracle Management) and then approves of the currently active price feeds as well as builds and approves their oracle security audit/risk assessment.
- (Optional) **A Legal team** (elected through MIP7) has created and approved the legal risk assessment of the collateral type based on the work completed by the above domain teams.
- **A Risk team** (elected through MIP7) builds and approves risk constructs for the collateral types that have been greenlit through the MIP9 and MIP8 processes.
- **A Smart Contracts team** (elected through MIP7) builds and approves the collateral types' adapter, medianizer, oracle security module for collateral types that have been greenlit through the MIP9 and MIP8 processes. Additionally, the Smart Contracts domain team will create the executive vote code (spell) as well as the technical risk assessments of the aforementioned smart contracts.
- **An Oracles team** (elected through MIP7), updates the oracle operations for collateral types that have been greenlit through the MIP9 and MIP8 processes through MIP10 (Oracle Management). Additionally, the Oracles domain team approves the currently active price feeds as well as builds and approves their oracle security audit/risk assessment.
- (Optional) **A Legal team** (elected through MIP7) creates and approves the legal risk assessment of the collateral types based on the work completed by the above domain teams.

---

### MIP12c2: Proposing New Risk Parameters, Oracles, and Collateral Adapters

MIP12c2 is a Process MIP component that allows the any community member to propose new risk parameters, oracles, and adaptors for a new, or existing collateral type based on the work products of domain teams using a subproposal.
MIP12c2 is a process MIP component that allows any domain team to propose new risk parameters, oracles, and adaptors for a new, or existing collateral type based on the work products of domain teams using a subproposal.

MIP12c2 subproposals must contain the following three deliverables in the specification section:
1. A risk construct based on an active general risk model by a ratified risk team and the results of polls that define all risk parameters for the collateral type.
2. A security audit and risk assessment of a deployed and operational collateral adapter, medianizer, oracle security module and executive vote code by a smart contracts domain team.
1. A risk domain team creates a risk construct for the collateral type (which should, in most cases, be based on a general risk model) and, in some cases, the results of polls that define all risk parameters for the collateral type.
2. A security audit and risk assessment of a deployed and operational collateral adapter, medianizer, oracle security module, and executive vote code by a smart contracts domain team.
3. A security audit and risk assessment of the current status of the oracle price feeds for supporting the new collateral type by an oracle domain team.

MIP12c2 subproposals have the following parameters:
Expand All @@ -65,34 +66,35 @@ MIP12c2 subproposals must contain the following three deliverables in the specif

MIP12c2 subproposals must use the template located at **[MIP12c2-Subproposal-Template.md](MIP12c2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status.


---

### MIP12c3: Collateral Type Checklist for Governance Approval


**Before being approved by governance, the following must be prepared in advance:**

- The risk model/risk construct for the collateral type
- The risk construct for the collateral type
- The oracle solution for the collateral type

**After the collateral type has been approved by governance, the following actions are performed by the Smart Contracts Domain Team to formally implement the collateral type as a part of the Maker Protocol:**
**After the collateral type has been approved by governance, the Smart Contracts Domain Team conducts the following actions to formally implement the collateral type as a part of the Maker Protocol:**

- The Smart Contract Domain team creates the spell with the following bundled components generated from the risk model and the oracle solution:
- The **Smart Contract Domain team** creates the executive spell with the following bundled components generated from the risk construct and the oracle solution for the collateral type at hand:
- `ilk` - Vault type
- `debt ceiling` - the maximum amount of Dai that can be generated from Vault/collateral type.
- `stability fee` - a variable-rate fee on Dai that is generated from the collateral type's Vault.
- `debt ceiling` - the maximum amount of Dai that can be generated from the Vault/collateral type.
- `stability fee` - a variable-rate fee on Dai generated from the collateral type's Vault.
- `collateralization ratio` - the ratio between the value of the collateral and the value of the generated Dai for the specific collateral type Vault.
- `flipper` - for the specified collateral type
- `lot` - size for flip auction
- `beg` - min bid increase
- `min` bid increment
- `end` - max auction duration
- `ttl` - time duration before an auction ends after a bid
- **Collateral type Oracle**
- Specify the location of the Oracle Security Module (OSM) for the collateral type
- **Oracle Requirements:**
- Specify the location of the Oracle Security Module (OSM) for the collateral type.
- gem.join adaptor
- **Once the spell has been created, the code is executed and the following occurs:**
- The collateral type has been added to the Maker Protocol
- Vaults can now be created with the new collateral type

**Once the executive spell has been created, the code is executed once the Executive Governance Vote passes, and the delay period has passed. At this point, the:**
- The collateral type has been added to the Maker Protocol.
- Vaults can now be created with the new collateral type.

---
Loading

0 comments on commit 072c34f

Please sign in to comment.