Decentralised News · Editorial by Heath Muchena · Evidence reviewed 11 November 2026. Original DN analysis and local instrument; field testing is claimed only where expressly reported.
What Matters
A fast API response can carry an old observation. Measure freshness from the timestamp that actually describes the data, then include the time spent waiting inside the agent’s own workflow. DN’s calculator compares that age with a declared budget and clock uncertainty. It does not invent a universal data-decay price or turn a recent timestamp into a safe trading signal.
Decentralised News · Agent Data Research · Edition 1.0 · Reviewed 11 November 2026
DN Evidence Block
Established by documentation: OGC observation-time semantics, HTTP cache-age semantics, timestamp formats, and documented Chainlink and Pyth Core fields. Original DN work: an age-budget model, conditional uncertainty calculation and local JSON record. Not measured: provider latency, stale-data rates, economic decay, clock accuracy or agent performance. All worked numbers are illustrative.
The freshness clock starts before the API call
An agent requests a data point, receives a response in a fraction of a second and spends another minute planning an action. The response time tells us something about delivery. It does not tell us when the underlying event was observed, whether the source republished an old value or how much age accumulated before the agent used it.
For a hypothetical environmental-data buyer, a reading observed at noon, uploaded at 12:05 and used at 12:06 is six minutes old at the decision point. A quick request at 12:06 does not make the reading new. A fresh ledger transaction containing that reading would add another timestamp, not change the original observation.
DN’s oracle-delivery comparison concerns latency. Its paid API-call analysis concerns billable requests and accepted outcomes. The distinct decision here is whether a data item’s age, with its actual timestamp semantics, satisfies a budget at the moment of use.
Name the timestamp before subtracting it
| Timestamp | Event it may describe | Question to preserve |
|---|---|---|
| Observation or phenomenon time | When the measured event occurred or the observation applies. | Is it an instant, an interval or a supplied fallback? |
| Result or publication time | When a result was produced or published. | How much processing or source age preceded it? |
| Oracle round update | When the specified on-chain round was updated. | What underlying observations contributed to that round? |
| Receipt time | When the consuming system obtained the response. | How old was the payload on arrival? |
| Decision time | When the workflow evaluates or uses the data. | Did planning, approval or queueing consume the remaining budget? |
OGC SensorThings distinguishes phenomenon time from the time a result was generated. Its 2.0 specification also allows a service to assign current server time when an observation is posted without phenomenon time. The field name alone therefore does not prove that a device measured its own event timestamp. Review how the value was populated. [1]
This is a useful contract question: “Does this field come from the source event, a gateway or a server default?” Preserve the answer in the data schema and procurement record. If it is unknown, an agent can still calculate elapsed time from the supplied timestamp, but it cannot honestly call the result physical-observation age.
HTTP freshness is not a universal observation clock
RFC 9111 defines HTTP caching and the Age header in relation to stored responses and cache calculations. That machinery supports correct HTTP reuse. It does not create a universal timestamp for every physical measurement or financial observation contained in the response body. [2]
A newly generated API response may package older source data. Conversely, a cached response can be perfectly suitable for a task whose underlying information changes slowly. Avoid equating “cache miss” with new evidence or “cache hit” with unusable information. The task’s acceptance criterion and the payload’s semantics determine what matters.
Store delivery metadata alongside source metadata. An operations team may need request duration to diagnose its network and observation age to assess the decision. Combining both into one latency number makes it harder to identify whether the delay arose at the sensor, publisher, transport layer or consuming workflow.
Documented oracle fields require their own interpretation
Chainlink’s AggregatorV3Interface exposes updatedAt for a round. Keep that documented meaning when logging it. Do not silently rename it “exchange trade time” or “physical observation time.” A buyer comparing feeds should ask what source aggregation and publication process lies before the on-chain update. [4]
Chainlink’s feed overview also describes updates associated with heartbeat and deviation thresholds. A configured update mechanism is useful context, but it does not relieve the consuming application of checking whether the returned data meets its own requirements in the current state. This article does not measure an individual feed’s actual update distribution. [5]
Pyth Core’s getPriceNoOlderThan lets the caller supply an age bound and returns a price object including publishTime. That is a concrete example of an application declaring a freshness requirement. The cited API is Pyth Core, not Pyth Pro, and the existence of the method is not DN evidence that a specific deployment or trade passed its checks. [6]
These examples are deliberately not a provider ranking. Their fields represent events in particular systems. Comparing them fairly requires consistent source semantics, deployment details and observation windows. A nominally smaller elapsed number is not automatically better if it starts from a later event in the pipeline.
The DN age-budget model
Define S as the entered source timestamp, R as receipt, D as the decision point, B as the maximum permitted age and U as a combined bound on source/decision clock error. The model requires nominal ordering S ≤ R ≤ D. All calculations use elapsed time, not a provider’s marketing category.
Nominal age = D − S. Conditional age bounds are max(0, D − S − U) to D − S + U. The lower bound is clipped at zero because the model assumes the source event precedes the decision. The bounds are only as defensible as the timestamp meaning and the entered clock-error bound.
The budget classification is explicit. If the upper age bound is at most B, the item is within the declared budget. If the lower bound exceeds B, it exceeds the budget. Otherwise the boundary is uncertain. This is a statement about a user-selected age rule; it is not a statement that the data is accurate or an action is safe.
The tool also separates nominal source-to-receipt time, R − S, from receipt-to-decision time, D − R. Those two durations help locate where nominal age accumulated. They are not independently uncertainty-adjusted because the model does not ask for a separate receipt-clock error budget.
One example, three honest decisions
Suppose an illustrative source timestamp is 12:00:00 UTC, receipt is 12:00:04 and the decision point is 12:00:12. Nominal age is 12 seconds: four before receipt and eight inside the consuming workflow. With an assumed combined clock-error bound of three seconds, the conditional age interval is nine to 15 seconds.
| Illustrative age budget | Classification | Why |
|---|---|---|
| 15 seconds | Within the declared budget | The interval’s upper bound is exactly the inclusive limit. |
| 10 seconds | Boundary uncertain | The nine-to-15-second interval crosses the limit. |
| 8 seconds | Exceeds the declared budget | Even the lower bound is older than permitted. |
For the 10-second budget, remaining allowance ranges from minus five to plus one second. A negative lower allowance is useful information: under part of the stated uncertainty range, the budget is already exhausted. Hiding negative values would make the output easier to read but less honest.
None of these figures is a DN sensor measurement or a recommended trading threshold. The example demonstrates how a nominally precise timestamp can lead to an uncertain decision when the clocks are not perfectly aligned.
Choose a budget from the decision, not the sales page
A weather-history analysis, a customer-facing dashboard and an automated control action can need different freshness rules even when they buy the same feed. Define what becomes unacceptable as the source ages. The answer might concern changed conditions, contractual validity, a missed window or the need for a second confirmation.
Sometimes an age threshold is insufficient. A rapidly changing signal may need a change-rate bound or corroborating observation. A slowly changing but uncertain measurement may need better accuracy rather than faster delivery. A source that has stopped updating may need explicit unavailable status even if a recent last value remains accessible.
The original outline proposed pricing a universal data-decay curve. DN has not found evidence in this review that supports assigning such a curve across DePIN data. Monetary value depends on the task, alternatives, permission to reuse the data and cost of error. The defensible first instrument is an age-budget calculation whose assumptions a reader can inspect.
The local calculator and its boundaries
Enter a stream alias, decision, evidence reference, source-time meaning and three timestamps. The calculator accepts a deliberately narrow UTC format ending in Z, with optional millisecond precision, for years 2000–2100. RFC 3339 supports broader timestamp representations; using a narrower input subset here reduces ambiguous local-time interpretation. Convert offsets correctly before entry. [3]
Invalid calendar dates, unsupported leap seconds, missing numeric values and inconsistent nominal event ordering are rejected. Zero clock uncertainty must be entered explicitly and is labelled as an assumption. The tool does not test a clock or infer uncertainty from how many decimal places appear in a timestamp.
If source-time meaning is publication, round update, server assignment or unknown, the output retains that qualifier. The numerical budget result remains a result for the entered timestamp. It does not establish how old an earlier physical observation was. The JSON export preserves that distinction for downstream agents.
DN Data Age Budget Calculator
The tool checks a user-defined timestamp-age budget. It does not determine accuracy, financial suitability, a safe action or the monetary value of stale data.
Use non-sensitive descriptions. This tool makes no external requests and retains inputs only in temporary page memory. Downloading creates a local JSON file.
No calculation yet. Blank values are not zero.
Check freshness again at the actual point of use
An early check can expire while a workflow waits for approval or another dependency. Record the intended decision point and re-evaluate according to the application’s policy when the data is used. The consumer’s queue is part of the age budget even when the provider delivered promptly.
Keep a reason for rejected inputs. Missing source time, implausible ordering, an exceeded budget and unresolved clock error require different fixes. A retry may help with a temporarily stale publisher; it may do nothing for a schema that only reports receipt time. Repeatedly buying the same insufficient record can increase the API bill without improving the decision.
When later commissioning measurements, retain both accepted and rejected items and specify the sampling window. Report missing timestamps and unavailable responses alongside age statistics. A freshness distribution calculated only from successful responses can hide the operational condition that the buyer most needs to understand.
Methodology, limitations and change log
Edition 1.0, 11 November 2026. DN reviewed primary standards and provider API documentation and authored the interval model. No paid requests, oracle reads, clock comparisons or trading experiments were performed. The model handles a single source timestamp; interval observations, aggregation windows and multi-source joins require additional semantics.
The export uses dn.data-age-budget.v1, version 1.0.0, and records the documentation review date, local creation time, input basis, timestamp meanings and formulas. It contains user-entered facts or scenarios, not authenticated telemetry. The tool makes no external requests and does not authorize a downstream action.
Change log: Initial edition replaces an unsupported universal price-decay curve with a declared age-budget model. Review is required when cited field semantics or the model change. Send corrections identifying the field, version and evidence to press@decentralised.news.
Frequently asked questions
Is low latency the same as fresh data?
No. Delivery can be quick even when the payload describes an earlier event. Preserve the source timestamp and its meaning.
What if I only know when the API published the result?
Use publication time and label the output accordingly. The calculator will not relabel it as physical-observation age.
What does “boundary uncertain” mean?
The conditional age interval crosses the chosen limit. It does not quantify a probability of failure or prescribe an action.
Can the tool calculate a stale data point’s dollar value?
No. That requires a task-specific economic model and evidence that this review does not supply.
