Switchboard-Support-Ende zwingt Solana-Protokolle zur Überprüfung aktiver Oracle-Abhängigkeiten

Die Support-Frist von Switchboard am 25. September hat eine sechstägige Migrationswarnung zu einem Test der Preis-Feeds von Solana gemacht. Die öffentliche Dokumentation zeigt, wo das Oracle weiterhin Teil des Designs einer Anwendung ist, doch diese Seiten können nicht beweisen, dass ein aktiver Markt den Feed noch verwendet. Jito und marginfi bieten zwei unterschiedliche Perspektiven auf die potenzielle Exposition.

Switchboard hat sein angegebenes Ende des technischen Supports am 25. September erreicht, womit Solana-Anwendungen die in ihren aktiven Programmen konfigurierten Preisquellen selbst überprüfen müssen.

Die Erklärung des Oracle-Projekts vom 19. September, wie sie in der Berichterstattung über die Ankündigung wiedergegeben wurde, besagte, dass sein Kernentwicklungsbeitrag Switchboard Technology Labs den Betrieb einstellen und alle Implementierungen sofort als veraltet markiert würden. Das Team forderte Integratoren auf, zu anderen Anbietern zu migrieren, und nannte Pyth und RedStone. Der 25. September wurde als letzter Tag des bestehenden Supports beschrieben.

Das Ende des technischen Supports ist ein realer operativer Meilenstein. Es beweist nicht für sich allein, dass jeder On-Chain-Feed um Mitternacht aufhörte, sich zu aktualisieren, oder dass jede Anwendung, die einmal mit Switchboard in Verbindung gebracht wurde, weiterhin von ihr abhing.

Switchboards eigene Dokumentation hat Kamino, Jito, marginfi und Drift als Nutzer genannt. Dies sind historische Integrationsangaben eines Anbieters, der einen Oracle-Dienst verkaufte, kein Echtzeitbestand aktiver Feeds am 25. September. Die aktuelle Dokumentation jedes Projekts zeigt ein komplizierteres Bild. Jitos Tip Router-Seiten beschreiben Switchboard weiterhin in ihrem Preisbildungsfluss, während marginfis technisches Upgrade im September Pfade hinzufügte, die diese Abhängigkeit vermeiden sollen. Ein Dokument kann veraltet sein, während ein anderes eine Migration antizipiert. Keines ersetzt eine Inspektion der aktiven Kontokonfiguration.

Die frühere Finanzierungsrunde von Switchboard betrug 7,5 Millionen USD im Mai 2024. Dieser Betrag liefert Hintergrundinformationen zur Geschichte des Unternehmens, misst jedoch nicht die aktuelle Protokoll-Exposition. Die relevante Zahl ist die Anzahl und der Wert aktiver Märkte, deren Risikoberechnungen weiterhin Daten aus einem Feed verwenden, der nicht zuverlässig aktualisiert werden kann. Diese Zahl lässt sich nicht aus einem Kundenlogo ableiten.

Eine gelistete Integration ist kein aktiver Feed

Switchboards öffentliche Einführung beschreibt On-Demand-Feeds: Anwendungen erstellen oder rufen die benötigten Daten ab, und ein Preis wird über Solana-Konten verfügbar gemacht. Dokumentation kann identifizieren, wo ein Protokoll weiß, wie es einen Switchboard-Feed liest, aber sie identifiziert möglicherweise nicht, welche Option ein bestimmter Markt aktuell wählt. Ein Software Development Kit kann einen Oracle-Typ lange unterstützen, nachdem die letzte Bank davon abgewichen ist. Umgekehrt kann sich eine Website ändern, während eine aktive Reserve ihr älteres Oracle-Konto beibehält.

Drei Beweisebenen sollten getrennt betrachtet werden. Die erste ist eine Marketing- oder Integrationsseite, die zeigt, dass eine Beziehung bestand. Die zweite ist die unterstützte Konfiguration eines Programms, sichtbar in technischer Dokumentation oder Code. Die dritte ist die aktive Konfiguration und aktuelle Update-Historie des tatsächlichen Marktes. Nur die dritte kann eine Behauptung stützen, dass ein benannter Markt zu einem bestimmten Zeitpunkt weiterhin von Switchboard abhing. Selbst dann kann eine Backup-Quelle konfiguriert sein, sodass die Auswirkungen eines gestoppten primären Feeds gegen die relevante Fallback- und Aktualitätsregel geprüft werden müssen.

Marginfis Protokolldokumentation behält SwitchboardPull und Venue-Varianten unter den verfügbaren Oracle-Setups bei. Dort heißt es, dass ein Aufrufer einen Switchboard-Pull-Feed unmittelbar vor der Nutzung cranken muss. Dieselbe Tabelle listet Pyth-Push-Feeds und Scope-Konten als weitere Setups auf. Das fortbestehende Vorhandensein der Switchboard-Zeile ist kein Beweis dafür, dass jede marginfi-Bank sie weiterhin nutzt; die Tabelle beschreibt unterstützte Typen, keine vollständige Liste, welche Bank heute welchen Feed verwendet.

Marginfis separate Program-0.1.11-Notiz ist aktueller und spezifischer. Sie wies Entwickler an, das SDK vor dem 4. September auf mindestens Version 2.8.0 zu aktualisieren, mit dem Hinweis, dass Banken ab diesem Datum zu neuen Oracle-Setups übergehen würden. Das Release fügte neun Varianten hinzu, die nicht von Switchboard abhängen, darunter Kamino-Scope-Feeds und wechselkursbasierte Preisbildung für bestimmte Liquid-Staking- und Principal-Token.

Die Notiz sagt nicht, dass jede Bank bis zum 25. September migriert hatte. Sie zeigt jedoch, dass marginfi vor der Shutdown-Ankündigung öffentlich einen Weg weg von der bedrohten Abhängigkeit dokumentierte.

Die Migration führte einen zweiten möglichen Fehlermodus ein. Marginfi sagt, dass ältere SDKs eine Bank, die mit einem der neuen Oracle-Enum-Werte konfiguriert ist, nicht dekodieren können. Eine einzelne Bank mit einem nicht unterstützten Wert kann Project0Client.initialize und Bank-Lesevorgänge verhindern, statt nur eine Aktion zu betreffen, die diese Bank einbezieht. Die Änderung eines Oracles kann somit eine Infrastrukturabhängigkeit lösen, während sie einen Integrator beschädigt, der seine Software nicht aktualisiert hat. Marginfis Dokument erklärt, wie Integratoren das SDK-Problem vermeiden können; es ist kein Beweis dafür, dass ein bestimmter Nutzer es erlebt hat.

Project 0 hat Unified Margin über Solana-Venues hinweg beschrieben, einschließlich Kamino und Drift. Cross-Protokoll-Schnittstellen schaffen eine weitere Ebene, auf der eine Oracle-Migration bewertet werden muss. Die Warnung zu älteren SDK-Versionen ist ein konkreter Beleg für ein Integrationsrisiko, beweist aber keinen Ausfall in Project 0 oder einer anderen benannten Anwendung. Eine verantwortungsvolle Prüfung würde Softwareversionen und aktive Lending-Bank-Konfigurationen überprüfen, bevor ein Ausfall behauptet wird.

Jitos Tip Router dokumentiert weiterhin Switchboard

Jito Foundations Tip Router-Übersicht besagt, dass Switchboard das relative Gewicht von Assets wie JitoSOL und JTO bestimmt, die in mit dem Tip Router verbundenen Vaults gehalten werden. Die Übersicht identifiziert ein On-Chain-Tip-Router-Programm, einen Node-Operator-Client und einen permissionlosen Cranker. Die Preisbildungsdokation nennt Switchboard als den aktuellen Oracle-Feed und beschreibt Backup-Gewichte, wenn Feeds nicht verfügbar sind.

Die Dokumente ordnen Switchboard eine spezifische Rolle zu: die Preisbildung von Vault-Assets für Gewichtsberechnungen in einem Tip-Verteilungs- und Restaking-System. Sie sagen nicht, dass ein nicht verfügbarer Switchboard-Feed automatisch eine Solana-Lending-Position liquidiert. Jitos Preisbildungsseite beschreibt einen Fallback-Mechanismus, was die simplistische Behauptung schwächt, dass ein Support-Ende zwangsläufig alle Tip-Router-Operationen stoppen würde. Die genauen Fallback-Werte, Aktivierungsbedingungen und aktuellen Live-Oracle-Konten erfordern weiterhin eine aktuelle Programmzustandsprüfung.

Die Tip Router-Übersicht zeigte bei Prüfung am 25. September eine last-updated-Markierung von vor neun Monaten. Dieses Alter begrenzt die Verwendbarkeit der Seite. Sie etabliert ein dokumentiertes Design und identifiziert, wohin eine technische Frage gerichtet werden kann, kann jedoch nicht belegen, dass das aktuelle Programm dieselbe Feed-Konfiguration aufweist. Jito könnte On-Chain-Konten aktualisiert haben, ohne die Seite zu überarbeiten, oder es nutzt Switchboard weiterhin mit einem Fallback. Ohne eine aktuelle Transaktionsinspektion oder eine aktuelle Erklärung von Jito bleibt eine benannte aktive Abhängigkeit unbewiesen.

Jitos öffentliche GitHub-Release-Notes für Tip Router beziehen sich auf das Wiederholen von Switchboard-Oracle-Gateways in Keeper-Operationen. Eine Codebasis mit einer solchen Logik demonstriert technische Integration, nicht notwendigerweise eine Abhängigkeit jedes Vaults zum Zeitpunkt der Veröffentlichung. Code kann über Monate hinweg einen Kompatibilitätspfad aufrechterhalten. Die lebendige Frage ist, ob aktuelle Preis-Update-Transaktionen ein Switchboard-Konto adressieren, das von einem Vault genutzt wird, der noch Wert trägt, und ob dieses Konto nach der Support-Frist fortschreitet.

Der Unterschied geht oft verloren, wenn alle Oracle-Nutzer in einer einzigen Liste erfasst werden. Jitos beschriebene Berechnung betrifft relative Asset-Gewichte in einem Verteilungssystem. Die Berechnung eines Lending-Marktes bestimmt den Sicherheitenwert und die Kreditnehmergesundheit. Beide verbrauchen Preisdaten, aber ihre Fehlerpfade unterscheiden sich. Eine Prüfung, die Logos zählt, würde grundlegend unterschiedlichen Verwendungen dieselbe Schwere zuweisen.

Kaminos Scope ist ein Aggregator, keine Anbieterbezeichnung

Kamino Finance öffentliches Scope-Repository beschreibt einen On-Chain-Aggregator, der Werte aus mehreren Oracle-Konten in einen Preis-Feed kopiert und Updates unter vordefinierten Regeln validiert. Sein README besagt, dass ein Feed bis zu 512 Preise unterstützt und dass die Zuordnung zwischen einem Index und einem Token-Paar nicht vollständig On-Chain gespeichert ist. Ein Downstream-Programm kann auf Scope verweisen, während Scope selbst für das ausgewählte Asset auf andere Feeds angewiesen ist. Das Vorhandensein von Scope in einer Bank-Konfiguration ist somit ein Ausgangspunkt für die Rückverfolgung derächlichen Datenquelle, nicht das Ende.

Die September-Notiz von marginfi listet Scope als Option auf, die für das von ihr beschriebene neue Setup nicht von Switchboard abhängt. Das bedeutet nicht, dass jede Bereitstellung von Scope an jedem Datum jede Switchboard-Quelle ausschließt. Ein Aggregator kann seine zugrunde liegenden Eingaben ändern. Eine vollständige Abhängigkeitsprüfung benötigt sowohl das vom Verbraucher ausgewählte Scope-Konto als auch das Quell-Mapping, das zur Befüllung seines Eintrags verwendet wird. Kaminos Repository liefert die Architektur, kein mit Zeitstempel versehenes Inventar der aktuellen Mainnet-Quellen für jede Anwendung.

Kamino hat weiterhin Institutionen in sein Lending-Ökosystem gebracht. Galaxy eröffnete im September zwei Stablecoin-Vaults auf der Plattform. Das Vorhandensein neuer Vaults zeigt, warum es unsound wäre, ein gesamtes Protokoll als exponiert zu bezeichnen, ohne seine einzelnen Assets zu prüfen. Ein USDC-Vault, eine Liquid-Staking-Token-Reserve und ein tokenisierter Aktienmarkt können unterschiedliche Oracle-Pfade verwenden. Galaxys Vaults wurden nicht als Switchboard-nutzend verifiziert, daher sind sie nicht in einer Zählung betroffener Positionen enthalten.

Ebenso zeigt die ältere Liste von Kamino, Jito, marginfi und Drift in Switchboards Einführungsmaterial nicht, wie die Exposition unter ihnen verteilt war. Ein Projekt kann ein Oracle nur für einen Markt verwenden, es als Fallback nutzen oder Code nach dem Wechsel aktiver Feeds beibehalten. Die einzige verteidigungsfähige Analyseeinheit ist ein spezifischer Markt oder Vault und sein konfigurierter Feed zu einem bestimmten Zeitpunkt. Ohne diese Einheit sind Aussagen über gefährdete Mittel Marketing-Arithmetik rückwärts.

Ein veralteter Feed kann mehr als eine Auswirkung haben

Die technische Folge eines zurückbleibenden Feeds hängt vom verbrauchenden Protokoll ab. Ein Lending-Programm benötigt im Allgemeinen einen Preis, um den Sicherheitenwert und die Kreditfähigkeit zu bestimmen. Wenn es einen alten Wert ablehnt, kann eine Aktion fehlschlagen oder ein Markt kann gemäß seinen Regeln pausieren. Wenn es veraltete Daten akzeptiert, könnte ein Kreditnehmer gegen einen Preis transagieren, der nicht mehr dem Markt entspricht. Eine Fallback-Quelle kann den Markt am Laufen halten, während sie einen anderen Aktualisierungsrhythmus oder eine andere Vertrauensregel einführt. Die Dokumentation des Protokolls und die On-Chain-Konfiguration bestimmen, welcher Pfad gilt.

Marginfi sagt ausdrücklich, dass Switchboard-Pull-Feeds vor der Nutzung gecrankt werden müssen. Ein Integrator muss daher eine frische Aktualisierung als Teil seines Transaktionspfads liefern. Pyth-Push-Feeds werden dagegen als durch Pyths Infrastruktur frisch gehalten beschrieben. Scope nutzt einen aggregierten Kontowert, der durch einen konfigurierten Eintragsindex ausgewählt wird. Der Wechsel zwischen diesen Typen verändert die Konten, die eine Transaktion benötigt, und den Code, der sie prüft. Die September-SDK-Warnung ist ein sichtbares Beispiel dafür, wie diese Änderungen Anwendungssoftware erreichen.

Für Jito Tip Router beschreibt die öffentliche Dokumentation Backup-Gewichte für nicht verfügbare Feeds. Ob diese Backups eine genaue Belohnungsverteilung durch einen anhaltenden Ausfall gewährleisten, ist eine der aktiven Konfiguration und Jitos Betreibern, die ein Dokumentationssatz nicht beantwortet. Wenn ein Feed nach dem Support-Ende des Unternehmens durch unabhängige Node-Operatoren weiterläuft, muss möglicherweise kein Fallback sofort ausgelöst werden. Wenn Aktualisierungen aufhören, aber das Backup aktiv ist, können die Operationen mit einer anderen Preisbildungsmethode fortgesetzt werden. Dies sind bedingte Pfade, keine Vorhersage des aktuellen Systemzustands.

Ein unabhängiger Oracle-Vorfall führte Anfang September zu Liquidationen auf Vesu. Er illustriert, dass inkorrekte Preisbildung wirtschaftliche Auswirkungen haben kann, ist aber kein Beweis für einen Vorfall bei Switchboard, Jito oder marginfi. Eine Shutdown-Hinweis sollte nicht durch Analogie in eine Liquidationsbehauptung umgedeutet werden. Beweise für ein tatsächliches Ereignis wären veraltete Konto-Zeitstempel, fehlgeschlagene Transaktionen, eine Protokollpause oder identifizierte Verluste. Keines wurde hier für die Frist vom 25. September gezeigt.

Solanas Umstellung auf 250-Millisekunden-Slots veränderte das Tempo der Blockproduktion, garantierte aber nicht, dass eine externe Preisquelle aktualisiert. Schnellere Slots können einen neuen Preis früher übermitteln, wenn einer existiert; sie können keinen Preis erzeugen, wenn der liefernde Node stoppt. Der Freshness-Test eines Protokolls kann nach Slot, Zeit oder einer anderen Regel gemessen werden, sodass eine Änderung der Netzwerkuhr verändern kann, wie Entwickler alte Feed-Konfigurationen interpretieren.

Wer trägt die Migrationsarbeit?

Der Oracle-Betreiber veröffentlicht oder koordiniert Daten, aber das verbrauchende Protokoll wählt das Konto, das sein Programm liest, und die Grenzen, die es diesem Preis setzt. Ein Lending-Protokoll kann verlangen, dass Governance oder ein Administrator die Oracle-Adressen für seine Märkte ändert. Sein Frontend und Drittanbieter-Integratoren müssen dann Transaktionen mit den richtigen zusätzlichen Konten konstruieren. Nutzer bemerken möglicherweise nur eine abgelehnte Ausleihe oder einen pausierten Markt, lange nachdem der Betreiber und das Protokoll ihre technischen Entscheidungen getroffen haben.

Ein Betreiber, der den Support beendet, hat nicht unbedingt die Macht, die Programmkonfiguration eines Kunden umzuschreiben. Switchboard forderte die Nutzer zur Migration auf, weil die Integrationseigner handeln müssen. Projekte sollten anhand der Adressen und Kontoupdates beurteilt werden, die sie kontrollieren. Wenn eine Anwendung vor dem 19. September zu Pyth wechselte, hat die spätere Support-Frist keine direkte Auswirkung auf diesen Markt. Wenn sie weiterhin einen Switchboard-Feed wählt und kein funktionierendes Backup hat, ist das Verhalten des Feeds nach dem 25. September das konkrete Problem.

Die stärkste Gegenlesung des Shutdown-alarms folgt aus marginfis September-Notiz und Jitos dokumentiertem Backup. Anwendungen können Redundanz entwerfen oder einem Vendor-Ausstieg vorausgehen; der Code und die Dok zeigen Mechanismen dafür. Switchboards On-Demand-Modell kann einen Teil der Feed-Infrastruktur unabhängig weiterlaufen lassen, selbst wenn der Kernbeitrag den Support eingestellt hat. Die Hinweis veröffentlichte keinen verifizierten Zeitplan, zu dem jedes Konto anhalten würde, und keine Primärevidenz belegt einen solchen universellen Cutoff.

Ein Herunterfahren eines Anbieters kann auch verzögerte Auswirkungen haben. Code, der On-Demand-Preise anfordert, kann erfolgreich sein, solange ein unabhängiges Gateway antwortet, und dann fehlschlagen, wenn dieses Gateway stillgelegt wird oder seine Betreiber aufhören, ein bestimmtes Asset zu aktualisieren. Ein Beobachter benötigt mehrere Zeitstempel nach der Frist, nicht eine einzelne erfolgreiche Transaktion, um einen fortgesetzten Dienst abzuleiten. Dasselbe gilt für eine fehlgeschlagene Transaktion: Ein Fehler kann von einem veralteten SDK oder unzureichender Kontoeingabe herrühren statt von einem nicht verfügbaren Oracle. Marginfis Migrationsdokument liefert ein explizites Beispiel eines Software-Dekodierungsfehlers, der sonst fälschlicherweise als Oracle-Ausfall etikettiert werden könnte.

Die faire Schlussfolgerung ist enger als die promotionalen und alarmistischen Versionen: Öffentliche Dokumente identifizieren Kandidatenabhängigkeiten und Fluchtwege, aber eine aktuelle markenweise Konfigurationsprüfung ist erforderlich, um verbleibende Exposition festzustellen.

Das Live-Inventar fehlt weiterhin

Die Berichterstattung vergleicht Switchboards Liste von vier prominenten Integratoren mit aktuellen Primärdokumenten von Jito, marginfi und Kamino. Sie erzeugt mehrere dokumentarische Erkenntnisse. Jitos ältere Tip-Router-Dokumentation nennt Switchboard für die Vault-Preisbildung und identifiziert einen Fallback für nicht verfügbare Feeds. Marginfis September-0.1.11-Notiz beschreibt neun neue Setups unabhängig von Switchboard und warnt vor einem separaten SDK-Bruch, wenn Integratoren nicht upgraden. Kaminos Scope-Repository erklärt, warum eine Aggregator-Bezeichnung allein nicht jede Upstream-Datenquelle identifizieren kann.

Das verfügbare Material erzeugt keine Zählung aktiver unmigrierter Feeds, exponierter Nutzermittel oder eines Ausfalls bei einem benannten Protokoll. Öffentliche Seiten enthalten keinen synchronisierten 25.-September-Schnappschuss aller Oracle-Konten, letzten erfolgreichen Updates, Fallback-Einstellungen und der von jedem Markt unterstützten Beträge. Die Behauptung eines spezifischen Dollarbetrags aus der Protokoll-TVL wäre unvertretbar, da nicht alle Assets eines Protokolls notwendigerweise dasselbe Oracle teilen. Die präzise Frage bleibt auf der Ebene der aktiven Konten offen.

Eine ordnungsgemäße Zählung würde den Markt als Zeile verwenden, nicht das Protokoll. Für jede aktive Lending-Bank, jeden Derivatmarkt oder Belohnungsvault würde ein Prüfer seine Programmadresse, den gewählten Oracle-Typ, das Oracle-Konto, die Backup-Quelle falls vorhanden, die letzte erfolgreicheaktualisierung, das maximal zulässige Alter und den Wert der Positionen, die tatsächlich von diesem Preis abhängen, aufzeichnen. Doppelte Märkte, die ein Oracle-Konto teilen, sollten nicht als separate Feeds gezählt werden. Ein Markt, der zwei unabhängige Oracles verwendet, sollte nicht als vollständig von einem von beiden abhängig gezählt werden, ohne seine Fallback-Logik zu lesen. Der Zeitstempel der Marktkonfiguration ist wichtig, da ein Administrator nach der Beobachtung einen Feed ändern könnte.

Es gibt einen zusätzlichen Verifikationsschritt, wenn die Quelle ein Aggregator ist. Der Verbraucher kann ein Scope-Konto und einen Eintragsindex identifizieren, während das Scope-Mapping auf einen oder mehrere Anbieter verweist. Ein Update im Scope-Konto nach dem 25. September beweist, dass ein Aggregator einen Wert erzeugt hat, aber es beweist nicht für sich allein, dass Switchboard den zugrunde liegenden Preis weiterhin geliefert hat. Der Untersuchende benötigt den ausgewählten Eintrag und die Quellkonfiguration für dieses Update. Wo dieses Mapping nicht verfügbar ist, sollte das Ergebnis als unbekannt aufgezeichnet werden, nicht stillschweigend Pyth oder Switchboard zugeschrieben werden.

Worauf zu achten ist

• Markt-Oracle-Adressen: Vergleichen Sie den konfigurierten Feed jeder aktiven Bank oder jedes Vaults mit den dokumentierten Switchboard-Konten.
• Preis-Update-Zeitstempel: Prüfen Sie, ob ein identifizierter Feed nach dem 25. September weiterhin frische Werte veröffentlicht.
• Fallback-Konfiguration: Identifizieren Sie die Quelle und das Aktualitätslimit, die verwendet werden, wenn ein primärer Feed zurückbleibt.
• Aktuelle Programmtransaktionen: Prüfen Sie, ob Ausleihen, Abwicklung oder Tip-Verteilung für den betroffenen Markt weiterhin abgeschlossen werden.
• Betreiber-Updates mit Datum: Suchen Sie nach einer benannten Migration, einer Marktpause oder einer verbleibenden Abhängigkeit, gestützt auf eine Konto- oder Programmadresse.

Die Beobachtungszeit für jede Prüfung sollte aufgezeichnet werden; ein Screenshot ohne Block oder Zeitstempel kann schnell veralten.

Marginfis Upgrade-Notiz besagt, dass eine Bank mit einem neuen Oracle-Enum-Wert dazu führen kann, dass ein älteres SDK seinen Client nicht initialisieren kann, selbst wenn ein Nutzer nicht mit dieser bestimmten Bank interagiert. Die Anweisung, SDK-Version 2.8.0 oder höher zu verwenden, wurde vor dem Migrationsstart am 4. September veröffentlicht, drei Wochen vor Switchboards Support-Frist.

FAQ

Wann sagte Switchboard, dass der Support enden würde?

Die Shutdown-Ankündigung wurde am 19. September 2026 gemacht und den 25. September als Ende des bestehenden technischen Supports identifiziert. Die Hinweis erklärte die Implementierungen sofort für veraltet.

Sind alle Switchboard-Oracle-Feeds am 25. September gestoppt?

Die Support-Frist allein belegt nicht, dass jedes On-Chain-Konto aufhörte, sich zu aktualisieren. Aktuelle Transaktions- und Feed-Zeitstempel sind erforderlich, um diese Behauptung zu machen.

Nutzt Jito weiterhin Switchboard?

Jitos Tip-Router-Dokumentation nennt Switchboard weiterhin für die Vault-Preisbildung, aber ihre Übersicht war zuletzt vor etwa neun Monaten aktualisiert worden. Die Seiten beweisen nicht die aktive Konuration vom 25. September.

Hat marginfi von Switchboard migriert?

Marginfis September-Upgrade dokumentiert neun neue Oracle-Setups, die nicht von Switchboard abhängen, und sagt, dass Banken ab dem 4. September begannen zu wechseln. Es besagt nicht, dass jede Bank die Migration abgeschlossen hat.

Warum kann eine Oracle-Migration ein SDK brechen?

Marginfi sagt, dass ältere SDKs die Enum-Werte seiner neun neuen Setups nicht erkennen. Eine mit einem davon konfigurierte Bank kann dazu führen, dass die Initialisierung eines alten Clients fehlschlägt; Version 2.8.0 oder höher unterstützt die Varianten.

Ist Kamino Scope unabhängig von jedem externen Oracle?

Scope aggregiert Werte aus anderen Oracle-Konten. Sein Vorhandensein in der Konfiguration eines Verbrauchers identifiziert nicht jede Upstream-Quelle, ohne das spezifische Eintrags-Mapping zu untersuchen.

Wie können Nutzer prüfen, ob ein Markt betroffen ist?

Das konfigurierte Oracle-Konto des Marktes, die letzte Aktualisierung und die Fallback-Einstellungen liefern eine stärkere Antwort als eine historische Anbieterliste. Protokollankündigungen können bestätigen, ob ein bestimmter Markt migriert hat.

Wurden Verluste aus diesem Shutdown verifiziert?

Keine Verluste bei einem benannten Protokoll wurden für diesen Artikel verifiziert. Ein früherer Vorfall bei einem anderen Protokoll kann nicht beweisen, dass hier einer auftrat. Dies ist eine Bildung Analyse, keine Anlageberatung.

Haftungsausschluss: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken und stellt keine Finanz- oder Anlageberatung dar. Zahlen spiegeln die zum Zeitpunkt der Erstellung verfügbaren regulatorischen Einreichungen und Berichte wider und ändern sich mit jeder Offenlegung. Nichts hier ist eine Empfehlung zum Kauf, Verkauf oder Halten eines Wertpapiers oder Assets. Betreiben Sie immer Ihre eigene Recherche. Informationen sind Stand 25. September 2026 korrekt.