Comment une brève erreur de l’oracle Pragma a déclenché 3 millions de dollars de liquidations sur Vesu

Une erreur de prix de seulement deux minutes a suffi à déclencher environ 3 millions de dollars de liquidations anormales sur Vesu, un protocole de prêt de Starknet. Le 4 septembre 2026, entre 04 h 08 et 04 h 10 UTC, un flux de prix amont défaillant de Pragma a transmis des valeurs incorrectes. Quarante-sept positions d’emprunt, réparties sur plusieurs pools Vesu, ont alors semblé pouvoir être liquidées. 32

Le point essentiel est le suivant : Vesu présente l’événement comme une défaillance des données fournies par l’oracle, et non comme une vulnérabilité de ses contrats intelligents. Le moteur de liquidation a appliqué les règles prévues, mais à partir d’une hypothèse de prix erronée. 32

Ce qui s’est passé en deux minutes

Dans un protocole de prêt DeFi, la valeur du collatéral d’un emprunteur est comparée en continu à celle de sa dette. Si le ratio tombe sous un seuil défini, un liquidateur peut lancer la procédure prévue par le protocole et saisir une partie du collatéral.

Sur Vesu, les prix incorrects de Pragma ont fait paraître 47 positions insuffisamment garanties. Des liquidations automatisées ont ensuite retiré environ 3 millions de dollars de collatéral avant que le flux ne se corrige. 2032

Autrement dit, dire que les contrats « ont fonctionné comme prévu » ne signifie pas que le résultat économique était juste. Un contrat intelligent peut exécuter fidèlement les données qu’il reçoit ; il ne peut pas, à lui seul, déterminer si le prix communiqué par un oracle correspond réellement au marché.

Pourquoi une erreur d’oracle peut liquider des positions pourtant saines

La logique de liquidation doit être mécanique et rapide : si le collatéral perd réellement de la valeur, une réaction tardive peut exposer les prêteurs à des pertes. Mais cette automatisation traite aussi une baisse de prix erronée comme un mouvement de marché authentique, à moins que des garde-fous ne l’arrêtent.

La séquence est simple :

1. Un oracle publie un prix utilisé par le marché de prêt.
2. Le protocole recalcule la santé de la position avec ce prix.
3. La position semble passer sous son seuil minimal de collatéralisation.
4. Des liquidateurs exécutent la procédure de liquidation ordinaire.

Dans le cas de Vesu, c’est la première étape qui était erronée. La voie de liquidation n’a ni été contournée ni exploitée. Vesu a précisé qu’aucun correctif des contrats côté protocole n’était nécessaire. 32

Mesures prises par Vesu : pauses, récupération et consignes aux utilisateurs

Vesu a indiqué que Pragma, avec les parties concernées, avait déployé un correctif de la cause racine. Le flux de prix s’est autocorrigé dans la fenêtre de deux minutes, et Vesu prévoyait que les curateurs des pools lèvent les suspensions des pools concernés après la mitigation. 32

Le protocole a également déclaré travailler avec Pragma, StarkWare, la Starknet Foundation et les curateurs de pools afin de tenter de récupérer les fonds pour les utilisateurs affectés. Il s’agit d’un effort de récupération, pas de la confirmation que chaque utilisateur avait déjà été remboursé. 2432

Selon les consignes rapportées par Vesu, les utilisateurs concernés devaient :

• conserver leurs positions Earn ouvertes, un retrait pouvant affecter leur éligibilité à une éventuelle procédure de récupération ;
• ouvrir un ticket d’assistance sur le Discord de Vesu si leur position avait été liquidée durant l’incident. 2734

Le statut des pools pouvant évoluer selon les décisions de leurs curateurs, les utilisateurs doivent se référer aux communications officielles les plus récentes de Vesu plutôt que de supposer que tous les marchés ont été touchés ou qu’ils partagent le même statut.

Ce que l’on sait du correctif — et ce qui reste à établir

Les informations publiques confirment plusieurs éléments : la source du problème était un flux de prix Pragma en amont ; l’anomalie a duré environ deux minutes ; le flux s’est corrigé ; et un correctif de la cause racine a été déployé en collaboration avec les parties concernées. 2332

En revanche, elles ne détaillent pas encore le mécanisme technique précis ayant produit les mauvaises valeurs, ni un cadre final d’indemnisation. Vesu a annoncé qu’un rapport technique complet devait suivre. Jusqu’à sa publication, toute affirmation sur le défaut logiciel exact, sur l’attribution détaillée des responsabilités ou sur l’issue définitive de la récupération des fonds reste non confirmée. 27

Le précédent Aave et le cas Switchboard : le risque oracle dépasse Vesu

L’incident rappelle que, même lorsque le code onchain est déterministe et vérifiable, les protocoles financiers dépendent de données extérieures — au premier rang desquelles les prix des actifs.

Aave : 26,6 millions de dollars de liquidations après une erreur de valorisation

Le 10 mars 2026, un incident du CAPO, l’oracle de risque d’Aave, a réduit d’environ 2,85 % le taux de change effectif wstETH/stETH sur les marchés Ethereum Core et Prime. Cette valorisation incorrecte a déclenché environ 26,6 millions de dollars de volume de liquidations. Le rapport post-mortem d’Aave attribue l’événement à une incohérence entre un ratio instantané et son horodatage, non à un effondrement général du marché. 1011

Comme pour Vesu, les règles de liquidation n’ont pas cessé de fonctionner : elles ont été appliquées à une valorisation incorrecte.

Switchboard : une compromission seulement suspectée, mais plus grave par nature

Dans une autre catégorie de risque, Switchboard a suspendu par précaution ses opérations d’oracle sur Aptos, Sui, IOTA et Movement après des signalements d’une possible compromission touchant ses déploiements fondés sur Move. Cette suspension concernait les services d’oracle et n’a pas interrompu la production de blocs de ces réseaux. 34

Des informations ont lié cet épisode à des prix IOTA manipulés, à une émission anormale de VUSD et à des liquidations. Toutefois, il convient de parler d’une compromission présumée tant qu’une enquête définitive n’en aura pas établi la cause et l’ampleur. 25

Quels garde-fous peuvent limiter ce risque ?

Aucune mesure isolée ne garantit qu’un protocole de prêt rejettera toute donnée erronée. L’objectif est plutôt d’éviter qu’une anomalie de quelques minutes produise immédiatement des effets irréversibles. Les protections courantes comprennent :

• le recours à plusieurs sources de prix indépendantes plutôt qu’à un seul chemin de données ;
• des limites d’écart qui rejettent ou mettent en pause les variations inhabituelles ;
• des contrôles de fraîcheur afin que des données anciennes ne soient pas traitées comme actuelles ;
• des coupe-circuits et des mécanismes d’arrêt d’urgence au niveau des pools ;
• des délais ou un contrôle renforcé pour les changements de configuration d’oracle à fort impact ;
• des paramètres de collatéralisation prudents pour les actifs volatils ou complexes.

Le compromis est inévitable : des garde-fous plus stricts peuvent ralentir la réponse à un vrai mouvement de marché, tandis que des protections plus souples rendent les liquidations automatisées plus sensibles à des données incorrectes. L’épisode Vesu montre pourquoi cet arbitrage est au cœur de la gestion des risques en DeFi.

Pour les emprunteurs, la leçon pratique est claire : le risque de liquidation ne dépend pas seulement de la volatilité du marché ou d’un piratage de contrat intelligent. Il dépend aussi de l’intégrité, de la configuration et de la résilience opérationnelle des oracles qui déterminent la santé d’une position onchain.