出典確認済みリサーチ: PYTH Chainlink Oracle Freshness
本文は確認済みの英語原文で表示しています。翻訳版は出典確認後に追加します。
Verified Fact Boundary
1. Pyth best-practices documentation discusses confidence intervals for price feeds. 2. Pyth price-data documentation explains price-data fields and feed update information. 3. Chainlink Data Feeds documentation describes Data Feeds as an official price-feed surface. 4. Chainlink Data Feeds API reference documents latestRoundData fields including timestamps used for freshness checks. 5. A price value without freshness and uncertainty context is not enough for collateral, liquidation, settlement or user-facing risk decisions. 6. Public oracle documentation does not prove a particular application selected the correct feed, threshold, fallback or emergency pause rule.
閉じる
Decision Matrix
記事の表：横にスクロールするか、表の領域にフォーカスして矢印キーを使ってください。
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Freshness timestamp | publish time or updatedAt is the first control for deciding whether data can still be used | store feed timestamp and local read timestamp before acting on the value | chain latency, delayed publishers and application-specific freshness tolerance |
| Uncertainty field | confidence interval or deviation context explains uncertainty around the reported value | surface uncertainty alongside price instead of displaying price as a guarantee | how each app translates confidence into collateral or liquidation policy |
| Heartbeat threshold | feed update cadence can be threshold-driven rather than continuous | record the expected update trigger and stale-data cutoff for the feed | market closure, outage behavior and feed-specific heartbeat values |
| Fallback route | a fallback can protect users only if it is written before the primary source fails | define fallback source, pause rule and reconciliation requirement in advance | whether fallback data has equal rights, precision and manipulation resistance |
| Stop condition | oracle data must not be used when freshness, uncertainty or feed identity is unknown | pause pricing, liquidation or user action when timestamp or uncertainty evidence is missing | future feed migration, publisher set changes and app-level emergency governance |
Source Map
- Pyth Developer Hub: Best Practices (pyth-best-practices)
- Pyth Developer Hub: Understanding Price Data (pyth-understanding-price-data)
- Chainlink Documentation: What are Chainlink Data Feeds? (chainlink-data-feeds-overview)
- Chainlink Documentation: Data Feeds API Reference (chainlink-data-feeds-api)
Control Notes
1. Freshness timestamp
Freshness timestamp is the point where public documentation must become an operating rule. In this package, it means publish time or updatedAt is the first control for deciding whether data can still be used. The practical action is to store feed timestamp and local read timestamp before acting on the value. The unresolved edge is chain latency, delayed publishers and application-specific freshness tolerance, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
2. Uncertainty field
Uncertainty field is the point where public documentation must become an operating rule. In this package, it means confidence interval or deviation context explains uncertainty around the reported value. The practical action is to surface uncertainty alongside price instead of displaying price as a guarantee. The unresolved edge is how each app translates confidence into collateral or liquidation policy, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
3. Heartbeat threshold
Heartbeat threshold is the point where public documentation must become an operating rule. In this package, it means feed update cadence can be threshold-driven rather than continuous. The practical action is to record the expected update trigger and stale-data cutoff for the feed. The unresolved edge is market closure, outage behavior and feed-specific heartbeat values, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
4. Fallback route
Fallback route is the point where public documentation must become an operating rule. In this package, it means a fallback can protect users only if it is written before the primary source fails. The practical action is to define fallback source, pause rule and reconciliation requirement in advance. The unresolved edge is whether fallback data has equal rights, precision and manipulation resistance, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
5. Stop condition
Stop condition is the point where public documentation must become an operating rule. In this package, it means oracle data must not be used when freshness, uncertainty or feed identity is unknown. The practical action is to pause pricing, liquidation or user action when timestamp or uncertainty evidence is missing. The unresolved edge is future feed migration, publisher set changes and app-level emergency governance, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, safety guarantee, recovery promise, platform ranking or price implication.
The operating test is narrow.
Known Unknowns
- chain latency, delayed publishers and application-specific freshness tolerance
- how each app translates confidence into collateral or liquidation policy
- market closure, outage behavior and feed-specific heartbeat values
- whether fallback data has equal rights, precision and manipulation resistance
- future feed migration, publisher set changes and app-level emergency governance
Practical Takeaway
Oracle readiness depends on freshness and uncertainty controls, not only on whether a price endpoint returns a number. Pyth documents confidence intervals and price-data fields, while Chainlink documents Data Feeds and an API reference where latestRoundData includes update timestamps. The radar outcome is to record publish time, confidence or deviation meaning, heartbeat or update threshold, stale-data rule, fallback route and action stop condition before relying on a feed for collateral, liquidation, pricing or user display. The article stops at the evidence boundary. It helps the reader decide what to inspect next without converting public documentation into a promise that a private account, wallet, API key, pool route, stablecoin balance, tokenized asset or policy framework will work under every future condition.