Using Chainlink Oracles for LINK-USD

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.


I wish I could double like this.


Couldn’t agree more with this. LINK’s centralization is against the spirit of Maker’s decentralized governance, but I do support the idea of Chainlink applying as a light feed to the Maker Oracles.

1 Like

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 contract with 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.

From a recent presentation on cryptoeconomic security


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

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

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

Please see here for more details:

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 page, and/or digging even deeper into them on e.g. is a good example of a well run node operator, who also has their Keybase verification attached to their node; 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 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; and additional papers on oracle security;, 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; To be clear, a large percentage of our networks did perform as needed and did allow our users to continue operating properly.

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

Is Chainlink intending to submit a MIP10c14 application?

1 Like

Considering another critical oracle failure just occurred during the latest crash, as no adequate solution has been implemented since the previous similar issues, I would like to see updates regarding this highly needed integration!

1 Like

As commented in this other discussion, there are no indication of a critical oracle failure.


Doesn’t Maker essentially already utilize Chainlink?

No that’s not the case. You don’t seem to understand how Maker’s Oracles work at all.


Can you explain more? What exchanges does Setzer have access to? This doesn’t seem to be published anywhere.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.