This post is in response to @LongForWisdom, giving an analysis of how the use of Chainlink’s oracle can help accelerate the creation of more DAI and reduce various important risks for MKR holders at the same time. Initially focusing on using Chainlink’s oracles on the LINK/USD that’s already live and successfully securing tens of millions in value; https://feeds.chain.link/link-usd.
Being a user of DAI myself, I want to see it succeed and for Maker to maintain its position as the leading stable coin project in the space, yet even as recently as today, we’re seeing various DeFi protocols seek to overtake Maker as the leader in DeFi, which is something that Maker can protect itself against, by:
Adding collateral more quickly in times of stability (long-term growth) and times of crisis with the peg (fast responsiveness is key)
Focusing its resources on the core problems of accelerating DAI creation, which is not the creation of an oracle mechanism and
Avoiding oracle failures tied to the DAI and Maker brand that can significantly harm faith in DAI and depress MKR prices to lower levels, as they recently have.
Also, Chainlink’s passionate community members use the DeFi products that rely on a Chainlink oracle, which is particularly relevant in this conversation about adding LINK as an MCD collateral. Systems which don’t use Chainlink’s oracles aren’t considered to be sufficiently secure for them to utilize the DeFi product itself.
I also firmly believe that Maker having a leadership position in the DeFi market contributes to the faith that users place in DAI as an alternative to other stable currencies, which is why I feel strongly that Chainlink and Maker can be a great team. For example, Chainlink is already running many of the oracles that Maker needs today and the ones it will need soon; https://feeds.chain.link/.
The ultimate goal of Maker is to become a stablecoin protocol that is as decentralized and censorship-resistant as possible to reduce any single point of failure. This is especially important to ensure that Maker is uncapturable and cannot be taken down or tampered with by any single entity. As I have understood the goals of the Maker community, this also includes being able to survive separately from the Maker Foundation, which has been openly advocated through statements like “The Maker Foundation will, over time, be dissolved, and the community will govern all aspects of the Maker Protocol.” (The Maker Foundation’s Vision of a Self-sustaining MakerDAO: Initiation of Maker Improvement Proposals (MIPs) Framework) However, It’s important to not only decentralize the governance of Maker, but also its oracle mechanism and the price feeds that relate to how Maker is able to properly function once its governance is decentralized.
Chainlink’s decentralized oracle framework can help Maker achieve its stated goal of full decentralization by reducing reliance on the Maker Foundation and the in-house built and managed oracle protocol. This is important because even if the Maker Foundation were to run into issues or be legally strong armed, Maker’s oracle system would be able to continue operating as designed with no issues or censorship.
Chainlink offers a self-sovereign oracle protocol built by a large independent team whose sole focus is building secure and reliable oracle networks (with many being price feeds). The Chainlink Network is operated on mainnet by a decentralized network of publicly known and independent node operators who are separate from both the Chainlink and Maker teams. By integrating a transparently decentralized oracle solution into the Maker protocol, the security of Maker’s core stablecoin product becomes more robust, thus providing a stronger foundation from which it can scale to secure more value in the future.
While there are oracle networks with many node operators like https://feeds.chain.link/eth-usd, the LINK/USD price reference data feed (https://feeds.chain.link/link-usd) which we’re considering here, currently has nine security reviewed node operators and seven independent data providers (listed in Johann’s original post above) to ensure that when LINK is used as collateral within the MCD system, it will always have a reliable, secure, and tamper-resistant oracle mechanism that is completely independent from the Maker Foundation. I also know that as the value secured by a Chainlink oracle network grows, it begins to increase in size to the levels of https://feeds.chain.link/eth-usd, https://feeds.chain.link/btc-usd and beyond.
Increase speed of adding additional collateral to MCD and remove oracle related bottlenecks
Chainlink has a large integration team that is able to assist and complete oracle integrations with other protocols in a highly efficient manner. They are focused solely on building oracles and have extensive experience helping numerous DeFi protocols quickly and securely solve their oracle needs. Chainlink has been integrated into several top ranking and high quality DeFi applications on mainnet like Synthetix, Aave, Loopring, bZx, Nexus Mutual, and more. By relying on Chainlink, they are able to focus their developer bandwidth on improving their core offering instead of building infrastructure. Post Chainlink integration, these DeFi projects went on to rise substantially in total value secured, boosting the growth of their external integrations with other protocols.
For example, Aave launched on mainnet in January of this year with support for 16 different cryptocurrencies secured by 16 different Chainlink price feeds (https://twitter.com/AaveAave/status/1215296815823802369). The Aave team was able to support so many cryptocurrencies at launch because they had no oracle development bottlenecks to deal with. The Chainlink team was responsible for launching these decentralized price feeds, while Aave focused on building and perfecting their core offering.
Since then, Aave’s decentralized money market has rapidly scaled up to now secure over $100M in user deposits (https://aavewatch.now.sh/) and has grown to become the fourth largest DeFi protocol (https://defipulse.com/). Emilio Frangella, Software Engineer at Aave stated “Chainlink helped us reduce our time to market, while at the same time providing the highest guarantee of data integrity, decentralization and security.” They were able to drastically expedite their launch schedule, allowing them to spend more time and resources to innovate, iterate, and build new products. Chainlink accelerated the rollout of several of new products by quickly deploying price feeds for new assets integrated into their money market. For example, Chainlink was able to quickly launch new price feeds for new cryptos like BUSD and even unique collateral types such as Uniswap LP tokens. (https://twitter.com/lemiscate/status/1266122217387065350)
Similarly, the Synthetix team was able to quickly launch many new unique products such as the FTSE 100 and Nikkei 225 synthetic assets (https://blog.synthetix.io/more-information-on-the-new-equity-indices/). This was due to the fact that they also worked with Chainlink on their oracle development/infrastructure, who quickly spun up new customized oracle networks that meet their exact design requirements. The Synthetix community was then able to focus on which assets should be added, rather than focusing on how the oracle network should be structured. Additionally, Chainlink helped Synthetix design and implement a reference price algorithm for oracles to price assets that are mostly liquid as monthly Futures contracts like commodities such as oil (https://sips.synthetix.io/sips/sip-62).
From this experience and more, Chainlink has built out a solid framework for onboarding new integrations and supporting them with new oracle networks for any price feeds that projects require to continue to expand in growth and featureset. What this ultimately means for Maker is that Chainlink can help quickly and securely onboard new collateral types for MCD. This would greatly reduce Maker’s current integration bottleneck of needing to spend time and resources on provisioning and supporting a new price feed for each new collateral addition. Instead of spending weeks finding data sources and setting up a new oracle network, Chainlink can reduce this down to days and take on the oracle integration work.
I want to emphasize that I am personally a huge fan of Maker and the system that has been built over the years. DAI basically kickstarted DeFi as we know it today and I have been routing for you guys since the beginning. DAI by and large has been an astounding success as the de facto decentralized stablecoin of DeFi, proving its worth surviving the 90% downturn of ETH in 2018. I watched that happen in real time and it really made it clear to me that DAI works and it works damn well. DAI is integrated into basically every DeFi application and recognized as the most liquid and trusted decentralized stablecoin by far. Basically the point I am getting at there is that I am a huge fan of DAI and want to see it scale into the billions of dollars. I even collect different wrapped versions of DAI across DeFi (seriously, check chainlinkgod.eth).
However with all that being said, I cannot ignore that there has been a major acceleration in the amount of new and innovative stablecoin designs and other DeFi protocols competing with Maker for the leadership position in our space. All of these new stablecoins are vying for user deposits and I’m afraid that if Maker doesn’t move fast enough, then these other projects will overtake DAI as the default decentralized stablecoin within DeFi and beyond. Running a stablecoin startup is already a demanding task in and of itself, but running an oracle startup alongside that will dilute development efforts even further. Additionally, is it really ideal if the success of one startup is tied to the success of another startup? A stablecoin startup and an oracle startup have two very different goals in mind, and unfortunately in this situation, the risk of each project is inherently tied to the other. If for whatever reason the stablecoin startup fails, then the oracle startup will become completely unfunded and lose user trust in the sustainability of that oracle solution. If the oracle startup fails for whatever reason, then so too would the stablecoin startup fail as not only would that stablecoin be receiving faulty data, but people’s trust in DAI would be completely shattered.
I can’t answer this question for Maker, but what I do know is that Maker is incredibly thoughtful about considering key financial risks, with this being a major technical risk that could cause DAI to lose its leading position because precious time and effort was used up in a secondary startup that had an entirely separate goal from building a stablecoin and which wasn’t able to allow Maker to move fast enough. This diluted focus means DAI becomes less competitive, less able to quickly add new collateral, and reduces the future growth of DAI. The main point here is that you have an option to start down a parallel path with a widely adopted decentralized oracle. There is also a market demand for your use of the Chainlink oracle at the moment, while also giving you a good opportunity to decentralize a part of this risk away partially, so that all of Maker’s collateral doesn’t rely on any one oracle system.
Remove the Risk that Oracle Failures Could Reduce Faith in DAI
In addition to the slower speed of DAI growth and competitiveness that arises from running two startups simultaneously, you need to ensure your position as the leader in DeFi by keeping user confidence. I love Maker and I want it to succeed by ensuring that it keeps its position as a leader in DeFi. However, if the secondary startup that is focused on oracles fails again like it did on Black Thursday, then that will once again greatly lower public opinion of DAI in the minds of users. The image of DAI was hurt badly from the issues that arose that day, exacerbated by oracle issues. In my opinion, running an oracle startup in parallel to Maker’s primary goals of making DAI succeed, reduces the speed at which DAI can succeed. The Maker community should focus its efforts on making the best stablecoin possible, assessing the risks of adding new collateral, or otherwise you risk falling behind and losing the leader position.
There are many other startups that are trying to take the position of top stablecoin and they are creating new and innovative ways of attracting capital from users. These startups in DeFi are rapidly growing both marketshare and mindshare alike due to their ability to quickly pivot and innovate, using various incentives. The issue of speed risk is combined with the high risk oracle issues (listed in sections below), both of which directly affect the value of MKR and DAI. If a major oracle failure happens, people will lose confidence and this will hurt both the Maker community (MKR holders) and the users of Maker (DAI holders). This is a major reason why DeFi projects are now more than ever choosing to not roll their own oracle. The oracle problem is a very complicated issue with a lot of nuances that are not fully understood by many.
A secure and well-rounded oracle solution requires a large top quality full time team, security experts and academics who can assist in ensuring such a solution is as fundamentally bulletproof as possible. This is no small task and this is a major endeavor and risk Maker is taking on that could greatly adversely affect the value of both MKR and DAI. By working with a team like Chainlink, Maker is able to greatly reduce such oracle risk and ensure user confidence will always be at an all time high as the Maker community and foundation can focus entirely on ensuring DAI stays king stablecoin.
Ensure that at least the LINK/USD Collateral will Remain Functional
This can be taken one step at a time, where Chainlink can prove itself under a controlled environment and can expand outward to more collateral types if desired. Additionally, using Chainlink price feeds for LINK is no more risky as a collateral type than if LINK was added under Maker’s oracle. If Chainlink LINK/USD price feeds fail, then LINK would collapse in value anyways. This is because the performance of Chainlink oracles and the value of the LINK token are intrinsically tied together and this correlation will only strengthen in the future. The real benefit here is that using Chainlink oracles for the LINK collateral type diversifies Maker’s oracle risk greatly. Meaning if Maker’s oracles were to fail (due to reasons listed further below) and collateral was improperly liquidated, then the LINK collateral type would continue to operate as normal under a Chainlink oracle network, meaning DAI would still have some amount of value backing it, not all would be lost.
Improve DAI Adoption by Scaling its Supply
DAI needs to be able to scale its supply side in order to succeed as an in-demand stable currency. The primary way of achieving this is through adding new collateral types, which allows more DAI to be minted from a broader range of users. Not only can LINK boost the minting of new DAI, but Chainlink can offload complex governance work around building oracle infrastructure needed to support new collateral types. Such oracle work will only get more complex and time consuming as Maker’s collateral portfolio becomes deeper and their collateral types become more diverse. This includes expanding beyond cryptocurrencies like ETH and BAT into various other real world asset classes like commodities, real estate, loans, invoices, etc. Chainlink can do the heavy lifting involved with finding trusted accurate data feeds, providing adapters to the oracle nodes, launching the oracle network, funding the oracle network, and maintaining the oracle network including its improvements over time. This frees up a lot of time and resources for the Maker Governance system to focus on perfecting the Maker ecosystem, getting DAI adopted in traditional markets, and making DAI the most diversely collateralized stablecoin in the market.
Now into the formal comparison between Chainlink and Maker’s oracle system.
Achieve Market Coverage and Prevent Data Manipulation
Chainlink oracle networks for price reference data currently live on mainnet only fetch and aggregate price data from high quality professional market data aggregators with large, experienced, and full time teams such BraveNewCoin, Kaiko, Amberdata, and more. These entities aggregate market data across all centralized and decentralized exchanges, taking into account liquidity, volume, and time. Each of these services has PagerDuty alerts for market anomalies and use their own calculation algorithms for aggregation, bringing additional redundancy, reliability, and tamper-resistance to oracle networks.
Each Chainlink oracle network aggregates data from at least 7 independently vetted data aggregators, incorporating decentralization at both the node operator and data source layers. Decentralization of multiple high quality data sources provides robust market coverage and protects against data manipulation attacks. Calling these API data sources requires credential management capabilities, which Chainlink nodes are able to natively support using modular external adapters that can be created by anyone, written in any programming language, and hosted anywhere (https://docs.chain.link/docs/external-adapters). This provides a robust framework to quickly launch new price feeds with authenticated data sources.
On the other hand, Maker’s Oracles don’t pull price data from data aggregators. Instead, they pull data directly from preselected exchanges and take the median value. Each exchange is weighted equally, even when volume differs significantly between exchanges. This means that even an oracle fetching price data from six exchanges may not be secure because it doesn’t account for major volume shifts between exchanges. The cost of manipulation goes down greatly because an attacker would only need to manipulate the low volume exchanges to affect the price oracle. It’s not uncommon either for centralized exchanges to go down during times of high volatility or report outlier data points, which Maker’s system is only handling through a simple median.
This issue is compounded further if a major portion of an asset’s volume shifts to an exchange that was not included in the aggregation process. The cost of manipulation would lower even further, and the oracle’s market coverage is lost until the Maker oracle team notices the issue and manually intervenes to fix the issue. While the exchanges Maker chooses may have been liquid when the price feed was initially created, there is no guarantee that the volume stays on such exchanges or that a new exchange won’t pop up and become the new liquid market for an asset.
To bring to light the magnitude of these issues, consider the below examples and how the Maker oracle system struggles to create an accurate price point. We will demonstrate using Maker’s BTC/USD price feed, which aggregates price data from five select exchanges: Bitstramp, Bittrex, Coinbase, Gemini, and Kraken (https://github.com/makerdao/mips/blob/master/MIP10/MIP10c8-List-of-Oracle-Data-Models.md). The volume weight and BTC prices for each exchange are arbitrary values to show how Maker’s oracle would handle a worst case scenario.
In this first example, the majority of trading volume has moved to just two exchanges, while the rest of exchanges share a minority percentage of volume. As such, the three low volume exchanges have been artificially manipulated to raise the price point of the resulting median. This creates major slippage and can potentially make the entire Maker system and any other project relying on this price feed insolvent (undercollateralized). This is due to the fact that it could result in users being able to create larger than normal loans while the liquidations mechanism would be not functioning properly, furthering the undercollaterization risk of any system using Maker’s oracles.
In this second example, the majority of volume has moved and concentrated on exchanges that weren’t included in the aggregation process. The lower volume exchanges that were in the aggregation process are manipulated to artificially crash the price. This causes Maker’s price feed to deliver an artificially low price, triggering faulty liquidations of users.
It should be noted that each of these data manipulation issues can happen to any collateral type in the Maker system and the resulting price point can be manipulated up or down. In both situations, Maker’s Oracle mechanism creates a highly inaccurate price point compared to the global market price. Proper market coverage is only created by calculating the volume weighted price, not weighting each exchange equally and taking a simple median. This is something that professional data aggregators like Bloomberg and Reuters have spent decades perfecting to prevent delivering falsified price points to clients, even during extreme market manipulation.
The problem will become an increasing risk as the Maker system grows to secure more value. Especially as less liquid assets are introduced as collateral, creating higher risk of market manipulation. This will become a major impediment to wider Maker adoption, especially in the enterprise world where these data risks are highly scrutinized. While the one hour delay of Maker’s OSM could allow somebody to catch a data error before it wreaks havoc, it’s unclear if there are any automated systems like PagerDuty set up to alert of such a price anomaly, or if it’s expected for humans to be manually watching new price updates. Additionally, all of Maker’s oracles rely on the same off-chain data aggregation tool called the Setzer. If it were ever to run into any issues/bugs when calculating an aggregated data point, the bug/issue would replicate across every Maker oracle node and affect all price feeds. Maker’s price feed updates would then contain incorrect data or not update at all.
The underlying issue with this type of oracle design is that it attempts to solve two hard problems: the data transfer oracle problem (not an easy problem to solve on its own) and the data quality problem (a whole separate issue with its own attack vectors and design considerations). In this sense, Maker’s oracle is taking on the additional role of trying to act as a data procurement company. Ultimately, Chainlink does not try to spread itself too thin by trying to solve two very challenging problems. It focuses solely on providing developers with a large collection of high quality nodes and the tools to incorporate them in tamper-resistant decentralized oracle networks. Chainlink leaves the data quality problem to the experts with decades of experience and knowledge on how to generate a global market price.
Security Through Well Built Secure Systems vs. Security Through Obscurity
Chainlink’s decentralized price reference data networks are focused on providing security through transparency by using 30+ professional dev ops team operated by independent, publicly known, and security reviewed node operators (e.g. Certus One; https://certus.one/). These node operators already operate blockchain infrastructure that secures hundreds of millions of dollars and have highly technical and experienced teams. This means all active Chainlink nodes have their reputation and business model on the line, determining not only how much they earn in the Chainlink network, but all other networks they serve. Malicious node operators would lose their reputation and thus lose all future revenue for all services they provide in and outside the Chainlink ecosystem.
The Chainlink network also has 100+ nodes competing to be included in well paying oracle networks (https://market.link) that can be security reviewed and added for additional decentralization at any time. The Chainlink framework is highly generalized and flexible enough to support any oracle model desired by users. Maker can work with the Chainlink team to get something quickly and securely built that can meet their exact needs.
Chainlink provides a very detailed set of information to the public about its price reference data feeds. Chainlink’s https://feeds.chain.link main page shows the following:
- Each price reference data feed available
- The latest price of each reference data feed
- Which DeFi projects are sponsoring and supporting each price feed (with hyperlinks)
- Which security reviewed node operators are securing the price feeds (with hyperlinks)
Each price feed page shows the following:
- Aggregator contract address
- Latest aggregated price
- When updates should occur (including deviation threshold + heartbeat)
- Minimum amount of node responses needed for aggregation to begin
- Latest aggregation update time of the price feed
- A visual showing how many and which nodes are in the reference data feed
- A visual showing if nodes are fetching data or have already delivered data
- 24hr price history chart
- 24hr volatility history chart
- Latest gas price paid by each node in Gwei
- Latest answer delivered by each node
- Latest response time by each node
- Link to each node’s Etherscan for on-chain transactions
- Link to each node’s market.link for nodes listing their details/jobs/adapters/price
- Link to each node’s explorer.chain.link for exact data request history and job details
Below is an example of the ETH/USD price feed (https://feeds.chain.link/eth-usd) and the on-chain data it displays to end users.
Chainlink offers a much more transparent oracle system and allows end users and developers alike to peer directly into each oracle network. This enables them to know definitively whether the oracle system is reliable or not using historical on-chain data presented in a simple, easy to consume fashion. There are also third party sites like https://reputation.link that show raw data and refined stats about the Chainlink network in aggregate (over the past week), as well as specific data about each individual oracle node, including:
- Transaction count (lifetime, one year, one month)
- Average response time in blocks
- Average response time in seconds
- LINK payments earned
- Completion Ratio (successful/failed transactions)
Nodes can be compared directly against each other to see which oracle nodes are more reliable than others. Additionally, there’s a page showing the performance data and uptime of multiple Data Aggregator APIs used by Chainlink nodes. This allows developers to make more informed decisions when it comes to selecting both reliable nodes and data sources. All this data is pulled directly from the blockchain and publically available to anyone
Another tool available for listing and learning more information about hundreds of Chainlink nodes are third party marketplaces like https://market.link. Chainlink Market shows:
- A profile of each node operator with a description and link to their website
- Which data sources and off-chain services each node offers
- The node’s oracle contract address where queries are sent to
- The payment amount required for each specific data request
- Which reference price feeds each node is delivering data to
- How many total jobs each node offers including specific job spec details
- How many job runs nodes have completed in total
- Any credentials, security reviews, and identity verifications (e.g. keybase)
- A search engine for developers to find any data source or node
Maker’s current oracle system seems to be based on security through obscurity. 15 of the 20 Maker oracle nodes are anonymous, which leaves users in the dark about who runs much of the network. In general, security through obscurity is not a viable or scalable model for oracle networks as it creates a very opaque network that requires users to trust many unknown parties with the security of their funds. This introduces risk that nodes are potentially being run by the same entities. Maker has been leading DeFi in the creation of an open and permissionless ecosystem of financial systems, but without security through transparency, the number of users that can be brought in is limited.
The information available to the general public about Maker’s oracle network is through a UI (https://makerdao.com/en/feeds/) that only shows the current price of each feed and the OSM contract addresses. The linked contracts on Etherscan do not provide much more details about the price feeds. As I remember it, there was previous interface that showed additional data on Maker’s oracles that was replaced by this more opaque overview, which is a worrying sign of a preference for security through obscurity being the preferred approach.
Beyond this interface, I can’t find any resources to observe the quality of the data put on-chain, the individual responses by nodes, the uptime/accuracy performance of each node, the frequency of updates, which nodes’ data is used during aggregation, or any info about relayers. This lack of transparency means performance data about how Maker’s oracle network is operating is unavailable to users and developers. I would personally like to see more information made available so I and others could dig deeper into Maker’s oracle and analyze its historical performance and reliability.
(post continues in next comment)