I agree people usually go to where it is cheapest to borrow (which Maker has the upper hand currently), but for many linkies, borrowing on a platform that doesn’t use Chainlink oracles is added risk of a false liquidation occurring from a manipulated price feed (due to malicious activity or otherwise), which needs to be taken into account for risk adjusted interest rates. Although in my opinion, even if Maker’s borrowing rates are higher than Aave, something can be said for the utility and novelty of minting new decentralized stablecoins on its native platform rather than borrowing stablecoins on a third party platform.
I think a fair comparison from Aave to Maker would be to compare the outstanding loans of all stablecoins offered on Aave as people often choose the lowest interest rate and switch between stablecoins (sometimes with flash loans) as needed, so that would be $12.67M in outstanding loans with much of that being backed by LINK collateral.
Yeah it’s hard to quantify demand exactly, but I can provide qualitative context:
A) Likely to attract usage from leverage traders mainly when Maker’s borrowing interest rate is well below Aave’s, moderate support from linkies.
B) Definitely more usage and support than A, but less than in C, this is also a whole lot harder to do from an technical perspective due to Maker’s usage of an off-chain p2p gossip network for its oracles, it also doesn’t really to much sense imho to weight an entire oracle network (LINK/USD with 9 nodes) equally to each public and anon node individually in Maker’s oracle network. Maybe each chainlink node could be added separately to Maker’s existing oracle network, but that increases complexity linearly with the number of nodes and takes much more integration work from both the Chainlink and Maker teams to pull off for little added benefit (compared to C).
C) Receives most amount of demand and wide support from Linkies, this is also much easier to implement from a technical perspective as the LINK/USD network can operate as-is without changes and be connected to the OSM through a simple proxy contract.
I don’t want to get into why I think Maker’s oracles are less than ideal in certain situations (e.g. pulling market data from exchanges directly and weighting each exchange equally instead of pulling from data aggregators who smooth outliers and weigh exchanges by volume), but generally oracle security is something Linkies are passionate about, so for many, no chainlink oracles means much less support and thus much less DAI minted than could have been possible. I appreciate the discussion, I’d say there’s always trade-offs in each situation, just depends on what we’re optimizing for.
Once again, appreciate the time, effort and points made in the previous post. I found the context you provided really useful.
This may sound a little strange, but I’d actually love to see a comparison from the Chainlink community’s PoV (or a neutral party’s). Do you have any links you can share that I can look over? I’d love to see something that goes into the differences and the pros and cons of each approach.
I think it would be fine to post a link to it within this thread when it’s done. The initial proposal is essentially asking Maker Holders to rely on Chainlink’s oracle, so knowing how they differ would provide insight into that decision.
Similarly to the Chainlink community, I would say that many in the Maker community trust the current oracle implementation, and replacing it even for a single collateral package would require us to evaluate the replacement.
It is important to note that MakerDAO previously approved an Oracles Incentives Restructuring proposal to align incentives among Feeds, Data consumers, and MKR holders and this plan uses Dai instead of a token. This is both an important experiment in the DeFi ecosystem with involvement from many important players as well as a great new emerging business opportunity for MakerDAO.
We will jeopardize both opportunities if we allow anyone sidestep the current Oracles Governance Framework and Incentives Restructuring plan and submit final asset prices.
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
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
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.
Maker and its stablecoin DAI would greatly benefit from Chainlink’s model of security through transparency by giving developers and users alike access to a broad range of resources, statistics, and analytics. As an example, Ethereum would be crippled without tools such as Etherscan providing transparency and analytics into the network. This concept applies just as much to oracle networks as it does to blockchains. Such information would bring more trust to DAI and enable a greater level of adoption and usage as users would be able to get insight into the internal workings and performance of the oracle system DAI relies upon to be a stable overcollateralized currency. By leveraging Chainlink, Maker can quickly and easily implement security through transparency today and greatly benefit all current and future users of DAI.
Team Bandwidth and Network Effects
Chainlink oracle networks are supported by their full time team of 40+ people focused solely on solving the oracle problem. Nodes are operated by independent parties who are directly funded by the DeFi community (numerous projects which can include Maker) and Chainlink’s node operator fund to ensure that initial growth is bootstrapped by subsidies and long-term operations are sustainable well into the future. Given the Chainlink network subsidy and large growing open source community, Chainlink oracles networks are far cheaper for DeFi projects to integrate with than it would cost to implement, operate, secure, fund, monitor, and build tools for your own oracle network.
Please note that this picture is dated and shows only a portion of the team. They have been expanding in order to further support the integration of Chainlink into more projects. There are currently 12 open positions available including software engineers, cloud reliability engineers, integration engineers, and more. All of these team members would help Maker succeed and support Maker well into the future as both projects grow.
Through its 200+ integration pipeline (https://chainlinkecosystem.com), Chainlink oracle networks are quickly achieving an economy of scale with multiple projects supporting common price feeds, lowering the costs for each individual user. This is something Maker’s oracle system is currently spending funds on trying to achieve. Instead of focusing on a secondary product, Maker can reallocate these funds, while at the same time gain support from the large Chainlink community. The Chainlink community has already demonstrated its ability to raise the profile of DeFi applications, such as Aave’s largest pool being LINK. The Chainlink community wants to use applications that use Chainlink oracles, meaning adopting Chainlink’s LINK/USD price oracle would garner a huge amount of support.
Chainlink is also working on many innovations in blockchain oracle technology. For example, they are introducing binding service agreements where Chainlink nodes can be required to put up collateral that can be slashed for delivering outlier data points, non-performance, or any other undesired behavior. Binding service agreements create a clearly defined short-term economic penalty for malfeasance (which can be fed into publicly viewable reputation systems), while future income losses continue to be the long-term economic penalty. This is just one of the many technical features being developed by the Chainlink team, demonstrating their ability to bring original academic research to oracle solutions, including:
Comparatively, Maker’s oracle team is unlikely to have the same bandwidth or resources to continually improve their oracles at the same rate as Chainlink since Maker is constrained by trying to solve two difficult problems at the same time (data transfer and data quality). Instead of building everything in-house, Maker can at least partly include Chainlink in enabling the Maker team and community to focus on their core product offering and business logic.
The LINK/USD integration can be an initial trial run for working with Chainlink.
Additionally, the DAI Savings Rate (DSR) has been a great addition to the Maker ecosystem, providing DAI users everywhere with the ability to earn a positive yield. This drives demand for DAI and gives the Maker governance community another method of helping maintain the peg. As the DSR is funded entirely by the stability fee borrowers pay, any other initiative pulling funds from the same source (like Maker’s current oracles) will decrease the interest rate the DSR is able to offer users. It’s important that as much of the stability fee as possible stays within the ecosystem and goes either to the DSR to boost DAI adoption or to burn MKR tokens to boost the growth of Maker’s governance community. By leveraging Chainlink and its shared cost model, Maker will be able to greatly reduce the amount of DAI siphoned away from the DSR, ensuring DAI is used more efficiently within the ecosystem and becomes more valuable to end users.
Maker is taking a big risk by trying to operate as a stablecoin startup and an oracle startup simultaneously. By integrating Chainlink for some initial collateral such as LINK/USD, Maker would be able to increase decentralization of the protocol, gain more independence from the Maker Foundation, ensure transparency of the oracle mechanism, increase efficiency of stability fee usage, and gain assistance from a large, experienced, and well funded team (no grants needed) who can help Maker ensure its oracle system is as secure and reliable as possible.
The use of the LINK/USD oracle would also encourage usage of Maker by the Chainlink community, which I have seen firsthand for the many other DeFi products and protocols that implement Chainlink.
The costs of integration are also minimal, having been researched and presented by the Chainlink team above. An integration of Chainlink’s LINK/USD reference price feed (https://feeds.chain.link/link-usd) for the LINK collateral type would be an easy interaction for both teams through a simple proxy contract that greatly lowers Maker’s attack surface by decentralizing its oracle mechanism using a time-tested oracle network that has strong market coverage for asset prices. This would efficiently act as a trial run of Chainlink oracles, proving itself to the Maker community through actual usage through the LINK collateral type. I think this is something that is worth a shot as I see no downsides to doing so as it only increases the security and tamper resistance of the Maker protocol overall.
Ultimately, Chainlink can harden the Maker protocol and its oracle system against more advanced attack vectors, which is critical to ensuring Maker can securely scale DAI up to support larger capital markets that require more stringent security and reliability guarantees, especially around data quality. This puts Maker in a position to gain substantial future market share against other DeFi competitors and even traditional finance competitors. Problems today only get magnified as time goes on, so integrating a secure and reliable decentralized oracle network like Chainlink ensures the success of MakerDAO well into the future.
Sorry for the long post, but I think this information is incredibly important to understand and process. Let me know if you have any questions about my analysis. I’m happy to discuss and elaborate further.
Personally, I think it’s a great idea to use the chainlink LINK/USD oracle directly for future LINK collateral types, as is being suggested in this original forum post. IMO the best argument for it is that it’s going to likely increase the amount of Dai generated with LINK (the reason for adding LINK in the first place), and be a first step towards a deeper collaboration between the two communities.
Secondly, I also think that the risk of doing so is uniquely low with the LINK asset specifically, since the value of LINK is tied directly to the performance of the chainlink oracles regardless.
Hypothetically, if the chainlink LINK/USD oracle failed and started printing 0, and as a result caused significant material harm to those who integrated it, the value of LINK would likely crash to nothing as platforms like Aave got wiped out with liquidations while all holders of the asset and all chainlink integration partners would immediately lose all faith in the project. So even if Maker used its own oracle system and correctly reported the market price of LINK - it’s unlikely the outcome would be any different than Maker having to liquidate the entire collateral type and keepers paying nothing for it. Not to mention that Maker of course would still have the Oracle Security Module in the proposed solution, so there would be an hour warning to trigger oracle freeze which further minimizes the potential risk of using the chainlink oracles for the LINK collateral type, even if you don’t trust them as much as the Maker oracles.
IMO both Maker and Chainlink have strong and battle tested oracle systems that have been live for multiple years and never experienced serious failure, and while I don’t think it would be a good idea for Maker to abandon its own oracle system and the lindy effect it has built up, to become completely reliant on a single external system.
At the same time, I think it would equally be a big missed opportunity if the community doesn’t pursue a deeper, and bespoke collaboration between the two projects that would allow Maker to deeply integrate the Chainlink oracles into the Maker oracle.
Such a collaboration would benefit Maker by adding diversification and robustness to the Maker oracle and further reducing its reliance on any single party, and it would benefit Chainlink and LINK holders by creating a permanent source of income for Chainlink oracles.
And IMO, a great first step towards that future would be to start by using the Chainlink oracles directly for the LINK/USD asset, and then use that experience as the springboard towards a deeper integration.
Still keen on adding LINK oracles to the ecosystem given Zeus Capital’s analysis? Sure I think they have an interest in LINK declining in price, but think there is some merit to what the fund believes.
This report contains heavy disinformation and gets even the most basic facts about Chainlink wrong. I would disregard this entire report as they don’t get any information correct and the firm pushing it has made it clear it was written because they have a short position. It even includes a guide for others on how to short the LINK token.
It’s disheartening to see a 66 page report that tries so hard to gaslight the Chainlink community with falsehood after falsehood. This is commonly referred to as Gisp Gallop, where a wave of misinformation is pushed that takes longer to debunk than it does to write, but unfortunately it’s all too effective as most people do not dig deeper.
As a summary they lie about the
• SmartContract team
• LINK Tokenomics
• On-chain data
• Addressable market
• Network security
• Adoption from DeFi
• Onboarding of nodes
• “Market manipulation”
• And basically everything else
If you have any specific questions that arose from this, I would be happy to answer.
Hey guys - knowing that the LINK collateral has already been greenlit by the Community poll I’d like to propose what I think the next steps should be regarding this proposal.
Before doing so, I’ll summarize what I got from the previous discussions on this thread and why I think this proposal goes hands in hands with creating a viable LINK-USD collateral framework which can further the growth of the Maker ecosystem in the long term.
The need of a sufficiently secure LINK-USD feed - The proposed feed is up and running already as well as being used by leading teams in the industry such as Set Protocol. It has 9 fully identified and security-reviewed independent node operators and 7 independent data providers. We also have a good performance history and logs that go back to the last 6 months.This allows us to analyze the behaviour of the feed, including live and historical - heartbeat, minimum amount of node responses needed for aggregation, and latest aggregation update time of the price feed.
Sustainability - The Chainlink network has the right token economics to allow the subsidy of the LINK-USD feed for the next few years. Additionally, the LINK-USD feed is also being maintained and kept working due to 3rd party paying customers of the system. These flows pay for premium APIs which refresh the price every minute or less and allow node operators to use premium hardware as well as sustain very expensive periods of network congestion.
Protection against attacks - The risks of price feed manipulation/distortion have been studied and mitigated. It uses volume weighted exchange prices instead of using a median of exchange prices. The use of premium data sources also significantly reduces the risk of price manipulation, even during extreme market conditions offering protection for future LINK vault holders against large-scale price manipulation attacks.
As a long time supporter of Maker, I believe the inclusion and usage of Chainlink price feed benefits users of the system by decreasing the price feed risks associated with LINK collateral in the MCD. As a result of reduction of risks, the LINK Debt Ceiling may be set higher resulting in a higher total amount of premium being earned from holders borrowing DAI using LINK as collateral.
Rationale for merging: Without merging this proposal into MIP6 LINK Application, I consider the MIP6 as incomplete. Upon merging, the updated MIP6 LINK Application will be reviewed by domain teams, and the potential benefits introduced by the LINK price feeds will be quantified - specifically, the impact of this proposal on LINK’s Debt Ceiling and Collateralization Ratio. @LongForWisdom - does it make sense for you to proceed this way?
First of all I want to thank Johan for drafting this proposal and presenting it to the Maker Governance community. This further validates the thesis of transparent decentralized governance and is a testament to how far we’ve come as a community.
After carefully going through the proposal, I’d like to articulate my thoughts on behalf of my role on the Oracle Domain Team. I want to make it clear that I’m speaking in an advisory capacity rather than from a position of authority. Ultimately, this analysis should serve as a data point for Maker Governance to consider when making their decision.
I’ve split my analysis into several categories.
Maker’s Oracles are entirely owned by Maker Governance. This ownership model ensures all Oracle-related decisions are vetted by MKR holders. There are no hidden switches, backdoors, or private keys controlled by the Maker Foundation that allow it to affect the operation of the Oracles in any way. Every action related to the Oracles, including adding/removing Feeds and changing Data Models, requires a proposal which is then reviewed and ratified by Maker Governance in a transparent manner with MKR token holders have the ultimate say.
In contrast, Chainlink’s LINK/USD Oracle is owned by the address 0x304D69727DD28ad6E1aa2c01Db301dB556C7b725 which has full authority to make any arbitrary decisions relating to Chainklink’s LINK/USD Oracle, including adding and removing Node Operators (Feeds in Maker lingo) as well as changing the quorum, the combination of which enables that address to manipulate the Oracle price at will.
The core revenue for MKR holders is driven by Stability Fees and Oracle Fees.
On the collateral front the incentives are aligned, and MakerDAO and Chainlink can be great partners. LINK is a solid collateral type to add to the Maker Protocol and helps diversify the collateral portfolio backing Dai. Inclusion of LINK would earn MKR holders additional Stability Fees and lead to more Dai generation which helps stabilize the peg.
Since ratification of the Oracle Incentives Restructuring Proposal MKR holders created an additional income stream through Oracle Fees by creating an Oracles as a Service product out of Maker’s Oracle infrastructure.
In the Oracle domain, Chainlink and MakerDAO are competitors. Currently Maker and Chainlink have split the DeFi market and target the same customers. Using the Chainlink Oracles even for a single collateral type undermines MakerDAO’s own Oracles service offering. Why would our partners choose to use Maker’s Oracles if we utilize Chainlink’s Oracles? Utilizing Chainlink’s LINK/USD Oracle has potential far reaching consequences including cannibalizing Oracle Fee revenues for MKR token holders.
Chainlink’s usage of data aggregator sources rather than sourcing raw data directly is troubling.
The node operators fetch data directly from data aggregator endpoints. We favor using aggregators because there are many inherent issues that can arise from fetching data directly from exchanges. Possible exchange data issues include liquidity and volume shifts across exchanges, data manipulation and other situations that are a huge threat for a misarchitected oracle system
The MakerDAO Oracles query data directly from exchanges and employ a Data Model to process that data in a transparent way specifically out of a matter of preference compared to external data services such as those used by Chainlink. This approach has several advantages.
First the MakerDAO Oracles don’t have to trust external data services. There is no additional point of failure, no risk of api services failing, and no risk of intentional censorship. More importantly the MakerDAO Oracles, and by extension the Maker Protocol, don’t have to trust those external data services which could potentially provide malicious data. An added benefit is that we don’t need to vet the tech stack of external services, nor keep up with technical changes in their backend that could affect our Oracle price.
Second, this approach gives Maker Governance much more flexibility and control. The Maker Protocol can process data using a Data Model exactly how governance determines it should be processed and in a completely transparent manner. The risk of each asset type can be analyzed independently and handled accordingly on a case by case basis. This results in Maker’s Oracles being much more secure and deterministic. It also means Maker Governance can iterate quickly and adjust Data Models depending on changing market circumstances rather than having to request external services change their API to suit our preferences which they may not be willing to do or aren’t prepared to do with the agility we would like.
As for the concerns of exchange data carrying its own risks, I agree completely, which is exactly why Domain Teams conduct research and study academic papers about market-manipulation, wash-trading, and market-depth among others when conducting risk analysis to compose Data Models that are unique for every collateral type. These Data Models are then reviewed and ratified by Maker Governance to create a transparent and decentralized mechanism for how the Maker Protocol derives a canonical price.
The Maker Oracles are currently significantly more decentralized than Chainlink’s Oracles and we would ultimately be decreasing the decentralization of the Maker Protocol were it to utilize Chainlink’s LINK/USD Oracle, or any other for that matter.
Chainlink’s LINK/USD Oracle has 10 Feeds, with a quorum of 7. Meanwhile Maker’s Oracles currently have 25 Feeds with a quorum of 13. Maker’s Feeds include a long list of respected actors in the Ethereum ecosystem, with valuable brands and reputations they have to protect to continue operating in the space. These include dYdX, 0x, Set Protocol, Gnosis, Maker Foundation, Kyber Network, Infura, Etherscan, Gitcoin, and Argent (with a pending proposal from MyCrypto).
Another aspect to consider with respect to decentralization is the multi-sig ownership of the Chainlink LINK/USD Oracle that was mentioned in the previous section on Governance. The Maker Community has no sybil guarantees of the Chainlink multi-sig, meaning they could all be the same individual. Apart from malicious behavior by the signatories of the multi-sig, there is also an additional risk that 3rd party manages to compromise the keys of the multi-sig signatories. This risk doesn’t exist at all with respect to Maker’s Oracles since all Oracles are entirely controlled by the Maker Governance. Usage of Chainlink’s LINK/USD Oracle in the Maker Protocol would inherently be placing trust in Chainlink the organization. This poses a significant risk to the Maker Protocol as it’s adding a centralized point of failure.
Maker’s Oracles are designed to maximize resiliency when the network is congested. Key to this is that the number of Feeds is independent from the number of transactions that need to occur. With 25 Feeds, it only takes a single transaction rather than the model Chainlink uses which requires each Feed to submit its own transaction (linear relationship of Feeds to transactions). Network congestion is fairly correlated with price volatility, as gas prices spike from bot activity. **This means that when the price is the most volatile, and liquidations are likely to be necessary, Chainlink’s Oracles struggle due to needing to mine at a minimum 7 transactions to achieve a price update as opposed to Maker’s Oracles which require a single transaction to be mined. Evidence of this can be found during Black Thursday during which Chainlink’s Oracles went down for over 6 hours. These conditions illustrate the importance of a 1-transaction model for optimal Oracle performance.
As a design philosophy, the Maker Protocol was designed from a security point of view to have no external technical dependencies. This enables a controlled environment for analyzing the behavior of the system to ensure its integrity. Utilizing Chainlink’s LINK/USD Oracle would create the first external technical dependency in the Maker Protocol. I would caution Maker Governance to take such a drastic step without carefully considering the ensuing consequences.
In summary, after an investigation by the Oracle Team analyzing a variety of different aspects it makes little sense for the Maker Protocol to utilize Chainlink’s Oracles for LINK/USD nor any other collateral asset due to the increased decentralization, security, transparency, and flexibility afforded by the MakerDAO Oracles combined with the potential revenue of its Oracles as a Service business interests.
That being said I think Chainlink is a great project in its own right that is helping DeFi to innovate and scale, and I do think there are other ways to collaborate.
We’re excited to find the best way to be a positive Maker community member and to do our best in supporting the growth and overall success of MCD…We look forward to working with the Maker community in their preferred manner.
Might I suggest that Chainlink apply to become a Light Feed for the Maker Oracles? I’m sure the community would be enthusiastic about Chainlink’s inclusion to help further decentralize the Oracles that the Maker Protocol relies on.
Hi @Johann, with respect to the governance aspect of this, I do not think that merging this proposal into the MIP6 application for LINK makes sense in terms of governance process.
Combining the two would prevent MKR Holders that wanted LINK as collateral without providing the LINK/USD oracle (or vice versa) from expressing their preferences.
Additionally, LINK-as-collateral already passed community greenlight. By merging the proposals after that vote, it lends weight to this LINK-as-oracle proposal despite the fact it was never voted on.
Furthermore, the community has voted on a specific process to onboard new collateral via the MIPs process, that process wasn’t written with attached proposals like this in mind, and it would be difficult to merge them while still following that ratified process.
ChainLinkGod says, “As the DSR is funded entirely by the stability fee borrowers pay, any other initiative pulling funds from the same source (like Maker’s current oracles) will decrease the interest rate the DSR is able to offer users.” “By leveraging Chainlink and its shared cost model, Maker will be able to greatly reduce the amount of DAI siphoned away from the DSR, ensuring DAI is used more efficiently within the ecosystem and becomes more valuable to end users.” “Maker is taking a big risk by trying to operate as a stablecoin startup and an oracle startup simultaneously.” This is like Microsoft asking Amazon to save money by stopping AWS and move both Amazon and its customers to Azure.
Maker oracles are the clear leader in DeFi today. I hope MKR holders are not shortsighted of the opportunity that lies ahead and support the network effects and dominance already built by Maker Oracles so that it continues to be a pillar everyone in DeFi can rely on for a long time into the future.
Hi @NikKunkel, thank you for taking the time to create a response to our proposal. We appreciate the time you’ve put into having this dialogue with us here.
I do want to provide you with some additional information as to why I believe Chainlink’s oracle networks might indeed meet your requirements, how they can accelerate the addition of even more collateral to MCD (including LINK), and how they may also reduce additional risks. We’d be thrilled to work closely with you on helping meet your oracle/data input needs, and are glad to do this now, later, or at whatever point you do find sufficient value in what we can offer Maker and MCD.
In addition, I’d also like to clarify one or two points, just to make sure that you have the right information about the proper operation of our system.
We do take decentralization in all facets of the Chainlink Network very seriously, and are continually focused on increasing the amount of nodes, data providers and informed multisig key signers involved in approving system upgrades, in line with the same model used by great decentralized infrastructure teams like ENS (Ethereum Name Service).
The address you mentioned for updating the LINK/USD network is a multi-signature contractwith eight independent signers. This multisig includes multiple Chainlink node operators, who are the people actually running these networks and are the ones who implement upgrades in quorum size increases, additional data sources, and many other upgrades that are occurring to properly secure the market data being consumed by our users. This multisig is also consistently increasing in size, and we are now also on a path towards including users of the oracle networks as multisig signers as well, which will make the group signing off on changes even more diversified and therefore increasingly resistant to manipulation. This follows the ENS model, where signers are chosen from a pool of highly competent people who are key stakeholders in the protocol’s proper operation and have been verified to have security-hardened private key management. This multisig is not based on a token ownership model, eliminating the possibility of anyone buying control over the Chainlink network.
Maker Governance can be added as one or multiple signers to this multisig. This would allow the MakerDAO community to use the existing voting processes, using MKR tokens to sign off on changes to the Chainlink network’s that Maker utilizes for its expanding pool of MCD assets. We’re glad to explore this option if it’s particularly important for MKR holders to vote on Chainlink oracle network upgrades. This model also allows us to include various other communities in this vote as well, which is especially important if they are also paying for, using and therefore seeking a say in how their underlying oracle network is being upgraded.
Additionally we are actively working on implementing a governance contract and governance framework, which will further decentralize control of the Chainlink networks update process, adding a governance/voting contract with various additional limitations and protections in place. Our first goal was to offer the most decentralized oracle network with the highest quality node operators while also providing the highest quality data, secondly we’ve gone on to make that oracle network economically sustainable, and finally we will be having all the key stakeholders of the network governing it into a state of well informed and proper ongoing operation.
I believe that our goals are actually quite compatible, as we both want to help grow Maker’s MCD as much as possible, and thus DeFi as a whole. We can contribute to that growth through the oracle systems we have built and refined over the past few years and would be excited to do that together with you and the larger Maker community at whatever time you think is appropriate.
What we’re proposing is not the replacement of the current Maker oracle system, just the addition of an oracle network, oracle team, or “oracle partner” into Maker’s existing process. Almost all financial firms use multiple systems not developed entirely by them, and are often able to execute on their goals substantially faster than the firms that adopt a ‘Not Invented Here’ approach to the evolution of their technology stack.
I also know that we are aligned in making sure that the oracles used by Maker continue to operate at the highest level of reliability, data quality and decentralization, which once again shows a clear compatibility in our goals. Chainlink Network’s developers, node operators and growing community, has the largest incentive of any project in the entire blockchain industry to operate an oracle correctly, as its exclusive focus, and there are continually increasing amounts of resources being deployed by multiple teams, to make sure that it not only operates properly, but also provides the highest quality of data. Here is some brief info about one of the teams building the Chainlink software; https://team.chain.link/ as well as a recently released grant program. This should give you some sense of the resources that are continuing to be deployed around allowing Chainlink to properly solve the oracle problem using decentralized computation, while also making sure that DeFi smart contracts operate using high quality data.
We’re not suggesting that Maker has to switch entirely to Chainlink, just that the resources already made available by Chainlink, specifically in the case of the LINK/USD network; https://feeds.chain.link/link-usd, might be useful. We also believe that as mentioned earlier in this thread by @rune, it would be a missed opportunity not to explore a productive working relationship with a protocol/team that can accelerate the speed at which additional collateral such as LINK is securely added to MCD. I actually think that the immediate effect of this would be dramatically reducing the costs that need to be paid for adding new collateral, accelerating their addition and providing more bandwidth to Maker’s existing oracle team, so they can focus on their plans, possibly allowing them to look more at the layer around how oracles should securely interact with MCD.
We also imagine that at some point soon, there will be so much collateral being on-boarded to MCD that multiple oracle teams will eventually be needed, providing both additional decentralization and an ability to more quickly add various collateral. I don’t know what Maker’s plans are for building out its various decentralized teams, but if good teams that aren’t from the Maker foundation, can help Maker succeed in its primary goals of enabling MCD to secure hundreds of billions in value, then I do think that is a large opportunity to help Maker succeed.
Now may or may not be the right time for us to work together from Maker’s point of view, but I do think it would be benefit Maker/MCD, to have a path for hard working, committed and well resourced teams like ours to help improve MCD as a Maker team or through some kind of “partner program”, in a way that allows us to provide the full extent of our capabilities. In this thread, we’re doing our best to be part of the Maker community, because both I and the Chainlink team believe in Maker, MCD and its important role in DeFi.
Additional Risks to Consider
It is also important to note that if Maker uses only a single oracle mechanism created by it, and becomes known for depending entirely on that oracle as the basis of the entire system’s security, an oracle failure could become catastrophic for the faith that users have in Maker and MCD/DAI. An oracle failure from an oracle made entirely by Maker that leads to the loss of user funds, would likely be seen as a failure of the Maker/MCD system generally and therefore call into question the reliability of all the DAI in existence, because the same team that made the oracle and chose to fully rely exclusively on that system for data, also created the system that generates DAI itself. Conversely, any kind of failure by an oracle system external to Maker, is treated as unrelated to Maker’s overall reliability, competence and DAI’s overall reliability as a stable coin, through a separation of concerns that the MCD system can protect against with one hour delays and similar risk mitigation measures.
The substantial risk in focusing on only using a single Maker made oracle mechanism, and tying Maker’s brand/security/reputation entirely to that oracle, is that people’s faith in DAI would then come to depend on two distinct and separate and equally difficult to achieve outcomes:
The ability to aggregate a large pool of high quality collateral that is properly weighted against various risks, to generate the world’s leading censorship resistant stable coin.
The ability to build a leading method of decentralized computation to solve the oracle problem and secure the infrastructure that provides that decentralized computation.
These two outcomes are clearly very different and being world class at the first (generating MCD/DAI), is entirely uncorrelated to being capable of achieving the second; creating a new form of decentralized computation to solve the oracle problem. This means that there are now two distinct buckets of risk for DAI’s overall success, financial engineering risk and technology/oracle risk, which was rightfully born out of the necessity for a decentralized oracle at Maker’s launch, but doesn’t need to continue as a possible “failure mode” if there are other well made oracle mechanisms that are focused on successfully solving this second technology risk.
Please take a look at this recently released and detailed blog post on this point: https://blog.chain.link/the-importance-of-data-quality-for-defi/. The risks being taken by creating a market data product, especially for the more thinly traded tokens now being added to MCD, together with an oracle mechanism made up of multiple services, all at the same time, are quite large in our opinion. We are worried that ignoring these risks, with a resource constrained team and an architecture that has connections to unpaid APIs (no quality guarantees), multiple hops between data and the contracts (relayers), as well as a slow process for updating the composition of the data product through extended voting periods, could hold large unforeseen risks.
The first risk involves volume shifts and whether the exploitation of your chosen exchanges becomes low cost. This risk means that only money and a trading account would be required to manipulate the oracle values being fed into Maker’s MCD. As cryptocurrencies are a permissionless technology, any exchange is able to list a crypto-asset and start a new liquid market, which could become rapidly popular due to fee incentives, yield farming incentives, and/or other incentives we haven’t even seen yet. This means volume can shift and has historically shifted very rapidly. This creates a lack of sufficient market coverage as volume could concentrate to a few exchanges and/or move to exchanges that weren’t included in the aggregation process, both of which can heavily skew the resulting median.
The second risk involves flash crashes, where the market price on one or a few exchanges deviatie far outside the rest of the market. A large contributor to this is that many cryptocurrency exchanges lack sufficient circuit breakers to prevent such issues. We have seen numerous cases over the years of reputable exchanges such as Coinbase, Kraken, and Bitmex experience crashes ranging from 66% to 99%.
The third major risk involves quality dilution where the lower quality data sources within a simple aggregation method dilutes the higher quality data sources. By not taking the volume-weighted average, the final resulting data point is not guaranteed to be of high enough quality to secure the contracts the data is fed into.
We have already seen the manipulation of an oracle mechanism using only trading activity on thinly traded order books found on a DEX, leading to an actual loss of funds for end-users. To continue ignoring these substantial risks, in the hopes that volume won’t shift, hope that flash crashes won’t happen and/or hope that data sources will be able to get switched out quickly if they do, is a large risk. This risk is also much greater with the more thinly traded tokens that are now being added to MCD.
To mitigate these categories of risk, Chainlink Price Reference Feeds pull data from high quality data providers, who have decades of experience ensuring robust market coverage, even during volume shifts, flash crashes and various adversarial situations. These data providers have raised VC funding, sell their data to top crypto hedge funds, and have their entire focus on making a high quality data product, which is why they are our data sources for crypto prices. Our system is in fact built to solve the very data quality problem that MCD now faces as it is focused on adding additional collateral that is valued in thinly traded markets, which are prone to rapid shifts in volume and the many other risks described here.
The Chainlink network features a large amount of decentralization, with hundreds of nodes currently competing to be deployed to the oracle networks that require additional node operators, based on the value that they secure. Chainlink’s price reference feeds operate only using the highest quality, professionally run and security-reviewed node operators who are dev-ops teams with experience in architecting and maintaining reliable blockchain infrastructure. Many of these operators hold private keys within their nodes that secure hundreds of millions of dollars in various Proof-of-Stake networks, in addition to being Chainlink node operators. They are well staffed, time-tested and security driven node operator teams with their focus being on devops, systems security and being a high quality blockchain miner/validation service. In Chainlink’s case they are mining “off-chain data inputs into the blockchain”.
Our system actually highlights cryptographically proven historical performance and various other security guarantees of our node operators. This creates a highly decentralized network of the highest quality node operators, that does not employ a ‘security through obscurity’ approach, but instead is fully transparent, providing access to performance data about every node operator and their true reliability. Feel free to dig into these node operators by clicking on them in the http://feeds.chain.link/ page, and/or digging even deeper into them on https://market.link/ e.g. https://market.link/nodes/eaa65e96-c498-4af6-a682-47ff9951f75f is a good example of a well run node operator, who also has their Keybase verification attached to their node; https://keybase.io/linkpool/sigs/463c433b285f1df4a29c37ff72697eb92175b44bc31f2670861167ef21f840da0f. It is this approach to transparency, which creates both the sybil resistance, and accountability for node operators who have large amounts of funds at stake in their reputation as a high quality node operator. Once again, please notice that we work with a very focused and high quality group of network participants that specialize in their specific role in the Chainlink Network’s proper operation.
It is also notable that the Chainlink team’s node doesn’t even participate in the vast majority of these oracle networks as a node operator, with all the other node operators having their performance history tied to their identity, which is fully transparent to incentivize proper behavior towards the protocol. Another point to consider would be that Chainlink’s nodes don’t need additional “relayer” nodes to actually send data into a smart contract, which means less hops/trusted third parties for the data, and in many cases the nodes are run by data providers themselves, creating even less hops.
Conversely, in Maker’s current system, it seems difficult to predict when free/unpaid exchange APIs may go down, have a flash crash, or become thinly traded enough to manipulate at low costs, we also can’t seem to tell who 60%+ of the Maker nodes are operated by, whether that is one person, many people and/or whether they are Maker team members. Additionally, we don’t know who the 5 relayer addresses that actually send those nodes responses into Maker’s contracts are run by or what guarantees we can expect about their availability, incentives, and/or independence from one another. Not even mentioning the nodes themselves, If these unknown relayers stopped operating during a period of highly volatile market prices, or if they continued to operate but a single exchange’s prices became manipulated, then the resulting gap in price could lead to inaccurate liquidations, which would lead to the same issues with inaccurate liquidations from earlier this year, but possibly at a larger scale, as the value secured by Maker continues to grow.
We are not proposing that Maker replace its oracle system entirely, that is not the topic of this post, we are just highlighting that the difference in our approach could provide an additional layer of security to MCD that is worth adding as an additional oracle mechanism. Chainlink can accelerate the onboarding of new collateral and this can be done through a trial run, during the on-boarding of LINK and the use of the https://feeds.chain.link/link-usd network as an easy to implement starting point. In any case, at some point in the future, it does seem prudent for Maker to begin a working relationship with an additional oracle method/team/partner, who can serve to accelerate maker’s onboarding of MCD, as well as become a committed long-term partner and additional Maker community member on the topic of oracles.
Chainlink’s goal is to create a decentralized oracle mechanism that maintains the highest security standards, data quality standards and decentralization that is needed for smart contracts to properly interact with external inputs/data. With this in mind, the design decisions we’ve made to this point are something we are entirely willing and able to stand behind as meeting those high standards. The usage of on-chain consensus to arrive at the aggregation of oracle reports from multiple sybil resistant nodes, is indeed more costly, but it is also far more secure and reliable than the off-chain aggregation schemes that are composed of multiple services and various protocols in various unaudited combinations.
We are currently finalizing the details of a scalable, secure and well researched off-chain aggregation scheme, which we briefly outlined last year in Chainlink Threshold Signatures. Just like the original Chainlink whitepaper; https://link.smartcontract.com/whitepaper and additional papers on oracle security; https://chain.link/mixicles.pdf, this is also being built together with leading security researchers, such as Ari Juels (Previous Chief Scientist of RSA). Even with all of this attention to detail from experienced security and distributed systems experts, our approach is still undergoing an extensive security audit, in order to assure us that its security assumptions can be relied upon. Though we are eager to arrive at a more efficient method for placing oracle reports on-chain, we are absolutely unwilling to compromise on security in order to achieve short term cost savings and/or efficiency gains.
In regards to Black Thursday, there are a few important points to consider.
Firstly, none of our users suffered losses as a result of the Chainlink oracle, as we were in touch with them about the Ethereum network’s congestion, the limitations that created, and how they should react accordingly. In fact, many users spoke out publicly about their happiness with how many of our networks were operating as needed for their smart contract to operate properly during this period of truly extreme network conditions;
Secondly, for the few networks that were delayed due to the extreme network congestion of black thursday, this is something that extended to Maker’s oracle mechanism as well; https://insights.glassnode.com/what-really-happened-to-makerdao/. Though we haven’t, looked into the downtime of the Maker oracle in detail, I do remember that it lasted for multiple hours, and as far as we could see, extended to all of Maker’s oracle feeds. If that is correct, then this means that the black Thursday event actually stopped all price feed updating for all Maker collateral, whereas many Chainlink feeds continued to operate to the levels that allowed our users to operate.
Thirdly, this was an extreme network congestion event, that also affected the proper operation of nearly every DeFi application on the Ethereum network, and was something that these applications were unable to cope with as well, many having to pause their markets, transactions and overall operations, even when they only had a single address that was responsible for triggering events on their system. This means that just like Maker’s oracle feeds were unable to create updates with less signers, many other systems with a single signer were also unable to operate properly. This shows that having a single signer doesn’t guarantee acceptance into network transactions during periods of extreme congestion, while also showing that having a single signer/data relayer does seem to guarantee that if that one signer is unable to function properly, all the systems that depend on them come to fail.
Importantly, we did learn a lot from black thursday, leading us to create and deploy what we call the “bulletproof transaction manager”, about which we’ll be releasing a blog post sometime soon. As of this past weekend’s spike in gas prices, we’re glad to say that all of our networks operated as expected, delivering high quality data, from multiple sybil resistant nodes, securely and transparently.
We do of course appreciate your points on these network congestion concerns, and want to assure you and the larger Maker community, that this is something we’ve been taking extremely seriously with our work on the Bullet Proof Transaction Manager and our upcoming release of Chainlink Threshold Signatures, as the definitive way to perform off-chain aggregation of oracle reports without compromising on security.
We’re extremely excited to work together with Maker, as an additional oracle network that can accelerate adding collateral, which will allow us to become an active Maker community member, contributing to the success of MCD. We do believe that Maker will reach the exciting heights that have been laid out for its decentralized and community driven future. We want to be part of that community and to play a role in that future, whenever Maker decides it’s the right time for us to help in the unique and focused way we know how.
We do see many people in the Maker community wanting to work with us as an opportunity to accelerate Maker’s creation of more DAI, as mentioned by @rune, possibly starting with our ability to offer the LINK/USD oracle network, which is already live and has been successfully operating throughout its life. There seem to be many people that are on the fence about us working together, possibly because our system’s guarantees are unclear to them, which we completely understand, as these are complex distributed systems, infrastructure security and data quality questions that have many nuances. Finally there are a few people who seem to oppose us working together, seemingly driven by the idea that Maker should create its own form of decentralized computation to solve the oracle problem and exclusively tie all of Maker’s collateral and its overall brand to that oracle mechanism.
It’s been quite fascinating participating in the Maker community, governance process and interacting with these many varied groups. As noted by @rune earlier in this thread, the use of the LINK/USD oracle specifically, presents a unique opportunity for a risk minimized way to test out our collaboration, while creating more DAI and providing more information to Maker governance about what it’s like to utilize a Chainlink oracle network for MCD.
It is a valid point that our collateral is linked to the proper operation the Chainlink oracle network, and therefore there won’t be any additional risk from using the already live LINK/USD Chainlink oracle network, specifically for the addition of LINK as collateral. This would allow us to start our collaboration in a risk minimized manner, provide additional data to the Maker community/governance process and allow the formation of a clearer picture about the risks and benefits of working together with Chainlink as an additional partner/team on the topic of oracles.
As eager as we are to work together with Maker and the amazing community you’ve built here, we do understand that this is a multi-faceted decision, and that we may have misunderstood Maker’s priorities when it comes to MCD, oracles, and/or any number of other points. We prefer to have closely collaborative partnerships with the DeFi projects that we work with, that are based on the Chainlink Network’s ability to provide unique value to its smart contracts users, and we hope that we’ll have the chance to work with Maker in this way as well. If that time isn’t now, and the interests within Maker that see the creation of your own form of decentralized computation to solve the oracle problem (a difficult, risky and resource intensive endeavor), do turn that into a primary focus, then we can understand why working with us may not be a priority. We will of course be huge fans of Maker nonetheless, and hope that we can work together sometime in the future, when the value of Chainlink’s oracle networks and the deep collaboration/expertise we can offer is more closely aligned with Maker’s long-term priorities.
Yep, we think so too. Going to need a lot of oracles feeds.
How does “oracle nemesis” sound?
I shouldn’t have used such strong wording here. There is plenty of room in this space for both Maker and Chainlink oracles to have an abundance of success. I wish you and the other marines luck. 1k EOY is FUD