A lending contract can count the ETH deposited into it. It cannot decide what that ETH is worth in dollars merely by inspecting the wallet balance. A prediction market faces a similar problem: the contract can hold collateral and calculate payouts, but it needs a defined way to establish which outcome occurred.
A blockchain oracle supplies information that a smart contract can use beyond its own available state. That might be an asset price, an event result or a fund’s reported net asset value. The oracle makes these applications possible, while adding dependencies on how information is collected, delivered and interpreted.
Why a smart contract cannot just open a website
On Ethereum and similar chains, nodes must reproduce the same result from the same transaction and state. An ordinary website can change between requests, become unavailable or return different answers to different visitors. Letting each validator independently fetch a live web page during execution would undermine that shared result. Ethereum’s oracle documentation explains this boundary between contract execution and external information.
Instead, an external process brings a report into a form the blockchain can accept. The contract reads a published value or verifies a report supplied with a transaction. It does not secretly acquire unrestricted internet access.
Blockchain consensus establishes which report was accepted and which rules executed. It does not independently establish that a weather station worked, a company reported honestly or a market price was free from manipulation.
Follow the information from source to decision
A price-dependent application typically involves several separate steps:
- Observation: exchanges, trading firms or other providers produce observations about an asset. Sources may measure different venues, trading hours or instruments.
- Processing: an oracle system applies its aggregation and reporting rules. Multiple operators can reduce reliance on one reporter, but shared upstream sources can still create a common point of failure.
- Delivery: a transaction publishes a value, or a caller submits an authenticated report for verification. The destination chain determines when that transaction executes.
- Application: the consuming contract checks the feed identifier, units and permitted age, then applies its own borrowing, settlement or other rules.
These responsibilities should not be collapsed into the oracle provider’s name. Chainlink’s decentralized data model, for example, separates data sourcing, node reporting and onchain aggregation. An application still has to integrate the resulting feed correctly.
Different applications need different oracle designs
Push and pull describe how updates reach the application. They do not, by themselves, tell you whether the system is centralized or decentralized.
| Design | How information arrives | What the application must consider |
|---|---|---|
| Push feed | Updates are published to an onchain feed. Contracts read its latest available value. | Publication triggers, transaction delays and how old the stored observation may be. |
| Pull report | A caller obtains a report and submits it when an application needs it. | Authentication, the observation’s age and the cost of submitting the update. |
| Optimistic oracle | A proposed answer can be challenged during a defined period; disputes follow a resolution process. | Clear resolution criteria, monitoring incentives, bonds and time to settlement. |
Chainlink describes deviation and heartbeat triggers for updates to its push-based feeds. A heartbeat is not a promise that every update will arrive despite congestion or outages. UMA’s optimistic oracle instead gives participants time to challenge proposed answers. That can suit event resolution better than a price needed immediately for a trade.
Not all oracle inputs originate offchain. A contract can derive a price from a decentralized exchange’s onchain history. Uniswap v2’s cumulative-price design supports time-weighted average prices, or TWAPs. Averaging can make brief manipulation more expensive, but the result still depends on liquidity and the chosen observation window. A longer window also reacts more slowly to genuine price changes.
How an outdated price can change a liquidation
Consider a simplified lending position with 10 ETH as collateral, $12,000 of debt and an 80% liquidation threshold. Assume the debt’s dollar value stays fixed and ignore interest and fees.
At $2,000 per ETH, collateral is worth $20,000 and the debt is 60% of its value. If ETH falls to $1,400, collateral falls to $14,000; the debt now represents about 85.7%, above the assumed threshold. The position would meet this example’s liquidation condition once the contract accepts that price.
If the application continues using the old $2,000 observation, the position may appear healthy while its economic backing has weakened. A falsely low observation can create the opposite problem: liquidation of a position that should remain healthy. The contract can execute its code exactly as written in either case.
This is why systems such as the EVAA lending protocol need to be understood through both their price inputs and their liquidation rules. The figures above are an illustration, not EVAA’s parameters.
A fresh signature is not necessarily fresh information
Three questions matter: when was the underlying observation produced, when was the report formed, and when did the blockchain accept it? A recently submitted transaction may carry an older observation.
Pyth Pro’s integration guidance distinguishes update timing from individual feed freshness and recommends handling uncertainty in reported prices. A valid signature authenticates a report under the relevant verification rules; it does not make every value current or eliminate disagreement between markets.
Developers also need a failure policy. Rejecting stale data, limiting new borrowing or pausing price-sensitive operations can contain damage. Automatically switching to an untested fallback can introduce another dependency. Chainlink explicitly assigns application developers responsibility for data checks, circuit breakers and contingency logic.
On some Layer 2 networks, the ability to submit a transaction is another concern. A sequencer outage can prevent users from adjusting positions. Chainlink’s sequencer uptime guidance describes status checks and a recovery grace period; a price timestamp alone does not address that access problem.
What to look for before relying on an application
Look for the exact feed and network, the underlying market or reporting source, the maximum accepted age and what happens during an outage. Check who can replace the oracle or change those limits. “Uses an oracle” is a starting point for understanding a protocol, not a security rating.
The same distinction matters for tokenized assets. Publishing a fund’s NAV does not establish custody, legal ownership or redemption rights. Our discussion of Chainlink, Hanwha and RWA infrastructure explains why reliable data delivery and asset rights are separate parts of a product.
You can explore markets through KTX Crypto Exchange. For any product, read its own pricing and settlement rules: an onchain oracle value is not automatically the price at which your order will execute.
FAQ
Does using an oracle mean I need to buy its token?
No. Users often interact with an application without holding its oracle provider’s token. Update fees and who pays them depend on the integration. A provider’s token also has its own market risks.
Can an oracle move the assets in my wallet?
A data report alone is not a wallet signature or token spending approval. Contracts may use that report to trigger actions involving assets already governed by their rules, including collateral liquidation.
Is an oracle price the same as an executable trading quote?
No. A reference may aggregate several sources or average an interval. Your execution depends on the venue, available liquidity, order size and fees. A displayed reference does not guarantee a fill.
Is a blockchain bridge the same thing as an oracle?
They can overlap in messaging and verification infrastructure. A bridge typically enables crosschain transfers or messages; an oracle supplies information for an application. Their names do not establish identical security assumptions.
Can an oracle keep sensitive business information private?
Not simply by delivering it onchain. Data published openly may be visible to anyone. A privacy-sensitive application needs a separate design for disclosure, access and verification.
Risk notice: Oracle failures, manipulated sources and integration errors can cause losses even when a blockchain operates normally. This article is educational and is not investment advice.