---
title: "Veraltete Oracle-Preise"
description: "Ein Oracle-Preis ist für einen Verbraucher veraltet, wenn sein dokumentierter Aktualisierungszeitpunkt älter ist als das für die jeweilige Aktion zulässige Höchstalter; eine sichere Behandlung erfordert zudem Feed-Validierung, Sequencer-Prüfungen, Fallbacks und eine kontrollierte Wiederaufnahme."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Veraltete Oracle-Preise
> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.
## Direkte Antwort
Ein Oracle-Wert ist für eine bestimmte Verbraucheraktion veraltet, wenn `age = consumerClock - sourceTimestamp` das für diese Aktion konfigurierte `maxAge` überschreitet. Ein unveränderter Preis kann weiterhin aktuell sein, und ein kürzlich veröffentlichter Wert kann wirtschaftlich falsch sein. Der Verbraucher muss zunächst fehlende oder zukünftige Zeitstempel und ungültige Antworten ablehnen und anschließend eine Feed-, Asset-, Chain-, Handelszeiten- und aktionsspezifische Annahmerichtlinie anwenden.
Heartbeat und Abweichungsschwellen sind Auslöser für Veröffentlichungen, keine Aktualitätsgarantien oder Dienstgütevereinbarungen. Nach einem Auslöser kann sich ein Bericht verzögern; zugleich kann sich der Markt unterhalb der Schwelle bewegen, obwohl eine Aktion ein engeres Höchstalter verlangt. Pull-Oracles schaffen eine weitere Grenze: Vor dem Lesen muss der Aufrufer unter Umständen ein authentifiziertes Update einreichen, und der Vertrag muss Updates ablehnen, die älter als sein festgelegtes Limit sind.
Auf einer L2 bilden Sequencer-Status und Wartefrist nach der Wiederherstellung eine separate Schranke. Ihr Bestehen beweist weder einen aktuellen Asset-Preis noch Finalität der L2 oder gleichen Zugang für alle Nutzer. Fallback-Quellen und letzte gültige Preise sind kontrollierte Degradationsmodi, keine Wahrheit; jede Quelle und jeder Wiederherstellungspfad benötigt Einheiten, Zeitstempel, Unabhängigkeit, Berechtigungen, zulässige Aktionen und Abstimmungsregeln.
## Funktionsweise
1. Legen Sie Chain, Block und Uhr, Verbrauchervertrag und Aktion, Feed-Proxy und Aggregator, Asset-Paar und Dezimalstellen, Schnittstellenversion, Fallback-Konfiguration und Upgrade-Status fest.
2. Lesen Sie die exakte Antwort über die bereitgestellte Schnittstelle und behandeln Sie Reverts oder fehlende Daten. Prüfen Sie Antwort, Status oder Konfidenz, soweit einschlägig, sowie `sourceTimestamp != 0` und `sourceTimestamp <= consumerClock`, bevor Sie subtrahieren.
3. Erfassen Sie Heartbeat, Abweichung, Handelszeiten und Veröffentlichungskonfiguration und setzen Sie danach für jede Aktion ein unabhängiges `maxAge`. Definieren Sie die Grenze ausdrücklich, etwa Annahme bei `age <= maxAge` und Ablehnung bei `age > maxAge`.
4. Prüfen Sie bei unterstützten L2-Bereitstellungen Initialisierung und Status des Sequencer-Feeds, berechnen Sie anhand des dokumentierten Felds die Zeit seit der Wiederherstellung und erzwingen Sie die konfigurierte Wartefrist, bevor Sie die Preisaktualität separat prüfen.
5. Verfolgen Sie jede erforderliche Komponente zusammengesetzter Preise, Verhältnispreise und Fallbacks. Vereinheitlichen Sie Richtung und Einheiten und begrenzen Sie die effektive Aktualität durch die älteste notwendige Abhängigkeit, nicht den jüngsten Zeitstempel.
6. Definieren Sie pro Aktion Normal-, Degradations- und Pausenzustand. Neue Kreditaufnahme, Prägung oder Hebelung kann geschlossen fehlschlagen, während Rückzahlung oder zusätzliche Besicherung verfügbar bleibt; testen Sie veraltete, Fallback- und wiederaufgenommene Preise gegen Exposure, Liquidität und Keeper-Kapazität.
7. Überwachen Sie Quellen- und Proxy-Wechsel, Aktualisierungslatenz, Ablehnungsquoten, Sequencer-Status, Abweichungen zwischen Quellen und Handelszeiten; proben Sie Ausfall, Fallback-Versagen, Wiederherstellungssprung, konzentrierte Liquidationen, MEV, Ausfallkreditbuchung und Rückkehr in den Normalbetrieb.
Bei Chainlink-artigen Schnittstellen kann `latestRoundData()` eine Rundenkennung, eine vorzeichenbehaftete Antwort, Startzeit, Aktualisierungszeit und ein altes Rundenfeld liefern. Die aktuelle API bezeichnet `answeredInRound` als veraltet; eine historische Ungleichheitsprüfung darf deshalb nicht als allgemeingültige aktuelle Regel dargestellt werden. Maßgeblich sind der genaue Proxy, Aggregator und die konkrete Implementierung. Ein Zeitstempel bezeichnet die dokumentierte Aktualisierung des Feed-Zustands, nicht die Ausführbarkeit des Werts in beliebiger Größe. Soliditys `block.timestamp` ist der Zeitstempel des aktuellen Blocks innerhalb der Konsensgrenzen, keine externe Wanduhr.
## Rechenbeispiele
- **Höchstaltergrenze.** Es gelten `consumerClock = 1,800,000,000` und `sourceTimestamp = 1,799,999,100`, somit `age = 900 seconds = 15 minutes`. Eine Richtlinie mit `maxAge = 600 seconds` lehnt den Wert um `300 seconds` ab; mit `maxAge = 1,200 seconds` wird er mit `300 seconds` Spielraum angenommen. Derselbe Feed-Wert kann für eine Aktion gültig und für eine andere veraltet sein.
- **Auslöser ist keine Aktualität.** Der zuletzt veröffentlichte Preis beträgt `100.00`, die Abweichungsschwelle `1%` und der Heartbeat `3,600 seconds`. Nach `2,700 seconds` liegt ein beobachteter Marktpreis von `100.80` nur `0.8%` entfernt; keiner der didaktischen Auslöser wurde erreicht. Bei `101.20` beträgt die Abweichung `1.2%` und kann eine Veröffentlichung anstoßen, doch der Verbraucher liest weiterhin `100.00`, bis ein gültiger neuer Bericht aufgenommen wurde.
- **Doppelte L2-Schranke.** Ein Sequencer-Feed meldet den Betrieb mit `startedAt = 1,799,996,400`, `consumerClock = 1,800,000,000` und `grace = 3,600 seconds`; exakt `3,600 seconds` sind vergangen. Nach einer Richtlinie, die blockiert, solange `elapsed <= grace` gilt, bleibt die Aktion gesperrt und wird bei `3,601 seconds` zulässig. Zusätzlich müssen Preiszeitstempel, Antwort und alle weiteren Verbraucherprüfungen bestehen.
- **Wiederherstellungssprung.** Bei `10 ETH` Besicherung, `12,000 USD` Schulden und einer Liquidationsschwelle von `75%` ergibt der veraltete Wert von `2,000 USD/ETH` den Wert `healthFactor = 10 * 2,000 * 0.75 / 12,000 = 1.25`. Ein wiederaufgenommener Wert von `1,400 USD/ETH` ergibt `0.875`. Unter diesen Lehrannahmen wird das Konto liquidierbar; die Ausführung hängt jedoch weiterhin von Protokollregeln, Liquidität, Keepern, Gas, Reihenfolge und Chain-Verfügbarkeit ab.
## Risiken
- Falsche Chain, falscher Feed, Proxy, Aggregator, falsches Asset-Paar oder falsche Schnittstellenversion.
- Ein Verbraucher liest eine Antwort ohne Zeitstempel oder dokumentierten Status.
- Null- oder Zukunftszeitstempel beziehungsweise ein Subtraktionsunterlauf werden nicht abgelehnt.
- Das Höchstalter ist für Asset, Aktion, Handelszeiten oder Volatilität zu großzügig.
- Das Höchstalter ist zu eng und verursacht Dienstverweigerung oder verhindert Risikominderung.
- Heartbeat wird als garantierte Veröffentlichungsfrist oder Dienstgütevereinbarung behandelt.
- Unterschwellige Drift oder Basis akkumuliert, ohne den Abweichungsauslöser zu erreichen.
- Ein ausgelöster Bericht verzögert sich durch Quelle, Unterzeichner, Netzwerk, Gas, Relay oder Chain.
- Eine veraltete oder implementierungsspezifische Rundenprüfung wird universell angewandt.
- Änderungen an Feed, Proxy, Aggregator, Heartbeat, Abweichung oder Schnittstelle bleiben unbemerkt.
- Die Semantik geschlossener, pausierter oder feiertagsbedingt fortgeschriebener Marktdaten wird ignoriert.
- Ein zusammengesetzter oder Verhältnispreis wirkt aktuell, obwohl eine erforderliche Komponente veraltet ist.
- Der L2-Sequencer-Status wird ignoriert, ist nicht initialisiert, verspätet oder stammt aus dem falschen Netzwerk.
- Die Wartefrist fehlt, ist falsch konfiguriert oder weist einen Grenzfehler auf.
- Der Sequencer-Test besteht, obwohl der Asset-Preis veraltet oder nicht verfügbar bleibt.
- L1-Zeit, L2-Blockzeit, Beobachtungszeit, Veröffentlichungszeit und Wanduhr werden gleichgesetzt.
- Ein Pull-Update fehlt, ist zu alt, selektiv gewählt, fehlerhaft oder unzureichend finanziert.
- Ein Fallback oder letzter gültiger Wert ist veraltet, korreliert, anders skaliert oder zirkulär.
- Fail-open erlaubt unsichere Aktionen; pauschales Fail-closed sperrt hingegen Rückzahlung, Nachbesicherung oder geordnete Erholung.
- Wiederherstellungssprung, Liquidationsballung, MEV, dünne Liquidität, Pausenrennen oder Ausfallkreditabstimmung verursachen Folgeverluste.
## Häufige Missverständnisse
- **„Der Heartbeat garantiert in jedem Intervall ein aktuelles Update.“** Er ist eine Auslöserkonfiguration; Quellen- oder Chain-Ausfälle können die Veröffentlichung trotzdem verzögern.
- **„Ein aktueller Zeitstempel beweist einen richtigen ausführbaren Preis.“** Er belegt nur die dokumentierte Aktualisierungszeit; Quellenqualität, Einheiten, Konfidenz, Markttiefe und Verbraucherlogik bleiben getrennt.
- **„Ein Höchstalter passt für jeden Feed und jede Aktion.“** Assets, Handelszeiten, Chains sowie Kredit-, Liquidations-, Handels- und Abwicklungsaktionen haben unterschiedliche Latenz- und Verfügbarkeitsanforderungen.
- **„Sequencer in Betrieb heißt, dass alles sofort wieder anlaufen kann.“** Wartefrist und Preisaktualität sind unabhängige Schranken; weitere Protokoll- oder Chain-Regeln können hinzukommen.
- **„Fallback oder Revert jeder Funktion ist stets am sichersten.“** Ein schwacher Fallback bewertet Risiken falsch; ein pauschaler Ausfall kann Rückzahlung oder Verbesserung der Besicherung verhindern.
## Verwandte Themen
- [Oracle](/de/crypto/oracle/)
- [Oracle-Angriffe](/de/crypto/oracle-attack/)
- [Reaktion auf einen Sequencer-Ausfall](/de/crypto/sequencer-downtime-response/)
## Quellen
- [Chainlink Data Feeds](https://docs.chain.link/data-feeds) - Chainlink Documentation (abgerufen: 2026-08-13)
- [Data Feeds API Reference](https://docs.chain.link/data-feeds/api-reference) - Chainlink Documentation (abgerufen: 2026-08-13)
- [Developer Responsibilities](https://docs.chain.link/data-feeds/developer-responsibilities) - Chainlink Documentation (abgerufen: 2026-08-13)
- [L2 Sequencer Uptime Feeds](https://docs.chain.link/data-feeds/l2-sequencer-feeds) - Chainlink Documentation (abgerufen: 2026-08-13)
- [How to Use Real-Time Data in EVM Contracts](https://docs.pyth.network/price-feeds/core/use-real-time-data/pull-integration/evm) - Pyth Developer Hub (abgerufen: 2026-08-13)
- [Best Practices](https://docs.pyth.network/price-feeds/core/best-practices) - Pyth Developer Hub (abgerufen: 2026-08-13)
- [Units and Globally Available Variables](https://docs.soliditylang.org/en/latest/units-and-global-variables.html) - Solidity Documentation (abgerufen: 2026-08-13)
- [SC03:2026 Price Oracle Manipulation](https://scs.owasp.org/sctop10/SC03-PriceOracleManipulation/) - OWASP Smart Contract Security (abgerufen: 2026-08-13)
Source: https://wiki.fcontext.com/de/crypto/oracle-price-staleness/index.mdx