A smart contract is blind to the outside world by default. It can prove its own math and inspect its own state, but it has no native way to see a market price, a weather reading, or a settlement figure. Oracles close that gap: they gather facts from off-chain sources, sign them, and place them where a contract can read them. The key caveat is that publishing something on-chain proves the data was delivered, not that it was true.
Three delivery models, three kinds of risk
Feeds generally take one of three shapes. A push model has a network of reporters periodically write a fresh answer to an on-chain contract; whatever value sits there between rounds is what applications read, even if the market has since moved. A pull model reverses the flow, requiring the consumer to bring a recent, signed update along with the transaction, which allows fresher readings but makes the application responsible for rejecting outdated ones. A third option computes a time-weighted average using a liquidity pool’s recent prices, which smooths brief spikes yet also trails fast moves and depends on the pool having enough depth to mean anything. Each design trades one kind of risk for another rather than removing risk.
The expensive failure is usually an old number, not a fake one
Feeds rarely break by inventing a price; more often they simply go stale. A feed can run exactly as specified while its stored value lags far enough to distort a decision. Picture a collateralized loan: if the market price has dropped but the contract keeps valuing the position with an older, higher figure, both borrowing capacity and liquidation boundaries drift away from reality. The same lag might be harmless on a read-only dashboard and dangerous inside a liquidation routine. The useful question is therefore not which provider is best in general, but whether this reading is adequate for this action at this moment.
Questions to answer before trusting a feed
A careful review should be able to answer a short list. What exact asset and currency does the feed represent, and is the underlying market liquid enough? How recent is the stored value, and what does the feed’s own timestamp say? How are individual sources combined, and what happens to outliers? Who holds the authority to upgrade the feed or its contracts? What does the application do if the chain stalls or the price gaps? If none of that is documented, the honest conclusion is to treat the integration as unverified.
Oracles, indexers, and explorers are different tools
It helps to keep three pieces apart. An oracle supplies authenticated outside information for contracts to act on. An indexer reorganizes data that already lives on-chain to make it quicker to query. A block explorer is a window for people to inspect transactions. An indexer can list every past loan, but it cannot produce a trustworthy current market price on its own; a healthy system usually leans on all three for different jobs.
Read the feed as an input, not a verdict
An oracle is one component of a risk system, not a certificate of truth. A signed reading tells you who attested a value and when; it says nothing about whether that value was a fair price for the market it claims to describe. Sensible integrations wrap a feed in their own safeguards, such as collateral limits, freshness ceilings, and emergency pauses, precisely because the feed itself cannot promise that its number is the number you actually need.
Adapted from What Is a Crypto Oracle? Price Feeds, Failures, and Safety.