New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.
A smart contract receives a number from an oracle. What does that number represent? It might be a direct measurement, a value supplied by an organisation, an aggregate of several sources or an estimate derived from other observations. Those possibilities require different explanations. CryptoInfo Now’s historical catalogue includes an opinion about deriving an estimate from transaction data and a report about an oracle partnership. This new guide does not validate either source’s accuracy or present a current price feed. It uses a hypothetical temperature-reading service to examine the general problem: how information acquires meaning as it moves from an outside source into a system that applies a rule to it.
Define the quantity before the delivery channel
For the hypothetical exercise, a service reports the temperature at a named observation point. Specify the unit, the relevant location, the measurement time and the meaning of the value. An instantaneous reading, an hourly average and a daily maximum are different quantities even if each is displayed as one number. A consuming application needs the correct quantity for its rule. A reliable delivery channel cannot repair an undefined measurement. The explanation should therefore begin with what is being represented, not with the technical name of the transport used to send it.
Ethereum’s oracle documentation describes applications that make off-chain data available to smart contracts and discusses the questions introduced by relying on that data. This is a primary reference for the boundary, not proof that a particular feed is accurate. The hypothetical review asks what the source actually observes and what claim the delivered value makes. If the service reports an estimate rather than a measurement, the distinction belongs in the data description. A reader should not have to infer it from an implementation detail hidden far from the interface.
Record the transformation between input and output
Suppose the service receives three example readings and publishes their average. The resulting number is an aggregate, not a new direct measurement at an independent station. The review should identify the aggregation rule and the conditions under which inputs are included or excluded. If one reading is missing, does the service wait, publish from the remaining inputs or return an unavailable state? These choices affect the meaning of the output. They should not be concealed behind the same status label that appears when every expected input is present.
A model-derived estimate adds another layer. The source observations may be real while the relationship used to infer the desired quantity remains uncertain. A successful calculation shows that the model ran on its inputs, not that the estimate equals an independently observed truth. The hypothetical documentation names the model version, relevant inputs and limitations of interpretation. This is the useful distinction raised by the historical transaction-data opinion: an estimate derived from a record is a claim produced by a method, and the method needs examination separately from the integrity of the underlying record.
Separate measurement time from delivery time
A value can arrive quickly while describing an old observation. Record when the measurement was made, when it was processed and when the consuming system received it. Those timestamps answer different questions. A short transmission delay does not establish freshness if the source itself has not updated. Conversely, a recent measurement might be delayed in transit. The hypothetical application checks the time condition that matters to its decision rather than treating the arrival of any new message as proof that the represented state is current.
Define how the system handles missing or ambiguous time information. It might reject a value, mark it stale or use a documented fallback appropriate to its purpose. The important point is to avoid silently assuming that an unlabeled number is recent enough. A screen showing Updated now can refer to the interface refreshing rather than the source being measured again. The review should identify the basis of that label. A clear account of time is often more informative than a broad performance claim about the speed of the feed.
Ask which assumptions the consumer adds
The consuming application may apply a threshold, compare two feeds or trigger a notification. That decision rule is a separate component from data delivery. For the temperature example, a rule intended for an hourly average should not quietly receive an instantaneous reading under the same field name. A technically valid message can still be semantically unsuitable. The review maps the producer’s definition to the consumer’s expectation and records any conversion, rounding or unit adjustment between them. This makes a mismatch visible before a correct-looking number causes an unintended decision.
Also identify what the consumer assumes about the source’s independence, coverage and reliability. Several inputs may rely on the same underlying observation, so counting them does not automatically establish diversity. A signature may support an attribution or integrity claim without establishing that the source’s measurement is correct. These are questions to inspect in the actual arrangement, not properties guaranteed by the word oracle. The hypothetical review keeps delivery, attribution, measurement quality and decision logic on separate lines so that one verified property does not imply all the others.
Make disagreement and unavailability ordinary states
If two sources disagree, the system needs a defined response. It should not manufacture certainty by choosing whichever value makes the interface look most complete. The appropriate policy depends on the application, but the explanation should identify it. The hypothetical service can retain the conflicting observations and publish a disagreement status. That status is useful information. A blank, stale or disputed input may be exactly what a reader needs to understand, rather than an inconvenience to be hidden behind the last value that happened to look plausible.
Test the path for unavailable sources, delayed updates, inconsistent units and a model output outside its intended conditions. Record what the consumer does in each case. A demonstration using only clean, cooperative inputs cannot establish the behaviour of the complete feed. The value of these tests is not a universal safety guarantee. It is an evidence-backed account of the defined boundary: which inputs the service accepts, how it transforms them and what it communicates when the conditions for an ordinary result are not met.
Describe the feed as a chain of evidence
The final hypothetical feed description names the quantity, source, transformation, time basis, delivery mechanism and consumer rule. It states which properties were checked and which depend on supplied information. If accuracy was evaluated, the account needs a comparison method and an appropriate reference, not merely a statement that the feed operated without an error. If accuracy was not evaluated, say so. This prevents a successful integration test from being presented as an independent validation of the data’s real-world meaning.
The historical catalogue’s oracle records remain useful prompts for these questions, but their product and partnership claims are not current findings. The new guide’s central lesson is that an oracle carries a claim with a provenance and a method. It may deliver a measurement, an aggregate or an estimate, and each should be labelled accordingly. Follow the chain from observation to interpretation to action. A reader who can see those boundaries can understand what the system knows, what it infers and what it merely receives from another party.
Technical references
From the recovered archive
- UTXOracle: A Decentralized Approach To The Oracle Problem · captured 22 June 2024
- Sui Partners with Stork Oracle for Faster Pricing Data · captured 8 August 2024