Solana mantuvo la producción de bloques el 12 de agosto, pero estuvo cerca de perder la finalidad de sus transacciones después de que un fallo de infraestructura dejara sin capacidad de votar a validadores que representaban casi el 29% del stake de la red. La cadena siguió activa, aunque con más huecos en la producción, una caída acusada del procesamiento de transacciones y un retraso temporal en la confirmación irreversible de los bloques.
El incidente se originó en Teraswitch, que la Fundación Solana describe como el mayor proveedor de infraestructura de la red. Según el análisis posterior de la compañía, un router periférico situado en Miami conservaba una ruta predeterminada obsoleta. Durante unas tareas rutinarias de mantenimiento de un proveedor de tránsito, esa ruta se activó y un error en los valores de una política de enrutamiento aplicó una instrucción de “no exportar” hacia Europa y Asia-Pacífico.
Una caída de conectividad que afectó a 12 centros
La configuración incorrecta se propagó por la red de Teraswitch e impidió que varios centros de datos accedieran a internet a través de sus routers locales operativos. Doce instalaciones de Europa y Asia-Pacífico perdieron la conectividad tanto con internet como entre sí. Entre ellas había infraestructura que alojaba validadores de Solana y nodos RPC, utilizados para atender solicitudes de acceso a la cadena.
Teraswitch informó de que el tráfico de sus proveedores se recuperó por completo 33 minutos después de la primera alerta. La Fundación Solana publicó el 14 de septiembre el relato del incidente, mientras que la firma independiente de monitorización de riesgos de blockchain Metrika corroboró en términos generales tanto su alcance como el hecho de que la red continuó generando bloques.
Los datos de Metrika muestran que los slots omitidos llegaron a superar el 32%. Al mismo tiempo, el rendimiento de las transacciones que no eran votos cayó por debajo de 300 operaciones por segundo, frente a un rango habitual aproximado de entre 1.100 y 1.300. El observador de la firma registró además alrededor de media hora durante la cual los nuevos bloques todavía no habían alcanzado la finalidad.
El margen de seguridad quedó reducido
La finalidad de Solana requiere que vote más del 66% del stake. Por eso, la pérdida de conectividad de cerca del 29% dejó a la red a unos cuatro o cinco puntos porcentuales del umbral aproximado a partir del cual se habría detenido la finalidad, según Metrika. Los bloques pendientes terminaron finalizándose cuando se restablecieron las conexiones.
La diferencia entre que la cadena siga produciendo bloques y que pueda finalizarlos resulta relevante. Solana no sufrió una interrupción completa de la producción, pero durante el episodio los usuarios y los sistemas que dependen de una liquidación rápida operaron con un rendimiento notablemente peor y con más incertidumbre sobre cuándo quedarían cerradas las transacciones.
La concentración de infraestructura, bajo escrutinio
La Fundación señaló que Teraswitch llegó a alojar el 38% del stake de la red en 2025 y que su equipo redujo esa proporción por debajo del 30% antes del incidente. Ambas cifras no miden exactamente lo mismo: una refleja el stake alojado por el proveedor y la otra, el porcentaje que quedó fuera de servicio durante el fallo. Sin embargo, el episodio muestra cómo validadores gestionados de forma independiente pueden verse afectados al mismo tiempo cuando comparten un único dominio de fallo.
Teraswitch aplicó ese mismo día medidas de refuerzo para impedir que una ruta no válida bloquee el acceso de los centros a sus routers periféricos operativos. En su informe de septiembre, la compañía explicó que todavía estaba desarrollando controles adicionales de monitorización de rutas. La diversidad de proveedores y la capacidad para observar con rapidez este tipo de problemas siguen siendo, por tanto, elementos centrales para la resiliencia de la red.
