Oracles
What Are Blockchain Oracles? Types and How They Work
October 23, 2026
13 mins read
What are blockchain oracles? Oracles bring off-chain data such as prices and events to smart contracts. Learn how they work and the main types in use.
Blockchain oracles are services that bring data from outside a blockchain, such as asset prices, event results or sensor readings, to smart contracts. A blockchain cannot fetch that data itself, so oracles act as the bridge between off-chain sources and on-chain logic. They come in several types, grouped by where the data comes from (software or hardware), which way it flows (inbound or outbound) and who runs them (centralized or decentralized). They also differ in how updates reach the chain: pushed by the oracle or pulled by the application.
What is a Blockchain Oracle?
Blockchain oracles are services that supply external data to smart contracts. They act as a connection point between the outside world and blockchains.
Off-chain data, meaning data outside the network, is inaccessible to blockchains and smart contracts. Yet many contractual agreements need information from the outside world to execute. By acting as a bridge between off-chain and on-chain data, blockchain oracles fill this gap. They are essential components of the blockchain ecosystem because they widen what smart contracts can do. Without oracles, smart contracts could only use data that already exists on their own network, which would severely limit their utility.
A blockchain oracle is the layer that queries, authenticates and checks external data sources before relaying that information. The data can take many forms, such as price details, confirmation that a payment succeeded or temperature readings from a sensor.
Requesting data from the outside world requires the smart contract to be triggered and network resources to be used. Some oracles can also send information back to outside systems in addition to relaying it to smart contracts.
There are many types of oracles, and how each one operates depends on its purpose. This article walks through the main designs.
An example of a Blockchain Oracle
David and Thomas bet on who would win the FIFA World Cup 2022 final between Argentina and France. David predicts Argentina will win, while Thomas backs France. They agree on the terms and deposit their money into a smart contract, which will release all of the money to the winner based on the result of the match.
Because the smart contract cannot read external data, it relies on an oracle to provide the result of the final. The oracle gets the winner from a trusted API (an interface that serves data to other software) and passes it to the smart contract. Depending on the result, the contract then transfers the money to either David or Thomas.
Without an oracle, the contract would have no way to learn the result on its own.
The Blockchain Oracle Problem
Smart contracts execute decisions based on the information oracles provide. The main issue in oracle design follows from that: any smart contract that depends on an oracle inherits the oracle's weaknesses. This is known as the oracle problem.
Blockchains themselves cannot connect to real-world data (Source)
Blockchains get their most important properties, such as strong consensus on the validity of transactions, prevention of double-spending attacks and resistance to downtime, by being deliberately isolated from external systems. Oracles sit outside that consensus, so they are not covered by the security a public blockchain provides. The gap between trustless on-chain execution and data that arrives from outside is still an active design problem. We look at its legal, financial and technical side for institutions in the oracle problem for enterprise DeFi.
Man-in-the-middle attacks are another risk, where a malicious actor intercepts the data flow between the contract and the oracle and alters it.
The oracle problem matters because, as Chainlink's guide to blockchain oracles puts it, most smart contract use cases, including decentralized finance (DeFi), depend on real-world data and off-chain events. Oracles give blockchains a gateway to off-chain resources, which widens the kinds of digital agreements they can support while keeping the core security of the chain.
Oracles and smart contracts serve many industries, including asset prices in banking, weather data in insurance, randomness in gaming and identity verification in government.
How does a Blockchain Oracle work?
This breakdown follows the oracle model in the ethereum.org developer documentation.
Users
Users are entities, for example smart contracts, that need information from outside the blockchain to carry out a task. The user sends a data request to the oracle contract to start the basic workflow of an oracle service. A data request usually answers some or all of these questions:
-
Which sources may off-chain nodes use to get the data?
-
How do reporters analyze data from sources to pick out the relevant data points?
-
How many oracle nodes can take part in retrieving the data?
-
How should discrepancies between oracle reports be handled?
-
How are submissions filtered and combined into a single value?
Oracle contract
The oracle contract is the on-chain part of the oracle service. It receives data requests from other contracts, passes them to oracle nodes and returns the data they deliver to the client contracts. It may also run calculations on the returned data points to produce an aggregate value for the requesting contract.
When a client contract requests data, it calls functions that the oracle contract exposes. The oracle contract then emits a log event describing the new request. Off-chain nodes that subscribe to that log are alerted and fetch the data specified in the event.
Oracle nodes
The oracle node is the off-chain part of the oracle service. It gathers data from external sources, including APIs hosted on third-party servers, and posts it on-chain for smart contracts to use. Oracle nodes listen for events from the on-chain oracle contract and carry out the task described in the log.
A common job for an oracle node is to send an HTTP GET request to an API, parse the response to extract the relevant data, format it for the blockchain and send it on-chain in a transaction to the oracle contract. The node can also be asked to attest to the accuracy and reliability of the data it submits.
Computational oracles also rely on off-chain nodes to run heavy computations that are impractical on-chain because of gas costs and block size limits. For example, an oracle node can produce a verifiable random number for a blockchain game, using a verifiable random function (VRF).
Common Oracle Design Patterns
Oracles follow several design patterns, which the ethereum.org documentation lists as immediate-read (the contract reads a stored value once, for example a date of birth), publish-subscribe and request-response.
The ethereum.org docs note that the latter two are the most common among Ethereum smart contracts:
Publish-subscribe oracles
A publish-subscribe oracle offers a "data feed" that other contracts read regularly. Because the data changes often, client contracts must watch for updates. A typical example is an oracle that publishes the latest ETH-USD price.
Request-response oracles
A request-response oracle lets the client contract make arbitrary data requests, beyond what a publish-subscribe feed provides.
Request-response oracles fit best when:
-
The dataset is too large to fit in a smart contract's storage
-
Users only need a small portion of the data
In a request-response oracle, the on-chain contract takes in a data request and sends it to an off-chain node for processing, which makes it more complex than a publish-subscribe feed.
Users who start a data request cover the cost of getting data from the off-chain source. The client contract must pay the gas the oracle contract spends returning the result through the callback function named in the request.
Push and pull oracles
Newer oracle networks also differ in how price updates reach the chain.
- Push oracles: the oracle operator writes updates to each chain on a schedule or when prices move, and pays the transaction fees for every update.
- Pull oracles: prices are signed off-chain and written on-chain only when an application needs them, inside the same transaction that uses the price. The user who needs the update pays for it. Pyth Network described this model in its December 2022 post "Pull, Don't Push: A New Price Oracle Architecture".
Pyth's post argues that pull designs let one network serve many more feeds and chains, because nobody pays to write prices that no contract reads. Push designs keep a fresh value on-chain for any contract to read at any time.
Optimistic oracles
An optimistic oracle does not fetch data by default. It accepts a proposed answer unless someone challenges it. UMA's optimistic oracle, as its documentation describes, works in four steps:
- A contract posts a data request with a reward, a bond amount and a challenge period.
- A proposer submits an answer and posts a bond, a deposit that is lost if the answer is wrong and returned if it stands.
- During the challenge period anyone can dispute the answer by posting their own bond.
- Disputes go to UMA's Data Verification Mechanism, where UMA stakers vote on the correct outcome.
This model suits questions that no API answers directly, such as the outcome of a prediction market. It also shows what happens when the vote itself is contested: our case study of the Polymarket UMA oracle dispute walks through one.
Different types of Blockchain Oracles
Blockchain oracles are classified by several qualities:
-
Source: Does the data come from software or hardware?
-
Direction of information: Is it inbound or outbound?
-
Trust: Is it centralized or decentralized?
One oracle may fit into more than one category. For instance, an oracle that draws information from a company website is a centralized inbound software oracle.
Software Oracles
Software oracles connect to online data sources and send the data to the blockchain. The data can come from any online database, server, website or other source on the internet.
Because they are connected to the internet, software oracles can deliver information to smart contracts as it changes. That makes them among the most common kinds of blockchain oracles.
Exchange rates, digital asset prices and flight information are a few of the data types software oracles often provide.
Hardware Oracles
Some smart contracts need to interact with the physical world. Hardware oracles gather data from real-world devices and provide it to smart contracts. The data can come from electronic sensors, barcode scanners and other reading devices.
Simply put, a hardware oracle turns real-world events into digital values that smart contracts can use.
One example is a sensor that detects whether a cargo aircraft has arrived at the airport. When it has, the sensor sends the data to a smart contract, which acts on it.
Inbound and Outbound Oracles
Inbound oracles send information from external sources to smart contracts, while outbound oracles send information from smart contracts to the outside world.
For example, an inbound oracle might tell a smart contract the temperature measured by a sensor. A smart lock is an example of an outbound oracle: as soon as payment arrives at a specified address, the smart contract sends a signal through an outbound oracle that opens the lock.
Centralized and Decentralized Oracles
A centralized oracle is managed by a single entity and is the only source of data for the smart contract. Relying on one source is risky because the oracle's owner can decide whether the contract works, and any interference by a bad actor hits the contract directly. The main issue with centralized oracles is that they are a single point of failure. Our comparison of centralized and decentralized oracles goes deeper into the trade-offs.
Decentralized oracles share a goal with public blockchains: avoiding counterparty risk. By not relying on a single source, they improve the accuracy of the data supplied to smart contracts. They are also called consensus oracles, because the smart contract consults several oracles to assess the validity and accuracy of the data.
Decentralized oracles aim for trustlessness, but like trustless blockchain networks they do not remove trust entirely. They spread it across many participants.
Contract-specific Oracles
A contract-specific oracle is built for use by a single smart contract. A team that deploys many smart contracts therefore needs a matching number of contract-specific oracles.
Maintaining this kind of oracle takes a lot of time and money, which makes it impractical for businesses that pull data from many sources. On the other hand, developers can customize contract-specific oracles freely, because each one is built from scratch for a particular use case.
Human Oracles
Oracles can also be people with expertise in a specific field. They gather information from several sources, check it and pass it to smart contracts. Because human oracles can use cryptography to confirm their identity, it is hard for a fraudster to impersonate them and supply false information.
Blockchain Oracle Use Cases
Smart contract developers use oracles to build more complex decentralized apps for a wider range of use cases. The most widely adopted ones, as Chainlink's guide to blockchain oracles groups them, are below.
Decentralized Finance (DeFi)
A large part of DeFi relies on oracles for information about assets and markets. Lending markets use price oracles to calculate how much users can borrow and whether their positions are undercollateralized and at risk of liquidation. Automated market makers (AMMs), the pools behind decentralized exchanges, use price oracles to keep liquidity near the current market price. Synthetic asset platforms use price oracles to link the value of tokens to real-world assets.
Dynamic NFTs and Gaming
Oracles also support non-financial uses, such as dynamic NFTs: tokens that change appearance, value or distribution based on the time of day or the weather. Compute oracles can produce verifiable randomness, which projects use to assign NFTs random traits or pick random winners in high-demand drops. On-chain games use verifiable randomness for elements such as random loot boxes or tournament matchmaking.
Insurance
Insurance smart contracts use inbound oracles to confirm that an insured event happened during claims processing, drawing on physical sensors, web APIs, satellite images and legal data. Outbound oracles can then pay out claims through other blockchains or traditional payment networks.
Real-World Assets
Tokenized funds, bonds and stablecoins depend on off-chain data such as net asset value (NAV), reserve balances and collateral positions. Oracle feeds deliver those values to smart contracts. zkDatabase adds Zero-Knowledge Proofs (cryptographic proofs that a computation was done correctly, without revealing the data) next to the feed, so counterparties can check that the underlying data was stored and processed as claimed without seeing it. A proof does not show that the input value itself is true; that still depends on the source. We explain that layer in Zero-Knowledge Proofs for off-chain data vs oracles.
Final Words
Widespread use of blockchains depends on reliable communication between smart contracts and the outside world. Without blockchain oracles, smart contracts could only use data that already exists on their own network, which would greatly reduce their potential.
Decentralized oracles reduce systemic risk in the blockchain ecosystem by removing the single point of failure that one data source creates. As more value moves on-chain, oracles remain one of the building blocks that has to be secure, dependable and resistant to manipulation.
Explore zkDatabase: see how zkDatabase adds proofs to off-chain data that smart contracts depend on.
Related toOracles
