﻿---
title: "TWAP-Oracle"
description: "Ein TWAP-Oracle leitet aus protokollspezifischen kumulierten Beobachtungen eine zeitgewichtete Referenz ab; arithmetische v2-Preise und mittlere v3-Ticks unterscheiden sich mathematisch sowie bei Historie, Liquidität und Manipulationsgrenzen."
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.

# TWAP-Oracle

> Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

<a id="answer"></a>

## Direkte Antwort

Ein zeitgewichtetes Durchschnittspreis-Oracle leitet aus kumulierten Beobachtungen über ein festgelegtes Intervall eine Referenz ab. Es gibt keine universelle Formel. Uniswap v2 kumuliert den linearen marginalen Poolpreis in beiden Richtungen; Differenzen der Endpunkte ergeben arithmetische TWAPs. Uniswap v3 kumuliert den Tick als logarithmische Preiskoordinate; der arithmetische mittlere Tick entspricht einem geometrischen mittleren Relativpreis.

Das Ergebnis ist nur aussagekräftig, wenn Chain, Pool, Implementierung, Gebührenstufe, Tokenreihenfolge, Basis-/Notierungsrichtung, Dezimalstellen, Endpunkte, Zeitspanne, befüllte Historie und Rundung feststehen. Eine erfolgreiche Abfrage beweist weder Fair Value noch ausführbare Tiefe. Ein längeres Fenster verwässert kurze Verzerrungen, erhöht aber die Verzögerung und verhindert weder anhaltende Manipulation noch Lücken konzentrierter Liquidität, Kontrolle durch Proposer oder Sequencer, Reorgs oder einen Verbraucher, dessen abschöpfbarer Wert die Manipulationskosten übersteigt.

Beobachtungs- und Marktaktualität sind verschieden. Ein heute berechneter Durchschnitt kann bewusst ein altes Regime enthalten; ein aktiver Pool kann dünn oder von externen Märkten entkoppelt sein. Verbraucher benötigen daher Historien-, Liquiditäts- und Abweichungsprüfungen, aktionsspezifische Grenzen und definiertes Degradations- oder Pausenverhalten.

<a id="mechanism"></a>

## Funktionsweise

1. Legen Sie Chain und Block, Factory und Pooladresse, Protokollversion und Gebührenstufe, `token0` und `token1`, Dezimalstellen, Basis-/Notierungsrichtung, Verbraucheraktion, Fenster und gefährdeten Wert fest.
2. Bestimmen Sie kumuliertes Objekt und Einheiten: lineares v2-`price0Cumulative` oder `price1Cumulative`, v3-`tickCumulative` oder eine dokumentierte andere Statistik. Übertragen Sie keine Arithmetik zwischen Implementierungen.
3. Prüfen Sie Endpunktzeitstempel, positive Zeitspanne, älteste initialisierte Historie, aktuelle Kardinalität und Interpolations- oder kontrafaktische Regeln. `observationCardinalityNext` ist Zielkapazität, keine bereits befüllte Historie.
4. Teilen Sie bei v2 die Änderung des kumulierten Preises durch die Sekunden und normieren Sie Festkommaeinheiten und Token-Dezimalstellen. Berechnen Sie jede Richtung separat; ein umgekehrter arithmetischer TWAP ist gewöhnlich nicht der Kehrwert des direkten.
5. Rufen Sie bei v3 die dokumentierte Beobachtungsschnittstelle auf, teilen Sie die Änderung des kumulierten Ticks durch das Fenster, runden Sie einen negativen nicht exakten Quotienten wie `OracleLibrary` gegen minus unendlich und bilden Sie mit `price = 1.0001^tick` eine normierte Notierung.
6. Messen Sie aktuelle In-Range-, harmonische, Wide-Range-, Gebührenstufen- und externe Liquidität. Testen Sie Ein- und Mehrblockpfade, Gebühren, Arbitrage, Reihenfolge, Zensur, Rückabwicklung, Reorgs, Verzögerung und abschöpfbaren Verbraucherwert.
7. Vergleichen Sie TWAP, Spot und unabhängige Referenzen unter expliziten Aktualitäts- und Abweichungsgrenzen; überwachen Sie Historie, Liquiditätsbereiche, Pool-Upgrades und Chain-Zustand und proben Sie unzureichende Historie, Divergenz, Pause, Fallback, Liquidation und Erholung.

Uniswap v2 speichert zwei gerichtete kumulierte Werte. Uniswap v3 speichert Beobachtungen in einem Ringpuffer und kann interpolieren oder einen aktuellen kontrafaktischen kumulierten Wert konstruieren. Solche Endpunkte sind gültige Protokollarithmetik, aber kein Nachweis eines Handels zu diesem Zeitpunkt. Mehr Kardinalität schafft Raum für künftige Beobachtungen, füllt Vergangenes jedoch nicht auf.

<a id="example"></a>

## Rechenbeispiele

- **Kumulierter v2-Preis.** Bei `C_start = 1,000,000 price-seconds`, `C_end = 1,360,000 price-seconds` und `elapsed = 3,600 seconds` gilt `TWAP = (1,360,000 - 1,000,000) / 3,600 = 100 quote/base`. Endpunkte, Richtung, Skala und Zeitstempel gehören zum Ergebnis.
- **Kehrwertfalle.** Ein direkter Preis beträgt `100` für `900 seconds` und `400` für `900 seconds`; sein arithmetischer TWAP ist `250`. Umgekehrte Spots sind `0.01` und `0.0025`; deren TWAP ist `0.00625`, sein Kehrwert `160`, nicht `250`. Mittelwert und Kehrwertbildung kommutieren nicht.
- **Negativer mittlerer Tick.** Sei `tickCumulativeDelta = -39,601` über `3,600 seconds`. Solidezimaldivision kürzt mit Rest auf `-11`, der v3-Helper rundet aber auf `meanTick = -12` ab. Der geometrische Relativpreis ist `1.0001^-12 = 0.998800779636`. Vorzeichen- oder Rundungsfehler verzerren die Notierung systematisch.
- **Verwässerung und Verzögerung.** Ein Pool steht bei `100` für `1,740 seconds` und bei `400` für `60 seconds` in einem `1,800-second`-Fenster. Der v2-artige arithmetische TWAP beträgt `(100 * 1,740 + 400 * 60) / 1,800 = 110`; das v3-artige geometrische Mittel `100^(29/30) * 400^(1/30) = 104.7294122821`. Beide unterscheiden sich vom Spot `400` und voneinander; keiner benennt allein Manipulationskosten oder ausführbare Größe.

<a id="risks"></a>

## Risiken

- Falsche Chain, Factory, Pool, Gebührenstufe, Implementierung oder Upgrade-Status.
- Vertauschte Basis-/Notierungsrichtung oder `token0`/`token1`.
- Falsche Token-Dezimalstellen, Festkommaskala oder Notierungsnormierung.
- Arithmetischer v2- und geometrischer v3-Preis werden gleichgesetzt.
- Umgekehrter TWAP wird als Kehrwert des direkten berechnet.
- Falsche Endpunkte, Zeitspanne, Fenstergrenze oder aktueller Block.
- Null-, negative, umlaufende oder implementierungsspezifische Zeitarithmetik wird falsch behandelt.
- Angeforderte Historie liegt vor der ältesten initialisierten Beobachtung.
- `observationCardinalityNext` wird mit befüllter `observationCardinality` verwechselt.
- Interpolierte oder kontrafaktische Beobachtungen gelten fälschlich als Trades.
- Negativer Tick wird gegen null statt minus unendlich gerundet.
- Tickumrechnung, Ganzzahlbereich, Overflow oder Rundung sind unsicher.
- Aktive In-Range- oder harmonische Liquidität ist für das Exposure zu dünn.
- Wide-Range-Tiefe fehlt, wird entfernt oder in der Analyse ignoriert.
- Liquidität ist über Pools, Gebührenstufen, Chains oder Märkte fragmentiert.
- Kurzes Fenster bleibt für Einblock-, atomare oder vorübergehende Manipulation sensibel.
- Langes Fenster hinkt echter Neubewertung, Depeg oder Liquiditätsmigration nach.
- Mehrblock-Proposer, Sequencer, Zensur, MEV oder Reorg erhöhen die Kontrolle.
- TWAP gilt ohne Abweichungs- und Tiefenprüfung als aktueller Fair Value oder ausführbarer Preis.
- Exposure übersteigt Manipulationskosten und Fallback-, Pausen- oder Erholungsverhalten ist unsicher.

<a id="misconceptions"></a>

## Häufige Missverständnisse

- **„TWAP bedeutet immer arithmetischen Preismittelwert.“** v3 mittelt Ticks und erzeugt einen geometrischen mittleren Relativpreis.
- **„Die umgekehrte Notierung ist stets eins durch den direkten TWAP.“** Für separat gemittelte lineare Preise gilt diese Symmetrie nicht.
- **„Ein längeres Fenster macht Manipulation unmöglich.“** Es tauscht Empfindlichkeit für kurze Verzerrungen gegen Verzögerung und bleibt bei anhaltender Kontrolle beeinflussbar.
- **„Mehr Kardinalität erzeugt sofort mehr Historie.“** Sie erhöht nur künftige Kapazität; Beobachtungen müssen erst initialisiert werden.
- **„Eine aktuelle erfolgreiche Abfrage beweist ausführbaren Fair Value.“** Schnittstellenerfolg belegt weder wirtschaftliche Aktualität noch Tiefe, Unabhängigkeit oder sicheres Exposure.

<a id="related"></a>

## Verwandte Themen

- [Automatisierter Market Maker](/de/crypto/amm/)
- [Oracle-Angriffe](/de/crypto/oracle-attack/)
- [Veraltete Oracle-Preise](/de/crypto/oracle-price-staleness/)

<a id="sources"></a>

## Quellen

- [Uniswap v2 Core](https://app.uniswap.org/whitepaper.pdf) - Uniswap (abgerufen: 2026-08-13)
- [Oracles](https://developers.uniswap.org/docs/protocols/v2/concepts/oracles) - Uniswap Developers (abgerufen: 2026-08-13)
- [Uniswap v3 Core](https://uniswap.org/whitepaper-v3.pdf) - Uniswap (abgerufen: 2026-08-13)
- [Price Oracles](https://developers.uniswap.org/docs/protocols/v3/concepts/price-oracles) - Uniswap Developers (abgerufen: 2026-08-13)
- [Oracle.sol](https://github.com/Uniswap/v3-core/blob/main/contracts/libraries/Oracle.sol) - Uniswap v3 Core (abgerufen: 2026-08-13)
- [OracleLibrary.sol](https://github.com/Uniswap/v3-periphery/blob/main/contracts/libraries/OracleLibrary.sol) - Uniswap v3 Periphery (abgerufen: 2026-08-13)
- [Uniswap v3 TWAP Oracles in Proof of Stake](https://blog.uniswap.org/uniswap-v3-oracles) - Uniswap Labs (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-twap/index.mdx
