[RWA-007/SolarX] Collateral Onboarding Oracle Assessment (MIP10c3-SP40)


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



This Oracle would provide the price of RWA-007/USD as part of the collateral onboarding process for SolarX. RWA-007 is structured according to the specification laid out in MIP21 that interacts directly with the Maker Protocol.

Oracle Data Model

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

Oracle Supporting Data Model(s)


Oracle Address

  • DSValue - Mainnet - TBD

Supported Tools

  • DSValue - unmodified

Remaining Work



The SolarX token utilizes the MIP21 Real World Asset model in order to integrate into the Maker Protocol.

It should be noted that the Oracle for RWA-007 is exclusively used for generating Dai. The RWA-007 Oracle is not responsible for triggering liquidations. Instead liquidations are triggered via notice from Maker Governance.

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 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 RWA 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 Core Units rather than through SolarX 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 and RWF Core Units 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 RWA collatearl types and looks forward to working with the community to develop it further.


100% agree with this–my question would be–“who” ( a CU, or RWA Committee) in Maker Governance determines the price value, and what RWA appraisal tools are used.

Will the price value have a “Mark to Market” approach (Are assets worth as much as other assets with similar utility), and what about the income approach (earnings and liabilities minus market value).

And will collateral price value evaluations be performed on a weekly/monthly/quarterly basis. Many questions–perhaps best suited for the RWF CU–but these are things I think about when thinking of how Oracle feeds will price RWA collateral value.

TY Nik and Marc-Andrea for this assessment–much appreciated.

1 Like

Thanks for your feedback, I agree those are all astute observations. As you noted, I believe they’re best suited for the RWF and Risk CUs.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.