What is a blockchain oracle? An oracle is an application that supplies data feeds, making information from outside the blockchain available to smart contracts. For Ethereum, that role addresses a specific boundary: smart contracts alone cannot retrieve information from offchain sources.
The distinction matters whenever an application needs information about something beyond the blockchain. Supplying that information and establishing whether it is dependable are separate questions. Understanding an oracle means following both: where the input comes from, and what remains to be evaluated before relying on it.
Why smart contracts need an outside data supply
Ethereum’s introduction to smart contracts states that smart contracts alone cannot retrieve offchain information. Here, offchain means outside the blockchain. A weather observation recorded by an external service is an example of the kind of information at issue.
The word alone is essential. This limitation does not mean that a blockchain application can never use outside information. It means that the contract needs a way for that information to be made available to it. Oracles provide the data-supply role described in the documentation.
For a reader assessing an application, the useful question is therefore: what supplies its external inputs? Saying that an application uses a smart contract leaves that question unanswered. Identify the outside information it needs before examining the oracle description.
What an oracle feed provides—and what it leaves open
Ethereum’s oracle documentation defines oracles as applications producing feeds that make offchain data sources available to the blockchain for smart contracts. A simple way to follow the relationship is: external information, oracle feed, contract input.
This definition describes a function. It does not, by itself, establish that the supplied information is correct, current, continuously available, or safe to rely on. A description that identifies an oracle has explained part of the information path; further evidence is needed to evaluate that path.
A useful deduction follows from the two source statements: if a contract alone cannot retrieve offchain information and an oracle supplies it, understanding the contract’s external input requires examining the oracle arrangement as well. This deduction identifies an evaluation task, not a finding that a particular arrangement is reliable or unreliable.
Keep that question separate from the network roles discussed in our guide to Ethereum nodes and clients. This article focuses specifically on how outside information becomes available to contracts.
Separate data sources from trust models
The oracle documentation classifies systems along several dimensions. Two particularly useful distinctions are whether they use one or multiple data sources, and whether their trust model is centralized or decentralized. These answer different questions.
One source or multiple sources
Source count concerns where the information originates. When reading a description, look for the named source or sources rather than stopping at a phrase such as “external data.” If the description says there are multiple sources, ask which ones are included.
The classification alone does not establish that the resulting input is correct. A source list is useful information for an assessment, but it should not be presented as proof of accuracy or resistance to attacks.
Centralized or decentralized
Trust model is a separate classification in the documentation. Preserve that distinction when comparing explanations: a statement about source count does not answer the trust-model question.
Neither the centralized nor decentralized label alone establishes correctness, availability, safety, or attack resistance. Ask what the description actually explains about its trust model and what evidence supports any additional assurances. If those details are missing, record the gap rather than filling it with an assumption.
A hypothetical weather-data example
Imagine a classroom exercise about a fictional contract that uses a daily rainfall observation. This is a hypothetical example, not a deployed application or a recommendation to transact.
The exercise identifies a weather service as the offchain source and an oracle feed as the means of making its observation available to the contract. That explains the intended information path. It does not establish whether the observation is accurate or whether an appropriate update will be available.
Now imagine two written descriptions. The first names one weather source and describes a centralized trust model. The second names several weather sources and describes a decentralized trust model. Students should record both dimensions separately. The exercise provides no basis for declaring either arrangement safe merely from those labels.
Next, suppose the worksheet contains a rainfall value but does not say when it was observed. Students can identify the value provided, yet whether it represents the intended day remains unestablished. This illustrates why identifying a feed is only the beginning of evaluating its suitability for a particular question.
Ask about availability and regular updates
The oracle documentation explicitly asks how data can remain always available and be updated regularly. It raises these as problems to address, not as universal properties of oracle services.
Availability: What information explains whether the required data will be available when needed? A statement that a feed exists does not settle that question.
Updating: What does the documentation say about regular updates? The source’s question establishes no universal update interval and no promise that any particular feed is current or accurate.
In the classroom example, a useful review would ask separately whether the rainfall observation is available and whether it relates to the intended observation period. These are proposed evaluation questions. They do not assert that a particular service meets or fails either requirement.
A practical checklist for reading oracle descriptions
- Identify the outside input: What information does the application need from beyond the blockchain?
- Trace the supply role: Which oracle feed makes that information available to the contract?
- List the sources: Does the description identify one source or multiple sources?
- Record the trust model separately: Is it described as centralized or decentralized, and what explanation accompanies that label?
- Ask about availability: What evidence addresses access to the required information?
- Ask about updates: What is documented about regular updating, and what remains unspecified?
- Keep conclusions bounded: Distinguish a documented role or classification from evidence supporting a reliability claim.
This checklist helps organize a reading of the documentation; completing it does not certify a system’s safety. Source attribution likewise identifies the basis for an explanation without proving that an application is safe.
This educational article was prepared with AI assistance using the cited Ethereum documentation. It explains concepts and evaluation questions rather than recommending an oracle service or financial action.