Learn · season 04 · episode 12
Chainlink: where the price comes from
A lending contract needs a price to value collateral. An oracle brings external observations onchain, where contracts can read them. The source, publication time and consumer’s checks all matter.
Start with Aave lending for the collateral example. These are synthetic browser simulations, with no network calls or real funds.
How does a contract learn an outside price?
You will be able to explain why an observation, a published price and an application’s decision to use it are three different things.
First look · synthetic feed
A changed price must still reach the contract
Predict: if reporting stops, does the contract automatically know the new price? Step through an interruption.
1 · Observed outside
$2,000
An invented market observation
2 · Published on chain
$2,000
Updated 0 seconds ago
3 · Application’s age check
Passes age check
Maximum age here: 30 seconds
Publication: available.
Both prices start at $2,000. The contract can read a published answer with an update time.
Manual steps, invented seconds and one observation. This illustrates a push-based price feed, not Chainlink’s reporting protocol or Aave’s checks. Actual feed settings differ. A fresh answer can still be wrong.
What can go wrong: accepting old or incorrect data can misvalue collateral. Rejecting data can interrupt actions that need a price. Multiple sources can share the same error, so combining them is not a guarantee of truth.
Explain it back
A feed publishes a new answer just now, but all its sources copied the same wrong observation. Would a timestamp check catch the mistake? Explain what that check does and does not establish.
Compare your explanation
The timestamp shows when the answer was updated. It does not establish that the inputs were correct. A new answer can pass an age check and still misprice the asset; source quality and other application checks matter too.
Sources: Chainlink Price Feeds and developer responsibilities.
Explore aggregation, update triggers and consumer checks
01 · bring an observation onchain
A contract reads a published answer
A blockchain contract does not fetch an exchange website each time it runs. Oracle infrastructure collects outside data and makes an answer available onchain. Chainlink price feeds commonly combine data sources and independent node operators, although some feeds use a single source or calculated values.
01 · observations
Market data
Data providers obtain and process price observations.
02 · reporting
Oracle network
Operators contribute to the feed’s reporting process.
03 · publication
Onchain answer
An aggregator stores the published answer. A proxy provides the address consumers read.
04 · use
Consumer contract
The application reads an answer and applies its own checks and rules.
Sources: Price Feeds and the decentralized data model.
02 · combine observations
An outlier need not become the answer
The median is the middle value after sorting. This small experiment shows why aggregation can help with an isolated outlier, and why it still depends on the quality of the inputs. It is not a reproduction of Chainlink’s reporting protocol or a claim about any feed’s node count.
Move the observations
Synthetic median illustrationFive invented observations, sorted by price. The middle observation sets this model’s answer. Five is a teaching choice, not a Chainlink network size.
Sorted: $1,990 · $1,995 · $2,000 · $2,005 · $2,010
Median answer: $2,000
One extreme value does not move this example’s median. Three wrong observations do. Aggregation reduces some outlier effects; it cannot establish whether the underlying observations are true.
03 · wait for a publication
The latest answer is not a continuous price stream
For the push-based feed model shown here, a deviation threshold or a heartbeat can trigger a new reporting round. Deviation measures change from the onchain answer; a heartbeat measures elapsed time since the last update. The actual settings vary by feed. A trigger starts the process; an interruption can prevent a new answer from being published.
A trigger is not a published answer
Illustrative browser simulationA separate experiment, starting at $2,000. Assumed triggers: a move greater than 1% from the published answer, or 60 seconds since publication. Time moves only when you press the button. These are not a live feed’s settings.
Current deviation: 0.00%. Exactly 1% does not trigger this model. The next step evaluates both triggers.
Starting answer published at simulation time 0 seconds.
Dashed grey: observed scenario. Solid teal: published answer. Last 31 steps shown.
- Published answer
- $2000
- Published at
- 0s
- Simulation time
- 0s
- Answer age
- 0s
Example consumer: age check passes
0 seconds old ≤ 90-second policy. This consumer accepts equality and rejects older answers. Passing this one check does not prove the price is correct.
Read recent steps as a table
| Time | Observed | Published |
|---|---|---|
| 0s | $2000 | $2000 |
Try an outage for 100 seconds with a 90-second consumer limit. The heartbeat is reached, yet the old answer becomes too old to use. Restore publication and advance once to publish again. Successful rounds are immediate in this model; real networks have reporting and transaction delays.
Reference: Chainlink’s update triggers. This experiment compresses reporting into manual ten-second steps.
04 · decide whether to use it
The timestamp is part of the answer
The feed interface exposes the answer and its update timestamp through latestRoundData(). An application must understand the feed’s units, decimals, market coverage and update behavior, then decide whether the data is appropriate to use.
The consumer’s maximum age is a separate policy from the feed’s heartbeat. A limit that is too short may reject ordinary intervals between updates. A limit that is too long may accept an old answer after conditions have changed. The age check in this lesson is only one simplified check, not production integration code or Aave’s oracle policy.
Sources: Data Feeds API and developer responsibilities.