Using Chainlink Oracles for LINK-USD


Hi Maker Community, we’re excited about the prospect of working with you on our shared goals of helping make Maker and MCD even more successful than it already is. We know there is a proposal to add LINK to MCD, [LINK] Collateral Onboarding Application and are looking to support this integration technically, to enable its secure and efficient operation in helping improve DAI even further.

Firstly, it is important to say that we have many shared goals. We both want Maker to succeed as an approach to making stable currency, we both want DeFi to use Maker’s DAI as a way for users to gain the benefits of decentralized financial products with a stable medium of exchange and we also believe that DAI can help change the world, especially in places where stable currencies are a critical need. We’re excited to join the Maker community, devote resources to helping with this initial integration to help make it secure, efficient and successful for Maker, as well as become a longer term positive community member.

In this initial post we’ll cover some points, as a way to begin the discussion:

  • We’ll discuss the reasons and shared goals that led us to submit this proposal
  • Take an initial look at how Chainlink decentralized oracle networks operate to create an on-chain price feed that can be relied upon by Maker for this specific integration
  • Cover how integration is both secure and easy to accomplish for both systems


The team working on Chainlink is made up of true believers in DeFi’s usefulness to society, and in the Ethereum ecosystem as the environment where DeFi is taking off first, in no small part thanks to Maker. The creation, growth and secure maintenance of a fundamental building block for this ecosystem through MCD and it’s creation of DAI, is something that many of the people working on Chainlink firmly believe in as being important. Both Chainlink community members and Maker Community members want to see MCD succeed and are both eager to help secure the DAI stablecoin which will continue to grow the value transacted in DeFi. This growth in DeFi through MCD effectively provides for more value for Chainlink decentralized oracles to secure, while Chainlink’s enablement/launch of more use cases for MCD leads to more usage of DAI. In addition to this fundamental overlap in accelerating the growth of DeFi to each protocol’s mutual benefit, we also share many of the values around decentralization and security that need to exist for DeFi to provide its full value.
Bringing our two communities together through this initial integration is something we’d all be excited about and will help create a more active ecosystem around both Maker and Chainlink, which will in turn contribute to a much stronger and more robust DeFi ecosystem.

Price Feed Ecosystem

Let’s now discuss how Chainlink’s decentralized oracle networks provide on-chain price feeds. The price feed is a smart contract deployed on Ethereum which medianizes price values coming from multiple high quality and fully independent node operators, made up of leading DevOps teams.

In order to discuss the security guarantees offered by these feeds, we will explain the concepts of oracles (also referred to as node operators) and data providers that together form the basis of Chainlink’s decentralized oracle network’s security, liveness and reliability.

Node Operators

Node operators are entities responsible for running Ethereum and Chainlink nodes and maintaining credentials for API providers that fetch specific data points, such as the price of a crypto asset. You can view them as a bridge between the blockchain and given API endpoints.

The Chainlink ecosystem comprises around a hundred oracles/node operators, all displayed on third party listing services such as and

The node operators servicing our decentralized oracle networks to generate on-chain price feeds, are a subset of the overall node operator ecosystem. These price feed nodes have gone through thorough extensive security reviews and demonstrated high competency in the infrastructure field. They’re often teams with the following backgrounds:

Node operators in Chainlink reference price data networks are sybil resistant and go through both identity and security reviews before being added to networks. This provides full transparency to the on-chain price feeds contract creator and their users, who can assess the quality of each network’s node operators on profiles such as This also allows Chainlink to avoid relying on “security through obscurity” assumptions that are usually explicitly avoided by more secure systems. For example, the operators for the LINK/USD decentralized oracle network; have been running on mainnet since February 12th. With it also being used for more than three months in Set Protocol’s tokensets ( product to trigger rebalances based on the LINK price. These are the operators currently maintaining the feed, which can be increased as the value secured by this decentralized oracle network increases

These operators are distributed all over the world: some are in Europe (Certus.One and Staking Facilities), some are in China (SNZ Pool), some are in Korea ( B-Harvest), etc. By maintaining a diverse geographical distribution, we’re able to drastically reduce the risks associated with specific infrastructure failures in any one region. It’s also possible to thoroughly research and get performance data on each of these operators, as well as the LINK/USD network as a whole, which is the case for all Chainlink decentralized oracle networks.

Data Sources

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. These single exchange data source attack vectors have already been exploited successfully in many cases, and something we actively seek to avoid.

Decentralized oracle systems can by nature be slow to react to exchange operational issues and large shifts in volume across exchanges. In many cases, we believe oracles should rely on data aggregators teams that are experts at creating algorithms that detect data anomalies and important volume shifts across markets. Additionally, through the use of data aggregators, we’re able to decentralize the data curation process by relying on multiple different calculation methods and algorithms instead of a single possibly flawed calculation method.

The LINK-USD price feed currently uses 7 different data aggregators including BraveNewCoin (, Amberdata(, CoinAPI ( and other high quality data aggregators. These data aggregation teams have been providing price data to the top professional cryptocurrency traders, and others who rely on their data for billions of USD in value. The amount of data providers can also be increased over time as the amount of nodes grows, due to the additional value secured by this oracle network. These are all configurable parameters that we’re glad to consider increasing as the need for additional security from any one decentralized oracle network needs to increase.

Integration, Scaling and Decentralization

After conducting some initial technical due diligence, we believe that because Chainlink price reference contracts follow a read model, this makes it simple to integrate them as a source of data in the OSM module, this should make the integration of the LINK/USD feed for the Maker smart contract domain team extremely straightforward. This is further detailed in the following section.

An additional benefit of working with Chainlink, is that the team behind Chainlink is a well capitalized and sustainable organisation which doesn’t require any funding from the Maker Foundation. This allows further decentralization of the development and maintenance of MCD and its oracle mechanism for this specific collateral, entirely separately from Maker. Ensuring that independent systems such as Chainlink’s oracle networks, which are separate from the Maker foundation, will keep contributing data to ensure a specific collateral’s operation, could be seen as an important step towards making sure that DAI is as secure and decentralized as the Maker community seems to be seeking, and which we believe would contribute to the wellbeing of the overall DeFi ecosystem at large.

An additional important point is that because LINK is tied to the successful operation of Chainlink’s Oracle Networks, such as the one we’re proposing to use for feeding data into this integration, there is no additional risk for MCD in using the Chainlink oracles for this specific integration of LINK. Since LINK and the oracle networks successful operation are so closely intertwined, it will act as one wholistic pool of risk, at least for this specific integration. The risk may indeed even be reduced because a portion of Maker’s collateral will be running on a separate oracle mechanism.

We look forward to working with Maker community in their preferred manner, are glad to discuss all of this more, and are ready to scale up our LINK-USD decentralized oracle network; to the same levels as other larger networks (, and beyond if needed. 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 in this initial integration.

Implementation Details

According to the OSM, values can be read from any contract that has the peak() and read() method implemented. The Chainlink team will create a proxy contract that implements the read(), peek(), peep(), and poke() methods such as

interface IDSValue {

function peek() external view returns (bytes32, bool);

function read() external view returns (bytes32);

function peep() external view returns (bytes32, bool);

function poke() external;


The next lines will detail what each function currently looks like and how they will interact with the Chainlink reference contract(

peek(): Returns the current feed value and a boolean indicating whether it is valid.

current feed value: The current feed value will correspond to the latest price converted to bytes32 as required by the OSM.

boolean: The boolean will correspond to the result of a check for stale data, using the concept of Round updates.

read(): Returns the current feed value reverts if it was not set by some valid mechanism.

current feed value: This will be a simple function that calls the latest price value of Chainlink’s price feed.

peep(): Returns the next feed value (i.e. the one that will become the current value upon the next poke() call), and a boolean indicating whether it is valid.

In the context of Chainlink’s price feeds, this will return the same value as peek().

poke(): Updates the current feed value and reads the next one.

This function will trigger a new round of answers to be submitted by Chainlink nodes to the price feed. The diagram below shows how we expect the interaction between both systems to happen.


Moved to #oracles as I think this makes more sense in that category. Pinging @NikKunkel (of the oracle domain team) for attention.

Appreciate the thoughtful post @Johann !


Very interesting. Chainlink and Maker could be a dominant pair. Feeding Maker with real world payments via Chainlink brings many new dimensions to the Maker.

Feeding stocks as collateral to Maker loans is a good idea. One wouldn’t have to sell from a brokerage, move the money (+3-5 days), then buy ETH to offer up as collateral is too time consuming.


Personally I think this would be great integration for both Maker and Chainlink. I admit I’m a bit biased here, but really these are very complementary projects that could boost each other’s adoption (more DAI gets minted and feeds get more usage) and brings the two project’s communities together (sum greater than its parts). This could really be the beginning of something great in my opinion. Additionally from what I can tell on the technical side, this should be a fairly straightforward integration using proxy contracts to conform Chainlink’s methods and data structure to what the OSM supports and expects. If anyone has any questions about Chainlink on the technical side I’d be happy to help.


I appreciate you calling this out.

I’m not sure I follow how using Chainlink’s oracles leads to more DAI being minted. Could you expand on that point?

1 Like

LINK holders have historically dogfooded and bootstrapped the growth of Chainlinked protocols in DeFi, especially when it allows them to go leveraged long on LINK

Adding LINK as collateral on its own will generate some interest from linkes (free marketing from a passionate community as well), but if Maker used Chainlink’s LINK/USD oracle network, then we could potentially see the same growth that happened with Aave when they launched using Chainlink oracles (40% of Aave’s $67M total value locked is LINK being used as collateral in loans)

Vance from Framework Ventures gave his view here on how it creates a symbiotic community between projects


Cool, thanks for clarifying. I’m no slave the the efficient market hypothesis, but I would expect at least some of the demand for leverage to move to where leverage is cheapest, which Maker may be in some circumstances.

If I’m reading Aave’s dashboard correctly, there is less than 2M DAI borrowed, assuming the same statistic of 40% of that coming from LINK, that is not a large amount of DAI.

Obviously stuff like this is difficult to quantify, but as someone who is familiar with ChainLink and the community, could you offer any predictions as to the relative demand to mint DAI using LINK as collateral in the situations of:
A) Maker adding LINK as collateral without integrating Chainlink’s oracles.
B) Maker adding LINK as collateral and using the Chainlink oracle as a Lightfeed in Makers own decentralized oracle.
C) Maker adding LINK as collateral and using the Chainlink oracle as described in the initial post.

I guess I’m interested in quantifying how much of a difference this would make to the amount of DAI minted, and whether that trades off favourably against the negative impact on Maker’s own oracle initiatives.


My prediction should be A.
Maker adding LINK as collateral without integrating Chainlink’s oracles.

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.

1 Like

I am actually working on exactly that with a fellow community member :slight_smile:
Details many oracle projects, what’s the best way I can send it over once it has been reviewed and published?

1 Like

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.

I would love to get @Oracles opinion on the comparison once it’s presented.


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;

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:

  1. Adding collateral more quickly in times of stability (long-term growth) and times of crisis with the peg (fast responsiveness is key)

  2. Focusing its resources on the core problems of accelerating DAI creation, which is not the creation of an oracle mechanism and

  3. 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;

Increase Decentralization

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, the LINK/USD price reference data feed ( 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, 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 ( 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 ( and has grown to become the fourth largest DeFi protocol ( 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. (

Similarly, the Synthetix team was able to quickly launch many new unique products such as the FTSE 100 and Nikkei 225 synthetic assets ( 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 (

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 ( 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 ( 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; 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 ( 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 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 for nodes listing their details/jobs/adapters/price
  • Link to each node’s for exact data request history and job details

Below is an example of the ETH/USD price feed ( 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 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 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 ( 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)


(continuation of previous comment)

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 (, 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:

In addition to the initial whitepaper,, this additional research has been developed and supported by top academics like Ari Juels (, the former chief scientist of RSA and co-founder of IC3 (, a leading blockchain academic research institution.

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 ( 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.

1 Like

I think there is a good chance that analysis isn’t genuine. That said, it was quite an interesting read.

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
• Decentralization
• Network security
• Adoption from DeFi
• Onboarding of nodes
• Competition
• “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.

  1. 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.

  2. 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.

  3. 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.

Recommendation: Merge this proposal into MIP6 LINK Application.

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?