Unos 90 validadores de Solana que concentran cerca del 29% del SOL en staking perdieron conectividad durante el incidente del 12 de agosto, y los bloques tardaron hasta unos 30 minutos en finalizar, frente a los 13 segundos habituales, según el análisis del incidente de Metrika.

Aun así, Solana nunca se cayó. Los bloques siguieron produciéndose, y un gráfico de uptime del día habría mostrado una jornada común. El miércoles 21 de octubre, la red tiene programada la activación de Alpenglow, una actualización que apunta a una finalización de aproximadamente 150 milisegundos, pero nada en ella aborda el problema de hosting detrás de este episodio. Un informe de investigación publicado el 16 de octubre por la unidad FCAT de Fidelity, The State of Solana: Network Health and Resilience, sitúa a la red de hosting más grande en cerca del 29% del stake, muy cerca del porcentaje que Metrika vio quedar fuera de línea.

Qué ocurrió el 12 de agosto

Solana solo puede finalizar un bloque —el punto en el que una transacción se vuelve irreversible— mientras más de dos tercios del SOL en staking está votando, un proceso que normalmente toma unos 13 segundos. El 12 de agosto, con cerca del 71% del stake aún en línea, la red se mantuvo por encima de ese umbral, pero apenas. Metrika sitúa el porcentaje fuera de línea en 28.83%, frente al 33.34% en el que la finalización se detiene en toda la cadena.

Gráfico: porcentaje del SOL en staking fuera de línea el 12 de agosto, frente a la línea de parada de la finalización. Fuente: Metrika.

Según Metrika, entre cuatro y cinco puntos porcentuales adicionales de stake en las rutas afectadas habrían significado una parada de toda la red que habría requerido una recuperación coordinada. La falla comenzó en la instalación de TeraSwitch en Miami y se extendió a la infraestructura de validadores en Londres, Ámsterdam, Fráncfort, Singapur y Tokio, y en la mayoría de los casos los sistemas de respaldo de los validadores afectados nunca se activaron.

TeraSwitch corrigió la falla unos diez minutos después de diagnosticarla, y el tráfico volvió a fluir a las 04:16 UTC, 33 minutos después de que comenzara. Los validadores se recuperaron durante los 40 minutos siguientes. En esa ventana, el porcentaje de slots programados sin producir bloque saltó por encima del 32%, desde menos del 1%. Las transacciones que no son de voto por segundo cayeron de unos 1,100–1,300 a menos de 300. Durante aproximadamente media hora ningún bloque se finalizó, y el rezago se limpió luego en un impulso con un promedio de alrededor de 1,600 segundos desde la producción hasta la finalización.

La única cifra que no se movió fue el uptime, que se mantuvo en 100% porque la cadena nunca dejó de producir bloques. Durante aproximadamente media hora, sin embargo, nadie podía decir cuándo un pago se volvería irreversible. Metrika, que vende una plataforma de gestión de riesgo de activos digitales y utiliza sus propios indicadores para este análisis, trata el retraso en la finalización —no el tiempo de inactividad— como el evento que importa a quienes liquidan fondos en Solana.

Qué significaría —y qué no— una cadena detenida

El riesgo que describe FCAT es una finalización estancada y una posibleura. Una coalición que concentre más de un tercio del stake podría impedir que el resto alcance los dos tercios necesarios para la finalización, señala el informe, pero no obtendría control irrestricto sobre los activos de los usuarios ni la capacidad de reescribir transacciones finalizadas. Una falla de hosting que eliminara el mismo porcentaje de stake detendría la finalización sin que nadie ataque nada.

Ese porcentaje no es difícil de alcanzar. FCAT cuenta unos 20 identidades de validadores (18 en otro pasaje) que concentran más de un tercio del stake, y señala que ese tercio está en dos países, en dos redes de hosting y en dos implementaciones base de clientes. Son cuentas de voto, no organizaciones independientes: Figment, por ejemplo, opera dos de los cinco principales validadores de ese grupo. El veredicto general de FCAT es positivo, citando más de dos años sin una interrupción mayor del mainnet, un promedio de éxito de voto de cerca del 99.7% en 2026 y un stack de software que se diversifica lentamente. Señala la concentración como el punto a seguir vigilando. FCAT es la unidad de investigación de tecnología aplicada de Fidelity y opera su propio pequeño validador de Solana.

Dos meses después, el porcentaje sigue cerca del 29%

La foto de octubre de FCAT sitúa a la red de hosting más grande en cerca del 29% del stake. Las dos cifras miden cosas distintas —stake fuera de línea durante una falla y el porcentaje de todo el stake de una red—, pero llegan al mismo lugar. FCAT indica que la Solana Foundation ya venía trabajando para reducir el dominio de TeraSwitch. Así se desglosan sus cifras, desde las personas que operan los validadores hasta el código que ejecutan:

• 18–20 operadores — identidades de validadores que concentran más de un tercio del stake. Son cuentas de voto, no organizaciones independientes; Figment opera dos de los cinco principales del grupo.
• ~40% ubicación — porcentaje del stake en Fráncfort y Ámsterdam. Es una estimación por geolocalización de IP que FCAT advierte que puede ser inexacta; cerca del 59% está en Alemania, Países Bajos y EE. UU.
• ~29% proveedor de red — porcentaje del stake en una red de hosting, según la foto de octubre. Validadores en distintas ciudades pueden compartir un proveedor, y validadores en una misma ciudad pueden usar distintos.
• ~63% software — porcentaje del stake que ejecutó software basado en Jito en el tercer trimestre, con otro 26% ejecutando Harmonic. La mayoría de las configuraciones sigue compartiendo código Agave por debajo, por lo que un solo error allí podría afectarlas al mismo tiempo.

Fuente: FCAT, The State of Solana: Network Health and Resilience (octubre de 2026).

Los validadores se agrupan por una razón. La latencia premia estar cerca de otros nodos, señala FCAT, y hosts especializados como TeraSwitch y Latitude construyen hardware para la carga de trabajo de Solana. Los operadores sí cuentan con protecciones: failovers, energía de respaldo y redes privadas como DoubleZero que reducen la dependencia de la internet pública. La Foundation también estableció una red de respuesta a incidentes, SIRN, a inicios de 2026. El 12 de agosto, sin embargo, la mayoría de los respaldos nunca se activaron.

El límite de la Foundation alcanza cerca del 4% del stake

El programa de delegación de la Solana Foundation establece la regla principal. Desde el 1 de mayo de 2026, los validadores que quieran stake de la Foundation deben estar en una red de hosting por debajo de un techo del 25% y en un centro de datos por debajo del 15%. Un validador que incumple pierde su delegación de la Foundation hasta volver a cumplir.

Los límites entraron en vigor tres meses antes de la falla de agosto, y para la foto de octubre de FCAT la red más grande seguía por encima del techo. El alcance del programa es la otra mitad del problema. Al cierre del tercer trimestre había delegado a cerca del 51% de los validadores, pero esas delegaciones equivalían a cerca del 4% del stake activo. La regla da a los validadores una razón para diversificar, pero no gobierna el resto del stake.

Los datos de octubre de FCAT sitúan a la red de hosting más grande en cerca del 29% del stake —por encima del techo del 25% de la Foundation—, mientras que el programa de la Foundation había delegado cerca del 4% del stake activo al cierre del tercer trimestre.

Qué corrige Alpenglow —y qué no

Alpenglow llega al mainnet en el epoch 1064, que según Sol comienza alrededor de las 15:00 UTC del miércoles 21 de octubre; Anza, el equipo detrás del cliente Agave, ha dicho que cerca de las 14:50. El sistema de votación anterior sigue funcionando durante los primeros 5,000 slots, unos 18 minutos, y el nuevo toma el control en el slot 459,653,000. La finalización pasará de unos 12.8 segundos a aproximadamente 150 milisegundos, una cifra que Solana describe como una expectativa, no una constante. Los wallets y las apps siguen funcionando como hoy.

La actualización no hace nada por el problema de hosting. Un voto más rápido acorta el tiempo necesario para llegar a un acuerdo, pero nada en la página de actualizaciones de Solana cambia dónde operan los validadores ni qué proveedor los conecta.

Por ahora también reduce la diversidad de software. Los validadores deben ejecutar Agave, Jito-Solana o Harmonic Salsa en una versión basada en Agave 4.3.0. Firedancer y Frankendancer no tienen soporte durante la migración, y la página de Solana no da fecha para cuándo lo tendrán. Firedancer es el código independiente que FCAT califica como el movimiento más significativo de Solana hacia una diversidad de clientes independiente. Los validadores también deben mantener al menos 0.8 SOL por encima del mínimo exento de renta en su cuenta de voto, o no votarán ni producirán bloques en el siguiente epoch.

• Antes — desde ahora hasta cerca de las 14:50–15:00 UTC del 21 de octubre: los operadores de Firedancer y Frankendancer migran a un cliente basado en Agave, y cada validador que vota mantiene 0.8 SOL por encima del mínimo exento de renta en su cuenta de voto.
• En el cambio — comienza el epoch 1064: el sistema de votación anterior funciona durante los primeros 5,000 slots, unos 18 minutos, y Alpenglow toma el control en el slot 459,653,000.
• Después — qué cambia para los datos: las transacciones de voto salen de los bloques, así que los conteos de transacciones caen; confirmed y finalized pasan a ser el mismo estado; y los datos de participación se trasladan a certificados en el pie de bloque.

El monitoreo también cambia. El análisis de Metrika trata los votos por bloque como el indicador más cercano de qué tan cerca está la red de la línea de finalización, porque los votos son transacciones ordinarias incluidas en los bloques. Alpenglow saca los votos de los bloques, y las notas de migración de Solana indican que cualquier herramienta que mida la participación de los validadores analizando transacciones de voto necesitará una nueva fuente, porque esos datos se trasladan a los certificados del pie de bloque. Los conteos de transacciones reportados también caerán sin ninguna reducción en la actividad real.

Qué revisar esta semana

Si haces staking de SOL: consulta dónde está alojado tu validador antes de delegar. Validators.app, la fuente que usan tanto FCAT como la Foundation, rastrea el stake por red de hosting y centro de datos. Un validador en la red más grande comparte el riesgo de agosto.

Si construyes sobre Solana: espera que los dashboards de conteo de transacciones y TPS caigan el miércoles sin cambios en la actividad real. Sigue leyendo confirmed hasta que Alpenglow esté activo y luego pasa a finalized, como aconsejan las notas de migración de Solana. Antes de la activación, finalized seguirá significando una espera de unos 12.8 segundos. Revisa cualquier timeout o lógica de reintento ajustada a ese retraso, y rastrea el tiempo hasta la finalización junto con el uptime.

Si operas un validador: si usas Firedancer o Frankendancer, cambia a un cliente basado en Agave antes del epoch 1064, y verifica que la cuenta de voto tenga los 0.8 SOL.

Después del miércoles, hay dos cifras que vale la pena vigilar: si el porcentaje de la red de hosting más grande cae por debajo del techo del 25% de la Foundation, y cuándo Firedancer vuelve a tener soporte. Ninguna está en la agenda del miércoles.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión.