[RWA-003/CF-DROP] Collateral Onboarding Oracle Assessment (MIP10c3-SP29)

Preamble

MIP10c3-SP#: 29
Author(s): Niklas Kunkel (@NiklasKunkel)
Contributors:
Type: Process Component
Oracle Team Name: Green
Status: RFC
Date Proposed: 2020-05-27
Date Ratified: <yyyy-mm-dd>

Specification

Introduction

This Oracle would provide the price of RWA-003/USD as part of the collateral onboarding process for CF-DROP. While the Centrifuge token is used in MIP22, a placeholder token RWA-003 is created for MIP21 that interact directly with the Maker Protocol. It is the later that requires an Oracle.

Oracle Data Model

|    Source    |  Asset Pair   |Quorum | Feed Model  | Oracle Model |
| :----------- | :------------ | :---: | :---------: | :----------: |
|  Centrifuge  |  RWA-003/USD  |  N/A  |     N/A     |   DSValue    |

Oracle Supporting Data Model(s)

N/A

Oracle Address

  • DSValue - Mainnet - TBD
  • DSValue - Kovan - TBD

Supported Tools

  • DSValue - unmodified

Remaining Work

N/A

Summary

The ConsolFreight DROP token follows the Centrifuge Real World Asset (RWA) model to be added as a class of tokens to the Maker Protocol.

The Oracle Domain Team has to balance the community’s prioritization to introduce RWA into the Maker Protocol with the Oracle security implications posed by such assets. As such, the Oracle Domain Team is proposing an iterative Oracle development approach for Centrifuge real world assets. This enables the Maker Protocol to onboard RWA sooner, identify problems with the Oracle model, and iteratively optimize the Oracle while sandboxing risk.

Phase One
Phase one of the DROP Oracle uses a simple DSValue smart-contract controlled by Maker Governance. The DSValue contains a static price value that is modified at discrete points in time by Maker Governance via an Executive Vote. Two years of stability fees on top of the Debt Ceiling are already incorporated into the DSValue price.

This seemingly convoluted process of intermediation through the Domain Teams rather than through Centrifuge / ConsolFreight updating the Oracle directly is due to the moral hazard present between the asset issuer / borrower and the Maker Protocol. It is of the utmost importance with respect to the security of the Maker Protocol that RWA issuers cannot update their own Oracle.

Phase Two
Phase two of the Oracle utilizes an independent auditor to review the status/value of the underlying assets with respect to the price supplied by the asset issuer. Validated prices are signed by the auditor, and subsequently pushed by relayers to a Medianizer-OSM hybrid, which validates the auditor signature and queues the new price with a 24 hour delay. This removes the burden of validating prices from the Risk Domain Team and can potentially provide more frequent price updates supporting capital efficiency. The 24 hour delay produces an additional safeguard buffer during which Maker Governance can react to freeze the Oracle in the event of an invalid price.

The Oracle Domain Team welcomes all feedback with regard to the Oracle model for DROP tokens and looks forward to working with the community to develop it further.

5 Likes