Après la chute, quel type d'oracle avons-nous besoin ?
TechFlow SélectionTechFlow Sélection
Après la chute, quel type d'oracle avons-nous besoin ?
Quand l'oracle présente une fissure, toutes les structures supérieures s'effondrent.
Dédié à des analyses Web3 approfondiesAuteur :YQ
Traduction : TechFlow
Les 10 et 11 octobre 2025, une vente massive de 60 millions de dollars sur le marché au comptant a détruit une valeur de 19,3 milliards de dollars. Ce n’était pas dû à un effondrement du marché, ni à une série de liquidations en chaîne causées par des positions réellement endettées, mais à une défaillance d’oracle.
Ce n’est pas nouveau. Depuis février 2020, ce même schéma d’attaque a été exploité à plusieurs reprises avec succès, provoquant des dizaines d’incidents dans le secteur et entraînant des pertes s’élevant à plusieurs centaines de millions de dollars. L’incident d’octobre 2025 a toutefois amplifié l’échelle de la plus grande attaque par oracle précédente d’un facteur 160 — non pas en raison d’une complexité technique accrue, mais parce que les systèmes sous-jacents se sont étendus tout en conservant les mêmes vulnérabilités fondamentales.
Pendant cinq ans, nous avons payé un prix élevé pour notre apprentissage, sans jamais tirer les leçons. Cet article analysera pourquoi.
Le dilemme des oracles : sensibilité contre stabilité
Toute plateforme utilisant l’effet de levier fait face à un défi fondamental : comment évaluer précisément les garanties tout en empêchant la manipulation des prix ?
-
Trop sensible → vulnérable aux attaques de manipulation
-
Trop stable → incapable de refléter rapidement les pertes réelles
L’incident d’octobre 2025 a choisi la « sensibilité ». L’oracle suivait fidèlement les prix du marché au comptant ; lorsque 60 millions de dollars d’actifs ont été vendus, l’oracle a immédiatement baissé le prix des garanties, déclenchant des liquidations massives. Le système fonctionnait exactement comme conçu.
Cependant, cette conception s’est avérée désastreuse.
Un schéma ignoré depuis cinq ans
Avant d’analyser l’incident d’octobre 2025, il faut comprendre : cette situation n’est pas inédite.
Rappel des événements antérieurs (2020-2022)
Février 2020 : bZx (pertes de 350 000 $ + 630 000 $) Utilisation d’un oracle basé sur une seule source de données. Manipulation du prix du WBTC sur Uniswap via un prêt flash. 14,6 % de l’offre totale déplacée pour manipuler les données de prix dont dépendait bZx.
Octobre 2020 : Harvest Finance (24 millions de dollars volés, ruée de 570 millions) En seulement 7 minutes, utilisation d’un prêt flash de 50 millions de dollars pour manipuler le prix des stablecoins sur Curve. Effondrement des infrastructures et retrait massif de liquidités, avec des pertes bien supérieures au montant initial du vol.
Novembre 2020 : Compound (liquidations atteignant 89 millions de dollars) Le DAI a brièvement grimpé à 1,30 dollar sur Coinbase Pro, uniquement sur cet échange. L’oracle de Compound étant basé sur ce prix, des utilisateurs ont été liquidés à cause d’une anomalie temporaire. Une manipulation coûtant 100 000 dollars suffisait à influencer un carnet d’ordres profond de 300 000 dollars.
Octobre 2022 : Mango Markets (pertes de 117 millions de dollars) À partir d’un capital initial de 5 millions de dollars, le prix du jeton MNGO a été gonflé de 2394 % sur plusieurs plateformes. Puis, 117 millions de dollars ont été empruntés grâce à des garanties élevées, et des jetons de gouvernance volés ont servi à voter pour obtenir une « prime de bug bounty » de 47 millions de dollars. Première action réglementaire de la CFTC américaine contre la manipulation d’oracle.
Points communs
Chaque attaque suit la même logique :
-
Identifier une source de données manipulable utilisée par l’oracle
-
Calcul : coût de la manipulation < valeur récupérable
-
Mener l’attaque
-
Empocher le profit
De 2020 à 2022 : 41 attaques par manipulation d’oracle, entraînant le vol de 403,2 millions de dollars.
Réaction du secteur : réponses éparses, tardives et incomplètes. La plupart des plateformes continuent d’utiliser des oracles insuffisamment redondants, centrés sur le marché au comptant.
Puis, l’incident d’octobre 2025 est survenu.
Anatomie de la panne d’oracle : version 2025
10 octobre 2025, 5h43 du matin : 60 millions de dollars de USDe vendus sur le marché au comptant.
Dans un oracle bien conçu : plusieurs sources indépendantes absorberaient le choc, avec un impact négligeable.
Dans cet oracle : un désastre s’est produit.
Vente de 60 millions de dollars → Baisse du prix des garanties par l’oracle (wBETH, BNSOL, USDe) → Déclenchement de liquidations massives → Surchauffe des infrastructures → Manque de liquidité → Évaporation de 19,3 milliards d’actifs
Effet d’amplification
-
Mango Markets (2022) : Manipulation de 5 millions → Extraction de 117 millions (facteur 23)
-
Octobre 2025 : Manipulation de 60 millions → Destruction de 19,3 milliards (facteur 322)
Cela n’est pas dû à une complexité technique accrue, mais à l’élargissement de la même vulnérabilité à une échelle institutionnelle.
Problème de pondération
L’oracle dépendait fortement des prix au comptant des principaux échanges. Lorsqu’un échange domine le volume :
-
Haut volume donne l’apparence d’une découverte de prix fiable (raisonnement superficiel)
-
Centralisation augmente le risque de manipulation (faiblesse fatale)
-
Prix interne unique crée une boucle autoréférentielle (problème aggravé)
Un commentaire d’analyste expose cette erreur logique : « Comme [cet échange] a le plus gros volume pour usde/bnsol/wbeth, selon la pondération de l’oracle, il devrait se baser sur les prix au comptant. »
Cette intuition — croire au plus grand marché — a déjà coûté des milliards ces cinq dernières années. La concentration des volumes n’est pas preuve d’exactitude des prix, mais signal d’opportunité de manipulation.
Fenêtre de vulnérabilité planifiée
La mise à jour de la méthode de l’oracle avait été annoncée huit jours auparavant. Les attaquants disposaient donc de :
-
Dépendances de l’oracle
-
Date prévisible de transition
-
Huit jours de préparation
Les attaques passées exploitaient des vulnérabilités existantes ; celle d’octobre 2025 a exploité une faille pendant le changement de méthode d’oracle — une faille qui n’existait que parce que l’amélioration avait été annoncée à l’avance.
Test d’isolement des lieux
La preuve la plus claire que cet incident résultait d’une défaillance d’oracle, et non d’une perte réelle d’actifs :
-
Principaux échanges : Prix du USDe à 0,6567 $, wBETH à 430 $
-
Autres plateformes : Écart inférieur à 30 points de base
-
Pools de liquidité on-chain : Impact négligeable
Comme souligné par Guy d’Ethena : « Pendant l’incident, plus de 9 milliards de dollars de garanties en stablecoins restaient immédiatement rachetables. »
Les prix ont fortement fluctué sur les échanges sources des données de l’oracle, mais sont restés stables ailleurs. L’oracle a rapporté des prix manipulés, et le système a déclenché des liquidations basées sur des prix inexistant ailleurs sur le marché.
C’est exactement le même schéma que l’incident Compound de 2020 : manipulation isolée des prix sur un lieu, enregistrée fidèlement par l’oracle, entraînant une destruction systémique.
Réaction en chaîne infrastructurelle
L’analyste agintender a identifié le mécanisme d’amplification :
« Les liquidations en chaîne ont saturé les serveurs avec des millions de requêtes. Les market makers n’ont pas pu répondre à temps, créant un vide de liquidité. »
C’est une version agrandie de l’incident Harvest Finance en 2020. L’attaque déclenche des liquidations plus vite que l’infrastructure ne peut traiter. Les market makers ne peuvent pas réagir, la liquidité disparaît, et la réaction en chaîne s’auto-renforce.
Après l’effondrement infrastructurel de Harvest Finance en octobre 2020 (TVL tombé de 1 à 599 millions de dollars, afflux de retraits), la leçon était claire : les systèmes d’oracle doivent tenir compte de la capacité des infrastructures lors d’événements de stress.
Pourtant, l’incident d’octobre 2025 prouve que nous n’avons rien appris.
Compromis de sensibilité : deux méthodes, une catastrophe
Guy d’Ethena a clarifié le défi central de conception : l’oracle doit distinguer les écarts temporaires courts (bruit de marché) des pertes réelles durables (dommages réels).
Octobre 2025 a montré deux approches :
Approche haute sensibilité (échanges ayant échoué)
-
Suit en temps réel les prix au comptant
-
Répond rapidement aux variations du marché
-
Résultat : effet en chaîne de 19,3 milliards
C’est la méthode de bZx/Harvest : faire confiance au marché au comptant, puis être détruit par manipulation.
Approche haute stabilité (plateformes DeFi ayant survécu)
-
Fixation manuelle USDe = USDT
-
Ignore le bruit de marché à court terme
-
Résultat : aucune liquidation
C’est une solution excessive, meilleure que l’échec, mais loin d’être optimale.
L’industrie a eu cinq ans pour concevoir des solutions nuancées. Nous n’avons trouvé ni la meilleure, ni même une solution acceptable — nous sommes coincés entre deux extrêmes, et à l’échelle institutionnelle, nous avons choisi la voie catastrophique.
Théorème de l’attaque par oracle : désormais prouvé expérimentalement
Théorème : Dans tout système à effet de levier où :
-
L’oracle dépend principalement de marchés au comptant manipulables
-
Les conditions de liquidation sont déterministes
-
L’infrastructure a des limites de capacité
Alors : coût de la manipulation < valeur extractible via effet en chaîne
Preuve validée par pratique répétée :
-
bZx (février 2020) : Manipulation d’Uniswap → extraction de 350 000 $ + 630 000 $
-
Harvest (octobre 2020) : Manipulation de Curve → vol de 24 millions $ + ruée bancaire de 570 millions
-
Compound (novembre 2020) : Manipulation de Coinbase → liquidations de 89 millions $
-
Mango (octobre 2022) : Manipulation multi-plateforme → extraction de 117 millions $
-
Octobre 2025 : Manipulation du principal échange → perte de 19,3 milliards $
Avec une croissance linéaire du système, les dommages croissent exponentiellement. Le coût de manipulation reste quasiment constant (déterminé par la liquidité), mais la valeur extractible augmente avec l’effet de levier total du système.
Octobre 2025 a validé ce théorème à une échelle sans précédent.
Principes de conception d’oracle : les leçons que nous aurions dû tirer
-
Vérification multiple
Ne jamais dépendre du prix d’un seul échange, surtout si issu de son propre carnet d’ordres. C’est la leçon de bZx en février 2020. Une conception d’oracle raisonnable nécessite :
Prix de l’oracle = moyenne pondérée de sources multiples :
-
Prix de plusieurs échanges (40 %)
-
Pools de liquidité on-chain (30 %)
-
Taux de conversion des actifs wrappés (20 %)
-
Prix historique pondéré temporellement (10 %)
La répartition des poids importe moins que l’indépendance des sources. Si toutes les sources peuvent être manipulées simultanément par un capital raisonnable, alors vous n’avez en réalité qu’une seule source, pas plusieurs.
-
Sensibilité adaptative
L’oracle doit ajuster sa sensibilité selon les conditions du marché :
-
Marché normal : plus sensible aux variations de prix
-
Marché volatile : stabilité accrue via moyenne temporelle
-
Volatilité extrême : mécanismes de coupure et vérifications de cohérence
Les oracles TWAP (prix moyen pondéré temporellement) ont été largement adoptés après les attaques par prêt flash de 2020, spécifiquement pour éviter la manipulation par transaction unique. Pourtant, l’oracle d’octobre 2025 réagissait en temps réel aux prix au comptant, comme si ces cinq dernières années n’avaient jamais existé.
-
Résilience infrastructurelle
Le système d’oracle doit rester opérationnel durant les événements en chaîne :
-
Infrastructure indépendante pour les données de prix
-
Capacité à supporter des millions de requêtes concurrentes
-
Mécanismes de dégradation progressive en cas de surcharge
L’effondrement infrastructurel de Harvest Finance en octobre 2020 avait déjà mis en lumière l’importance de la capacité sous pression. Les liquidations en chaîne génèrent une charge exponentielle. Votre infrastructure doit supporter non seulement la première liquidation, mais aussi la 1000e quand les market makers ne suivent plus et que les utilisateurs paniquent.
-
Transparence sans faille
Une fenêtre de 8 jours entre annonce et mise en œuvre crée un vecteur d’attaque connu. De meilleures pratiques incluent :
-
Mettre en œuvre immédiatement après annonce
-
Utiliser des mises à jour progressives sans date fixe
-
Conserver les journaux d’audit mais éviter les périodes de prévisualisation
C’est une nouvelle leçon, mais logique d’un point de vue théorique des jeux : ne jamais annoncer à l’avance un changement exploitable. Les attaquants d’octobre 2025 ont eu 8 jours pour planifier, positionner et préparer. Ils savaient exactement quand la fenêtre de vulnérabilité s’ouvrirait.
Impact systémique : les leçons non encore assimilées
Il ne s’agit pas seulement de l’échec d’une plateforme isolée, mais de la révélation d’une vulnérabilité généralisée dans tout le secteur, toujours non résolue malgré cinq années d’apprentissage coûteuses :
-
Dépendance excessive aux prix au comptant
Malgré le fait que chaque attaque majeure depuis 2020 ait exploité cette faille, la plupart des plateformes utilisent encore des oracles centrés sur le marché au comptant. Le secteur sait que les prix au comptant sont manipulables, connaît les protections offertes par les oracles TWAP ou multisources, mais l’implémentation reste incomplète.
La rapidité et la sensibilité sont des atouts en conditions normales, mais deviennent des défauts fatals lors de manipulation. La mise à jour en temps réel semble plus précise — jusqu’à ce que quelqu’un la manipule.
-
Risque de concentration
Les principaux échanges deviennent des points de défaillance unique. Cela s’est vu avec bZx dépendant d’Uniswap, Compound de Coinbase, et la plateforme d’octobre 2025 dépendant de son propre carnet d’ordres. Les échanges changent, mais la vulnérabilité reste identique.
Quand un échange domine le volume, le prendre comme source principale semble logique. Pourtant, le risque de concentration des données de prix est comme tout risque de centralisation : inoffensif jusqu’à exploitation, puis désastreux.
-
Hypothèses infrastructurelles
Les systèmes conçus pour le marché normal s’effondrent sous pression. Harvest Finance l’a démontré en 2020, et octobre 2025 le redémontre : nous continuons de concevoir pour le normal, en espérant que la pression n’arrivera jamais.
L’espoir n’est pas une stratégie.
-
Paradoxe de la transparence
Publier des améliorations crée une fenêtre d’attaque. L’intervalle de 8 jours entre annonce et mise en œuvre des oracles a donné aux attaquants une feuille de route claire. Ils savaient exactement quand frapper et comment exploiter la faille.
C’est un nouveau mode d’échec, mais le problème fondamental demeure. Les attaques passées exploitaient des vulnérabilités existantes ; celle d’octobre 2025 a exploité une faille durant le changement de méthode d’oracle — une faille qui n’existait que parce que l’amélioration avait été annoncée à l’avance.
Voie à suivre : cette fois, avons-nous vraiment appris ?
Améliorations immédiates
-
Conception hybride d’oracle combinant plusieurs sources de prix et des vérifications de cohérence efficaces :
-
Prix des bourses centralisées (pondérés par volume)
-
Prix des DEX (uniquement pour les pools très liquides)
-
Preuves de réserves on-chain
-
Limites d’écart entre bourses
Chaque source doit être indépendante. Si la manipulation d’une source affecte les autres, il n’y a pas de redondance.
-
Ajustement dynamique des poids modulant la sensibilité selon les conditions du marché :
-
Volatilité normale : poids standards
-
Haute volatilité : fenêtre TWAP étendue, réduction de l’impact au comptant
-
Volatilité extrême : suspension des liquidations, enquête avant action
L’attaque de Compound montre que parfois, le prix « correct » sur un seul échange peut être faux pour le marché global. Votre oracle doit être assez intelligent pour le détecter.
-
Mécanisme de coupure suspendant les liquidations en cas de forte volatilité — non pour empêcher la désendettement légitime, mais pour distinguer manipulation et réalité du marché :
-
Si les prix convergent entre plateformes en quelques minutes : probablement réel
-
Si la variation est localisée à un seul lieu : probablement manipulation
-
Si l’infrastructure est saturée : suspendre les liquidations jusqu’au rétablissement
L’objectif n’est pas d’empêcher toutes les liquidations, mais celles déclenchées par des prix manipulés en chaîne.
-
Extension infrastructurelle concevoir des systèmes capables de supporter 100 fois la charge normale, car les effets en chaîne produisent ce niveau de charge :
-
Infrastructure indépendante pour les données de prix
-
Moteur de liquidation indépendant
-
Limitation de débit par adresse
-
Protocoles de dégradation progressive
Si votre système ne supporte pas la charge pendant une cascade, il amplifie la cascade. C’est une exigence de conception, pas une option d’optimisation.
Solutions à long terme
-
Réseaux d’oracles décentralisés adopter des solutions matures comme Chainlink, Pyth ou UMA, qui agrègent plusieurs sources et intègrent des mécanismes anti-manipulation. Elles ne sont pas parfaites, mais valent mieux que des oracles basés sur le spot exploités tous les 18 mois.
Après l’attaque de 2020, bZx a intégré Chainlink. Il n’a plus subi d’attaques via manipulation d’oracle. Ce n’est pas un hasard.
-
Intégration de preuves de réserve pour les actifs wrappés et stablecoins : valoriser les garanties via des réserves vérifiables, pas via la dynamique du carnet d’ordres. La technologie existe, mais l’adoption tarde.
-
Liquidations progressives évitant l’amplification des cascades par étapes :
-
Phase 1 : alerte et délai pour ajouter des garanties
-
Phase 2 : liquidation partielle (25 %)
-
Phase 3 : liquidation plus large (50 %)
-
Phase finale : liquidation complète
Cela donne du temps aux utilisateurs de réagir et réduit le choc sur le système d’une liquidation massive simultanée.
-
Audit en temps réel surveillant les comportements de manipulation d’oracle :
-
Écarts de prix entre échanges
-
Volumes anormaux sur paires peu liquides
-
Augmentation rapide des positions avant mise à jour d’oracle
-
Reconnaissance de motifs correspondant à des attaques connues
L’attaque d’octobre 2025 a probablement montré des signaux d’alerte. Vendre 60 millions de dollars de USDe à 5h43 du matin aurait dû déclencher une alarme. Si votre système de surveillance ne détecte pas cela, il est insuffisant.
Conclusion : un rappel de 19 milliards
La cascade de liquidations des 10 et 11 octobre 2025 n’a pas été causée par un effet de levier excessif ou une panique du marché, mais par un échec massif de conception d’oracle. Un mouvement de 60 millions de dollars a été amplifié en destruction de 19,3 milliards, car le système de données de prix ne pouvait pas distinguer manipulation et découverte réelle du prix.
Mais ce n’est pas un nouveau mode de défaillance. C’est la répétition constante du même scénario qui a détruit bZx en février 2020, Harvest en octobre 2020, Compound en novembre 2020, et Mango en octobre 2022.
Le secteur a reçu cinq fois cette leçon, à un coût croissant :
-
2020 : un protocole tire la leçon, applique une correction
-
2022 : les régulateurs tirent la leçon, entament des actions
-
2025 : tout le marché tire la leçon, paie 19,3 milliards de dollars
La seule question est : avons-nous enfin retenu la leçon ?
Chaque plateforme gérant des positions à effet de levier doit maintenant se demander :
-
Notre oracle est-il assez robuste contre les vecteurs d’attaque connus de 2020-2022 ?
-
Nos infrastructures peuvent-elles supporter les cascades que nous avons déjà observées ?
-
Avons-nous correctement équilibré sensibilité et stabilité ?
-
Reproduisons-nous les erreurs qui ont coûté des centaines de millions au secteur ?
L’histoire de cinq ans prouve que la manipulation d’oracle n’est ni un risque hypothétique ni un cas marginal — c’est une stratégie d’attaque documentée, reproductible et rentable, qui s’amplifie avec la taille du marché.
Octobre 2025 a montré ce qui arrive quand ces leçons ne sont pas assimilées à l’échelle institutionnelle. L’attaque n’était ni complexe ni nouvelle, juste le même scénario rejoué sur un système plus grand, exploitant une fenêtre de vulnérabilité connue.
L’oracle est la pierre angulaire du système. Quand elle fissure, toute la structure s’effondre.
Dans les marchés interconnectés modernes, la conception d’oracle ne concerne pas seulement la transmission des données, mais la stabilité du système.
Une erreur de conception, et 60 millions de dollars peuvent détruire 19,3 milliards.
Se tromper encore et encore, ce n’est pas apprendre, c’est répéter ses erreurs à coût croissant.
L’analyse repose sur des données publiques, des déclarations de plateformes et des études de cas de manipulation d’oracle sur cinq ans. Les opinions exprimées ici sont personnelles et n’engagent aucun organisme.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
