LibraryData and agents2017Design paperCorpus record
Chainlink: A Decentralized Oracle Network
Chainlink. Steve Ellis, Ari Juels, Sergey Nazarov.
The 2017 Chainlink paper: a network of independent nodes that fetch off-chain data, aggregate it, and deliver a signed result on-chain, with a reputation and penalty story around the nodes. It is the reference design for 'the contract needs a fact from outside'.
Chainlink's paper answers a narrow question: how a contract can receive a fact from outside its chain, from a committee of nodes that fetch, aggregate and sign, instead of from one operator typing it in.
The five-minute read
Contracts are blind
A contract can see its own state and the messages it is sent. A price, a shipment, or a sports result is not in that set. Someone must carry the fact across.
The paper distributes the carrying
A requester names a query and a service level. Several oracles fetch. An aggregating contract posts one answer. The design is a committee, not a single signed price.
Deposits and reputation are the incentive story
The paper wants lying to cost a deposit and a future stream of jobs. That only works if the fault can be identified and the marketplace for jobs is real.
The on-chain half is the easy half to audit
Aggregation, deviation thresholds and who may submit are visible. The fetch, from a website or an exchange, happens off-chain. The paper cannot make a website honest. It can make several fetches disagree in public.
A feed is not a proof of the world
The result is that a committee said a number at a time. Downstream contracts that treat it as a physical fact have adopted the committee as an oracle, which is the ordinary meaning of the word.
One action, walked through
- A requester posts a query: the source, the path, and how many oracles they will pay for.
- The assignment process, using reputation in the paper's design, selects nodes.
- Each node fetches the source off-chain and submits a signed answer on-chain.
- The aggregating contract drops outliers or takes a median, under the job's rules, and publishes one result.
- A contract that was waiting on the result proceeds. If the answers scattered, the job's stated policy decides whether to halt or to publish anyway.
The argument, unpacked
Decentralised is a count of fetchers
Three nodes reading the same compromised website will agree on the wrong number. Independence of sources matters as much as independence of node operators. The paper's architecture allows multiple sources. A deployment that points every node at one API has spent the architecture and kept the single point of failure.
Reputation needs a loss that can be booked
If bad answers cannot be distinguished from awkward truths, deposits cannot be slashed without a political decision. The paper is strongest for facts a later public event can score, and weakest for facts nobody else will ever confirm.
The oracle is now inside the threat model of every consumer
A money market that trusted a manual poster used to say so. A money market that trusts a feed should still say so. Chainlink's contribution is to make the committee explicit. It is not to remove trust. It is to name it.
What has to be true
- Enough independent operators actually run the job. A feed with one responder is a single oracle with extra steps.
- Sources can fail or lie. The aggregation policy has to say what scatter does.
- Payment for the job continues. An unpriced feed is a volunteer dependency.
- Consumers read the aggregated result, not a single node's answer in the mempool.
What happened after the paper
Chainlink became the default price relay for a large share of on-chain markets, and later added off-chain reporting to cut gas. Those deployments are narrower and more operational than the 2017 marketplace sketch. The paper is still the right diagram of request, committee, aggregate. A live feed's operator set and source list are the facts that decide how much the diagram is worth.
What to check before you use the idea
- How many oracles, and how many distinct sources, stand behind this feed?
- What does the aggregator do when they disagree?
- Who pays, and what happens when payment stops?
- Does the consuming contract treat the number as a fact or as a committee's report?
Terms
- Oracle
- A party, or a committee, that carries an off-chain fact into a contract.
- Aggregator
- The contract that turns many signed answers into the one result consumers read.
- Deviation threshold
- A rule for when a new answer is different enough to be worth publishing.
- Reputation
- The paper's record of a node's past jobs, meant to change who is hired and who is slashed.
The problem the paper names
A contract that pays on a price, a shipment or a sports result cannot see those facts. Whoever types the fact into the contract is a trusted party. Chainlink's paper distributes that typing across a committee with deposits and a stated aggregation function.
What the design proposes
- A requester specifies a query and a level of service.
- Selected oracles fetch, and an aggregating contract posts a combined answer.
- Reputation, deposits and the assignment of jobs are how the paper tries to make lying expensive.
How the mechanism is specified
- The on-chain contract does not know the world. It knows the aggregator's output and the identities that signed.
- Off-chain adapters are acknowledged as necessary, because most data does not start on a chain.
- The paper's security is the committee, the aggregation and the incentives. A single feed run by one operator is a narrower object than the paper describes.
What this page does not treat as proven
- An oracle network does not make a fact true. It makes a reported fact attributable.
- Later Chainlink functions, cross-chain products and staking designs are not the 2017 text.
- We do not describe node income.
Why a venture studio still reads it
Every settlement, insurance and agent-commerce venture on this site eventually needs an external fact. Chainlink is the paper that forces the fact to be a specified query with a named aggregation, rather than 'we will get the price from somewhere'.
This is Blockchain Lab's reading of a public design paper. It is not the paper, not a copy of it, and not an offer of tokens, equity, custody or a partnership. Later network behaviour can diverge from the text. Nothing here is investment, legal or technical advice.
Research status: Design paper. Last reviewed: 1 October 2026. This is a reading of a public paper, not investment, legal or security advice.