Fin Du Support Oracle Switchboard Sur Solana Aujourd’hui

Et si le vrai risque n’était pas la fin d’un prestataire, mais l’illusion qu’un logo sur une page d’accueil prouve encore qu’un marché lit ce prix ? Aujourd’hui, 25 septembre 2026, le support technique de Switchboard arrive à l’échéance annoncée six jours plus tôt. Sur Solana, des protocoles de prêt, de distribution de pourboires et d’agrégation de cours ont longtemps cité cet oracle. La question qui compte n’est plus « qui a déjà intégré le service », mais « qui, à cette minute, configure encore un compte Switchboard dans un programme vivant ».

Ce Que Change Vraiment La Fin Du Support

Un oracle n’est pas un simple widget de cours. C’est le thermomètre d’un système qui décide si une position est saine, si un coffre pèse assez lourd dans une répartition, si un emprunteur peut encore tirer de la liquidité. Quand l’équipe qui maintenait le service dit qu’elle se retire, le réseau ne s’éteint pas comme un interrupteur. Les comptes onchain restent. Des opérateurs indépendants peuvent encore pousser une mise à jour. Une application peut déjà avoir basculé vers Pyth, RedStone ou un agrégateur interne. Une autre peut afficher une documentation de neuf mois et un état réel tout autre.

Le 19 septembre 2026, Switchboard Technology Labs a indiqué qu’elle mettait fin à son activité de contributeur principal. Les implémentations étaient décrites comme dépréciées immédiatement. Le 25 septembre était présenté comme le dernier jour de support existant. Les intégrateurs étaient invités à migrer. Cette phrase d’entreprise est un jalon opérationnel. Elle ne prouve pas qu’à minuit tous les flux se sont figés, ni que chaque protocole historiquement associé reste exposé.

Une date de fin de support mesure l’engagement d’une équipe. Elle ne mesure pas, à elle seule, la fraîcheur d’un compte de prix sur une blockchain.

Lecture prudente d’un avis de fermeture

Trois Couches De Preuve Qu’Il Faut Séparer

La première couche est marketing. Une page d’introduction qui nomme Kamino, Jito, marginfi et Drift raconte qu’une relation commerciale ou technique a existé. C’est utile pour retracer l’histoire. Ce n’est pas un inventaire du 25 septembre.

La deuxième couche est la configuration supportée. Un SDK, une table d’oracles, un dépôt GitHub montrent ce qu’un programme sait lire. Un type peut rester dans le code longtemps après que le dernier marché a changé d’adresse.

La troisième couche est l’état vivant : compte oracle choisi, horodatage de la dernière mise à jour, règle de fraîcheur, source de repli, valeur réellement adossée à ce prix. Seule cette couche autorise une phrase du type « ce marché dépend encore de Switchboard aujourd’hui ». Sans elle, on fait de l’arithmétique inversée à partir d’une TVL globale.

Pourquoi Un Feed Stale N’A Pas Un Seul Effet

Dans un marché de prêt, un prix trop vieux peut faire échouer une action si le programme refuse la donnée. Il peut aussi laisser passer une opération contre un cours déconnecté du marché si la règle de fraîcheur est trop large. Un repli peut maintenir l’ouverture du marché tout en changeant le rythme de mise à jour ou le niveau de confiance. Rien de tout cela n’est automatique. C’est le code consommateur qui décide.

Dans un système de pondération de vaults, comme celui décrit pour le Tip Router de Jito, un feed indisponible n’équivaut pas forcément à une liquidation de collatéral. La documentation publique parle de poids de secours. La gravité n’est donc pas la même que celle d’une banque de lending qui valorise une garantie. Ranger tous les « utilisateurs d’oracle » dans une seule liste de danger, c’est confondre des métiers différents.

Il existe encore un autre scénario, souvent oublié : le feed continue d’être mis à jour par des opérateurs qui n’appartiennent plus à la société. Le modèle à la demande de Switchboard, où une application crée ou appelle la donnée dont elle a besoin, peut laisser une infrastructure partielle en vie. Une transaction réussie après la date n’est alors ni une preuve de continuité durable, ni une preuve d’abandon. Il faut plusieurs horodatages, pas un seul cliché.

Jito : Une Documentation Qui Nomme Encore Le Feed

Les pages du Tip Router de la Jito Foundation décrivent un programme onchain, un client d’opérateur de nœud et un cranker permissionless. Dans ce dispositif, Switchboard apparaît comme source de pondération relative d’actifs détenus dans des vaults liés au routeur, notamment des unités comme JitoSOL et JTO. Le rôle documenté est précis : aider à calculer des poids pour une logique de distribution et de restaking, pas noter la santé d’un emprunteur au sens d’un protocole de lending classique.

Le même corpus évoque des poids de secours lorsque les feeds ne sont pas disponibles. Cette phrase change la lecture alarmiste. Elle n’exonère personne. Elle oblige à poser des questions concrètes : quelles valeurs de repli, quelles conditions d’activation, quels comptes oracle réellement lus ce 25 septembre ? Une page mise à jour il y a neuf mois établit un dessin d’architecture. Elle n’établit pas la configuration actuelle.

Des notes de versions publiques du dépôt Tip Router mentionnent aussi des tentatives de nouvelle interrogation des passerelles oracle Switchboard côté keepers. Du code qui contient encore cette logique prouve une intégration technique. Il ne prouve pas que chaque vault porteur de valeur dépend encore de ce chemin. Un chemin de compatibilité peut survivre des mois dans un binaire après que les comptes vivants ont basculé.

Compter un logo Jito comme une exposition totale, c’est traiter une pondération de récompenses comme une règle de liquidation.

Distinction de chemins de défaillance

La lecture honnête est donc étroite. Jito a documenté Switchboard pour un usage de prix de vaults, avec un mécanisme de repli décrit. Sans inspection d’état de programme, sans déclaration récente de l’équipe, la dépendance live reste non vérifiée. Ce n’est pas une absolution. C’est le refus de transformer une page vieillie en bilan de risque.

Marginfi : Une Sortie Documentée, Pas Un Bilan Complet

Chez marginfi, la table des oracles conserve encore des variantes de type SwitchboardPull parmi les montages possibles. Elle précise qu’un appelant doit « crank » un feed pull juste avant usage. La même table liste des feeds poussés Pyth et des comptes Scope. Un lecteur pressé peut prendre la ligne Switchboard pour la preuve que chaque banque du protocole l’utilise encore. La table décrit des types supportés, pas le recensement des banques du jour.

La note de programme 0.1.11 est plus récente et plus parlante. Elle demandait aux développeurs de passer au SDK en version 2.8.0 au minimum avant le 4 septembre, date à partir de laquelle les banques commenceraient à migrer vers de nouveaux montages. Neuf variantes indépendantes de Switchboard y sont décrites, dont des feeds Kamino Scope et des prix fondés sur un taux de change pour certains jetons de staking liquide et certains jetons de principal. Le texte ne dit pas que toutes les banques avaient fini le 25. Il dit qu’une voie de sortie a été publiée avant l’annonce de fermeture.

Cette migration porte un second mode de panne, presque contre-intuitif. Un ancien SDK ne sait pas décoder une banque configurée avec l’une des nouvelles valeurs d’énumération. Une seule banque au format nouveau peut faire échouer l’initialisation du client et la lecture des banques, pas seulement l’action qui touche cette banque. Changer d’oracle peut donc soigner une dépendance d’infrastructure et casser un intégrateur qui n’a pas mis à jour son logiciel. La documentation dit comment éviter le piège. Elle n’est pas la preuve qu’un utilisateur nommé l’a subi.

Kamino Scope : Un Agrégateur N’Est Pas Une Étiquette De Fournisseur

Le dépôt public Scope de Kamino Finance décrit un agrégateur onchain qui copie des valeurs depuis plusieurs comptes oracle vers un feed unique, puis valide les mises à jour selon des règles préréglées. Un feed peut porter jusqu’à 512 prix. L’association entre un index et une paire de jetons n’est pas entièrement stockée onchain. Un programme aval peut donc pointer vers Scope pendant que Scope lui-même s’appuie, pour l’actif choisi, sur d’autres sources.

Voir Scope dans la configuration d’une banque est un point de départ, pas une conclusion. La note de septembre de marginfi présente Scope comme une option qui, dans le montage nouveau décrit, ne dépend pas de Switchboard. Cela n’implique pas que chaque déploiement de Scope, à chaque date, exclut toute source Switchboard. Un agrégateur change ses entrées. Un audit sérieux lit à la fois le compte Scope choisi par le consommateur et la cartographie des sources qui peuplent l’entrée.

Kamino a continué d’accueillir des acteurs institutionnels sur son écosystème de prêt. L’ouverture de coffres stablecoins par Galaxy en septembre rappelle pourquoi nommer « tout le protocole » comme exposé, sans regarder chaque actif, est une faute de méthode. Un coffre USDC, une réserve de jeton de staking liquide et un marché d’action tokenisée peuvent emprunter des chemins d’oracle différents. Rien n’a été vérifié ici sur l’usage éventuel de Switchboard par ces coffres Galaxy. Ils n’entrent donc pas dans un décompte de positions touchées.

Drift Et Les Listes Anciennes : Le Piège Du Catalogue

Drift apparaît dans le matériel d’introduction de Switchboard aux côtés des trois autres noms. Cette mention historique ne dit rien de la répartition actuelle de l’exposition. Un projet peut n’utiliser un oracle que pour un marché, le garder en secours, ou conserver du code après avoir changé les feeds live. L’unité d’analyse défendable est un marché ou un vault précis, avec son feed configuré à un instant daté.

Project 0 a décrit une marge unifiée à travers des places Solana, dont Kamino et Drift. Les interfaces transversales ajoutent une couche où une migration d’oracle doit être lue correctement par plusieurs logiciels. L’avertissement SDK de marginfi est une preuve concrète d’aléa d’intégration. Ce n’est pas la preuve d’une panne chez Project 0 ni chez Drift. Un audit responsable vérifierait versions logicielles et configurations de banques avant de parler d’indisponibilité.

Le financement de 7,5 millions de dollars levé par Switchboard en mai 2024 éclaire l’histoire de la société. Il ne mesure pas l’exposition protocolaire d’aujourd’hui. Le chiffre pertinent serait le nombre et la valeur des marchés dont le calcul de risque prend encore une donnée d’un feed désormais difficile à maintenir. Ce chiffre ne se déduit pas d’un logo client.

Qui Porte Le Travail De Migration

L’opérateur d’oracle publie ou coordonne une donnée. Le protocole consommateur choisit le compte que son programme lit et les limites qu’il pose sur ce prix. Dans un protocole de prêt, changer les adresses d’oracle d’un marché relève souvent de la gouvernance ou d’un administrateur. Les fronts et les intégrateurs tiers doivent ensuite construire des transactions avec les bons comptes additionnels. L’utilisateur final, lui, ne voit parfois qu’un emprunt rejeté ou un marché en pause, longtemps après les décisions techniques.

Une société qui cesse le support n’a pas forcément le pouvoir de réécrire la configuration d’un programme client. L’avis de Switchboard pressait les utilisateurs de migrer précisément parce que les propriétaires d’intégration doivent agir. Si une application avait déjà basculé vers Pyth avant le 19 septembre, l’échéance du 25 n’a pas d’effet direct sur ce marché. Si elle sélectionne encore un feed Switchboard sans repli opérationnel, le comportement de ce feed après la date devient le sujet concret.

Pyth a multiplié les annonces de distribution de données, y compris des partenariats de marché actions. RedStone a été cité parmi les destinations de migration. Ces noms ne sont pas des garanties magiques. Ils sont des alternatives industrielles. Un protocole peut aussi construire de la redondance interne. Les documents de marginfi et le repli décrit chez Jito montrent que des équipes anticipent un départ de fournisseur. Anticiper n’est pas terminer.

Slots Plus Courts, Prix Pas Magiques

Le passage de Solana vers des slots de l’ordre de 250 millisecondes accélère la production de blocs. Il n’oblige pas une source de prix externe à publier. Un slot plus rapide peut transporter plus tôt un cours quand ce cours existe. Il ne fabrique pas un cours quand le nœud qui le fournit s’arrête. Un test de fraîcheur peut se mesurer en slots, en secondes ou selon une autre règle. Changer l’horloge du réseau peut donc modifier la façon dont on interprète une vieille configuration de feed, sans résoudre l’absence de donnée.

Cette remarque technique évite un raccourci fréquent : croire que la performance de la chaîne compensera une rupture de fournisseur. La chaîne transporte. L’oracle atteste un monde extérieur. Les deux rythmes peuvent diverger. Un marché qui accepte une donnée trop ancienne sur une chaîne très rapide n’est pas « plus sûr ». Il est simplement plus vite capable d’agir sur une information douteuse.

Ne Pas Transformer Une Analogie En Incident

Un incident d’oracle sans lien direct a entraîné des liquidations sur Vesu plus tôt en septembre. L’épisode rappelle qu’un mauvais prix a des effets économiques. Il n’est pas une preuve d’incident chez Switchboard, Jito ou marginfi. Un avis de fermeture ne doit pas devenir une allégation de liquidation par analogie. Le signe d’un événement réel serait un horodatage de compte périmé, des transactions échouées, une pause de protocole ou des pertes identifiées. Rien de tel n’a été établi ici pour l’échéance du 25 septembre.

D’autres anomalies de pricing, sur d’autres chaînes et d’autres produits dérivés, ont déjà montré qu’une impression de marché erronée relayée par un oracle peut provoquer des liquidations forcées. Ces souvenirs collectifs chauffent le débat. Ils ne remplacent pas une observation datée sur Solana. La discipline de preuve reste la même : marché par marché, compte par compte.

Un précédent d’oracle ailleurs n’est pas un procès-verbal d’incident ici. L’analogie éclaire le risque. Elle n’écrit pas le constat.

Règle de méthode

Comment Compter Sans Se Mentir

La bonne grille n’est pas le protocole, c’est le marché. Pour chaque banque de prêt active, chaque marché dérivé, chaque vault de récompense, on enregistre l’adresse de programme, le type d’oracle choisi, le compte oracle, la source de secours s’il y en a une, la dernière mise à jour réussie, l’âge maximal permis et la valeur des positions qui dépendent réellement de ce prix. Deux marchés qui partagent un même compte ne font pas deux feeds distincts. Un marché qui lit deux oracles indépendants n’est pas « entièrement » dépendant de l’un sans lecture de sa logique de repli.

Un feed peut exister sans emprunteur actif. Un prix peut se mettre à jour sans marché consommateur. Un compte peut n’être plus référencé que dans du code dormant. Compter des comptes de feeds mesure une infrastructure. Compter des marchés configurés mesure une dépendance. Compter des positions et des garanties qui touchent ces marchés mesure une exposition économique. Ces trois nombres ne sont pas interchangeables avec le total des dépôts d’un projet.

Quand la source est un agrégateur, une mise à jour du compte Scope après le 25 septembre prouve qu’un agrégateur a produit une valeur. Elle ne prouve pas, à elle seule, que Switchboard a fourni le sous-jacent. Il faut l’entrée sélectionnée et la configuration de source de cette mise à jour. Si l’étiquette de paire n’est pas entièrement onchain, la cartographie peut exiger une documentation de mainteneur. Là où la cartographie manque, le résultat doit rester « inconnu », pas attribué par habitude à Pyth ou à Switchboard.

• Adresses oracle des marchés : comparer le feed configuré aux comptes Switchboard documentés.
• Horodatages de prix : voir si un feed identifié publie encore après le 25 septembre.
• Repli : noter la source et la limite de fraîcheur si le primaire décroche.
• Transactions récentes : vérifier emprunts, dénouements ou distribution de tips.
• Notes datées des mainteneurs : migration nommée, pause, dépendance restante, avec adresse.

Chaque contrôle doit porter son heure d’observation. Une capture d’écran sans bloc ni tampon vieillit en quelques minutes. C’est banal. C’est aussi la raison pour laquelle un article du matin ne peut pas clore le dossier du soir.

Ce Que Les Documents Permettent De Dire Aujourd’hui

Deux constats documentaires tiennent. La documentation plus ancienne du Tip Router de Jito nomme Switchboard pour le pricing de vaults et décrit un repli. La note de septembre de marginfi décrit neuf montages indépendants de Switchboard et prévient d’une rupture SDK si les intégrateurs n’upgradent pas. Le dépôt Scope de Kamino explique pourquoi une étiquette d’agrégateur ne révèle pas toutes les sources amont.

Ces pages ne livrent ni un décompte de feeds non migrés, ni un montant de fonds exposés, ni la preuve d’une panne chez un protocole nommé. Elles n’offrent pas non plus un instantané synchronisé, au 25 septembre, de tous les comptes oracle, des dernières mises à jour réussies, des réglages de repli et des encours adossés à chaque marché. Afficher un total en dollars à partir de la TVL d’un protocole serait indéfendable, parce que tous les actifs d’un projet ne partagent pas le même oracle.

Questions Fréquentes Sans Fausse Assurance

Quand le support devait-il s’arrêter ? L’annonce date du 19 septembre 2026. Le 25 septembre était présenté comme la fin du support technique existant. Les implémentations étaient décrites comme dépréciées tout de suite.

Tous les feeds se sont-ils arrêtés ce jour-là ? L’échéance de support ne l’établit pas. Il faut des horodatages de transactions et de comptes.

Jito utilise-t-il encore Switchboard ? La documentation du Tip Router le nomme encore pour le pricing de vaults, avec un aperçu marqué comme vieux de neuf mois au moment du contrôle. Ces pages ne prouvent pas la configuration live du 25 septembre.

Marginfi a-t-il quitté Switchboard ? La mise à jour de septembre documente neuf montages qui n’en dépendent pas et indique un début de mouvement au 4 septembre. Elle n’affirme pas que chaque banque a terminé.

Pourquoi une migration d’oracle peut-elle casser un SDK ? Parce que de nouvelles valeurs d’énumération ne sont pas reconnues par d’anciens clients. Une banque au nouveau format peut faire échouer l’initialisation. La version 2.8.0 ou supérieure est présentée comme le seuil de compatibilité.

Scope est-il indépendant de tout oracle externe ? Non. Scope agrège. Sa présence chez un consommateur n’identifie pas chaque source amont sans la cartographie de l’entrée.

Des pertes ont-elles été vérifiées du fait de cette fermeture ? Non, pas pour un protocole nommé dans cette analyse. Un incident ailleurs ne prouve pas un incident ici. Il s’agit d’un texte éducatif, pas d’un conseil d’investissement.

Ce Qu’Un Utilisateur Peut Vérifier Sans Se Prendre Pour Un Auditeur

On peut lire les annonces de gouvernance et les notes de version datées, plutôt que les pages « partenaires » figées. On peut regarder si une interface prévient d’une pause de marché ou d’un changement d’oracle. On peut, si l’on sait lire un explorateur, comparer l’adresse de feed d’un marché que l’on utilise avec les comptes historiquement associés à Switchboard, puis regarder l’âge de la dernière écriture. On peut surtout refuser le raccourci « ce protocole a X milliards, donc X milliards sont en danger ».

Les intégrateurs, eux, ont une liste plus sèche : version de SDK, comptes additionnels exigés par le nouveau type d’oracle, besoin éventuel de crank avant usage, comportement du client si une seule banque du set a basculé. Le cas marginfi montre qu’un oubli logiciel peut ressembler à une panne d’oracle. Confondre les deux fait perdre du temps et crée de fausses alertes.

Les mainteneurs de protocoles ont, de leur côté, un devoir de clarté. Un repli décrit il y a neuf mois doit être validé contre l’état présent. Une option de migration publiée en septembre n’est pas la preuve que chaque banque l’a prise. Discloser le marché, le compte, la date, le repli, voilà le minimum pour qu’un utilisateur juge si la migration est opérationnelle, et pas seulement si les transactions passent encore.

Une Leçon Plus Large Pour La DeFi Solana

Les oracles sont devenus une commodité de discours. On les range dans une slide, à côté des audits et des assurances. Le départ d’un fournisseur rappelle qu’ils restent une dépendance d’exploitation. Le modèle pull, le modèle push, l’agrégateur interne, le taux de change d’un jeton de principal : chaque choix déplace le travail. Tantôt c’est l’intégrateur qui doit crank. Tantôt c’est l’infrastructure du fournisseur qui pousse. Tantôt c’est un compte intermédiaire qui recopie.

La fragmentation des sources n’est pas un défaut en soi. Elle devient un défaut quand personne ne tient le plan de câblage. Un protocole multi-venues, une marge unifiée, un vault institutionnel nouveau : plus le graphe s’épaissit, plus une étiquette unique « oracle X » perd de sens. Le 25 septembre 2026 n’invente pas ce problème. Il le rend visible, parce qu’une équipe a mis une date sur son retrait.

Il restera des effets retardés possibles. Un chemin à la demande peut réussir tant qu’une passerelle indépendante répond, puis échouer lorsque cette passerelle est éteinte ou lorsqu’un actif précis n’est plus tenu à jour. Observer plusieurs timestamps après l’échéance vaut mieux qu’une transaction isolée. La même discipline s’applique à un échec : l’erreur d’un utilisateur peut venir d’un SDK périmé ou d’un compte manquant, pas d’un oracle mort.

Le marché aime les récits binaires, catastrophe ou rien. Les documents publics de ce dossier racontent autre chose : des candidats à la dépendance, des échappatoires écrites, un inventaire live encore absent. C’est moins spectaculaire. C’est plus proche de la façon dont les systèmes se cassent vraiment, par petits décalages entre la page, le code et le compte.

Cette analyse s’appuie sur des textes disponibles au 25 septembre 2026. Les configurations onchain bougent. Une phrase vraie ce matin peut être fausse ce soir si un administrateur change un feed. C’est précisément pourquoi l’unité de vérité n’est pas le communiqué, mais le marché nommé, à une heure nommée, avec un compte nommé.

Informations à caractère éducatif uniquement. Rien ici n’est une recommandation d’achat, de vente ou de conservation. Les chiffres et documents évoluent à chaque nouvelle publication. Faire ses propres vérifications reste la seule méthode sérieuse.