Now that the MIPs process has been approved, we've begun to see a flood of collateral onboarding applications. It's great to see so much enthusiasm by partners to become a collateral asset. The Maker Protocol needs a diverse portfolio of collateral to grow and reinfoce the peg. As the Oracle Team, it's my responsibility to help guide the community through the collateral onboarding process with respect to Oracles. At the same time, my duties extend much further as is documented in the Oracle Team Mandate.
Just to give an idea of what I'm talking about, here's a non-exhaustive list of what my team is currently juggling in no particular order.
Collateral Onboarding
- Assist the community in onboarding new collateral types Data Integrity
- integrate signed Coinbase data in the Oracles
- implement a robust and trustless way to query on-chain storage values along with Merkel proofs to validate data
Incentives
- Come up with a proper incentive mechanism for relayers
Reliability
- Create redundancy within every module of the Oracle client so a bug in any module can't halt the Oracle protocol. Think geth vs parity in 2016 when all the geth nodes crashed simultaneously and the Ethereum network would have halted were it not for the parity nodes holding up the network on their own.
- In particular I want to ensure we're not reliant on Secure Scuttlebutt and instead have multiple Transport Layers for Feeds to to gossip price data.
Resiliency
- Create a tx manager service with more dynamic gas pricing algorithm when network is congested to stabilize Oracle latency even when the market is at its most volatile
Data Sensitivity
- Implement more advanced stateful price querying tooling that can implement much more advanced Data Models such as CCCAGG (a time-sensitive volume weighted average price).
Decentralization
- find and assist new high quality partners to onboard as Light Feeds
- create a smart contract to fund Feed payments through the Maker Protocol in a decentralized manner.
- create a decentralized oracle freeze mechanism similar to the decentralized emergency shutdown module to enable MKR holders to intervene in the case of an Oracle attack.
Product
- find and assist Ethereum projects to get whitelisted Oracle access
Transparency
- implement an update Oracle Feed dashboard that shows all Oracle and Feed data in an easy to understand format.
Governance
- create a robust MIP framework around Oracle governance (formerly the Oracle Governance Framework defined in the Oracle Team Mandate).
Velocity
- find, hire, and onboard talented developers to my team to increase the quality and throughput of our work.
Yea, that's a lot. For most of you, the context for most of these is missing which I hope to remedy at a later date. So I hope you'll understand when it seems like I'm not responding to a governance proposal quickly enough that my team is working hard on the community's behalf.
There needs to be a balance between time devoted to the collateral onboarding process and time devoted to ensuring the long term health of the Oracle protocol. What collateral types are worth purusing immediately? Which ones aren't? Is there a key piece missing that is blocking us from onboarding this collateral type until some later point in time? While I don't presume to have all the answers, we have to start somewhere, and we can iterate from there.
V1.0.0 Author: Niklas Kunkel Contributors: Date: 05/05/20
There are two main factors the Oracle Team takes into consideration when evaluating prioritization of collateral onboarding proposals.
- The Economic Impact
- The Technical Complexity
This section seeks to answer the question, how much Dai supply can be expected to be created if this collateral is included. Now one may ask, isn't this a job for the Risk Team(s)? Certainly the Risk Team(s) are uniquely qualified in this domain. Yet as can be seen by going through this process, even rough ballpark estimates that set upper and lower bounds can aid the Oracle Team remarkably well from a prioritization perspective.
Concrete Data:
Circulating Token Supply: < # >
Token Marketcap: < # in USD >
Total Number of Holders: < # >
Token Distribution: < Top X holders hold Y% of Circulating Token Supply >
Avg Collateralization Ratio of Maker Protocol: < % >
Assumptions:
- Assume a reasonable minimum collateralization ratio based off empirical values in collateral portfolio (e.g. 150%)
- Token supply capture rate will be bounded by empirical values in collateral portfolio (e.g. [0.55%, 2.74%] )
Formula:
Lower Estimated Economic Impact = totalMcap * avgCR * MIN(captureRate)
Upper Estimated Ecnomic Impact = totalMcap * minCR * MAX(captureRate)
This should give us an estimated range for amount of Dai that may be generated given inclusion of the collateral type into the Maker Protocol.
Given the distribution of token holders relative to the total number of token holders, how many users with significant sums of the proposed collateral are we reasonably targeting with this integration?
Determine how complex integrating Oracles for this collateral type would be and how long it would take to implement such a solution.
Is a solution currently not possible because of a key missing component?
Are there enough high quality data sources available to construct a reliable, resilient, and secure Oracle for the proposed collateral asset?
Can the current tooling support the types of data sources that are needed?
Can the current tooling support the types of data modeling that are needed?
If not, what would it take to expand the functionality of the current tooling to support the necessary data sources and data modeling?
Does adding these features interfere with ongoing or planned development of new tooling on the Oracle Team roadmap?
What dependencies (both technical and system), risks, costs, and latency are added to the Oracle Protocol as a function of these added features?
Does adding these features require work from other stakeholders such as the Smart Contracts Team(s)?
How long would it take to design, implement, test, and deploy such a solution?
The combination of Economic Impact mapped against the Technical Complexity of onboarding a new collateral type can paint a picture of whether an Oracle Team ought to accept, reject, or defer a collateral onboarding application.
| Low Technical Complexity | High Technical Complexity | |
|---|---|---|
| Low Economic Impact | maybe | reject |
| High Economic Impact | accept | maybe |
This is where the Oracle Team delivers its reccomendation whether to accept, reject, or defer the collateral onboarding application along with a short summary of the reasons for doing so.