Whitepapers Deconstructed: Chainlink

I’ve written this article with the aim of providing a concise summary of both Chainlink whitepapers, bridging the gap between introductory articles and the intimidating original papers. While being fairly comprehensive, I’d strongly encourage anyone wanting a more detailed understanding to check out the original whitepapers and smart contract research forum.


The vision of Chainlinks founder Sergey Nazarov, was to redefine the blockchain industry, by allowing the creation of Hybrid Smart Contracts (HSCs). HSCs are smart contracts with a hybrid infrastructure, having transaction settlement on-chain and contract computation done off-chain. The HSC framework will maintain the security and reliability of a blockchain, while having performance benefits of off-chain computation while removing the external data limitations. This has already allowed decentralised financial products to be built (DeFi applications).

Background On Smart Contracts

Security: Existing on a distributed network, the smart contract is immutable and has no single point of failure that is vulnerable to an attack.

Reliability: Once deployed, the smart contracts automatically executes commands under the conditions programmed.

Transparency: The conditions of the agreement are transparent and cannot be altered, removing a requirement of trust between two parties.


However, this solution introduces a second issue. Using a single oracle to gather data from a single source nullifies the decentralised property that comes from a decentralised blockchain. There are single points of failure at the oracle and data source levels, which is the second piece of the oracle problem. An oracle must maintain the key security and reliability properties, Chainlinks solution is a Decentralised Oracle network (DON).


Chainlink Architecture

On-chain: The first on-chain component is USER-SC, the smart contract made by the user which broadcasts requests for data and stores the returned value. The second is CHAINLINK-SC, which is the smart contract that acts as the interface between USER-SC and the Chainlink DON. CHAINLINK-SC calls three further smart contracts; The order-matching contract contains the data and reputation requirements set by the user, and orders a network of suitable oracles to fulfill the task. The aggregating contract collects data provided from the oracles and returns the median value to USER-SC. The reputation contract updates a reputation metric to track performance of an oracles, based on data accuracy and response time. It is extremely important for the Chainlink ecosystem to have a record of oracle behaviour.

Chainlink: The off-chain component are the the individual oracles run by operators that make up Chainlink DONs. They accept suitable data requests on-chain, obtain data through an API call from their external data source(s) off-chain, then submit it on-chain through a transaction.

External: These are the external data sources that oracles gather their data from. Oracles pay for data licenses in order to access these, ensuring the original data is of high quality.

Off-Chain Reporting (OCR)

As discussed in the oracle problem section, an off-chain aspect to the Chainlink DON introduces a vulnerable point of failure. The OCR protocol is designed to be Byzantine Fault Tolerant (BFT), meaning it can continue to function correctly with a proportion of up to 1/3 of nodes potentially becoming either faulty or malicious. There are three subprotocols in the OCR design;

Pacemaker: The pacemaker is the underlying protocol that drives the report generation process. It continuously runs and acts as a timer that initiates new epochs of the report generation protocol, with each epoch having a random node act as the leader. If insufficient progress is made in the specified timeframe, it will be aborted with a new report generation instance and leader.

Report Generation: The report generation protocol is the process of nodes in the network communicating to arrive at a signed report of data values to be sent to the blockchain. It is a BFT consensus algorithm, meaning the protocol can continue to function correctly even if up to 1/3 of nodes are faulty or act maliciously. These nodes are known as Byzantine Nodes.

The process starts with the leader node making a request for follower nodes to gather data, and compiles responses into a report. There are several rounds that progress when the protocol gathers sufficient signed observations from nodes, ultimately guaranteeing at least one honest node confirms to the validity of the final report (assuming <1/3 are byzantine nodes).

Transmission: The transmission protocol is the algorithm responsible for transmitting the final report from the oracle to the smart contract on the Ethereum blockchain. To avoid excessive transactions, the reports are only submitted if a specified amount of time has passed, or if the price value has changed beyond a threshold since the last report. The selection of oracle(s) to submit on-chain is randomly chosen from the network of nodes.

Chainlink Services

Verifiable Randomness Function (VRF): Decentralised applications (DApps) that utilise smart contracts may require a source of randomness to ensure fair operation. Chainlink VRF service generates a random number which can be verified by users through a corresponding cryptographic proof, allowing for transparent randomness. Use cases include blockchain games such as lotteries and NFTs generation.

Keepers: A limitation of smart contracts is that functions can only be triggered when on-chain conditions are met, requiring an external call to trigger at an arbitrary time or condition. Chainlink keepers provides a decentralised, high-uptime, low-cost option for contract authors to outsource smart contract upkeep, instead of creating their own off-chain infrastructure to do so. Use cases include executing limit orders from a decentralised exchange and liquidating undercollateralized loans. A practical example could be; “If account balance is below $50 USD in ETH, then top it up with ETH from this other account.”

Fair Sequencing Services (FSS): In permissionless blockchains miners have control over which transactions go in a block and how they’re ordered. A miner can exploit this through Miner Extractable Value (MEV). MEV occurs when a miner creates a profit through reordering and censoring transactions, coming at the cost of the user. This comes in the form of front-running, back-running and sandwich attacks. Chainlink FSS aims to create order fairness by approximating a first-come first-serve system by decentralising transaction order, resulting in a more equitable financial system.


DON Operator Corruption (Cryptoeconomics)

Staking: Staking is an explicit incentive, where node operators must deposit locked assets in the form of LINK tokens, which can be confiscated for misbehaviour. Chainlink staking is founded in game-theory and hinges on an idea called watchdog priority.

Each oracle gets the opportunity to act as a watchdog and raise an alert if they believe an aggregate report to be incorrect. When an alert occurs the reporting decision is escalated to a second maximally-reliable oracle network, consisting of nodes with only the highest reputation scores. Escalation should be a rare event and therefore the second-tier network can be highly compensated. A correct alert will result in the highest priority watchdog receiving the sum of staked LINK of corrupt nodes that delivered false data, however will forfeit their own stake if it was proven to be a faulty alert. This results in a super-linear staking effect:

Future Fee Opportunity (FFO): FFO is an implicit incentive. Misbehaviour by an oracle node also jeopardises the future share of fees earned by providing their services, penalising the node with an opportunity cost in terms of potential lost revenue from network participation.

Systemic Failures

External Data Source Trust Minimisation:

Even among high-quality (subscription model) data sources, few digitally sign the data they provide. Chainlink aims to accelerate the use of digital signatures by creating a capability for Chainlink nodes to function as an authenticated API front end for external data sources. This capability is referred to as Authenticated Data Origination (ADO), and will help strengthen the end-to-end integrity of oracle reports.

DON Trust Minimisation

Software monoculture occurs when all systems run identical software (such as Chainlink nodes), meaning a vulnerability subjects the network to a catastrophic failure in the event of a successful attack. Chainlink has two main contingency options if such an event were to occur:

Failover clients: Failover clients acts as a second line of defence as a form of software diversification. Nodes are able to switch to a secondary client in the face of an emergency, reducing the dependence on the primary client. For example, nodes running OCR as the primary client also support the previous FluxMonitor client, which has had field testing over a longer period of time.

Minority reports: In the event that honest nodes make up a minority of the network, a minority report is an option to flag the smart contract on-chain. The smart contract has its own polices as to how it responds to these, such as a circuit breaker.

Guard Rails

Guard rails are on-chain failsafe mechanisms that protect the smart contract against failures in the off-chain components of Chainlink. Smart contract owners specify the conditions under which they trigger. For example, a Circuit Breaker can pause updates to the smart contract. In an emergency an Escape Hatch can temporarily shut down the smart contract in some manner and/or temporarily terminate pending transactions.

Chainlink Events

Finally, a quick shout out to Patrick Collins for having awesome content, definitely helped me during my research, check him out: