Scadenza del supporto Switchboard: i protocolli Solana devono verificare le dipendenze oracle attive

La scadenza del supporto di Switchboard fissata per il 25 settembre ha trasformato un avviso di migrazione di sei giorni in una prova per i feed di prezzo di Solana. La documentazione pubblica mostra dove l'oracle fa ancora parte del progetto di un'applicazione, ma quelle pagine non possono dimostrare che un mercato attivo stia ancora utilizzando il feed. Jito e marginfi offrono due quadri molto diversi della potenziale esposizione.

Switchboard ha raggiunto la dichiarata fine del supporto tecnico del 25 settembre, lasciando alle applicazioni Solana il compito di verificare le fonti di prezzo configurate nei loro programmi attivi.

La dichiarazione del 19 settembre del progetto oracle, come riportata nella copertura dell'annuncio, ha affermato che il suo principale contributore allo sviluppo, Switchboard Technology Labs, avrebbe cessato le attività e che tutte le implementazioni erano state deprecate immediatamente. Il team ha invitato gli integratori a migrare verso altri fornitori, citando Pyth e RedStone. Il 25 settembre è stato descritto come l'ultimo giorno di supporto esistente.

La fine del supporto tecnico è una vera pietra miliare operativa. Non dimostra, di per sé, che ogni feed on-chain abbia smesso di aggiornarsi a mezzanotte o che ogni applicazione un tempo associata a Switchboard ne sia rimasta dipendente.

La documentazione stessa di Switchboard ha citato Kamino, Jito, marginfi e Drift come utenti. Si tratta di affermazioni storiche di integrazione da parte di un fornitore che vendeva un servizio oracle, non di un inventario in tempo reale dei feed attivi al 25 settembre. La documentazione attuale di ciascun progetto presenta un quadro più complesso. Le pagine del Tip Router di Jito descrivono ancora Switchboard nel loro flusso di pricing, mentre l'aggiornamentoico di settembre di marginfi aggiunge percorsi progettati per evitare tale dipendenza. Un documento può essere obsoleto mentre un altro anticipa una migrazione. Nessuno dei due sostituisce un'ispezione della configurazione attiva degli account.

Il precedente round di finanziamento di Switchboard fu di 7,5 milioni di dollari a maggio 2024. Tale cifra fornisce un contesto sulla storia dell'impresa, ma non misura l'esposizione attuale del protocollo. La cifra rilevante è il numero e il valore dei mercati attivi i cui calcoli di rischio utilizzano ancora dati di un feed che non può essere aggiornato in modo affidabile. Tale cifra non può essere dedotta dal logo di un cliente.

Un'integrazione elencata non è un feed attivo

L'introduzione pubblica di Switchboard descrive feed on-demand: le applicazioni creano o richiamano i dati di cui hanno bisogno, e un prezzo viene reso disponibile tramite account Solana. La documentazione può identificare dove un protocollo sa come leggere un feed Switchboard, ma può non identificare quale opzione un determinato mercato seleziona attualmente. Un kit di sviluppo software può supportare un tipo di oracle molto dopo che l'ultimo banco vi ha rinunciato. Al contrario, un sito web può cambiare mentre una riserva attiva conserva il suo account oracle più datato.

Tre livelli di evidenza vanno tenuti separati. Il primo è una pagina di marketing o di integrazione, che dimostra che una relazione esisteva. Il secondo è la configurazione supportata da un programma, visibile nella documentazione tecnica o nel codice. Il terzo è la configurazione attiva e la cronologia degli aggiornamenti recenti del mercato reale. Solo il terzo può supportare l'affermazione che un determinato mercato dipendesse ancora da Switchboard in un dato momento. Anche allora, può essere configurata una fonte di backup, quindi l'effetto dell'arresto di un feed primario va verificato rispetto alla regola di fallback e freschezza pertinente.

La documentazione del protocollo di marginfi conserva SwitchboardPull e le varianti venue tra le configurazioni oracle disponibili. Indica che il chiamante deve azionare (crank) un feed pull di Switchboard immediatamente prima dell'uso. La stessa tabella elenca i feed push di Pyth e gli account Scope come altre configurazioni. La presenza continuativa della riga Switchboard non è prova che ogni banco marginfi lo utilizzi ancora; la tabella descrive i tipi supportati, non un elenco completo di quale banco usi quale feed oggi.

La nota separata sul Program 0.1.11 di marginfi è più recente e specifica. Ha istruito gli sviluppatori ad aggiornare l'SDK almeno alla versione 2.8.0 prima del 4 settembre, indicando che i banchi avrebbero iniziato a spostarsi verso nuove configurazioni oracle da quella data. La release ha aggiunto nove varianti che non dipendono da Switchboard, inclusi i feed Kamino Scope e il pricing basato su tassi di cambio per alcuni token di liquid staking e principal token.

La nota non afferma che ogni banco avesse completato la migrazione entro il 25 settembre. Mostra però che marginfi ha documentato pubblicamente una via d'uscita dalla dipendenza minacciata prima dell'annuncio dello shutdown.

La migrazione ha introdotto una seconda possibile modalità di guasto. Marginfi afferma che gli SDK più vecchi non possono decodificare un banco configurato con uno dei nuovi valori enum dell'oracle. Un singolo banco con un valore non supportato può impedire Project0Client.initialize e le letture dei banchi, anziché limitarsi a un'azione che coinvolge quel banco. Modificare un oracle può quindi risolvere una dipendenza infrastrutturale mentre si rompe un integratore che non ha aggiorn il proprio software. Il documento di marginfi spiega come gli integratori possono evitare il problema dell'SDK; non è prova che un utente specifico lo abbia subito.

Project 0 ha descritto il margine unificato tra le venue Solana, incluse Kamino e Drift. Le interfacce cross-protocollo creano un ulteriore livello in cui una migrazione oracle deve essere valutata. L'avviso sulle versioni SDK precedenti è evidenza concreta di un rischio di integrazione, ma non dimostra un guasto in Project 0 o in qualsiasi altra applicazione citata. Un audit responsabile verificherebbe le versioni software e le configurazioni attive dei banchi di prestito prima di dichiarare un disservizio.

Il Tip Router di Jito documenta ancora Switchboard

La panoramica del Tip Router della Jito Foundation afferma che Switchboard determina il peso relativo di asset come JitoSOL e JTO detenuti nei vault collegati al Tip Router. La panoramica identifica un programma Tip Router on-chain, un client per gli operatori di nodo e un cranker permissionless. La sua documentazione di pricing indica Switchboard come feed oracle attuale e descrive pesi di backup quando i feed non sono disponibili.

I documenti collocano Switchboard in un ruolo specifico: la determinazione del prezzo degli asset dei vault per i calcoli dei pesi in un sistema di distribuzione delle mance e di restaking. Non affermano che un feed Switchboard non disponibile liquiderebbe automaticamente una posizione di prestito su Solana. La pagina di pricing di Jito descrive un meccanismo di fallback, indebolendo l'affermazione semplicistica che la fine del supporto fermerebbe necessariamente tutte le operazioni del Tip Router. I valori esatti di fallback, le condizioni di attivazione e gli account oracle attivi attuali richiedono comunque una verifica dello stato attuale del programma.

La panoramica del Tip Router mostrava un indicatore di ultimo aggiornamento di nove mesi prima al momento della verifica del 25 settembre. Quella data limita l'uso della pagina. Stabilisce un progetto documentato e identifica dove indirizzare una domanda tecnica, ma non può stabilire che il programma attuale abbia la stessa configurazione dei feed. Jito può aver aggiornato gli account on-chain senza revisionare la pagina, oppure può ancora usare Switchboard con un fallback. Senza un'ispezione recente delle transazioni o una dichiarazione attuale di Jito, una dipendenza attiva nominata resta non verificata.

Le note di rilascio pubbliche su GitHub di Jito per il Tip Router si riferiscono al tentativo ripetuto di raggiungere i gateway oracle di Switchboard nelle operazioni keeper. Una codebase contenente tale logica dimostra un'integrazione tecnica, non necessariamente una dipendenza di ogni vault al momento della pubblicazione. Il codice può preservare un percorso di compatibilità per mesi. La domanda attuale è se le recenti transazioni di aggiornamento dei prezzi puntino a un account Switchboard utilizzato da un vault che detiene ancora valore, e se quell'account avanzi dopo la scadenza del supporto.

La distinzione viene spesso persa quando tutti gli utenti di un oracle vengono inseriti in un unico elenco. Il calcolo descritto da Jito influisce sui pesi relativi degli asset in un sistema di distribuzione. Il calcolo di un mercato di prestito determina il valore del collaterale e la salute del mutuatario. Entrambi consumano dati di prezzo, ma i loro percorsi di guasto differiscono. Un audit che conta i loghi assegnerebbe la stessa gravità a usi fondamentalmente diversi.

Lo Scope di Kamino è un aggregatore, non un'etichetta di fornitore

Il repository pubblico Scope di Kamino Finance descrive un aggregatore on-chain che copia i valori da più account oracle in un unico feed di prezzo e valida gli aggiornamenti secondo regole predefinite. Il suo README afferma che un feed supporta fino a 512 prezzi e che l'associazione tra un indice e una coppia di token non è interamente memorizzata on-chain. Un programma a valle può puntare a Scope mentre Scope stesso si affida ad altri feed per l'asset selezionato. Ved Scope in una configurazione di banco è quindi un punto di partenza per risalire alla reale fonte dei dati, non un punto d'arrivo.

La nota di settembre di marginfi elenca Scope come opzione che non dipende da Switchboard per la nuova configurazione che descrive. Questo non significa che ogni distribuzione di Scope in ogni data escluda ogni fonte Switchboard. Un aggregatore può cambiare i suoi input sottostanti. Un controllo completo delle dipendenze richiede sia l'account Scope selezionato dal consumatore sia la mappatura delle fonti usata per popolare la sua voce. Il repository di Kamino fornisce l'architettura, non un inventario con timestamp delle fonti mainnet attuali per ogni applicazione.

Kamino ha continuato a portare istituzioni nel suo ecosistema di prestito. Galaxy ha aperto due vault in stablecoin sulla piattaforma a settembre. L'esistenza di nuovi vault mostra perché definire un intero protocollo come esposto senza verificarne i singoli asset sarebbe infondato. Un vault USDC, una riserva in liquid staking token e un mercato azionario tokenizzato possono usare percorsi oracle diversi. I vault di Galaxy non sono stati verificati come utenti di Switchboard, quindi non sono inclusi nel conteggio delle posizioni interessate.

Analogamente, il precedente elenco di Kamino, Jito, marginfi e Drift nel materiale introduttivo di Switchboard non mostra come l'esposizione fosse distribuita tra loro. Un progetto può usare un oracle per un solo mercato, usarlo come fallback o conservare codice dopo aver cambiato i feed attivi. L'unica unità di analisi difendibile è un mercato o vault specifico e il suo feed configurato in un momento specificato. Senza tale unità, le affermazioni sui fondi a rischio sono aritmetica di marketing applicata a ritroso.

Un feed obsoleto può avere più di un effetto

La conseguenza tecnica di un feed che resta indietro dipende dal protocollo consumatore. Un programma di prestito generalmente necessita di un prezzo per determinare il valore del collaterale e la capacità di prestito. Se rifiuta un valore obsoleto, un'azione può fallire o un mercato può fermarsi secondo le sue regole. Se accetta dati non aggiornati, un mutuatario potrebbe transare a un prezzo che non corrisponde più al mercato. Una fonte di fallback può mantenere il mercato operativo introducendo un diverso ritmo di aggiornamento o regola di affidabilità. La documentazione del protocollo e la configurazione on-chain determinano quale percorso si applica.

Marginfi afferma esplicitamente che i feed pull di Switchboard devono essere azionati prima dell'uso. Un integratore deve quindi fornire un aggiornamento fresco come parte del percorso della transazione. I feed push di Pyth, al contrario, sono descritti come mantenuti aggiornati attraverso l'infrastruttura di Pyth. Scope utilizza un valore aggregato di account selezionato da un indice di voce configurato. Passare tra questi tipi modifica gli account necessari a una transazione e il codice che li verifica. L'avviso SDK di settembre è un esempio visibile di questi cambiamenti che raggiungono il software applicativo.

Per il Tip Router di Jito, la documentazione pubblica descrive pesi di backup per i feed non disponibili. Se tali backup preservino un'allocazione accurata delle ricompense durante un'interruzione prolungata è una questione per la configurazione attiva e gli operatori di Jito, non qualcosa che una frase di documentazione risolve. Se un feed continua ad aggiornarsi tramite operatori di nodo indipendenti dopo la fine del supporto, nessun fallback può essere attivato immediatamente. Se gli aggiornamenti cessano ma il backup è attivo, le operazioni possono continuare con un metodo di pricing diverso. Sono percorsi condizionali, non unaisione dello stato attuale del sistema.

Un incidente oracle non correlato ha portato a liquidazioni su Vesu all'inizio di settembre. Illustra che un prezzo errato può avere effetti economici, ma non è prova di un incidente presso Switchboard, Jito o marginfi. Un avviso di shutdown non dovrebbe essere trasformato in un'affermazione di liquidazione per analogia. L'evidenza di un evento reale includerebbe timestamp di account obsoleti, transazioni fallite, la sospensione di un protocollo o perdite identificate. Nessuna è stata dimostrata qui per la scadenza del 25 settembre.

Il passaggio di Solana a slot da 250 millisecondi ha cambiato il ritmo di produzione dei blocchi, ma non ha garantito l'aggiornamento di una fonte di prezzo esterna. Slot più veloci possono trasmettere un nuovo prezzo prima quando esiste; non possono fabbricare un prezzo quando il nodo che lo fornisce si ferma. Il test di freschezza di un protocollo può essere misurato in slot, tempo o altra regola, quindi un cambiamento dell'orologio di rete può alterare il modo in cui gli sviluppatori interpretano le vecchie configurazioni dei feed.

Chi sostiene il lavoro di migrazione?

L'operatore dell'oracle pubblica o coordina i dati, ma è il protocollo consumatore a scegliere l'account che il suo programma legge e i limiti che impone a quel prezzo. Un protocollo di prestito può richiedere la governance o un amministratore per modificare gli indirizzi oracle dei suoi mercati. Il suo front end e gli integratori terzi devono quindi costruire transazioni con gli account aggiuntivi corretti. Gli utenti possono notare solo un prestito rifiutato o un mercato in pausa, molto dopo che l'operatore e il protocollo hanno preso le loro decisioni tecniche.

Un operatore che termina il supporto non ha necessariamente il potere di riscrivere la configurazione del programma di un cliente. Switchboard ha esortato gli utenti a migrare perché i proprietari delle integrazioni devono agire. I progetti dovrebbero essere valutati in base agli indirizzi e agli aggiornamenti degli account che controllano. Se un'applicazione è passata a Pyth prima del 19 settembre, la successiva scadenza del supporto non ha effetto diretto su quel mercato. Se seleziona ancora un feed Switchboard e non ha un backup funzionante, il comportamento del feed dopo il 25 settembre è la questione concreta.

La lettura opposta più solida all'allarme shutdown deriva dalla nota di settembre di marginfi e dal fallback documentato di Jito. Le applicazioni possono progettare ridondanza o anticipare l'uscita di un fornitore; il codice e i documenti mostrano meccanismi a tal fine. Il modello on-demand di Switchboard può lasciare parte dell'infrastruttura dei feed funzionante in modo indipendente anche se il contributore principale ha cessato il supporto. L'avviso non ha pubblicato un calendario verificato in cui ogni account si sarebbe fermato, e nessuna evidenza primaria stabilisce un'interruzione universale di questo tipo.

La chiusura di un fornitore può anche avere effetti ritardati. Un codice scritto per richiedere prezzi on-demand può funzionare finché un gateway indipendente risponde, per poi fallire quando quel gateway viene ritirato o i suoi operatori smettono di aggiornare un asset specifico. Un osservatore necessita di diversi timestamp successivi alla scadenza, non di una singola transazione riuscita, per dedurre un servizio continuativo. La stessa disciplina vale per una transazione fallita: un errore può derivare da un SDK obsoleto o da input di account insufficienti anziché da un oracle non disponibile. Il documento di migrazione di marginfinisce un esempio esplicito di un guasto di decodifica software che potrebbe altrimenti essere etichettato erroneamente come un'interruzione oracle.

La conclusione corretta è più ristretta sia delle versioni promozionali sia di quelle allarmistiche: i documenti pubblici identificano dipendenze candidate e vie d'uscita, ma è necessario un audit attuale della configurazione mercato per mercato per stabilire l'esposizione residua.

L'inventario attivo resta assente

La presente analisi confronta l'elenco di quattro integratori di spicco di Switchboard con i documenti primari attuali di Jito, marginfi e Kamino. Ne risultano diversi riscontri documentali. La documentazione più datata del Tip Router di Jito nomina Switchboard per il pricing dei vault e identifica un fallback per i feed non disponibili. La nota 0.1.11 di settembre di marginfi descrive nove nuove configurazioni indipendenti da Switchboard e avverte di un conseguente problema SDK se gli integratori non effettuano l'aggiornamento. Il repository Scope di Kamino spiega perché la sola etichetta di aggregatore non può identificare ogni fonte a monte.

Il materiale disponibile non produce un conteggio dei feed attivi non migrati, dei fondi degli utenti esposti o di disservizi presso alcun protocollo nominato. Le pagine pubbliche non contengono un'istantanea sincronizzata al 25 settembre di tutti gli account oracle, degli ultimi aggiornamenti riusciti, delle impostazioni di fallback e degli importi supportati da ciascun mercato. Affermare un totale specifico in dollari dalla TVL del protocollo sarebbe indifendibile, perché gli asset di un intero protocollo non condividono necessariamente lo stesso oracle. La domanda precisa resta aperta a livello di account attivo.

Un conteggio corretto userebbe il mercato come riga, non il protocollo. Per ogni banco di prestito attivo, mercato derivati o vault di ricompense, un revisore registrerebbe l'indirizzo del programma, il tipo oracle selezionato, l'account oracle, la fonte di backup se presente, l'ultimo aggiornamento riuscito del prezzo, l'età massima consentita e il valore delle posizioni effettivamente dipendenti da quel prezzo. I mercati duplicati che condividono un account oracle non dovrebbero essere conteggiati come feed distinti. Un mercato che usa due oracle indipendenti non dovrebbe essere conteggiato come interamente dipendente da uno dei due senza leggerne la logica di fallback. Il timestamp della configurazione del mercato conta, perché un amministratore potrebbe cambiare il feed dopo l'osservazione.

Esiste un ulteriore passaggio di verifica quando la fonte è un aggregatore. Il consumatore può identificare un account Scope e un indice di voce, mentre la mappatura di Scope punta a uno o più fornitori. Un aggiornamento nell'account Scope dopo il 25 settembre dimostra che un aggregatore ha prodotto un valore, ma non dimostra di per sé che Switchboard abbia continuato a fornire il prezzo sottostante. L'investigatore necessita della voce selezionata e della configurazione delle fonti per quell'aggiornamento. Laddove tale mappatura non sia disponibile, il risultato dovrebbe essere registrato come sconosciuto, non attribuito silenziosamente a Pyth o Switchboard.

Cosa monitorare

• Indirizzi oracle dei mercati: confrontare il feed configurato di ogni banco o vault attivo con gli account Switchboard documentati.
• Timestamp degli aggiornamenti dei prezzi: verificare se un feed identificato continua a pubblicare valori freschi dopo il 25 settembre.
• Configurazione di fallback: identificare la fonte e il limite di freschezza usati se un feed primario resta indietro.
• Transazioni recenti del programma: verificare se prestiti, regolamenti distribuzioni delle mance si completano ancora per il mercato interessato.
• Aggiornamenti datati dei manutentori: cercare una migrazione nominata, una pausa del mercato o una dipendenza residua supportata da un account o indirizzo di programma.

L'ora di osservazione di ciascun controllo dovrebbe essere registrata; uno screenshot senza blocco o timestamp può rapidamente diventare obsoleto.

La nota di aggiornamento di marginfi afferma che un banco che utilizza un nuovo valore enum dell'oracle può far fallire l'inizializzazione del client di un SDK più vecchio, anche se l'utente non interagisce con quel particolare banco. L'istruzione di usare la versione SDK 2.8.0 o successiva è stata pubblicata prima dell'avvio della migrazione del 4 settembre, tre settimane prima della scadenza del supporto di Switchboard.

FAQ

Quando ha detto Switchboard che il supporto sarebbe terminato?

L'annuncio di shutdown è stato fatto il 19 settembre 2026, identificando il 25 settembre come fine del supporto tecnico esistente. L'avviso ha deprecato immediatamente le implementazioni.

Tutti i feed oracle di Switchboard si sono fermati il 25 settembre?

La sola scadenza del supporto non stabilisce che ogni account on-chain abbia smesso di aggiornarsi. Sono necessari timestamp attuali delle transazioni e dei feed per affermarlo.

Jito usa ancora Switchboard?

La documentazione del Tip Router di Jito nomina ancora Switchboard per il pricing dei vault, ma la sua panoramica risulta aggiornata nove mesi prima. Le pagine non dimostrano la configurazione attiva al 25 settembre.

marginfi ha migrato via da Switchboard?

L'aggiornamento di settembre di marginfi documenta nove nuove configurazioni oracle che non dipendono da Switchboard e indica che i banchi hanno iniziato a spostarsi dal 4 settembre. Non afferma che ogni banco abbia completato la migrazione.

Perché una migrazione oracle può rompere un SDK?

Marginfi afferma che gli SDK più vecchi non riconoscono i valori enum usati dalle sue nove nuove configurazioni. Un banco configurato con uno di essi può far fallire l'inizializzazione di un client obsoleto; la versione 2.8.0 o successiva supporta le varianti.

Lo Scope di Kamino è indipendente da ogni oracle esterno?

Scope aggrega valori da altri account oracle. La sua presenza in una configurazione del consumatore non identifica ogni fonte a monte senza esaminare la specifica mappatura delle voci.

Come possono gli utenti verificare se un mercato è interessato?

L'account oracle configurato del mercato, l'ultimo aggiornamento e le impostazioni di fallback forniscono una risposta più solida di un elenco storico di fornitori. Gli annunci del protocollo possono confermare se un mercato specifico ha migrato.

Sono state verificate perdite da questo shutdown?

Nessuna perdita presso un protocollo nominato è stata verificata per questo articolo. Un incidente precedente presso un altro protocollo non può dimostrare che uno sia avvenuto qui. Questa è un'analisi educativa, non una consulenza finanziaria.

Disclaimer: questo articolo ha finalità informative ed educative e non costituisce consulenza finanziaria o di investimento. I dati riflettono i documenti normativi e le informazioni disponibili al momento della stesura e cambiano con ogni divulgazione. Nulla di quanto riportato costituisce una raccomandazione ad acquistare, vendere o detenere qualsiasi titolo o asset. Effettuate sempre le vostre ricerche. Le informazioni sono accurate al 25 settembre 2026.