El fin del soporte de Switchboard deja a los protocolos de Solana verificar sus dependencias de oráculos en vivo

La fecha límite de soporte del 25 de septiembre de Switchboard convirtió un aviso de migración de seis días en una prueba de los feeds de precios de Solana. La documentación pública muestra dónde el oráculo sigue formando parte del diseño de una aplicación, pero esas páginas no pueden demostrar que un mercado en vivo aún utilice el feed. Jito y marginfi ofrecen dos visiones distintas de la posible exposición.

Switchboard ha alcanzado su fecha declarada de fin de soporte técnico el 25 de septiembre, dejando a las aplicaciones de Solana la tarea de verificar las fuentes de precios configuradas en sus programas en vivo.

El comunicado del 19 de septiembre del proyecto de oráculos, según se reprodujo en la cobertura del anuncio, dijo que su contribuyente principal de desarrollo, Switchboard Technology Labs, cerraría operaciones y que todas las implementaciones quedaban descontinuadas de inmediato. El equipo instó a los integradores a migrar a otros proveedores, mencionando Pyth y RedStone. El 25 de septiembre fue descrito como el último día de soporte existente.

El fin del soporte técnico es un hito operativo real. No demuestra, por sí solo, que todos los feeds on-chain dejaron de actualizarse a medianoche ni que cada aplicación alguna vez asociada con Switchboard permaneció dependiente de él.

La propia documentación de Switchboard ha nombrado a Kamino, Jito, marginfi y Drift como usuarios. Esas son afirmaciones históricas de integración de un proveedor que vendía un servicio de oráculos, no un inventario en tiempo real de feeds activos al 25 de septiembre. La documentación actual de cada proyecto presenta un panorama más complicado. Las páginas del Tip Router de Jito todavía describen Switchboard en su flujo de valoración, mientras que la actualización técnica de septiembre de marginfi añade rutas diseñadas para evitar esa dependencia. Un documento puede estar desactualizado mientras otro anticipa una migración. Ninguno sustituye una inspección de la configuración en vivo de las cuentas.

La ronda de financiamiento anterior de Switchboard fue de 7,5 millones de dólares en mayo de 2024. Ese monto aporta contexto sobre la historia del proyecto, pero no mide la exposición actual del protocolo. La cifra relevante es el número y el valor de los mercados en vivo cuyos cálculos de riesgo aún utilizan datos de un feed que puede actualizarse de manera confiable. Esa cifra no puede inferirse del logo de un cliente.

Una integración listada no es un feed activo

La introducción pública de Switchboard describe feeds bajo demanda: las aplicaciones crean o consultan los datos que necesitan, y un precio se pone a disposición mediante cuentas de Solana. La documentación puede identificar dónde un protocolo sabe cómo leer un feed de Switchboard, pero puede no identificar qué opción selecciona actualmente un mercado en particular. Un kit de desarrollo de software puede admitir un tipo de oráculo mucho después de que el último banco haya dejado de usarlo. A la inversa, un sitio web puede cambiar mientras una reserva en vivo conserva su cuenta de oráculo anterior.

Tres niveles de evidencia deben mantenerse separados. El primero es una página de marketing o de integración, que demuestra que existió una relación. El segundo es la configuración admitida de un programa, visible en la documentación técnica o en el código. El tercero es la configuración en vivo y el historial reciente de actualizaciones del mercado real. Solo el tercero puede respaldar la afirmación de que un mercado específico aún dependía de Switchboard en un momento dado. Aun así, puede haber una fuente de respaldo configurada, por lo que el efecto de un feed principal detenido debe verificarse contra la regla de respaldo y frescura correspondiente.

La documentación del protocolo de marginfi conserva las variantes SwitchboardPull y de venues entre sus configuraciones de oráculo disponibles. Indica que quien llama debe accionar (crank) un feed pull de Switchboard justo antes de usarlo. La misma tabla enumera los feeds push de Pyth y las cuentas de Scope como otras configuraciones. La presencia continuada de la fila de Switchboard no es prueba de que cada banco de marginfi aún lo use; la tabla describe tipos admitidos, no una lista completa de qué banco usa qué feed hoy.

La nota separada del Programa 0.1.11 de marginfi es más actual y específica. Instruyó a los desarrolladores a actualizar el SDK al menos a la versión 2.8.0 antes del 4 de septiembre, indicando que los bancos comenzarían a mudarse a nuevas configuraciones de oráculo a partir de esa fecha. La versión añadió nueve variantes que no dependen de Switchboard, incluidos los feeds Scope de Kamino y precios basados en tasas de cambio para ciertos tokens de liquid staking y tokens de principal.

La nota no dice que todos los bancos hubieran migrado para el 25 de septiembre. Sí demuestra que marginfi documentó públicamente una ruta de salida de la dependencia amenazante antes del anuncio del cierre.

La migración introdujo un segundo posible modo de falla. Marginfi indica que los SDK anteriores no pueden decodificar un banco configurado con uno de los nuevos valores de enumeración del oráculo. Un solo banco con un valor no admitido puede impedir Project0Client.initialize y las lecturas de bancos, en lugar de afectar solo una acción que involucre a ese banco. Cambiar de oráculo puede, por lo tanto, resolver una dependencia de infraestructura mientras rompe un integrador que no ha actualizado su software. El documento de marginfi explica cómo los integradores pueden evitar el problema del SDK; no es evidencia de que algún usuario en particular lo haya sufrido.

Project 0 ha descrito un margen unificado en venues de Solana, incluidos Kamino y Drift. Las interfaces entre protocolos crean otra capa en la que una migración de oráculo debe evaluarse correctamente. La advertencia sobre versiones anteriores del SDK es evidencia concreta de un riesgo de integración, pero no prueba una falla en Project 0 ni en ninguna otra aplicación mencionada. Una auditoría responsable verificaría las versiones de software y las configuraciones en vivo de los bancos de préstamo antes de afirmar una interrupción.

El Tip Router de Jito aún documenta Switchboard

La descripción del Tip Router de Jito Foundation dice que Switchboard determina el peso relativo de activos como JitoSOL y JTO mantenidos en bóvedas vinculadas al Tip Router. La descripción identifica un programa on-chain de Tip Router, un cliente para operadores de nodos y un cranker sin permisos. Su documentación de valoración nombra a Switchboard como el feed de oráculo actual y describe pesos de respaldo cuando los feeds no están disponibles.

Los documentos sitúan a Switchboard en un rol específico: valorar los activos de las bóvedas para los cálculos de pesos en un sistema de distribución de propinas y restaking. No dicen que un feed de Switchboard no disponible liquidaría automáticamente una posición de préstamo en Solana. La página de valoración de Jito describe un mecanismo de respaldo, lo que debilita la afirmación simplista de que el fin del soporte detendría necesariamente todas las operaciones del Tip Router. Los valores exactos de respaldo, las condiciones de activación y las cuentas de oráculo en vivo actuales aún requieren una verificación del estado actual del programa.

La descripción general del Tip Router mostraba un marcador de última actualización de nueve meses atrás cuando se verificó el 25 de septiembre. Esa antigüedad limita cómo puede usarse la página. Establece un diseño documentado e identifica dónde dirigir una pregunta técnica, pero no puede establecer que el programa actual tenga la misma configuración de feed. Jito puede haber actualizado las cuentas on-chain sin revisar la página, o puede seguir usando Switchboard con un respaldo. Sin una inspección reciente de transacciones o una declaración actual de Jito, una dependencia en vivo nombrada permanece sin verificar.

Las notas de versión públicas de Jito en GitHub para el Tip Router se refieren a reintentar las gateways del oráculo Switchboard en las operaciones de keeper. Una base de código con esa lógica demuestra integración técnica, no necesariamente una dependencia de cada bóveda al momento de la publicación. El código puede preservar una ruta de compatibilidad durante meses. La pregunta en vivo es si las transacciones recientes de actualización de precios apuntan a una cuenta de Switchboard usada por una bóveda que aún conserva valor, y si esa cuenta avanza después de la fecha límite de soporte.

La distinción suele perderse cuando todos los usuarios de oráculos se colocan en una sola lista. El cálculo descrito de Jito afecta los pesos relativos de los activos en un sistema de distribución. El cálculo de un mercado de préstamo determina el valor del colateral y la salud del prestatario. Ambos consumen datos de precios, pero sus rutas de falla difieren. Una auditoría que cuente logos asignaría la misma gravedad a usos fundamentalmente distintos.

El Scope de Kamino es un agregador, no una etiqueta de proveedor

El repositorio público Scope de Kamino Finance describe un agregador on-chain que copia valores de múltiples cuentas de oráculos en un solo feed de precios y valida las actualizaciones según reglas preestablecidas. Su README dice que un feed admite hasta 512 precios y que la asociación entre un índice y un par de tokens no se almacena completamente on-chain. Un programa downstream puede apuntar a Scope mientras el propio Scope depende de otros feeds para el activo seleccionado. Ver Scope en la configuración de un banco es, por lo tanto, un punto de partida para rastrear la fuente real de datos, no el final.

La nota de septiembre de marginfi lista a Scope como una opción que depende de Switchboard para la nueva configuración que describe. Eso no significa que cada despliegue de Scope en cada fecha excluya toda fuente de Switchboard. Un agregador puede cambiar sus entradas subyacentes. Una verificación completa de dependencias necesita tanto la cuenta de Scope seleccionada por el consumidor como el mapeo de fuentes usado para poblar su entrada. El repositorio de Kamino aporta la arquitectura, no un inventario con marca de tiempo de las fuentes actuales de mainnet para cada aplicación.

Kamino ha continuado incorporando instituciones a su ecosistema de préstamos. Galaxy abrió dos bóvedas de stablecoins en la plataforma en septiembre. La existencia de nuevas bóvedas muestra por qué nombrar a un protocolo entero como expuesto sin revisar sus activos individuales sería insostenible. Una bóveda de USDC, una reserva de token de liquid staking y un mercado de acciones tokenizadas pueden usar rutas de oráculos distintas. Las bóvedas de Galaxy no han sido verificadas como usuarias de Switchboard, por lo que no se incluyen en un conteo de posiciones afectadas.

Asimismo, la lista anterior de Kamino, Jito, marginfi y Drift en el material introductorio de Switchboard no muestra cómo se distribuyó la exposición entre ellos. Un proyecto puede usar un oráculo para un solo mercado, usarlo como respaldo o retener código después de cambiar los feeds en vivo. La única unidad de análisis defendible es un mercado o bóveda específica y su feed configurado en un momento especificado. Sin esa unidad, las afirmaciones sobre fondos en riesgo son aritmética de marketing al revés.

Un feed desactualizado puede tener más de un efecto

La consecuencia técnica de que un feed se quede atrás depende del protocolo consumidor. Un programa de préstamos generalmente necesita un precio para determinar el valor del colateral y la capacidad de endeudamiento. Si rechaza un valor antiguo, una acción puede fallar o un mercado puede pausarse según sus reglas. Si acepta datos desactualizados, un prestatario podría operar contra un precio que ya no coincide con el mercado. Una fuente de respaldo puede mantener el mercado funcionando mientras introduce un ritmo de actualización o una regla de confianza diferente. La documentación del protocolo y la configuración on-chain determinan qué camino aplica.

Marginfi indica explícitamente que los feeds pull de Switchboard deben accionarse antes de su uso. Un integrador debe, por lo tanto, suministrar una actualización fresca como parte de su ruta de transacción. Los feeds push de Pyth, en cambio, se describen como mantenidos frescos mediante la infraestructura de Pyth. Scope utiliza un valor de cuenta agregado seleccionado por un índice de entrada configurado. Moverse entre estos tipos cambia las cuentas que una transacción necesita y el código que las verifica. La advertencia de septiembre sobre el SDK es un ejemplo visible de esos cambios llegando al software de las aplicaciones.

Para el Tip Router de Jito, la documentación pública describe pesos de respaldo para feeds no disponibles. Si esos respaldos preservan una asignación precisa de recompensas durante una interrupción prolongada es una pregunta para la configuración en vivo y los operadores de Jito, no algo que una frase de documentación resuelva. Si un feed sigue actualizándose mediante operadores de nodos independientes después de que la empresa deje de dar soporte, es posible que no se active ningún respaldo de inmediato. Si las actualizaciones cesan pero el respaldo está activo, las operaciones pueden continuar con un método de valoración diferente. Estos son caminos condicionales, no una predicción del estado actual del sistema.

Un incidente de oráculo no relacionado llevó a liquidaciones en Vesu a principios de septiembre. Ilustra que una valoración incorrecta puede tener efectos económicos, pero no es evidencia de un incidente en Switchboard, Jito ni marginfi. Un aviso de cierre debe convertirse en una afirmación de liquidaciones por analogía. La evidencia de un evento real incluiría marcas de tiempo desactualizadas en cuentas, transacciones fallidas, una pausa del protocolo o pérdidas identificadas. Nada de eso se ha mostrado aquí para la fecha límite del 25 de septiembre.

El movimiento de Solana a slots de 250 milisegundos cambió el ritmo al que se producen los bloques, pero no garantizó que una fuente de precios externa se actualice. Los slots más rápidos pueden transportar un nuevo precio antes cuando existe; no pueden fabricar un precio cuando el nodo que lo suministra se detiene. La prueba de frescura de un protocolo puede medirse por slot, por tiempo u otra regla, por lo que un cambio en el reloj de la red puede alterar cómo los desarrolladores interpretan configuraciones de feeds antiguas.

¿Quién asume el trabajo de migración?

El operador del oráculo publica o coordina los datos, pero el protocolo consumidor elige la cuenta que su programa lee y los límites que impone a ese precio. Un protocolo de préstamos puede requerir gobernanza o un administrador para cambiar las direcciones de oráculos de sus mercados. Su front end y los integradores de terceros deben entonces construir transacciones con las cuentas adicionales correctas. Los usuarios pueden notar solo un préstamo rechazado o un mercado pausado, mucho después de que el operador y el protocolo hayan tomado sus decisiones técnicas.

Un operador que termina el soporte no tiene necesariamente el poder de reescribir la configuración del programa de un cliente. Switchboard instó a los usuarios a migrar porque los propietarios de las integraciones deben actuar. Los proyectos deben evaluarse por las direcciones y actualizaciones de cuentas que controlan. Si una aplicación se mudó a Pyth antes del 19 de septiembre, la posterior fecha límite de soporte no tiene efecto directo sobre ese mercado. Si aún selecciona un feed de Switchboard y no tiene un respaldo funcional, el comportamiento del feed después del 25 de septiembre es el tema concreto.

La lectura opuesta más sólida de la alarma por el cierre surge de la nota de septiembre de marginfi y del respaldo documentado de Jito. Las aplicaciones pueden diseñar redundancia o adelantarse a la salida de un proveedor; el código y los documentos muestran mecanismos para hacerlo. El modelo bajo demanda de Switchboard puede dejar parte de la infraestructura de feeds funcionando de forma independiente incluso si el contribuyente principal dejó de dar soporte. El aviso no publicó un cronograma verificado en el que cada cuenta se detendría, y ninguna evidencia primaria establece un corte tan universal.

El cierre de un proveedor también puede tener efectos diferidos. El código escrito para solicitar precios bajo demanda puede funcionar mientras una gateway independiente responda, y luego fallar cuando esa gateway se retira o sus operadores dejan de actualizar un activo específico. Un observador necesita varias marcas de tiempo posteriores a la fecha límite, no una sola transacción exitosa, para inferir servicio continuado. La misma disciplina aplica a una transacción fallida: un error puede provenir de un SDK desactualizado o de una entrada de cuenta insuficiente en lugar de un oráculo no disponible. El documento de migración de marginfi aporta un ejemplo explícito de una falla de decodificación de software que de otro modo podría etiquetarse erróneamente como una caída del oráculo.

La conclusión justa es más limitada que las versiones promocionales y alarmistas: los documentos públicos identifican dependencias candidatas y rutas de escape, pero se necesita una auditoría actual de configuraciones mercado por mercado para establecer cualquier exposición restante.

El inventario en vivo sigue siendo el documento faltante

El reportaje compara la lista de Switchboard de cuatro integradores destacados con documentos primarios actuales de Jito, marginfi Kamino. Produce varios hallazgos documentales. La documentación anterior del Tip Router de Jito nombra a Switchboard para la valoración de bóvedas e identifica un respaldo para feeds no disponibles. La nota 0.1.11 de septiembre de marginfi describe nueve configuraciones nuevas independientes de Switchboard y advierte de una falla separada del SDK si los integradores no actualizan. El repositorio Scope de Kamino explica por qué una etiqueta de agregador por sí sola no puede identificar cada fuente de datos upstream.

El material disponible no produce un conteo de feeds en vivo sin migrar, de fondos de usuarios expuestos ni de una interrupción en ningún protocolo nombrado. Las páginas públicas no contienen una instantánea sincronizada del 25 de septiembre de todas las cuentas de oráculos, últimas actualizaciones exitosas, configuraciones de respaldo y montos respaldados por cada mercado. Afirmar un total específico en dólares a partir del TVL del protocolo sería indefendible, porque todos los activos de un protocolo no necesariamente comparten el mismo oráculo. La pregunta precisa permanece abierta a nivel de cuentas en vivo.

Un conteo adecuado usaría el mercado como fila, no el protocolo. Para cada banco de préstamo activo, mercado de derivados o bóveda de recompensas, un auditor registraría su dirección de programa, el tipo de oráculo seleccionado, la cuenta de oráculo, la fuente de respaldo si existe, la última actualización de precio exitosa, la antigüedad máxima permitida y el valor de las posiciones realmente dependientes de ese precio. Los mercados duplicados que comparten una cuenta de oráculo no deben contarse como feeds distintos. Un mercado que usa dos oráculos independientes no debe contarse como totalmente dependiente de ninguno sin leer su lógica de respaldo. La marca de tiempo de la configuración del mercado importa porque un administrador podría cambiar un feed después de la observación.

Hay un paso de verificación adicional cuando la fuente es un agregador. El consumidor puede identificar una cuenta de Scope y un índice de entrada, mientras el mapeo de Scope apunta a uno o más proveedores. Una actualización en la cuenta de Scope después del 25 de septiembre demuestra que un agregador produjo un valor, pero no prueba por sí sola que Switchboard siguió suministrando el precio subyacente. El investigador necesita la entrada seleccionada y la configuración de fuentes de esa actualización. Cuando ese mapeo no esté disponible, el resultado debe registrarse como desconocido, no atribuirse silenciosamente a Pyth o Switchboard.

Qué observar

• Direcciones de oráculos de mercado: Compare el feed configurado de cada banco o bóveda activa con las cuentas de Switchboard documentadas.
• Marcas de tiempo de actualización de precios: Verifique si un feed identificado sigue publicando valores frescos después del 25 de septiembre.
• Configuración de respaldo: Identifique la fuente y el límite de frescura usados si un feed principal se queda atrás.
• Transacciones recientes del programa: Compruebe si el préstamo, la liquidación o la distribución de propinas aún se completa para el mercado afectado.
• Actualizaciones fechadas de mantenedores: Busque una migración nombrada, una pausa de mercado o una dependencia restante respaldada por una cuenta o dirección de programa.

La hora de observación de cada verificación debe registrarse; una captura de pantalla sin bloque o marca de tiempo puede quedar desactualizada rápidamente.

La nota de actualización de marginfi indica que un banco que use un nuevo valor de enumeración de oráculo puede hacer que un SDK anterior falle al inicializar su cliente, incluso si un usuario no interactúa con ese banco en particular. La instrucción de usar la versión 2.8.0 del SDK o posterior se publicó antes del inicio de la migración el 4 de septiembre, semanas antes de la fecha límite de soporte de Switchboard.

FAQ

¿Cuándo dijo Switchboard que terminaría el soporte?

El anuncio del cierre se realizó el 19 de septiembre de 2026 e identificó el 25 de septiembre como el fin del soporte técnico existente. El aviso descontinuó las implementaciones de inmediato.

¿Se detuvieron todos los feeds de oráculo de Switchboard el 25 de septiembre?

La fecha límite de soporte por sí sola no establece que cada cuenta on-chain dejó de actualizarse. Se necesitan marcas de tiempo actuales de transacciones y feeds para hacer esa afirmación.

¿Jito sigue usando Switchboard?

La documentación del Tip Router de Jito todavía nombra a Switchboard en la valoración de bóvedas, pero su descripción general está marcada como actualizada por última vez nueve meses antes. Las páginas no prueban la configuración en vivo al 25 de septiembre.

¿Migró marginfi fuera de Switchboard?

La actualización de septiembre de marginfi documenta nueve configuraciones nuevas de oráculo que no dependen de Switchboard y dice que los bancos comenzaron a mudarse desde el 4 de septiembre. No afirma que cada banco completó una migración.

¿Por qué una migración de oráculo puede romper un SDK?

Marginfi dice que los SDK anteriores no reconocen los valores de enumeración usados por sus nueve configuraciones nuevas. Un banco configurado con uno de ellos puede hacer que la inicialización de un cliente antiguo falle; la versión 2.8.0 o posterior admite las variantes.

¿Es el Scope de Kamino independiente de todo oráculo externo?

Scope agrega valores de otras cuentas de oráculos. Su presencia en la configuración de un consumidor no identifica cada fuente upstream sin examinar el mapeo de entrada específico.

¿Cómo pueden los usuarios verificar si un mercado está afectado?

La cuenta de oráculo configurada del mercado, su última actualización y sus ajustes de respaldo ofrecen una respuesta más sólida que una lista histórica de proveedores. Los anuncios del protocolo pueden confirmar si un mercado específico ha migrado.

¿Se han verificado pérdidas por este cierre?

No se verificaron pérdidas en ningún protocolo nombrado para este artículo. Un incidente anterior en otro protocolo no puede probar que uno ocurriera aquí. Este es un análisis educativo, no asesoramiento de inversión.

Descargo de responsabilidad: Este artículo es solo con fines informativos y educativos y no constituye asesoramiento financiero ni de inversión. Las cifras reflejan los registros regulatorios y reportajes disponibles al momento de la redacción y cambian con cada divulgación. Nada de lo aquí escrito es una recomendación para comprar, vender o mantener ningún valor o activo. Haga siempre su propia investigación. La información es precisa al 25 de septiembre de 2026.