Oracles

In brief

Smart contracts cannot fetch arbitrary off-chain APIs without breaking deterministic consensus. Oracles source, verify (to some standard), and post external data — or send on-chain results outward. Designs range from one operator, to aggregated networks, to optimistic disputes, to protocol-native prices such as a Uniswap TWAP. The oracle problem is trust in that external information: correctness, availability, and incentives. Spot prices on an AMM during a transaction are especially easy to shove around. An oracle is not a crystal ball.

Why the chain cannot “just look it up”

ethereum.org’s oracle documentation starts from determinism. Every honest node must get the same result from the same inputs. If the input is “call this website now,” two nodes can see two prices, or a timeout, and disagree about the next state.

So contracts are limited to data already in state: balances, storage, logs, and whatever earlier transactions wrote. An oracle is the application that takes off-chain information and stores it on-chain (or, less often, pushes on-chain events to the outside world). After it is stored, nodes replay it like any other state.

That is why Batch C’s Smart contracts article said contracts cannot freely fetch the weather.

What an oracle actually does

Typical pieces (ethereum.org):

• a requesting contract (the user of the data);
• an on-chain oracle contract that records requests and answers;
• off-chain nodes that read APIs, exchanges, or instruments and send a transaction back.

Patterns:

• Publish-subscribe / feed. A regularly updated value (ETH/USD) that anyone can read.
• Request-response. A one-off query (“who won?”) that is too bulky to keep streaming.
• Input vs output vs compute. Bring data in; send a result out (unlock a door); do heavy work off-chain and post a result.

Push means oracle operators submit updates on their schedule or when a condition such as a heartbeat or price-deviation threshold fires. Chainlink Data Feeds are a concrete example: an aggregator stores reports, and a proxy points consumers at the current aggregator so the implementation can be changed.

Pull means a caller supplies a recent update when the application needs it. Pyth’s documented model has publishers submit prices to an oracle program on Pythnet, which produces an aggregate price and confidence interval. A caller fetches a signed update from the off-chain Hermes service, submits it to the destination-chain Pyth contract, and then reads it. The contract verifies the update’s provenance and age rules; that does not prove the market observation is objectively true.

Price feeds

DeFi’s usual oracle is a price. Lending, perps and stablecoin vaults need a number to decide collateral and liquidation.

Sources can be:

• off-chain CEX and index APIs, aggregated by a network;
• on-chain DEX reserves or TWAPs;
• a hybrid (an off-chain feed that secretly follows an on-chain pool — samczsun’s Synthetix MKR case).

Aggregation (a median, trimmed mean, or another stated rule) reduces the impact of one bad source. It does not create truth. If every publisher ultimately observes the same illiquid venue or the same vendor, they can fail together. Pyth’s primary docs illustrate a more explicit output: publisher prices and confidence intervals are combined into one aggregate price and an aggregate confidence interval, which widens when publishers disagree.

Update mechanisms matter: heartbeat (update at least every N hours) versus deviation threshold (update if price moves X%). Chainlink’s feed documentation tells integrators to check updatedAt / latestTimestamp and to set their own min/max sanity bounds. Stale data is a first-class failure.

Centralized, networked, optimistic, local

One operator. Fast, clear blame, single throat to choke. ethereum.org: no independent check that the number is right; availability is that operator’s uptime; incentives to stay honest may be thin relative to the value secured.

Decentralized oracle networks. Several nodes observe sources and agree off-chain or on-chain before posting one aggregate. Independence must be checked at both layers: ten nodes using one vendor are not ten independent sources. Chainlink documents Offchain Reporting and a consumer/proxy/aggregator split. “Decentralized” here is a spectrum: who selects nodes and sources, who owns the proxy, and who can upgrade the aggregator (Chainlink documents a multisig owner). ethereum.org also describes Maker-style Schelling / medianizer networks and staking/voting on answers.

Optimistic oracles. UMA’s documented design lets a proposer post a resolution with a bond. Anyone may dispute it during a challenge period; undisputed proposals settle, while disputes go to UMA’s Data Verification Mechanism, where stakers vote. The trust assumptions therefore include the resolution rules, bond and challenge settings, active disputers, and the voting backstop. This is a different latency and monitoring profile from a continuously refreshed price feed.

Application-specific / protocol-native. Uniswap v2’s accumulator lets other contracts read a time-weighted average price. It is not “Chainlink.” It is also not a spot tick. samczsun and the Uniswap v2 paper both warn that spot reserves during a transaction are a toy for attackers.

Not every DeFi app uses the same network. Compound historically documented an Open Price Feed. Some protocols mix feeds. Some should not have used a pool spot price at all.

What goes wrong

samczsun’s 2020 essay is the independent beginner text:

• Off-chain feed errors. One source reports KRW 1000× high; the aggregate accepts it; a bot trades (Synthetix, 2019).
• On-chain spot manipulation. Trade the pool, read the inflated price, borrow or mint against it, trade back — often in one transaction with a flash loan. Reading a scale while someone is jumping on it.
• Hidden on-chain dependence. An “off-chain” feed that actually tracks Uniswap.
• Unlabeled oracles. A vault that prices itself off Balancer redeem amounts can be inflated mid-transaction (yVault example in that essay).

Other beginner failures: stale heartbeats in a crash; thin markets with little arbitrage; latency so liquidations fire on a number the market has already left; coverage gaps (the feed exists for ETH/USD, not for the farm token you listed). Pull integrations can also fail if the caller supplies no fresh update or applies an unsafe age threshold; Pyth provides a getPriceNoOlderThan path that rejects prices older than the application’s limit.

Oracle extractable value (OEV) is MEV around the update itself — especially liquidations that become possible the moment a new price lands. Chainlink now documents SVR feeds aimed at recapturing some of that; the existence of the product is evidence the problem is real, not an endorsement.

The oracle problem

ethereum.org’s three tests:

1. Correctness — authenticity of the source and integrity in transit.
2. Availability — the feed is there when the contract must act.
3. Incentive compatibility — reporters can be blamed and paid or punished.

No design scores a perfect 3 in every market. A contract that “uses an oracle” has chosen a trust model. It has not escaped trust.

What this article is not saying

Oracles do not make off-chain data objectively true. “Decentralized oracle” is not a synonym for “cannot lie.” Listing Chainlink, Pyth, UMA or Uniswap TWAP is taxonomy, not a shopping list.