Ein Solana-Orakel stellt heute den Support ein. Wer verlässt sich noch auf seine Preise?

Switchboards Support-Frist am 25. September hat eine sechstägige Migrationswarnung in einen Test für Solanas Preisfeeds verwandelt. Die aktuelle öffentliche Dokumentation zeigt, wo seine Daten weiterhin Teil des Designs einer Anwendung sind, aber diese Seiten können nicht beweisen, dass ein Live-Markt den Feed noch nutzt. Jito und marginfi bieten zwei deutlich unterschiedliche Ansichten des Engagements.

Switchboard hat sein angekündigtes Ende des technischen Supports am 25. September erreicht, sodass Solana-Anwendungen die in ihren Live-Programmen konfigurierten Preisquellen überprüfen müssen.

Die Erklärung des Oracle-Projekts vom 19. September, wie in der Berichterstattung über die Ankündigung wiedergegeben, besagte, dass sein Kernentwicklungsbeitragender Switchboard Technology Labs eingestellt würde und alle Implementierungen sofort veraltet seien. Das Team drängte Integratoren zur Migration zu anderen Anbietern und nannte Pyth und RedStone. Der 25. September wurde als letzter Tag für bestehenden Support bezeichnet. Ein Unternehmen, das den Support einstellt, ist ein echter operativer Meilenstein. Es beweist jedoch nicht für sich genommen, dass jeder Onchain-Feed um Mitternacht aufgehört hat zu aktualisieren oder dass jede Anwendung, die einst mit Switchboard verbunden war, weiterhin davon abhängig blieb.

Switchboards eigene Dokumentation hat Kamino, Jito, marginfi und Drift als Nutzer genannt. Dies sind historische Integrationsbehauptungen eines Anbieters, der einen Oracle-Dienst verkaufte, keine Echtzeit-Inventur aktiver Feeds am 25. September. Die Überprüfung der aktuellen Dokumentation jedes Projekts zeigt ein komplizierteres Bild. Jitos Tip Router-Seiten beschreiben Switchboard weiterhin in ihrem Preisfluss; marginfis technisches Upgrade im September fügt Wege hinzu, die darauf ausgelegt sind, diese Abhängigkeit zu vermeiden. Ein Dokument kann veraltet sein, während ein anderes eine Migration vorwegnimmt. Keines ersetzt eine Inspektion der Live-Kontokonfiguration.

Die frühere Switchboard-Finanzierungsrunde betrug 7,5 Millionen Dollar im Mai 2024. Der Betrag ist nützlicher Hintergrund zur Geschichte des Unternehmens, gibt aber kein Maß für die heutige Protokoll-Exposition. Die relevante Zahl ist die Anzahl und der Wert der Live-Märkte, deren Risikoberechnungen noch Daten von einem Feed beziehen, der nicht zuverlässig aktualisiert werden kann, und diese Zahl kann nicht aus einem Kundenlogo abgeleitet werden.

Eine aufgeführte 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. Die Dokumentation kann identifizieren, wo ein Protokoll weiß, wie man einen Switchboard-Feed liest. Sie identifiziert möglicherweise nicht, welche Option ein bestimmter Markt derzeit wählt. Ein Software Development Kit kann einen Oracle-Typ noch lange unterstützen, nachdem die letzte Bank davon abgeschaltet hat. Umgekehrt kann sich eine Website ändern, während eine Live-Reserve ihr älteres Oracle-Konto behält.

Drei Evidenzebenen müssen getrennt gehalten werden. Erstens eine Marketing- oder Integrationsseite, die zeigt, dass eine Beziehung bestand. Zweitens eine unterstützte Konfiguration eines Programms, sichtbar in technischer Dokumentation oder Code. Drittens die Live-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 noch auf Switchboard angewiesen war. Selbst dann kann eine Backup-Quelle konfiguriert sein, sodass die Auswirkung eines gestoppten primären Feeds gegen die relevante Fallback- und Aktualitätsregel geprüft werden muss.

Betrachten Sie marginfis Protokolldokumentation. Ihre Oracle-Tabelle behält SwitchboardPull und Venue-Varianten unter den verfügbaren Setups. Sie besagt, dass ein Aufrufer einen Switchboard-Pull-Feed kurz vor der Verwendung crankieren muss. Dieselbe Tabelle listet Pyth-Push-Feeds und Scope-Konten als andere Setups auf. Ein Leser könnte die fortbestehende Switchboard-Zeile fälschlicherweise als Beweis dafür ansehen, dass jede marginfi-Bank sie noch verwendet. 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 bis zum 4. September auf mindestens Version 2.8.0 zu aktualisieren, und erklärte, dass Banken ab diesem Datum mit der Umstellung auf neue Oracle-Setups beginnen würden. Das Release fügte neun Varianten hinzu, die nicht von Switchboard abhängen, darunter Kamino-Scope-Feeds und wechselkursbasierte Preisgestaltung für bestimmte Liquid-Staking- und Principal-Token. Die Notiz besagt nicht, dass jede Bank bis zum 25. September migriert war. Sie zeigt jedoch, dass ein Projekt öffentlich einen Weg weg von der bedrohten Abhängigkeit dokumentierte, bevor die Abschaltungsankündigung erfolgte.

Die Migration birgt einen überraschenden zweiten Fehlermodus. Marginfi sagt, dass ältere SDKs eine Bank nicht dekodieren können, die mit einem der neuen Oracle-Enum-Werte konfiguriert ist. Eine einzelne Bank mit einem nicht unterstützten Wert kann Project0Client.initialize und Bank-Lesevorgänge verhindern, nicht nur eine Aktion, die diese Bank betrifft. Mit anderen Worten: Das Ändern eines Oracles kann eine Infrastrukturabhängigkeit beheben und gleichzeitig einen Integrator brechen, der seine Software nicht aktualisiert hat. Marginfis Dokument erklärt Integratoren, wie sie das SDK-Problem vermeiden können; es ist kein Beweis dafür, dass ein bestimmter Nutzer darunter gelitten hat.

Project 0 hat einheitliche Margin über Solana-Venues hinweg beschrieben, einschließlich Kamino und Drift. Protokollübergreifende Schnittstellen schaffen eine weitere Ebene, auf der eine Oracle-Migration korrekt gelesen werden muss. Die Notiz über ältere SDK-Versionen ist konkreter Beweis für eine Integrationsgefahr, ohne einen Fehler in Project 0 oder einer anderen genannten App zu belegen. Ein verantwortungsvolles Audit würde Softwareversionen und Live-Konfigurationen von Lending-Banken prüfen, bevor ein Ausfall behauptet wird.

Jitos Tip Router dokumentiert weiterhin Switchboard

Die Tip-Router-Übersicht der Jito Foundation 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 Onchain-Tip-Router-Programm, einen Node-Operator-Client und einen permissionless Cranker. Ihre Preisdokumentation nennt Switchboard als aktuellen Oracle-Feed und beschreibt Backup-Gewichte, wenn Feeds nicht verfügbar sind.

Die Dokumente weisen Switchboard eine bestimmte Aufgabe zu: die Preisgestaltung von Vault-Assets für Gewichtsberechnungen in einem Tip-Distributions- und Restaking-System. Sie besagen nicht, dass ein nicht verfügbarer Switchboard-Feed automatisch eine Solana-Lending-Position liquidieren würde. Jitos Preisseite beschreibt einen Fallback-Mechanismus, was die vereinfachte Behauptung abschwächt, dass ein Support-Ende notwendigerweise alle Tip-Router-Operationen stoppt. Die genauen Fallback-Werte, Aktivierungsbedingungen und aktuellen Live-Oracle-Konten erfordern noch eine aktuelle Prüfung des Programmzustands.

Die Tip-Router-Übersicht zeigte bei der Überprüfung am 25. September einen Marker für die letzte Aktualisierung von neun Monaten. Dieses Alter verändert die Art und Weise, wie sie verwendet werden kann. Es etabliert ein dokumentiertes Design und zeigt, wo eine technische Frage gestellt werden kann. Es kann nicht belegen, dass das aktuelle Programm dieselbe Feed-Konfiguration hat. Jito könnte Onchain-Konten aktualisiert haben, ohne die Seite zu überarbeiten, oder es könnte weiterhin Switchboard mit einem Fallback verwenden. Ohne eine aktuelle Transaktionsprüfung oder eine aktuelle Erklärung von Jito bleibt eine genannte Live-Abhängigkeit unbestätigt.

Jitos öffentliche GitHub-Release-Notes für Tip Router beziehen sich auf das erneute Versuchen von Switchboard-Oracle-Gateways in Keeper-Operationen. Eine Codebasis, die solche Logik enthält, demonstriert ebenfalls technische Integration, nicht notwendigerweise eine Abhängigkeit jedes Vaults zum Zeitpunkt der Veröffentlichung. Code kann einen Kompatibilitätspfad monatelang bewahren. Die aktuelle Frage ist, ob aktuelle Preisaktualisierungstransaktionen auf ein Switchboard-Konto abzielen, das von einem Vault verwendet wird, der noch Wert trägt, und ob dieses Konto nach der Support-Frist voranschreitet.

Die Unterscheidung geht oft verloren, wenn alle Oracle-Nutzer in eine einzige Liste aufgenommen werden. Jitos beschriebene Berechnung beeinflusst relative Asset-Gewichte in einem Distributionssystem. Die beschriebene Berechnung eines Lending-Marktes bestimmt den Sicherheitenwert und die Gesundheit des Kreditnehmers. Beide verbrauchen Preisdaten, aber ihre Fehlerpfade unterscheiden sich. Ein Audit, das Logos zählt, würde grundlegend unterschiedlichen Verwendungen dieselbe Schwere zuweisen.

Kaminos Scope ist ein Aggregator, kein Anbieter-Label

Kamino Finance's öffentliches Scope-Repository beschreibt einen Onchain-Aggregator, der Werte aus mehreren Oracle-Konten in einen einzigen Preisfeed kopiert und Aktualisierungen nach vorgegebenen Regeln validiert. Das 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 onchain gespeichert ist. Ein nachgelagertes Programm kann auf Scope verweisen, während Scope selbst für das ausgewählte Asset auf andere Feeds angewiesen ist. Scope in einer Bank-Konfiguration zu sehen, ist daher ein Ausgangspunkt für die Rückverfolgung der tatsächlichen Datenquelle, nicht das Ende.

Die marginfi-Notiz vom September listet Scope als eine Option auf, die für das beschriebene neue Setup nicht von Switchboard abhängt. Das impliziert nicht, dass jede Bereitstellung von Scope zu jedem Zeitpunkt 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 die Quellenzuordnung, die zum Befüllen seines Eintrags verwendet wird. Kaminos Repository liefert die Architektur, nicht ein mit Zeitstempeln 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. Die Existenz neuer Vaults zeigt, warum es unhaltbar wäre, ein ganzes Protokoll als exponiert zu bezeichnen, ohne seine einzelnen Assets zu prüfen. Ein USDC-Vault, eine Reserve für Liquid-Staking-Token und ein tokenisierter Aktienmarkt können unterschiedliche Oracle-Pfade verwenden. Wir haben nicht verifiziert, dass Galaxys Vaults Switchboard verwenden, daher sind sie nicht in einer Zählung betroffener Positionen enthalten.

Ebenso sagt uns die ältere Liste von Kamino, Jito, marginfi und Drift in Switchboards Einführungsmaterial nicht, wie die Verteilung der Exposition unter ihnen aussieht. Ein Projekt kann ein Oracle nur für einen Markt verwenden, es als Fallback nutzen oder Code beibehalten, nachdem Live-Feeds gewechselt wurden. Die einzig vertretbare Analyseeinheit ist ein spezifischer Markt oder Vault und sein konfigurierter Feed zu einem bestimmten Zeitpunkt. Ohne diese Einheit sind Behauptungen über gefährdete Gelder rückwärts laufende Marketing-Arithmetik.

Ein veralteter Feed hat mehr als eine mögliche Auswirkung

Die technische Konsequenz eines zurückbleibenden Feeds hängt vom konsumierenden Protokoll ab. Ein Lending-Programm benötigt im Allgemeinen einen Preis, um den Sicherheitenwert und die Kreditkapazität zu bestimmen. Wenn es einen alten Wert ablehnt, kann eine Aktion fehlschlagen oder ein Markt gemäß seinen Regeln pausieren. Wenn es veraltete Daten akzeptiert, könnte ein Kreditnehmer gegen einen Preis handeln, der nicht mehr dem Markt entspricht. Eine Fallback-Quelle kann den Markt in Betrieb halten, aber einen neuen Aktualisierungsrhythmus oder eine neue Konfidenzregel einführen. Die Dokumentation und die Onchain-Konfiguration des Protokolls entscheiden, welcher Pfad gilt.

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

Für Jito Tip Router beschreiben die öffentlichen Dokumente Backup-Gewichte für nicht verfügbare Feeds. Ob diese Backups eine genaue Belohnungszuweisung während eines anhaltenden Ausfalls gewährleisten, ist eine Frage der Live-Konfiguration und der Jito-Betreiber, nicht etwas, das ein Dokumentationssatz klärt. Wenn ein Feed nach Einstellung des Unternehmenssupports durch unabhängige Node-Betreiber weiter aktualisiert wird, wird möglicherweise kein Fallback sofort ausgelöst. Wenn Aktualisierungen aufhören, aber das Backup aktiv ist, kann der Betrieb mit einer anderen Preismethode fortgesetzt werden. Dies sind bedingte Pfade, keine Vorhersage des aktuellen Systemzustands.

Ein unabhängiger Oracle-Vorfall führte zu Liquidationen auf Vesu Anfang September. Er veranschaulicht, dass falsche Preisgestaltung wirtschaftliche Auswirkungen haben kann, ist aber kein Beweis für einen Vorfall bei Switchboard, Jito oder marginfi. Eine Abschaltungsmitteilung sollte nicht per Analogie in eine Liquidationsbehauptung umgewandelt werden. Das Anzeichen eines tatsächlichen Ereignisses wären veraltete Konto-Zeitstempel, fehlgeschlagene Transaktionen, eine Protokollpause oder identifizierte Verluste, von denen hier nichts für die Frist vom 25. September gezeigt wurde.

Solanas Umstellung auf 250-Millisekunden-Slots änderte das Tempo, in dem Blöcke produziert werden, garantierte aber nicht, dass eine externe Preisquelle aktualisiert wird. Schnellere Slots können einen neuen Preis früher transportieren, wenn einer existiert. Sie können keinen Preis erzeugen, wenn der Node, der ihn liefert, stoppt. Der Frischetest eines Protokolls kann nach Slot, Zeit oder einer anderen Regel gemessen werden, sodass eine Änderung der Netzwerkuhr die Interpretation alter Feed-Konfigurationen durch Entwickler verändern kann.

Wer trägt die Migrationsarbeit?

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

Ein Betreiber, der den Support einstellt, hat nicht unbedingt die Macht, die Programmkonfiguration eines Kunden umzuschreiben. Die Switchboard-Mitteilung drängte Nutzer zur Migration, weil Integrationsinhaber handeln müssen. Projekte sollten anhand der Adressen und Kontoaktualisierungen bewertet werden, die sie kontrollieren. Wenn eine Anwendung bereits vor dem 19. September zu Pyth gewechselt ist, hat die spätere Support-Frist keine direkte Auswirkung auf diesen Markt. Wenn sie noch einen Switchboard-Feed auswählt und kein funktionierendes Backup hat, ist das Verhalten des Feeds nach dem 25. September das konkrete Problem.

Die stärkste gegenteilige Lesart des Shutdown-Alarms folgt aus marginfis eigener September-Notiz und Jitos dokumentiertem Backup. Anwendungen können Redundanz entwerfen oder einem Anbieterausstieg zuvorkommen; der Code und die Dokumente zeigen Mechanismen dafür. Switchboards On-Demand-Modell kann einen Teil der Feed-Infrastruktur unabhängig weiterlaufen lassen, selbst wenn der Kernbeitragende den Support eingestellt hat. Die Mitteilung veröffentlichte keinen verifizierten Zeitplan, zu dem jedes Konto anhalten würde, und wir fanden keine primäre Evidenz, die einen solchen universellen Cutoff belegt.

Es gibt eine andere Art von Kontinuitätsfrage für ein Protokoll, das sein eigenes Fallback geschaffen hat. Ein Backup-Preis kann einen vollständigen Stillstand verhindern, während ein Asset seltener oder mit einem anderen Quellensatz bepreist wird. Für einen Belohnungsverteilungsprozess kann ein vorübergehendes Backup-Gewicht die Epochenabrechnung am Laufen halten, obwohl die Zuteilung dann auf den Annahmen des Backups beruhen kann. Für einen Lending-Markt könnte das Fallback den in einer Gesundheitsprüfung verwendeten Preis ändern. Dies sind keine Behauptungen über aktuelle Jito- oder marginfi-Einstellungen. Sie zeigen, was ein Maintainer offenlegen muss, bevor Nutzer beurteilen können, ob eine Migration in operativer Hinsicht abgeschlossen ist, nicht nur, ob Transaktionen noch ausgeführt werden.

Eine Anbieterabwicklung kann auch verzögerte Auswirkungen haben. Code, der geschrieben wurde, um On-Demand-Preise anzufordern, kann erfolgreich sein, während ein unabhängiges Gateway antwortet, und dann fehlschlagen, wenn dieses Gateway außer Betrieb genommen 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 auf fortgesetzten Dienst zu schließen. Dieselbe Disziplin gilt für eine fehlgeschlagene Transaktion: Der Fehler eines Nutzers kann von einem veralteten SDK oder unzureichender Kontoeingabe herrühren statt von einem nicht verfügbaren Oracle. Marginfis Migrationsdokument liefert ein explizites Beispiel für einen Software-Dekodierungsfehler, der andernfalls fälschlich als Oracle-Ausfall bezeichnet werden könnte.

Diese Beruhigung hat eine Grenze. Ein neun Monate zuvor beschriebenes Fallback muss gegen den aktuellen Zustand validiert werden, und eine im September beschriebene Migrationsoption ist kein Beweis dafür, dass jede Bank sie wahrgenommen hat. Die beiden Dokumente liefern glaubwürdige Gründe, nicht von einer Katastrophe auszugehen, lassen aber eine messbare Lücke. Die faire Schlussfolgerung ist enger als sowohl die werbliche als auch die alarmistische Version: Öffentliche Dokumente identifizieren mögliche Abhängigkeiten und Auswege; eine aktuelle Markt-für-Markt-Konfigurationsprüfung ist erforderlich, um jegliche verbleibende Exposition festzustellen.

Das Live-Inventar ist immer noch das fehlende Dokument

Die ursprüngliche Berichterstattung hier vergleicht Switchboards Liste von vier prominenten Integratoren mit aktuellen Primärdokumenten von Jito, marginfi und Kamino. Sie liefert zwei verifizierte dokumentarische Befunde. Jitos ältere Tip-Router-Dokumentation nennt Switchboard für die Vault-Preisgestaltung und einen Fallback für nicht verfügbare Feeds. Marginfis Notiz vom September 0.1.11 beschreibt neun neue Setups unabhängig von Switchboard und warnt vor einem separaten SDK-Bruch, wenn Integratoren nicht aktualisieren. Kamonos Scope-Repository erklärt, warum ein Aggregator-Label allein nicht jede vorgelagerte Datenquelle identifizieren kann.

Die Arbeit liefert nicht eine Zählung der live nicht migrierten Feeds, der exponierten Nutzergelder oder eines Ausfalls bei einem der genannten Protokolle. Die verfügbaren öffentlichen Seiten enthalten keinen synchronisierten Schnappschuss vom 25. September aller Oracle-Konten, der letzten erfolgreichen Aktualisierungen, Fallback-Einstellungen und der von jedem Markt unterstützten Beträge. Die Behauptung eines bestimmten Dollarbetrags aus dem TVL des Protokolls wäre unhaltbar, da die Vermögenswerte des gesamten Protokolls nicht unbedingt dasselbe Oracle verwenden. Die genaue Schlagzeilenfrage bleibt auf der Ebene der Live-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 Reward-Vault würde der Prüfer ihre Programm-Adresse, den ausgewählten Oracle-Typ, das Oracle-Konto, die Backup-Quelle, falls vorhanden, die letzte erfolgreiche Preisaktualisierung, das maximal zulässige Alter und den Wert der Positionen erfassen, die tatsächlich von diesem speziellen Preis abhängen. Doppelte Märkte, die sich ein Oracle-Konto teilen, sollten nicht als separate Feeds gezählt werden; ein Markt, der zwei unabhängige Orakel verwendet, sollte nicht als vollständig von einem der beiden abhängig gezählt werden, ohne seine Fallback-Logik zu lesen. Der Zeitstempel der Marktkonfiguration ist wichtig, da ein Administrator einen Feed nach der Beobachtung ändern könnte.

Diese Methode erklärt, warum selbst eine wahre Aussage wie die, dass ein Protokoll in der Vergangenheit 550 Feeds unterstützte, für die gegenwärtige Frage nicht ausreicht. Ein Feed kann existieren, ohne dass ein aktiver Kreditnehmer vorhanden ist, kann eine Preisaktualisierung haben, ohne dass ein verbrauchender Markt existiert, oder kann nur in ruhendem Code referenziert werden. Eine Zählung der Feed-Konten misst die Infrastruktur. Eine Zählung der konfigurierten Märkte misst die Abhängigkeit. Eine Zählung der Positionen und Sicherheiten, die diese Märkte tatsächlich berühren, misst die wirtschaftliche Exposition. Nichts davon ist austauschbar mit den gesamten Vermögenswerten, die in allen von einem Projekt betriebenen Produkten eingezahlt wurden.

Es gibt einen weiteren Verifizierungsschritt, wenn eine Quelle ein Aggregator ist. Der Verbraucher kann ein Scope-Konto und einen Eintragsindex identifizieren, während die Scope-Zuordnung auf einen oder mehrere Anbieter weiterverweist. Eine Aktualisierung im Scope-Konto nach dem 25. September beweist, dass ein Aggregator einen Wert erzeugt hat, aber es beweist nicht für sich genommen, dass Switchboard weiterhin den zugrunde liegenden Preis geliefert hat. Der Ermittler benötigt den ausgewählten Eintrag und die Quellkonfiguration für diese Aktualisierung. Kamonos Repository merkt an, dass Token-Paar-Labels nicht vollständig onchain gespeichert sind, sodass externe Konfiguration oder Maintainer-Dokumentation erforderlich sein kann, um einen Index seinem Asset zuzuordnen. Wo diese Zuordnung nicht verfügbar ist, sollte das Ergebnis als unbekannt erfasst 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.
• Zeitstempel der Preisaktualisierung: Prüfen Sie, ob ein identifizierter Feed nach dem 25. September weiterhin frische Werte veröffentlicht.
• Fallback-Konfiguration: Suchen Sie nach der Quelle und dem Frischelimit, die verwendet werden, wenn ein primärer Feed zurückbleibt.
• Letzte Programmtransaktionen: Prüfen Sie, ob Kreditaufnahme, Abrechnung oder Tip-Verteilung für den betroffenen Markt noch abgeschlossen werden.
• Datierte Maintainer-Updates: Suchen Sie nach einer benannten Migration, Marktpause oder verbleibenden Abhängigkeit, unterstützt durch eine Konto- oder Programm-Adresse.

Erfassen Sie die Beobachtungszeit für jede Prüfung; ein Screenshot ohne Block oder Zeitstempel kann schnell veralten.

Marginfis Upgrade-Hinweis besagt, dass eine Bank, die einen neuen Oracle-Enum-Wert verwendet, dazu führen kann, dass ein älteres SDK seinen Client nicht initialisieren kann, selbst wenn ein Benutzer nicht mit dieser bestimmten Bank interagiert. Die Anweisung, SDK-Version 2.8.0 oder höher zu verwenden, wurde vor dem Beginn der Migration am 4. September veröffentlicht, drei Wochen vor Switchboards Support-Deadline.

FAQ