Le cygne noir se répète : le cycle de cinq ans des failles des oracles

Une vente massive de 60 millions de dollars a entraîné l'évaporation de 19.3 milliards de dollars de capitalisation boursière.

Auteur : YQ

Traduction et compilation : Saoirse, Foresight News

(Le contenu original a été ajusté et abrégé)

Du 10 au 11 octobre 2025, une vente massive de 60 millions de dollars a entraîné l'évaporation de 19.3 milliards de dollars de capitalisation boursière. Cela ne provenait pas d'un krach du marché, ni d'une cascade d'appels de marge déclenchée par des positions légitimes en difficulté, mais d'une défaillance d'oracle.

Ce n'est pas une nouveauté. Depuis février 2020, le même mode d'attaque a été exploité avec succès, causant des centaines de millions de dollars de pertes à l'industrie lors de dizaines d'incidents. L'attaque d'octobre 2025 était 160 fois plus importante que la plus grande attaque d'oracle précédente — non pas parce que la technologie était plus complexe, mais parce que le système sous-jacent a conservé les mêmes vulnérabilités fondamentales tout en augmentant d'échelle.

Cinq années de leçons douloureuses ont été ignorées. Cette analyse explore les raisons de cette situation.

2020-2022 : Le « script fixe » des attaques d'oracle

Avant d'analyser l'incident d'octobre 2025, il est important de noter que des situations similaires se sont déjà produites.

Février 2020 : Incident bZx (perte de 350 000 $ + 630 000 $)

En utilisant un oracle à source unique, l'attaquant a manipulé le prix du WBTC sur Uniswap via un flash loan, déplaçant 14,6 % de l'offre totale de ce token pour manipuler les données de prix sur lesquelles bZx reposait entièrement.

Octobre 2020 : Incident Harvest Finance (24 millions de dollars volés, panique de 570 millions de dollars)

En seulement 7 minutes, l'attaquant a manipulé le prix des stablecoins sur Curve avec un flash loan de 50 millions de dollars, provoquant non seulement un vol de fonds, mais aussi l'effondrement de l'infrastructure et un retrait massif de liquidités, avec un impact bien supérieur au montant initial volé.

Novembre 2020 : Incident Compound (89 millions de dollars d'actifs liquidés)

Le stablecoin DAI a grimpé à 1,30 $ sur Coinbase Pro, alors qu'aucune autre plateforme n'a connu ce phénomène. Comme l'oracle de Compound utilisait Coinbase comme référence de prix, les utilisateurs ont été liquidés de force en raison de ce prix anormal pendant seulement une heure. À l'époque, il suffisait de 100 000 $ pour manipuler un carnet d'ordres de 300 000 $ de profondeur.

Octobre 2022 : Incident Mango Markets (perte de 117 millions de dollars)

L'attaquant, avec un capital initial de 5 millions de dollars, a fait grimper le prix du token MNGO de 2394 % sur plusieurs plateformes, puis a emprunté 117 millions de dollars en utilisant des garanties surévaluées, et a utilisé les tokens de gouvernance volés pour voter en sa faveur, s'octroyant une « prime de bug » de 47 millions de dollars. C'était la première fois que la CFTC américaine prenait des mesures d'application contre la manipulation d'oracle.

Toutes ces attaques suivent le même processus :

1. Identifier la dépendance de l'oracle à une « source de données manipulable » ;
2. Calculer la rentabilité : coût de manipulation < valeur extractible ;
3. Exécuter la manipulation ;
4. Encaisser les profits et sortir.

Entre 2020 et 2022, 41 attaques de manipulation d'oracle ont entraîné le vol de 403,2 millions de dollars. La réponse de l'industrie a été dispersée, lente et incomplète — la plupart des plateformes utilisent encore des oracles principalement basés sur les prix spot, avec une redondance insuffisante.

Ensuite, la catastrophe d'octobre 2025 est survenue.

Analyse de la faille « 10.11 »

Le 10 octobre 2025 à 5h43 du matin, une vente concentrée de 60 millions de dollars en USDe a déclenché une réaction en chaîne fatale :

Vente spot de 60 millions de dollars → l'oracle abaisse la valorisation des collatéraux (wBETH, BNSOL, USDe) → liquidations massives → surcharge de l'infrastructure → vide de liquidité → 19.3 milliards de dollars de capitalisation boursière évaporés

Ce n'est pas l'échec d'une seule plateforme, mais la révélation d'une vulnérabilité persistante dans toute l'industrie — même après cinq ans de pertes importantes, ces failles n'ont toujours pas été corrigées :

1. Dépendance excessive aux prix spot

Bien que chaque attaque majeure depuis 2020 ait exploité la « manipulabilité des prix spot », la plupart des plateformes utilisent encore des oracles principalement basés sur les prix spot. L'industrie sait que les prix spot sont sujets à la manipulation, et que le « prix moyen pondéré dans le temps (TWAP) » et les « oracles multi-sources » offrent une meilleure protection, mais ces solutions n'ont jamais été pleinement mises en œuvre.

La racine du problème : « rapidité et sensibilité » sont considérées comme des avantages, jusqu'à ce qu'elles deviennent des failles. Les mises à jour de prix en temps réel semblent plus précises — jusqu'à ce que quelqu'un les manipule.

2. Risque de centralisation

Les plateformes de trading dominantes créent un « point de défaillance unique » : bZx dépendait d'Uniswap, Compound de Coinbase, les plateformes de janvier et octobre 2025 de leur propre carnet d'ordres — c'est toujours le même problème, même si la plateforme change, la faille demeure.

Lorsqu'un exchange domine le volume des transactions, l'utiliser comme principale source de données pour l'oracle semble raisonnable. Mais le risque de centralisation dans le flux de prix est identique à tout risque de centralisation : tout semble normal jusqu'à ce que ce soit exploité.

3. Biais dans les hypothèses d'infrastructure

Les systèmes conçus pour des « marchés normaux » échouent de façon catastrophique sous pression. Harvest Finance l'a démontré en 2020, mais l'incident d'octobre 2025 montre que l'industrie continue de « concevoir pour la normalité et d'espérer que les événements extrêmes n'arrivent jamais ».

Mais « espérer » n'est pas une stratégie.

4. Le paradoxe de la transparence

Publier des plans d'amélioration technique crée en réalité une fenêtre d'attaque. Le délai de « 8 jours entre l'annonce et la mise en œuvre » d'une mise à jour d'oracle donne aux attaquants professionnels une feuille de route claire — ils savent exactement quand attaquer et quelle faille exploiter.

C'est un « nouveau mode d'échec pour un vieux problème » : auparavant, les attaques exploitaient des failles existantes, mais en octobre 2025, l'attaque a exploité la « période de transition lors du changement d'algorithme d'oracle » — cette faille n'existait que parce que le plan d'amélioration a été annoncé à l'avance.

Sortir de l'impasse

Mesures d'amélioration immédiates

1. Conception d'oracles hybrides

Intégrer plusieurs sources de prix et ajouter des vérifications de cohérence efficaces :

• Prix des exchanges centralisés (CEX) (pondération par volume inter-plateformes, 40 %) ;
• Prix des exchanges décentralisés (DEX) (seulement les pools à forte liquidité, 30 %) ;
• Preuve de réserve on-chain (20 %) ;
• Taux de conversion des actifs encapsulés (10 %).

L'essentiel est « l'indépendance des sources de données » : si toutes les sources peuvent être manipulées à coût raisonnable, alors « multi-sources » revient à « source unique ».

2. Ajustement dynamique des pondérations

Ajuster la sensibilité de l'oracle selon les conditions du marché :

• Période de volatilité normale : utiliser les pondérations standards ;
• Période de forte volatilité : allonger la fenêtre de calcul du TWAP, réduire l'influence du prix spot ;
• Période de volatilité extrême : activer le mécanisme de coupe-circuit et la vérification de cohérence.

L'incident Compound de 2020 a prouvé : parfois, le « bon prix » sur un exchange est le mauvais prix pour le marché entier. L'oracle doit être capable de détecter ce type d'écart.

3. Mécanisme de coupe-circuit

Suspension des liquidations lors de fluctuations extrêmes — le but n'est pas d'empêcher le « deleveraging légitime », mais de distinguer « manipulation » et « réalité du marché » :

• Si les prix convergent sur plusieurs plateformes en quelques minutes : il s'agit probablement d'une vraie fluctuation de marché ;
• Si l'anomalie n'apparaît que sur une seule plateforme : il s'agit probablement d'une manipulation ;
• Si l'infrastructure est surchargée : suspendre les liquidations jusqu'à rétablissement de la capacité.

L'objectif n'est pas de « bannir toutes les liquidations », mais d'« éviter les liquidations en chaîne causées par la manipulation des prix ».

4. Extension de l'infrastructure

Concevoir le système pour une « capacité 100 fois supérieure à la normale » — car les réactions en chaîne créent une charge exponentielle :

• Construire une infrastructure indépendante pour le flux de prix ;
• Déployer un moteur de liquidation indépendant ;
• Limiter le taux de requêtes par adresse ;
• Établir un protocole de « dégradation progressive » (prioriser les fonctions essentielles en cas de surcharge).

Si le système ne peut pas supporter la charge d'une réaction en chaîne, il aggrave la catastrophe. C'est une nécessité de conception, pas une option d'optimisation.

Solutions à long terme

1. Réseau d'oracles décentralisé

Adopter des solutions d'oracle matures (telles que Chainlink, Pyth, UMA), qui agrègent les données de multiples sources pour une résistance intégrée à la manipulation. Elles ne sont pas parfaites, mais bien meilleures que les oracles dépendant du spot qui se font attaquer tous les 18 mois.

bZx, après l'attaque de 2020, a intégré Chainlink et n'a plus subi d'attaque de manipulation d'oracle — ce n'est pas un hasard.

2. Intégration de la preuve de réserve

Pour les actifs encapsulés et les stablecoins, il faut vérifier la valeur des collatéraux on-chain. Par exemple, le prix de USDe devrait être basé sur des « réserves vérifiables », et non sur la « dynamique du carnet d'ordres ». La technologie existe déjà, seul le déploiement accuse du retard.

3. Liquidation progressive

Éviter l'amplification des réactions en chaîne par des liquidations par étapes :

• Premier seuil : alerte, temps donné à l'utilisateur pour ajouter du collatéral ;
• Deuxième seuil : liquidation partielle (25 %) ;
• Troisième seuil : liquidation plus importante (50 %) ;
• Seuil final : liquidation totale.

Cela donne du temps aux utilisateurs pour réagir et réduit l'impact des « liquidations massives synchronisées » sur le système.

4. Audit et surveillance en temps réel

Surveiller en temps réel les manipulations d'oracle :

• Écarts de prix inter-plateformes ;
• Volumes anormaux sur des paires à faible liquidité ;
• Croissance rapide de la taille des positions avant la mise à jour de l'oracle ;
• Correspondance avec des schémas d'attaque connus.

L'attaque d'octobre 2025 aurait dû déclencher des alertes : une vente de 60 millions de dollars en USDe à 5h43 du matin est une transaction anormale qui doit déclencher une alerte. Si le système de surveillance ne l'a pas détectée, c'est qu'il est gravement défaillant.

Conclusion : l'avertissement des 19 milliards de dollars

Les liquidations en chaîne des 10-11 octobre 2025 n'ont pas été causées par un « excès de levier » ou une « panique du marché », mais par un « échec à grande échelle de la conception des oracles ». Si une opération de marché de 60 millions de dollars a pu causer 19.3 milliards de dollars de pertes, c'est parce que le système de flux de prix ne pouvait pas distinguer « manipulation » et « découverte légitime des prix ».

Mais ce n'est pas un problème nouveau — ce qui a détruit bZx en février 2020, Harvest en octobre 2020, Compound en novembre 2020, Mango Markets en octobre 2022, ce sont toujours les mêmes types de défaillances.

En cinq ans, l'industrie a tiré la même leçon cinq fois, à un coût de plus en plus élevé :

• 2020 : quelques protocoles apprennent et corrigent ;
• 2022 : les régulateurs interviennent et commencent à appliquer la loi ;
• 2025 : le marché entier paie 19.3 milliards de dollars de « frais de scolarité ».

La seule question qui reste : retiendrons-nous enfin cette leçon ?

Toutes les plateformes gérant des positions à effet de levier doivent affronter les questions suivantes :

• Nos oracles peuvent-ils résister aux vecteurs d'attaque identifiés entre 2020 et 2022 ?
• Notre infrastructure peut-elle faire face à des scénarios de liquidations en chaîne déjà survenus ?
• Avons-nous trouvé un équilibre raisonnable entre « sensibilité » et « stabilité » ?
• Sommes-nous en train de répéter les erreurs qui ont coûté des centaines de millions à l'industrie ?

Cinq ans d'histoire l'ont prouvé : la manipulation d'oracle n'est pas un « risque hypothétique » ou un « cas marginal », mais une stratégie d'attaque « documentée, reproductible et très lucrative », dont l'ampleur croît avec le marché.

L'incident d'octobre 2025 montre que lorsque ces leçons sont ignorées à l'échelle institutionnelle, la catastrophe est inévitable. Cette attaque n'était ni complexe, ni nouvelle — c'était simplement la même méthode, exploitant une « fenêtre de vulnérabilité connue », appliquée à un système de plus grande taille.

L'oracle est la pierre angulaire de tout le système. Si la pierre angulaire se fissure, tout s'effondre. Depuis février 2020, nous le savons, et nous avons

dépensé des milliards de dollars pour le vérifier à maintes reprises. La seule question qui reste est de savoir si l'événement coûteux d'octobre 2025 suffira à transformer enfin les leçons connues en actions concrètes.

Dans un marché aujourd'hui hautement interconnecté, la conception d'un oracle n'est pas « juste un flux de données » — c'est la stabilité de tout le système qui est en jeu. Une seule erreur de conception, et 60 millions de dollars peuvent détruire 19 milliards de dollars de valeur.

Si nous continuons à répéter les mêmes erreurs, ce n'est pas que nous n'apprenons pas de l'histoire, c'est juste que le prix de l'erreur ne fait qu'augmenter.

Cette analyse est basée sur des données de marché publiques, des déclarations de plateformes et des études de cas de manipulation d'oracle sur cinq ans.