Oracle Team Collateral Onboarding Evaluation
Author: Niklas Kunkel (Oracle Team)
Explanation of the Oracle Team Collateral Onboarding Methodology
How much Dai can be expected to be generated against UNI-V1-DAI?
Token Contract Address: 0x2a1530C4C41db0B0b2bB646CB5Eb1A67b7158667
Circulating Token Supply: 22,791.80 UNI-V1-DAI
Token Market Cap of Circulating Token Supply (
TMC ): $10,067,385.90
- Current ETH Balance of Pool = 25,340.52 ETH
- Current DAI Balance of Pool = 5,020,821.36 DAI
Total Number of Holders: 841
Token Distribution: Top 20 holders hold 86.02% of Circulating Token Supply
Avg Collateralization Ratio of Maker Protocol (
avgCR ): 361.38%
- Assume a reasonable minimum collateralization ratio (
minCR ) based off empirical values in collateral portfolio. Since this token has exposure to ETH which has a collateralization ratio of 150%, let’s assume
minCR = 150%.
- Market Cap Utilization (
MCU ), the amount of the TMC that can reasonably expect to be deposited in the Maker Protocol, is bounded by empirical values in collateral portfolio (e.g. [0.55%, 2.74%] )
Currently the lowest and highest
MCU in the Maker Protocol are
Estimated Lower Economic Impact = TMC * MIN(MCU) / avgCR
Estimated Lower Economic Impact = $10,067,385.90 * .0073 / 3.6138 = 20,336.47 DAI
Estimated Upper Economic Impact = TMC * MAX(MCU) / minCR
Estimated Upper Economic Impact = $10,067,385.90 * .0373 / 1.5 = 250,342.33 DAI
Due to the limited amount of Dai that is estimated to be minted for UNI-V1-DAI the Oracle team is labeling this as Low Economic Impact
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?
The Oracle stack doesn’t currently support Feeds querying data from the blockchain.
Are there enough high quality data sources available to construct a reliable, resilient, and secure Oracle for the proposed collateral asset?
No. Using the Uniswap API would be completely centralized and allow complete manipulation of the Oracle. The better alternative of using on-chain data is not currently supported.
Can the current tooling support the types of data sources that are needed?
No, see above.
Can the current tooling support the types of data modeling that are needed?
There is an active discussion in the Oracle section discussing the potential Data Model for UNI-V1-DAI. This model is not currently implemented in the Oracle tooling.
Does adding these features interfere with ongoing or planned development of new tooling on the Oracle Team roadmap?
This feature is already on the roadmap.
What dependencies (both technical and system), risks, costs, and latency are added to the Oracle Protocol as a function of these added features?
Getting blockchain data would require Feeds to run their own Ethereum node or subscribe to external services. Running a node adds complexity to the Oracle stack and introduces a new point of failure. It also would significantly increase the costs of running a Feed. Increasing costs while keeping compensation the same would negatively impact the security incentives for Feeds. Subsriving to an Ethereum node service like Infura would work but now has a centralized trust-dependency on Infura who could censor data intentionally (or unintenionally if the service goes down which it has in the past). All of these problems are solvable, but require extensive R&D.
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?
About 2 months to develop and test.
Given the R&D work involved to add support for blockchain data in a secure and reliable manner the Oracle Team considers this a high technical complexity project.
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, decline, or defer a collateral onboarding application.
||Low Technical Complexity
||High Technical Complexity
|Low Economic Impact
|High Economic Impact
Low Economic Impact x High Technical Complexity => decline
UNI-V1-DAI looks like a very interesting token in that it enables market-makers of Uniswap V1 to generate extra yield. That being said, given the current supply of UNI-V1-DAI tokens, the amount of Dai that could be expected to be generated is exceedingly low.
Due to the current limitations of the Oracle tooling, creating an Oracle that meets our quality standards for reliability and security is fairly difficult. These limitations are not unique to UNI-V1-DAI but extend to all classes of tokens that require verifiable on-chain data. Advanced tooling which can support this functionality is on the roadmap for the Oracles.
The combination of low economic impact and high technical complexity to implement an Oracle inclines the Oracle Team to decline this collateral type at the present time. Once the supply of
UNI-V1-DAI has grown and the Oracle stack has been updated to include the necessary functionality, the Oracle Team will consider revising the reccommendation.