Oracle evidence: timestamp, pair, network, fallback
An oracle observation is useful only after checking what it measures, where it is deployed, when it was updated, and how the consuming application handles unavailable or unsuitable data. A number stored onchain is not automatically a current executable spot price. Treat the feed and its consumer as two related evidence objects.
Chainlink’s feed-selection documentation discusses feed categories and selection considerations. Use the documentation relevant to the exact feed. It does not establish one universal freshness tolerance or guarantee that every feed is appropriate for every asset, network, or application.
Create a feed identity card
Record the network, feed address, asset pair, quote currency, decimals, and description. Confirm the official deployment reference rather than selecting a contract by a familiar name. A pair inverted by mistake or a decimal conversion error can produce a plausible-looking but entirely wrong research result.
Then record the observed answer and update timestamp, together with the block at which they were read. Keep retrieval time separate from data-update time. A newly retrieved response can contain an older observation. Whether that age is acceptable depends on the research purpose and applicable feed characteristics.
| Identity-card field | Why it matters |
|---|---|
| Pair and denomination | Establish the measured quantity |
| Network and address | Prevent deployment confusion |
| Decimals | Convert raw values correctly |
| Update timestamp | Measure the observation’s age |
| Intended use | Establish the relevant freshness requirement |
| Consumer behavior | Identify validation and fallback assumptions |
A freshness threshold should be justified by the task. Do not invent one global number and present it as a protocol rule.
Hypothetical stale-but-retrieved observation
Assume a fictional research script retrieves a price at 12:00 UTC, while the feed’s update timestamp is 11:40 UTC. The response was obtained now, but the underlying observation is twenty minutes old. A daily valuation worksheet and an analysis of a sudden intraday event may need different treatment of that age.
Suppose the researcher compares it with a venue quote at exactly noon. A difference may reflect observation timing, market coverage, pair definition, or another methodological factor. It should not immediately be called an oracle failure. Record the mismatch and align definitions before interpreting it.
Now assume the application consumes a different feed address than the research script. Even a correct feed reading would fail to establish what the application actually used. This hypothetical example shows why deployment identity and consumer linkage belong in the same evidence packet.
Inspect the consuming rule
Locate the application code or documentation describing how it reads and validates data. Ask whether it checks the relevant timestamp, expected denomination, and unavailable-data behavior. Research should describe verified controls without claiming a security audit has been performed.
If there is a fallback, identify its source and activation condition. “Has a fallback” is not enough to establish suitable behavior: a fallback can have its own age, coverage, and operational dependencies. Keep each source as a separate record and document which one was active at the observation point.
Reproduce one raw-to-display conversion independently. For example, retain the raw integer and the divisor implied by the documented decimals. Verify units through the complete calculation rather than simply checking whether the displayed result resembles a recent market price. Plausibility is a weak substitute for dimensional consistency.
Limits and common mistakes
A public feed review cannot guarantee future availability or establish every contributor’s data quality. Historical state may also be needed to determine what an application saw at a past moment. A current response cannot answer that historical question by itself.
The workflow is unsuitable for claiming an executable trading price without venue-specific evidence. Common mistakes include confusing retrieval time with update time, selecting the right pair on the wrong network, comparing inverse denominations, treating decimals as a cosmetic detail, and assuming published feed capabilities prove a consumer validates them. The final note should identify the exact observation and the suitability conditions, not apply a generic trustworthy label.
FAQ
Is onchain data automatically fresh?
No. Inspect the observation timestamp and the requirements of the specific task. Retrieval time alone is insufficient.
Can a feed discrepancy establish an arbitrage opportunity?
No. A feed observation and an executable venue quote are different measurements. This research method does not establish trading access, costs, or an achievable return.