diff --git a/.gitmodules b/.gitmodules new file mode 100644 index 000000000..a6e888987 --- /dev/null +++ b/.gitmodules @@ -0,0 +1,3 @@ +[submodule "MIP22/tinlake-maker-lib"] + path = MIP22/tinlake-maker-lib + url = https://github.com/centrifuge/tinlake-maker-lib/ diff --git a/MIP0/MIP0c13-Subproposals/MIP0c13-SP1.md b/MIP0/MIP0c13-Subproposals/MIP0c13-SP1.md index 326bd0c0d..1c7165d83 100644 --- a/MIP0/MIP0c13-Subproposals/MIP0c13-SP1.md +++ b/MIP0/MIP0c13-Subproposals/MIP0c13-SP1.md @@ -24,4 +24,4 @@ This subproposal should in no way be seen as a condemnation of, or a reaction to ### Relevant Information [Meeting Summary](https://github.com/makerdao/community/blob/master/governance/governance-and-risk-meetings/summaries/episode-102.md#rich-brown) in which Rich annouced his intention to step away from his role at the Foundation. -Forum [thread](https://forum.makerdao.com/t/thank-you-rich-brown/3379) thanking Rich for his work. +Forum [thread](https://forum.makerdao.com/t/thank-you-rich-brown/3379) thanking Rich for his work. diff --git a/MIP10/MIP10c11-List-of-Oracle-Whitelists.md b/MIP10/MIP10c11-List-of-Oracle-Whitelists.md index a72a05cdd..8dc307a31 100644 --- a/MIP10/MIP10c11-List-of-Oracle-Whitelists.md +++ b/MIP10/MIP10c11-List-of-Oracle-Whitelists.md @@ -9,60 +9,118 @@ - **Date Joined:** Date the customer was added to the whitelist - **Email:** The point of contact with the customer for all issues relating to Oracles. - **Fee (Dai):** The monthly whitelisting fee in Dai. -- **Whitelisted Contract:** The Ethereum address of the whitelisted contract -- **Origin:** A link to the Governance Vote that added the customer to the Oracle whitelist. +- **Origin:** A link to the Governance Vote that added the customer to the Oracle whitelist. +- **ROMP:** The Responsible Oracle Migration Proposal +- **Whitelisted Contract:** The Ethereum address of the whitelisted contract ## Template Spec **Oracle Name:** < name in MIP10c5 > **Oracle Classification:** | < yyyy-mm-dd > | < email > | < # > | < address > | < link to MIP10c3/MIP10c9 > | +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :------- | :------------- | :-------- | :-------- | :------------------- | :----------------------------------- | :-------------------------- | +| < name > | < yyyy-mm-dd > | < email > | < # > | < address > | < link to MIP10c3/MIP10c9/MIP10c12 > | | ## Oracle Whitelists **Oracle Name:** BAT/USD **Oracle Classification:** Medianizer **Contract Address:** 0x18B4633D6E39870f398597f3c1bA8c4A41294966 -| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | -| :--------------| :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | -| Maker Protocol | 2019-11-18 | N/A | N/A | 0xB4eb54AF9Cc7882DF0121d26c5b97E802915ABe6 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------- | :-------- | :----------------------------------------- | :----------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0xB4eb54AF9Cc7882DF0121d26c5b97E802915ABe6 | N/A | [Vote](https://mkrgov.science/executive/0xf44113760c4f70afeeb412c63bc713b13e6e202e) | **Oracle Name:** BAT/USD **Oracle Classification:** Oracle Security Module **Contract Address:** 0xB4eb54AF9Cc7882DF0121d26c5b97E802915ABe6 -| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | -| :------------- | :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | -| Maker Protocol | 2019-11-18 | N/A | N/A | 0x65C79fcB50Ca1594B025960e539eD7A9a6D434A3 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :------------- | :------------- | :--------------------------- | :-------- | :----------------------------------------- | :----------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0x65C79fcB50Ca1594B025960e539eD7A9a6D434A3 | N/A |[Vote](https://mkrgov.science/executive/0xf44113760c4f70afeeb412c63bc713b13e6e202e) | +| DeFi Saver | 2020-07-03 | nikola.jankovic@decenter.com | ROMP | 0xeAa474cbFFA87Ae0F1a6f68a3aBA6C77C656F72c | [MIP10c9-SP2](https://github.com/makerdao/mips/blob/master/MIP10/MIP10c9-Subproposals/MIP10c9-SP2.md) | [Vote](https://mkrgov.science/executive/0x057d35a858d6350d10f714785baf5c07703dbd4c) | **Oracle Name:** BTC/USD **Oracle Classification:** Medianizer **Contract Address:** 0xe0F30cb149fAADC7247E953746Be9BbBB6B5751f -| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | -| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :-------------------------- | -| Set Protocol | 2020-04-25 | alex@setprotocol.com | ROMP | 0xbf63446ecF3341e04c6569b226a57860B188edBc | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmealoapl7e1yzabsobg9wckj3bs8hb8pgquc5jx7r8qpo) | -| dYdX | 2020-04-25 | contact@dydx.exchange | ROMP | 0x538038E526517680735568f9C5342c6E68bbDA12 | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmealoapl7e1yzabsobg9wckj3bs8hb8pgquc5jx7r8qpo) | +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :----------------------- | :-------------------------- | +| Maker Protocol | 2020-04-25 | N/A | N/A | 0xf185d0682d50819263941e5f4EacC763CC5C6C42 | N/A | [Vote](https://mkrgov.science/executive/0x872c49c9e90e4ac7f84452ca52161fddc849246e) | +| Set Protocol | 2020-04-25 | alex@setprotocol.com | ROMP | 0xbf63446ecF3341e04c6569b226a57860B188edBc | [pre-MIP](https://forum.makerdao.com/t/proposal-btcusd-oracle-set-protocol-dydx/2011)| [Vote](https://mkrgov.science/executive/0x3526a5858aa91c058a7084ae8ab6d323d2baebb8) | +| dYdX | 2020-04-25 | brendan@dydx.exchange | ROMP | 0x538038E526517680735568f9C5342c6E68bbDA12 | [pre-MIP](https://forum.makerdao.com/t/proposal-btcusd-oracle-set-protocol-dydx/2011) | [Vote](https://mkrgov.science/executive/0x3526a5858aa91c058a7084ae8ab6d323d2baebb8) | + +**Oracle Name:** BTC/USD +**Oracle Classification:** Oracle Security Module +**Contract Address:** 0xf185d0682d50819263941e5f4EacC763CC5C6C42 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :------------- | :------------- | :--------------------------- | :-------- | :----------------------------------------- | :----------------------- | :-------------------------- | +| Maker Protocol | 2020-04-30 | N/A | N/A | 0x65C79fcB50Ca1594B025960e539eD7A9a6D434A3 | N/A | [Vote](https://mkrgov.science/executive/0x872c49c9e90e4ac7f84452ca52161fddc849246e) | +| DeFi Saver | 2020-07-03 | nikola.jankovic@decenter.com | ROMP | 0xeAa474cbFFA87Ae0F1a6f68a3aBA6C77C656F72c | [MIP10c9-SP3](https://github.com/makerdao/mips/blob/master/MIP10/MIP10c9-Subproposals/MIP10c9-SP3.md) | [Vote](https://mkrgov.science/executive/0x057d35a858d6350d10f714785baf5c07703dbd4c) | **Oracle Name:** ETH/BTC **Oracle Classification:** Medianizer **Contract Address:** 0x81A679f98b63B3dDf2F17CB5619f4d6775b3c5ED -| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | -| :--------------| :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | -| tBTC | 2020-04-25 | N/A | ROMP | TBD | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmeymkw5rhenzsevpvnhequj9glvq6n5buzapyrvestcdg) | +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------- | :-------- | :----------------------------------------- | :---------------------- | :-------------------------- | +| tBTC | 2020-04-25 | N/A | ROMP | TBD | [pre-MIP](https://forum.makerdao.com/t/proposal-ethbtc-oracle-tbtc/2010) | [Vote](https://mkrgov.science/executive/0x3526a5858aa91c058a7084ae8ab6d323d2baebb8) | **Oracle Name:** ETH/USD **Oracle Classification:** Medianizer **Contract Address:** 0x64DE91F5A373Cd4c28de3600cB34C7C6cE410C85 -| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | -| :--------------| :------------- | :------------------- | :-------- | :----------------------------------------- | :-------------------------- | -| Maker Protocol | 2019-11-18 | N/A | N/A | 0x81FE72B5A8d1A857d176C3E7d5Bd2679A9B85763 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | -| Set Protocol | 2020-04-25 | alex@setprotocol.com | ROMP | 0x97C3e595e8f80169266B5534e4d7A1bB58BB45ab | [Governance Vote](https://vote.makerdao.com/polling-proposal/qmzfpgr8hwabpycsq6vnnzp2cebh8uzxjpor8rtzenhkop) | +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :----------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0x81FE72B5A8d1A857d176C3E7d5Bd2679A9B85763 | N/A | [Vote](https://mkrgov.science/executive/0xf44113760c4f70afeeb412c63bc713b13e6e202e) | +| Set Protocol | 2020-04-25 | alex@setprotocol.com | ROMP | 0x97C3e595e8f80169266B5534e4d7A1bB58BB45ab | [pre-MIP](https://forum.makerdao.com/t/proposal-whitelist-set-protocol-on-ethusd-oracle/2013) | [Vote](https://mkrgov.science/executive/0x3526a5858aa91c058a7084ae8ab6d323d2baebb8) | +| MCDEX | 2020-07-03 | contact@mcdex.io | ROMP | 0x12Ee7E3369272CeE4e9843F36331561DBF9Ae6b4 | [MIP10c9-SP4](https://github.com/makerdao/mips/blob/master/MIP10/MIP10c9-Subproposals/MIP10c9-SP4.md) | [Vote](https://mkrgov.science/executive/0x057d35a858d6350d10f714785baf5c07703dbd4c) | +| dYdX | 2020-08-02 | brendan@dydx.exchange | ROMP | 0x538038E526517680735568f9C5342c6E68bbDA12 | [MIP10c9-SP5](https://github.com/makerdao/mips/blob/master/MIP10/MIP10c9-Subproposals/MIP10c9-SP5.md) | [Vote](https://mkrgov.science/executive/0xf132619f3aa8fc35b256c089097e91a0c2b3902a) | **Oracle Name:** ETH/USD **Oracle Classification:** Oracle Security Module **Contract Address:** 0x81FE72B5A8d1A857d176C3E7d5Bd2679A9B85763 -| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | Origin | -| :------------- | :------------- | :-------- | :-------- | :----------------------------------------- | :-------------------------- | -| Maker Protocol | 2019-11-18 | N/A | N/A | 0x65C79fcB50Ca1594B025960e539eD7A9a6D434A3 | [Spell](https://etherscan.io/address/0xf44113760c4f70afeeb412c63bc713b13e6e202e#code) | \ No newline at end of file +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :------------- | :------------- | :--------------------------- | :------- | :----------------------------------------- | :----------------------- | :-------------------------- | +| Maker Protocol | 2019-11-18 | N/A | N/A | 0x65C79fcB50Ca1594B025960e539eD7A9a6D434A3 | N/A | [Vote](https://mkrgov.science/executive/0xf44113760c4f70afeeb412c63bc713b13e6e202e) | +| DeFi Saver | 2020-07-03 | nikola.jankovic@decenter.com | ROMP | 0xeAa474cbFFA87Ae0F1a6f68a3aBA6C77C656F72c | [MIP10c9-SP1](https://github.com/makerdao/mips/blob/master/MIP10/MIP10c9-Subproposals/MIP10c9-SP1.md ) | [Vote](https://mkrgov.science/executive/0x057d35a858d6350d10f714785baf5c07703dbd4c) | + +**Oracle Name:** KNC/USD +**Oracle Classification:** Medianizer +**Contract Address:** 0x83076a2F42dc1925537165045c9FDe9A4B71AD97 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :------------------------| :----------------------- | +| Maker Protocol | 2020-06-27 | N/A | N/A | 0xf36B79BD4C0904A5F350F1e4f776B81208c13069 | [MIP12c2-SP2](https://github.com/makerdao/mips/blob/master/MIP12/MIP12c2-Subproposals/MIP12c2-SP2.md) | [Vote](https://mkrgov.science/executive/0x9ef95251233e0586bf3b17f14d31e2a756454a0d) | + +**Oracle Name:** KNC/USD +**Oracle Classification:** Oracle Security Module +**Contract Address:** 0xf36B79BD4C0904A5F350F1e4f776B81208c13069 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :------------- | :------------- | :-------------------- | :------- | :----------------------------------------- | :-------------------------- | :------------------ | +| Maker Protocol | 2020-06-27 | N/A | N/A | 0x65c79fcb50ca1594b025960e539ed7a9a6d434a3 | [MIP12c2-SP2](https://github.com/makerdao/mips/blob/master/MIP12/MIP12c2-Subproposals/MIP12c2-SP2.md) | [Vote](https://mkrgov.science/executive/0x9ef95251233e0586bf3b17f14d31e2a756454a0d) | + +**Oracle Name:** MANA/USD +**Oracle Classification:** Medianizer +**Contract Address:** 0x681c4F8f69cF68852BAd092086ffEaB31F5B812c +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :------------------------| :----------------------- | +| Maker Protocol | 2020-07-28 | N/A | N/A | 0x8067259EA630601f319FccE477977E55C6078C13 | [MIP12c2-SP1](https://github.com/makerdao/mips/blob/master/MIP12/MIP12c2-Subproposals/MIP12c2-SP1.md) | [Vote](https://mkrgov.science/executive/0xf67de12cab72a3f3a2ece4caa99c53eb0ddff75d) | + +**Oracle Name:** MANA/USD +**Oracle Classification:** Oracle Security Module +**Contract Address:** 0x8067259EA630601f319FccE477977E55C6078C13 +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :------------------------| :----------------------- | +| Maker Protocol | 2020-07-28 | N/A | N/A | 0x65c79fcb50ca1594b025960e539ed7a9a6d434a3 | [MIP12c2-SP3](https://github.com/makerdao/mips/blob/master/MIP12/MIP12c2-Subproposals/MIP12c2-SP2.md) | [Vote](https://mkrgov.science/executive/0xf67de12cab72a3f3a2ece4caa99c53eb0ddff75d) | + + +**Oracle Name:** ZRX/USD +**Oracle Classification:** Medianizer +**Contract Address:** 0x956ecD6a9A9A0d84e8eB4e6BaaC09329E202E55e +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :------------------------| :----------------------- | +| Maker Protocol | 2020-06-27 | N/A | N/A | 0x7382c066801E7Acb2299aC8562847B9883f5CD3c | [MIP12c2-SP3](https://github.com/makerdao/mips/blob/master/MIP12/MIP12c2-Subproposals/MIP12c2-SP2.md) | [Vote](https://mkrgov.science/executive/0x9ef95251233e0586bf3b17f14d31e2a756454a0d) | + + +**Oracle Name:** ZRX/USD +**Oracle Classification:** Oracle Security Module +**Contract Address:** 0x7382c066801E7Acb2299aC8562847B9883f5CD3c +| Customer | Date Joined | Email | Fee (Dai) | Whitelisted Contract | MIP | Governance Vote | +| :--------------| :------------- | :-------------------- | :-------- | :----------------------------------------- | :------------------------| :----------------------- | +| Maker Protocol | 2020-06-27 | N/A | N/A | 0x65c79fcb50ca1594b025960e539ed7a9a6d434a3 | [MIP12c2-SP1](https://github.com/makerdao/mips/blob/master/MIP12/MIP12c2-Subproposals/MIP12c2-SP1.md) | [Vote](https://mkrgov.science/executive/0x9ef95251233e0586bf3b17f14d31e2a756454a0d) | \ No newline at end of file diff --git a/MIP10/MIP10c3-Subproposals/MIP10c3-SP5.md b/MIP10/MIP10c3-Subproposals/MIP10c3-SP5.md index 395521731..7f8e09529 100644 --- a/MIP10/MIP10c3-Subproposals/MIP10c3-SP5.md +++ b/MIP10/MIP10c3-Subproposals/MIP10c3-SP5.md @@ -5,7 +5,7 @@ Author(s): Niklas Kunkel (@NiklasKunkel) Contributors: Type: Process Component Oracle Team Name: Green -Status: RFC +Status: Formal Submission (FS) Date Proposed: 2020-08-05 Date Ratified: ``` @@ -78,4 +78,4 @@ This Oracle would provide the LRC/USD price as part of the collateral onboarding ### Summary -LRC has a decent distribution of sources over a multitude of different quotes that in combination provide a resilient mechanism for determining a price. That being said, the Oracle Team will continue to monitor new exchange listings and their volume growth in order to potentially append a 6th data source. \ No newline at end of file +LRC has a decent distribution of sources over a multitude of different quotes that in combination provide a resilient mechanism for determining a price. That being said, the Oracle Team will continue to monitor new exchange listings and their volume growth in order to potentially append a 6th data source. diff --git a/MIP10/MIP10c3-Subproposals/MIP10c3-SP6.md b/MIP10/MIP10c3-Subproposals/MIP10c3-SP6.md index 3968336d1..bd284f034 100644 --- a/MIP10/MIP10c3-Subproposals/MIP10c3-SP6.md +++ b/MIP10/MIP10c3-Subproposals/MIP10c3-SP6.md @@ -1,11 +1,11 @@ ## Preamble ``` -MIP10c3-SP#: 5 +MIP10c3-SP#: 6 Author(s): Niklas Kunkel (@NiklasKunkel) Contributors: Type: Process Component Oracle Team Name: Green -Status: RFC +Status: Formal Submission (FS) Date Proposed: 2020-08-05 Date Ratified: ``` @@ -70,4 +70,4 @@ This Oracle would provide the USDT/USD price as part of the collateral onboardin Unlike other regulated fiat-backed stablecoins, Tether stands out due to its unregulated nature and questionable backing. It makes little sense to hard-peg the value of USDT to $1 because there is no guarantee of solvency. This is in contrast to tokens like USDC, TUSD, or PAXOS which have much stronger guarantees. As such, the Oracle Team recommends a floating price USDT Oracle with active liquidations. -Being one of the most highly traded tokens in the Ethereum ecosystem, there are a plethora of data to choose from. While high volume and liquidity are always high priority items for Data Models, the Oracle Team focused additional attention towards segregating the USDT price from outsized influence to any single pair. Out of the six total sources, two are against BTC, two are against ETH, and two are against USD. This minimizes the impact of price distortions driven exclusively by BTC or ETH though not necessarily a combination of the two. Similarly the Oracle is also resilient to manipulation of lower liquidity fiat pairs on BitFinex and Kraken. \ No newline at end of file +Being one of the most highly traded tokens in the Ethereum ecosystem, there are a plethora of data to choose from. While high volume and liquidity are always high priority items for Data Models, the Oracle Team focused additional attention towards segregating the USDT price from outsized influence to any single pair. Out of the six total sources, two are against BTC, two are against ETH, and two are against USD. This minimizes the impact of price distortions driven exclusively by BTC or ETH though not necessarily a combination of the two. Similarly the Oracle is also resilient to manipulation of lower liquidity fiat pairs on BitFinex and Kraken. diff --git a/MIP10/MIP10c3-Subproposals/MIP10c3-SP7.md b/MIP10/MIP10c3-Subproposals/MIP10c3-SP7.md new file mode 100644 index 000000000..973e83e16 --- /dev/null +++ b/MIP10/MIP10c3-Subproposals/MIP10c3-SP7.md @@ -0,0 +1,48 @@ +## Preamble +``` +MIP10c3-SP#: 7 +Author(s): Niklas Kunkel (@NiklasKunkel) +Contributors: +Type: Process Component +Oracle Team Name: Green +Status: Formal Submission (FS) +Date Proposed: 2020-08-05 +Date Ratified: +``` + +## Specification + +### Introduction + +This Oracle would provide the PAX/USD price as part of the collateral onboarding process for PAX. + +### Oracle Data Model + + | Source | Asset Pair |Quorum | Feed Model | Oracle Model | + | :----------- | :------------ | :---: | :---------: | :----------: | + | 1 | PAX/USD | N/A | N/A | N/A | + + +### Oracle Supporting Data Model(s) + +N/A + +### Oracle Address +- Medianizer - Mainnet TBD +- Oracle Security Module (OSM) - Mainnet TBD + +### Supported Tools +- Setzer - N/A +- Omnia - N/A +- PAX/USD DSValue on Kovan Testnet - [0x437e95fef67f931e47279692812bfb35a127e0dc](https://kovan.etherscan.io/address/0x437e95fef67f931e47279692812bfb35a127e0dc) + +### Remaining Work + +- Deploy and configure DSValue and Oracle Security Module smart contracts to Mainnet +- Coordinate Feeds to upgrade to latest release candidate + +### Summary + +As a regulated fiat-backed stablecoin, PAX can be treated similarly to the manner the Maker Protocol handles USDC and TUSD. This is a relatively safe operation due to the redeemable guarantees of PAXOS for the underlying USD as well as the regulatory and legal guarantees surrounding the deposit trusts. + +This fixed value is meant to incentivize Dai generation as there is no risk of liquidation. Similarly this mechanism protects the Maker Protocol from triggering short-sighted liquidations when short-term blips such as a flash crash arise in the market when the $1 peg should soon thereafter recover in most circumstances. diff --git a/MIP10/MIP10c7-Subproposals/MIP10c7-SP1.md b/MIP10/MIP10c7-Subproposals/MIP10c7-SP1.md new file mode 100644 index 000000000..4e3651c51 --- /dev/null +++ b/MIP10/MIP10c7-Subproposals/MIP10c7-SP1.md @@ -0,0 +1,67 @@ +## Preamble +``` +MIP10c7-SP#: 1 +Author(s): Niklas Kunkel (@NiklasKunkel) +Contributors: +Oracle Team Name: Green +Status: Formal Submission +Date Proposed: 2020-09-12 +Date Ratified: +``` + +## Specification + +### Introduction + +As markets and liquidity profiles evolve, it is important to revisit Data Models for collateral assets to ensure they accurately reflect the new normal. + +*This proposal adds FTX (ETH/USD) and Uniswap (ETH/USDC) as price sources for the ETH/USD Oracle and removes Bitfinex (ETH/USDT).* + + +### Oracle Data Model + +| Source | Asset Pair | Quorum | Feed Model | Oracle Model | +| :------------ | :------------ | :----: | :---------: | :----------: | +| Binance | ETH/BTC | 13 | Median | Median | +| Bitstamp | ETH/USD | +| Coinbase | ETH/USD | +| FTX | ETH/USD | +| Gemini | ETH/USD | +| Kraken | ETH/USD | +| Uniswap | ETH/USDC | + + +### Oracle Supporting Data Model(s) + +### BTC/USD Data Model + +| Source | Asset Pair |Quorum | Feed Model | Oracle Model | +| :------------ | :------------ | :---: | :---------: | :----------: | +| Bitstamp | BTC/USD | 13 | Median | Median | +| Bittrex | BTC/USD | +| Coinbase | BTC/USD | +| Gemini | BTC/USD | +| Kraken | BTC/USD | + + +### USDC/USD +| Source | Asset Pair | Feed Model | +| :-------------- | :------------ | :----------: | +| 1 | N/A | N/A | + + +### Supporting Evidence + +DeFi has grown exponentially and Uniswap now does significant volume rivaling many centralized exchanges. Similarly, FTX has experienced remarkable growth and now boasts a significant Ethereum volume against USD. Meanwhile there is continued uncertainty over Tether's backing. + + +- What is better about the new Data Model? +This proposal would remove any dependency on USDT from the ETH/USD Data Model. +It also adds Uniswap as a source which as an AMM is very expensive for an attacker to manipulate. + +### Oracle Address +- Medianizer +- Oracle Security Module (OSM) + +### Supported Tools +- Setzer -3adfa65dfb926f41a451ee2ce60d48432e7ff69f - [Added FTX/Uniswap & Removed BitFinex](https://github.com/makerdao/setzer-mcd/commit/3adfa65dfb926f41a451ee2ce60d48432e7ff69f) \ No newline at end of file diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP1.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP1.md index 17f806f97..57c339163 100644 --- a/MIP10/MIP10c9-Subproposals/MIP10c9-SP1.md +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP1.md @@ -1,3 +1,5 @@ +# MIP10c9-SP1: Subproposal to Whitelist DeFi Saver for ETH/USD Oracle Access + ## Preamble ``` diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP10.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP10.md new file mode 100644 index 000000000..6ccb6643f --- /dev/null +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP10.md @@ -0,0 +1,39 @@ +## Preamble +``` +MIP10c9-SP#: 10 +Author(s): Artem K +Contributors: +Status: Formal Submission +Date Proposed: 2020-09-16 +Date Ratified: +``` + +## Specification + +### Introduction +Yearn's core product is Vaults which allow depositing certain assets which are then delegated to Strategies which farm and recycle the rewards back into the base asset. A more complex product is Delegated Vaults which leverage a certain asset to borrow another asset and delegate it to a Vault. + +We are currently building our second Maker-based vault that will leverage WBTC-A ilk in a similar manner to our yWETH vault that uses ETH-A ilk. It will maintain a Maker Vault and delegate the drawn DAI to the yearn DAI Vault. To make the strategy able to rebalance and unwind, we require access to the next OSM price. + +We'll be using a permissioned proxy contract should new strategies requiring the OSM emerge. It is controlled by yearn's governance. + +### Oracle Name +BTC/USD + +### Customer(s) +yearn finance - Andre Cronje (andre.cronje@yearn.finance) + +### Whitelist + yearn finance - 0x82c93333e4E295AA17a05B15092159597e823e8a - OSM + +### Requirements +For each customer address to be whitelisted: + - Is the contract source code verified on etherscan? yes + - Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? yes + - Is Oracle data written to storage? no + - If Oracle data is stored, is it stored in a private variable? not stored + - If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? not stored + +### Fee + +In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that. \ No newline at end of file diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP11.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP11.md new file mode 100644 index 000000000..81120bf80 --- /dev/null +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP11.md @@ -0,0 +1,46 @@ +## Preamble +## Preamble +``` +MIP10c9-SP#: 11 +Author(s): Desmond Ho, Anton Buenavista +Contributors: Desmond Ho, Anton Buenavista +Status: Formal Submission +Date Proposed: 2020-09-16 +Date Ratified: +``` + +## Disclaimer + +MIP10 is meant to handle all of the Oracle related actions. Unfortunately MIP10 has inconsistencies and doesn’t conform to the monthly governance cadence that the Maker Improvement Proposal framework is built around. This has generated a backlog of Oracle proposals. While MIP10 is refactored to conform to the regular MIP process, Oracle proposals such as this one will utilize the more liberal weekly governance cycle. While strictly speaking this makes them not subproposals, they are included in the subproposal archive as a point of provenance to serve as a paper trail. + +## Specification + +### Introduction + +KyberSwap has a Promo Token, facilitated by Kyber Network, that is used at hackathons and conferences to promote usage of its platform. 1 PT token is pegged to approximately 1 USD, and is priced against ETH. Hence, the v1 medianizer suited its purpose well and was used. + +### Oracle Name + +ETH/USD + +### Customer(s) + +Kyber Network - [hello@kyber.network](mailto:hello@kyber.network) + +### Whitelist + +PT Pricing Contract - 0xe1bdeb1f71b1cd855b95d4ec2d1bfdc092e00e4f - MedianETHUSD (0x64DE91F5A373Cd4c28de3600cB34C7C6cE410C85) + +### Requirements + +For each customer address to be whitelisted: + +* Is the contract source code verified on etherscan? yes +* Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? yes +* Is Oracle data written to storage? no +* If Oracle data is stored, is it stored in a private variable? no +* If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? no + +### Fee + +In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that. \ No newline at end of file diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP2.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP2.md index c960f25b8..60f5df66e 100644 --- a/MIP10/MIP10c9-Subproposals/MIP10c9-SP2.md +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP2.md @@ -1,3 +1,5 @@ +# MIP10c9-SP2: Subproposal to Whitelist DeFi Saver for BAT/USD Oracle Access + ## Preamble ``` diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP3.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP3.md index d25865c15..f28f48ca5 100644 --- a/MIP10/MIP10c9-Subproposals/MIP10c9-SP3.md +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP3.md @@ -1,3 +1,5 @@ +# MIP10c9-SP3: Subproposal to Whitelist DeFi Saver for WBTC/USD Oracle Access + ## Preamble ``` diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP6.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP6.md new file mode 100644 index 000000000..f85eaae4c --- /dev/null +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP6.md @@ -0,0 +1,39 @@ +## Preamble +``` +MIP10c9-SP#: 6 +Author(s): Artem K +Contributors: +Status: Formal Submission +Date Proposed: 2020-08-23 +Date Ratified: +``` + +## Specification + +### Introduction +Yearn's core product is Vaults ([example](https://etherscan.io/address/0xacd43e627e64355f1861cec6d3a6688b31a6f952#code)) which allow staking certain assets which are then delegated to Strategies ([example](https://etherscan.io/address/0xa069E33994DcC24928D99f4BBEDa83AAeF00B5f3#code)) which recycle the rewards back into the base asset. A more complex product is Delegated Vaults which leverage a certain asset to borrow an asset and delegate it to a Vault. + +We are currently building ([work in progress](https://etherscan.io/address/0x6f6194041f019c7fa21a6e35e4fb496b2d6e1e95#code)) such a delegated vault strategy for the ETH Vault. It will maintain a Maker Vault and and delegate the drawn DAI to the yearn DAI Vault. To make the strategy safer and more robust, we require an ability to incentivize people to save the Vault from liquidation. To verify this on chain, we need access to the next OSM price. + +We'll be using a permissioned proxy contract should new strategies requiring the OSM emerge. It is controlled by yearn's governance. + +### Oracle Name +ETH/USD + +### Customer(s) +yearn finance - Andre Cronje (andre.cronje@yearn.finance) + +### Whitelist + yearn finance - 0xCF63089A8aD2a9D8BD6Bb8022f3190EB7e1eD0f1 - OSM + +### Requirements +For each customer address to be whitelisted: + - Is the contract source code verified on etherscan? yes + - Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? yes + - Is Oracle data written to storage? no + - If Oracle data is stored, is it stored in a private variable? not stored + - If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? not stored + +### Fee + +In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that. \ No newline at end of file diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP7.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP7.md new file mode 100644 index 000000000..85bca3311 --- /dev/null +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP7.md @@ -0,0 +1,42 @@ +## Preamble +``` +MIP10c9-SP#: 7 +Author(s): Andrew Leone +Contributors: Nik Kunkel (@NiklasKunkel) +Status: Formal Submission +Date Proposed: 2020-09-09 +Date Ratified: +``` + +## Specification + +### Introduction +Opyn has outstanding insurance options for cDAI, cUSDC, aUSDC which utilize the v1 Maker medianizer oracle for the ETH/USD price. The ETH/USD price is required throughout each Opyn insurance option’s life to ensure that options are correctly collateralized and to calculate a settlement value upon an exercise of an option. The options are collateralized in ETH and pay out an amount of USDC or DAI, in ETH. + +Shutting off the v1 medianizer has paused the contracts as the price of ETH/USD is no longer being returned. The options expire on February 10, 2021 and June 30, 2021. Future options will not be deployed using the v1 medianizer as a price source and Opyn will not require the v1 medianizer after June 30, 2021. The v1 medianizer can be removed from the v2 medianizer whitelist after that date. + + +This proposal is to: +1. Whitelist the v1 Maker medianizer address with the v2 Maker medianizer. +2. Reconfigure the v1 medianizer to allow poke() to query the v2 medianizer for the ETH/USD medianizer price. peek() will return the value most recently queried from the v2 medianizer. + +### Oracle Name +- ETH/USD + +### Customer(s) +- Opyn - andrew@opyn.co + +### Whitelist +- Maker v1 Medianizer - 0x729D19f657BD0614b4985Cf1D82531c67569197B - Medianizer + +### Requirements +For each customer address to be whitelisted: + - Is the contract source code verified on etherscan? Yes + - Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? No + - Is Oracle data written to storage? Yes + - If Oracle data is stored, is it stored in a private variable? No + - If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? No + +### Fee + +In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that. \ No newline at end of file diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP8.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP8.md new file mode 100644 index 000000000..3b76a5e94 --- /dev/null +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP8.md @@ -0,0 +1,43 @@ +## Preamble +``` +MIP10c9-SP#: 8 +Author(s): Scott Winges +Contributors: Nik Kunkel (@NiklasKunkel) +Status: Formal Submission +Date Proposed: 2020-09-09 +Date Ratified: +``` + +## Specification + +### Introduction + +DDEX used the Maker medianizer oracle v1 for WBTC/USD price info prior to deprecation. The price is primarily used for determining the collateral status of loans, but is also used for several other information fields on the application. DDEX would use the v2 medianizer for the same purposes. + +### Oracle Name + +* WBTC/USD + +### Customer(s) + +* DDEX ([scott@ddex.io](mailto:scott@ddex.io)) + +### Whitelist + +``` +- DDEX - 0x4935B1188EB940C39e22172cc5fe595E267706a1 - Medianizer +``` + +### Requirements + +For each customer address to be whitelisted: + +* Is the contract source code verified on etherscan? yes +* Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? yes +* Is Oracle data written to storage? no +* If Oracle data is stored, is it stored in a private variable? no +* If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? n/a + +### Fee + +In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that. \ No newline at end of file diff --git a/MIP10/MIP10c9-Subproposals/MIP10c9-SP9.md b/MIP10/MIP10c9-Subproposals/MIP10c9-SP9.md new file mode 100644 index 000000000..c056d3b0f --- /dev/null +++ b/MIP10/MIP10c9-Subproposals/MIP10c9-SP9.md @@ -0,0 +1,43 @@ +## Preamble +``` +MIP10c9-SP#: 9 +Author(s): Matt Luongo +Contributors: Antonio Salazar Cardozo +Status: Formal Submission +Date Proposed: 2020-08-25 +Date Ratified: +``` + +## Specification + +### Introduction + +This is a proposal to update an existing address for the tBTC system's +`SatWeiPriceFeed` contract, which has already been whitelisted (see [the original +proposal](https://vote.makerdao.com/polling-proposal/qmeymkw5rhenzsevpvnhequj9glvq6n5buzapyrvestcdg)). + +The [old address](etherscan.io/address/0x3b995E9f719Cb5F4b106F795B01760a11d083823) can be decommissioned. + +### Oracle Name + +ETH/BTC + +### Customer(s) +- tBTC (matt@thesis.co, antonio@thesis.co) + +### Whitelist + +- tBTC - `0xA3F68d722FBa26173aB64697B4625d4aD0F4C818` - Medianizer + +### Requirements +For each customer address to be whitelisted: + +- Is the contract source code verified on etherscan? **yes** +- Is the Oracle data used in a permissioned manner that would prevent parasitic behavior? **yes** +- Is Oracle data written to storage? **no** +- If Oracle data is stored, is it stored in a private variable? n/a +- If Oracle data is stored, is the value accessible on-chain exclusively by the protocol? n/a + +### Fee + +In accordance with the Responsible Oracle Migration Proposal, fees are waived for the first year and determined by MKR Governance after that. \ No newline at end of file diff --git a/MIP12/MIP12c2-Subproposals/MIP12c2-SP3.md b/MIP12/MIP12c2-Subproposals/MIP12c2-SP3.md index a366ec241..b7ac4cffe 100644 --- a/MIP12/MIP12c2-Subproposals/MIP12c2-SP3.md +++ b/MIP12/MIP12c2-Subproposals/MIP12c2-SP3.md @@ -7,9 +7,9 @@ MIP12c2-SP: 3 Title: Domain work requirements for onboarding the MANA collateral type Author(s): Cyrus Younessi (@DonutJr), Niklas Kunkel (@NiklasKunkel), Mariano Conti (@nanexcool) Contributors: Charles St.Louis (@CPSTL) -Status: Formal Submission (FS) +Status: Accepted Date Proposed: 2020-07-08 -Date ratified: +Date ratified: 2020-07-28 ``` ## Specification diff --git a/MIP12/MIP12c2-Subproposals/MIP12c2-SP4.md b/MIP12/MIP12c2-Subproposals/MIP12c2-SP4.md index 50f662bbe..92be8c5c5 100644 --- a/MIP12/MIP12c2-Subproposals/MIP12c2-SP4.md +++ b/MIP12/MIP12c2-Subproposals/MIP12c2-SP4.md @@ -16,21 +16,21 @@ Date ratified: ### Summary -This proposal defines the documentation and work requirements for the onboarding of the [LRC Collateral type](https://etherscan.io/token/0xbbbbca6a901c926f240b89eacb641d8aec7aeafd#readContract) to the Maker Protocol, explicitly highlighting the domain teams' objectives and work requirements needed to get it implemented to the Maker Protocol. If this proposal is ratified, the LRC collateral type will be added to the Maker Protocol allowing anyone to lock LRC in a Maker Vault to generate Dai. +This proposal defines the documentation and work requirements for the onboarding of the [LRC Collateral type](https://etherscan.io/token/0xbbbbca6a901c926f240b89eacb641d8aec7aeafd#readContract) to the Maker Protocol, explicitly highlighting the domain teams' objectives and work requirements needed to get it implemented to the Maker Protocol. If this proposal is ratified, the LRC collateral type will be added to the Maker Protocol allowing anyone to lock LRC in a Maker Vault to generate Dai. ### Proposal Details This subproposal contains the domain work products required for the LRC collateral asset to be added to the Maker Protocol. More specifically, it includes the risk parameters, oracle solutions, and the necessarily smart contracts required for the successful onboarding of LRC. -1. **Risk Domain Work:** The risk domain team's work contains the following risk construct/evaluation for the LRC collateral type: +1. **Risk Domain Work:** The risk domain team's work contains the following risk construct/evaluation for the LRC collateral type: - [[LRC] Collateral Onboarding Risk Evaluation](https://forum.makerdao.com/t/lrc-mip12c2-sp2-collateral-onboarding-risk-evaluation/3549) -2. **Smart Contracts Domain Work:** The smart contracts domain team's work required to get LRC added to the Maker Protocol includes an assessment of the general and technical information about the LRC token, a risk summary, formal verification considerations, audits & related documentation, a contract logic summary, administrative addresses, and lastly a contract risk summary. The full assessment can be viewed below: +2. **Smart Contracts Domain Work:** The smart contracts domain team's work required to get LRC added to the Maker Protocol includes an assessment of the general and technical information about the LRC token, a risk summary, formal verification considerations, audits & related documentation, a contract logic summary, administrative addresses, and lastly a contract risk summary. The full assessment can be viewed below: - [[LRC] ERC20 Token Smart Contract Domain Team Assessment](https://forum.makerdao.com/t/lrc-erc20-token-sc-domain-team-assessment/3471) -3. **Oracles Domain Work:** The oracles domain team's work required to get LRC added to the Maker Protocol, includes making sure the oracle price feeds to support the new collateral type are prepared. The full assessment can be viewed below: +3. **Oracles Domain Work:** The oracles domain team's work required to get LRC added to the Maker Protocol, includes making sure the oracle price feeds to support the new collateral type are prepared. The full assessment can be viewed below: - [[LRC] Oracle Domain Team Assessment](https://forum.makerdao.com/t/mip10c3-sp5-proposal-lrcusd-oracle-collateral-onboarding-oracle-assessment/3540) diff --git a/MIP12/MIP12c2-Subproposals/MIP12c2-SP5.md b/MIP12/MIP12c2-Subproposals/MIP12c2-SP5.md index 442ead02d..dd19566cf 100644 --- a/MIP12/MIP12c2-Subproposals/MIP12c2-SP5.md +++ b/MIP12/MIP12c2-Subproposals/MIP12c2-SP5.md @@ -16,21 +16,21 @@ Date ratified: ### Summary -This proposal defines the documentation and work requirements for the onboarding of the [COMP Collateral type](https://etherscan.io/token/0xc00e94cb662c3520282e6f5717214004a7f26888) to the Maker Protocol, explicitly highlighting the domain teams' objectives and work requirements needed to get it implemented to the Maker Protocol. If this proposal is ratified, the COMP collateral type will be added to the Maker Protocol allowing anyone to lock COMP in a Maker Vault to generate Dai. +This proposal defines the documentation and work requirements for the onboarding of the [COMP Collateral type](https://etherscan.io/token/0xc00e94cb662c3520282e6f5717214004a7f26888) to the Maker Protocol, explicitly highlighting the domain teams' objectives and work requirements needed to get it implemented to the Maker Protocol. If this proposal is ratified, the COMP collateral type will be added to the Maker Protocol allowing anyone to lock COMP in a Maker Vault to generate Dai. ### Proposal Details This subproposal contains the domain work products required for the COMP collateral asset to be added to the Maker Protocol. More specifically, it includes the risk parameters, oracle solutions, and the necessarily smart contracts required for the successful onboarding of COMP. -1. **Risk Domain Work:** The risk domain team's work contains the following risk assessment for the COMP collateral type: +1. **Risk Domain Work:** The risk domain team's work contains the following risk assessment for the COMP collateral type: - [[COMP] Risk Domain Team Assessment](https://forum.makerdao.com/t/comp-collateral-onboarding-risk-evaluation/4049) -2. **Smart Contracts Domain Work:** The smart contracts domain team's work required to get COMP added to the Maker Protocol includes an assessment of the general and technical information about the COMP token, a risk summary, formal verification considerations, audits & related documentation, a contract logic summary, administrative addresses, and lastly a contract risk summary. The full assessment can be viewed below: +2. **Smart Contracts Domain Work:** The smart contracts domain team's work required to get COMP added to the Maker Protocol includes an assessment of the general and technical information about the COMP token, a risk summary, formal verification considerations, audits & related documentation, a contract logic summary, administrative addresses, and lastly a contract risk summary. The full assessment can be viewed below: - [[COMP] ERC20 Token Smart Contract Domain Team Assessment](https://forum.makerdao.com/t/comp-erc20-token-smart-contract-domain-community-assessment/3587) -3. **Oracles Domain Work:** The oracles domain team's work required to get COMP added to the Maker Protocol, includes making sure the oracle price feeds to support the new collateral type are prepared. The full assessment can be viewed below: +3. **Oracles Domain Work:** The oracles domain team's work required to get COMP added to the Maker Protocol, includes making sure the oracle price feeds to support the new collateral type are prepared. The full assessment can be viewed below: - [[COMP] Oracle Domain Team Assessment](https://forum.makerdao.com/t/mip10c3-sp9-proposal-compusd-oracle-collateral-onboarding-oracle-assessment/4045) @@ -44,4 +44,4 @@ The goal of this proposal is to provide transparency to the Maker Community as t - [Collateral Status Index](https://forum.makerdao.com/t/collateral-status-index/2231) ---- \ No newline at end of file +--- diff --git a/MIP12/MIP12c2-Subproposals/MIP12c2-SP6.md b/MIP12/MIP12c2-Subproposals/MIP12c2-SP6.md index 09b850dce..3460a9472 100644 --- a/MIP12/MIP12c2-Subproposals/MIP12c2-SP6.md +++ b/MIP12/MIP12c2-Subproposals/MIP12c2-SP6.md @@ -16,21 +16,21 @@ Date ratified: ### Summary -This proposal defines the documentation and work requirements for the onboarding of the [LINK Collateral type](https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca) to the Maker Protocol, explicitly highlighting the domain teams' objectives and work requirements needed to get it implemented to the Maker Protocol. If this proposal is ratified, the LINK collateral type will be added to the Maker Protocol allowing anyone to lock LINK in a Maker Vault to generate Dai. +This proposal defines the documentation and work requirements for the onboarding of the [LINK Collateral type](https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca) to the Maker Protocol, explicitly highlighting the domain teams' objectives and work requirements needed to get it implemented to the Maker Protocol. If this proposal is ratified, the LINK collateral type will be added to the Maker Protocol allowing anyone to lock LINK in a Maker Vault to generate Dai. ### Proposal Details This subproposal contains the domain work products required for the LINK collateral asset to be added to the Maker Protocol. More specifically, it includes the risk parameters, oracle solutions, and the necessarily smart contracts required for the successful onboarding of LINK. -1. **Risk Domain Work:** The risk domain team's work contains the following risk assessment for the LINK collateral type: +1. **Risk Domain Work:** The risk domain team's work contains the following risk assessment for the LINK collateral type: - [[LINK] Risk Domain Team Assessment](https://forum.makerdao.com/t/link-collateral-onboarding-risk-evaluation/4047/2) -2. **Smart Contracts Domain Work:** The smart contracts domain team's work required to get LINK added to the Maker Protocol includes an assessment of the general and technical information about the LINK token, a risk summary, formal verification considerations, audits & related documentation, a contract logic summary, administrative addresses, and lastly a contract risk summary. The full assessment can be viewed below: +2. **Smart Contracts Domain Work:** The smart contracts domain team's work required to get LINK added to the Maker Protocol includes an assessment of the general and technical information about the LINK token, a risk summary, formal verification considerations, audits & related documentation, a contract logic summary, administrative addresses, and lastly a contract risk summary. The full assessment can be viewed below: - [[LINK] ERC20 Token Smart Contract Domain Team Assessment](https://forum.makerdao.com/t/link-erc20-token-smart-contract-technical-assessment/3467) -3. **Oracles Domain Work:** The oracles domain team's work required to get LINK added to the Maker Protocol, includes making sure the oracle price feeds to support the new collateral type are prepared. The full assessment can be viewed below: +3. **Oracles Domain Work:** The oracles domain team's work required to get LINK added to the Maker Protocol, includes making sure the oracle price feeds to support the new collateral type are prepared. The full assessment can be viewed below: - [[LINK] Oracle Domain Team Assessment](https://forum.makerdao.com/t/mip10c3-sp8-proposal-linkusd-oracle-collateral-onboarding-oracle-assessment/4039) @@ -44,4 +44,4 @@ The goal of this proposal is to provide transparency to the Maker Community as t - [Collateral Status Index](https://forum.makerdao.com/t/collateral-status-index/2231) ---- \ No newline at end of file +--- diff --git a/MIP13/MIP13c3-SP1.md b/MIP13/MIP13c3-SP1.md new file mode 100644 index 000000000..f4ee8db86 --- /dev/null +++ b/MIP13/MIP13c3-SP1.md @@ -0,0 +1,41 @@ +# MIP13c3-SP1: Declaration of Intent (Forward Guidance) + +## Preamble +``` +MIP13c3-SP#: 1 +Author(s): Akiva Dubrofsky (@akiva) +Contributors: @vitalyr +Status: Request for Comments (RFC) +Date Proposed: <2020-07-08> +Date Ratified: +``` + +## Specification + +### Context and Motivation + +- Aware, of the efforts within the Maker community by companies to help Vault users hedge their exposure to the base rate via various derivative contracts, + +- Acknowledging, the importance of the aforementioned services being necessary to the scalability of MakerDAO, due to the historic volatility in the DSR (and SF during SCD), + +- Recognizing, the necessity of Risk Teams and voters having the ability to react to any risk presented to the system at any time, and enact measures to protect the system, + +- Supporting, the ongoing work of providing full transparency and fairness to its users, + +The following is declared: + +### Declaration Detail + +1. MakerDAO will adjust the Risk Premia of specific collateral types in order to have proper System Surplus, and to avoid System Deficit, in the following list of scenarios: +a. A change deemed significant by a Risk Team in the nature of the collateral object +b. Some new piece of information is found previously unknown to a risk team +c. An event that was unforeseeable (“a black swan” event) +2. MakerDAO will, whenever possible, seek to minimize/mitigate any causal relationship between the actions of some given “Party A” (some user of Vaults) with some unrelated “Party B” (another Vault user’s) risk parameters. Whereas Party A and Party B have no relationship with one another other than merely both being users of the Maker system. +3. MakerDAO will not adjust Risk Parameters without due cause and proper consideration of its impacts on Vault users, specifically those sensitive to such changes. +4. The MakerDAO community, while reserving its right to react at any time to any given risk, will create a working group to identify particular factors that would result in events a,b,c, listed above in Article 1 thereby providing forward guidance to Vault users. In no situation will any list be considered exhaustive. + +This declaration is flexible in implementation while aiming to improve fairness for users. + +### Relevant Links +- https://forum.makerdao.com/t/soft-locks-and-future-guidance-a-pre-mip-discussion/2875 +- https://forum.makerdao.com/t/rate-stabilization-for-makerdao/2274 diff --git a/MIP13/MIP13c3-Subproposals/MIP13c3-SP1.md b/MIP13/MIP13c3-Subproposals/MIP13c3-SP1.md index d22ebb0ff..a9b6b5b50 100644 --- a/MIP13/MIP13c3-Subproposals/MIP13c3-SP1.md +++ b/MIP13/MIP13c3-Subproposals/MIP13c3-SP1.md @@ -5,7 +5,7 @@ MIP13c3-SP#: 1 Author(s): Akiva Dubrofsky (@akiva) Contributors: @vitalyr -Status: Formal Submission (FS) +Status: Request for Comments (RFC) Date Proposed: <2020-07-08> Date Ratified: Declaration Statement: MakerDAO intends to keep RP on Vaults as transparent and stable as possible. diff --git a/MIP13/MIP13c3-Subproposals/MIP13c3-SP2.md b/MIP13/MIP13c3-Subproposals/MIP13c3-SP2.md index 4029b85a1..25f581896 100644 --- a/MIP13/MIP13c3-Subproposals/MIP13c3-SP2.md +++ b/MIP13/MIP13c3-Subproposals/MIP13c3-SP2.md @@ -5,7 +5,7 @@ MIP13c3-SP#: 2 Author(s): Sam MacPherson (@hexonaut) Contributors: n/a -Status: Formal Submission (FS) +Status: Request for Comments (RFC) Date Proposed: 2020-08-11 Date Ratified: --- diff --git a/MIP13/MIP13c3-Subproposals/MIP13c3-SP3.md b/MIP13/MIP13c3-Subproposals/MIP13c3-SP3.md new file mode 100644 index 000000000..44cb66329 --- /dev/null +++ b/MIP13/MIP13c3-Subproposals/MIP13c3-SP3.md @@ -0,0 +1,119 @@ +# MIP13c3-SP3: Declaration of Intent - Strategic reserves fund (SRF) + +## Preamble + +``` +MIP13c3-SP#: 3 +Author(s): Sébastien Derivaux (@SebVentures) +Contributors: n/a +Status: Request for Comments (RFC) +Date Proposed: 2020-08-21 +Date Ratified: +--- +Declaration Statement: Creation of a Strategic Reserves Fund to have a financial power and autonomy +Declaration to Replace: n/a +``` + + +## Specification + +### Context and Motivation + +* Maker will need at some point financial resources to pay for its own expenses (observers and staff). Currently, the foundation is providing for that but it isn’t expected to last forever. +* DAI is insured by the surplus buffer (owned by MKR holders) and MKR issuance. The DAI surplus buffer can be redeemed by DAI holders with an ES. MKR issuance in time of crisis is detrimental to MKR holders as it can come with a low issuance price ([Maker buy and burn MKR when the price is high and issue MKR when the price is low](https://forum.makerdao.com/t/risk-of-pro-cyclical-mkr-issuance/1693)). +* Maker doesn’t have any financial resources to encourage DAI usage or enforce the peg. +* The strategic reserves fund (SRF) intent is to provide financial resources and processes to MakerDAO in order to address those 3 concerns. + +A poll on such idea gained support with the Maker community: [[Poll] Creation of a MakerDAO strategic reserves (solving the peg)](https://forum.makerdao.com/t/poll-creation-of-a-makerdao-strategic-reserves-solving-the-peg/3638). This Declaration of Intent is the next step. + +### Declaration Detail + +* The overall intent is to raise and manage Maker funds by defining a new component of Maker Protocol : The strategic reserves fund (SRF) +* Main goals of the SRF are: + * Allows MakerDAO to cover operational expenses in the future and stop being dependent on the foundation for that. + * Increase DAI product utility by conducting operations in the open markets (DAI product utility should be correlated with MKR price) + * Provide a revenue stream uncorrelated from DAI stability fees + * Provide funds in case of DAI subsystem failure to avoid issuing MKR at a low price and dilute existing MKR holders + * Due to the novelty and the complexity of the task, all implementation details provided here are only tentative and the final implementation can deviate. All details are provided for illustration on the intent. +* There are 4 subcomponents in the SRF intent: Fund raising, Strategy, Tactics and Gouvernance. +* The Maker Protocol is currently composed mainly (only?) by the DAI Credit System that contains all the vaults and the surplus buffer. The SRF is not connected to the DAI Credit System. The failure of one doesn’t impact the other (in case of ES, SRF is not affected). The net asset value of the SRF belongs to MKR holders with no recourse from DAI holders or vault owners. + +### Fund raising + +This intent recognizes that strategic reserves can’t be minted. The SRF will start with MKR tokens as assets. Those will be sold on the market as needed. A floor price will be decided by MakerDAO governance under which MKR can’t be sold in order to protect MKR price. + +3 sources of MKR are considered: + +* Issuance of a fixed amount of MKR tokens (e.g. 20k) at the creation of the SRF +* Transfer of some MKR tokens from the foundation in exchange of taking some foundation expenses (using a net present value of future expected expenses) +* Issuance of MKR tokens when MKR tokens are burnt through flap auctions (keeping the MKR outstanding amount fixed). This is the most likely way. An alternative would be to suck() DAI from the Surplus Buffer to the Strategic Reserves. + +### Strategy + +MakerDAO governance will set the strategy of the SRF as general guidance and operational boundaries with an on-chain vote. + +Initial guidance can be: + +* Main objective: Buy and burn MKR tokens when the price is cheap +* Secondary objective: Generate yield by providing liquidity to pools that improve DAI usability + +A boundary framework can be set as follow to begin with: + +* Allowed assets: + * MKR + * DAI + * USDC: max 50% of assets + * PAX: max 50% of assets + * TUSD: max 50% of assets + * ETH: max 10% of assets + * Uniswap liquidity pools: max 50% of assets, with underlying assets limits +* Allowed smart contracts: + * Maker Vaults + * Maker Oasis + * Uniswap trade: only to sell MKR tokens above $500 or to buy MKR tokens below $300 + * Uniswap liquidity pools +* Allowed external wallets: + * None +* Maximum amount per transaction: $110k + +### Tactics + +MakerDAO governance will also set the tactic that should be used to implement the strategy. While strategy contains broad objectives, hard boundaries and is not expected to change frequently, tactics are like a script to follow. The tactics can be changed more frequently depending on the environment while staying within the boundaries of the strategy. There can be many concurrent tactics. + +For instance, here is some tactics: + +#### MKR price protection + +* If net asset value of the reserves are > $10M and MKR price below the boundary framework ($300) + * Buy up to $100k MKR tokens per day on Uniswap + +#### DAI peg enabler + +* Sell up to $100k of MKR tokens per day to USDC on Uniswap with a selling price above $600. +* Add the proceed to a USDC-A vault +* Generate the maximum allowed DAI +* Sell those DAI to USDC, PAX and TUSD on Oasis. + * The selling price should be between 1.005 and 1.015 + * Inside this range, it should be the price obtained on coingecko for the previous day minus 0.1% + +The scripts are executed by the SRF gouvernance. The SRF governance is mandated to follow the script. It is nevertheless expected that unexpected circumstances will override the script by doing nothing and asking for MakerDAO to update the tactics. For example: strong suspicion on a USDC issue, USDC $ price outside of [0.995,1.005], ... + +### SRF Governance + +While tactics are implementations of the overall strategy, they are set in motion by the SRF governance. The SRF might be implemented as a multisig wallet that will require 4 out of 7 validators. + +Those 7 validators will represent the SRF governance. They are elected or removed by an on-chain vote by the MKR holders. + +The SRF Governance elect a Treasurer that will report each week the evolution of the SRF. A template report will be defined. + +There might be a need to create a [Treasury domain team](https://forum.makerdao.com/t/signaling-request-should-maker-make-a-treasury-to-manage-revenue/1122) in the future, espacially when the Strategic Reserves Fund will be used to pay for MakerDAO expenses (staff and oracles). This will also require work on MIP14: Protocol DAI Transfer. + +## Relevant Links + +* [[Poll] Creation of a MakerDAO strategic reserves (solving the peg)](https://forum.makerdao.com/t/poll-creation-of-a-makerdao-strategic-reserves-solving-the-peg/3638) +* [System Reserves](https://forum.makerdao.com/t/system-reserves/2069) +* [MIP14: Protocol DAI Transfer](https://forum.makerdao.com/t/mip14-protocol-dai-transfer/2462) +* [Signal Request: Increase System Surplus Threshold](https://forum.makerdao.com/t/signal-request-increase-system-surplus-threshold/3316) +* https://forum.makerdao.com/t/risk-of-pro-cyclical-mkr-issuance/1693 +* https://forum.makerdao.com/t/proposal-system-reserve-vault/1841/5 +* https://forum.makerdao.com/t/signaling-request-should-maker-make-a-treasury-to-manage-revenue/1122 diff --git a/MIP13/MIP13c3-Subproposals/MIP13c3-SP4.md b/MIP13/MIP13c3-Subproposals/MIP13c3-SP4.md new file mode 100644 index 000000000..875feb598 --- /dev/null +++ b/MIP13/MIP13c3-Subproposals/MIP13c3-SP4.md @@ -0,0 +1,232 @@ +# MIP13c3-SP4 Declaration of Intent & Commercial Points - Off-Chain Asset Backed Lender to onboard Real World Assets as Collateral for a DAI loan + +## Preamble +``` +MIP13c3-SP#: 4 +Author(s): Matthew V Rabinowitz (@mrabino1) +Contributors: n/a +Status: Request for Comments (RFC) +Date Proposed: 2020-09-01 +Date Ratified: +--- +Declaration Statement: Off-Chain Asset Backed Lender to onboard Real World Assets into the Maker Protocol to borrow DAI and deploy in the “Real World”. +Declaration to Replace: n/a +``` +## Specification + +### Context and Motivation + +As the MKR protocol evolves and new collateral is being added to the portfolio that supports DAI, a direct need to diversify away from on-chain crypto assets and bring in uncorrelated “Real World Assets” presents itself (especially collateral that is backed with credit quality). Further, in addition to bringing stability, an economically motivated fiduciary and sound legal structure will add liquidity to the DAI ecosystem helping to tame the DAI price and use market forces to pull it towards its reference currency, the US Dollar. In doing so, a series of legal structures will be used to secure protections for MKR holders to allow the lending of DAI to LendCo (an off-chain asset backed lender). This DAI along with equity that LendCo has and will continue to raise will then be used to provide loans to willing Borrowers (“BorrowCo”). + +### Declaration Detail + +1. Specific Declaration of Intent + + 6s, as an off-chain asset backed lender, desires to engage with the MKR community to cause the addition of a new collateral type along with new roles that would need to be filled from a person(s) / entity nominated by MKR holders. As an off-chain asset backed lender, 6s wants to engage the MKR community in a compliant way to execute a revolving credit facility loan agreement to help bring DAI loans to the “real world” to complement the business operations of 6s. + + Fundamentally, we are marrying a revolving credit facility loan agreement and a trust. As a result, we will need to create a new role (or expand the roles of others) of a “Maker Representative” as a person / legal entity needs to engage with the regulated Trust Company that will serve as trustee of the trust. + + Please see the bottom of this document for all reference links and historic associated posts. + +2. Who are the interested parties? + + 6s Capital LLC & 6s Capital Partners LLC (together “6s”), Delaware USA, along with any future international tax optimized feeder structures + +3. Provide a brief high-level overview of the project + + 6s works with multiple commercial real estate developers throughout the United States. 6s provides secured loans equal to 100% Loan-to-Cost for construction and the underlying real estate acquisition until completion for build-to-suits and ground leases for Credit Tenant Leases. + + **Time Lapse - [Sample]**(https://6s.capital/constructiontimelapse/) + + + + Further, rather than a digital oracle to automate the decision of whether a “breach” has occurred that would then trigger a liquidation, 6s and MKR governance* would enter into a revolving credit facility agreement whereby the obligations / requirements / covenants are laid out in written form enforceable in a Court of Law (as opposed to purely numeric with a pricing oracle) or code. + + **Note:** as MKR Governance cannot execute a legal document, MKR Governance will need to nominate one (or more) “Maker Representatives” to review the reporting from 6s to attest to the community whether or not 6s remains in compliance with the revolving credit facility agreement. This representative role will be an indemnified role. + + **Compliance includes, but is not limited to:** + * Annual audited financial statements of 6s + * Quarterly Independently reviewed financial statements + * List of all outstanding loans + * In construction + * Performing + * Non-performing + * Equity Requirement Reports per loan + + The Maker Representative’s role truly will be to report on compliance of 6s and to cause the execution of the operative documents between 6s and MKR holders. + + Further, and subject to MKR consent, a legal entity is recommended to also hold the role of a Maker Representative which may also be the Tax Favorable Entity (“TFE”) that is providing the DAI loan to the Trust, thus consolidating the two. + + Subject to legal & tax requirements, verification, and MKR discussion, a Cayman Islands legal entity may be recommended. + + * https://www.treasury.gov/resource-center/tax-policy/treaties/Documents/FINAL%20US%20-%20Cayman%20Islands%20-%20Cayman%20alternat.pdf + * https://wagnerduys.com/resources/resource/withholding-exemptions-to-cross-border-interest-payments/ + + As contemplated, the Trust should have minimal taxation as the TFE / Maker Representative Entity would receive the taxable gain. + + After the final jurisdiction of the TFE is determined, Matthew Rabinowitz or someone / somegroup in the community in collaboration with Matthew Rabinowtiz and with local counsel will form the entity (or cause it to be formed). Upon formation (if done or caused by Matthew Rabinowitz), he will assign all rights related to the entity to someone / somegroup in the community. The TFE would then explicitly *not* be run / owned / affiliated with LendCo or its officers. + + **Core Operative documents:** + + * Revolving credit facility agreement (between 6s and Trust for benefit of MKR holders) + * Promissory note and security documents (between 6s and Trust for benefit of MKR holders) + * Trust Agreement (between Trust Company, as trustee and MKR holders) + + As this structure may exist for years or decades, a Trust company is being engaged to follow the Trust Agreement in the event of a 6s breach or MKR liquidation of the vault to ensure proceeds from the liquidation are held “in-trust” in favor of the beneficiaries of the Trust (which shall be the same smart contract as outlined above under how LendCo would repay its debt). + + **The Maker Representative’s role is:** + + * Represent the will of the MKR holders and engage and instruct the Trust Company to be the Trustee of the Trust and execute the revolving credit facility agreement and other documents as the Trustee, and + * Review and attest to the compliance of the revolving credit facility agreement to the MKR community. + * If also a legal entity, the Maker Representative Entity (“MRE”) and the TFE could be the same. Further, it is the TFE that will provide the actual loan to the Trust. + + Pursuant to the revolving credit facility agreement, 6s and MKR governance would agree on a set of reporting requirements that 6s would be required to deliver to a Maker Representative on a quarterly basis (with some spot inspection rights). Should 6s be in breach of the agreement, and all cures periods have expired, the Maker Representative would report this to MKR Governance and thereafter MKR governance would and should liquidate the vault and notify the Trustee to commence liquidation on 6s (which would then wind-down the affairs of 6s and sell any remaining assets). All proceeds would then be delivered to the beneficiary of the Trust, MKR holders, to repay the DAI loan. + + **Provide a brief history of the project:** + + 6s was born during the COVID-19 banking credit squeeze when its sister company, 6s Development LLC had challenges with banks no longer wanting to provide credit. The principals of 6s Development LLC have been doing Credit Tenant Lease development for 15 years and have built well over a thousand locations. 6s Capital LLC aims to permanently replace and ensure a future is built on a financial foundation of rock, not sand. None of the locations built by 6s Development has defaulted. + +4. List any possible oracle data sources for the proposed token. + + No data feed Oracle for this collateral type. However, the revolving credit facility agreement will have data reporting requirements that must be maintained to remain in compliance and keep MKR governance from liquidating the vault. The Maker Representative shall be the interface between 6s and the MKR governance. Fundamentally, this reporting shall comprise an “analog oracle.” + + Further, a Technical MIP is being submitted for review. Please see the reference section at the bottom of this document. + +5. List any parties interested in taking part in liquidations for the proposed token. + + The Trustee (a regulated Trust Company) will follow the Trust Agreement established for this transaction. It will liquidate any and all assets pursuant to the trust agreement for the benefit of the trust beneficiary and deliver proceeds to pay down the Vault balance. + +6. Diagram of Operative Documents and Flow: + +![image2](https://user-images.githubusercontent.com/4902221/91903313-50f0bc80-eca3-11ea-83fa-ff4bd1f8797e.jpg) +image3 + +**Steps:** +1. Mint new DAI to TFE +2. TFE lends DAI to Trust +3. Trust lends DAI to LendCo +4. LendCo conduct lending operations and either repays the loans to the Trust or recycles the capital back into another approved scope transaction +5. LendCo repays the Trust in DAI +6. The Trust repays the TFE +7. The TFE repays the vault +--- + +7. Process for Real World Asset module + + The below structure contemplates FIVE fundamental levers that MKR governance can control to influence LendCo’s behavior: + + 1. Aggregate Debt Ceiling + 2. Risk Premium - Interest Rate + 3. Scope (may be modified by MKR governance ratification of a LendCo request) + 4. Equity Requirement (may be modified by MKR governance ratification of a LendCo request) + 5. Liquidation + + Given the business operational needs of LendCo and the possible (if not likely) need to tweak parameters for the benefit of DAI stability, the frequency surrounding modifications should be on a weekly cycle with proper forum posts in advance. + + Once the legal entities and legal contracts are in place, MKR Governance need only modify the five levers above to control / incentivize LendCo (regardless of how many BorrowCos are behind LendCo). + + +8. Why is this important? + +- This proposal for the community introduces a new market force to help stabilize the DAI ecosystem. Further, it is a natural counterbalance to helping push DAI to its reference currency, the US Dollar. By introducing an external economically incentived third-party, further liquidity will be added by using an approved “capital sink.” + 1. It is critically important that any DAI that overflows into this structure for Real World Asset Backed Loans, have the community’s pre-approval for credit quality. + 2. A “capital sink” in this context means a known holding “pool” for capital that has been / can be deployed with known credit in an approved structure. + - By implementing legal structures that help secure the MKR holders from the “hit by the bus scenarios,” the DAI ecosystem will have an overflow value for excess DAI (when above $1) and a mechanism for encouraging repayment when below $1. In doing this, a needed dampening effect is created that will help smooth out the DAI price. +- Graphical Objective: + +![image1](https://user-images.githubusercontent.com/4902221/91903307-4f26f900-eca3-11ea-89ca-ce60a2891aab.png) + +- The above is achieved by using market forces and an economically motivated off-chain structure. + * Every time the market price is above 1, an economically motivated off-chain party should mint DAI to deploy off-chain. In reverse, when DAI is below 1, that same party should seek to repay the debt. + * When DAI is materially above 1, that party is well motivated to scale-up operations to deploy capital in-bulk. + * That capital could be held off-chain for weeks / months / years. + +- Time Horizon + + - This proposal does not have a time restriction on how long the DAI will be borrowed by the TFE / the Trust / LendCo. Rather LendCo is economically incentivized to respond to market forces and deploy / repay capital accordingly. As such, if the market conditions continue, the overflow DAI may be deployed (and recycled) off-chain for months / years. + + - This size of the overflow / capital sink is constrained by: + + 1. Community approved debt ceiling + 2. LendCo operations (scope) + 3. LendCo economics + +- Legal Structure Selection + + 1. The combination of a bankruptcy remote Trust + an Operating LLC (as a Lender) is needed for a few essential reasons: + + 1. MKR holders are a collection of unknown people or legal entities that own MKR. A legal construct is needed to give them standing in a Court of Law. A Trust with MKR holders as beneficiaries meets this requirement. + 2. Legal precedence with a bankruptcy remote Trust + + - Most MBS / CMBS / ABS utilize a common statutory Trust for a similar purpose. In those structures, another “connected” trust issue securities to investors, this structure does not have that. It simply has MKR holders as beneficiaries of the Trust in the case of a liquidation. + + 3. Industry familiarity with how to liquidate real-estate assets should a liquidation be triggered + 4. The Revolving Credit Facility Agreement is commonplace for most large companies to access inexpensive costs of capital from a bank. A bank does not need a Trust to foreclose on assets in the event of a breach / liquidation. For MKR, since those rights are held by an unknown group, a Trust (above) is needed + 5. Concentration of compliance and audit requirements to LendCo + + 2. Individually, a Trust structure is not new. The Revolving Credit Facility Agreement is not new. Pushing them together with MKR holders as the beneficiaries with an MKR community defined scope is novel. + 3. As a result of the above, LendCo can borrow DAI in significant scale without increasing the cognitive load on the MKR community / Maker Representative. + 4. The independent accountants handle the scale of transactions while the auditors ensure the books are being kept in accordance with GAAP. The Maker Representative then needs to review the aggregate work done by everyone else to attest to the community that things are in compliance. + +

6s Capital  LLC (“6s”) / Maker Community (“MKR”)

TERM SHEET

FOR DISCUSSION PURPOSES ONLY - PUBLIC DRAFT

Purpose / Objective

To structure a real world credit facility for an asset backed lender utilizing the MKR DAI ethereum facility to deploy capital into commercial real estate projects by structuring and marrying the debt capital with preferred equity such that 100% of the capital stack can be constructed and then lent to a willing borrower on commercially reasonable terms. Further, by utilizing a Trust structure with an independent and regulated Trust Company together with a revolving credit facility agreement, we can provide a mechanism to protect MKR holders in the event of a liquidation

Parties

Matthew V Rabinowitz, Managing Director of 6s Capital LLC

6s Capital LLC, a Delaware limited liability company (“6s”), manager of LendCo (http://6s.capital)

6s Capital Partners LLC, a Delaware series limited liability company and possible future offshore feeder sourcing structures, for tax optimization purposes only (“LendCo”)

Maker Community (“MKR”)

  TBD    Trust, a Delaware Statutory Trust (“Trust”), or a different jurisdiction, as needed

  TBD    Trust Company (“TrustCo” or “Trustee”), a regulated Trust Company

Maker Representatives (1 primary with 2 backups and an updated ETH address controlled exclusively by governance that may be updated at MKR governance discretion to nominate new people). Maker Representative may also be a legal entity in a jurisdiction of its choosing provided that it is approved by MKR Governance. Maker Representative shall be indemnified by 6s.

Tax Favorable Entity (“TFE”) provides a revolving DAI loan to the Trust. The TFE may also be a Maker Representative Entity.

  TBD    LLC, a Delaware limited liability company (“BorrowCo”)

collectively known as the “Parties.”

LendCo Operational Scope

Make asset-backed loans, starting with: construction of new credit tenant lease single-tenant locations throughout the United States (with no State specific restriction) or refinance stabilized inventory for the same. Tenant lease shall be Ground Lease or Build-to-Suit which is either a double-net or triple-net lease in place. LendCo must have a first position senior lien on the collateral provided by its borrower.

Scope may be modified by MKR governance ratification of a LendCo request.

General Sequence

  1. BorrowCo approaches LendCo for a construction or refinance loan for a project with a credit tenant with a lease that is already executed and valid.
  2. LendCo Reviews Loan request  to see if it meets lending requirements.
  3. LendCo Rejects / Approves Loan
  4. LendCo Raises Preferred Equity, if needed
  5. BorrowCo and LendCo execute all loan documents with all title review and legal work complete and a closing date is set
  6. LendCo deploys its equity at the closing (if needed and if within the equity requirement constraint), LendCo borrows against its credit limit with a DAI loan.
  1. Upon Closing LendCo now has a senior lien on BorrowCo’s real-estate and the project as a whole.
  1. If a DAI loan is needed, LendCo borrows DAI and sells on the open spot market for USD.
  2. Project continues with progress checks from LendCo (pursuant to the Loan Agreement between LendCo and BorrowCo until such time as BorrowCo divests the project or is foreclosed upon by LendCo).
  3. To sell to a third-party, BorrowCo must get LendCo to release its senior lien. It then requests a payoff letter from LendCo to know precisely how much to repay LendCo in exchange for a release of the lien and all aspects under the loan documents.
  4. A closing date is scheduled, BorrowCo sells / refinances the project with a third-party. In doing so, the LendCo receives all remaining principal + interest and in exchange it releases the senior lien.
  5. LendCo repays the DAI loan (or revolves it into the next project) and repays the preferred equity investors pursuant to their subscription agreements.

The cycle then repeats and is done in parallel with many borrowers.

LendCo Restrictions

  • No speculative project risk. All projects must be either stabilized or “shovel-ready” pursuant to the scope, as amended and ratified by MKR Governance from a LendCo request.

Operative Documents between MKR (or the Trust on MKR behalf) and LendCo

  • Revolving Credit Facility Agreement (“RCFA”) - Based on a bank’s traditional credit facility agreement but modified for MKR governance and liquidation to a Trust
  • Statutory Trust Agreement (“STA”) that creates and governs the Trust
  • Security Agreement (which includes an unconditional irrevocable assignment of all rights from LendCo in favor of the Trust (e.g. a pre-arranged divorce before you are married))
  • LendCo ETH address: 0x000000000000000000000000000 (TBD)
  • LendCo ERC-20: (TBD)
  • No economic value / No redemption value / No voting value (even if stolen)

Operative Documents between LendCo and BorrowCos

  • Loan Agreement (w/ draw schedule requirement) and term of up two calendar years (with 6 month extensions possible) - Construction to Bridge
  • Promissory Note
  • Deed of Trust / Mortgage
  • Consents
  • General Contractor
  • Architecture
  • Engineering
  • Environmental Indemnification Agreement
  • Personal Guarantee / Completion Guarantee with “Bad Boy” carve-outs
  • Bank Account Control Agreement
  • Equity Pledge Agreement
  • Operating Agreement (Common for all BorrowCos)

Revolving credit facility agreement - Modified for MKR governance and liquidation to a Trust

General

  • Debt-to-Equity / Equity Requirement per loan
  • Required equity must be completely deployed into a given project before any MKR proceeds may be used for that project.
  • Approved Tenants
  • Starting ratio of 30% equity requirement for new construction and 15% for refinance / stabilized inventory.
  • Discretionary Tenants
  • Starting ratio of 30% equity requirement for new construction and 20% for refinance / stabilized inventory.
  • MKR governance may modify the equity requirement higher or lower at its discretion, but in no case shall the equity requirement be higher than 30% equity per transaction (as measured at closing for that specific transaction)
  • However, if MKR governance subsequently lowers the equity requirement, all outstanding loans with a higher equity requirement are automatically internally "refinanced'' with the new equity requirement. However, if the equity component is raised, the equity requirement shall only apply to transactions that occur after that  governance decision.
  • Equity shall be "released" from a given project and recycled elsewhere within LendCo when a given project is stabilized (specific to if the equity requirement is different).
  • Stabilized shall be determined when the project is either rent paying or the project is accepted by or handed over to the tenant where the credit tenant is then obligated to pay and the operational obligations of the BorrowCo are complete.
  • Gap Collateral - At LendCo’s discretion, equity may be substituted for evidence of capital deployed (with supporting documentation) by BorrowCo or the difference between the appraised stabilized value and an existing loan outstanding when LendCo will have the senior lien over the entire project (e.g. a given project is worth $8MM and the outstanding debt is $5MM, the $3MM difference (or a portion thereof) can be considered as equity if LendCo has a lien over the entire project, at LendCo discretion). Further, Gap Collateral may also take the form of capital locked and controlled via the Bank Account Control Agreement.
  • Equity may be shifted internally within LendCo provided that all Debt-to-Equity ratios / equity requirements are not in breach on a project-by-project basis as projects complete.
  • Term
  • After the first 36 months, the Term of the engagement shall change to be renewed for an additional 12 calendar months while the authorized MKR debt ceiling is above zero and the DAI outstanding is greater than 0. Further and after the initial 36 months, either party will be able to terminate the agreement with 12 months notice to the other or by LendCo repaying the outstanding balance (including all interest and principal) in full. The foregoing notwithstanding, should LendCo be in material breach of the revolving credit facility agreement, LendCo shall not be able to borrow any additional capital and must wind down operations.
  • Reporting
  • LendCo must deliver the following after the execution of the RCFA to the Maker Representative:
  • Annually on or before August 01
  • Audit of financial statements
  • Quarterly within 45 calendar days after the end of each time period
  • Independently reviewed financial statements (consolidated and consolidating)
  • List of all loans outstanding with each closing binder for each transaction
  • List of all loans in default (if any)
  • Equity compliance report per loan outstanding

  • Inspections
  • Random Spot Inspections
  • LendCo shall make its books available to a Maker Representative with 10 calendar day notice one time per calendar year in between reporting periods

  • Maker Representatives
  • Individual(s) or legal entity(ies) selected by MKR Governance to represent the best interests of the community.
  • All reporting requirements will be made to either the Maker Representative (that will have executed a Non-Disclosure Agreement with LendCo less to attest to compliance) or to nominated parties from MKR governance that will execute the same
  • LendCo will indemnify the Maker Representatives
  • LendCo will not be determined to be in breach if all of the appointed Maker Representative refuses to execute a non-disclosure agreement
  • Maker Representative subsequently attests to the MKR community LendCo’s compliance in the following reporting areas
  • Annual Audit
  • Quarterly Independently-reviewed  Financial Statements Delivered
  • No operations outside of approved scope
  • No loans above portfolio threshold issued
  • Debt-to-Equity ratios / equity requirements for all loans in compliance
  • All loans issued are either performing or under construction
  • Maker Representative may also be in the form of a legal entity.

Liquidations

  • In the event that MKR governance determines there has been a breach of the RCFA or that MKR determines that it no longer wants to continue to engage with LendCo, by MKR governance passing an executive vote, the Trustee will follow the trust agreement and allow a 12 month period to wind-down the facility. Should LendCo fail to do so, the Trustee will force the liquidation of the assets of LendCo and send proceeds to the Trust (which shall be held and ultimately transferred to MKR).

Initial Operational Asset-Backed Lending Scope:

  • Commercial Real-Estate - Credit Tenant Leases
  • LendCo must have a first position senior lien as a result of a transaction (or a legally perfected equivalent in the event of a white label structure)
  • Tenant list may be modified by MKR governance ratification of a LendCo request.
  • Compliance shall be measured at the time of loan closing to determine breach
  • Starting List of Tenants for Build-to-Suit or Ground Leases
  • Commercial
  • Dollar General
  • Service King
  • Caliber Collision
  • O’Reilly Auto Parts
  • Wawa
  • Tractor Supply
  • Grocery Outlet
  • Dutch Brothers Coffee
  • Starbucks Coffee
  • 7-Eleven
  • Industrial
  • Amazon
  • FedEx
  • UPS
  • Chep
  • LendCo may have up to 15% of its loan portfolio be discretionary so long as underwriting lending criteria are met
  • Operational Asset Backed Lending Scope may be modified by MKR governance ratification of a LendCo request.
  • 2021 Target - Expand Scope to include a new investment grade industry for a capital sink

Pricing

  • Proposed Risk Premium Range
  • Ceiling
  • Wall Street Prime + 100 bps per annum
  • Floor
  • 50 bps per annum
  • Proposed Starting Risk Premium (subject to MKR governance modification) with any modification to the rate taking effect the first day of the subsequent month
  • Debt Ceiling: 0-25MM
  • Wall Street Prime - 25bps (currently computed as 3.00%)
  • Debt Ceiling: 25-50MM
  • Wall Street Prime + 0 bps (currently computed as 3.25%)
  • Debt Ceiling: >50MM
  • Wall Street Prime + 25bps (currently computed as 3.50%)

Initial Revolving Facility Size

  • 15MM DAI (subject to future modification by MKR governance)

Forward Guidance / Target Revolving Facility Size

  • ~100MM DAI in 12 calendar months
  • >100MM DAI thereafter based on project demand and community sentiment

Annual Revolving Facility Paydown Requirement

  • If the revolver debt ceiling limit is hit, LendCo will pay down any amount accrued in excess of the Facility limit at least annually.

LendCo may further constrain its lending operations by "Other Lending Constraint.s.

Trust Agreement

The Trust embodies the rights of MKR holders and lends the DAI to LendCo. The Trust shall be used in event of liquidation.

 

Should a liquidation event occur whereby the Trustee had to pursue legal action against LendCo, all proceeds would be held “in-trust” for the benefit of the beneficiaries of the Trust.

The beneficiaries of the Trust are to be explicitly defined as those who own MKR (or its subsequent replacement / relaunch). The Trustee will direct and send all liquidation proceeds to the repayment smart contract for LendCo.

LendCo shall repay its DAI loan directly to MKR or via the Trustee. Failure to do so, will cause the Trustee to liquidate LendCo assets and repay the DAI loan.

The Trustee will be directed to file all appropriate filing, formations, and tax returns for the Trust.

BorrowCo Requirements

Newly formed Delaware limited liability company in good standing with the State of Delaware

The principals behind any BorrowCo:

  • No Bankruptcies
  • Cleared independent background checks
  • 10 years minimum real-estate development experience
  • Must disclose a Personal Financial Statement (PFS) to the satisfaction of LendCo
  • Must disclose last 3 years of personal tax returns to LendCo

Reporting:

  • Weekly construction reports
  • Annual tax returns
  • Quarterly financial statements
  • Monthly Budget vs Actuals

Guarantor:

  • Personal guarantee / Parent guarantee / completion guarantee (at LendCo discretion) with "Bad Boy" carve-outs from the principals of BorrowCo and its parent (if applicable)

Legal Opinion:

  • Closing requirement per transaction of an enforceability opinion that the agreements and lien are enforceable in the jurisdiction of the loan

Other Lending Constraints / Consideration

In addition to the equity requirement per loan, LendCo may also further constrain its lending activities by:

  • Loan-to-Value (measured at closing)
  • Loan-to-Cost (measured at closing)
  • Debt Service Coverage Ratio (DSCR, measured at closing)
  • Developer exit spread compared to market
  • Amount of loans outstanding to the principals of BorrowCo
  • Portfolio exposure to a given tenant

Governing Law

The Revolving Credit Facility Agreement shall be governed by New York law.

The Delaware Statutory Trust Agreement shall be governed by Delaware law.

The Borrower Loan Documents shall be governed by New York law with State specific enforceability provisions included per loan.

Sustainable Plan Objectives / International Expansion

Target:

  • Starting with year 2 and by year 7
  • 40% of all outstanding loans will be for renewable sustainable projects
  • Starting with year 5 to year 10
  • 30% international projects (subject to having EuroDAI (or other target reference currency available)

Time Lapse - Sample

https://6s.capital/constructiontimelapse/

+ +--- + +**Matthew Rabinowitz’s Bio:** + +Matt is an execution driven business strategy and corporate finance professional with overall responsibility for 6s Capital LLC including managing the financial resources (banking, financing, equity capital) as well as the financial service providers (accounting, audit, insurance and tax). He has run point on strategic planning / business development / creating strategic alliances / contract negotiation / SPV implementations & management including assisting in the overall strategy, negotiations and contract support for the large (~10GW) renewable energy consortium including Boone Pickens, Fluor Corp. BNSF Railways, ABB, and Siemens. Thereafter, he assisted in the overall strategy, negotiations and contract support for two Life Settlement Trust Certificate bond offerings. He co-managed for two private placement debt arbitrage pooled investment funds. To achieve the best pricing on debt securities, he co-founded and ran back office operations for both an SEC Registered Investment Advisor and a subsequently acquired FINRA Broker/Dealer. He co-managed an oil & gas SPV to acquire an operating oil field asset which was subsequently divested. Finally, he co-founded a commercial real-estate development firm and designed its corporate structure. Matt earned a Master in Business Administration from the University of Texas at Dallas and a Bachelor of Science in Electrical Engineering from Texas Tech University. + +--- + +**Projects first in line:** + +Two projects have already cleared underwriting for financing after the above structure is put in place. Neither project has any construction / development risk. The two projects are both Ground Leases and have been “handed over” to the tenant. The Lease for each project is in force with the credit tenant on the hook to make rental payments with a store opening or date specific (whichever occurs first). + +- Transaction #1 Required Closing Proceeds: $3,700,000 + + - (Appraised Value: $5,620,000) + +- Transaction #2 Required Closing Proceeds: $5,200,000 + + - (Appraised Value: $7,140,000) + +- Both transactions will require appraisals to be refreshed prior to closing. + +----- + +**Underlying Legal Documents:** + +- Documents are still being drafted and will be posted in this thread prior to the deadline for the next governance cycle. + +- **Note:** The Trust Agreement will use the form provided by the selected corporate trustee. As one has not been finalized yet, we will provide a basic template; however, until a trustee is selected the “actual” draft cannot be provided. + +----- + +**General Next Steps** + +* Declaration of Intent +* Community discussion / debate +* Formal submission of proposals for Governance cycle +* Inclusion of polls for proposals +* Governance poll for proposals +* Executive vote for proposals (including the Maker Representative(s) + * If accepted, + * the initial debt ceiling would be voted on *but* would be conditionally set to zero following the Maker Representative report (below) + * 6s team then deploys the structure contemplated herein alongside with the Maker Representative +* Once the Maker Representative reports to the community that all legal documents / entities are completely in place, a second executive vote would be held to implement the first debt ceiling as agreed in the first executive vote. + * With this final action, 6s would be able to borrow DAI pursuant the revolving credit facility agreement. + +----- + +## Relevant Links + +* {INSERT TECHNICAL MIP LINK} +* https://forum.makerdao.com/t/how-makerdao-can-be-a-competitive-lender-in-the-credit-tenant-lease-marketplace/3521 +* https://forum.makerdao.com/t/adding-real-world-assets-rwa-as-dai-collateral-is-a-critical-step-for-maker-to-stabilize-the-peg-and-in-doing-so-we-change-the-world/3653 +* https://forum.makerdao.com/t/real-world-assets-ctl-document-roadmap-getting-started-v1/ +* https://forum.makerdao.com/t/translucent-finance-off-chain-lenders/3800 +* https://forum.makerdao.com/t/economics-behind-real-world-assets-rwa-part-1/3801 +* https://forum.makerdao.com/t/economics-behind-real-world-assets-rwa-part-2/3893 +* https://delcode.delaware.gov/title12/c038/sc01/ +* https://docs.google.com/document/d/1sf0NIib9z8YXVlsEgur4twjlBp4HhN8jCS_epHKKZYw/edit?usp=sharing +* [FAQs based on commentary from the community](https://docs.google.com/document/d/1sf0NIib9z8YXVlsEgur4twjlBp4HhN8jCS_epHKKZYw/edit?usp=sharing) diff --git a/MIP13/MIP13c3-Subproposals/MIP13c3-SP5.md b/MIP13/MIP13c3-Subproposals/MIP13c3-SP5.md new file mode 100644 index 000000000..e67df2b3f --- /dev/null +++ b/MIP13/MIP13c3-Subproposals/MIP13c3-SP5.md @@ -0,0 +1,94 @@ +# MIP13c3-SP5: Maker to commence onboarding work of Centrifuge based Collateral +## Preamble +``` +MIP13c3-SP#: 5 +Author(s): Lucas Vogelsang (@spin on forum.makerdao.com, lucas@centrifuge.io) +Contributors: +Status: Request for Comments (RFC) +Date Proposed: 2020-09-09 +Date Ratified: +--- +Declaration Statement: MakerDAO supports Centrifuges effort in developing an onboarding process for their RWA as collateral to MCD. +Declaration to Replace: n/a +``` + +## Specification +### Context and Motivation +Onboarding Real Wold Assets to Maker is seen as one of the main priorities to scale MakerDAO. This is a goal Centrifuge has been working on for over a year. It requires adapting the current collateral onboarding process as these assets are different from the current collateral. Centrifuge has worked with both the domain teams as well as the broader community to discuss these differences and come up with solutions such as the MIP22 proposed in this cycle. + +Onboarding real world assets to MakerDAO is a unique challenge, that - similar to the migration from SAI to DAI - might seem as an unsourmountable task at first. However, it is only the natural extention of the current MCD building on prior learnings. This declaration outlines a path towards onboarding those assets at a low debt ceiling to gain first experience within the community and kick of the next evolution of Multi-Collateral-Dai towards a diversified asset backed lending protocol. + +With this endeavour come many questions that the community hasn't had to address so far. Those need to be diligently answered by setting up a thorough process. This process should MakerDAO can gain valuable experience by experimenting at a small scale slowly growing the amount of DAI that can be generated from these assets as it gains confidence in the system and the system is improved to offer further protection. + +This declaration of intent is the first step to developing an onboarding process specific to Centrifuge based RWA applications in MakerDAO. + +#### Collateral Overview +Centrifuge has partnered with a number of different asset originators that can be onboarded to Maker ready to add demand for DAI and diversity to the system. These asset originatiors jointly have capital needs of well over DAI 50M and bring a diverse set of crypto-uncorrelated assets to Maker. All of these collateral types have followed the standard MIP6 process and have already been greenlit by the communiy (except KickFurther which is in the current cycle). + +The following collateral applications are to be considered for this new process. They are listed with their capital demands and their current cost of capital as a benchmark for the Maker to use as guidance on the opportunity to generate DAI. + +* **ConsolFreight**, Financing freight invoices, Capital needs in DAI: up to 5M, Current Cost of Capital: they have a bank line of credit at 1.5% for $50k, [MIP6](https://forum.makerdao.com/t/cf-drop-mip6-application-consolfreight-drop-tokenized-freight-shipping-invoices/2214) +* **New Silver**: Financing real estate backed loans, Capital needs in DAI: 15M, Current cost of Capital: NS holds a private fund credit line of $20M with a 3MO LIBOR +4.75%, [MIP6](https://forum.makerdao.com/t/ns-drop-mip6-application-new-silver-drop-real-estate-backed-loans/3477) +* **Paperchain**, Financing music streaming invoices, Capital needs in DAI: 1M, Current cost of capital: sourcing from independent investors and funds at 6-10% range, [MIP6](https://forum.makerdao.com/t/pc-drop-mip6-application-paperchain-drop-tokenized-music-streaming-invoices/2215) +* **KickFurther**, Financing consignment inventory for eCommerce & retail brands, MIP6 application to follow +* **Harbor Trade Credit**, Financing short term trade finance transactions [MIP6](https://forum.makerdao.com/t/htc-drop-mip6-application-harbor-trade-credit-drop-short-term-trade-receivables/3502) + + +### Declaration Detail +The MakerDAO community declares its intent to onboard Centrifuge's assets according to an onboarding process outlined below. Centrifuge is encouraged to develop and implement this process for its proposed assets resulting in a MIP template that can be used for this category of assets broadly based on the current MIP6-MIP12 process. + +Given the proper due dilligence by the Maker community and the domain teams, Centrifuge is encouraged to use the developed MIP with collateral types as soon as they are ready. + +#### Scope of this onboarding process +The process is designed to be safe for onboarding assets up to a certain limit. If these limits are hit, governance must decide if the debt ceiling can be increased gradually or how further protection (such as more due dilligence or technical improvements) should be added. Assets onboarding with this process should at the beginning not surpass **4M DAI** in debt ceiling per collateral type. And the total for all collateral types following this process should not surpass **15M DAI** to stay within a bounds that even in the worst case scenario would not endanger the Maker project and DAI. + +#### Collateral Onboarding Form (MIP6) +The regular collateral onboarding process used for tokens like 0x, Loopring etc. is an inspiration for this process. And all assets to be considered for onboarding should start out with a MIP6 proposal. In the future a likely adaption of this might be to create multiple variations for MIP6 proposals depending on the collateral type. For now, this is is out of scope and the MIP6 and MIP9 Community Greenlight Poll should be used. + + +#### Onboarding Process Component 1: Liquidation Process +Real world assets require a different liquidation than using the existing keeper infrastructure. The technical changes are defined in the proposed MIP22. For the collateral type, the application should outline how the portfolio can be liquidated through the mechanism defined in MIP22 listing different offchain lenders. The community must exercise due dilligence on this process ensuring that in fact these assets can be liquidated off chain. + +Requirements for onboarding: +- Description of the liquidation process overall +- Detailed model of the expected losses incurred at liquidation as well as the speed of which these assets can be liquidated +- Supporting documentation/evidence of available off-chain refinancing options for the collateral if the loans can't be held to maturity + + +#### Onboarding Process Component 2: Smart Contracts Work +Like any other collateral added to Maker, the technical integration must be audited prior to onboarding the collateral type. Centrifuge is developing the necessary adapters as well as the executive code (the spell) that can add onboard a Centrifuge-based asset to MCD. As part of the smart contract work that will go into this, Centrifuge will do a full dry run of this with a Kovan-deployment of DSS and work with the smart contracts domain team as well as other developers familiar with the project. In addition, the code will be audited by an audit firm that has performed audits of the Maker codebase before. + +The resulting set of contracts that are to be used then only needs to be minimally modified for each new collateral type. Any modifications to the code would require the re-evaluation of the technical onboarding process. + +Requirements for onboarding: +- List out any modifications deviating from previously approved versions of collateral adapters. + - If there are none, no external audit necessary + - If there are changes, resent a thorough technical review and audit of any modifications + + +#### Onboarding Process Component 3: Risk Work + +The onboarding process for risk will be in conjuction with the risk domain teams as their capacity permits. All asset proposals need to include the usual risk parameters for the system. This includes the parameters below: + +* **Stability fee**: fee on Dai that is generated from a RWA Vault should be competitive with the current cost of capital of the asset originator or the industry standard rate of the specific asset. +* **Debt ceiling**: We propose the maximum amount of Dai that can be generated from Vault/RWA should not be higher than 4m in the first itereation. The debt ceiling for RWA as collateral should be determined by the capital need / origination volume of the asset originator. +* **Collateralization ratio**: The ratio between the value of the collateral and the value of the generated Dai for the specific RWA vault. +* **Downside protection / TIN ratio**: The ratio between DROP and TIN (Senior and Junior tranche). This is an additional saftey cushion for any RWA vault. It should be derived from the asset originators historic default rate and/or the asset's historic default rate (e.g. Invoices as an asset type have a historic default rate of less than 1%) +- **Reporting**: Present a Risk Assessment Report co-authored by active Maker community members; either by the current Risk Domain Team or longer term a Domain Team specializing in non-crypto assets. + +#### Executive Vote +Following a positive community greenlight (MIP8) and completion of the work outlined in the three components above, the result should be an executive vote on the spell onboarding the asset to the DAO based on the risk parameters. A MIP template will be created for this. + + +## Relevant links +* [MIP22 Proposal: Centrifuge Direct Liquidation Module](https://forum.makerdao.com/t/mip22-centrifuge-direct-liquidation-module/3930) +* [MIP22 Pre-MIP Discussion: Vault Liquidation Mechanism for Centrifuge Trade Finance Assets](https://forum.makerdao.com/t/vault-liquidation-mechanism-for-centrifuge-trade-finance-assets-a-pre-mip-discussion/3737) +* [Centrifuge: Onboarding RWA Backed Collateral to MCD](com/t/centrifuge-onboarding-rwa-backed-collateral-to-mcd/2721) + + +### MIP6 Proposals +* [HTC](https://forum.makerdao.com/t/htc-drop-mip6-application-harbor-trade-credit-drop-short-term-trade-receivables/3502) +* [CF](https://forum.makerdao.com/t/cf-drop-mip6-application-consolfreight-drop-tokenized-freight-shipping-invoices/2214) +* [PC](https://forum.makerdao.com/t/pc-drop-mip6-application-paperchain-drop-tokenized-music-streaming-invoices/2215) +* [NS](https://forum.makerdao.com/t/ns-drop-mip6-application-new-silver-drop-real-estate-backed-loans/3477) +* KF (TBC) diff --git a/MIP13/MIP13c3-Subproposals/MIP13c3-SP6.md b/MIP13/MIP13c3-Subproposals/MIP13c3-SP6.md new file mode 100644 index 000000000..53d5d7ab7 --- /dev/null +++ b/MIP13/MIP13c3-Subproposals/MIP13c3-SP6.md @@ -0,0 +1,62 @@ +# MIP13c3-SP6: SourceCred Funding + +## Preamble +``` +MIP13c3-SP#: 6 +Author(s): @LongForWisdom +Contributors: +Status: RFC +Date Proposed: 2020-10-05 +Date Ratified: +--- +Declaration Statement: Maker Governance intends to fund the use of SourceCred within the Maker Community to incentivize effective governance of the Maker Protocol. +Declaration to Replace: n/a +``` +## Specification + +### Context and Motivation + +The SourceCred algorithm has been in a trial phase on the Maker forums for the past few months and has been generally seen as successful by its participants and the trial working group. + +The big next step for the use of SourceCred within Maker is to set it up such that it can be funded directly by the protocol, this promotes decentralization and separation from the Maker Foundation. + +In my view, it is beneficial for MKR Token Holders to fund SourceCred on an ongoing basis for the following reasons: +- It incentivizes involvement in governance. The more humans you have paying attention to governance, the more chance that current issues will be discussed and understood thoroughly. +- It helps align incentives between members of the Governance forum who do not hold MKR and MKR Holders. +- Larger MKR Holders have thus far been unable or unwilling to participate openly in governance, SourceCred represents a way for them to fund governance through the protocol equally, bypassing the free-rider problem that appears if any large MKR Holder wanted to incentivize governance directly. +- People spend a lot of time on the forums, making proposals and discussing the Maker protocol deeply they deserve to be compensated for their time. + + +### Declaration Detail + +Maker Governance intends to fund the use of SourceCred within the Maker Community to incentivize effective governance of the Maker Protocol. To further this aim, Maker Governance would like to see a technical solution developed that allows funding and distribution according to cred scores. + +**This funding should:** +- Come from the Maker Protocol using funds from the surplus buffer or generated through MKR minting. +- Be distributed according to cred scores generated using weightings ratified by Maker Governance. + +**The technical implementation of this funding system is flexible, but should:** +- Allow variable amounts of value in the form of DAI to be drawn from the Maker Protocol for distribution. +- Follow best practices and be audited by one or more Smart Contracts Domain Team personnel. +- Be presented to Maker Governance in the form of a technical MIP. + +**The technical implementation of the distribution system is flexible, but should:** +- Allow for variable amounts of any token to be distributed according to cred scores. +- Ensure that off-chain cred scores are communicated for on-chain distribution in a trust-minimized way. +- Follow best practices and be audited by one or more Smart Contracts Domain Team personnel. +- Be presented to Maker Governance in the form of a technical MIP. + +**In addition, the following point should be addressed:** +- Off-chain cred scores should be calculated in a reliable and trust-minimized way. + +Note that both parts of the technical solution should be presented in the same technical MIP if they differ from existing structures. + +### Relevant Links + +**Forum** +- [Maker SourceCred Trial Initial Post](https://forum.makerdao.com/t/maker-sourcecred-trial/2551) +- [SourceCred Trial: Review of Month 1](https://forum.makerdao.com/t/sourcecred-trial-review-of-month-1-payout-increase/2999) +- [SourceCred Pilot Extension](https://forum.makerdao.com/t/sourcecred-pilot-extension/3892) +- [Opting in to SourceCred](https://forum.makerdao.com/t/opting-in-to-sourcecred-wth-is-sourcecred/3913) + + diff --git a/MIP14/MIP14c2-Subproposal-Template.md b/MIP14/MIP14c2-Subproposal-Template.md new file mode 100644 index 000000000..831c3db33 --- /dev/null +++ b/MIP14/MIP14c2-Subproposal-Template.md @@ -0,0 +1,59 @@ +# MIP14c2: Subproposal for Protocol DAI Transfer + +## Preamble +``` +MIP14c2-SP: # +Title: +Author(s): +Contributors: +Status: +Date Proposed: <yyyy-mm-dd> +Date ratified: <yyyy-mm-dd> +--- +Amount: +``` + +## Specification + +### Sentence Reason + +- A one sentence reason of why DAI is being transferred from the protocol. + +### Reason Details + +- More details regarding the reason for the Protocol DAI Transfer. + +### Surplus Analysis + +- An analysis of whether the proposed transfer can be taken from the current surplus or if it would result in a FLOP auction. + +### DAI Transfer Ceiling Analysis + +- An analysis of whether the proposed transfer is within the parameters of the DAI Transfer Ceiling + +### Targets + +- Clearly listed target addresses with matching amounts in the format: +``` +Recipient Address: 0x0000000000000000000000000000000000000000 +Amount To Transfer: 0 DAI +``` +- Combined amount of DAI should not be higher than the Amount specified in the Preamble nor exceed the DAI Transfer Ceiling. + +### Relevant Information: + +- Links to discussion, evidence or anything related to the transfer. + +### Proposed Executive Code +The following executive code snippets are intended to be inserted within the 'Execute' function within 'SpellAction' contract of the executive spell. Any additional code required to support this executive code snippet is the responsibility of the Smart Contracts domain team writing the executive spell. Any Smart Contracts domain team is free to modify this code snippet as required to match the intention of this subproposal. + +``` +VatAbstract(MCD_VAT).hope(MCD_JOIN_DAI); +VatAbstract(MCD_VAT).suck(MCD_VOW, address(this), RAY * totalDaiAmountToTransfer); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer1, daiAmountToTransfer1); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer2, daiAmountToTransfer2); +DaiJoinAbstract(MCD_JOIN_DAI).exit(targetAddressToTransfer3, daiAmountToTransfer3); +... +``` + +Variables totalDaiAmountToTransfer, targetAddressToTransfer and daiAmountToTransfer should be modified according to the Amount and Targets section above. diff --git a/MIP10/MIP10c7-Subproposals/placeholder.md b/MIP14/MIP14c2-Subproposals/placeholder.md similarity index 100% rename from MIP10/MIP10c7-Subproposals/placeholder.md rename to MIP14/MIP14c2-Subproposals/placeholder.md diff --git a/MIP14/MIP14c4-Subproposal-Template.md b/MIP14/MIP14c4-Subproposal-Template.md new file mode 100644 index 000000000..58b498af4 --- /dev/null +++ b/MIP14/MIP14c4-Subproposal-Template.md @@ -0,0 +1,29 @@ +# MIP14c4: Subproposal for Protocol DAI Transfer Ceiling + +## Preamble +``` +MIP14c4-SP#: # +Author(s): +Contributors: +Status: +Date Proposed: <yyyy-mm-dd> +Date Ratified: <yyyy-mm-dd> +--- +``` +## Specification + +## Current DAI Transfer Ceiling + +- The intial DAI Transfer Ceiling will be set to 250,000 + +## Transfer Ceiling Change + +- Maximum amount of DAI that can be transferred from the protocol in total + +### Context and Motivation + +- Why is the Protocol DAI Transfer Ceiling being changed? + +### Relevant Links + +- Forum Discussions, etc diff --git a/MIP14/MIP14c4-Subproposals/placeholder.md b/MIP14/MIP14c4-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP14/MIP14c4-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP14/mip14.md b/MIP14/mip14.md new file mode 100644 index 000000000..2277a7a18 --- /dev/null +++ b/MIP14/mip14.md @@ -0,0 +1,121 @@ +# MIP14: Protocol DAI Transfer + +## Preamble +``` +MIP#: 14 +Title: Protocol DAI Transfer +Author(s): @LongForWisdom, @jtathmann +Contributors: +Type: Process +Status: Request for Comments (RFC) +Date Proposed: 2020-08-27 +Date Ratified: <yyyy-mm-dd> +Dependencies: MIP0 +Replaces: N/A +``` +## References +**[MIP14c2-Subproposal-Template.md](MIP14c2-Subproposal-Template.md)** +**[MIP14c4-Subproposal-Template.md](MIP14c4-Subproposal-Template.md)** + +## Sentence Summary + +MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. + +## Paragraph Summary + +MIP14 defines a generic process for transfering DAI from the Maker Protocol to a target ethereum address. This process is a fallback method of transferring value from the protocol in the event that a more specific process does not exist to do so. + +## Component Summary + +**MIP14c1: Considerations Regarding Protocol DAI Transfers** +A component which outlines the various considerations that should be made before transferring DAI out of the protocol using MIP14c2. + +**MIP14c2: Protocol DAI Transfer Process** +A process component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. + +**MIP14c3: Protocol DAI Transfer List** +A list component that lists the previous direct DAI transfers that have been made by the protocol in the past. + +**MIP14c4: Protocol DAI Transfer Ceiling** + +A process component that allows governance to define and modify the total amount of DAI that can be transferred from the protocol using MIP14 + +## Motivation + +Giving governance the ability to use the value generated by the Maker Protocol is beneficial for two main reasons: +- It allows Maker Governance to incentivise actions taken to improve the protocol. +- It reduces Maker Governance's reliance on the Maker Foundation. + +Less reliance on the Foundation moves the protocol towards decentralization. Creating a process to allow Maker Governance to spend the value accrued by the protocol empowers Maker Governance to build and improve the protocol in the future. + +## Specification / Proposal Details + +**MIP14c1: Considerations Regarding Protocol DAI Transfers** +There are several important considerations to take into account before transferring value out of the Maker Protocol. +- Transfer of DAI from the protocol to an external address that is not controlled by Maker Governance is a one-way operation. +- Transfer of DAI from the protocol will take DAI from the surplus buffer if available. +- If there is insufficient DAI available in the surplus buffer unbacked DAI will be created and FLOP auctions will be able to be triggered immediately. +- If there is a more specific process MIP that allows DAI transfers that is more appropriate to the use case, use that process instead. + +--- + +**MIP14c2: Protocol DAI Transfer Process** +MIP14c2 is a Process MIP component that allows Maker Governance to transfer DAI from the Maker Protocol to a target ethereum address. Note that MIP14c2 subproposals are technical subproposals, they define executive code that transfers DAI from the Maker Protocol to one or more target addresses. + +If a MIP14c2 subproposal is Accepted, The DAI Transfer is appended to the list in MIP14c3 by a MIP Editor. + +MIP14c2 subproposals have parameters that depend on the total amount of DAI to be transferred (even if split among multipe target addresses) according to the following logic: + +**< 10,000 DAI Transfer** +- **Feedback Period:** 0 full weeks +- **Frozen Period:** 0 full weeks + +**10,000 - 100,000 DAI Transfer** +- **Feedback Period:** 4 full weeks +- **Frozen Period:** 1 full week + +**> 100,000 DAI Transfer** +- **Feedback Period:** 12 full weeks +- **Frozen Period:** 4 full weeks + +If a MIP14c2 subproposal would result in a FLOP auction, Governance Facilitator(s) will use established communication channels to ensure the community is informed + +MIP14c2 subproposals must use the template located at **[MIP14c2-Subproposal-Template.md](MIP14c2-Subproposal-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. + +--- + +**MIP14c3: Protocol DAI Transfer List** +This list can be amended through subproposals created under MIP14c2. + +**List Entry Template** +Entries into this list should follow the following template: +``` +Reason: +Sub-proposal Number: # +Date Ratified: (yyyy-mm-dd) +Amount Transferred: +Recipient Address: +Total DAI Processed by MIP14 to date: +``` + +**Historical Transfer List** +There are currently no historical transfers. Below is an example transfer which should be removed (as should this paragraph) when the first ratified transfer is added to this list . +``` +Reason: Funding Chocolate for Governance Facilitators +Sub-proposal Number: MIP14c1-SP0 +Date Ratified: 2020-02-30 +Amount Transferred: 100,000 DAI +Recipient Address: 0x0000000000000000000000000000000000000000 +Total Dai Processed by MIP14 to date: 100,000 +``` + +--- + +**MIP14c4: Protocol DAI Transfer Ceiling** + +MIP14c4 sets the maximum amount of DAI that can be transferred in total from the protocol using this process. MIP14c2-subproposals will not be eligible if they cause the historic amount of DAI transferred from the protocol to exceed the ceiling, which will be initially set to 250,000 DAI and can be modified by MIP14c4 subproposal. + +**DAI Transfer Ceiling Adjustment** +- **Feedback Period:** 4 full weeks +- **Frozen Period:** 1 full week + diff --git a/MIP15/MIP15c8-Subproposals/placeholder.md b/MIP15/MIP15c8-Subproposals/placeholder.md index 48cdce852..bb4b95335 100644 --- a/MIP15/MIP15c8-Subproposals/placeholder.md +++ b/MIP15/MIP15c8-Subproposals/placeholder.md @@ -1 +1,2 @@ placeholder + diff --git a/MIP15/mip15.md b/MIP15/mip15.md index 84af043a0..96e6e8b2a 100644 --- a/MIP15/mip15.md +++ b/MIP15/mip15.md @@ -68,6 +68,7 @@ A dark spell is necessary because it conceals the bytecode that fixes the critic - **Dark Spell:** A special spell using an opcode that allows the address of a spell to be pre-determined before deployment. - **Governance Security Module (GSM) Delay:** A configurable delay attribute, setting the minimum wait time before governance votes can be applied to the system. + --- **MIP15c2: Dark Spell Process Overview** diff --git a/MIP16/mip16.md b/MIP16/mip16.md index 9e28cc3ae..bee698f33 100644 --- a/MIP16/mip16.md +++ b/MIP16/mip16.md @@ -8,9 +8,9 @@ Title: The Weekly Governance Cycle Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) Contributors: Type: Process -Status: Formal Submission (FS) +Status: Accepted Date Proposed: 2020-07-01 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-07-28 Dependencies: Replaces: n/a ``` diff --git a/MIP18/MIP18c4-Subproposals/MIP18c4-SP1.md b/MIP18/MIP18c4-Subproposals/MIP18c4-SP1.md index 661ca6864..b3d5ff7a3 100644 --- a/MIP18/MIP18c4-Subproposals/MIP18c4-SP1.md +++ b/MIP18/MIP18c4-Subproposals/MIP18c4-SP1.md @@ -5,10 +5,10 @@ MIP18c4-SP#: 1 Meta-parameter to add, modify or remove: Remove the DSR Spread Author(s): Rune Christensen (@Rune23), Charles St.Louis (@CPSTL) -Contributors: -Status: Formal Submission (FS) +Contributors: n/a +Status: Accepted Date of Submission: 2020-07-07 -Date of Ratification: <yyyy-mm-dd> +Date of Ratification: 2020-07-28 ``` ## Specification diff --git a/MIP18/mip18.md b/MIP18/mip18.md index daee13f5f..02a761e38 100644 --- a/MIP18/mip18.md +++ b/MIP18/mip18.md @@ -8,9 +8,9 @@ Title: Meta-Parameter Adjustments Author(s): @LongForWisdom, Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: Type: Process -Status: Formal Submission (FS) +Status: Accepted Date Proposed: 2020-07-07 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-07-28 Dependencies: Replaces: diff --git a/MIP19/mip19.md b/MIP19/mip19.md index 985c7184f..1ff29bc7e 100644 --- a/MIP19/mip19.md +++ b/MIP19/mip19.md @@ -7,16 +7,15 @@ Title: Liquidations System 1.1 Upgrade Author(s): Mariano Conti (@nanexcool), Charles St.Louis (@CPSTL) Contributors: Kurt Barry (@kmbarry1) Type: Technical -Status: Formal Submission (FS) +Status: Accepted Date Proposed: 2020-07-06 -Date Ratified: <yyyy-mm-dd> +Date Ratified: 2020-07-28 Dependencies: n/a Replaces: n/a License: AGPL v3.0 ``` ## References -- [Executive Vote: Unblock the remaining Debt Auctions Blog Post](ttps://blog.makerdao.com/executive-vote-march-26-2020/) - [Debt Auction Blocking in the Dai Credit System Presentation by Kurt Barry](https://docs.google.com/presentation/d/1nnpPBiOLEWi81q8zrHoIWH4s3iQaKrCSaR68AafzQJo/edit#slide=id.p) - [Video recording of the presenation](https://www.youtube.com/watch?v=erh25lnaIo0) - [Formal Verification Run](https://reports.makerfoundation.com/k-dss/dcc4d3a8fcab50a5af6f/) diff --git a/MIP20/mip20.md b/MIP20/mip20.md new file mode 100644 index 000000000..ff9c6a56c --- /dev/null +++ b/MIP20/mip20.md @@ -0,0 +1,116 @@ +# MIP20: Target Price Adjustment Module (`Vox`) + +## Preamble +``` +MIP#: 20 +Title: Target Price Adjustment Module (`Vox`) +Author(s): Lev Livnev (@equivrel), 🌧️ McRainface +Contributors: n/a +Type: Technical +Status: Request for Comments (RFC) +Date Proposed: 2020-07-08 +Date Ratified: <yyyy-mm-dd> +Dependencies: n/a +Replaces: n/a +License: AGPL3+ +``` +## References + +- The proposed [dss-vox](https://github.com/livnev/dss-vox) implementation +- [target price adjustment in purple paper](https://makerdao.com/purple/#sec-4-3) +- [target price adjustment in sai](https://github.com/makerdao/sai/blob/master/src/vox.sol#L63) +- [The Target Rate Feedback Mechanism: An Introduction](https://forum.makerdao.com/t/the-target-rate-feedback-mechanism-an-introduction/2319) + +## Sentence summary + +This proposal provides a smart contract implementation of `Vox`, a module which adjusts the target price of DAI according to a governance defined rate, allowing the institution of negative effective interest rates. + +## Paragraph summary + +The Dai Stablecoin System is intended to reliably maintain dai's exchange rate with respect to a reference asset (USD). Certain parameters of the System, such as the Stability Fee, are administered by Maker governance on an ongoing basis in response to evolving market conditions. This MIP implements the `Vox` module, which allows Maker governance to institute negative effective interest rates. In contrast to the Target Rate Feedback Mechanism (TRFM), the mechanism in this proposal does not adjust rates algorithmically using a DAI price oracle. Instead, the target rate is set directly by governance, similary to how the Stability Fees and Dai Savings Rate are set today. + +## Component summary + +**MIP20c1: Definitions:** defines Target Price, Target Rate, Target Price Adjustment Module, and Target Price Cap. + +**MIP20c2: Desired properties:** lists important properties that the `Vox` implementation must satisfy. + +**MIP20c3: Proposed code:** contains snippet of proposed implementation. + +**MIP20c4: Test cases:** lists existing test cases, including integration test + +**MIP20c5: Security considerations:** comments on the limited nature of the security implications of adding the `Vox`. + +**MIP20c6: Other considerations:** describes the changes to governance of monetary policy, and contrasts the proposal in this MIP with the TRFM. + +**MIP20c7: Formal verification/audit information:** comments on the amenability of the proposed code to formal verification, even though formal specification, audit, or code review have yet to be conducted. + +**MIP20c8: Licensing:** states the license under which the proposal and code are distributed. + + +## Motivation + +In an environment where the supply of DAI is too low to meet demand, monetary policy might find itself at the "zero lower bound" where stimulus can no longer be effected through lowering interest rates. In this case, it may necessary to purseu a policy of negative interest rates, in which the direction of the cashflow is reversed, with savers possibly paying borrowers. In the system as it exists today, the combination of the CDP Stability Fee and Dai Savings Rate serves as a cash flow from borrowers (CDP users) to savers (DAI holders), or in other words, an interest rate. However, that interest rate is effectively constrained to be positive: though it is technically possible to accrue a negative interest rate to CDPs, depositing DAI into the Savings Contract is optional so savers would be able to avoid negative rates simply by not using it, leaving a deficit on MakerDAO's balance sheet. + +A crucial requirement in the implementation of this policy is for all DAI holders to be exposed to the negative rate. For technical reasons, it is not feasible to continuously manipulate on-chain user token balances, since this behaviour would undermine the implicit assumptions of well-behaved token semantics and could break integrations into other smart contract systems. A more compliant way of implementing negative interest rates is to manipulate the target price of DAI itself: this MIP implements such a system. + +Adjusting the target price of DAI up or down causes an implicit value transfer from DAI borrowers to DAI holders, or from DAI holders to DAI borrowers, respectively, meaning that Target Price adjustment at a fixed rate of change acts like an effective interest rate, with a negative Target Rate corresponding to a negative effective interest rate. + +## Specification + +### MIP20c1: Definitions + +- **Target Price**: the system accounting price of 1 DAI in USD. This is currently represented as `spot.par()`, and is set to $1.00. Multi-collateral dai uses the Target Price in two places: when measuring the collateral ratio of a CDP, and when calculating the redemption value of DAI after Emergency Shutdown. The governance community may also use the Target Price as the price target for DAI/USD when setting interest rates and other risk parameters. +- **Target Rate**: the annualised compounding rate of change of the Target Price (short for Target Price Adjustment Rate). +- **Target Price Adjustment Module**: the smart contract which periodically adjusts the Target Price by the Target Rate. +- **Target Price Cap**: the maximum Target Price that the Target Price Adjustment Module is able to set. + +### MIP20c2: Desired properties + +- At every call to `vox.prod()`, `spot.par()` should change by the target rate accrued over the period of time since the last call to `vox.prod()`. +- The Target Rate should be initialised at 0% per year, which results in no change to the Target Price. +- The Target Price should not be adjusted after Emergency Shutdown, regardless of the value of the Target Rate prior to Emergency Shutdown. +- The Target Price should not be adjusted above the Target Price Cap. When the Target Price Cap is reached, the Target Price should be set to exactly the Target Price Cap and further upward adjustments should have no effect. + +### MIP20c3: Proposed code + see [vox.sol](https://github.com/livnev/dss-vox/blob/master/src/vox.sol). The core price adjustment functionality is simple: + +``` +function prod() external { + uint256 age = sub(now, tau); + tau = now; + + if (age == 0) return; // optimised + if (way == ONE) return; // optimised + if (spot.live() == 0) return; // no adjustment after cage + + uint256 par = min(cap, rmul(rpow(way, age, ONE), spot.par())); + spot.file("par", par); +} +``` + +### MIP20c4: Test cases + +see [vox.t.sol](https://github.com/livnev/dss-vox/blob/master/src/vox.t.sol) + +- `test_prod_noop` +- `test_prod_basic` +- `test_prod_cap` +- `test_mainnet_target_adjustment` (this one is an integration test using the mainnet deployment of `dss`) + +### MIP20c5: Security considerations + +The proposed solution is simple and non-invasive, interacting with only one other component of the system (the `Spotter`) through an existing method for adjusting the `par` price. Even though the core system was designed with the possibility of a changing `par` in mind, peripheral components and integrations should be carefully inspected for reliance on a fixed `par`. + +### MIP20c6: Other considerations + +Upon adoption of this MIP, the Target Rate parameter can be adjusted by governance as an additional monetary policy lever, similar to the current notion of "Base Rate". Monetary policy processes may have to be amended in order to leverage this facility, and this MIP may be expanded in order to specify them. + +This MIP can be compared with the folkloric Target Rate Feedback Mechanism (TRFM), an unused implementation of which was present in single-collateral dai. The TRFM relies on the same notion of adjusting the target price of DAI as a monetary policy tool. The crucial difference between the TRFM and the mechananism proposed in this MIP is that while the TRFM algorithm sets the Target Rate automatically and continuously depending on a DAI price oracle, this MIP does not propose for the Target Rate to be set algorithmically. + +### MIP20c7: Formal verification/audit information + +The proposed contract is written in a way which is amenable to formal specification and verification, in accordance with the style and practices of the core multi-collateral DAI contracts, though it has not been formally specified. No audit or code review has taken place yet. + +### MIP20c8: Licensing + - [AGPL3+](https://www.gnu.org/licenses/agpl-3.0.en.html) diff --git a/MIP21/MIP21.md b/MIP21/MIP21.md new file mode 100644 index 000000000..fdf700bf8 --- /dev/null +++ b/MIP21/MIP21.md @@ -0,0 +1,159 @@ +# MIP21: Real World Assets - Off-Chain Asset Backed Lender + +``` +MIP#: 21 +Title: Real World Assets - Off-Chain Asset Backed Lender +Author(s): Matthew V Rabinowitz (@mrabino1) +Contributors: Lev Livnev (@equivrel) +Type: Technical +Status: Request for Comments (RFC) +Date Proposed: 2020-09-01 +Date Ratified: <yyyy-mm-dd> +Dependencies: MIP13c3-SP4 (Declaration of Intent - Off-Chain Asset Backed Lender to Onboard Real World Assets as Collateral for a DAI loan) +Replaces: n/a +License: n/a +``` +## References +- MIP13c3-SP4 - Declaration of Intent [Link](https://forum.makerdao.com/t/mip13c3-sp4-declaration-of-intent-commercial-points-off-chain-asset-backed-lender-to-onboard-real-world-assets-as-collateral-for-a-dai-loan/3914) +- [prototype source code](https://github.com/livnev/rwa-example) + +## Sentence Summary +This proposal defines a MakerDAO Module implementation for DAI borrowing with Real World Asset Backed Lenders. + +## Paragraph Summary + +With the proposed on-boarding of Real World Assets as collateral into the Maker protocol, we will be requesting a technical MIP as we need to trailblaze a new way to engage the “real-world” while still having an umbilical to the blockchain. This will require some technical modifications to how the system handles collateral / liquidations etc. as well as adding some smart contracts (as outlined below) to handle the minting and repayment process. This Technical MIP is being submitted in parallel (with the Declaration of Intent) for MKR governance consideration. + +## Component Summary + +**MIP21c1: Collateral Parameters** where the per-collateral asset parameters are defined. + +**MIP20c2: Smart Contract Components** where the contracts novel to this proposal are listed and described. + +**MIP20c3: Liquidation Oracle** where the details of the liquidation oracle contract are described. + +**MIP21c4: Write-offs** where the process for writing off losses is described. + +**MIP20c5: Proposed Code** where the proposed code is linked. + +**MIP20c6: Test Cases** where the test cases are listed. + +**MIP20c7: Security Considerations** is TODO + +**MIP20c8: Auditor Information and Report** is TODO + +## Motivation +See paragraph summary above. + +## Specification + +### MIP21c1: Collateral Parameters +- **Liquidation remediation period** (`tau`): +- **Asset document hash** (`doc`): + +### MIP21c2: Smart Contract Components + +Inserting real world assets via an off-chain asset backed lender, where the liquidations are handled by a third-party requires certain changes to how a module would interact with the Maker protocol. Specifically, +- Minting +- Repayments +- Liquidations +- Write-offs + +The above said, many items remain un-changed from the current mechanism: +- Debt computation +- Interest Rates +- Debt Ceiling Constraint + +The smart contracts implementing the new functionality are as follows: + +- `RwaLiquidationOracle`: which acts as a liquidation beacon for an off-chain enforcer. +- `RwaFlipper`: which acts as a dummy liquidation module in the event of write-offs. +- `RwaUrn`: which facilitates borrowing of DAI, delivering to a designated account. +- `RwaDeploySpell` (TODO): which deploys and authorises the components for RWA collateral types +- `RwaInitSpell` (TODO): which activates a new RWA collateral type +- (TODO) auxiliary wallet contracts for handling disbursement and repayment of DAI. +- `RwaLiquidateSpell` (TODO): which allows MakerDAO governance to initiate liquidation proceedings. +- `RwaRemedySpell` (TODO): which allows MakerDAO governance to dismiss liquidation proceedings. +- `RwaWriteoffSpell` (TODO): which allows MakerDAO governance to write off a loan which was in liquidation. + +### MIP21c3: Liquidation Oracle + +Instead of performing liquidations via on-chain public auctions, triggered by a continuously updated price feed, liquidation is triggered manually by MakerDAO governance and is enforced off-chain by a third party. The standard oracle and auction infrastructure are replaced by a "liquidation oracle" contract. MakerDAO governance can initiate liquidation proceedings, when they deem it necessary, by calling `tell()` on the `RwaLiquidationOracle`. This starts the countdown, and after the remediation period has passed the oracle will start to report that the position is under liquidation. If the cause for triggering liquidation has been remedied, or if the original liquidation trigger was illegitimate, during the remediation period, or after, MakerDAO governance can dismiss the liquidation proceedings by calling `cure()`. + +An off-chain enforcer (such as a trustee, etc.) can periodically check the liquidation status of the position by calling `good()`. `good()` will report that the position is in liquidation if and only if MakerDAO governance has triggered liquidation with `tell()` and the remediation period has passed without `cure()` being called. + +### MIP21c4: Write-offs + +If at the end of the liquidation process there is still debt remaining on the position, and MakerDAO governance believes that the debt will not be paid off, it can trigger a write-off by calling `cull()`. Write-off works by setting the system's collateral value to zero, which will cause the position to proceed to on-chain liquidation via `bite()`, etc. Unlike the liquidation modules for existing collateral types, the specialised liquidation module `RwaFlipper` does not attempt a sale of the underlying collateral and instead just marks the loss on the system's balance sheet by allowing system debt to be created. + + + +### MIP21c5: Proposed Code (WIP) +[Real World Assets Example](https://github.com/livnev/rwa-example) + + +### MIP21c6: Test Cases (TODO) +- Add Real World Asset Module +- Mint DAI +- Repay DAI +- Modify Annual Interest Rate +- Liquidate Vault +- Write-off any associated losses + +### MIP21c7: Security Considerations +The framework surrounding minting and repaying DAI is rather battle-hardened. Further, the computation on interest rate calculations and debt ceilings is equally hardened. + +Counterintuitively, the majority of the functionality related to liquidations will be completed by real world people that are using legal documents to govern their actions. Thus many of the features that might otherwise cause security vulnerability may be disabled as they are effectively outsourced to a Trust company or the legal system in general. + +### MIP21c8: Auditor Information and Report +The code has not been audited. + +## Additional Information + +### Mint Process + +All smart contracts below are owned by and controlled by MKR Governance, not LendCo. + +1. With a smart contract triggered by LendCo and another MKR holder, the DAI created is sent to a “Tax Favorable Entity” (“TFE”) ETH address. + + 1. Minting was “gated” by LendCo but not caused by LendCo + 2. DAI is now created and at the TFE + 3. The ETH address for the TFE is controlled and may be subsequently modified by MKR Governance. + +2. Anyone with MKR may trigger the smart contract to move the DAI from the TFE to the Trust (w/ one exception. LendCo is specifically excluded as a party that can cause this). + + 1. DAI is now being borrowed (from the TFE to the Trust). The DAI is now at the Trust. + 2. The ETH address for the Trust is controlled and may be subsequently modified by MKR Governance. + +3. LendCo may then borrow DAI from the Trust. + + 1. The LendCo recipient target ETH address is changeable by MKR Governance. + 2. LendCo’s ETH address shall be a confirmed / validated, constant address for a registered broker-dealer OTC desk FBO of LendCo. + +The above process removes the custody risk for the DAI and inserts a process for accounting to track that DAI was minted into existence to a TFE, then moved from TFE to a jurisdiction specific “trust” account (or its equivalent). From there, the DAI is borrowed from the Trust when it is called upon by LendCo. + +In reverse, + +1. LendCo sends fiat wire to the broker-dealer OTC desk. +2. OTC desk converts fiat to DAI. +3. OTC desk orders the transfer of DAI to a previously validated ETH address (which is a smart contract) which was requested by LendCo +4. That Smart contract address is and represents the “Trust.” +5. Thereafter anyone that has MKR can cause that DAI to be transferred to the TFE ETH address. +6. Finally anyone can cause the TFE ETH address to pay down the Vault balance. + - The above said, the underlying functionality will always exist that will allow anyone to pay down this vault. + +**Note:** None of the addresses above are “owned” or controlled by LendCo. The addresses are Always with MKR governance. Important add-on: it is important for the DAI to have a source of origination; a stop in TFE; another stop in the Trust;. and then to its final destination. In all cases, LendCo / the Trust / TFE need a paper trail for accounting and regulatory compliance. The reasons for the gating of DAI minting and movements is that DAI loans may not be caused from minting to LendCo without the explicit assistance from someone else in the MKR community.) + +**Operational Security** + +Given the size and centralization of an off-chain asset backed lender, OpSec is a critical component to be hardened prior to any material debt ceiling being allocated. To that end, it is presently contemplated that LendCo will have its Vault adapter be modified away from the default (where DAI is returned to the originating ETH address) since we are planning to implement the above minting and repayment process. + +The foregoing serves three purposes: + +1.) To minimize the attack surface to as little as possible on the minting of DAI + +2.) To allow for LendCo to clear a financial audit, as Broker / Dealer will issue account statements that outline the arrival of DAI and the sales/purchase price. + +3.) The Broker / Dealer has already completed KYC / AML on all of the cash that is used in exchange for the DAI (in both directions). + +--- diff --git a/MIP22/mip22.md b/MIP22/mip22.md new file mode 100644 index 000000000..54733975b --- /dev/null +++ b/MIP22/mip22.md @@ -0,0 +1,183 @@ +# MIP22: Centrifuge Direct Liquidation Module + +## Preamble +``` +MIP#: 22 +Title: Centrifuge Direct Liquidation Module +Author(s): Lucas Vogelsang (@spin on forum.makerdao.com, lucas@centrifuge.io) +Contributor(s): Lea Schmitt (lea@centrifuge.io), Lev Livnev (@equivrel on forum.makerdao.com) +Type: Technical +Status: Request for Comments (RFC) +Date Proposed: 2020-09-02 +Date Ratified: yyyy-mm-dd +Dependencies: none +Replaces: none +Licenses: AGPL + +``` + +## References + +- Introductory post discussing the economics and legal benefits of this liquidation: [Vault Liquidation Mechanism for Centrifuge Trade Finance Assets - A Pre MIP Discussion](https://forum.makerdao.com/t/vault-liquidation-mechanism-for-centrifuge-trade-finance-assets-a-pre-mip-discussion/3737) +- Relevant MIP6 Proposals for which this liquidation could be used: [Paperchain](https://forum.makerdao.com/t/pc-drop-mip6-application-paperchain-drop-tokenized-music-streaming-invoices/2215), [ConsolFreight](https://forum.makerdao.com/t/cf-drop-mip6-application-consolfreight-drop-tokenized-freight-shipping-invoices/2214), [Harbor Trade Credit](https://forum.makerdao.com/t/htc-drop-mip6-application-harbor-trade-credit-drop-short-term-trade-receivables/3502) +- Example code: `tinlake_flip.sol` and `drop_join.sol` in this repository + +## Sentence Summary + +This proposal provides a vault liquidation mechanism for Tinlake based short-term loan collateral that entails letting a portfolio of said short term assets mature or refinance them off-chain and using loan repayments to settle the Vault balance. + +## Paragraph Summary + +For Vaults of Centrifuge pooled short term loans, auctioning off a portfolio of short term loans is not necessarily the most effective way for Maker to liquidate a vault. When these assets are very illiquid the discount a keeper would want outweights the benefit of just waiting for maturity of the underlying loans. Centrifuge has built the Tinlake contracts to manage the liquidations of loan portfolios on chain. This mechanism allows the Maker smart contracts to get direct access to these repayments without the need for any external keepers. + +## Component Summary + +**MIP22c1: Collateral Prerequisites** +Describes the requirements for the collateral type to make use of the proposed liquidation module. + +**MIP22c2: Liquidation Mechanism** +Describes the mechanism by which Vaults are liquidated when the described adapter is used. + +**MIP22c3: Definitions** +Adapter Component Definitions + +**MIP22c4: Proposed Code** +An explanation of the logic along with code + +**MIP22c5: Usage of Code & Test Cases** +Still outstanding + +**MIP22c6: Security Considerations** +Still outstanding + +**MIP22c7: License** +The code is licensed under APGL. + +## Motivation + +As we have stated in previous threads and discussions we believe that adding real world assets (RWA) to MCD is the path forward to scale Dai supply and balance the collateral risk portfolio through uncorrelated assets. + +A key issue preventing the addition of RWA to the Maker Protocol has been the absence of a reliable process to liquidate a Maker vault that is backed by these assets. + +When a legal entity invests in a Tinlake pool that is backed by RWA they enter a legal contract with the issuer and therefore get a legal claim on the underlying collateral (the real world asset). + +When Maker liquidates a Vault backed by these tokens it must have a way to get the DAI repaid that was generated in the Vault without having to enter a legal contract with the issuer. + +We are proposing a liquidation mechanism that solves for that whenever a Vault is backed by by **short-term loan collateral**. This mechanism does not require an auction and no additional legal structures. We see this solution as a major push towards making RWA in MCD a reality near term. + +The solution proposed in this MIP requires that the pool of loans that is tokenized through Centrifuge is either: +1. Of very short maturity and waiting for loan maturity is economically viable. + +**or** + +2. The loans can be sold off (refinanced) by the issuer off chain and there is a process in place for the liquidation of the pool in case any DROP token holder (such as Maker) + +Whether the proposed liquidation component should be used for a given collateral type should be part of the Risk Assessment and discussed on an asset by asset basis. If that is desired, the below code should be configured to be used when adding a new collateral with the MIP12 executive vote. + + +## Specification + +### MIP22c1: Collateral Prerequisites + +Assets that should be able to use this collateral have a few requirements: +* This only works for collateral that is using Centrifuge's Tinlake smart contracts to tokenize their off-chain loans. +* There must be sufficient investors besides MakerDAO that ensure the correct operation of the legal recoure. +* The Risk Domain Teams deem this liquidation mechanism for the collateral type sufficient. + +--- + +### MIP22c2: Liquidation Mechanism + +When the liquidation of a Vault is kicked, the proposed liquidation adapter forces the Tinlake pool into liquidation by submitting an order to redeem all collateral in the Vault. The Tinlake contracts than automatically allocate all incoming cash-flows from borrowers to investors (i.e. the Maker Vault) for redemptions. + +![](https://storage.googleapis.com/centrifuge-hackmd/upload_a65b9b92a17a23596ab4c0d4a2404ff7.png) + +--- + +### MIP22c3: Definitions +* **Tinlake Flipper:** the contract that can liquidate a Vault by going to the Tinlake Pool contracts to redeem DROP for DAI and then transfer the raised DAI to the `Vow` +* **DROPJoin:** An adaptor based heavily on GemJoin which allows only a selected Tinlake pool contract to add collateral to the Maker Vault. +* **Tinlake Pool:** a pool of asset backed loans settled in DAI +* **DROP:** the senior pool share ERC20 token which is redeemable against a share of the DAI repaid by the loans in the Tinlake Pool + +--- + +### MIP22c4: Proposed Code +The code has been kept to a minimum and any functional changes are shown below. We will publish a Git repository after collecting feedback on this proposal (to be ammended). The code in full can be viewed [here](https://github.com/lucasvo/mips/tree/mip22/MIP22). + +For each Tinlake pool there will only be one Vault owned by the pool. The pool will have the logic necessary to manage the Vault. We modify the standard GemJoin adapter to only allow the `join` method to be called by `wards` (i.e. it is an authorized call). This will prevent anyone else from opening a CDP with DROP tokens as they would not be able to add the collateral to the system. + +The `TinlakeJoin` contract looks as follows. Note the added `auth` modifier in the `join` function. This is the only necessary change. + +``` +contract DROPJoin is GemJoin { + function join(address usr, uint wad) external auth note { + require(live == 1, "GemJoin/not-live"); + require(int(wad) >= 0, "GemJoin/overflow"); + vat.slip(ilk, usr, int(wad)); + require(gem.transferFrom(msg.sender, address(this), wad), "GemJoin/failed-transfer"); + } +} +``` + +The `Tinlake Flipper` takes all of the collateral from a Vault and requests redemption from the pool. The Tinlake contracts then enforce that any payments on loans are disbursed to the any DROP holder that requests redemption. As DAI is redeemed from the Pool, the adapter transfers the DAI into the `vow` until the `tab` is recovered. At that point any additional DAI that could be redeemed with the DROP is given back to the Pool. + + The auction mechanism is binary: only liquidating part of the collateral would not be desired from an economical perspective. Therefore the mechanism is designed to liquidate everything and only after return any excess DAI raised to the pool. + + When a Vault is liquidated (`Cat.bite` is called), the Cat will call `Flipper.kick` which kicks off the liquidation. At first it withdraws the entire collateral (the DROP tokens) from the system and places a `redeemOrder` on the `pool` contract. + + ``` + function kick(address dest_, address gal, uint256 tab_, uint256 lot, uint256 bid) + public auth returns (uint256 id) + { + vow = gal; + dest = dest_; + tab = tab_; + vat.flux(ilk, msg.sender, address(this), lot); + dropJoin.exit(address(this), lot); + pool.redeemOrder(drop.balanceOf(address(this))); + emit Kick(id, lot, bid, tab_, dest, vow); + } +``` + +The redeem order will now be taken into account whenever loan repayments flow into the pool or other investors want to join the pool. As the pool redeems the DROP any user can call the function `take`. It moves the DAI available for withdrawal from the pool and either repays up outstanding debt (`tab`) to the `vow` or returns it to the pool. This method can be called multiple time to cause the pool to `disburse` more DAI and return it to the pool as funds available for borrowers. + +``` + function take() public { + (uint returned, ) = pool.disburse(); + uint tabWad = tab / RAY; // always rounds down, this could lead to < 1 RAY to be lost in dust + if (tabWad < returned) { + dai.transfer(dest, sub(returned, tabWad)); + returned = tabWad; + } + if (tab != 0) { + daiJoin.join(vow, returned); + tab = sub(tab, mul(returned, RAY)); + } + } +``` + +The Tinlake smart contracts collect redeem orders and return any DAI returned by borrowers proportionally to all DROP token holders first. This means that to receive highest priority on the redemption the liquidation should request the entire DROP to be redeemed. + +This can be done by setting the variable `dunk` to `uint(-1)`. This raises the minimum size of the collateral to auction off during the liquidation to above the maximum collateral that can ever exist thus forcing liquidation of the entire Vault and not just part of it. + +--- + +### MIP22c5: Test Cases +Tinlake is undergoing an audit which will be published by Sep 22nd. We will ammend this section with information on the test cases we have covering both the + +--- +### MIP22c6: Security Considerations + +This section will be completed. The core Tinlake contracts have undergone security audits in the past ([reports](https://github.com/centrifuge/security/tree/master/audits/tinlake)) and we will be publishing the audit we are conducting for the next release in the next few weeks as it is ready. + +As for the contracts that interact directly with MakerDAO (TinlakeFlipper and DROPJoin) those will be submitted with extensive test coverage and have been written following MakerDAO/DappHub's smart contract style guide, make use of no external libraries and are easy to audit totalling to less than 100 lines of code. + +--- +### MIP22c7: License + +- All code is licensed under the AGPL license + +--- + + diff --git a/MIP22/tinlake-maker-lib b/MIP22/tinlake-maker-lib new file mode 160000 index 000000000..03daffefd --- /dev/null +++ b/MIP22/tinlake-maker-lib @@ -0,0 +1 @@ +Subproject commit 03daffefdbe61a5b479d0e374c6d05eb0e53b7f7 diff --git a/MIP26/mip26.md b/MIP26/mip26.md new file mode 100644 index 000000000..0b493b742 --- /dev/null +++ b/MIP26/mip26.md @@ -0,0 +1,160 @@ +# MIP26: DssGov - Governance Contract Redesign + +## Preamble +``` +MIP#: 26 +Title: DssGov - Governance Contract Redesign +Author(s): Smart Contracts Domain Team +Type: Technical +Status: conception +Date Proposed: 2020-10-06 +Dependencies: +Replaces: DSChief +``` + +## Sentence Summary +This MIP defines **DssGov**, a contract replacement for **DSChief** that comes with improved security, usability and functionality for holders of the Maker governance token (MKR). + +## Paragraph Summary +The Governor Contract, or DssGov for short, is a Dai Stablecoin System Contract that authorises Maker governance to make changes to the Maker protocol by supporting on-chain proposals. Unlike the existing DSChief, DssGov introduces security enhancements to prevent flashloan actions, usability improvements to enable multiple concurrent executive votes, as well as delegation functionality to allow holders to delegate their vote. This contract will also support integration with Layer 2 solutions to enable off-chain vote participation. + +## Executive Summary - the proposed DssGov contract supports: +- Multiple concurrent proposals +- A threshold that must be exceeded for proposals to pass +- Delegation +- Flashloan risk prevention + +The technical complexity and impact of this MIP is considered HIGH due to it being a critical part of the Maker protocol. + +## Motivation +This Maker Improvement Proposal initially stemmed from a need to make the existing governance contract more secure and user friendly, however it quickly became apparent that a new contract must also introduce additional functionality such as delegation to meet community needs and ecosystem evolution. + +For a summary of the existing Governance system please refer to the [Governance Chief Contract Redesign: A Pre-mip Discussion](https://forum.makerdao.com/t/governance-chief-contract-redesign-a-pre-mip-discussion/3080) and the [Chief - Detailed Documentation](https://docs.makerdao.com/smart-contract-modules/governance-module/chief-detailed-documentation) for a detailed view of the DSChief smart contract. + +From a **security** perspective the above pre-MIP discussion revealed a number of motivations for change, including: +- The current governance contract implementation is exposed to transition risk when moving votes from one proposal to another because a reduced amount of MKR could be used to elect a random (and potentially malicious) proposal. +- When a new proposal gains a majority of MKR, the action of lifting a new hat is not an automatic/instant action, meaning that alternative proposals can sneak in to introduce unexpected changes. +- Stray spells can exist without expiry, potentially posing an ongoing threat to the system. +- There is no pause duration between user lock/free actions leading to a potential flashloan risk. +- Migration risk when moving to a new Chief contract (such as DssGov), where authority must be transferred which introduces a coordination problem to ensure that there is enough MKR on the new contract’s hat while also ensuring there is enough MKR in the old chief to pass the proposal. +- MKR distribution across proposals potentially weakens the current HAT and exacerbates the above transition/migration risks. + +From a **usability** perspective, motivations include: +- That the current system is only able to support a single executive at a time which is unmanageable and doesn’t scale with the addition of more collateral types and risk parameters. +- That the use of the hat mechanism (the transition from one proposal to another) would not allow multiple concurrent proposals to exist. + +Discussion of the above, also introduced motivations for **additional functionality**: +- Support for Layer 2 integration to facilitate off-chain voting and reduce/eliminate rising gas costs +- Support for Delegation thereby allowing users to help secure the system even through they may not be weekly participants + +Taking the above motivation as inspiration, it is evident that much of the complexity stems from the existing hat paradigm. Rethinking this design gives the Maker community an opportunity to explore more secure and usable methods of governance. + +## Specification +The new design utilises a threshold mechanism that, alongside snapshotting, enables multiple concurrent executives as well as support for delegation and protection against flashloans. These features and capabilities will be described in the specifications below. + +### MIP26c1 Utilizing a threshold that must be exceeded for a proposal to pass +This new design uses a variable threshold based on the amount of active MKR locked in DssGov. This threshold must be exceeded in order for a spell to be cast and make protocol changes. This is a departure from the Hat paradigm currently used, which requires users to shift their MKR from one proposal to another. In addition to the security motivations mentioned above, this design improvement also allows for the support of multiple concurrent proposals once voters have locked their MKR in DssGov. + +It will be the responsibility of governance to define the threshold as a percentage of the amount of active MKR locked in DssGov. This value will be a percentage value as opposed to an absolute number because a fixed number may introduce an unreachable amount causing the system to cease to function if that value is unable to be reached. + +**Voter engagement in 2020 illustrates the following levels of participation**: + +![](https://i.imgur.com/SDd27CO.png) + + +Further risk analysis and research will be conducted to determine the correct threshold level, however initial review indicates that a level higher than 50k MKR would have been sufficient for all but one of this year’s executive votes. This design is also considering an upper boundary to the threshold to prevent accidental locking of the system if an unattainable level were to be set. This would be a constant value and if included would be voted on by Governance when accepting the design. + +The concept of a threshold introduces the need to ensure that the MKR in DssGov is ‘active’ MKR, i.e. not stale or forgotten MKR which is something expanded upon below. + +### MIP26c2 Using active/inactive MKR to define the threshold +Due to the threshold relying on the amount of active MKR locked in DssGov, it becomes necessary to ensure that the locked MKR is not old, forgotten, or lost. This is important to prevent the "stale" MKR from skewing the threshold value and make it impossible for actual participating MKR to reach the required numbers to pass a proposal. + +If MKR has remained inactive for a period of time as defined by governance it will be considered stale and will no longer count towards the total active amount of MKR. It is expected that this period of time will be defined as a number of weeks or months pending further analysis. Inactivity can be influenced both by the inactivity of the owner, and if the owner has delegated their MKR, then also the inactivity of the delegated address. Both periods of inactivity can have different time values as defined by governance. + +It is expected that the period at which a delegate becomes inactive will be much shorter than the point at which an MKR owner becomes inactive. This is to ensure that delegates are acting in the interest of the MKR delegated to them, while the MKR owner doesn’t have to interact with the system as often to confirm their continued involvement. + +If a delegate becomes inactive this means that the voting rights delegated to them will also become inactive and likewise no longer count towards the total active amount of MKR (which influences the threshold calculation). If however a delegate becomes active again after being inactive, they can reactivate the MKR delegated to them unless the owner has since removed their delegation. + +Inactivity of an owner means that their delegation will be removed from any delegated address. In the event that an owner’s MKR becomes inactive, it will be possible for the MKR owner to return the MKR back to their original account as a separate transaction. Alternatively, they will be able to delegate once again if desired. + +The ability to make a user’s MKR inactive is made possible through the following gas mint/burn mechanism explained in the next section. + +### MIP26c3 Mint/burn function to facilitate accurate counting of MKR balances +When an MKR owner locks their MKR in DssGov, they will be minting a gas token. This gas token will allow any bot or altruistic participant to remove that user’s MKR from the total amount of active MKR if it becomes stale. Due to the existence of the gas token there will not be any cost to a bot/altruistic user for undertaking this action, which will maintain a fresh state for the threshold to reference. + +Minting a gas token occurs in two instances: +1. When an owner delegates to themselves or to a delegate address they will be minting a gas token and, +2. When a delegated address begins its period of activity it will also mint a gas token. + +These operations will ensure that it is possible for third parties to unwind inactive MKR from the system. Keeping the protocol updated with the correct amount of active MKR is not only important for managing the threshold, but also for a new function that we will introduce now, called snapshotting. + +### MIP26c4 Using snapshots to record MKR account balances participating in governance +Snapshotting is the process of calculating MKR account balances locked in DssGov at the point in time that a proposal was created. The system will therefore only allow that maximum amount of MKR recorded at the time of the snapshot to vote on the respective proposals. + +If a user adds or removes MKR after a proposal has been created, the amount of MKR recorded as part of the snapshot will not be altered for those proposals. Future proposals will use a new snapshot that will record a new MKR balance calculated at the time of the proposal’s creation. + +Snapshotting is important because it eliminates the gas intensive nature of unvoting MKR from old proposals to vote for new proposals. This mechanism coupled with the threshold optimises user governance interaction with the protocol. In order to make this solution function correctly, it is important to know that in the background there are two explicit snapshots: + +**User Action Snapshot** - captures the amount of voting rights a user has since they made their last action. An action could include any kind of change in their voting rights; locking, freeing, delegating their MKR, or having their MKR declared inactive due to it not being used as per MIP26c3 (the mint/burn function). + +**Proposal Creation Snapshot** - records the total active MKR amount in DssGov at the moment of proposal creation based on the user action snapshots. This value will be used to determine the threshold and quorum values. It is not possible for the proposal creation snapshot to record all user voting rights in one go - as one might do with a traditional database, instead it must reference the user action snapshot to check the user’s corresponding voting rights. + +### MIP26c5 Supporting multiple proposals +Although multiple concurrent proposals are made possible through the aforementioned threshold and snapshotting mechanisms, it is worth calling this out independently as a new capability because it is the main pain point for governance participants today. Currently, users are unable to participate in multiple concurrent proposals without locking/freeing MKR from one proposal to another as part of the continuous approval voting system. + +This redesign removes the need to shift MKR weights and also eliminates the need for bundling proposals as users will be able to interact with multiple concurrent proposals. As previously mentioned, these proposals will only pass if the amount of MKR in the snapshot exceeds the defined threshold. + +The voting experience retains the existing ‘yes’ voting in support of a proposal, where there is no explicit ‘no’ vote. This again reinforces the importance of the threshold. This design decision has been chosen to facilitate faster voting. An alternative design would require a voting window in which yay/nay votes would contribute towards an outcome at the end of a time period. Such a time period of e.g. 3 days would prevent quick changes to risk parameters, as such the time-window solution along with the use of explicit ‘no’ votes was dropped in favor of continuous approval voting. + +One can imagine the frontend implementation surfacing multiple proposals, each of which can now pass on their own independent merit. These proposals will continue to function as part of a continuous approval voting process that now references the amount of MKR in a users account at the time of snapshotting. The system will continue to use spell expiry limits and system pauses as implemented today, which will be covered further below. + +### MIP26c6 Delegation + +Delegation is the process of enabling another individual to vote on the owner’s behalf, whereby they are given voting rights in MKR weight, while the owner retains custody of the MKR tokens and is free to transfer them at any time. At a high level the user will lock their MKR in DssGov and either vote themselves or delegate to another address as shown below: + +![](https://i.imgur.com/5NbV842.png) + +This mechanism ensures that tokens do not rely on the security of third party delegation addresses, including Layer 2 solutions that may want to participate as a delegate. Locking and delegating directly from the Chief contract is a safe way to participate in delegation as tokens can only ever be returned to the MKR owner’s address. + +This solution does not allow delegates to forward delegated votes to other addresses. This design decision was made due to the complexities of recording voter balances and changes across a hierarchy of potential delegates. + +It is worth mentioning that snapshot rules also apply for delegates. Therefore, if a user delegates their MKR to another address, a snapshot will be created that a proceeding proposal will reference as part of it’s MKR calculation. This will ensure that the delegate is able to vote with the correct amount of MKR weight given to them. + +Although the snapshot capability will not let an MKR owner vote for a proposal if they have delegated their MKR to another address, governance is always able to remove (drop) a prior proposal if it is deemed malicious by creating a new proposal which will not have a delay. + +**Note**: it will not be possible for delegate addresses to stake (and burn) MKR through the Emergency Shutdown Module. Delegate addresses would however be able to participate in a governance vote that chooses to shutdown the system through normal governance voting that goes through the standard system delay (like any other governance executive). + +### MIP26c7 System pauses +In the existing design, Maker requires delays to protect itself from ecosystem risks and attacks. Currently the Maker protocol relies on a 12hour delay between the time a spell is passed and when it takes effect. Similarly, the new design will rely on an executive (GovExec) with a 12hour delay to pass proposals. + +However, if proposals are deemed malicious, governance can vote on a zero delay spell to cancel a previously actioned proposal. Likewise, proposals can also be created to protect against malicious variables, auction and oracle attacks with zero delay. This is illustrated below: + +![](https://i.imgur.com/1pLiuJQ.png) + +### MIP26c8 Flashloan Protection +The advent of flashloans allows individuals to borrow large sums of cryptocurrency and action multiple transactions within a single block without having to post any collateral. This problem has become more evident as liquidity pools have formed around governance tokens including MKR. Flashloans are prevented by ensuring that a user’s snapshot will always be at least one block older than the proposal’s snapshot. + +Similarly, proposal creation avoids flashloan risks by requiring the locking of a small amount of MKR as detailed in the following section. + +### MIP26c9 Decentralizing the submission of proposals +To promote decentralization yet protect the system against spam proposals, it is necessary to approve certain known addresses, such as domain teams, governance facilitators and other governance mandated actors, yet still allow all other addresses to submit proposals provided that they hold a defined amount of MKR in their account to prevent spamming. + +With this feature it will be possible for approved addresses to post proposals as needed. For all other addresses, a Governance defined amount of MKR from the submitting address will be held as a bond to prevent the submission of spam proposals. Once the defined duration has elapsed, the MKR bond shall be returned to the user’s address. + +Currently, no punishment has been defined for the staked MKR in the event a malicious proposal is posted. The governance community should explore whether an explicit mechanism is deemed necessary. Currently it is only possible to drop (remove) a malicious proposal by voting on a proceeding executive. The locking up of MKR when creating a proposal is however useful as previously mentioned to prevent the use of flashloans and the creation of multiple spam proposals. + +### MIP26c10 One time defensive quorum to migrate from DSChief to DssGov +Transition risk surfaced as a key security motivator in the current design of the DSChief, not only when transitioning to a new proposal but also when transitioning to this new version of the governance contract and the executive proposals that it will generate. + +Therefore, to ensure a smooth transition from DSChief to the New DssGov a minimum quorum will be used as a one-off defensive mechanism that protects the protocol by only enabling DssGov if the minimum quorum is exceeded. For the transition, Governance will elect a spell in DSChief which will give authority in all core contracts to DssGov and will also remove the DSChief authority from them. It is at that point that the transfer to the new governance contract will be complete, however the new DssGov will not be able to generate proposals until enough MKR has moved to it. This should be set relatively close to the existing Chief’s Hat value in order to confirm that we have buy-in from the Maker Governance community. + + +### MIP26c11 Layer 2 Integration +DssGov is being built independently and decoupled from any particular Layer 2 solution. Even though a Layer 2 solution is not part of this MIP, it warrants being mentioned as a capability that will be supported through DssGov and associated features. This will provide an ideal opportunity for governance voters to vote and/or delegate to an off-chain address while reducing their exposure to gas cost fluctuations. + +### MIP26c12 3rd party audits and formal verification +No audit or code review has taken place yet. DssGov will however undergo 3rd party audits and formal verification prior to an executive vote for use by the Maker Protocol. + +### MIP26c13 Licensing +[AGPL3+](https://www.gnu.org/licenses/agpl-3.0.en.html) + diff --git a/MIP28/MIP28c7-Subproposals/MIP28c7-SP1.md b/MIP28/MIP28c7-Subproposals/MIP28c7-SP1.md new file mode 100644 index 000000000..222ba6650 --- /dev/null +++ b/MIP28/MIP28c7-Subproposals/MIP28c7-SP1.md @@ -0,0 +1,37 @@ +# MIP28c7-SP1: Subproposal for Operational Support Domain Facilitator Onboarding + +## Preamble +``` +MIP28c7-SP#: 1 +Author(s): @AmyJung +Contributors: +Status: Request For Comments (RFC) +Date Proposed: 2020-10-07 +Date Ratified: <yyyy-mm-dd> +--- +Domain Role: Operational Support Domain Facilitator +Proposed Applicant: @AmyJung +``` + +## Application + +### Motivation +Working behind the scenes for over a year with Rich Brown on scaling Community Development provided great insights for how MakerDAO could grow in an effective, yet decentralized manner. More recently, I’ve been working closely with LongForWisdom and other community members through working groups such as Autonomous MakerDAO and SourceCred, and Collateral Onboarding Initiatives. + +The Operational Support domain is an accumulation of a lot of the work we’ve been doing in the background. Given my experience, I would primarily focus on: +* Resourcing: Bridge and manage effective resource distribution from Maker Foundation and the Protocol. +* People: Identify, recruit, and support individuals of diverse backgrounds in domain teams. Incubate and provide funding for smaller working group/proto-teams. +* Onboarding Experience: Map end-to-end experience for onboarding domain members, including providing operational support for initial team setup. +* Bounties and Grants: Produce and manage additional incentives to promote further growth of important initiatives and provide a path to contributing to a domain. + +### Credentials +* Currently Head of Community Development at Maker Foundation as recommended by Rich Brown +* MakerDAO Community Development contributor since July 2019 for Program Operations & Strategy +* Active in Ethereum since 2017, and worked as Design Operations Lead at ConsenSys and incentivized testnet launch at cLabs (Celo) +* Previous work as a consultant to early stage startups (Program Director at a retail and CPG accelerator), and program development for universities (Columbia, Fordham). + +### Relevant Information +* https://github.com/amy-jung +* Forum: @AmyJung, @RawHaus +* https://twitter.com/itsamyjung +* https://sharedrealities.co/ diff --git a/MIP28/MIP28c8-Subproposals/placeholder.md b/MIP28/MIP28c8-Subproposals/placeholder.md new file mode 100644 index 000000000..b3a425249 --- /dev/null +++ b/MIP28/MIP28c8-Subproposals/placeholder.md @@ -0,0 +1 @@ +placeholder \ No newline at end of file diff --git a/MIP28/mip28.md b/MIP28/mip28.md new file mode 100644 index 000000000..367d26bce --- /dev/null +++ b/MIP28/mip28.md @@ -0,0 +1,201 @@ +# MIP28: Operational Support Domain Definition + +## Preamble +``` +MIP#: 28 +Title: Operational Support (OS) Domain Definition +Author(s): @AmyJung +Contributors: n/a +Type: General +Status: Request For Comments (RFC) +Date Proposed: 2020-10-07 +Date Ratified: n/a +Dependencies: n/a +Replaces: n/a +``` + +## References +**[MIP28c7-SP1.md](MIP28c7-SP1.md)** + + +## Sentence Summary +MIP28 defines the Operational Support domain according to the domain definition template provided in MIP23. + + +## Paragraph Summary +The Operational Support (OS) domain's key function is to ensure the development and management of distributed operations at MakerDAO. Additionally, the Operational Support domain is responsible for helping domain teams coordinate to complete objectives and manage shared resources. The domain’s main responsibilities fall into three categories: + +* General operations for domains +* Cross-domain team coordination +* Grants management and distribution + + +## Component Summary +**MIP28c1: Operational Support Domain Overview** +Provides an overview of the Operational Support domain. + +**MIP28c2: Operational Support Facilitator Role and Responsibilities** +A list of the responsibilities taken on by Operational Support Facilitators. + +**MIP28c3: Operational Support Facilitator Candidate Criteria** + A list of the qualities and qualifications suggested for Operational Support Facilitators. + +**MIP28c4: Operational Support Facilitator Removal Criteria** +A list of the criteria under which an Operational Support Facilitator should be considered for removal. + +**MIP28c5: Operational Support Facilitator List** +A list of the current Operational Support Facilitators and their details. + +**MIP28c6: Operational Support Contributor List** +A list of the current Operational Support Contributors and their details. + +**MIP28c7: Operational Support Facilitator Onboarding Component** +A process component that allows for the onboarding of an Operational Support Facilitator. + +**MIP28c8: Operational Support Facilitator Offboarding Component** +A process component that allows for the offboarding of an Operational Support Facilitator. + + +## Motivation +As initial domain teams mature and more domain teams emerge, MakerDAO will need a group to support coordination of various teams and ensure resources are allocated effectively across teams. This domain team is focused on supporting other domain teams and serving the best interests of MakerDAO through an operational lens. + +Staying true to the nature of decentralized organizations, the Operational Support domain would seek to have domain teams remain independent, yet collaborative for the continued development of the Maker Protocol and MakerDAO members. + + +## Specification / Proposal Details + +### MIP28c1: Operational Support Domain Overview +The Operational Support (OS) domain's key function is to ensure the development and management of distributed operations at MakerDAO. Additionally, the Operational Support domain is responsible for helping domain teams coordinate to complete objectives and manage shared resources. The domain’s main responsibilities fall into three categories: + +* General operations for domains +* Cross-domain team coordination +* Grants management and distribution + +Naturally, the focus of the domain functions will change with the maturity of MakerDAO. Functions are divided into “Short Term”, which defines temporary responsibilities during early stages of the DAO structure, and “Long Term”, which defines responsibilities that will remain permanently and be refined as the DAO matures. + +**Short Term Functions:** + +* Bootstrap initial operations of domains that are not yet developed or difficult to scale quickly, such as Finance, HR, Legal, Partnerships, TechOps, etc. +* Bridge and manage resources from Maker Foundation. +* Propose growth focused minimum operational framework and guidance documents. +* Support domain teams transition into DAO structure; support domain teams in initial setups. + +**Long Term Functions:** + +* Identify potential bottlenecks and opportunities for more effective coordination and resource distribution to domain teams. +* Incubate and provide grants funding for smaller working groups and proto-teams. +* Coordinate domain budget proposals and payments. +* Help new domain teams onboard. +* Manage account permissions to any shared MakerDAO resources (ie. Github, Forum, etc). + +--- + +### MIP28c2: Operational Support Facilitator Role and Responsibilities +The Operational Support domain will focus on three sectors, ideally with a Operational Support Facilitator in each specialization. + +* General Operations +* Cross-Domain Coordination +* Grants + +A Operational Support Facilitator has the following responsibilities in addition to those detailed in MIP28c1: + +**General Operations:** +* Ensure resources are distributed outlined by Governance. +* Produce reports for the community on resource funding and spending. +* Research tooling in the ecosystem, and coordinate with partners for potential pilots. +* Set up key metrics and feedback loops to be able to adapt processes as necessary. + +**Cross-Domain Coordination:** +* Plan and develop new domain onboarding processes. +* Work closely with Governance to organize and facilitate open communication and collaboration processes that ensure coherence across teams. +* Identify and support key initiatives, facilitate prioritization, and organize the execution of important roadmap initiatives, such as collateral onboarding. +* Support standardization of documentation used to scope, resource, track and archive project developments. +* Strive to improve transparent process and communication. + +**Grants:** +* Produce grant initiatives to incentivize the fulfillment of DAO objectives. +* Improve recruitment to ensure a healthy pipeline of potential grantees. +* Manage grantee payments. + +Generally, Operational Support Facilitators must keep the lists in component MIP28c5 and MIP28c6 up to date. + +--- + +### MIP28c3: Operational Support Facilitator Candidate Criteria +The following criteria should be used when evaluating an individual for the role of a Operational Support Facilitator: +* Experience in one or more of General Operations (Finance, HR, Legal, TechOps, etc.). +* Experience in project management and managing cross-functional operations. +* Excellent team facilitation skills. +* Able to work collaboratively and communicate effectively in diverse environments with teammates, organizational stakeholders, and community members. +* Should have familiarity with MakerDAO and general understanding of Maker Protocol. +* Should show interest in participation in the MakerDAO community. +* Should have a general understanding of each domain and how they connect. +* Should be comfortable moving projects from ideation to implementation. +* Experience working with distributed teams. (Nice to have) + +--- + +### MIP28c4: Operational Support Facilitator Removal Criteria +A Operational Support Facilitator should be considered for removal if they are: +* Displaying biased or malicious behaviour which are not serving in the best interest of domain teams and MakerDAO. +* Majority domain teams (51%) feel they are not being supported by the current Operational Support Facilitator. +* Misusing resources or favoring one domain over another. +* Absent from their duties for a prolonged period. +* Expressing unwillingness to continue in their role. + +--- + +### MIP28c5: Operational Support Domain Facilitator List +This list can be amended by the Operational Support Domain Facilitators at any time to reflect the current state of the Operational Support Domain. It is the responsibility of the Operational Support Domain Facilitators to keep this list accurate and up to date. + +Entries into this list should follow the following template: + +``` +Name: +Sub-proposal Number: MIP28c7-SP# +Date Added: YYYY-MM-DD +Authorized Address: +``` + +There are currently no Operational Support Facilitators. + +--- + +### MIP28c6: Operational Support Contributor List + +This list can be amended by the Operational Support Facilitators at any time to reflect the current state of the Support domain. It is the responsibility of the Operational Support Facilitators to keep this list accurate and up to date. + +Entries into this list should follow the following template: + +``` +Name: +Sub-proposal Number: MIP28c7-SP# +Date Added: YYYY-MM-DD +About me: (paragraph describing qualifications / experience / etc) +``` + +There are currently no Operational Support Contributors. + +--- + +### MIP28c7: Operational Support Facilitator Onboarding Component + +MIP28c7 is a Process MIP component that allows the onboarding of Operational Support Facilitators using a subproposal. MIP28c7 subproposals have the following parameters: +- **Feedback Period**: 1 month +- **Frozen Period**: 1 month + +MIP28c7 subproposals must use the template located at **[MIP28c7-Subproposal-Template.md](https://github.com/makerdao/mips/blob/formal-submission/MIP23/MIP23c4-Domain-Onboarding-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. + +--- + +### MIP28c8: Operational Support Facilitator Offboarding Component + +MIP28c8 is a Process MIP component that allows the offboarding of Operational Support Facilitators using a subproposal. MIP28c7 subproposals have the following parameters: +- **Feedback Period**: 0 months +- **Frozen Period**: 0 month + +MIP28c8 subproposals must use the template located at **[MIP28c8-Subproposal-Template.md](https://github.com/makerdao/mips/blob/formal-submission/MIP23/MIP23c4-Domain-Offboarding-Template.md)**. This template is considered ratified once this MIP moves to Accepted status. + +Domain Facilitators may voluntarily offboard themselves by filling out the MIP28c8 subproposal template and posting it publicly in the official forum and making a brief public statement on the weekly governance and risk meeting. + +--- diff --git a/MIP4/MIP4c2-Subproposals/MIP4c2-SP5.md b/MIP4/MIP4c2-Subproposals/MIP4c2-SP5.md index fd20a3c19..c52ce6cac 100644 --- a/MIP4/MIP4c2-Subproposals/MIP4c2-SP5.md +++ b/MIP4/MIP4c2-Subproposals/MIP4c2-SP5.md @@ -7,7 +7,6 @@ MIP4c2-SP#: 5 MIP to be Amended: MIP12 Author(s): Charles St.Louis (@CPSTL), Rune Christensen (@Rune23) Contributors: -Status: Obsolete Date of Amendment Submission: 2020-07-08 Date of ratification: <yyyy-mm-dd> ```