Now that the MIPs Framework has been ratified, a flood of collateral onboarding applications has started poping up. It’s great to see so much enthusiasm from partners to be added as collateral. The Maker Protocol needs a diverse portfolio of collateral to grow and reinforce the peg. As the Oracle Team, it’s my responsibility to help guide the community through the collateral onboarding process with respect to Oracles by giving recommendations. 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.
- Assist the community in onboarding new collateral types
- 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
- Come up with a proper incentive mechanism for relayers
- 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 gossip price data.
- 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
- 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).
- 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.
- Find and assist Ethereum projects to get whitelisted Oracle access
- Implement an Oracle Feed Dashboard that shows all Oracle and Feed data in an easy to understand format.
- Create a robust MIP framework around Oracle governance (formerly the Oracle Governance Framework defined in the Oracle Team Mandate).
- Find, hire, and onboard talented developers to my team to increase the quality and throughput of the Oracle Team’s work.
Yea, that’s a lot. The context for most of these is missing which I hope to remedy at a later date.
There needs to be a balance between time devoted to the collateral onboarding process and time devoted to ensuring the long term development of the Oracle protocol.
What collateral types are easy to create Oracles for? Which ones are difficult? Are there enough data sources to create a secure Oracle that is resistant to manipulation? 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, I’ve composed an initial methodology the Oracle Team is utilizing to prioritize collateral onboarding work versus other endeavors in the Oracle domain.
Collateral Onboarding Proposal Methodology
Author: Niklas Kunkel
The collateral onboarding recommendations published by the Oracle Team in accordance with MIP6 are independent and non-binding. In other words, a recommendation by the Oracle Team does not impede the collateral onboarding process. Ultimately it is the community’s decision whether to include a collateral in the Maker Protocol. Like other Domain Teams, The Oracle Team has no authority to unilaterally include or exclude a collateral, it merely provides guidance in relation to Oracles. This methodology is intended to evolve over time to adapt to the ever changing circumstances affecting Maker governance.
The recommendations are evaluated in relation to the technical feasibility and technical complexity to create a secure Oracle for the proposed collateral type and don’t take any other factors into account.
Technical Complexity Evaluation
Determine how complex integrating Oracles for this collateral type would be and how long it would take to implement such a solution.
Are there sufficient 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 type of data modeling that is needed?
What would it take to expand the functionality of the current tooling to support the necessary data sources and data modeling?
Is a solution currently not possible because of a key missing component?
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 interfere with ongoing or planned development of new tooling on the Oracle Team roadmap?
Does adding these features require work and/or coordination from other stakeholders such as the Smart Contracts Team(s)?
How long would it take to design, implement, test, and deploy such a solution?
This is where the Oracle Team delivers its recommendation to the community whether to accept or defer the collateral onboarding along with a short summary of the reasons for doing so. Note that the Collateral Onboarding Greenlight Vote takes place regardless of the Oracle Team’s recommendation. It is merely one data point among many that Maker Governance needs to factor into their decision.
- Fixed formulas
- Added ranges to define low economic impact and high economic impact
- Changed variable names in formulas
- Added disclaimer
- Removed economic impact as a factor for the recommendation
- Removed Evaluation matrix
- Formatted Technical Complexity Evaluation