Fulcrom Finance entre en mode dégradé après la panne du réseau Pyth

Fulcrom Finance, une plateforme d'échange perpétuel décentralisée construite sur la blockchain Cronos, est passée en mode de trading dégradé après qu'une panne importante a affecté sa source principale de données de prix, Pyth Network. La plateforme a invité les utilisateurs à éviter d'ouvrir de nouvelles positions pendant que le flux était hors ligne.

La perturbation a commencé vers 02:58 UTC le 22 mai, touchant l'infrastructure Pythnet et Hermes de Pyth, et a duré plus de quatre heures. Pour une plateforme qui traite des trades à effet de levier en utilisant des prix en temps réel, quatre heures sans données fiables sont moins un « simple bogue » et plus « les lumières clignotent dans la salle d'opération ».

Pyth Network aggrège une vaste quantité de données de prix, puisant des informations auprès d'éditeurs institutionnels et les distribuant sur plus de 100 blockchains. Le réseau prend en charge plus de 3 000 flux de prix individuels et collabore avec plus de 130 éditeurs de données sur 114 chaînes. Autrement dit, il constitue l'infrastructure sur laquelle de nombreux protocoles DeFi s'appuient.

Lorsque cette canalisation a cessé de fonctionner, Fulcrom a été l'une des plateformes prises au dépourvu. La plateforme repose sur les prix d'actifs en temps réel de Pyth pour alimenter son modèle de trading perpétuel à faibles frais et ses pools de liquidité. Sans des données de prix précises, exécuter des trades leviers devient un jeu de fléchettes les yeux bandés, ce qui explique pourquoi l'équipe a rapidement signalé l'état dégradé.

Voici le problème avec les échanges perpétuels : ils ont besoin de prix constants et précis pour calculer les taux de financement, évaluer les positions et déclencher des liquidations. Lorsque l'oracle est hors ligne, la plateforme d'échange perd littéralement la capacité de déterminer la valeur de quoi que ce soit. Ce n'est pas une situation dans laquelle vous voulez que les traders s'engagent massivement dans des longs 50x.

Fulcrom avait intégré les flux Pyth dès le début de son développement, tirant parti du support dédié de Pyth pour l'écosystème Cronos lancé en mars 2023. L'intégration avait du sens à l'époque et en a encore sur le papier. Mais les points uniques de défaillance ont tendance à se révéler aux moments les plus inopportuns.

La bonne nouvelle : Fulcrom est revenu à un fonctionnement normal après la résolution de la panne, sans signalements généralisés de liquidations majeures ou de retards importants dans le volume de trading. Pour une plateforme comptant environ 13,5 millions de dollars en valeur totale verrouillée et un volume de trading cumulé dépassant 13,7 milliards de dollars, c’est un résultat meilleur que ce que beaucoup auraient pu attendre.

Aucune cascade de liquidations catastrophiques. Aucun fonds d'utilisateur perdu. L'avertissement en mode dégradé semble avoir fonctionné comme prévu, en évitant aux traders de s'aventurer dans un champ de mines.

Le token de gouvernance de Fulcrom, FUL, affiche une capitalisation boursière proche de 18 millions de dollars, avec un prix de négociation autour de 0,0011 $ . Le token propre à Pyth, PYTH, était récemment négocié dans la fourchette de 0,04 $ . Aucun de ces deux tokens ne semble avoir subi un effondrement dramatique suite à l’incident, bien que les implications réputationnelles soient plus difficiles à évaluer.

Regardez, le fait que Fulcrom ait géré cela sans catastrophe mérite vraiment d’être souligné. L’histoire du DeFi est parsemée d’incidents liés aux oracles qui se sont terminés par des coffres vides et des canaux Discord en colère. Les attaques de bZx en 2020, diverses exploitations par flash loans et d’innombrables cascades de liquidations ont toutes été attribuées à des défaillances ou manipulations d’oracles. Le fait que Fulcrom ait évité ce danger témoigne d’une gestion des risques raisonnable de leur part.

L'incident est une illustration type du risque de dépendance aux oracles, qui est sans doute la menace systémique la plus sous-estimée dans la finance décentralisée. Chaque DEX perpétuel, protocole de prêt et plateforme d'actifs synthétiques a besoin de données de prix externes pour fonctionner. Ces données doivent provenir d' quelque part, et « quelque part » est généralement un petit nombre de réseaux d'oracles.

Pyth est l’un des plus grands. Chainlink est l’autre acteur majeur. Lorsque l’un ou l’autre connaît une interruption, les répercussions peuvent toucher des dizaines ou des centaines de protocoles simultanément. En anglais : l’ensemble de l’écosystème DeFi est construit sur l’hypothèse que quelques fournisseurs de données maintiendront un temps de disponibilité quasi parfait. Cette hypothèse a tenu cette fois-ci. Ce ne sera pas toujours le cas.

Pour les utilisateurs de Fulcrom spécifiquement, cet épisode soulève des questions sur la redondance. La plateforme dispose-t-elle d'options de secours pour les oracles ? Peut-elle basculer vers une autre source de prix en cas de panne ? Ce sont ce genre de détails d’infrastructure qui rares fois apparaissent dans les documents marketing, mais qui sont extrêmement importants lorsque les choses dérivent.

Pour le marché dans son ensemble, la fenêtre de quatre heures rappelle que le récit du DeFi « toujours actif » comporte des réserves. Les plateformes d'échange traditionnelles disposent de dispositifs de coupure et d'arrêt conçus précisément pour ces scénarios. Les plateformes décentralisées sont encore en train de définir leur propre protocole équivalent, et « demander aux utilisateurs d'arrêter de trader » est à peu près aussi manuel que possible.

Pyth, pour sa part, a investi dans l'amélioration de son infrastructure, notamment des outils pour une meilleure transparence des flux et une protection contre la valeur extraite par les mineurs. La capacité du réseau à maintenir ses opérations sur d'autres services pendant la panne suggère que le problème était limité et non systémique. Mais les problèmes limités ont tendance à s'étendre si les causes racines ne sont pas traitées.

Les traders détenant des positions levier sur toute plateforme dépendant d'un oracle devraient considérer cet incident comme un test de stress à partir duquel ils peuvent apprendre. La prochaine interruption pourrait ne pas être résolue en quatre heures, et la prochaine plateforme pourrait ne pas gérer le mode dégradé aussi efficacement. Intégrer ce risque dans la taille des positions et le choix de la plateforme n'est pas de la paranoïa. C'est simplement des mathématiques.