El soporte de un oráculo de Solana termina hoy. ¿Quién sigue confiando en sus precios?

La fecha límite de soporte del 25 de septiembre de Switchboard ha convertido una advertencia de migración de seis días en una prueba para los feeds de precios de Solana. La documentación pública actual muestra dónde sus datos siguen formando parte del diseño de una aplicación, pero esas páginas no pueden probar que un mercado en vivo siga utilizando el feed. Jito y marginfi ofrecen dos visiones marcadamente diferentes de la exposición.

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

La declaración del 19 de septiembre del proyecto de oráculos, como se reprodujo en la cobertura del anuncio, decía que su contribuyente principal de desarrollo, Switchboard Technology Labs, cerraría y todas las implementaciones quedarían obsoletas de inmediato. El equipo instó a los integradores a migrar a otros proveedores, nombrando a Pyth y RedStone. El 25 de septiembre se describió como el último día de soporte existente. Una empresa que finaliza el soporte es un hito operativo real. No prueba, por sí mismo, que todos los feeds en cadena dejaron de actualizarse a medianoche o que todas las aplicaciones alguna vez asociadas con Switchboard siguieran dependiendo 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áculo, no un inventario en tiempo real de feeds activos el 25 de septiembre. Revisar la documentación actual de cada proyecto revela un panorama más complicado. Las páginas del Tip Router de Jito todavía describen a Switchboard en su flujo de precios; 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 de cuentas en vivo.

La ronda de financiación anterior de Switchboard fue de 7,5 millones de dólares en mayo de 2024. La cantidad es un antecedente útil sobre la historia de la empresa, pero no da una medida de la exposición actual del protocolo. El recuento relevante es el número y el valor de los mercados en vivo cuyos cálculos de riesgo todavía toman datos de un feed que no puede actualizarse de manera confiable, y ese recuento no puede inferirse a partir de un logotipo de 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 llaman los datos que necesitan, y un precio se pone a disposición a través de cuentas de Solana. La documentación puede identificar dónde un protocolo sabe cómo leer un feed de Switchboard. Puede que no identifique 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 se cambie a otro. A la inversa, un sitio web puede cambiar mientras una reserva en vivo conserva su cuenta de oráculo anterior.

Es necesario mantener separados tres niveles de evidencia. Primero está una página de marketing o integración, que muestra que existió una relación. Segundo está la configuración admitida de un programa, visible en la documentación técnica o el código. Tercero está la configuración en vivo y el historial de actualizaciones recientes del mercado real. Solo el tercero puede respaldar la afirmación de que un mercado nombrado todavía dependía de Switchboard en un momento dado. Incluso entonces, puede configurarse una fuente de respaldo, por lo que el impacto de un feed primario detenido debe verificarse contra la regla de respaldo y frescura correspondiente.

Considere la documentación del protocolo de marginfi. Su tabla de oráculos conserva SwitchboardPull y variantes de venue entre las configuraciones disponibles. Dice que quien llama debe accionar un feed pull de Switchboard justo antes de usarlo. La misma tabla enumera feeds push de Pyth y cuentas Scope como otras configuraciones. Un lector podría confundir la fila de Switchboard que continúa con la prueba de que todos los bancos de marginfi todavía lo usan. 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 más específica. Indicaba a los desarrolladores que actualizaran el SDK al menos a la versión 2.8.0 antes del 4 de septiembre, diciendo que los bancos comenzarían a migrar a nuevas configuraciones de oráculos a partir de esa fecha. La versión añadió nueve variantes que no dependen de Switchboard, incluyendo feeds de Kamino Scope y precios basados en tipos de cambio para ciertos tokens de staking líquido y principales. La nota no dice que todos los bancos hubieran migrado para el 25 de septiembre. Sí muestra que un proyecto documentó públicamente una ruta para alejarse de la dependencia amenazada antes del anuncio de cierre.

La migración conlleva un segundo modo de fallo sorprendente. Marginfi dice que los SDK más antiguos no pueden decodificar un banco configurado con uno de los nuevos valores de enumeración de oráculos. Un solo banco con un valor no soportado puede impedir Project0Client.initialize y las lecturas de bancos, no solo una acción que involucre a ese banco. En otras palabras, cambiar un oráculo puede arreglar una dependencia de infraestructura mientras rompe un integrador que no ha actualizado su software. El documento de Marginfi dice a los integradores cómo evitar el problema del SDK; no es evidencia de que algún usuario particular lo haya sufrido.

Project 0 ha descrito margen unificado entre venues de Solana, incluyendo Kamino y Drift. Las interfaces entre protocolos crean otra capa en la que una migración de oráculo debe leerse correctamente. La nota sobre versiones antiguas del SDK es evidencia concreta de un riesgo de integración, sin probar un fallo en Project 0 o en cualquier otra app nombrada. Una auditoría responsable verificaría las versiones de software y las configuraciones activas de los bancos de préstamo antes de afirmar una interrupción.

El Tip Router de Jito todavía documenta Switchboard

La descripción general del Tip Router de la Fundación Jito dice que Switchboard determina el peso relativo de activos como JitoSOL y JTO mantenidos en bóvedas vinculadas al Tip Router. La descripción general identifica un programa Tip Router onchain, un cliente de operador de nodo y un cranker sin permisos. Su documentación de precios nombra a Switchboard como el feed de oráculo actual y describe pesos de respaldo cuando los feeds no están disponibles.

Los documentos colocan a Switchboard en un trabajo específico: valorar los activos de las bóvedas para cálculos de peso 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 precios de Jito describe un mecanismo de respaldo, lo que debilita la afirmación simplista de que un fin de soporte necesariamente detiene todas las operaciones del Tip Router. Los valores exactos de respaldo, las condiciones de activación y las cuentas de oráculo activas actuales todavía necesitan una verificación del estado actual del programa.

La descripción general del Tip Router mostraba un marcador de última actualización de hace nueve meses cuando se verificó el 25 de septiembre. Esa antigüedad cambia cómo puede usarse. Establece un diseño documentado e identifica dónde hacer una pregunta técnica. No puede establecer que el programa actual tenga la misma configuración de feeds. Jito puede haber actualizado las cuentas onchain 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 activa nombrada permanece sin verificar.

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

La distinción a menudo se pierde 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 descrito de un mercado de préstamos determina el valor del colateral y la salud del prestatario. Ambos consumen datos de precios, pero sus rutas de fallo difieren. Una auditoría que cuente logotipos asignaría la misma severidad a usos fundamentalmente diferentes.

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

El repositorio público Scope de Kamino Finance describe un agregador onchain que copia valores de múltiples cuentas de oráculo en un único feed de precios y valida las actualizaciones bajo 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 onchain. Un programa downstream puede apuntar a Scope mientras que Scope mismo depende de otros feeds para el activo seleccionado. Ver Scope en una configuración de banco es, por lo tanto, un punto de partida para rastrear la fuente de datos real, no el final.

La nota de marginfi de septiembre enumera Scope como una opción que no depende de Switchboard para la nueva configuración que describe. Eso no implica que cada implementación 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 Scope seleccionada por el consumidor como el mapeo de origen utilizado para poblar su entrada. El repositorio de Kamino proporciona la arquitectura, no un inventario con marca de tiempo de las fuentes actuales de mainnet para cada aplicación.

Kamino ha seguido incorporando instituciones a su ecosistema de préstamos. Galaxy abrió dos bóvedas de stablecoin en la plataforma en septiembre. La existencia de nuevas bóvedas muestra por qué nombrar un protocolo completo como expuesto sin verificar sus activos individuales sería poco sólido. Una bóveda de USDC, una reserva de token de staking líquido y un mercado de acciones tokenizadas pueden usar diferentes rutas de oráculo. No hemos verificado que las bóvedas de Galaxy usen Switchboard, por lo que no se incluyen en un recuento de posiciones afectadas.

De manera similar, la lista más antigua de Kamino, Jito, marginfi y Drift en el material introductorio de Switchboard no nos dice la distribución de exposición entre ellos. Un proyecto puede usar un oráculo solo para un mercado, usarlo como respaldo o conservar el código después de cambiar los feeds en vivo. La única unidad de análisis defendible es un mercado o bóveda específico y su feed configurado en un momento especificado. Sin esa unidad, las afirmaciones sobre fondos en riesgo son aritmética de marketing ejecutada al revés.

Un feed obsoleto tiene más de un efecto posible

La consecuencia técnica de que un feed se retrase depende del protocolo consumidor. Un programa de préstamos generalmente necesita un precio para determinar el valor de la garantía 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 obsoletos, un prestatario podría transaccionar contra un precio que ya no coincide con el mercado. Una fuente de respaldo puede mantener el mercado operando pero introducir un nuevo ritmo de actualización o regla de confianza. La documentación del protocolo y la configuración onchain deciden qué camino se aplica.

Marginfi dice explícitamente que los feeds pull de Switchboard deben ser accionados antes de su uso. Un integrador debe, por lo tanto, proporcionar una actualización fresca como parte de su ruta de transacción. Los feeds push de Pyth, por el contrario, se describen como mantenidos frescos a través de 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 necesita una transacción y el código que las verifica. La advertencia del SDK de septiembre es un ejemplo visible de esos cambios llegando al software de aplicación.

Para Jito Tip Router, los documentos públicos describen pesos de respaldo para feeds no disponibles. Si esos respaldos preservan una asignación precisa de recompensas durante una interrupción sostenida 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 a través de operadores de nodos independientes después de que la empresa deja de brindar 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 precios diferente. Estas son rutas condicionales, no una predicción del estado actual del sistema.

Un incidente de oráculo no relacionado provocó liquidaciones en Vesu a principios de septiembre. Ilustra que los precios incorrectos pueden tener efectos económicos, pero no es evidencia de un incidente en Switchboard, Jito o marginfi. Un aviso de cierre no debe convertirse en una afirmación de liquidación por analogía. La señal de un evento real serían marcas de tiempo de cuentas obsoletas, transacciones fallidas, una pausa del protocolo o pérdidas identificadas, ninguna de las cuales se ha mostrado aquí para la fecha límite del 25 de septiembre.

El cambio de Solana a ranuras de 250 milisegundos cambió el ritmo al que se producen los bloques, pero no garantizó que una fuente de precios externa se actualice. Las ranuras más rápidas pueden llevar un nuevo precio antes cuando existe uno. No pueden fabricar un precio cuando el nodo que lo suministra se detiene. La prueba de frescura de un protocolo puede medirse por ranura, 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 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 del oráculo de sus mercados. Su interfaz y los integradores externos tienen entonces que construir transacciones con las cuentas adicionales correctas. Los usuarios quizá solo noten 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 pone fin al soporte no tiene necesariamente el poder de reescribir la configuración del programa de un cliente. El aviso de 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 ya se trasladó a Pyth antes del 19 de septiembre, la fecha límite de soporte posterior no tiene un efecto directo sobre ese mercado. Si todavía selecciona un feed de Switchboard y no tiene un respaldo funcional, el comportamiento del feed después del 25 de septiembre es el problema concreto.

La lectura opuesta más sólida de la alarma de cierre se deriva de la propia 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 ha dejado de dar soporte. El aviso no publicó un calendario verificado en el que toda cuenta se detendría, y no encontramos evidencia primaria que establezca un corte universal de ese tipo.

Existe un tipo diferente de cuestión de continuidad para un protocolo que creó su propio respaldo. Un precio de respaldo puede evitar una detención total mientras valora un activo con menos frecuencia o con un conjunto de fuentes diferente. Para un proceso de distribución de recompensas, un peso de respaldo temporal puede mantener la contabilidad de épocas en marcha, aunque la asignación puede entonces depender de los supuestos del respaldo. Para un mercado de préstamos, el respaldo podría cambiar el precio usado en una verificación de salud. Estas no son afirmaciones sobre la configuración actual de Jito o marginfi. Muestran lo que un mantenedor debe divulgar antes de que los usuarios puedan juzgar si una migración está completa en términos operativos, no solo si las transacciones todavía se ejecutan.

La retirada de un proveedor también puede tener efectos retardados. El código escrito para solicitar precios bajo demanda puede tener éxito mientras responde una pasarela independiente, y luego fallar cuando esa pasarela 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 un servicio continuado. La misma disciplina se aplica a una transacción fallida: el error de un usuario puede surgir de un SDK obsoleto o de una entrada de cuenta insuficiente en lugar de un oráculo no disponible. El documento de migración de Marginfi proporciona un ejemplo explícito de un fallo de decodificación de software que de otro modo podría etiquetarse erróneamente como una interrupción del oráculo.

Hay un límite para esa tranquilidad. Un respaldo descrito nueve meses antes necesita validación contra el estado actual, y una opción de migración descrita en septiembre no es prueba de que todos los bancos la adoptaran. Los dos documentos ofrecen razones creíbles para no asumir una catástrofe, a la vez que dejan una brecha medible. La conclusión justa es más limitada que ambas versiones, la promocional y la alarmista: los documentos públicos identifican dependencias candidatas y rutas de escape; se necesita una auditoría actual de la configuración mercado por mercado para establecer cualquier exposición restante.

El inventario en vivo sigue siendo el documento faltante

El reportaje original aquí compara la lista de Switchboard de cuatro integradores prominentes con documentos primarios actuales de Jito, marginfi y Kamino. Produce dos hallazgos documentales verificados. La documentación más antigua de Tip Router de Jito nombra a Switchboard para el precio de la bóveda y un respaldo para feeds no disponibles. La nota de marginfi de septiembre 0.1.11 describe nueve nuevas configuraciones independientes de Switchboard y advierte de una ruptura 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 trabajo no produce un recuento de feeds en vivo no migrados, fondos de usuarios expuestos ni una interrupción en ningún protocolo nombrado. Las páginas públicas disponibles no contienen una instantánea sincronizada del 25 de septiembre de todas las cuentas de oráculo, últimas actualizaciones exitosas, configuraciones de respaldo y montos soportados por cada mercado. Afirmar un total específico en dólares a partir del TVL del protocolo sería indefendible, porque los activos de todo el protocolo no necesariamente comparten el mismo oráculo. La pregunta precisa del titular permanece abierta a nivel de cuenta en vivo.

Un recuento adecuado usaría el mercado como la fila, no el protocolo. Para cada banco de préstamo activo, mercado de derivados o bóveda de recompensas, el auditor registraría su dirección de programa, tipo de oráculo seleccionado, cuenta de oráculo, fuente de respaldo si la hay, última actualización de precio exitosa, antigüedad máxima permitida y el valor de las posiciones que realmente dependen de ese precio en particular. 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 cualquiera de ellos 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.

Este método explica por qué incluso una afirmación verdadera como que un protocolo soportó 550 feeds en el pasado es insuficiente para la pregunta presente. Un feed puede existir sin un prestatario activo, puede tener una actualización de precio sin un mercado consumidor, o puede ser referenciado solo en código inactivo. Un recuento de cuentas de feed mide infraestructura. Un recuento de mercados configurados mide dependencia. Un recuento de posiciones y garantías que realmente tocan esos mercados mide exposición económica. Ninguno es intercambiable con los activos totales depositados en todos los productos operados por un proyecto.

Hay un paso de verificación adicional cuando una fuente es un agregador. El consumidor puede identificar una cuenta Scope y un índice de entrada, mientras que el mapeo de Scope apunta hacia uno o más proveedores. Una actualización en la cuenta Scope después del 25 de septiembre prueba que un agregador produjo un valor, pero no prueba por sí mismo que Switchboard continuó suministrando el precio subyacente. El investigador necesita la entrada seleccionada y la configuración de la fuente para esa actualización. El repositorio de Kamino señala que las etiquetas de par de tokens no se almacenan completamente onchain, por lo que puede ser necesaria configuración externa o documentación del mantenedor para mapear un índice a su activo. Donde ese mapeo no esté disponible, el resultado debe registrarse como desconocido, no atribuirse silenciosamente a Pyth o Switchboard.

Qué observar

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

Registre el tiempo de observación para cada verificación; una captura de pantalla sin un bloque o marca de tiempo puede volverse obsoleta rápidamente.

La nota de actualización de marginfi afirma que un banco que usa un nuevo valor de enumeración de oráculo puede hacer que un SDK más antiguo 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 o posterior del SDK se publicó antes del inicio de la migración del 4 de septiembre, tres semanas antes de la fecha límite de soporte de Switchboard.

Preguntas frecuentes