Un oracle Solana cesse son support aujourd'hui. Qui dépend encore de ses prix ?

La date limite de support du 25 septembre de Switchboard a transformé un avertissement de migration de six jours en un test pour les flux de prix de Solana. La documentation publique actuelle montre où ses données font encore partie de la conception d'une application, mais ces pages ne peuvent pas prouver qu'un marché en direct utilise encore le flux. Jito et marginfi offrent deux points de vue très différents de l'exposition.

Switchboard a atteint sa fin annoncée du support technique le 25 septembre, laissant les applications Solana vérifier les sources de prix configurées dans leurs programmes en direct.

La déclaration du 19 septembre du projet d'oracle, telle que reproduite dans la couverture de l'annonce, indiquait que son contributeur principal au développement, Switchboard Technology Labs, cesserait ses activités et que toutes les implémentations seraient immédiatement dépréciées. L'équipe a exhorté les intégrateurs à migrer vers d'autres fournisseurs, nommant Pyth et RedStone. Le 25 septembre a été décrit comme le dernier jour pour le support existant. Une entreprise qui met fin au support est un jalon opérationnel réel. Cela ne prouve pas, en soi, que chaque flux onchain a cessé de se mettre à jour à minuit ou que chaque application autrefois associée à Switchboard est restée dépendante de celui-ci.

La documentation de Switchboard elle-même a nommé Kamino, Jito, marginfi et Drift comme utilisateurs. Ce sont des affirmations d'intégration historiques d'un fournisseur qui vendait un service d'oracle, et non un inventaire en temps réel des flux actifs le 25 septembre. Vérifier la documentation actuelle de chaque projet révèle une image plus compliquée. Les pages de Jito's Tip Router décrivent encore Switchboard dans leur flux de tarification ; la mise à niveau technique de septembre de marginfi ajoute des chemins conçus pour éviter cette dépendance. Un document peut être obsolète tandis qu'un autre anticipe une migration. Ni l'un ni l'autre ne remplace une inspection de la configuration du compte en direct.

Le tour de financement antérieur de Switchboard était de 7,5 millions de dollars en mai 2024. Le montant est un contexte utile sur l'histoire de l'entreprise, mais il ne donne aucune mesure de l'exposition actuelle du protocole. Le décompte pertinent est le nombre et la valeur des marchés en direct dont les calculs de risque prennent encore des données d'un flux qui ne peut pas être mis à jour de manière fiable, et ce décompte ne peut pas être déduit d'un logo client.

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

L'introduction 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 mis à disposition via les comptes Solana. La documentation peut identifier où un protocole sait lire un flux Switchboard. Elle peut ne pas identifier quelle option un marché particulier 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 a cessé de l'utiliser. Inversement, un site Web peut changer alors qu'une réserve en direct conserve son ancien compte d'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 par un programme, visible dans la documentation technique ou le code. Le troisième est la configuration en direct et l'historique de mise à jour récent du marché réel. Seul le troisième peut étayer l'affirmation qu'un marché nommé dépendait encore de Switchboard à un moment donné. Même alors, une source de secours peut être configurée, de sorte que l'impact d'un flux principal arrêté doit être vérifié par rapport à la règle de secours et de fraîcheur pertinente.

Considérez la documentation du protocole de marginfi. Son tableau d'oracle conserve SwitchboardPull et les variantes de lieu parmi les configurations disponibles. Il indique qu'un appelant doit actionner un flux pull Switchboard juste avant utilisation. Le même tableau répertorie les flux push Pyth et les comptes Scope comme autres configurations. Un lecteur pourrait confondre la ligne Switchboard maintenue avec la preuve que chaque banque marginfi l'utilise encore. Le tableau décrit les types pris en charge, et non une liste complète de quelle banque utilise quel flux aujourd'hui.

La note distincte de Marginfi sur le Programme 0.1.11 est plus récente et plus précise. Elle demandait aux développeurs de mettre à niveau le SDK 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 ajoutait neuf variantes qui ne dépendent pas de Switchboard, notamment les flux Kamino Scope et une tarification basée sur le taux de change pour certains jetons de staking liquide et de principal. La note ne dit pas que toutes les banques avaient migré au 25 septembre. Elle montre toutefois qu’un projet a documenté publiquement une voie de sortie de la dépendance menacée avant l’annonce de l’arrêt.

La migration comporte un second mode de défaillance surprenant. Marginfi indique que les anciens SDK 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 la lecture des banques, pas seulement une action impliquant cette banque. En d’autres termes, changer un oracle peut corriger une dépendance d’infrastructure tout en cassant un intégrateur qui n’a pas mis à jour son logiciel. Le document de Marginfi explique aux intégrateurs comment éviter le problème du SDK ; ce n’est pas la preuve qu’un utilisateur particulier en a souffert.

Project 0 a décrit une marge unifiée entre les plateformes Solana, notamment Kamino et Drift. Les interfaces inter-protocoles créent une couche supplémentaire où une migration d’oracle doit être lue correctement. La note sur les anciennes versions du SDK est une preuve concrète d’un risque d’intégration, sans prouver une défaillance dans Project 0 ou toute autre application nommée. Un audit responsable vérifierait les versions logicielles et les configurations actives des banques de prêt avant de déclarer une panne.

Le Tip Router de Jito documente encore Switchboard

L’aperçu du Tip Router de la Fondation Jito indique que Switchboard détermine le poids relatif d’actifs tels que JitoSOL et JTO détenus dans des coffres liés au Tip Router. L’aperçu identifie un programme Tip Router onchain, un client opérateur de nœud et un cranker sans permission. Sa documentation de tarification nomme Switchboard comme flux d’oracle actuel et décrit des pondérations de secours lorsque les flux sont indisponibles.

Les documents assignent à Switchboard une tâche spécifique : évaluer les actifs des coffres pour les calculs de pondération 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 un arrêt du support ferait nécessairement cesser toutes les opérations du Tip Router. Les valeurs de repli exactes, les conditions d’activation et les comptes d’oracle actuellement actifs nécessitent encore une vérification de l’état actuel du programme.

L’aperçu du Tip Router affichait un marqueur de dernière mise à jour de neuf mois lors de la vérification du 25 septembre. Cet âge change la façon dont il peut être utilisé. Il établit une conception documentée et identifie où poser une question technique. Il ne peut pas établir que le programme actuel a la même configuration de flux. Jito peut avoir mis à jour les comptes onchain sans réviser la page, ou peut encore utiliser Switchboard avec un repli. Sans inspection récente des transactions ou déclaration actuelle de Jito, une dépendance active nommée reste non vérifiée.

Les notes de version publiques de Jito sur GitHub pour le Tip Router font référence à la nouvelle tentative des passerelles d’oracle Switchboard dans les opérations du keeper. Une base de code contenant une telle logique démontre également une intégration technique, pas nécessairement une dépendance de chaque coffre au moment de la publication. Le code peut conserver un chemin de compatibilité pendant des mois. La question actuelle est de savoir si les transactions récentes de mise à jour des prix ciblent un compte Switchboard utilisé par un coffre contenant encore de la valeur, et si ce compte progresse après la date limite de support.

La distinction est souvent perdue lorsque tous les utilisateurs d’oracle sont placés dans une seule liste. Le calcul décrit de Jito affecte les pondérations relatives des actifs dans un système de distribution. Le calcul décrit 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 chemins de défaillance diffèrent. Un audit qui compte les logos attribuerait la même sévérité à des usages fondamentalement différents.

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

Le dépôt public Scope de Kamino Finance décrit un agrégateur onchain qui copie les valeurs de plusieurs comptes oracle dans un seul flux de prix 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 indice et une paire de tokens n'est pas entièrement stockée onchain. Un programme en aval peut pointer vers Scope tandis que Scope lui-même s'appuie sur d'autres flux pour l'actif sélectionné. Voir Scope dans une configuration de banque est donc un point de départ pour tracer la source de données réelle, pas une fin.

La note de marginfi de septembre liste Scope comme une option qui ne dépend pas de Switchboard pour la nouvelle configuration qu'elle décrit. Cela n'implique pas que chaque déploiement de Scope à chaque date exclut chaque source Switchboard. Un agrégateur peut modifier ses entrées sous-jacentes. Une vérification complète des dépendances nécessite à la fois le compte Scope sélectionné par le consommateur et le mappage des sources utilisé pour remplir 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é d'intégrer 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 tout un protocole comme exposé sans vérifier ses actifs individuels serait infondé. Un coffre USDC, une réserve de token de staking liquide et un marché d'actions tokenisées peuvent utiliser des chemins d'oracle différents. Nous n'avons pas vérifié que les coffres de Galaxy utilisent Switchboard, ils 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 nous indique pas la distribution de l'exposition entre eux. Un projet peut utiliser un oracle uniquement pour un marché, l'utiliser comme solution de repli, ou conserver le code après avoir changé les flux en direct. La seule unité d'analyse défendable est un marché ou coffre spécifique et son flux configuré à un moment donné. Sans cette unité, les affirmations sur les fonds à risque sont de l'arithmétique marketing à l'envers.

Un flux obsolète a plus d'un effet possible

La conséquence technique d'un flux qui prend du 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 pourrait effectuer une transaction sur la base d'un prix qui ne correspond plus au marché. Une source de repli peut maintenir le marché en fonctionnement mais introduire un nouveau rythme de mise à jour ou une nouvelle règle de confiance. La documentation du protocole et la configuration onchain déterminent quel chemin s'applique.

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

Pour Jito Tip Router, la documentation publique décrit des pondérations de secours pour les flux indisponibles. Savoir si ces sauvegardes préservent une allocation précise des récompenses lors d'une panne prolongée est une question qui relève de la configuration en direct et des opérateurs de Jito, et non d'une phrase de documentation. Si un flux continue de se mettre à jour via des opérateurs de nœuds indépendants après que l'entreprise a cessé son support, aucune solution de repli ne sera peut-être déclenchée immédiatement. Si les mises à jour cessent mais que la sauvegarde est active, 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 d'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 une 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. Le signe d'un événement réel serait des horodatages de comptes obsolètes, des transactions échouées, une pause de protocole ou des pertes identifiées, dont aucun n'a été montré ici pour l'échéance du 25 septembre.

Le passage de Solana à des slots de 250 millisecondes a modifié le rythme de production des blocs, mais n'a pas garanti qu'une source de prix externe se mette à jour. Des slots plus rapides peuvent transporter un nouveau prix plus tôt lorsqu'il existe. Ils ne peuvent pas fabriquer un prix lorsque le nœud qui le fournit s'arrête. Le test de fraîcheur d'un protocole peut être mesuré par slot, par temps ou par une autre règle, de sorte qu'un changement dans l'horloge du réseau peut modifier la façon dont les développeurs interprètent les anciennes configurations de flux.

Qui assume le travail de 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 qu’il impose à ce prix. Un protocole de prêt peut exiger une gouvernance ou un administrateur pour modifier les adresses d’oracle de ses marchés. Son interface et les intégrateurs tiers doivent alors construire des transactions avec les bons comptes supplémentaires. Les utilisateurs peuvent ne remarquer qu’un emprunt rejeté ou un marché en pause, longtemps après que l’opérateur et le protocole ont pris leurs décisions techniques.

Un opérateur qui met fin à son support n’a pas nécessairement le pouvoir de réécrire la configuration du programme d’un client. L’avis de Switchboard exhortait les utilisateurs à migrer parce que les propriétaires d’intégration doivent agir. Les projets devraient être évalués selon les adresses et les mises à jour de comptes qu’ils contrôlent. Si une application est déjà passée à Pyth avant le 19 septembre, la date limite de support ultérieure n’a pas d’effet direct sur ce marché. Si elle sélectionne encore un flux Switchboard et n’a pas de solution de secours fonctionnelle, le comportement du flux après le 25 septembre est le problème concret.

L’interprétation opposée la plus solide de l’alerte d’arrêt découle de la note de septembre de marginfi et de la sauvegarde documentée de Jito. Les applications peuvent concevoir une redondance ou anticiper la sortie d’un fournisseur ; le code et les documents montrent des mécanismes pour ce faire. Le modèle à la demande de Switchboard peut laisser une partie de l’infrastructure de flux fonctionner indépendamment même si le contributeur principal a cessé son support. L’avis n’a pas publié de calendrier vérifié auquel chaque compte s’arrêterait, et nous n’avons trouvé aucune preuve primaire établissant une telle coupure universelle.

Il existe un autre type de question de continuité pour un protocole qui a mis en place son propre repli. Un prix de secours peut empêcher un arrêt total tout en évaluant un actif moins fréquemment ou avec un ensemble de sources différent. Pour un processus de distribution de récompenses, un poids de secours temporaire peut maintenir la comptabilité des époques en mouvement, bien que l’allocation puisse alors dépendre des hypothèses du secours. Pour un marché de prêt, le repli pourrait modifier le prix utilisé dans un contrôle de santé. Il ne s’agit pas d’affirmations sur les paramètres actuels de Jito ou de marginfi. Elles montrent ce qu’un mainteneur doit divulguer avant que les utilisateurs puissent juger si une migration est complète en termes opérationnels, et pas seulement si les transactions s’exécutent encore.

Un arrêt progressif de fournisseur peut aussi avoir des effets différés. Un code écrit pour demander des prix à la demande peut réussir tant qu’une passerelle indépendante répond, puis échouer lorsque 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 à la date limite, et non d’une seule transaction réussie, pour en déduire la continuité du service. La même discipline s’applique à une transaction échouée : l’erreur d’un utilisateur peut provenir d’un SDK obsolète ou d’une entrée de compte insuffisante plutôt que d’un oracle indisponible. Le document de migration de Marginfi fournit un exemple explicite d’un échec de décodage logiciel qui pourrait autrement être étiqueté à tort comme une panne d’oracle.

Cette assurance a une limite. Un repli décrit neuf mois plus tôt doit être validé par rapport à l’état actuel, et une option de migration décrite en septembre ne prouve pas que chaque banque l’a adoptée. Les deux documents fournissent des raisons crédibles de ne pas présumer une catastrophe, tout en laissant un écart mesurable. La conclusion équitable est plus étroite que les versions promotionnelle et alarmiste : les documents publics identifient des dépendances candidates et des voies de secours ; un audit actuel de la configuration marché par marché est nécessaire pour établir toute exposition restante.

L'inventaire en direct reste le document manquant

Le reportage original ici compare la liste de Switchboard de quatre intégrateurs prominents avec les documents primaires actuels de Jito, marginfi et Kamino. Il en résulte deux constatations documentaires vérifiées. La documentation plus ancienne de Jito sur Tip Router nomme Switchboard pour la tarification des coffres et un recours pour les flux indisponibles. La note de marginfi de septembre 0.1.11 décrit neuf nouvelles configurations indépendantes de Switchboard et avertit d'une rupture distincte du SDK si les intégrateurs ne mettent pas à jour. Le dépôt Scope de Kamino explique pourquoi une simple étiquette d'agrégateur ne peut pas identifier toutes les sources de données en amont.

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

Un décompte approprié utiliserait le marché comme ligne, et non le protocole. Pour chaque banque de prêt active, marché de produits dérivés ou coffre de récompenses, l'auditeur enregistrerait son adresse de programme, le type d'oracle sélectionné, le compte d'oracle, la source de secours 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 particulier. Les marchés en double qui partagent un même compte d'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 recours. L'horodatage de la configuration du marché importe car un administrateur pourrait modifier un flux après l'observation.

Cette méthode explique pourquoi même une affirmation vraie telle qu'un protocole ayant pris en charge 550 flux dans le passé est insuffisante pour la question présente. Un flux peut exister sans emprunteur actif, peut avoir une mise à jour de prix sans marché consommateur, ou peut être référencé uniquement dans du code dormant. Un décompte des comptes de flux mesure l'infrastructure. Un décompte des marchés configurés mesure la dépendance. Un décompte des positions et des garanties touchant réellement ces marchés mesure l'exposition économique. Aucun n'est interchangeable avec le total des actifs déposés dans tous les produits gérés par un projet.

Il existe une étape de vérification supplémentaire lorsqu'une source est un agrégateur. Le consommateur peut identifier un compte Scope et un indice d'entrée, tandis que le mappage 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 de la source pour cette mise à jour. Le dépôt de Kamino note que les étiquettes de paires de jetons ne sont pas entièrement stockées onchain, de sorte qu'une configuration externe ou une documentation de maintenance peut être nécessaire pour mapper un indice à son actif. Lorsque ce mappage est indisponible, le résultat doit être enregistré comme inconnu, et non silencieusement attribué à Pyth ou Switchboard.

Ce qu'il faut surveiller

• Adresses d'oracle de marché : Comparez le flux configuré de chaque banque ou coffre actif avec les comptes Switchboard documentés.
• Horodatages de mise à jour des prix : Vérifiez si un flux identifié continue à publier des valeurs fraîches après le 25 septembre.
• Configuration de recours : Recherchez la source et la limite de fraîcheur utilisées si un flux principal prend du retard.
• Transactions récentes du programme : Vérifiez si l'emprunt, le règlement ou la distribution des pourboires se termine encore pour le marché concerné.
• Mises à jour datées des mainteneurs : Recherchez une migration nommée, une pause de marché ou une dépendance restante, soutenue par une adresse de compte ou de programme.

Enregistrez l'heure d'observation pour chaque vérification ; une capture d'écran sans bloc ou horodatage peut rapidement devenir obsolète.

La note de mise à jour de marginfi indique qu'une banque utilisant une nouvelle valeur d'énumération d'oracle peut faire échouer un SDK plus ancien à initialiser son client, même si un utilisateur n'interagit pas avec cette banque particulière. L'instruction d'utiliser la version 2.8.0 ou ultérieure du SDK a été publiée avant le début de la migration du 4 septembre, trois semaines avant la date limite de support de Switchboard.

FAQ