Oracle, który stoi od 225 dni i nie zgłasza błędu

Odczyty w tym tekście wykonano 4 września 2026, 11:08 UTC, przez publiczny endpoint eth.blockscout.com. Adresy kontraktów podaję, bo cała wartość tego pomiaru polega na tym, że da się go powtórzyć na jedno wywołanie RPC.

Feed nie jest strumieniem, a świeżość jest problemem konsumenta

W modelu push, używanym przez Chainlink Data Feeds oraz przez kontrakty zmierzone w tym tekście, wartość jest zapisana w kontraktcie-agregatorze i siedzi tam, dopóki ktoś nie zapisze nowej. Wyobrażenie, że dane „płyną", jest błędne. Konsument czyta wartość funkcją latestRoundData(), która zwraca roundId, answer i updatedAt. Zapis wyzwala jeden z dwóch warunków: deviation threshold (procentowa zmiana wartości względem ostatniego zapisu) albo heartbeat (maksymalny czas bezczynności, po którym zapis następuje niezależnie od zmiany). Realne parametry dwóch opublikowanych feedów rezerw: TUSD ma heartbeat 24 godziny i próg odchylenia 5%, WBTC około 10 minut i 1% (Spark, Real-Time Reserve Attestation, 20 lipca 2026, 🟡). Powód różnicy jest po stronie aktywa: rezerwy WBTC są weryfikowalne on-chain co blok, rezerwy TUSD wymagają odpytania systemu bankowego.

Dokumentacja Chainlinka jest w tym punkcie jednoznaczna i przenosi odpowiedzialność tam, gdzie mało kto jej szuka: aplikacja powinna sama sprawdzać updatedAt i wstrzymać działanie, jeśli odpowiedź nie jest wystarczająco świeża (Chainlink Documentation, Data Feeds, 🟢).

Oracle nie zwraca błędu, gdy dana jest stara. Zwraca starą daną z prawdziwym znacznikiem czasu, a wykrycie tego jest zadaniem konsumenta. Nie jest to luka w projekcie, lecz sam projekt.

W jednym momencie wiek danej różnił się o cztery rzędy wielkości

Odczytałem osiem kontraktów oracle obsługujących NAV i parametry ryzyka tokenizowanych funduszy. Sześć z nich to LlamaGuardOracle (licencja BUSL-1.1), dwa to feedy Pendle. Wszystkie implementują AggregatorV2V3Interface.

Z tej tabeli wynikają cztery rzeczy.

Sześć z ośmiu feedów działa tak, jak powinno, i pokazuje mierzalny rytm. JAAA i JTRSY odświeżono 3,8 godziny przed odczytem, a USYC oraz USTB 21–22 godziny wcześniej. 4 września 2026 to piątek, a ostatni zapis dla USYC i USTB przypadł na czwartek po południu, czyli cykl dzienny z uwzględnieniem weekendu. Dzienna kadencja NAV jest zatem mierzalna, a nie tylko postulowana w materiałach dostawcy.

Oracle NAV dla USCC nie był aktualizowany od 225 dni. Kontrakt zwraca 1 145,6042 z prawdziwym, starym updatedAt i nie zgłasza błędu. Każdy konsument, który nie sprawdza znacznika czasu, dostanie tę liczbę jako aktualną.

Oracle NAV dla ACRED nigdy nie został zapisany: roundId = 0, answer = 0. Kontrakt jest wdrożony, ma nadane role, ma admina, a zwraca zero dla tokenizowanego funduszu kredytowego Apollo. Zerowa wycena jest groźniejsza od złej: zła o 20% daje straty proporcjonalne, zero daje natychmiastową likwidację całej pozycji collateralu albo, zależnie od kierunku użycia, pożyczkę bez ograniczenia.

Zapisuje jeden klucz, nie sieć węzłów. Rolę WRITER_ROLE, czyli uprawnienie do zapisu wartości, trzyma we wszystkich trzech sprawdzonych przypadkach kontrakt LlamaGuardOracleProxy. DEFAULT_ADMIN_ROLE trzymają konta zewnętrzne (EOA): dla USYC i ACRED dwa różne, dla USCC jedno (odczyt zdarzeń RoleGranted, 4 września 2026).

„Brak odczytu" to nie „zero" i nie wolno tego mieszać

Jedyny wbudowany bezpiecznik tych kontraktów to maxPriceDeviation, czyli maksymalne dopuszczalne odchylenie nowej wartości od poprzedniej, w punktach bazowych. Komentarz w kodzie mówi wprost: wartość 0 oznacza wyłączenie tej kontroli.

W siedmiu z ośmiu odpytanych adresów maxPriceDeviation() zwróciło potwierdzone 0: ACRED, USYC, USTB, JAAA, JTRSY oraz oba feedy Pendle. Kontrola odchylenia jest w nich wyłączona; nie ma żadnego on-chain ograniczenia, o ile nowa wartość może różnić się od poprzedniej. Jeden zapis może zmienić NAV o dowolną wielkość.

Dla USCC tego odczytu nie ma i trzeba to powiedzieć wprost. Wywołanie maxPriceDeviation() na 0x129c32858fD67645Ae9FB37c9f41b81D380e29c9 revertuje, bo kontrakt nie wystawia tej funkcji, więc jest to najpewniej inna albo starsza wersja implementacji. Nie wiadomo zatem, czy oracle USCC ma jakikolwiek limit odchylenia, czy nazywa się on inaczej, ani jaka jest jego wartość. „Brak odczytu" nie jest równoważny „potwierdzonemu zeru" i nie zapisuję go jako zera. Akurat w przypadku feedu, który stoi od 225 dni, byłaby to pomyłka najbardziej kusząca i najbardziej myląca.

Reszta architektury tych kontraktów jest solidna: dane historycznych rund są niezmienne po utworzeniu, a kontrakt prowadzi rejestr zmian parametrów ryzyka (updateHistory, updateTypes) i listę autoryzowanych rynków. Problem nie leży w kodzie, ale w tym, że nikt do niego nie pisze.

Interfejs zgodny ze standardem nie mówi nic o pochodzeniu danych

AggregatorV3Interface to standardowy interfejs feedów Chainlinka i każdy może go zaimplementować. To najważniejszy wniosek techniczny z tego pomiaru. Kontrakt, który ten interfejs implementuje, jest dla konsumenta nieodróżnialny od feedu sieci Chainlinka: te same funkcje, te same typy zwracane, ten sam sposób odczytu. Pod spodem może być sieć niezależnych węzłów z konsensusem i kryptograficznym podpisem raportu albo jeden adres z rolą WRITER_ROLE, wpisujący liczby, które sam uznał za właściwe.

Zgodność interfejsu nie dowodzi pochodzenia danych. Nie dowodzi też, że dane są odświeżane ani że mają jakiekolwiek zabezpieczenie odchylenia. Przy ocenie integracji rozstrzyga zatem nie interfejs, ale to, kto pisze i jak często. Oba te fakty są odczytem on-chain, nie pytaniem do działu sprzedaży.

Oracle nie liczy NAV, tylko go przenosi

NAV (net asset value, wartość aktywów netto na jednostkę) nie jest liczony przez oracle, przez emitenta tokena ani przez blockchain. Liczy go fund administrator, czyli podmiot prowadzący księgi funduszu według zasad rachunkowości funduszowej; w BUIDL to BNY Mellon. Tu leży źródło większości nieporozumień o tej warstwie. Filing SEC Securitize (Form 424B3, 2026, 🟢) mówi to wprost: informacja o NAV dostarczana smart contractom pochodzi od właściwego fund administratora albo transfer agenta, a dostawcy oracle służą do jej przeniesienia.

Konsekwencja jest praktyczna: doskonała sieć oracle przeniesie do łańcucha złą liczbę, jeśli administrator ją źle policzy albo poda z opóźnieniem. Decentralizacja chroni przed manipulacją w transporcie, nie przed błędem u źródła.

Do tego dochodzi rzecz, której prawie nikt nie wyjaśnia: dzienna publikacja nie oznacza dziennej wyceny. Kredyt prywatny wycenia się klasycznie kwartalnie, a po wejściu modelu TSSO (Trusted Single Source Oracle, pilotaż RedStone i Securitize ogłoszony 1 lipca 2025, 🟢) publikuje się go dziennie. Jeśli administrator wycenia portfel modelem raz na kwartał i przez 90 dni publikuje interpolację plus narosłe odsetki, dzienny NAV jest dziennie aktualizowany, ale nie dziennie ustalany. Pytanie do emitenta dotyczy więc częstotliwości wyceny, nie częstotliwości publikacji.

Domyślny model oracle (cena z dziesięciu giełd, odrzucenie skrajnych, mediana) tu nie działa. Aktywa na platformach tokenizacyjnych zwykle nie są swobodnie handlowane na rynku wtórnym i nie mają ciągłej ceny rynkowej (SEC EDGAR, Securitize Form 424B3, 2026, 🟢). Nie ma czego agregować, a dziesięć źródeł tej samej liczby to jedno źródło skopiowane dziesięć razy. Stąd TSSO: nie udawać wielu źródeł, ale uczynić jedno weryfikowalnym i podpisanym on-chain.

Dostawca sam ostrzega przed swoim feedem

Dokumentacja Chainlinka do feedów Proof of Reserve (🟢) mówi, że feedy cross-chain używające kontraktów zarządzających listą adresów mogą różnić się konfiguracją, a jeśli menedżer tej listy jest samoraportujący, feed może obejmować salda z adresów, których własność nie została kryptograficznie potwierdzona. To ujawnienie od strony, która mogłaby milczeć. W takim przypadku istnieje ryzyko, że emitent zawyży wartość feedu, dodając do listy adresy, których nie kontroluje. Chainlink Labs dodaje, że nie odpowiada za dokładność danych samoraportowanych.

Znaczy to dokładnie tyle: PoR weryfikuje, że pod wskazanymi adresami leżą wskazane środki, a nie że te adresy należą do emitenta, chyba że konfiguracja konkretnego feedu to zapewnia. Sprawdzenie tej konfiguracji jest częścią analizy produktu, nie szczegółem technicznym.

Trzy z czterech mechanizmów strat nie są problemem sieci oracle

Cztery udokumentowane incydenty z okresu od listopada 2025 do sierpnia 2026 mają cztery różne mechanizmy, a mieszanie ich pod hasłem „oracle risk" zaciera to, co z nich wynika.

Źródło wyceny. 4 listopada 2025 Stream Finance ujawnił, że zewnętrzny zarządzający stracił około 93 mln USD aktywów protokołu. xUSD stracił peg, kontagion oszacowano na około 285 mln USD, a deUSD od Elixira spadł o ~98% (CCN, Tiger Research, BlockEden, listopad 2025, 🟡). Kluczowy szczegół: protokół pożyczkowy wyceniał xUSD po 1,06 USD, gdy rynek płacił około 0,86 USD, bo wycena opierała się na cenie zadanej na sztywno albo na NAV raportowanym przez sam protokół. Żaden feed nie zawiódł, bo nikt żadnego feedu nie odpytywał. Do tego rozbieżność widoczna przed upadkiem: z około 500 mln USD deklarowanego TVL weryfikowalne on-chain było około 170 mln USD.

Konfiguracja u konsumenta. W lutym 2026 błędna konfiguracja oracle'a dla cbETH na Base zostawiła protokół Moonwell z 1,78 mln USD złego długu (cryptonews.com, 🟡). Nie było ataku. Był zły parametr.

Manipulacja przy cienkiej płynności. W sierpniu 2026 eksploit oracle'a cenowego wyprowadził z tego samego protokołu 8,7 mln USD przez token MAMO, czyli trzecia awaria oracle'owa w jedenaście miesięcy, o wartości przekraczającej cały roczny przychód protokołu (crypto.news, TechTimes, 27 sierpnia 2026, 🟡). A 15 lipca 2026 platforma Ostium na Arbitrum, oferująca instrumenty pochodne na aktywa rzeczywiste, straciła 23,75 mln USD w USDC w eksploicie oracle'a (🔴).

Starzenie danej bez ataku. Czwarty mechanizm nie ma jeszcze kwoty straty i to jest w nim najciekawsze. W sierpniu 2026 pojawiła się analiza opisująca, że starzenie się danych oracle'owych może złamać protokół DeFi bez żadnego hacku (CryptoDaily, 🟡). Pomiar z tego tekstu jest tej analizy stanem faktycznym: dwa kontrakty na mainnecie, jeden z daną z 22 stycznia, drugi z zerem, oba z interfejsem Chainlinka.

Te cztery mechanizmy siedzą w czterech różnych punktach: źródło wyceny, konfiguracja konsumenta, płynność rynku, świeżość danej. Trzy z czterech nie są problemem sieci oracle i decentralizacja żadnego z nich nie rozwiązuje. Debata publiczna koncentruje się na transporcie, czyli na odporności sieci węzłów na atak, a to w RWA najrzadsza przyczyna strat.

Pomiar dotyczy stanu tych oracle'ów, nie ich wykorzystania

To zastrzeżenie jest częścią wyniku, nie przypisem do niego.

Zmierzono stan ośmiu oracle'ów, nie ich wykorzystanie. Odczytałem, że dana USCC ma 225 dni i że dana ACRED nigdy nie została zapisana. Nie ustaliłem, czy jakikolwiek aktywny kontrakt czyta cenę z tych adresów. Mogą to być kontrakty przygotowane, zapasowe albo wycofane. Pomiar dowodzi, że dana jest stara, a nie że ktoś jej używa jako aktualnej.

Powiązanie z konkretnym rynkiem pożyczek jest poszlaką, nie dowodem. Aave pisze na własnym blogu, że warstwę wyceny i walidacji on-chain dla Horizona dostarcza Chainlink przez „LlamaGuard Net Asset Value (NAV)" (🟢), LlamaRisk jest dostawcą ryzyka tego rynku, a zbiór aktywów pokrytych tymi oracle'ami (USCC, USTB, USYC, JAAA, JTRSY) odpowiada liście collateralu Horizona, przy czym ACRED jest collateralem na Morpho. Nazwa produktu, nazwa dostawcy i lista aktywów zgadzają się w trzech niezależnych punktach. To mocna poszlaka i nadal nie dowód: rozstrzygnięcie wymaga odczytania konfiguracji oracle w kontraktach puli, czego nie zrobiono. Nie formułuję z tego twierdzenia o awarii tego rynku.

Druga strona tej samej niewiedzy jest równie istotna. Aave pisze, że operatorzy Chainlinka „wspierają automatyczne zabezpieczenia, gdy feedy są stale albo poza zakresem" (🟢), ale nie podaje progu ani zachowania. Jeśli takie zabezpieczenie działa, skutkiem starej danej nie jest zła wycena, a zamrożenie rynku: brak nowych pożyczek, brak likwidacji, pozycje uwięzione. To bezpieczniejszy scenariusz niż zła cena. Który z dwóch zachodzi, nie wiadomo.

Jest jeszcze rachunek pokazujący, jak mało znaczy sama liczba bez kierunku. Jeśli przyjąć skalowanie ×100 przez analogię do USTB (który raportuje 11,19943 dla NAV rzędu 11,20), to odczyt 1 145,6042 odpowiada NAV/S ≈ 11,456 na 22 stycznia 2026, wobec 11,72 na 4 września 2026 (rwa.xyz, karta USCC, 4 września 2026, 🟢), czyli zaniżeniu wartości collateralu o 2,25%, a więc w stronę konserwatywną. Skalowanie jest inferencją, nie odczytem, i tak je oznaczam. Ten paradoks działa jednak tylko dlatego, że NAV rósł. USCC to fundusz basis z efektami mark-to-market i jego NAV może spadać; przy spadającym NAV zamrożona dana pokazuje collateral droższy niż jest, health factory wyglądają zdrowo, likwidacje się nie odpalają, a dziura rośnie po cichu. To dokładnie ten kształt awarii, który zmaterializował się przy Stream Finance.

Trzy odczyty, które rozstrzygają więcej niż cała dokumentacja

Teza tego tekstu jest wąska i dlatego mocna: w RWA groźniejsza od złej liczby jest liczba, której nikt nie odświeżył, bo zła liczba zwykle zostawia ślad w cenie, a stara nie zostawia żadnego. Kontrakt nie ma jak jej odrzucić. Z jego punktu widzenia dana z 22 stycznia jest tak samo poprawna jak dana z dzisiejszego południa, bo poprawność w rozumieniu agregatora to obecność wartości i znacznika czasu, nie ich sensowność.

Cała ta analiza zajęła kilka wywołań RPC bez klucza API i bez współpracy emitenta. Trzy rzeczy do odczytania przy każdym RWA używanym jako collateral: updatedAt (ile godzin ma dana), roundId > 0 (czy kiedykolwiek zapisano) i answer > 0 (czy nie jest zerem). Czwarta rzecz jest trudniejsza i najważniejsza, a jest to kod konsumenta: czy sprawdza te trzy warunki, zanim na nich zbuduje decyzję o likwidacji. Odczyt jest dostępny każdemu i prawie nikt go nie wykonuje.