La fin du support de Switchboard laisse les protocoles Solana vérifier leurs dépendances oracle en production

L'échéance du 25 septembre pour le support de Switchboard a transformé un préavis de migration de six jours en un test pour les flux de prix de Solana. La documentation publique montre où l'oracle reste intégré à la conception d'une application, mais ces pages ne peuvent pas prouver qu'un marché actif utilise encore ce flux. Jito et marginfi offrent deux visions très différentes de l'exposition potentielle.

Switchboard a atteint la fin officielle de son support technique le 25 septembre, laissant les applications Solana vérifier les sources de prix configurées dans leurs programmes en production.

Selon la déclaration du 19 septembre du projet oracle, telle que reprise dans la couverture de l'annonce, son contributeur principal de développement, Switchboard Technology Labs, cesserait ses activités et toutes les implémentations seraient dépréciées immédiatement. L'équipe a exhorté les intégrateurs à migrer vers d'autres fournisseurs, citant Pyth et RedStone. Le 25 septembre a été décrit comme le dernier jour de support existant.

La fin du support technique constitue un véritable jalon opérationnel. Cela ne prouve pas, en soi, que chaque flux on-chain a cessé d'être mis à jour à minuit ni que chaque application autrefois associée à Switchboard en demeurait dépendante.

La propre documentation de Switchboard a cité Kamino, Jito, marginfi et Drift comme utilisateurs. Il s'agit de déclarations d'intégration historiques de la part d'un fournisseur vendant un service d'oracle, et non d'un inventaire en temps réel des flux actifs au 25 septembre. La documentation actuelle de chaque projet présente un tableau plus complexe. Les pages du Tip Router de Jito décrivent toujours Switchboard dans leur processus de valorisation, tandis que la mise à niveau technique de septembre de marginfi ajoute des conçues pour éviter cette dépendance. Un document peut être obsolète tandis qu'un autre anticipe une migration. Aucun des deux ne remplace l'inspection de la configuration réelle des comptes.

Le précédent tour de financement de Switchboard s'élevait à 7,5 millions de dollars en mai 2024. Ce montant éclaire l'historique du projet, mais ne mesure pas l'exposition actuelle du protocole. La donnée pertinente est le nombre et la valeur des marchés actifs dont les calculs de risque utilisent encore des données d'un flux qui ne peut plus être mis à jour de manière fiable. Ce chiffre ne peut être déduit d'un logo de client.

Une intégration répertoriée n'est pas un flux actif

La présentation publique de Switchboard décrit des flux à la demande : les applications créent ou appellent les données dont elles ont besoin, et un prix est rendu disponible via des comptes Solana. La documentation peut identifier où un protocole sait lire un flux Switchboard, mais elle peut ne pas identifier l'option qu'un marché donné sélectionne actuellement. Un kit de développement logiciel peut prendre en charge un type d'oracle longtemps après que la dernière banque l'ait abandonné. Inversement, un site web peut changer alors qu'une réserve active conserve son ancien compte oracle.

Trois niveaux de preuve doivent être distingués. Le premier est une page marketing ou d'intégration, qui montre qu'une relation a existé. Le deuxième est la configuration prise en charge d'un programme, visible dans la documentation technique ou le code. Le troisième est la configuration réelle et l'historique récent des mises à jour du marché concerné. Seul le troisième peut étayer l'affirmation qu'un marché donné dépendait encore de Switchboard à un moment précis. Même alors, une source de secours peut être configurée, de sorte que l'effet d'un flux principal arrêté doit être vérifié au regard de la règle de repli et de fraîcheur applicable.

La documentation du protocole marginfi conserve les variantes SwitchboardPull et venue parmi ses configurations d'oracle disponibles. Elle indique qu'un appelant doit actionner (crank) un flux pull Switchboard juste avant utilisation. La même table liste les flux push Pyth et les comptes Scope comme autres configurations. La présence persistante de la ligne Switchboard ne prouve pas que chaque banque de marginfi l'utilise encore ; la table décrit les types pris en charge, et non une liste complète de la banque utilisant quel flux aujourd'hui.

La note distincte du Program 0.1.11 de marginfi est plus récente et plus précise. Elle demandait aux développeurs de mettre à niveau le SDK vers au moins la version 2.8.0 avant le 4 septembre, indiquant que les banques commenceraient à migrer vers de nouvelles configurations d'oracle à partir de cette date. La version a ajouté neuf variantes indépendantes de Switchboard, dont les flux Kamino Scope et une tarification basée sur des taux de change pour certains jetons de liquid staking et principal tokens.

La note ne dit pas que chaque banque avait migré au 25 septembre. Elle montre bien que marginfi a publiquement documenté une voie de sortie de la dépendance menacée avant l'annonce d'arrêt.

La migration a introduit un second mode de défaillance possible. Selon marginfi, les SDK plus anciens ne peuvent pas décoder une banque configurée avec l'une des nouvelles valeurs d'énumération d'oracle. Une seule banque avec une valeur non prise en charge peut empêcher Project0Client.initialize et les lectures de banques, au-delà des seules actions impliquant cette banque. Changer d'oracle peut donc résoudre une dépendance d'infrastructure tout en cassant un intégrateur qui n'a pas mis à jour son logiciel. Le document de marginfi explique comment les intégrateurs peuvent éviter ce problème SDK ; ce n'est pas la preuve qu'un utilisateur particulier l'a subi.

Le Project 0 a décrit une marge unifiée à travers les plateformes Solana, dont Kamino et Drift. Les interfaces inter-protocoles créent une couche supplémentaire où une migration d'oracle doit être évaluée. L'avertissement concernant les anciennes versions du SDK constitue une preuve concrète d'un risque d'intégration, mais ne prouve pas de défaillance dans le Project 0 ou toute autre application nommée. Un audit responsable vérifierait les versions logicielles et les configurations réelles des banques de prêt avant d'affirmer une panne.

Le Tip Router de Jito documente toujours Switchboard

La présentation du Tip Router de la Jito Foundation indique que Switchboard détermine le poids relatif des actifs tels que JitoSOL et JTO détenus dans les coffres liés au Tip Router. La présentation identifie un programme Tip Router on-chain, un client pour opérateurs de nœuds et un cranker sans permission. Sa documentation de tarification nomme Switchboard comme flux oracle actuel et décrit des poids de secours lorsque les flux sont indisponibles.

Ces documents placent Switchboard dans un rôle spécifique : valoriser les actifs des coffres pour les calculs de poids dans un système de distribution de pourboires et de restaking. Ils ne disent pas qu'un flux Switchboard indisponible liquiderait automatiquement une position de prêt Solana. La page de tarification de Jito décrit un mécanisme de repli ce qui affaiblit l'affirmation simpliste selon laquelle une fin de support arrêterait nécessairement toutes les opérations du Tip Router. Les valeurs exactes du repli, les conditions d'activation et les comptes oracle réels exigent toujours une vérification de l'état actuel du programme.

La présentation du Tip Router affichait une mention de dernière mise à jour datant de neuf mois lors de la vérification du 25 septembre. Cet âge limite l'usage de la page. Elle établit une conception documentée et indique où poser une question technique, mais ne peut établir que le programme actuel présente la même configuration de flux. Jito a peut-être mis à jour les comptes on-chain sans réviser la page, ou utilise encore Switchboard avec un repli. Sans inspection récente des transactions ni déclaration actuelle de Jito, une dépendance réelle nommée demeure non vérifiée.

Les notes de version publiques GitHub de Jito pour le Tip Router mentionnent la réessai des passerelles oracle Switchboard dans les opérations de keeper. Une base de code contenant une telle logique démontre une intégration technique, pas nécessairement une dépendance de chaque coffre à la date de publication. Le code peut conserver un chemin de compatibilité pendant des mois. La question concrète est de savoir si les transactions récentes de mise à jour de prix ciblent un compte Switchboard utilisé par un coffre portant encore de la valeur, et si ce compte progresse après l'échéance du support.

La distinction est souvent perdue lorsque tous les utilisateurs d'un oracle sont placés dans une même liste. Le calcul décrit par Jito affecte les poids relatifs des actifs dans un système de distribution. Le calcul d'un marché de prêt détermine la valeur du collatéral et la santé de l'emprunteur. Les deux consomment des données de prix, mais leurs trajectoires de défaillance diffèrent. Un audit qui compte des logos attribuerait la même gravité à des usages fondamentalement différents.

Le Scope de Kamino est un agrégateur, pas une étiquette de fournisseur

Le dépôt public Scope de Kamino Finance décrit un agrégateur on-chain qui copie les valeurs de plusieurs comptes oracle dans un flux de prix unique et valide les mises à jour selon des règles prédéfinies. Son README indique qu'un flux prend en charge jusqu'à 512 prix et que l'association entre un index et une paire de jetons n'est pas entièrement stockée on-chain. Un programme en aval peut pointer vers Scope tandis que Scope lui-même repose sur d'autres flux pour l'actif sélectionné. Voir Scope dans la configuration d'une banque est donc un point de départ pour retracer la source réelle des données, non une conclusion.

La note de septembre de marginfi liste Scope comme une option ne dépendant pas de Switchboard pour la configuration qu'elle décrit. Cela ne signifie pas que chaque déploiement de Scope à chaque date exclut toute source Switchboard. Un agrégateur peut changer ses entrées sous-jacentes. Une vérification complète des dépendances exige à la fois le compte Scope sélectionné par le consommateur et le mappage des sources utilisé pour alimenter son entrée. Le dépôt de Kamino fournit l'architecture, pas un inventaire horodaté des sources mainnet actuelles pour chaque application.

Kamino a continué à attirer des institutions dans son écosystème de prêt. Galaxy a ouvert deux coffres de stablecoins sur la plateforme en septembre. L'existence de nouveaux coffres montre pourquoi désigner un protocole entier comme exposé sans vérifier ses actifs individuels serait erroné. Un coffre USDC, une réserve de jeton de liquid staking et un marché d'actions tokenisées peuvent utiliser des chemins oracle différents. Les coffres de Galaxy n'ont pas été vérifiés comme utilisant Switchboard et ne sont donc pas inclus dans un décompte des positions affectées.

De même, l'ancienne liste de Kamino, Jito, marginfi et Drift dans le matériel d'introduction de Switchboard ne montre pas comment l'exposition se répartissait entre eux. Un projet peut utiliser un oracle pour un seul marché, comme solution de repli, ou conserver du code après avoir changé de flux actifs. La seule unité d'analyse défable est un marché ou un coffre spécifique et son flux configuré à un moment donné. Sans cette unité, les affirmations sur les fonds à risque relèvent d'un calcul marketing inversé.

Un flux obsolète peut avoir plus d'un effet

La conséquence technique d'un flux en retard dépend du protocole consommateur. Un programme de prêt a généralement besoin d'un prix pour déterminer la valeur du collatéral et la capacité d'emprunt. S'il rejette une valeur ancienne, une action peut échouer ou un marché peut se mettre en pause selon ses règles. S'il accepte des données obsolètes, un emprunteur peut transiger sur un prix qui ne correspond plus au marché. Une source de repli peut maintenir le marché opérationnel tout en introduisant un rythme de mise à jour ou une règle de confiance différents. La documentation du protocole et la configuration on-chain déterminent quel scénario s'applique.

Marginfi indique explicitement que les flux pull Switchboard doivent être actionnés avant utilisation. Un intégrateur doit donc fournir une mise à jour fraîche dans son chemin de transaction. Les flux push Pyth, en revanche, sont décrits comme maintenus à jour par l'infrastructure de Pyth. Scope utilise une valeur de compte agrégée sélectionnée par un index d'entrée configuré. Passer d'un type à l'autre change les comptes dont une transaction a besoin et le code qui les vérifie. L'avertissement SDK de septembre est un exemple visible de ces changements touchant les logiciels applicatifs.

Pour le Tip Router de Jito, la documentation publique décrit des poids de secours pour les flux indisponibles. Le fait que ces replis préservent une allocation précise des récompenses lors d'une panne prolongée est une question relevant de la configuration réelle et des opérateurs de Jito, et non quelque chose qu'une phrase de documentation résout. Si un flux continue d'être mis à jour par des opérateurs de nœuds indépendants après la fin du support, aucun repli ne sera peut-être déclenché immédiatement. Si les mises à jour cessent mais que le repli est actif, les opérations peuvent se poursuivre avec une méthode de tarification différente. Ce sont des chemins conditionnels, pas une prédiction de l'état actuel du système.

Un incident oracle sans rapport a entraîné des liquidations sur Vesu plus tôt en septembre. Cela illustre qu'une tarification incorrecte peut avoir des effets économiques, mais ce n'est pas la preuve d'un incident chez Switchboard, Jito ou marginfi. Un avis d'arrêt ne doit pas être transformé en affirmation de liquidation par analogie. Les preuves d'un événement réel comprendraient des horodatages de comptes obsolètes, des transactions échouées, une pause de protocole ou des pertes identifiées. Rien de tout cela n'a été montré pour l'échéance du 25 septembre.

Le passage de Solana aux slots de 250 millisecondes a changé le rythme de production des blocs, mais ne garantissait pas la mise à jour d'une source de prix externe. Des slots plus rapides peuvent véhiculer un nouveau prix plus vite s'il existe ; ils ne peuvent pas fabriquer un prix quand le nœud qui le fournit s'arrête. Le test de fraîcheur d'un protocole peut être mesuré en slots, en temps ou selon une autre règle ; un changement d'horloge réseau peut donc modifier l'interprétation par les développeurs d'anciennes configurations de flux.

Qui porte la charge de la migration ?

L'opérateur d'oracle publie ou coordonne les données, mais le protocole consommateur choisit le compte que son programme lit et les limites imposées à ce prix. Un protocole de prêt peut exiger une gouvernance ou un administrateur pour changer les adresses oracle de ses marchés. Son interface et ses intégrateurs tiers doivent ensuite construire des transactions avec les comptes supplémentaires appropriés. Les utilisateurs ne remarquent peut-être qu'un emprunt refusé ou un marché en pause, longtemps après les décisions techniques de l'opérateur et du protocole.

Un opérateur mettant fin support n'a pas nécessairement le pouvoir de réécrire la configuration du programme d'un client. Switchboard a exhorté les utilisateurs à migrer parce que les propriétaires d'intégrations doivent agir. Les projets doivent être évalués selon les adresses et mises à jour de comptes qu'ils contrôlent. Si une application est passée à Pyth avant le 19 septembre, l'échéance ultérieure n'a aucun effet direct sur ce marché. Si elle sélectionne encore un flux Switchboard sans repli fonctionnel, le comportement du flux après le 25 septembre est le problème concret.

La lecture opposée la plus solide de l'alarme d'arrêt découle de la note de septembre de marginfi et du repli documenté de Jito. Les applications peuvent concevoir de la redondance ou anticiper le retrait d'un fournisseur ; le code et les documents montrent des mécanismes pour ce faire. Le modèle à la demande de Switchboard peut laisser certaines infrastructures de flux fonctionner indépendamment même si le contributeur principal a cessé le support. L'avis n'a pas publié de calendrier vérifié auquel chaque compte s'arrêterait, et aucune preuve primaire n'établit un tel cutoff universel.

La fin des activités d'un fournisseur peut aussi avoir des effets différés. Un code demandant des prix à la demande peut réussir tant qu'une passerelle indépendante répond, puis échouer quand cette passerelle est retirée ou que ses opérateurs cessent de mettre à jour un actif spécifique. Un observateur a besoin de plusieurs horodatages postérieurs à l'échéance, et non d'une seule transaction réussie, pour inférer un service continu. La même discipline s'applique à une transaction échouée : une erreur peut provenir d'un SDK obsolète ou d'entrées de compte insuffisantes plutôt que d'un oracle indisponible. Le document de migration de marginfi fournit un exemple explicite de défaillance de décodage logiciel qui pourrait autrement être étiquetée à tort comme une panne d'oracle.

La conclusion équitable est plus étroite que les versions promotionnelles et alarmistes : les documents publics identifient des dépendances candidates et des voies de sortie, mais un audit actuel de la configuration, marché par marché, est nécessaire pour établir toute exposition restante.

L'inventaire en temps réel reste absent

Le reportage compare la liste des quatre intégrateurs prominent de Switchboard aux documents primaires actuels de Jito, marginfi et Kamino. Il produit plusieurs constats documentaires. L'ancienne documentation du Tip Router de Jito nomme Switchboard pour la valorisation des coffres et identifie un repli pour les flux indisponibles. La note 0.1.11 de septembre de marginfi décrit neuf nouvelles configurations indépendantes de Switchboard et avertit d'une rupture SDK distincte si les intégrateurs ne mettent pas à niveau. Le dépôt Scope de Kamino explique pourquoi une simple étiquette d'agrégateur ne peut identifier chaque source amont.

Le matériel disponible ne produit pas de décompte des flux actifs non migrés, des fonds utilisateurs exposés ni de panne chez un protocole nommé. Les pages publiques ne contiennent pas d'instantané synchronisé au 25 septembre de tous les comptes oracle, des dernières mises à jour réussies, des paramètres de repli et des montants pris en charge par chaque marché. Affirmer un total en dollars spécifique à partir de la TVL d'un protocole serait indéfendable, car tous les actifs d'un protocole ne partagent pas nécessairement le même oracle. La question précise demeure ouverte au niveau des comptes en production.

Un décompte approprié utiliserait le marché comme ligne, non le protocole. Pour chaque banque de prêt active, marché de dérivés ou coffre de récompenses, un auditeur enregistrerait son adresse de programme, le type d'oracle sélectionné, le compte oracle, la source de repli le cas échéant, la dernière mise à jour de prix réussie, l'âge maximal autorisé et la valeur des positions réellement dépendantes de ce prix. Les marchés en double partageant un même compte oracle ne devraient pas être comptés comme des flux distincts. Un marché utilisant deux oracles indépendants ne devrait pas être compté comme entièrement dépendant de l'un ou l'autre sans lire sa logique de repli. L'horodatage de la configuration du marché importe car un administrateur pourrait changer un flux après l'observation.

Une étape de vérification supplémentaire s'impose quand la source est un agrégateur. Le consommateur peut identifier compte Scope et un index d'entrée, tandis que le mappage de Scope pointe vers un ou plusieurs fournisseurs. Une mise à jour dans le compte Scope après le 25 septembre prouve qu'un agrégateur a produit une valeur, mais ne prouve pas en soi que Switchboard a continué à fournir le prix sous-jacent. L'enquêteur a besoin de l'entrée sélectionnée et de la configuration des sources pour cette mise à jour. Là où ce mappage est indisponible, le résultat devrait être enregistré comme inconnu, et non attribué silencieusement à Pyth ou Switchboard.

Ce qu'il faut surveiller

• Adresses oracle des marchés : comparer le flux configuré de chaque banque ou coffre actif aux comptes Switchboard documentés.
• Horodatages des mises à jour de prix : vérifier si un flux identifié continue de publier des valeurs fraîches après le 25 septembre.
• Configuration du repli : identifier la source et la limite de fraîcheur utilisées si un flux principal prend du retard.
• Transactions récentes du programme : vérifier si l'emprunt, le règlement ou la distribution de pourboires se termine toujours pour le marché affecté.
• Mises à jour datées des mainteneurs : rechercher une migration nommée, une pause de marché ou une dépendance restante appuyée par une adresse de compte ou de programme.

L'heure d'observation de chaque vérification devrait être consignée ; une capture d'écran sans bloc ni horodatage devient rapidement obsolète.

La note de mise à niveau de marginfi indique qu'une banque utilisant une nouvelle valeur d'énumération d'oracle peut faire échouer l'initialisation du client d'un SDK plus ancien, même si un utilisateur n'interagit pas avec cette banque. La consigne d'utiliser le SDK version 2.8.0 ou ultérieure a été publiée avant le début de la migration du 4 septembre, trois semaines avant l'échéance du support de Switchboard.

FAQ

Quand Switchboard a-t-il annoncé la fin du support ?

L'annonce d'arrêt a été faite le 19 septembre 2026, identifiant le 25 septembre comme la fin du support technique existant. L'avis a déprécié les implémentations immédiatement.

Tous les flux oracle Switchboard se sont-ils arrêtés le 25 septembre ?

L'échéance du support seule n'établit pas que chaque compte on-chain a cessé d'être mis à jour. Des horodatages actuels des transactions et des flux sont nécessaires pour cette affirmation.

Jito utilise-t-il encore Switchboard ?

La documentation du Tip Router de Jito nomme toujours Switchboard pour la valorisation des coffres, mais sa présentation est marquée comme mise à jour pour la dernière fois il y a neuf mois. Ces pages ne prouvent pas la configuration réelle au 25 septembre.

marginfi a-t-il migré hors de Switchboard ?

La mise à niveau de septembre de marginfi documente neuf nouvelles configurations d'oracle indépendantes de Switchboard et indique que les banques ont commencé à migrer à partir du 4 septembre. Elle ne précise pas que chaque banque a achevé sa migration.

Pourquoi une migration d'oracle peut-elle casser un SDK ?

Selon marginfi, les SDK plus anciens ne reconnaissent pas les valeurs d'énumération utilisées par ses neuf nouvelles configurations. Une banque configurée avec l'une d'elles peut faire échouer l'initialisation d'un ancien client ; la version 2.8.0 ou ultérieure prend en charge les variantes.

Le Scope de Kamino est-il indépendant de tout oracle externe ?

Scope agrège des valeurs provenant d'autres comptes oracle. Sa présence dans la configuration d'un consommateur n'identifie pas chaque source amont sans examiner le mappage d'entrée spécifique.

Comment les utilisateurs peuvent-ils vérifier si un marché est affecté ?

Le compte oracle configuré du marché, la dernière mise à jour et les paramètres de repli fournissent une réponse plus fiable qu'une liste historique de fournisseurs. Les annonces des protocoles peuvent confirmer si un marché spécifique a migré.

Des pertes ont-elles été vérifiées suite à cet arrêt ?

Aucune perte chez un protocole nommé n'a été vérifiée pour cet article. Un incident antérieur sur un autre protocole ne peut prouver qu'un tel incident s'est produit ici Il s'agit d'une analyse pédagogique, et non d'un conseil en investissement.

Avertissement : cet article est fourni à titre informatif et pédagogique uniquement et ne constitue pas un conseil financier ou en investissement. Les chiffres reflètent les dépôts réglementaires et les reportages disponibles au moment de la rédaction et changent à chaque divulgation. Rien ici ne constitue une recommandation d'acheter, de vendre ou de détenir un titre ou un actif. Faites toujours vos propres recherches. Les informations sont exactes au 25 septembre 2026.