Ostateczny termin wsparcia Switchboard pozostawia protokoły Solana z koniecznością weryfikacji aktywnych zależności od wyroczni

Ostateczny termin wsparcia Switchboard 25 września zamienił sześciodniowe ostrzeżenie o migracji w test feedów cenowych Solany. Publiczna dokumentacja pokazuje, gdzie wyrocznia pozostaje częścią projektu aplikacji, ale te strony nie mogą udowodnić, że aktywny rynek nadal korzysta z feedu. Jito i marginfi przedstawiają dwa odmienne obrazy potencjalnej ekspozycji.

Switchboard osiągnął zadeklarowany koniec wsparcia technicznego 25 września, pozostawiając aplikacjom Solany weryfikację źródeł cen skonfigurowanych w ich aktywnych programach.

Oświadczenie projektu wyroczni z 19 września, przytoczone w relacjach z ogłoszenia mówiło, że jego główny udziałowiec rozwojowy, Switchboard Technology Labs, zakończy działalność, a wszystkie implementacje zostaną natychmiast zdeprecjonowane. Zespół wezwał integratorów do migracji do innych dostawców, wymieniając Pyth i RedStone. 25 września opisano jako ostatni dzień istniejącego wsparcia.

Zakończenie wsparcia technicznego to rzeczywisty kamień milowy operacyjny. Samo w sobie nie dowodzi jednak, że każdy feed on-chain przestał się aktualizować o północy ani że każda aplikacja kiedykolwiek powiązana ze Switchboard pozostawała od niego zależna.

Własna dokumentacja Switchboard wymieniała Kamino, Jito, marginfi i Drift jako użytkowników. To historyczne deklaracje integracji od dostawcy sprzedającego usługę wyroczni, a nie spis w czasie rzeczywistym aktywnych feedów na dzień 25 września. Aktualna dokumentacja każdego projektu przedstawia bardziej skomplikowany obraz. Strony Tip Routera w Jito nadal opisują Switchboard w swoim przepływie wyceny, podczas gdy wrześniowa aktualizacja techniczna marginfi dodaje ścieżki zaprojektowane tak, aby uniknąć tej zależności. Jeden dokument może być nieaktualny, gdy inny antycypuje migrację. Żaden nie zastępuje inspekcji aktywnej konfiguracji kont.

Wcześniejsza runda finansowania Switchboard wyniosła 7,5 mln dolarów w maju 2024 roku. Kwota ta dostarcza tła historycznego przedsięwzięcia, ale nie mierzy bieżącej ekspozycji protokołu. Istotna jest liczba i wartość aktywnych rynków, których obliczenia ryzyka wciąż korzystają z danych z feedu, którego nie można niezawodnie aktualizować. Tego nie da się wywnioskować z logo klienta.

Wymieniona integracja to nie aktywny feed

Publiczne wprowadzenie Switchboard opisuje feedy na żądanie: aplikacje tworzą lub wywołują potrzebne dane, a cena jest udostępniana przez konta Solany. Dokumentacja może wskazać, gdzie protokół potrafi odczytać feed Switchboard, ale może nie wskazywać, którą opcję dany rynek aktualnie wybiera. Zestaw deweloperski (SDK) może obsługiwać typ wyroczni długo po tym, jak ostatni bank od niego odstąpił. Odwrotnie, strona internetowa może się zmienić, podczas gdy aktywny rezerwa zachowuje starsze konto wyroczni.\nTrzy poziomy dowodów należy rozdzielać. Pierwszy to strona marketingowa lub integracyjna, która pokazuje, że relacja istniała. Drugi to obsługiwana konfiguracja programu, widoczna w dokumentacji technicznej lub kodzie. Trzeci to aktywna konfiguracja i niedawna historia aktualizacji rzeczywistego rynku. Tylko trzeci może uzasadniać twierdzenie, że dany rynek w określonym czasie nadal polegał na Switchboard. Nawet wtedy może być skonfigurowane źródło zapasowe, więc skutki zatrzymania feedu podstawowego trzeba sprawdzić względem właściwej reguły fallback i świeżości.

Dokumentacja protokołu marginfi zachowuje SwitchboardPull i warianty venue wśród dostępnych konfiguracji oracle. Mówi, że wywołujący musi skrankować feed pull Switchboard bezpośrednio przed użyciem. Ta sama tabela wymienia feedy push Pyth i konta Scope jako inne konfiguracje. Dalsza obecność wiersza Switchboard nie jest dowodem, że każdy bank marginfi nadal go używa; tabela opisuje obsługiwane typy, a nie kompletną listę tego, który bank używa którego feedu dzisiaj.

Osobna notka Program 0.1.11 marginfi jest bardziej aktualna i konkretna. Nakazywała deweloperom aktualizację SDK co najmniej do wersji 2.8.0 przed 4 września, informując, że od tej daty banki zaczną przechodzić na nowe konfiguracje oracle. Wydanie dodało dziewięć wariantów niezależnych od Switchboard, w tym feedy Kamino Scope oraz wycenę opartą na kursach wymiany dla certain tokenów liquid stakingu i principal tokens.

Notka nie mówi, że każdy bank dokonał migracji do 25 września. Pokazuje jednak, że marginfi publicznie udokumentował trasę odchodzenia od zagrożonej zależności przed ogłoszeniem zamknięcia.

Migracja wprowadziła drugi możliwy tryb awarii. Marginfi informuje, że starsze SDK nie potrafią zdekodować banku skonfigurowanego z jedną z nowych wartości enum wyroczni. Pojedynczy bank z nieobsługiwaną wartością może uniemożliwić Project0Client.initialize i odczyty banków, a nie tylko akcję dotyczącą tego banku. Zmiana wyroczni może więc usunąć jedną zależność infrastrukturalną, łamiąc przy tym integratora, który nie zaktualizował swojego oprogramowania. Dokument marginfi wyjaśnia, jak integratorzy mogąiknąć problemu z SDK; nie jest dowodem, że jakikolwiek użytkownik go doświadczył.

Project 0 opisał unified margin na platformach Solany, w tym Kamino i Drift. Międzyprotokołowe interfejsy tworzą kolejną warstwę, na której migracja wyroczni musi być poprawnie oceniona. Ostrzeżenie o starszych wersjach SDK to konkretny dowód zagrożenia integracyjnego, ale nie dowodzi awarii w Project 0 ani jakiejkolwiek innej nazwanej aplikacji. Odpowiedzialny audyt sprawdziłby wersje oprogramowania i aktywne konfiguracje banków pożyczkowych przed twierdzeniem o awarii.

Tip Router Jito nadal dokumentuje Switchboard

Przegląd Tip Routera Jito Foundation mówi, że Switchboard określa względną wagę aktywów takich jak JitoSOL i JTO trzymanych w vaultach powiązanych z Tip Routerem. Przegląd identyfikuje program on-chain Tip Router, klienta operatora węzła i permissionless crankera. Dokumentacja wyceny wymienia Switchboard jako bieżący feed oracle i opisuje wagi zapasowe na wypadek niedostępności feedów.

Dokumenty umieszczają Switchboard w konkretnej roli: wyceny aktywów vaultów dla obliczeń wag w systemie dystrybucji tipów i restakingu. Nie mówią, że niedostępny feed Switchboard automatycznie zlikwidowałby pozycję pożyczkową w Solanie. Strona wyceny Jito opisuje mechanizm fallback, co osłabia uproszczone twierdzenie, że wygaśnięcie wsparcia musi zatrzymać wszystkie operacje Tip Routera. Dokładne wartości zapasowe, warunki aktywacji i aktualne konta oracle wciąż wymagają sprawdzenia bieżącego stanu programu.

Przegląd Tip Routera wykazywał znacznik ostatniej aktualizacji sprzed dziewięciu miesięcy, gdy sprawdzano go 25 września. Ten wiek ogranicza sposób użycia strony. Ustanawia udokumentowany projekt i wskazuje, gdzie kierować pytanie techniczne, ale nie może potwierdzić, że obecny program ma tę samą konfigurację feedu. Jito mógł zaktualizować konta on-chain bez rewizji strony albo nadal używać Switchboard z fallbackiem. Bez niedawnej inspekcji transakcji lub aktualnego oświadczenia Jito nazwana zależność produkcyjna pozostaje niezweryfikowana.

Publiczne notki wydawnicze Jito na GitHub dla Tip Routera odwołują się do ponawiania prób wobec bram oracle Switchboard w operacjach keepera. Baza kodu zawierająca taką logikę demonstruje integrację techniczną, niekoniecznie zależność każdego vaultu w momencie publikacji. Kod może przechowywać ścieżkę kompatybilności przez miesiące. Pytaniem produkcyjnym jest, czy niedawne transakcjeizacji cen celują w konto Switchboard używane przez vault wciąż niosący wartość, oraz czy to konto nadal się aktualizuje po ostatecznym terminie wsparcia.

Ta rozróżnienie często ginie, gdy wszystkich użytkowników wyroczni umieszcza się na jednej liście. Opisane obliczenie Jito wpływa na względne wagi aktywów w systemie dystrybucji. Obliczenie rynku pożyczkowego określa wartość zabezpieczenia i kondycję pożyczkobiorcy. Oba konsumują dane cenowe, ale ich ścieżki awarii się różnią. Audyt zliczający logotypy przypisałby tę samą wagę fundamentalnie odmiennym zastosowaniom.

Scope Kamino to agregator, nie etykieta dostawcy

Publiczne repozytorium Scope Kamino Finance opisuje agregator on-chain, który kopiuje wartości z wielu kont wyroczni do jednego feedu cenowego i waliduje aktualizacje według z góry ustalonych reguł. Jego README mówi, że feed obsługuje do 512 cen, a powiązanie między indeksem a parą tokenów nie jest w całości przechowywane on-chain. Program downstream może wskazywać na Scope, podczas gdy sam Scope polega na innych feedach dla wybranego aktywa. Widok Scope w konfiguracji banku jest zatem punktem wyjścia do śledzenia rzeczywistego źródła danych, a nie jego końcem.

Wrześniowa notka marginfi wymienia Scope jako opcję niezależną od Switchboard dla opisywanej nowej konfiguracji. Nie oznacza to, że każde wdrożenie Scope w każdym terminie wyklucza każde źródło Switchboard. Agregator może zmieniać swoje dane wejściowe. Kompletna weryfikacja zależności wymaga zarówno wybranego konta Scope konsumenta, jak i mapowania źródeł używanego do zasilania jego wpisu. Repozytorium Kamino dostarcza architektury, a nie ostemplowanego spisu bieżących źródeł mainnetowych dla każdej aplikacji.

Kamino kontynuuje przyciąganie instytucji do swojego ekosystemu pożyczkowego. Galaxy otworzyła na platformie dwa vaulty stablecoinowe we wrześniu. Istnienie nowych vaultów pokazuje, dlaczego nazywanie całego protokołu eksponowanym bez sprawdzenia jego poszczególnych aktywów byłoby chybione. Vault USDC, rezerwa tokena liquid stakingu i rynek tokenizowanych akcji mogą korzystać z różnych ścieżek oracle. Vaulty Galaxy nie zostały zwfikowane jako użytkownicy Switchboard, więc nie są wliczane do liczby dotkniętych pozycji.

Podobnie starsza lista Kamino, Jito, marginfi i Drift w materiałach wprowadzających Switchboard nie pokazuje, jak rozkładała się między nich ekspozycja. Projekt może używać wyroczni tylko dla jednego rynku, używać jej jako fallbacku lub zachować kod po przełączeniu aktywnych feedów. Jedyną bronialną jednostką analizy jest konkretny rynek lub vault i jego skonfigurowany feed w określonym czasie. Bez tej jednostki twierdzenia o środkach zagrożonych ryzykiem to marketingowa arytmetyka czytana od tyłu.

Nieaktualny feed może mieć więcej niż jeden skutek

Techniczny skutek opóźnienia feedu zależy od protokołu konsumującego. Program pożyczkowy generalnie potrzebuje ceny, by określić wartość zabezpieczenia i zdolność pożyczkową. Jeśli odrzuca starą wartość, akcja może się nie powieść lub rynek może zostać wstrzymany zgodnie ze swoimi regułami. Jeśli akceptuje nieaktualne dane, pożyczkobiorca może transakcjonować po cenie już niezgodnej z rynkiem. Źródło zapasowe może utrzymać rynek w działaniu, wprowadzając inny rytm aktualizacji lub regułę zaufania. Dokumentacja protokołu i konfiguracja on-chain decydują, która ścieżka obowiązuje.

Marginfi wprost mówi, że feedy pull Switchboard trzeba skrankować przed użyciem. Integrator musi więc dostarczyć świeżą aktualizację jako część ścieżki transakcyjnej. Feedy push Pyth, w przeciwieństwie, są opisywane jako utrzymywane na bieżąco przez infrastrukturę Pyth. Scope używa zagregowanej wartości konta wybranej przez skonfigurowany indeks wpisu. Przejście między tymi typami zmienia konta, których transakcja potrzebuje, i kod, który je sprawdza. Wrześniowe ostrzeżenie o SDK to jeden widoczny przykład tego, jak te zmiany sięgają oprogramowania aplikacji.

Dla Tip Routera Jito publiczna dokumentacja opisujeagi zapasowe dla niedostępnych feedów. Czy te zapasy zachowują dokładną alokację nagród podczas przedłużającej się awarii, to pytanie o aktywną konfigurację i operatorów Jito, a nie coś, co rozstrzyga zdanie w dokumentacji. Jeśli feed aktualizuje się dalej przez niezależnych operatorów węzłów po zaprzestaniu wsparcia przez firmę, fallback może nie zostać natychmiast uruchomiony. Jeśli aktualizacje ustaną, ale zapas jest aktywny, operacje mogą trwać inną metodą wyceny. To ścieżki warunkowe, nie prognoza obecnego stanu systemu.

Niepowiązane zdarzenie z wyroczią doprowadziło wcześniej we wrześniu do likwidacji na Vesu. Ilustruje, że błędna wycena może mieć skutki ekonomiczne, ale nie jest dowodem incydentu w Switchboard, Jito ani marginfi. Ogłoszenie zamknięcia nie powinno być analogią zamienianą w twierdzenie o likwidacjach. Dowodem rzeczywistego zdarzenia byłyby nieaktualne znaczniki czasu kont, nieudane transakcje, wstrzymanie protokołu lub zidentyfikowane straty. Nic z tego nie pokazano dla terminu 25 września.

Przejście Solany na sloty 250 milisekundowych zmieniło tempo produkcji bloków, ale nie zagwarantowało aktualizacji zewnętrznego źródła cen. Szybsze sloty mogą przenieść nową cenę szybciej, gdy ona istnieje. Nie mogą wytworzyć ceny, gdy węzeł ją dostarczający przestaje działać. Test świeżości protokołu może być mierzony slotem, czasem lub inną regułą, więc zmiana zegara sieci może zmienić, jak deweloperzy interpretują stare konfiguracje feedów.

Kto ponosi ciężar migracji?

Operator wyroczni publikuje lub koordynuje dane, ale protokół konsumujący wybiera konto, które jego program odczytuje, i limity, jakie nakłada na tę cenę. Protokół pożyczkowy może wymagać zarządu lub administratora do zmiany adresów wyroczni dla swoich rynków. Jego frontend i integratorzy zewnętrzni muszą potem konstruowaćakcje z właściwymi dodatkowymi kontami. Użytkownicy mogą zauważyć jedynie odrzuconą pożyczkę lub wstrzymany rynek, długo po tym, jak operator i protokół podjęli decyzje techniczne.

Operator kończący wsparcie nie musi mieć władzy przepisania konfiguracji programu klienta. Switchboard wezwał użytkowników do migracji, ponieważ właściciele integracji muszą działać. Projekty należy oceniać po adresach i aktualizacjach kont, którymi sterują. Jeśli aplikacja przeszła na Pyth przed 19 września, późniejszy termin wsparcia nie ma na nią bezpośredniego wpływu. Jeśli nadal wybiera feed Switchboard i nie ma działającego zapasu, zachowanie feedu po 25 września jest konkretnym problemem.

Najsilniejsza przeciwna lektura alarmu o zamknięciu wynika z wrześniowej notki marginfi i udokumentowanego zapasu Jito. Aplikacje mogą projektować redundancję lub wyprzedzać odejście dostawcy; kod i dokumenty pokazują mechanizmy, by to robić. Model na żądanie Switchboard może pozostawić część infrastruktury feedów działającą niezależnie, nawet jeśli główny udziałowiec zaprzestał wsparcia. Ogłoszenie nie opublikowało zweryfikowanego harmonogramu, w którym każde konto zostałoby zatrzymane, a nie znaleziono dowodów pierwszorzędnych ustanawiających taką uniwersalną cezurę.

Wygaszenie dostawcy może też mieć efekty opóźnione. Kod żądający cen na żądanie może działać, dopóki niezależna brama odpowiada, po czym zawieść, gdy brama zostanie wycofana lub jej operatorzy przestaną aktualizować konkretne aktywo. Obserwator potrzebuje kilku znaczników czasu po terminie, a nie jednej udanej transakcji, by wnioskować o kontynuacji usługi. Ta sama dyscyplina dotyczy nieudanej transakcji: błąd może wynikać z nieaktualnego SDK lub niewystarczających danych kontowych, a nie z niedostępnej wyroczni. Dokument migracyjny marginfi dostarcza jawnego przykładu awarii dekodowania oprogramowania którą inaczej można by błędnie uznać za awarię wyroczni.

Uczciwy wniosek jest węższy niż wersja promocyjna i alarmistyczna: dokumenty publiczne identyfikują kandydackie zależności i trasy ewakuacji, ale bieżący audyt konfiguracji rynek po rynku jest potrzebny, by ustalić pozostałą ekspozycję.

Spis aktywnej infrastruktury wciąż nie istnieje

To opracowanie porównuje listę czterech prominentnych integratorów Switchboard z bieżącymi dokumentami pierwszorzędowymi od Jito, marginfi i Kamino. Daje kilka wniosków dokumentowych. Starsza dokumentacja Tip Routera Jito wymienia Switchboard do wyceny vaultów i wskazuje fallback dla niedostępnych feedów. Wrześniowa notka marginfi 0.1.11 opisuje dziewięć nowych konfiguracji niezależnych od Switchboard i ostrzega przed odrębną awarią SDK, jeśli integratorzy nie zaktualizują oprogramowania. Repozytorium Scope Kamino wyjaśnia, dlaczego sama etykieta agregatora nie pozwala zidentyfikować każdego źródła nadrzędnego.

Dostępny materiał nie daje liczby aktywnych niemigrowanych feedów, narażonych środków użytkowników ani awarii jakiegokolwiek nazwanego protokołu. Publiczne strony nie zawierają zsynchronizowanej migawki z 25 września wszystkich kont wyroczni, ostatnich udanych aktualizacji, ustawień fallback i kwot wspieranych przez każdy rynek. Twierdzenie o konkretnej kwocie na podstawie TVL protokołu byłoby nie do obrony, ponieważ wszystkie aktywa protokołu niekoniecznie korzystają z tej samej wyroczni. Precyzyjne pytanie pozostaje otwarte na poziomie aktywnych kont.

Właściwy spis używałby rynku jako wiersza, nie protokołu. Dla każdego aktywnego banku pożyczkowego, rynku instrumentów pochodnych lub vaultu nagród audytor odnotowałby adres programu, wybrany typ wyroczni, konto wyroczni, źródło zapasowe jeśli istnieje, ostatnią udaną aktualizację ceny, maksymalny dozwolony wiek oraz wartość pozycji rzeczywiście zależnych od tej ceny. Zduplikowane rynki współdzielące jedno konto wyroczni nie powinny być liczone jako odrębne feedy. Rynek używający dwóch niezależnych wyroczni nie powinien być liczony jako całkowicie zależny od którejkolwiek bez przeczytania jegoiki fallback. Znacznik czasu konfiguracji rynku ma znaczenie, ponieważ administrator mógł zmienić feed po obserwacji.

Istnieje dodatkowy krok weryfikacji, gdy źródłem jest agregator. Konsument może identyfikować konto Scope i indeks wpisu, podczas gdy mapowanie Scope wskazuje na jednego lub kilku dostawców. Aktualizacja konta Scope po 25 września dowodzi, że agregator wyprodukował wartość, ale samo w sobie nie dowodzi, że Switchboard nadal dostarczał cenę bazową. Badacz potrzebuje wybranego wpisu i konfiguracji źródeł dla tej aktualizacji. Tam, gdzie mapowanie jest niedostępne, wynik należy zapisać jako nieznany, a nie po cichu przypisywać go Pyth lub Switchboard.

Na co zwracać uwagę

• Adresy wyroczni rynków: porównaj skonfigurowany feed każdego aktywnego banku lub vaultu z udokumentowanymi kontami Switchboard.
• Znaczniki czasu aktualizacji cen: sprawdź, czy zidentyfikowany feed publikuje świeże wartości także po 25 września.
• Konfiguracja fallback: ustal źródło i limit świeżości używane, gdy feed podstawowy się opóźnia.
• Niedawne transakcje programu: sprawdź, czy pożyczanie, rozliczenia czy dystrybucja tipów wciąż kończą się dla dotkniętego rynku.
• Ostemplowane aktualizacje utrzymujących: szukaj nazwanej migracji, wstrzymania rynku lub pozostałej zależności potwierdzonej adresem konta lub programu.

Czas obserwacji każdego sprawdzenia powinien być zapisany; zrzut ekranu bez bloku lub znacznika czasu szybko staje się nieaktualny.

Notka aktualizacyjna marginfi stanowi, że bank używający nowej wartości enum wyroczni może spowodować, że starszy SDK nie zainicjalizuje klienta, nawet jeśli użytkownik nie wchodzi w interakcję z tym konkretnym bankiem. Instrukcja użycia SDK w wersji 2.8.0 lub nowszej została opublikowana przed startem migracji 4 września, trzy tygodnie przed ostatecznym terminem wsparcia Switchboard.

FAQ

Kiedy Switchboard powiedział, że wsparcie się skończy?

Ogłoszenie zamknięcia pojawiło się 19 września 2026 roku i wskazało 25 września jako koniec istniejącego wsparcia technicznego. Komunikat zdeprecjonował implementacje natychmiast.

Czy wszystkie feedy oracle Switchboard zatrzymały się 25 września?

Sam termin wsparcia nie dowodzi, że każde konto on-chain przestało się aktualizować. Potrzebne są bieżące znaczniki czasu transakcji i feedów, by to twierdzić.

Czy Jito nadal używa Switchboard?

Dokumentacja Tip Routera Jito nadal wymienia Switchboard przy wycenie vaultów, ale jej przegląd był oznaczony jako ostatni raz zaktualizowany dziewięć miesięcy wcześniej. Te strony nie dowodzą aktywnej konfiguracji z 25 września.

Czy marginfi zmigrował ze Switchboard?

Wrześniowa aktualizacja marginfi dokumentuje dziewięć nowych konfiguracji oracle niezależnych od Switchboard i mówi, że banki zaczęły się przenosić od 4 września. Nie stwierdza, że każdy bank ukończył migrację.

Dlaczego migracja wyroczni może zepsuć SDK?

Marginfi mówi, że starsze SDK nie rozpoznają wartości enum używanych przez jego dziewięć nowych konfiguracji. Bank skonfigurowany z jedną z nich może spowodować niepowodzenie inicjalizacji starego klienta; wersja 2.8.0 lub nowsza obsługuje te warianty.

Czy Kamino Scope jest niezależne od każdej zewnętrznej wyroczni?

Scope agreguje wartości z innych kont wyroczni. Jego obecność w konfiguracji konsumenta nie identyfikuje każdego źródła nadrzędnego bez zbadania konkretnego mapowania wpisów.

Jak użytkownicy mogą sprawdzić, czy rynek jest dotknięty?

Skonfigurowane konto wyroczni rynku, ostatnia aktualizacja i ustawienia fallback dają mocniejszą odpowiedź niż historyczna lista dostawców. Ogłoszenia protokołów mogą potwierdzić, czy konkretny rynek dokonał migracji.

Czy straty z tego zamknięcia zostały zweryfikowane?

Nie zweryfikowano strat w żadnym nazwanym protokole dla tego artykułu. Wcześniejszy incydent w innym protokole nie dowodzi, że coś takiego wydarzyło się tutaj. To analiza edukacyjna, nie porada inwestycyjna.

Zastrzeżenie: Ten artykuł ma charakter wyłącznie informacyjny i edukacyjny i nie stanowi porady finansowej ani inwestycyjnej. Dane odzwierciedlają rejestry regulacyjne i relacje dostępne w momencie pisania i zmieniają się z każdym ujawnieniem. Nic tutaj nie jest rekomendacją kupna, sprzedaży ani utrzymywania jakichkolwiek papierów wartościowych lub aktywów. Zawsze wykonaj własne badania. Informacje są aktualne na 25 września 2026 roku.