Czarny łabędź powraca: pięcioletnia recydywa luk w oraklach

Sprzedaż rynkowa o wartości 60 milionów dolarów doprowadziła do wyparowania 19.3 miliardów dolarów kapitalizacji rynkowej.

Autor: YQ

Tłumaczenie i opracowanie: Saoirse, Foresight News

(Treść oryginalna została zmodyfikowana i skrócona)

W dniach 10-11 października 2025 roku sprzedaż rynkowa o wartości 60 milionów dolarów doprowadziła do wyparowania 19.3 miliardów dolarów kapitalizacji rynkowej. Nie była to konsekwencja załamania rynku ani kaskady wezwań do uzupełnienia depozytu zabezpieczającego spowodowanych legalnymi stratami, lecz wynik awarii oracli.

To nie jest nowość. Od lutego 2020 roku ten sam schemat ataku był skutecznie wykorzystywany, powodując setki milionów dolarów strat w branży w dziesiątkach przypadków. Atak z października 2025 roku był 160 razy większy niż największy dotychczasowy atak na oracla — nie dlatego, że technologia była bardziej zaawansowana, ale dlatego, że podstawowe systemy, zwiększając skalę, zachowały te same fundamentalne luki.

Pięć lat bolesnych lekcji zostało zignorowanych. Niniejsza analiza wyjaśnia, dlaczego tak się stało.

2020-2022: „Stały scenariusz” ataków na oracla

Zanim przeanalizujemy wydarzenia z października 2025 roku, należy podkreślić: podobne sytuacje już miały miejsce.

Luty 2020: Incydent bZx (strata 350 tysięcy dolarów + 630 tysięcy dolarów)

Wykorzystano oracla z pojedynczego źródła, a atakujący poprzez flash loan zmanipulował cenę WBTC na platformie Uniswap, przenosząc 14,6% całkowitej podaży tego tokena, co pozwoliło na manipulację danymi cenowymi, na których całkowicie polegała platforma bZx.

Październik 2020: Incydent Harvest Finance (24 miliony dolarów skradzione, wywołując odpływ 570 milionów dolarów)

W zaledwie 7 minut atakujący, wykorzystując flash loan o wartości 50 milionów dolarów, zmanipulował ceny stablecoinów na platformie Curve, co doprowadziło nie tylko do kradzieży środków, ale także do załamania infrastruktury i odpływu płynności — skutki znacznie przekroczyły początkową kwotę kradzieży.

Listopad 2020: Incydent Compound (89 milionów dolarów aktywów zlikwidowanych)

Stablecoin DAI na platformie Coinbase Pro wzrósł do 1,30 dolara, podczas gdy na innych platformach nie odnotowano takiego ruchu. Ponieważ oracle Compound opierał się na wycenie z Coinbase, użytkownicy zostali przymusowo zlikwidowani z powodu anomalii cenowej trwającej zaledwie godzinę. Wówczas wystarczyło 100 tysięcy dolarów, by zmanipulować orderbook o głębokości 300 tysięcy dolarów.

Październik 2022: Incydent Mango Markets (strata 117 milionów dolarów)

Atakujący, wykorzystując 5 milionów dolarów kapitału początkowego, podbił cenę tokena MNGO na kilku platformach o 2394%, następnie, wykorzystując przewartościowane zabezpieczenie, pożyczył 117 milionów dolarów i użył skradzionych tokenów governance do głosowania na swoją korzyść, wyłudzając 47 milionów dolarów „nagrody za znalezienie luki”. Była to pierwsza akcja egzekucyjna Commodity Futures Trading Commission (CFTC) przeciwko manipulacji oraclem.

Wszystkie ataki przebiegały według tego samego schematu:

1. Identyfikacja zależności oracla od „manipulowalnych źródeł danych”;
2. Obliczenie opłacalności: koszt manipulacji < możliwa do uzyskania wartość;
3. Przeprowadzenie manipulacji;
4. Wycofanie się z zyskiem.

W latach 2020-2022, 41 ataków na oracla doprowadziło do kradzieży 403.2 milionów dolarów. Reakcja branży była jednak rozproszona, powolna i niepełna — większość platform nadal korzystała z oracli opartych głównie na cenach spot, bez odpowiedniej redundancji.

Następnie nadeszła katastrofa października 2025 roku.

Analiza luki „10.11”

10 października 2025 roku o godzinie 5:43 rano, skoncentrowana sprzedaż 60 milionów dolarów USDe wywołała śmiertelną reakcję łańcuchową:

Sprzedaż spot o wartości 60 milionów dolarów → oracle obniża wycenę zabezpieczeń (wBETH, BNSOL, USDe) → masowe przymusowe likwidacje → przeciążenie infrastruktury → próżnia płynności → wyparowanie 19.3 miliardów dolarów kapitalizacji rynkowej

Nie była to porażka jednej platformy, lecz ujawnienie długo istniejących luk w całej branży — mimo wysokich kosztów ponoszonych przez pięć lat, luki te nie zostały naprawione:

1. Nadmierna zależność od cen spot

Mimo że każda poważna luka od 2020 roku wykorzystywała „manipulowalność cen spot”, większość platform nadal korzysta z oracli opartych na cenach spot. Branża wie o ryzyku manipulacji cenami spot, wie też, że „średnia ważona czasowo cena (TWAP)” i „oracla wieloźródłowe” zapewniają lepszą ochronę, lecz wdrożenie tych rozwiązań pozostaje niepełne.

Źródłem problemu jest to, że „szybkość i czułość” były postrzegane jako zalety, zanim stały się lukami. Aktualizacja cen w czasie rzeczywistym wydaje się dokładniejsza — dopóki ktoś nie zacznie nią manipulować.

2. Ryzyko centralizacji

Dominujące platformy handlowe tworzą „pojedyncze punkty awarii”: bZx polegał na Uniswap, Compound na Coinbase, platformy z 2025 roku na własnych orderbookach — to wciąż ten sam problem — platformy się zmieniają, luka pozostaje.

Kiedy jedna giełda dominuje w wolumenie, wydaje się logiczne, by była głównym źródłem danych dla oracla. Jednak ryzyko centralizacji w przesyle cen jest takie samo jak w każdym innym systemie: wszystko wydaje się w porządku, dopóki nie zostanie wykorzystane.

3. Błędne założenia infrastrukturalne

Systemy zaprojektowane dla „normalnych warunków rynkowych” zawodzą katastrofalnie pod presją. Harvest Finance już w 2020 roku to udowodnił, ale wydarzenia z października 2025 roku pokazują, że branża wciąż projektuje systemy „na normalne warunki, licząc, że sytuacje stresowe nigdy nie nastąpią”.

A „liczenie na szczęście” to nie jest strategia.

4. Paradoks przejrzystości

Publikowanie planów ulepszeń technicznych może stworzyć okno do ataku. Ośmiodniowa luka między ogłoszeniem a wdrożeniem aktualizacji algorytmu oracla dała profesjonalnym atakującym jasny harmonogram i mapę działania — dokładnie wiedzieli, kiedy i jak zaatakować.

To „nowy tryb awarii starego problemu”: wcześniej ataki wykorzystywały „istniejące luki”, a atak z października 2025 roku wykorzystał „okres przejściowy podczas zmiany algorytmu oracla” — luka istniała tylko dlatego, że plan ulepszeń został ogłoszony z wyprzedzeniem.

Droga wyjścia

Natychmiastowe środki naprawcze

1. Hybrydowy projekt oracla

Integracja wielu źródeł cen i wdrożenie skutecznych mechanizmów weryfikacji racjonalności:

• Ceny z giełd scentralizowanych (CEX) (ważone wolumenem międzyplatformowym, udział 40%);
• Ceny z giełd zdecentralizowanych (DEX) (tylko pule o wysokiej płynności, udział 30%);
• Dowód rezerw on-chain (udział 20%);
• Współczynnik konwersji aktywów opakowanych (udział 10%).

Kluczowe jest „niezależność źródeł danych”: jeśli przy rozsądnych kosztach można zmanipulować wszystkie źródła jednocześnie, to „wieloźródłowość” w istocie pozostaje „jednoźródłowością”.

2. Dynamiczna regulacja wag

Dostosowanie czułości oracla do warunków rynkowych:

• Okresy normalnej zmienności: standardowe wagi;
• Okresy wysokiej zmienności: wydłużenie okna obliczania TWAP, zmniejszenie wpływu cen spot;
• Okresy ekstremalnej zmienności: uruchomienie mechanizmu awaryjnego, weryfikacja racjonalności.

Incydent Compound z 2020 roku już udowodnił: czasem „prawidłowa cena” na jednej giełdzie jest błędna dla całego rynku. Oracla muszą umieć wykrywać takie odchylenia.

3. Mechanizm awaryjny (circuit breaker)

Zawieszenie likwidacji podczas ekstremalnych wahań cen — celem nie jest powstrzymanie „uzasadnionego delewarowania”, lecz rozróżnienie „manipulacji” od „rzeczywistej sytuacji rynkowej”:

• Jeśli ceny na wielu platformach zbieżne w ciągu kilku minut: prawdopodobnie rzeczywista zmienność rynkowa;
• Jeśli anomalia tylko na jednej platformie: prawdopodobnie manipulacja;
• Jeśli infrastruktura przeciążona: zawieszenie likwidacji do czasu przywrócenia pojemności.

Głównym celem nie jest „zakaz wszystkich likwidacji”, lecz „uniknięcie kaskadowych likwidacji wywołanych manipulacją cenami”.

4. Skalowanie infrastruktury

Projektowanie systemów na „100-krotność normalnej pojemności” — ponieważ reakcje łańcuchowe generują wykładnicze obciążenie:

• Budowa niezależnej infrastruktury dla przesyłu cen;
• Wdrożenie niezależnych silników likwidacyjnych;
• Ograniczenie liczby żądań z pojedynczego adresu;
• Opracowanie protokołów „łagodnej degradacji” (priorytet dla kluczowych funkcji przy przeciążeniu).

Jeśli system nie wytrzyma obciążenia wywołanego reakcją łańcuchową, katastrofa się pogłębi. To konieczność projektowa, nie opcja optymalizacyjna.

Długoterminowe rozwiązania

1. Zdecentralizowana sieć oracli

Wdrożenie dojrzałych rozwiązań oracli (np. Chainlink, Pyth, UMA), które dzięki agregacji między źródłami danych mają wbudowaną odporność na manipulacje. Nie są idealne, ale znacznie lepsze niż oracla oparte na cenach spot, atakowane co 18 miesięcy.

bZx po ataku w 2020 roku wdrożył Chainlink i od tego czasu nie doświadczył ataku na oracla — to nie przypadek.

2. Integracja dowodu rezerw

Dla aktywów opakowanych i stablecoinów konieczna jest weryfikacja wartości zabezpieczenia on-chain. Na przykład wycena USDe powinna opierać się na „weryfikowalnych rezerwach”, a nie „dynamice orderbooka”. Technologia już istnieje, opóźnia się tylko wdrożenie.

3. Stopniowa likwidacja

Stopniowe likwidacje, by uniknąć eskalacji reakcji łańcuchowej:

• Pierwszy próg: ostrzeżenie, czas na uzupełnienie zabezpieczenia przez użytkownika;
• Drugi próg: częściowa likwidacja (25%);
• Trzeci próg: większa likwidacja (50%);
• Ostateczny próg: całkowita likwidacja.

Daje to użytkownikom czas na reakcję i zmniejsza wpływ „masowych likwidacji synchronicznych” na system.

4. Monitoring i audyt w czasie rzeczywistym

Monitorowanie manipulacji oraclem w czasie rzeczywistym:

• Odchylenia cen między platformami;
• Nietypowy wolumen na parach o niskiej płynności;
• Szybki wzrost pozycji przed aktualizacją oracla;
• Dopasowanie do znanych wzorców ataków.

Atak z października 2025 roku powinien był wygenerować sygnały ostrzegawcze: sprzedaż 60 milionów dolarów USDe o 5:43 rano to transakcja, która musi wywołać alarm. Jeśli system monitoringu tego nie wykrył, oznacza to poważne braki.

Wnioski: ostrzeżenie za 19 miliardów dolarów

Kaskadowe likwidacje z 10-11 października 2025 roku nie były skutkiem „nadmiernej dźwigni” czy „paniki rynkowej”, lecz „systemowej porażki projektowej oracli na dużą skalę”. To, że operacja rynkowa za 60 milionów dolarów doprowadziła do strat rzędu 19.3 miliardów dolarów, wynikało z tego, że system przesyłu cen nie potrafił odróżnić „manipulacji” od „prawidłowego odkrywania ceny”.

To jednak nie jest nowy problem — ten sam typ awarii zniszczył bZx w lutym 2020, Harvest w październiku 2020, Compound w listopadzie 2020 i Mango Markets w październiku 2022.

W ciągu pięciu lat branża pięciokrotnie uczyła się tej samej lekcji, za każdym razem płacąc coraz wyższą cenę:

• 2020: pojedyncze protokoły wyciągają wnioski i wdrażają poprawki;
• 2022: interwencja regulatorów, rozpoczęcie egzekwowania prawa;
• 2025: cały rynek płaci „czesne” w wysokości 19.3 miliardów dolarów.

Pozostaje tylko jedno pytanie: czy w końcu zapamiętamy tę lekcję?

Wszystkie platformy obsługujące pozycje lewarowane muszą zmierzyć się z następującymi pytaniami:

• Czy nasze oracla są odporne na wektory ataku zidentyfikowane w latach 2020-2022?
• Czy nasza infrastruktura jest gotowa na scenariusze kaskadowych likwidacji, które już się wydarzyły?
• Czy osiągnęliśmy rozsądny kompromis między „czułością” a „stabilnością”?
• Czy powielamy błędy, które już kosztowały branżę setki milionów dolarów?

Pięć lat historii dowiodło: manipulacja oraclem to nie „hipotetyczne ryzyko” czy „marginalny przypadek”, lecz „udokumentowana, powtarzalna i bardzo zyskowna” strategia ataku, której skala rośnie wraz z rynkiem.

Wydarzenia z października 2025 roku pokazują, jak katastrofalne mogą być skutki ignorowania tych lekcji na poziomie instytucjonalnym. Ten atak nie był ani skomplikowany, ani nowatorski — to ta sama metoda, wykorzystana w „oknie znanej luki”, lecz na większą skalę.

Oracla są fundamentem całego systemu. Gdy fundament pęka, wszystko się wali. Od lutego 2020 roku wiemy to i wydaliśmy już miliardy dolarów, by się o tym przekonać. Pozostaje pytanie, czy kosztowny incydent z października 2025 roku wystarczy, by w końcu zamienić znane lekcje w działanie.

W dzisiejszym wysoce połączonym rynku projektowanie oracli to nie tylko „przesyłanie danych” — to kwestia stabilności całego systemu. Jeden błąd w projekcie i 60 milionów dolarów może zniszczyć wartość 19 miliardów dolarów.

Jeśli nadal będziemy popełniać te same błędy, to nie dlatego, że nie uczymy się z historii, lecz dlatego, że cena powtarzania tych błędów staje się coraz wyższa.

Niniejsza analiza opiera się na publicznych danych rynkowych, oświadczeniach platform oraz studiach przypadków manipulacji oraclem z ostatnich pięciu lat.