A smart contract can execute a rule exactly as written and still make a poor decision if the information supplied to it is wrong. An oracle is the mechanism that brings outside observations into that execution environment: an asset price, a reported reserve balance, a result or another fact the contract cannot obtain merely by inspecting its own chain.
This makes oracles part of a financial application's trust model, not just a convenient data connection. The question is not only whether a number reached the blockchain. It is which number, from which sources, at what time, under whose authority, and what the application will do when the number is unavailable or unreliable.
The easiest way to understand the system is to separate observation, delivery and use. A source observes something. A delivery process publishes a representation of that observation. A contract consumes it under its own rules. Each stage introduces a different potential failure.
The blockchain does not independently know the outside world
Nodes need to agree on transaction execution. Allowing every validating computer to call a different website during the same transaction would introduce responses that could differ by location, timing, credentials or availability. A contract's deterministic execution therefore needs outside information represented in an agreed form within its execution environment.
Our Ethereum explainer describes that shared execution layer. An oracle does not replace it. It supplies an input that the layer can process consistently, while leaving the separate question of whether the input accurately represents the external event.
A signature can prove that a particular authorized publisher supplied a statement. It does not prove that the underlying statement is true. This distinction is familiar outside crypto: knowing which person signed a document is not the same as independently checking every fact in it.
Source, aggregation and delivery are separate dependencies
Consider a hypothetical price feed that collects quotations from three venues. Its design must specify which pairs qualify, whether prices are denominated in the same currency, how observations are combined and what happens when a venue fails to respond. A single displayed output can conceal those choices.
Multiple reporters can reduce dependence on one delivery operator, but not necessarily on one original source. If every reporter reads the same exchange, an error at that exchange can reach all of them. Diversity of operators and diversity of underlying observations are related, but not interchangeable.
Aggregation is another choice. A median can resist an isolated extreme value; a weighted calculation can give greater influence to selected sources. Neither is universally correct. The appropriate method depends on what the feed is meant to measure and which failures its designers expect.
A price needs an identity, a unit and a timestamp
A feed labelled ETH/USD and one labelled ETH/BTC answer different questions. A wrapped token may also have a different redemption mechanism from the native asset whose name it resembles. Before reading any number, an application must identify the asset, quote unit, chain and exact feed.
Chainlink's interface documentation describes responses that include an answer and timing information, with a separate decimals value for interpreting the integer. Reading the raw integer without applying its scale can produce an enormous valuation error even when every publisher reported correctly.
Here is an original arithmetic example. A hypothetical response of 123450000 with six decimal places represents 123.45 units, not 123,450,000 units. If a contract treats those values as equivalent, it has an integration bug rather than evidence of a faulty market quotation.
The same care applies to freshness. The newest stored answer may be old. Successful retrieval proves that data exists, not that it describes present conditions. A consumer needs a defined maximum age appropriate to the decision it is making.
Update rules are not a promise of continuous truth
Some feeds update after a specified price deviation or a time interval. Others allow an application transaction to bring a newer signed observation onchain when needed. These patterns change delivery cost and timing, but neither makes the observation perfectly simultaneous with the consuming transaction.
Chainlink's feed-selection guidance asks integrators to examine the chosen feed's characteristics rather than assume identical behavior across every asset. The frequency suitable for a liquid major asset may not suit a less actively traded token or a market with limited source availability.
Imagine a lending application that accepts observations up to ten minutes old. During calm conditions, that may seem uneventful. During rapid movement, a ten-minute-old collateral value can differ materially from the price at which a position could actually be unwound. The threshold is a policy choice with financial consequences.
Push and pull describe delivery, not an automatic security ranking
A push design publishes updates according to the feed's operating rules. Applications read the stored result. In a pull design, a transaction can carry an update for verification and consumption. Pyth documents both delivery approaches across its systems.
Pull delivery can avoid paying to publish every observation for every possible consumer. It also means the consumer must understand which update is accepted, how its age is checked and whether a user has discretion among otherwise eligible observations.
Push delivery has its own dependencies: update transactions must arrive, the network must process them and the stored value must remain suitable for the application. The useful comparison is the full path from observation to action, not a label declaring one design intrinsically safe.
An oracle value is not necessarily an executable quotation
A reference price may summarize a market without offering to trade any quantity at that number. A lending contract can use such a reference to value collateral, but a liquidation still needs an actual route for exchanging the asset. The route may have fees, limited depth or a different average fill.
Our liquidity guide explains why the last trade, best quotation and average execution for a larger order can differ. An oracle does not create liquidity merely by reporting a value. It supplies information to a separate decision process.
Suppose a hypothetical feed values one token at 100 units, while the available bids for a large sale average only 94. A liquidation model that assumes immediate execution at 100 can underestimate the cost. The feed might be measuring its intended reference accurately while the application's execution assumption is wrong.
Onchain prices also require manipulation analysis
Not all observations originate outside the blockchain. An application can derive a price from an onchain trading pool. That removes one external delivery path, but introduces dependence on the pool's reserves, active liquidity and the transactions that change them.
Uniswap's oracle documentation describes accumulated observations that can support time-weighted prices. Averaging over a period can make a momentary distortion less influential, but the result depends on the selected interval and the quality of the underlying market.
A longer averaging window can resist a brief change while reacting more slowly to a genuine market move. A shorter window responds faster but can be easier to disturb. These are design trade-offs; the word onchain does not settle them or make manipulation impossible.
Uncertainty can be more useful than a falsely precise answer
Pyth publishes a confidence measure alongside its price. Its integration guidance discusses disagreement between sources and the risk of stale observations. An application can use such information to adjust its behavior rather than treating every reported value as equally reliable.
A wider confidence range is not a guarantee that every executable price lies inside it. It is additional information produced by the feed's method. Consumers need to understand that method and decide how uncertainty affects the particular action they permit.
For a hypothetical collateral loan, using a conservative valuation may reduce the amount that can be borrowed. Pausing a new action when uncertainty exceeds a defined limit is another possible response. Both sacrifice some immediate usability to address a risk; neither is a universal recommendation for every protocol.
Network availability and market hours remain relevant
A blockchain may run continuously while the market supplying an observation does not. A stock-price feed, for example, needs an explicit policy for periods when its reference market is closed. Reusing the latest stored value is not proof of a fresh trade.
Pyth's documentation warns that network outages or unavailable observations can leave prices stale. It recommends explicit age checks. A consumer that catches an error and silently substitutes an old value can undo the protection that the feed's interface was designed to provide.
Layer 2 applications face another availability boundary. Chainlink's sequencer-uptime guidance describes checking whether the relevant sequencer is operating and allowing a grace period after recovery. A feed update and a user's ability to act can be disrupted differently; restarting execution without considering that asymmetry can create unfair outcomes.
Fallbacks and administrative controls need scrutiny
A fallback feed adds resilience only if its dependencies and behavior are understood. If both the primary and fallback rely on the same unavailable source, switching between them may achieve little. If they measure different assets or use incompatible scales, switching can create a new valuation problem.
Administrative permissions matter too. Ask who can change a feed address, replace publishers, alter freshness limits or pause an application. A technically distributed reporting network can still sit inside a contract whose administrator has broad authority over the final input.
Governance delays can provide notice of changes, but also slow emergency response. Emergency controls can reduce immediate harm, but concentrate authority. Evaluating an oracle therefore requires the consuming application's configuration and permissions, not just the provider's name.
Read the whole data path
A meaningful review starts with the exact fact the contract needs. It then identifies the source market or record, the reporting and aggregation method, the delivery mechanism, the accepted age and units, and the consumer's response to errors or uncertainty.
The final step is financial: what happens if the answer is delayed, manipulated or accurate but unsuitable for execution? Borrowing, settlement and position closure can fail in different ways. The same feed may be acceptable for displaying an indicative balance and inadequate for executing a leveraged trade.
The durable lesson is that blockchain consensus and external truth are different problems. Oracles make outside information usable by contracts; they do not remove the need to examine its meaning, freshness and authority. Good integration makes those dependencies explicit instead of hiding them behind one reassuring number.