Oracles and Chainlink Basics

Analogy categoryAnalogies

The Oracle Problem

A blockchain is a deterministic, closed system: every node must independently re-execute each transaction and arrive at the identical result, so contracts cannot make HTTP calls or read anything outside their own chain state, because if they could, two nodes querying an API at different moments would compute different results and consensus would break. Yet most useful applications need external data: a lending protocol needs asset prices, an insurance contract needs weather data, a game needs randomness. This gap is the oracle problem: how to bring real-world data on-chain trustlessly without reintroducing a single point of failure.

🏏

Cricket analogy: It's like a sealed match-referees' room that cannot see outside, so to apply a rain rule they must rely on an official weather feed brought in, since they cannot look out a window themselves.

Chainlink Decentralized Oracle Networks

Chainlink solves this with a decentralized oracle network. Instead of trusting one server, many independent node operators each fetch the requested data from multiple sources, and their responses are aggregated on-chain into a single value, discarding outliers. Because no single node can move the reported value, and operators stake reputation (and in some designs tokens) on honesty, the feed is resistant to any one party lying or going offline. For common assets, Chainlink runs continuously-updated Price Feeds that any contract can read for free, refreshed whenever the price moves past a deviation threshold or a heartbeat interval elapses.

🏏

Cricket analogy: It's like DRS combining Hawk-Eye, UltraEdge, and multiple camera angles from independent vendors, where no single sensor decides and the aggregate ruling resists any one faulty feed.

Reading a Price with Data Feeds

To consume a Chainlink Price Feed, your contract imports the AggregatorV3Interface and calls latestRoundData(), which returns the latest answer along with metadata including the round ID and the timestamp of the update. Prices are integers, not decimals: ETH/USD is reported with 8 decimals, so a value of 300000000000 means $3,000.00, and you must call decimals() to scale correctly. You should also check that the returned updatedAt timestamp is recent, because a stale feed (one that has not updated within its expected heartbeat) may indicate a problem, and using its value could be dangerous.

🏏

Cricket analogy: It's like reading a required run-rate off the scoreboard: the raw number means nothing until you scale it by overs remaining, and you check it is the current over, not a frozen display.

solidity

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import "@chainlink/contracts/src/v0.8/shared/interfaces/AggregatorV3Interface.sol";

contract EthUsdPriceConsumer {
    AggregatorV3Interface internal immutable priceFeed;

    // Sepolia ETH/USD feed: 0x694AA1769357215DE4FAC081bf1f309aDC325306
    constructor(address feed) {
        priceFeed = AggregatorV3Interface(feed);
    }

    /// @return answer scaled by decimals(); e.g. 300000000000 == $3000.00 for 8 decimals
    function getLatestPrice() public view returns (int256) {
        (, int256 answer, , uint256 updatedAt, ) = priceFeed.latestRoundData();
        require(answer > 0, "Invalid price");
        require(block.timestamp - updatedAt < 3 hours, "Stale price");
        return answer;
    }

    function feedDecimals() public view returns (uint8) {
        return priceFeed.decimals();
    }
}

Never derive randomness from block.timestamp, blockhash, or block.prevrandao for anything of value, because validators can influence or predict these and manipulate outcomes. Likewise, never read a price from a single DEX's spot pool as an oracle: it can be moved within one transaction by a flash loan, enabling price-manipulation attacks. Use a decentralized feed and always check the price is fresh.

Verifiable Randomness with Chainlink VRF

Randomness is a special case: values like block.timestamp, blockhash, or block.prevrandao are visible to or influenceable by validators, so using them to pick a lottery winner or mint a random NFT trait is exploitable, since a validator could reorder or drop transactions to favor an outcome. Chainlink VRF (Verifiable Random Function) provides randomness with an on-chain cryptographic proof: your contract requests randomness, and Chainlink returns the random words in a callback (fulfillRandomWords) together with a proof that the value was generated from a pre-committed secret key and cannot have been tampered with. The two-step request/callback flow means you must handle the asynchronous response rather than getting a value inline.

🏏

Cricket analogy: It's like a coin toss that would be riggable if the home captain controlled the coin, so you use an independent verifiable toss; VRF is the neutral, provably fair toss no side can influence.

Chainlink Data Feeds are read-only and gas-cheap: your contract just calls latestRoundData on a deployed aggregator address, which differs per network and per asset pair. VRF and Automation, by contrast, require funding a subscription with LINK to pay node operators for fulfilling requests.

Blockchains are deterministic and isolated, so contracts cannot fetch external data directly, which is the oracle problem.
Chainlink uses many independent nodes that aggregate multiple sources and discard outliers, avoiding a single point of failure.
Price Feeds are read via AggregatorV3Interface.latestRoundData(); prices are scaled integers, so use decimals() to interpret them.
Always check a feed's updatedAt timestamp for staleness before trusting its value.
Naive on-chain randomness (block.timestamp/blockhash/prevrandao) is manipulable by validators and unsafe for valuable outcomes.
Chainlink VRF supplies verifiable randomness via an asynchronous request/fulfillRandomWords callback with a cryptographic proof.
Reading a single DEX spot price as an oracle is vulnerable to flash-loan manipulation.