Solana Alpenglow: activación a partir del 28 de septiembre y qué deben comprobar ahora los delegadores

Solana no activa Alpenglow en una fecha secreta: el calendario de publicación de la desarrolladora Anza señala el 28 de septiembre de 2026 para la activación de la función en la red principal. Si tienes Solana (SOL), en la mayoría de los casos no tienes que hacer nada. Si haces staking por delegación, en cambio, tienes exactamente una tarea, y la fecha que más importa para ella no es el 28, sino el 21 de septiembre.

Este texto responde a la pregunta por la activación de Alpenglow en Solana y por su fecha acudiendo a la fuente primaria, en tres pasos: qué dice realmente el calendario, qué significa técnicamente «activación» y a qué distancia está la red, el día de esta medición, del estado que el calendario presupone. Las cifras sobre la difusión de la nueva versión las hemos tomado nosotros mismos en la red principal el 1 de septiembre de 2026.

Cuándo se activa Alpenglow en Solana: el calendario de Agave 4.3 señala el 28 de septiembre

La respuesta está en un documento que casi nadie lee: el calendario de publicación de Agave v4.3 en el wiki del cliente de validación. Agave es el software que mantiene Anza y con el que la mayoría de los validadores de Solana operan sus nodos. El calendario recoge cada hito de la versión con una fecha objetivo y una fecha de entrega, y la última línea correspondiente a la mainnet-beta lleva la entrada Begin feature activation con la fecha objetivo 2026-09-28.

La rama de la v4.3 se creó el 11 de agosto de 2026, la red de pruebas recibió la recomendación el 17 de agosto y la activación de la función en la red de pruebas y en devnet está completada, según las fechas de entrega, el 19 y el 24 de agosto respectivamente. Es un detalle importante para valorar la solidez del documento: la tabla se mantiene al día, las líneas marcadas llevan fechas de entrega reales y algunas de ellas son anteriores a las fechas objetivo. Un documento abandonado tiene otro aspecto.

Para el ámbito germanohablante esta es una información nueva. Los datos que circulan hablan del «tercer trimestre de 2026» o de «octubre de 2026», y ninguno de los dos es falso. Simplemente describen algo distinto del 28 de septiembre, y esa distinción es el núcleo de este artículo.

Por qué la palabra Alpenglow no aparece en el calendario

Quien busque la palabra Alpenglow en el calendario no encontrará nada. Este habla únicamente de la v4.3 y de activación de funciones. La conexión la establece un segundo documento oficial: en el resumen de la versión Agave 4.2, la Fundación Solana escribe que Alpenglow todavía no se activará en la 4.2 y que su activación cabe esperarla para Agave 4.3, «targeted for October 2026». Esa misma página incluye Alpenglow en su barra de indicadores con la mención «150ms Alpenglow target finality, activating in 4.3».

Solo ambos documentos juntos permiten formular el enunciado: la v4.3 contiene Alpenglow, y la activación de la función de la v4.3 comienza el 28 de septiembre. Quien lea solo uno de los dos encontrará o una fecha sin asunto o un asunto sin fecha. Eso explica también por qué hasta ahora no aparecía ningún día concreto en la cobertura en alemán.

Qué es Alpenglow y qué cambia con ello para tu staking de SOL lo hemos tratado con detalle en un artículo aparte: Solana Alpenglow y tu staking de SOL. Este texto se sitúa un nivel por debajo y responde a la cuestión de la fecha a partir del documento.

Las cinco fechas hasta la activación, una por una

El calendario escalona el camino hacia la red principal en cinco hitos. Ese escalonamiento es el verdadero hallazgo, porque deja ver que antes de la fecha límite hay una rampa lenta:

• 4 de septiembre: Anza marca en la rama v4.3 una candidata a actualización para la mainnet-beta. A partir de ahí existe una versión pensada para el uso en producción.
• 8 de septiembre: llamamiento a voluntarios para llevar el diez por ciento del stake a la v4.3. Ese mismo día comienza en la red de pruebas el procedimiento de reinicio y de paso de una versión a otra, hacia arriba y hacia abajo.
• 14 de septiembre: el mismo llamamiento para el 25 % del stake.
• 21 de septiembre: recomendación general de pasar a la v4.3. Es el momento en que un operador puede cambiar sin presión de tiempo.
• 28 de septiembre: comienzo de la activación de la función en la mainnet-beta.

Entre la recomendación general y la activación transcurre exactamente una semana. Esa semana no es un formalismo, sino un colchón: debe garantizar que la gran mayoría del stake ya ejecute la nueva implementación antes de que se accione siquiera el primer interruptor. El orden de los pasos del calendario es, así, la propia respuesta a la pregunta de cuánto tiempo tiene un validador.

Puerta de función y frontera de época: por qué el 28 de septiembre es un pistoletazo de salida y no un día de conmutación

Una puerta de función es un interruptor del protocolo que solo hace efectivo un cambio ya entregado cuando lo respalda stake suficiente. El software reposa, pues, mucho antes en los nodos sin hacer nada, hasta que la puerta se abre. Precisamente por eso ambos documentos oficiales emplean la palabra begin: el 28 de septiembre comienza la activación, que ese día no está concluida.

Qué es una época y por qué marca el compás

En Solana, una época es un tramo fijo de 432.000 espacios, en cuya frontera la red resuelve sus asuntos contables: las delegaciones surten efecto, las recompensas se liquidan y los interruptores quedan armados. Una época no dura, por tanto, un número fijo de horas; dura lo que tarden esos 432.000 espacios.

Lo hemos medido nosotros mismos el 1 de septiembre de 2026 a las 12:49 UTC. La red se encontraba en la época 1026, en el espacio 195.474 de 432.000. De la diferencia entre dos marcas de tiempo de bloque a lo largo de 198.000 espacios resulta un tiempo medio por espacio de 0,318 segundos y, de ahí, una duración de época de unas 38 horas. Entre el final de la época en curso y el 28 de septiembre quedan así unas 16 fronteras de época más.

De ahí se sigue la solución de la aparente contradicción entre «28 de septiembre» y «octubre de 2026»: el 28 de septiembre es el comienzo de la activación, el efecto en el funcionamiento diario se asienta a lo largo de las siguientes fronteras de época, y esas caen en octubre. El pistoletazo de salida y el efecto son dos momentos distintos, no dos fechas rivales.

Medición propia en la red principal: cuánto stake corre hoy sobre Agave 4.3

Un calendario dice lo que debe ocurrir. Si la red lo sigue puede comprobarse. Por eso, el 1 de septiembre de 2026 a las 12:49 UTC, consultamos a través del punto de acceso público de Solana dos listas que después cruzamos: la de todos los nodos con la versión que declaran y la de todas las cuentas de voto con su stake activo. Así puede calcularse la cuota de stake por versión de cliente, en vez de limitarse a contar nodos.

La base: 679 validadores activos con unos 438,1 millones de SOL de stake activo en conjunto, más 15 validadores descolgados que solo suman el 0,01 % del stake. El reparto por ramas de versión:

• Agave 4.2: 86,61 % del stake, 608 validadores
• Frankendancer, numeración antigua: 8,49 %, 40 validadores
• Frankendancer, numeración por calendario: 3,88 %, 15 validadores
• Agave 4.3 (alfa y beta): 0,39 %, 6 validadores
• Agave 4.4 (alfa): 0,08 %, 6 validadores
• demás indicaciones y nodos sin versión declarada: 0,56 %, 4 validadores

El hallazgo en una frase: una semana antes del primer hito del calendario, el 0,39 % del stake activo corre sobre una compilación 4.3, y se trata exclusivamente de versiones alfa y beta. El calendario quiere ver un diez por ciento el 8 de septiembre y un 25 % el 14 de septiembre. No es una contradicción ni una señal de alarma, porque la candidata a actualización para la red principal no se marca hasta el 4 de septiembre. Sí muestra cuánto tiene que ocurrir todavía entre hoy y la fecha objetivo, y te pone en la mano una cifra con la que comprobar el avance por tu cuenta.

Qué revelan los números de versión: Agave, Frankendancer y la diversidad de clientes

Al analizar la medición llama la atención que alrededor del doce por ciento del stake declara números de versión que no siguen en absoluto el esquema de Agave. No es un error, sino la huella de un segundo cliente de validación. Frankendancer es la etapa intermedia apta para producción del segundo cliente de Solana, Firedancer; según su documentación compila el validador de Agave como dependencia y aun así mantiene una numeración propia. En la forma antigua, el último grupo de cifras codifica la versión de Agave subyacente; en la más reciente figura una numeración por calendario, como la que la documentación de Firedancer recoge en el ejemplo v26.08.2 para la versión vigente de Frankendancer.

Si se descodifica la forma antigua, aparece una imagen reveladora: los 40 nodos de ese grupo corren sobre un núcleo 4.2. Ningún nodo con un número de versión de Frankendancer declara un núcleo 4.3. Los seis validadores en 4.3 son todos nodos de Agave con versiones alfa o beta.

Para ti, como titular, de aquí se desprende sobre todo una cosa: la pregunta de si tu validador corre ya la nueva versión no se responde por el nombre del proveedor. Lo determinante es únicamente la versión declarada. Y puedes consultarla sin instalar nada.

¿Tienes que hacer algo como delegador de SOL? La respuesta depende de tu custodia

Delegador, validador y comisión, en una frase cada uno

Un validador es una máquina que verifica bloques, participa en la votación y recibe recompensas por ello. Eres delegador cuando asignas tus SOL a un validador sin operar tú mismo un nodo; tus monedas no salen de tu cartera ni se transfieren al validador. La comisión es la parte de las recompensas que el validador retiene.

De ahí resultan tres casos, y solo uno de ellos exige atención:

• SOL en un mercado de criptomonedas, con o sin staking: para ti no cambia nada. La plataforma opera la tecnología y asume el riesgo del cambio. Qué proveedores ofrecen staking y en qué condiciones lo muestra nuestro repaso a las mejores plataformas de staking.
• SOL en autocustodia, pero sin staking: tampoco hay nada que hacer. Una actualización de protocolo no te exige ninguna operación en la cartera, ningún canje y ninguna autorización.
• SOL en autocustodia y delegados a un validador: aquí merece la pena mirar. No porque tus monedas corran peligro, sino porque un validador que se duerme en el cambio no genera recompensas mientras esté fuera de servicio y eso te cuesta rentabilidad.

Una precisión importante: tus SOL siguen siendo tuyos en todos estos casos. Una puerta de función modifica el comportamiento de la red, no el saldo de tu cuenta. En esta actualización no hay nada que reclamar, nada que canjear ni plazo alguno tras el cual algo caduque.

Cómo saber en cinco minutos qué versión de cliente ejecuta tu validador

El camino que hemos seguido para la medición anterior está abierto a cualquiera. Necesitas la dirección de tu cuenta de voto, que te muestra cualquier cartera con función de staking:

1. Consulta tu delegación. Abre en tu cartera el apartado de staking y anota el nombre o la dirección del validador al que has delegado.
2. Comprueba la versión. Los paneles públicos de validadores indican para cada nodo la versión de software declarada. Si a partir de mediados de septiembre sigue apareciendo allí una 4.2, cuando la recomendación general apunta desde hace tiempo a la 4.3, esa es tu señal.
3. Comprueba el estado. Esos mismos paneles muestran si un validador figura como descolgado y cuál es su tasa de bloques perdidos. Esos dos valores dicen más sobre la calidad de tu delegación que cualquier cifra de rentabilidad.
4. Redelega si hace falta. Puedes trasladar tu delegación a otro validador en cualquier momento. El cambio surte efecto en la siguiente frontera de época, es decir, en unas 38 horas según el ritmo que hemos medido.

Un momento razonable para esta comprobación es el 22 o el 23 de septiembre, justo después de la recomendación general. Antes de eso, una 4.2 no es una omisión, sino el estado recomendado.

Por qué el 21 de septiembre es para ti la fecha más importante

El 28 de septiembre es el día del que se escribe. El día en que puedes reconocer algo es el 21 de septiembre. Hasta entonces, un validador que siga en la versión antigua actúa conforme a las reglas, porque la recomendación dice expresamente otra cosa. A partir del 21 de septiembre eso se invierte: quien no cambie entonces habrá dejado sin usar una semana que el calendario prevé deliberadamente como colchón.

Esa inversión es el verdadero motivo por el que merece la pena recordar la fecha: un dato técnico se convierte en un rasgo de calidad de tu validador. Un operador que sigue el escalonamiento y se ofrece pronto como voluntario dice más sobre su diligencia que cualquier autodescripción.

Fíjate además en el segundo hito, el 8 de septiembre: el llamamiento se dirige a voluntarios para el diez por ciento del stake. Un validador que participa ejecuta a conciencia una versión reciente en producción. Es una señal de compromiso con la comunidad y, a la vez, un riesgo algo mayor. Ambas cosas van juntas y ninguna de ellas es por sí sola un error.

Qué cambia Alpenglow técnicamente: Votor, 150 milisegundos y el umbral del 40 %

Alpenglow sustituye el procedimiento de votación vigente, Tower BFT, por Votor, un mecanismo en dos fases. Si un bloque reúne por la vía rápida los votos del 80 % del stake, se considera definitivo de inmediato; si esa mayoría no se alcanza, deciden dos rondas del 60 % cada una. Así consta en la propuesta SIMD-0326, que ha superado la votación de los validadores y figura desde entonces en el registro oficial de los Solana Improvement Documents. La Fundación Solana señala unos 150 milisegundos como objetivo para la finalidad. La finalidad es el momento a partir del cual una transacción ya no puede revertirse, y es algo distinto del tiempo de confirmación que te muestra una cartera.

El segundo cambio afecta a la resistencia de la red. Con el procedimiento actual, la finalidad se detiene si falla más de un tercio del stake. Alpenglow eleva ese límite al 40 %. Lo cercano que esto está de la práctica se vio el mismo día en que se publicó el calendario: una caída del proveedor de centros de datos Teraswitch dejó fuera de la red el 28,83 % de los SOL en staking, según Solana Compass, es decir, 4,5 puntos porcentuales por debajo del umbral vigente hoy.

Una precisión importante para valorar el precio de SOL: una actualización del consenso es un asunto de infraestructura. No conlleva reparto alguno, ni monedas nuevas, ni derecho que puedas hacer valer. Quien deduce de una fecha de activación una afirmación sobre el precio confunde dos planos distintos.

Validator Admission Ticket: qué cambia la actualización en los costes de tu validador

Una parte de esta reforma casi nunca se menciona en la cobertura en alemán, pese a que afecta a la rentabilidad de cada nodo. Hoy, un validador debe escribir su voto en la cadena de bloques para cada espacio y paga por ello, según SIMD-0326, en torno a un SOL diario en comisiones. Con Alpenglow los votos dejan de circular por la cadena, con lo que esa partida de costes desaparecería sin sustitución.

Para mantener el equilibrio económico, la propuesta introduce el Validator Admission Ticket, abreviado VAT. Es una tasa que se descuenta de la cuenta de un validador antes de su admisión a una época; quien no pueda afrontarla queda fuera del conjunto activo. Su importe se fija en el 80 % de las comisiones de voto actuales, es decir, al principio unos 0,8 SOL diarios o 1,6 SOL por época. A diferencia de hoy, ese dinero se quema por completo, lo que frena la inflación.

La propuesta limita además el conjunto activo a los 2.000 validadores con mayor stake, porque así la implementación se simplifica notablemente. Con las cifras actuales ese límite queda lejos: en nuestra medición había 679 validadores activos. Para ti como delegador, eso significa que previsiblemente tu validador no quedará fuera por esta regla, siempre que atienda la tasa del ticket.

Qué se acelera con la actualización Alpenglow y qué sigue igual

Como las actualizaciones de una cadena de bloques generan con regularidad expectativas que la propia actualización no atiende, va aquí la separación sobria. El tiempo de transacción que una cartera te muestra como confirmación ya es corto hoy; lo que se acorta es el tiempo hasta la irreversibilidad definitiva. La aceleración pretendida hasta unos 150 milisegundos afecta, por tanto, al punto a partir del cual un pago realmente ya no puede recuperarse.

Una velocidad así se nota sobre todo allí donde los importes se mueven en rápida sucesión: en aplicaciones de negociación, en pagos en la caja de una tienda y en los puentes entre cadenas que esperan la confirmación definitiva antes de liberar activos. Para ti, que como titular haces una transferencia al mes, la diferencia sigue siendo invisible en el día a día.

Lo que expresamente sigue igual: el número de tus monedas, tus direcciones, tus palabras de recuperación y la forma en que custodias criptomonedas. Un procedimiento de consenso es la regla con la que la red se pone de acuerdo sobre un orden, y esa regla deja los saldos intactos. En la competencia entre las grandes cadenas de capa 1, la reforma no deja de ser relevante, porque afecta a todo el ecosistema: cada aplicación que corre sobre Solana hereda la finalidad más corta sin tener que cambiar nada por su cuenta.

Qué significa una actualización desatendida para tu rentabilidad de staking

Un validador gana recompensas participando en la votación sobre la cadena y produciendo bloques él mismo. Si cae, no gana nada, y como tu recompensa depende de la suya, tú tampoco ganas nada durante ese tiempo. No se te descuenta nada por ello: tu saldo permanece intacto, simplemente dejas de percibir el rendimiento del tiempo de inactividad.

Cuánto pesa eso depende de la duración. Un validador que necesita media época tras un cambio para volver a funcionar te cuesta en torno a un día de rendimiento. Con los órdenes de magnitud habituales hoy, es un importe que se pierde en los decimales. Un validador que permanece descolgado durante semanas sí es un problema real, y además con independencia de cualquier actualización.

A ello se añade una segunda evolución, que actúa en el mismo periodo y nada tiene que ver con Alpenglow: sobre la curva de emisión de Solana se decidió por separado, lo que reducirá la rentabilidad del staking en los próximos años. Qué hay detrás lo hemos desglosado en la rentabilidad del staking de Solana cae. Para tu valoración eso significa que la rentabilidad está cambiando ahora mismo desde varios frentes, y que la parte que corresponde a una sola actualización del consenso es la menor de todas.

Provisional significa provisional: cuán firme es la fecha y en qué se reconoce un aplazamiento

El calendario inscribe su propia reserva en la primera línea: se trata de un cronograma provisional, todas las fechas pueden cambiar y antes de cada actualización conviene esperar los anuncios en Discord. No es una fórmula vacía, sino la práctica habitual en una red que se actualiza sin una instancia central. El 28 de septiembre es una fecha objetivo, no un plazo con efectos jurídicos.

Existe, sin embargo, un buen indicio de lo en serio que cabe tomarse la tabla: las líneas ya resueltas llevan fechas de entrega, y dos de ellas son anteriores a su fecha objetivo. Eso habla de un plan que se cumple y no de un documento de deseos.

Un aplazamiento se reconoce exactamente en dos puntos, sin depender de la cobertura informativa. Primero, en el propio calendario: si la línea de la candidata para la red principal del 4 de septiembre se queda sin fecha de entrega, toda la cadena posterior se desplazará con alta probabilidad. Segundo, en la difusión: si el 15 de septiembre la cuota de stake en la 4.3 sigue en el entorno de nuestra medición actual del 0,39 % en lugar del 25 % pretendido, el 28 de septiembre ya no será sostenible en la práctica. Ambas comprobaciones te cuestan dos minutos y son más sólidas que cualquier pronóstico.

Comprobar la fecha de Alpenglow en Solana: qué conviene retener

La cuestión de la fecha tiene respuesta, y esa respuesta es poco espectacular: una fecha objetivo el 28 de septiembre, un efecto que se extiende por las siguientes fronteras de época hasta octubre y, para la inmensa mayoría de los titulares, ninguna necesidad de actuar. Tres pasos con los que cerrar el asunto:

1. Aclara en un minuto si esto te afecta siquiera. Si tus SOL están en una plataforma o sin staking en tu propia cartera, has terminado. Si delegas por tu cuenta, anota el 22 de septiembre para la comprobación de versión. Y si de todos modos vas a comparar dónde es posible el staking y en qué condiciones, el repaso a las mejores plataformas de staking te ayudará a ordenarlo.
2. Juzga a tu validador por rasgos duros y no por la rentabilidad anunciada. La versión declarada, el estado y la tasa de bloques perdidos te dicen más que cualquier porcentaje en una página de inicio. Quien prefiera delegar del todo el asunto encontrará entre los proveedores de nuestra comparativa de los mejores mercados de criptomonedas la variante más cómoda y, a cambio, menos autónoma.
3. Sigue documentando tus ingresos de staking igual que hasta ahora. Una actualización del consenso no cambia nada en el tratamiento fiscal de las recompensas; las entradas se siguen valorando en el momento en que se producen. Si aún no llevas un registro limpio, la comparativa de software fiscal para criptomonedas y rastreadores de cartera es el punto de partida adecuado.

(1 de septiembre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)