Comment la conception d’un Price Feed a provoqué la transformation de 60 millions de dollars en une catastrophe de 19 milliards de dollars

Les 10 et 11 octobre 2025, une vente massive de 60 millions de dollars a anéanti 19,3 milliards de valeur. Pas en raison d’un effondrement général. Pas à cause d’appels de marge en cascade sur des positions réellement fragilisées. Mais suite à une défaillance d’oracle.

Ce n’est pas un phénomène nouveau. Ce schéma d’attaque est exploité avec succès depuis février 2020, coûtant à l’industrie plusieurs centaines de millions à travers des dizaines d’incidents. Octobre 2025 marque une amplification x160 du précédent record d’attaque sur oracle — non par sophistication technique, mais parce que l’écosystème a pris de l’ampleur tout en conservant ses faiblesses fondamentales.

Cinq années de leçons coûteuses, restées lettre morte. Cette analyse en explore les causes.

Le dilemme des oracles : sensibilité contre stabilité

Toute plateforme à effet de levier est confrontée à un défi essentiel : comment valoriser avec précision le collatéral tout en prévenant la manipulation ?

Trop sensible → vulnérabilité aux manipulations Trop stable → incapacité à détecter les dégradations réelles

En octobre 2025, la sensibilité a été privilégiée. L’oracle a suivi en temps réel les prix au comptant alors que 60 millions de dollars étaient injectés sur le marché, dépréciant instantanément le collatéral et entraînant une vague de liquidations. Le système a fonctionné comme prévu.

Mais sa conception était gravement défaillante.

Un schéma répété sur cinq ans

Avant d’analyser octobre 2025, rappelons-le : la situation s’est déjà produite.

Le schéma directeur (2020-2022)

Février 2020 : bZx (350 K USD + 630 K USD) Oracle à source unique. Manipulation par prêt éclair du prix WBTC sur Uniswap. 14,6 % de l’offre totale déplacée pour fausser le flux utilisé par bZx.

Octobre 2020 : Harvest Finance (24 M USD volés, retrait massif de 570 M USD) Sept minutes. Prêt éclair de 50 M USD. Manipulation des prix stables sur Curve. Effondrement infrastructurel et retrait massif de liquidité, dépassant largement le montant du vol.

Novembre 2020 : Compound (89 M USD liquidés) DAI à 1,30 USD sur Coinbase Pro — nulle part ailleurs. L’oracle de Compound utilisait Coinbase comme référence. Liquidations sur des prix observés sur une seule plateforme pendant une heure. 100 K USD suffisaient pour manipuler un carnet de 300 K USD de profondeur.

Octobre 2022 : Mango Markets (117 M USD) 5 M USD de capital initial. Pump de MNGO de 2 394 % sur plusieurs plateformes. Emprunt de 117 M USD sur collatéral gonflé. Utilisation de tokens de gouvernance volés pour s’attribuer une “prime de bug” de 47 M USD. Première action de la CFTC contre la manipulation d’oracle.

Le fil conducteur

Toutes les attaques ont suivi la même logique :

1. Identifier une dépendance d’oracle à une source manipulable
2. Calculer : coût de la manipulation < valeur extractible
3. Exécuter
4. Encaisser

De 2020 à 2022 : 403,2 millions USD dérobés sur 41 attaques de manipulation d’oracle.

Réaction du secteur : Fragmentée. Lente. Incomplète. La plupart des plateformes ont maintenu des oracles axés sur le prix au comptant, sans redondance suffisante.

Puis vint octobre 2025.

L’anatomie de la défaillance oracle : édition 2025

10 octobre 2025, 05h43 : vente massive de 60 M USD USDe sur les marchés au comptant.

Avec un oracle bien conçu : impact minime, absorbé par plusieurs sources indépendantes.

Ici : catastrophe.

Vente au comptant de 60 M USD → L’oracle dévalue le collatéral (wBETH, BNSOL, USDe) →

Liquidations massives → Surcharge de l’infrastructure → Vide de liquidité → 19,3 Mds USD détruits

Le facteur d’amplification

• Mango Markets (2022) : manipulation de 5 M USD → 117 M USD extraits (x23)
• Octobre 2025 : manipulation de 60 M USD → 19,3 Mds USD détruits (x322)

Non par sophistication. Mais parce que la même faille existait à grande échelle.

Le problème de la pondération

L’oracle dépendait essentiellement des prix au comptant sur la place principale. Quand un marché domine le volume :

• Un volume élevé suggère une découverte de prix (logique a priori)
• Mais la concentration rend la manipulation possible (et fatale)
• L’usage exclusif de prix internes crée une boucle autoréférentielle (aggravant le risque)

Un analyste l’a résumé : “puisque [l’exchange] a le plus gros volume usde/bnsol/wbeth, même avec les pondérations oracle, il faut se référer au prix au comptant.”

Cette intuition — faire confiance au plus gros marché — a coûté des milliards lors des attaques d’oracle depuis cinq ans. La concentration du volume ne garantit pas l’exactitude des prix, mais favorise la manipulation.

La fenêtre programmée de vulnérabilité

Les mises à jour oracle ont été annoncées huit jours avant leur déploiement. L’attaquant disposait de :

• Dépendances connues sur l’oracle
• Calendrier de transition prévisible
• Huit jours pour s’organiser

Les attaques précédentes exploitaient des failles existantes. Octobre 2025 visait la transition — une vulnérabilité créée par l’annonce préalable des améliorations.

Le test d’isolement des plateformes

La preuve la plus nette d’une défaillance oracle, non d’une dépréciation d’actif :

Plateforme principale : USDe à 0,6567 USD, wBETH à 430 USD Autres plateformes : écart < 30 points de base

Pools on-chain : Impact quasi nul

Comme l’a souligné Guy d’Ethena : “plus de 9 milliards USD de collatéraux stables étaient disponibles à la demande pour rachat immédiat” durant l’événement.

Les prix ont bougé brutalement sur l’exchange source de l’oracle, mais sont restés stables ailleurs. L’oracle a transmis le prix manipulé. Le système a liquidé sur des prix inexistants sur le marché.

C’est le schéma Compound 2020 : manipulation sur une plateforme isolée, fidèlement rapportée, destructrice à grande échelle.

La cascade infrastructurelle

L’analyste agintender a pointé le mécanisme d’amplification :

“La liquidation en cascade a saturé les serveurs par des millions de requêtes. Les market makers n’ont pas pu placer leurs ordres à temps, générant un vide de liquidité.”

C’est le scénario Harvest Finance à grande échelle. L’attaque déclenche les liquidations plus vite que l’infrastructure ne peut les traiter. Les intervenants du marché sont dépassés. La liquidité disparaît. La cascade s’auto-renforce.

Après l’effondrement d’Harvest en octobre 2020 (TVL passant de 1 Md USD à 599 M USD), la leçon était claire : les oracles doivent intégrer la capacité d’infrastructure en période de stress.

Octobre 2025 a démontré notre incapacité à retenir la leçon.

Sensibilité : deux approches, un désastre

Guy d’Ethena a résumé le défi central : Les oracles doivent distinguer entre dislocations temporaires (bruit de marché) et pertes définitives (dépréciation réelle).

En octobre 2025, deux réponses :

Approche haute sensibilité (l’exchange défaillant)

• Prix au comptant en temps réel
• Réactivité immédiate
• Résultat : 19 Mds USD de pertes en cascade

C’est l’approche bZx/Harvest : confiance dans le prix au comptant, ruinée par la manipulation.

Approche haute stabilité (DeFi résiliente)

• USDe = USDT fixé
• Ignorer les dislocations temporaires
• Résultat : aucune liquidation

C’est une surcorrection. Mieux que l’échec, mais pas optimal.

L’industrie disposait de cinq ans pour créer des solutions nuancées. Nous avons récolté deux extrêmes, le catastrophique ayant été privilégié à grande échelle.

Le théorème de l’attaque oracle : validation empirique

Théorème : Tout système à effet de levier où :

1. Les prix d’oracle reposent principalement sur des marchés au comptant manipulables
2. Les déclencheurs de liquidation sont déterministes
3. L’infrastructure a une capacité limitée

Alors : coût de manipulation < valeur extractible via les cascades

Preuve par répétition :

• bZx (févr. 2020) : manipulation Uniswap → 350 K USD + 630 K USD extraits
• Harvest (oct. 2020) : manipulation Curve → 24 M USD volés + retrait massif de 570 M USD
• Compound (nov. 2020) : manipulation Coinbase → 89 M USD liquidés
• Mango (oct. 2022) : manipulation multi-plateformes → 117 M USD extraits
• Octobre 2025 : manipulation plateforme principale → 19,3 Mds USD détruits

À mesure que la taille du système augmente linéairement, les dégâts s’amplifient exponentiellement. Le coût de la manipulation reste stable (fonction de la liquidité), la valeur extractible croît avec l’effet de levier total.

Octobre 2025 valide ce théorème à une échelle inédite.

Principes de conception d’oracle : les leçons à retenir

1. Validation multi-sources

Ne jamais se fier à des prix issus d’une seule plateforme, surtout de ses propres carnets d’ordres. C’était la leçon de bZx en février 2020. Un oracle robuste doit :

Prix oracle = Moyenne pondérée de :

• Prix multi-plateformes (40 %)

• Pools de liquidité on-chain (30 %)

• Ratios de conversion pour tokens encapsulés (20 %)

• Prix historiques pondérés dans le temps (10 %)

L’indépendance des sources prime sur leur pondération. Si toutes peuvent être manipulées simultanément avec un capital raisonnable, il n’y a qu’une source.

1. Sensibilité adaptative

L’oracle doit ajuster sa sensibilité selon le marché :

• Marchés normaux : sensibilité accrue aux variations
• Marchés volatils : stabilité renforcée par pondération temporelle
• Mouvements extrêmes : coupe-circuits et contrôles de cohérence

Les oracles de prix moyen pondéré dans le temps ont été adoptés après les attaques par prêt éclair de 2020 pour éviter la manipulation sur une transaction. Pourtant, en octobre 2025, les oracles réagissaient au prix au comptant en temps réel, comme si cinq ans d’histoire n’avaient jamais existé.

1. Résilience infrastructurelle

L’oracle doit rester opérationnel pendant une cascade :

• Infrastructure dédiée pour les flux de prix
• Capacité pour des millions de requêtes simultanées
• Dégradation contrôlée sous charge

Après la chute d’Harvest Finance en octobre 2020, l’importance de la capacité en situation de crise était manifeste. Les cascades de liquidation génèrent une charge exponentielle. L’infrastructure doit supporter non seulement la première liquidation, mais aussi la millième quand les market makers sont dépassés et les utilisateurs paniquent.

1. Transparence sans vulnérabilité

La fenêtre de huit jours entre annonce et mise en œuvre a créé un vecteur d’attaque. Meilleures pratiques :

• Appliquer les changements dès l’annonce
• Procéder par mises à jour progressives sans date fixe
• Tenir des journaux d’audit sans période de prévisualisation

Nouvelle leçon logique : ne jamais annoncer à l’avance un changement exploitable. L’attaquant d’octobre 2025 avait huit jours pour tout préparer. Il connaissait le moment précis où la faille serait exploitable.

Perspective académique : le théorème de l’attaque oracle

Cinq ans de preuves empiriques démontrent :

Théorème : Tout système à effet de levier où :

1. Les prix d’oracle dépendent principalement de marchés au comptant manipulables
2. Les déclencheurs de liquidation sont déterministes
3. L’infrastructure a une capacité limitée

Alors : coût de manipulation < valeur extractible via les cascades

Validation empirique répétée :

• bZx (févr. 2020) : 10 M USD empruntés, 350 K USD extraits. Manipulation via Uniswap.
• Harvest (oct. 2020) : prêt éclair de 50 M USD, 24 M USD volés, retrait massif de 570 M USD.
• Compound (nov. 2020) : manipulation carnet d’ordres à 100 K USD, 89 M USD liquidés.
• Mango (oct. 2022) : 5 M USD de capital initial, 117 M USD extraits.
• Octobre 2025 : vente massive au comptant de 60 M USD, 19,3 Mds USD détruits.

La progression est évidente : la taille du système augmente linéairement, les dégâts exponentiellement. Le coût de la manipulation reste stable (fonction de la liquidité du marché ciblé), la valeur extractible croît avec l’effet de levier global.

Octobre 2025 apporte la validation empirique à une échelle inédite. Le théorème est confirmé.

Implications systémiques : les leçons toujours ignorées

Ce n’est pas l’échec d’une seule plateforme, mais la révélation de failles sectorielles persistantes malgré cinq ans d’apprentissage coûteux :

1. Surdépendance aux prix au comptant

La majorité des plateformes utilisent encore des oracles axés sur le prix au comptant alors que toutes les grandes attaques depuis 2020 exploitent précisément cette faille. L’industrie sait que les prix au comptant sont manipulables. Elle sait que le prix moyen pondéré dans le temps et les oracles multi-sources protègent mieux. Mais la mise en œuvre reste partielle.

Pourquoi ? Vitesse et sensibilité sont des atouts — jusqu’à ce qu’ils deviennent des failles. Les mises à jour temps réel semblent plus justes — jusqu’à la manipulation.

2. Risque de concentration

Les plateformes dominantes créent des points de défaillance uniques. Ce fut le cas pour bZx avec Uniswap, Compound avec Coinbase, puis la plateforme d’octobre 2025 avec son propre carnet d’ordres. La plateforme change, la faille demeure.

Quand une place concentre la majorité du volume, l’utiliser comme source principale d’oracle paraît logique. Mais le risque de concentration sur les flux de prix est comme dans tout système : acceptable… jusqu’à l’exploitation.

3. Hypothèses infrastructurelles

Les systèmes conçus pour les marchés normaux échouent en période de stress. Harvest Finance l’a démontré en 2020. Octobre 2025 montre que nous continuons de concevoir pour des conditions standards, en espérant éviter la crise.

L’espoir n’est pas une stratégie.

4. Le paradoxe de la transparence

Les annonces d’amélioration créent des fenêtres d’attaque. Le délai de huit jours entre l’annonce et la mise en œuvre des changements oracle a offert aux acteurs sophistiqués un plan et un calendrier. Ils savaient quand frapper et quoi exploiter.

Nouvelle forme d’échec pour un vieux problème. Les attaques précédentes ciblaient des failles existantes. Octobre 2025 a exploité la transition oracle — une vulnérabilité créée par l’annonce préalable.

La voie à suivre : apprendre réellement cette fois

Améliorations immédiates

1. Oracle mixteCombiner plusieurs sources de prix avec des contrôles de cohérence réels :

• Prix CEX (pondérés par volume entre plateformes)
• Prix DEX (uniquement sur pools très liquides)
• Preuve de réserves on-chain
• Limites de déviation inter-plateformes

Chaque source doit être indépendante. Si la manipulation d’une source affecte une autre, la redondance est absente.

2. Pondération dynamiqueAjuster la sensibilité de l’oracle selon le contexte :

• Volatilité normale : pondérations standards
• Forte volatilité : prix moyen pondéré dans le temps élargi, prix au comptant pondéré à la baisse
• Mouvements extrêmes : suspension des liquidations, enquête avant reprise

L’attaque Compound a montré que parfois le “bon” prix sur une plateforme est erroné pour le marché global. L’oracle doit être capable de le détecter.

3. Coupe-circuitsSuspendre les liquidations lors de variations extrêmes — non pour empêcher un désendettement légitime, mais pour distinguer manipulation et réalité :

• Convergence rapide des prix sur toutes plateformes : mouvement réel
• Prix isolés sur une plateforme : manipulation probable
• Infrastructure saturée : pause jusqu’à rétablissement

Objectif : empêcher les liquidations en cascade sur prix manipulés, non stopper tout désendettement.

4. Mise à l’échelle infrastructurelleConcevoir pour une capacité 100 fois supérieure à la normale, car c’est ce que génèrent les cascades :

• Infrastructure dédiée pour les flux de prix
• Moteurs de liquidation indépendants
• Limitation du débit par adresse
• Protocoles de dégradation contrôlée

Un système incapable de supporter la charge amplifie la cascade. Ce n’est pas un bonus, c’est une exigence de base.

Solutions de fond

1.Réseaux d’oracles décentralisésAdopter des solutions comme Chainlink, Pyth ou UMA, qui agrègent les sources et résistent à la manipulation. Ce n’est pas parfait, mais nettement supérieur aux oracles dépendants du prix au comptant, vulnérables tous les 18 mois. bZx a intégré Chainlink après 2020. Les attaques d’oracle ont cessé. Ce n’est pas un hasard.

2.Intégration de preuve de réservesPour les tokens encapsulés et les stablecoins, garantir la valeur du collatéral on-chain. USDe doit être valorisé sur la base de réserves vérifiables, non sur la dynamique du carnet d’ordres. La technologie existe ; l’implémentation traîne.

3.Liquidations progressivesLimiter la propagation en cascade par des liquidations étagées :

• Premier seuil : Avertissement et délai d’ajout de collatéral
• Deuxième seuil : liquidation partielle (25 %)
• Troisième seuil : liquidation accrue (50 %)
• Dernier seuil : liquidation totale
  L’utilisateur dispose de temps pour réagir, réduisant le choc systémique des liquidations simultanées.

4.Audit en temps réelSurveiller les tentatives de manipulation d’oracle :

• Écarts de prix entre plateformes
• Volumes inhabituels sur paires peu liquides
• Augmentation rapide des positions avant mise à jour oracle
• Détection de schémas d’attaque connus

L’attaque d’octobre 2025 a forcément laissé des signaux d’alerte. Une vente massive de 60 M USD USDe à 05h43 doit déclencher des alertes. Si la surveillance ne l’a pas détectée, elle est insuffisante.

Conclusion : le rappel des 19 milliards

La cascade de liquidation des 10 et 11 octobre n’est pas due à un surendettement ou à la panique, mais à une faille de conception oracle à grande échelle. Une opération de 60 millions de dollars s’est transformée en 19 milliards de pertes car le système n’a pas su distinguer manipulation et découverte réelle des prix.

Ce mode d’échec n’est pas nouveau. Il a déjà détruit bZx en février 2020, Harvest en octobre 2020, Compound en novembre 2020 et Mango en octobre 2022.

L’industrie a subi cette leçon cinq fois, à coût croissant :

• 2020 : Les protocoles individuels ont corrigé
• 2022 : Les régulateurs ont agi
• 2025 : L’ensemble du marché a payé 19,3 Mds USD d’apprentissage

La question : retiendra-t-on enfin la leçon ?

Toute plateforme gérant des positions à effet de levier doit se demander :

• Notre oracle résiste-t-il aux attaques connues de 2020-2022 ?
• Notre infrastructure peut-elle gérer une cascade déjà vécue ?
• Avons-nous trouvé le bon équilibre sensibilité/stabilité ?
• Répétons-nous les erreurs qui ont coûté des centaines de millions à l’industrie ?

Comme l’histoire le montre, la manipulation d’oracle n’est ni un risque théorique ni marginal, mais une stratégie documentée, rentable et scalable.

Octobre 2025 a révélé ce qui arrive quand ces leçons ne sont pas appliquées à grande échelle. L’attaque n’était ni sophistiquée ni nouvelle. C’était le même scénario, adapté à un système plus vaste, lors d’une fenêtre de vulnérabilité connue.

L’oracle est la base. S’il se fissure, tout s’effondre. Nous le savons depuis février 2020. Nous avons dépensé des milliards pour l’apprendre. La question est de savoir si octobre 2025 aura coûté assez cher pour que nous agissions enfin en conséquence.

Dans les marchés interconnectés contemporains, la conception oracle ne concerne pas seulement les flux de données — c’est une question de stabilité systémique. Se tromper, et 60 millions détruisent 19 milliards.

Persister dans l’erreur, c’est ne pas apprendre de l’histoire, mais rendre chaque récidive plus coûteuse.

Analyse basée sur des données publiques, des déclarations de plateformes et cinq ans d’études de cas sur la manipulation d’oracle. Les vues exprimées sont strictement personnelles, informées mais n’engagent aucune entité.

Avertissement :

1. Ce contenu est une republication de [yq_acc]. Tous droits réservés à l’auteur original [yq_acc]. Pour toute objection à cette republication, veuillez contacter l’équipe Gate Learn pour intervention rapide.
2. Avertissement : Les analyses et opinions de cet article n’engagent que l’auteur et ne constituent en aucun cas un conseil en investissement.
3. La traduction de cet article dans d’autres langues est assurée par Gate Learn. Sauf mention contraire, la copie, distribution ou le plagiat du contenu traduit est interdit.