Fulcrom Finance, platforma DeFi, została zmuszona do przejścia w tryb ograniczony po tym, jak feed cenowy Pyth Network, na którym polegała, przestał działać. Incydent, który tymczasowo ograniczył działania użytkowników, ujawnia centralną słabość zdecentralizowanych finansów: niemal całkowitą zależność od sieci oracle w zakresie danych rynkowych w czasie rzeczywistym.
Jak przebiegała awaria
Gdy feed Pyth przestał dostarczać dokładne dane cenowe, Fulcrom nie mógł zweryfikować wartości aktywów dla swoich funkcji pożyczkowych i handlowych. Protokół automatycznie przełączył się na tryb ograniczony, czyli środek bezpieczeństwa, który ogranicza niektóre operacje — zazwyczaj uniemożliwiając nowe pożyczki lub likwidacje do czasu otrzymania świeżych danych. Użytkownicy mogli nadal wypłacać istniejące pozycje, ale system skutecznie zamroził nową aktywność.
Dokładny czas trwania awarii feedu nie został ujawniony, ale zdarzenie to jest jednym z bardziej widocznych zakłóceń związanych bezpośrednio z pojedynczym dostawcą oracle. Fulcrom nie skonfigurował zapasowego źródła cen, pozostawiając się narażonym, gdy Pyth uległ awarii.
Pojedynczy punkt awarii oracle
Oracle łączą inteligentne kontrakty on-chain z danymi off-chain — cenami, pogodą, wynikami sportowymi — a DeFi od nich zależy. Uszkodzony lub zatrzymany feed może prowadzić do błędnych likwidacji, nieprawidłowych stóp procentowych lub, jak w przypadku Fulcrom, całkowitego zatrzymania podstawowych funkcji.
Pyth Network jest popularnym oracle wśród platform pochodnych i pożyczkowych, ponieważ pobiera dane z konsorcjum instytucjonalnych traderów i giełd. Jednak centralizacja agregacji cen — choć szybsza niż niektóre alternatywy — stwarza ryzyko koncentracji. Gdy Pyth przestaje działać, przestają działać również protokoły, które są od niego wyłącznie zależne.
Fulcrom nie wymienił żadnych zapasowych oracle ani nie wyjaśnił, dlaczego działał bez redundancji. Cisza sugeruje, że albo zespół wciąż ocenia alternatywy, albo uważa awarię Pyth za incydent wyjątkowy, a nie systemowe zagrożenie.
Co to zdarzenie mówi o zarządzaniu ryzykiem w DeFi
To nie był hack ani exploit zarządzania. To była rutynowa usterka infrastruktury spotęgowana brakiem redundancji. Protokoły DeFi często optymalizują pod kątem szybkości i niskiego opóźnienia, wybierając jeden szybki oracle zamiast konfiguracji wieloźródłowej, która mogłaby wprowadzić opóźnienia lub sprzeczne ceny. Kompromis staje się oczywisty, gdy to jedyne źródło zawiedzie.
Regulatorzy i audytorzy od lat wskazują zależność od oracle jako jedno z głównych ryzyk w DeFi. Przypadek Fulcrom daje im świeży, konkretny przykład: do sparaliżowania platformy nie potrzeba złego aktora, wystarczy techniczna usterka w usłudze zewnętrznej.
Dla użytkowników wnioskiem jest to, że odporność protokołu nie polega tylko na kodzie inteligentnych kontraktów — chodzi o to, skąd pozyskuje dane. Platforma, która na papierze wygląda solidnie, może natychmiast się zablokować, jeśli jej oracle zamilknie.
Fulcrom nie ogłosił, czy doda drugorzędny oracle ani czy wdroży ręczne nadpisanie w przypadku przyszłych awarii feedu. Ta decyzja prawdopodobnie zadecyduje, czy to zdarzenie stanie się tylko przypisem, czy studium przypadku pokazującym, że zdecentralizowane finanse potrzebują zdecentralizować swoje kanały informacyjne.
