Research Summary: Chainlink 2.0: Next Steps in the Evolution of Decentralized Oracle Networks

There are a lot of pretty weighty implications here and I’m still processing some of them. Might be helpful to discuss some of the potential use cases we can think about. Having trouble narrowing them down, or perhaps the space is too wide to pigeon-hole?

In the Applicability section above it says DONs can service blockchains and layer-2 networks. Are there bright lines between the role of an L2 and a DON? It seems like a DON could be considered a bespoke, temporal L2.5… Is that accurate?


Cheers Eric, lots of information we knew from before (VRF, Fair sequencing), but the whole section 9 is new, things like super-linear staking and alerts, not to mention that somehow Chainlink whitepaper is full of my name :-) (DON). Hopefully Linkpool will fit nicely into the whole staking proposal.


Congrats on this, seriously. Looking forward to reading more about super linear staking and looking into the code as this is developed.


Does this imply that DONs can act as an abstraction layer between chains? Can this be interpreted as a cross chain bridging solution? If so, how is custody handled in this model?


I’m curious about the guard rails, and how to ensure data integrity. Can anomalies be detected externally or is the committee responsible for slashing outliers? Are there any special hardware requirements for running a DON? Does it require an enclave or TCE?


Welcome to SCRF, @Granit23! You mentioned you’re looking forward to looking into the code. Is there anything in particular that you’re looking for or that you’re looking forward to making use of?


@jmcgirk this is a great question and it actually relates to one @Zach and I discussed a bit in the Off-Chain Reporting post about data integrity. During our conversation, @Zach summed up the idea of how data is ensured to be correct by stating the importance of staking:

I see explicit staking as a key aspect of scaling up network security in the medium to long term, particularly when the underlying smart contracts consuming this data begin to secure increasing amounts of value.

Chainlink 2.0 explicitly discusses how staking will be used as a way to ensure the data being reported by nodes is correct in section 9.4. Specifically, I want to draw attention to section 9.4.1 Further Mechanism Details starting on page 89.

Using the new bribery-resistant system all nodes will need to stake two different deposits; a deposit that can be slashed if disagreements are found and a “watchdog” deposit. This watchdog deposit seems to be a key aspect of ensuring data reported on DONs is accurate and correct. Essentially, this watchdog amount acts as a type of bounty for nodes to find and successfully report data errors being reported by other nodes.

If we look at Figure 16 we can see the general idea of how these staking deposits can be used to ensure data is reported properly, or how nodes can be rewarded if they report faulty data/incorrect nodes.

The figure shows that anyone attempting to maliciously influence other nodes to upload incorrect data must pay more than that of the potential rewards any one node may receive if they were to successfully report the malicious act/incorrect data. This economic incentive makes it so any purposeful data manipulation should be extremely expensive, and economically incentivizes nodes to report such instances.

In the comment chain I reference above regarding the security of OCR data, I purposed the idea that industries may come together to collude and provide false data in OCR reports. This specific bribery-resistant staking mechanism seems to address this issue, and helps ensure the data being uploaded is correct and accurate.

@Zach I’d love to hear your thoughts on the matter as well.


Thank you for the break down @Sergey! The cryptoeconomic security section is especially interesting to me given an adversary needs not just slightly more than the combined deposits like most staking implementations, but a budget quadratically greater amount of funds (as a function of the number of nodes) to successfully subvert a DON.

@tjd233, you are mostly correct here with your analysis in regards to significantly raising the cost of attack preventing data manipulation, but slightly off in regards to the watchdog deposit. The watchdog deposit is only slashed if an invalid alert is a created by a node (e.g. claimed the aggregate report was false when it was actually true). This prevents DoS attacks and false-positives from occurring. The regular stake a node deposits is what is slashed if they deliver false data (this stake is significantly greater than the watchdog stake).

Even more specifically, if the majority of nodes report a false data, then all those malicious nodes have all of their primary stake slashed. If only a minority of nodes report false data (and therefore doesn’t affect the final report), then they are only modestly slashed (e.g. 10x what their fee payment would have been, much less than their entire stake). This is conceptually similar to Ethereum 2.0’s staking mechanism where a large coordinated attack generates a larger penalty than when just a few nodes are wrong (which likely happens because of a configuration issue or honest mistake).

This incentivizes an even greater amount of stake to be deposited as nodes know if they have an isolated failure, then they will recoup the losses within the day, however if they become malicious and try to manipulate the final oracle report, then they will experience a significant economic consequence. It’s pretty brilliant in design and lead to greater decentralization of the network as a whole.


Thank you very much for this breakdown, and congratulations to all contributors to the whitepaper. One can only be satisfied with this novel approach at staking, which seems to solve the sybil attack problem in an adequate fashion. I was wondering who will pay the fees on the transaction in case of a slashing event, as this might happen during times of high gas prices and as such could influence the profit that the slashing event can generate for a succesful alert.


Massive congratulations to the Chainlink team on this monumental step towards mass adoption of hybrid smart contract technology and a fairer world for everyone.

We’re all in this together!


A bit of a general question for those who read/worked on the v1 and the v2:
what changed the most from the initial vision? What did you learn from the live network that affected that vision?


In the current architecture of Chainlink’s price feeds, the participants of the oracle network contributing to each price feed are predetermined and fixed. Questions that come to mind when I consider the impact of shifting Chainlink to what I think can be described as “offchain-computation-as-a-service” on a product such as price feeds:

With a shift to a DON architecture, what does the ETH-USD price feed look like in the future?

Will a DON still report a feed into an on-chain contract, as is the case today? Is it possible that a hybrid smart contract could abstract this function to fully offchain?

Is the DON reporting this data static? If no, how composable is the DON to requester requirements?

If there is a shift away from using a static DON toward a dynamically composed DON - or even a randomly composed DON - for a given job, how do you handle the selection of DON members and distribute the work?

It seems that the ultimate goal of this metalayer approach is to develop a network of nodes that perform a suite of offchain computations in both reactive and proactive service verticals. This approach implies that a component of the metalayer will be a data structure which acts as a foreman of sorts (possibly a structure that would live on the DON of DONs layer, a concept discussed briefly), tracking individual oracle capabilities/suitability to be included into a spontaneously-composed DON.

I am excited to see the ideas outlined in the paper begin to be implemented. I think the metalayer is necessary and elegant. Congrats to all involved.


Thanks everyone for your congratulations and support around this expanded vision for Chainlink, we’re all really excited about it.

@rncd thanks for your thoughtful points and questions.

I think the long term future of price feeds will likely be driven by the DON’s users and their requirements to both continue using the DON and around whether they are willing to pay additional fees to the DON for greater security. I expect DONs will evolve based on two key factors; the need to provide additional security as the value secured by them continues to grow, and the ability for the DON to provide additional functionality that the users of the DON would find useful. Part of what Chainlink achieves is the creation of an efficient on-chain marketplace for very specific user demands about what a DON should do, and the ability for DONs to cater to those demands in an increasingly flexible, secure and privacy preserving manner, with consuming contracts having a guarantee of performance and node operators having a guarantee of payment for performance.

Selection of DON members is made easier in Chainlink through the on-chain reputation generated by them, which services like and already display some information for. Part of Chainlink’s unique value for generating DON’s is its ability to compose them based on the immutable proof about past performance retained around specific node operators.

The chainlink network is a complement/enabling technology for blockchains and L2s that house the smart contract code which needs to interact with key resources off-chain. Chainlink will continue to enable other blockchains and L2s, in order to expand the functionality of the smart contracts that operate in those environments.

I also think that DONs will place data into web 2.0 systems that require hyper reliable oracle reports to trigger events that they consider “mission critical”; events that need to be tamper-proof based on the value of the outcomes they secure. I do believe that polishing a system like Chainlink into something that meets the stringent requirements of Web 3.0 systems, will also make it attractive to Web 2.0 systems that have a similarly intense need for highly reliable off-chain computation and/or validated data delivery.

I also think the metalayer is necessary and will enable a redefinition of what blockchains are known for by enabling developers to easily create hybrid smart contracts.

Please note, beyond clarification of how existing features already work, all of my posts on SCRF are just one person’s opinion, stated here to engage in a dialogue with the larger research community, in an effort to test and improve my personal point of view. Whatever I write here is not a definitive statement about how Chainlink will evolve, which will be based much more on what we discover in working with actual smart contracts. I am excited about having an open creative dialogue, in order to arrive at a clearer and more accurate picture of reality.


I think the implications of the metalayer have been mostly glossed over in discussions so far. The “restructuring” of Chainlink’s existing and under-development services into this new organization, and the expansion of the software framework supporting them, imply a fundamental change in the way that existing layer 1/2 solutions will interact with the network.

I think this describes the idea of the future metalayer best. Thinking aloud: So what happens when all of these node services, job initiation mechanisms, DON administration/clerical work, are consolidated into a unified new architecture? What does that look like? What does that mean for users of the network? How does it change how they interact with the network? What does scaling the metalayer imply?

Let’s assume that the Chainlink metalayer handles millions of transactions per day of varying types, pushing/pulling data to legacy systems and blockchains through native metacontracts, and opening and closing thousands of what I will call tickets - a future version of an ad-hoc job request. Clearly, the ticket administration aspect of this process will have to be automated. What component of the metalayer is responsible for self-organization? I will call this component the Overseer.

Imagine a hybrid Ethereum contract in which the offchain computation instruction component specifies a series of requirements for a DON job. The Overseer would be responsible for receiving and reading the ticket from the offchain component of the hybrid contract, handles the genesis and assembly of the DON, the distribution of the required instruction, and the dissolution (if necessary).

When I look at the staking diagram for the escalation of watchdog alerts, I see some of these same Overseer ideas reflected - where nodes act as administrators for others. So what would an Overseer consist of? It could be an application running on a set (or maybe superset) of nodes in the metalayer. It seems it would need a ledger or database containing information about itself in order to assign work correctly and respond to tickets.

I am making all of this up, but it is fun to think about autonomous distributed systems like this.

Ultimately, what I see being described in this paper is just that, a semi-autonomous blockchain accessory layer that performs a suite of offchain computation, data processing, and transfer services. If I had to bet on it, I would say that this metalayer evolves into a blockchain-like system.

Another thought: The description of assets at stake by a given node operator, $S≈$D+ $F+ $FS+ $R, may fall short of capturing the complete incentive picture of a metalayer node. There are separate classes of behavior within a node’s operational remit that in theory could affect a node’s incentive-based security. An example is a node providing FSS services in addition to participating in a price feed DON. Is FSS a tool that should be included when considering incentive-based security? Does a node’s participation in a given service such as FSS affect the way that incentive-based security should be considered for other services the node participates in? Fun questions to think about.


I’m so excited coming to layer 2 such as Optimistic Rollups, Polkadot, Binance Smart Chain, Polygon(Matic layer 2 solutions), Avalanche, etc. Bringing Decentralized Oracle Networks(DON) to build up a new era of the Chainlink ecosystem.

I also think that Chiainlink 2.0 committee-based BFT consensus protocols need more discussion about the governance by algorithm especially the detail in the open and fair information transparence.


Congratulations to the Chainlink team, I am very excited about the work being done and the clearer path for the future. =]


Hi @rncd, I think you bring up some good questions around the long-term vision of creating a decentralized metalayer. Such a layer of abstraction appears to consist of the collective sum of all the independent DONs, where each can be constructed to serve a particular use case. A hybrid contract can use the services provided by existing DONs, as well as launch their own DON, to meet their specific requirements. So in my opinion, it seems scaling the metalayer would entail launching additional DONs to provide more services for a larger collection of users.

By extending this definition of oracles, a metalayer really goes beyond data delivery to include any other capabilities that blockchains do not. A DON itself could operate in an entirely autonomous manner, such as reading the mempool for transactions and automatically fulfilling jobs as needed. Each DON could therefore have its own Overseer to change network parameters or automatically process requests using the original deployed design.

On the point about the incentive-based security and FSS, nodes who participate in DONs may provide a wide range of oracle services. I believe these diverse services can be taken into account with Future Fee Opportunity (FFO) within the Implicit Incentive Framework (IIF) where additional cryptoeconomic security is derived from the fees generated from providing oracle services. So the more services a DON node provides, the greater the amount of fees it can generate, leading to greater cryptoeconomic security as a whole. It would be interesting to see this quantified for each specific oracle service a DON could provide.


Incredible stuff everybody, really grateful to read all your thoughts.

For some additional reading on the capabilities of Chainlink, oracles in general, and their roles in blockchains and other systems:

Works like @tina1998612 summary of Liu, Bowen, and Pawel Szalachowski’s “A First Look into DeFi Oracles” provide us a snapshot of what the oracle landscape looked like in late 2019, and as somebody who works on the team of one of the oracle node operators mentioned in this work, I’m personally humbled to see how far we’ve come since then. @abdeljalil.beniiche’s summary of his paper, “A Study of Blockchain Oracles” and @andy’s summary of “Blockchain Oracles: A Framework for Blockchain-Based Applications” (Mammadzada, et al.) provide us useful frameworks for assessing the implementations of a given oracle, and the scope of their utility.

@Zach penned a lovely summary of the original Chainlink Whitepaper, which was written nearly 4 years ago. It’s exciting to look back and see what from that original vision has been executed, and how the scope of the capabilities of blockchain oracles has expanded.

  • The Mixicles Research Summary identifies how oracles can be used to enhance privacy and confidentiality in smart contracts while preserving auditability
  • The DECO Research Summary describes how oracles can be used to securely access sensitive data and execute smart contracts based on that data, without exposing it to the oracle or to other observers using existing TLS infra
  • As more offchain assets are used as collateral for onchain loans or other activities (See Maker’s collaboration with Centrifuge, allowing users to draw down DAI loans from real estate collateralized tokens) services like Proof of Reserves provide a valuable primitive for reliably reporting the supply of a given asset to its onchain, tokenized counterpart.
  • Chainlink’s Off-Chain Reporting Protocol (OCR) provides a nearly 90% reduction in gas costs for a network of oracle nodes to push a data point onchain, and provides the ability to scale the number of nodes in a network at a much lower cost than previous iterations.
  • Zach’s recent post, The Economic Scalability of Oracle Networks directly explores the positive effects of multiple users utilizing a given network of oracles.

Robust oracles are directly tackling big problems today, notably of course oracle exploits/flash loan attacks. MEV, Front-Running, etc are potentially problems oracles can tackle as well, and that’s discussed a bit further here. For more background on MEV, see SCRF Lead Researcher @Vishesh’s Research Summary of Flash Boys 2.0 (Daian, et al.)


5 posts were split to a new topic: Governance, Oracles and AI

I have read this white paper and thought it was a very excited idea, but I have a question about DECO.

Question about the 2 party computation (2PC) for computing kP^mac and kV^mac in the DECO paper (Fan Zhang et al., ACMCCS 2020, we checked the arXiv version ([1909.00938] DECO: Liberating Web Data Using Decentralized Oracles for TLS))).

My question is how to implement F_2PC^hs in the actual DECO protocol. In Figure 6, the prover P and the verifier V respectively send zP and zV to F_2PC^hs that computes kP^mac and kV^mac. But F_2PC^hs is described as a trusted third party (TTP) because it receives secret values zP and zV, computes z=zP+zV, derives k^mac via PRF with z as the key, and divides k^mac into kP^mac and kV^mac such that k^mac=kP^mac + kV^mac. It seems assuming TTP is not a reasonable solution. I guess that a secure 2PC protocol is employed but no explanation is given as for as I checked the paper.

DECO is the core of Chainlink v2.0, so it is an area of great concern.