The (updated) oracle conundrum for v2.

14 Sep 2023, 17:41

The (updated) oracle conundrum for v2 🔮✨ In our quest to shape the blueprint for oracles and v2, last month we made public some of our extensive research into the oracle landscape. 🔮 The feedback we received from our vibrant community and the different oracle providers was not only enlightening, but very helpful in refining our understanding of oracles. This iterative learning process has been invaluable, and we hope to have the same collaborative spirit for all future topics related to v2! Thus, we have taken the initiative to re-articulate our learnings, ensuring that the insights we have learnt can help contribute to the understanding of oracles within DeFi in general. Before we dive in, a couple of reminders: this is internal research that we’re making public, rather than a definitive oracle rating system - and our vision for v2 is to build a protocol that is as immutable as can be. Here's a recap of our collective insights on the infographic, and an updated look at things: /LiquityProtocol/status/1702377038185734582/photo/1 Admin control / Controlling entity No changes here - @WeAreTellor and @Uniswap are the only two we looked at that truly have no ‘admin’ control. Admin control in this instance refers to a controlling entity that has the ability to modify or upgrade that particular oracle. 👇 Compatibility with immutable dApps After speaking with different oracle teams on the matter, we came to a conclusion that fully immutable oracles are the only ones which can be determined as 'green', while oracles that follow a proxy architecture are not the same. Why, you ask? ⬇️ Proxy oracle contracts introduce potential risks due to their upgrade capacity. Most proxy oracle architectures have the ability to completely replace the oracle logic, and could (for example) block specific protocols from accessing vital price feeds based on the identity of the requesting protocol or the type of data request. The mere presence of such control is a concern - hence the change of the color code of any oracles with a proxy architecture to yellow. 👇 Attack costs and “cost to controlling entity” One great example of a learning from the iterative process taken with the different oracle providers was to split the crypto economic guarantees into two components: a) attack costs, and b) what the controlling entity has at stake. “Attack costs” refers to the economic cost of compromising the oracle’s security, e.g. a malicious actor gaining control over the price feed. The “cost to controlling entity” column refers to what a governing entity “has to lose” by manipulating, censoring or suddenly deleting the oracle. For the IC exchange rate canister specifically, we learned that it is now in fact heavily integrated into the core IC ecosystem, and that 'messing' with the oracle would pretty much undermine the ICP network as a whole. On top of that, it is also the only oracle we looked at that has a legitimate decentralized governance mechanism (voting-based). Despite this, our research still points to the notion that there isn’t any one oracle which combines complete trustlessness with reasonably low latency. 👇 Latency The only change here is that we learned that the IC exchange rate canister has a worst-case latency of ~1 minute due to historical data granularity - although there is potential for sub-second latency if their outcall functionality were extended to allow for medianization of the latest spot price. We would also like to clarify our stance on the track record tab of the infographic - our track record criteria specifically refers to the track record of the oracle provider on Mainnet In closing, this exploration was enriched by the proactive participation and feedback of our community and the various oracle teams. Collectively, these learnings help set the stage for our v2 journey, ensuring that it's founded on a collaborative spirit. Join our Discord for further discussions on all things oracles and v2: