Oracle à trade unique YieldBlox Stellar

Le 4 février 2026, le pool de prêt géré par DAO de YieldBlox — construit avec Blend sur la blockchain Stellar — a perdu environ 10,2 millions de dollars via une manipulation d'oracle à trade unique classique. L'attaquant a placé une seule offre de vente pour USTRY à 501 USDC par USTRY durant une fenêtre de 15 minutes pendant laquelle aucun autre trading USTRY n'avait eu lieu, définissant le prix de l'oracle Reflector pour toute la fenêtre. 7,2 millions de dollars ont ensuite été gelés par les validateurs Tier-1 Stellar.

Ce qui s'est passé

Le pool de prêt YieldBlox acceptait USTRY (un jeton de rendement des bons du Trésor américain) comme collatéral, avec des prix fournis par l'oracle Reflector — l'infrastructure native d'oracle de Stellar. La tarification Reflector pour la paire USTRY/USDC était basée sur les trades on-chain dans des fenêtres temporelles glissantes.

La combinaison fatale :

1. USTRY/USDC avait une liquidité extrêmement faible sur Stellar — le marché ne voyait que des trades sporadiques.
2. Aucun trade n'a eu lieu dans les 15 minutes précédant l'attaque — signifiant que le prochain trade définirait le prix rapporté de l'oracle pour toute la fenêtre.
3. La logique de dérivation de prix de Reflector ne nécessitait pas de volume minimum ou de trades multiples pour valider le prix d'une fenêtre ; un seul trade suffisait.

L'attaque :

1. L'attaquant a placé une offre de vente pour USTRY tarifée à 501 USDC par USTRY — largement au-dessus du vrai prix de marché (USTRY se négocie près du rendement Treasury sous-jacent, typiquement près de 1 $ par jeton).
2. Quelqu'un (l'attaquant lui-même, ou quelqu'un répondant au quote visible) a exécuté même un petit trade au prix offert — établissant le prix pour la fenêtre de l'oracle Reflector.
3. Avec l'oracle rapportant maintenant USTRY à 501 USDC par jeton, l'attaquant a déposé un petit montant d'USTRY comme collatéral et emprunté tout le disponible depuis le pool YieldBlox contre la valorisation gonflée.
4. Est parti sans rembourser, laissant YieldBlox avec de l'USTRY à valeur gonflée sans valeur comme seul backing pour les prêts volés.

Extraction totale : environ 10,2 millions de dollars en USDC, XLM et autres actifs du pool.

Conséquences

• Les validateurs Tier-1 Stellar ont gelé environ 7,2 millions de dollars des actifs volés dans les wallets de l'attaquant — utilisant la capacité de gel de compte de Stellar que le petit ensemble coordonné de validateurs du réseau peut exercer.
• YieldBlox a mis en pause le pool affecté et offert à l'attaquant une prime de 10 % avec deadline de 72 heures. L'attaquant n'a pas répondu.
• Le protocole a coordonné avec la Stellar Development Foundation sur la réponse de gel par validateur.
• Les ~7,2 M$ gelés ont fourni une base pour un remboursement partiel des utilisateurs ; les ~3 M$ restants n'ont pas été récupérés.

Pourquoi c'est important

YieldBlox est l'un des cas les plus nets pour comment l'agrégation d'oracles doit exiger des garanties de volume minimum et de nombre de sources pour tout actif utilisé comme collatéral. L'attaque n'a nécessité qu'un petit montant de capital d'attaquant pour construire la manipulation — le coût était la différence entre le quote gonflé et le règlement éventuel, que l'attaquant pouvait souvent capturer lui-même.

Les patterns défensifs qui auraient empêché la perte de YieldBlox :

1. Seuils minimums de liquidité avant qu'un actif soit accepté comme collatéral — les marchés avec un trading trop mince ne se qualifient pas.
2. Exigences de volume par fenêtre d'oracle — un seul trade à n'importe quel prix ne devrait pas être suffisant pour définir le prix canonique.
3. Agrégation multi-source — même si l'oracle primaire du protocole de prêt est local, une vérification de cohérence contre un feed externe (par ex. Chainlink pour la même paire sur une autre chaîne) attrape la manipulation évidente.
4. Disjoncteurs — pause automatique si les prix rapportés bougent en dehors des plages attendues par unité de temps.

Le gel par les validateurs Stellar de 7,2 M$ est une démonstration notable de ce qui est possible quand les chaînes ont des ensembles de validateurs petits et coordonnés disposés à prendre des actions de gel. La même capacité — exercée chez Sui (Cetus) et Terra (Astroport) — est précieuse pour la réponse à incident mais est structurellement incompatible avec les revendications de « neutralité crédible » que les maximalistes de la décentralisation font pour les grandes chaînes. Le compromis est réel et spécifique à la chaîne ; l'ensemble de validateurs de Stellar est suffisamment petit pour coordonner, et c'est ce qui a rendu la récupération possible.