---
title: "Comment choisir une fenêtre TWAP"
description: "Choisissez la période TWAP en testant le coût de manipulation, la profondeur, le retard, les observations disponibles et la valeur à risque du protocole, plutôt qu'une durée universelle."
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.
# Comment choisir une fenêtre TWAP
> À des fins éducatives uniquement ; ceci ne constitue ni un conseil en investissement ni un conseil de sécurité. Un oracle de prix mal conçu peut provoquer de mauvaises liquidations, des prêts sous-collatéralisés et des pertes.
## Réponse directe
Il n'existe pas de fenêtre TWAP universellement sûre. Choisissez la **fenêtre la plus courte qui rende encore irréaliste une manipulation rentable pour le pool et le protocole concernés**, puis vérifiez que son retard reste acceptable lors d'un véritable mouvement. Une fenêtre plus longue oblige généralement l'attaquant à agir plus longtemps, mais conserve aussi les anciens prix plus longtemps. Elle ne compense ni une faible liquidité, ni une liquidité concentrée hors du parcours, ni une valeur à risque excessive, ni une intégration défectueuse.
Il s'agit d'un budget de risque, pas d'un choix entre 5 minutes, 30 minutes ou 1 heure. Documentez le pool et la moyenne, l'erreur et le délai maximaux, la valeur extractible, le coût d'attaque, l'historique disponible et le comportement de secours. Reprenez l'analyse si la liquidité, les incitations, la production des blocs, les plafonds de collatéral ou le marché changent.
## Fonctionnement
Un oracle à accumulateur enregistre le prix dans le temps. Pour un accumulateur arithmétique, la moyenne de `t1` à `t2` vaut :
`TWAP(t1,t2) = (cumulativePrice(t2) - cumulativePrice(t1)) / (t2 - t1)`
Uniswap v2 accumule le prix au début de chaque bloc et le consommateur conserve deux valeurs. Uniswap v3 conserve des observations de ticks cumulés ; convertir le tick moyen produit donc une moyenne **géométrique** pondérée dans le temps. Moyenne, sens de cotation, capacité, arrondi et mise à jour font partie de la spécification. Tous les TWAP ne sont pas une moyenne arithmétique d'échantillons spot.
Procédez ainsi :
1. **Définissez la fonction de perte.** Notez l'effet du prix sur l'emprunt, la liquidation, l'émission, le rachat ou le règlement, puis fixez erreur et retard maximaux à la hausse comme à la baisse.
2. **Mesurez la liquidité exécutable.** Modélisez réserves, frais et liquidité active sur tout le parcours de prix. TVL et volume récent ne prouvent pas à eux seuls la résistance.
3. **Bornez le gain de l'attaquant.** Incluez plafonds de collatéral et d'emprunt, bonus de liquidation, positions ouvertes, composabilité et profit avant pause. Comparez le coût à toute la valeur extractible.
4. **Modélisez les attaques réalisables.** Testez distorsions sur un ou plusieurs blocs, capital flash, contrôle du proposant ou de l'ordre, arbitrage, back-running, congestion et débouclage. La recherche montre que l'hypothèse d'un coût linéaire avec la fenêtre peut échouer face à un attaquant plus fort.
5. **Balayez les fenêtres candidates.** Simulez sauts historiques et parcours adverses pour chaque durée. Rejetez celles qui autorisent une manipulation rentable ou un prix trop ancien.
6. **Ajoutez des contrôles indépendants.** Employez plafonds d'exposition, tests d'écart à une référence indépendante, limites d'ancienneté, collatéral prudent et règles de pause ou de secours testées. Ils limitent les pertes sans rendre sûre une source dangereuse.
Le résultat dépend du pool, du palier de frais, de la chaîne, de l'implémentation, de la paire et de l'état du protocole. Copier 30 minutes ne copie ni la liquidité ni les limites de perte d'un autre protocole.
## Exemple
Supposons un TWAP arithmétique simplifié et un prix qui passe instantanément de `100` à `70`, puis reste à `70`. Après 15 minutes, la fenêtre glissante de 30 minutes contient 15 minutes à chaque prix :
`(15 x 100 + 15 x 70) / 30 = 85`
Après 30 minutes, les anciennes observations à `100` ont disparu et le TWAP atteint `70`. Une fenêtre de 5 minutes atteint `70` après 5 minutes, mais l'attaquant doit aussi maintenir la distorsion moins longtemps. Dans un marché de prêt, valoriser le collatéral près de `85` alors que le marché exécutable est près de `70` peut retarder la liquidation et créer une créance douteuse ; un autre usage peut accepter une valeur plus lente.
L'exemple isole seulement le retard, pas le coût de manipulation, et `85` ne vaut pas pour une moyenne géométrique. Une revue réelle doit rejouer la formule exacte avec observations, liquidité active, frais, séquence des blocs et positions.
## Risques et contrôles
- **Fenêtre trop courte :** quelques blocs déformés peuvent rentabiliser l'attaque. Renforcez source ou marché, réduisez l'exposition ou diversifiez la référence.
- **Fenêtre trop longue :** l'oracle retarde un saut réel, reporte les liquidations en baisse ou sous-évalue le collatéral en hausse. Mesurez le pire retard et restez prudent.
- **Liquidité mal mesurée :** la TVL peut être inactive, concentrée, unilatérale ou hors du parcours. Utilisez la profondeur exécutable aux ticks et prix pertinents.
- **Échec d'observation :** historique insuffisant, données anciennes, capacité non initialisée, mauvais temps, pool ou sens invalident le calcul. Faites échouer l'appel ou passez dans un état sûr documenté, sans substitution silencieuse.
- **Modèle d'attaquant incomplet :** liquidité flash, proposant multibloc, ordre et profits interprotocoles réduisent le coût net. Testez les hypothèses ; « frais multipliés par minutes » n'est pas une preuve.
- **Évolution du marché et de la gouvernance :** migration, frais, nouveau collatéral, plafonds, mise à niveau ou changement de chaîne peuvent invalider le test. Surveillez les entrées et imposez une nouvelle revue.
- **Échec du secours :** une source indépendante peut différer en couverture, décimales, délai et panne. Définissez pause, rejet, limite ou bascule et testez ce parcours on-chain.
Avant déploiement, publiez unités, sens, moyenne, fenêtre, historique minimal, critères du pool, plafonds et comportement en panne. Surveillez ensuite l'écart à la référence et les données économiques du modèle d'attaque.
## Idées reçues
- **« Plus long est toujours plus sûr. »** La durée d'attaque peut augmenter, mais aussi le retard ; une faible liquidité et un modèle incomplet restent inchangés.
- **« Un TWAP de 30 minutes est une garantie du secteur. »** La durée n'est qu'un paramètre avec profondeur, liquidité active, frais, blocs, formule et valeur à risque.
- **« Un prêt flash ne peut pas affecter un TWAP. »** Il supprime la contrainte de capital dans une transaction. Le résultat dépend de l'échantillonnage, de la part influençable et de la logique voisine.
- **« Une TVL élevée implique un coût de manipulation élevé. »** Seule la liquidité exécutable sur le parcours pertinent résiste directement à l'opération modélisée.
- **« Le TWAP est le prix actuel. »** Il moyenne les états on-chain historiques d'un marché précis, retarde volontairement et peut ne pas représenter le marché global.
## Sujets connexes
- [Pool de liquidité](/crypto/liquidity-pool/)
- [Liquidation](/crypto/liquidation/)
- [Attaques d'oracle](/crypto/oracle-attack/)
- [Prix d'oracle obsolètes](/crypto/oracle-price-staleness/)
- [Oracle TWAP](/crypto/oracle-twap/)
## Sources
- [Uniswap v2 Core](https://docs.uniswap.org/whitepaper.pdf) - Uniswap (consulté le 2026-08-21)
- [Uniswap v3 Core](https://app.uniswap.org/whitepaper-v3.pdf) - Uniswap (consulté le 2026-08-21)
- [Uniswap v3 TWAP Oracles in Proof of Stake](https://blog.uniswap.org/uniswap-v3-oracles) - Uniswap Labs (consulté le 2026-08-21)
- [TWAP Oracle Attacks: Easier Done than Said?](https://doi.org/10.1109/ICBC54727.2022.9805499) - IEEE (consulté le 2026-08-21)
Source: https://wiki.fcontext.com/fr/crypto/twap-window-selection/index.mdx