Solana Alpenglow arranca el 21 de octubre en la epoch 1064: lo que importa ahora a quien hace staking

Solana recibe un nuevo procedimiento de consenso el miércoles 21 de octubre de 2026, hacia las 15:00 UTC. La Solana Foundation ha fijado la fecha de Alpenglow en la epoch 1064. Para todos los que solo guardan o transfieren Solana no cambia nada: los pagos serán definitivos más rápido y las carteras y aplicaciones seguirán funcionando como hasta ahora. Si has delegado tus SOL, en cambio, hay una cosa que aclarar, y antes de la fecha.

Porque la actualización impone dos condiciones a cada validador. Quien no las cumpla al comienzo de la epoch 1064 ya no vota en la epoch siguiente ni produce bloques. Para la delegación asociada eso significa: sin recompensas de staking durante ese periodo. La comprobación se hace antes, no después.

La epoch 1064 empieza el 21 de octubre a las 15:00 UTC

Una epoch es el periodo para el que Solana reparte entre sus validadores sus tareas en la red, y abarca siempre 432.000 slots, es decir, 432.000 ventanas breves de tiempo en cada una de las cuales puede nacer un bloque. Alpenglow se arma al comienzo de la epoch 1064.

El miércoles por la mañana corría la epoch 1057. Hasta el cambio quedan, por tanto, siete epochs, y la fecha está exactamente a una semana. La Solana Foundation indica en su página de actualización el 21 de octubre «at approximately 15:00 UTC»; la palabra approximately figura allí con razón, porque el comienzo de una epoch depende del avance de los bloques y no del reloj.

El interruptor de la actualización, en Solana un llamado feature gate, lleva el identificador A1pengvuM6JEcyNuTnMqepBKhwHE3N6PmUrdATGawhJS. En la testnet y en la devnet está activo; en la mainnet aparece como «not activated». En la devnet, Alpenglow arrancó el 25 de septiembre.

Alpenglow sustituye a TowerBFT y la ejecución queda intacta

Consenso designa el procedimiento con el que las máquinas de una red se ponen de acuerdo sobre el orden de los pagos y sobre el momento a partir del cual un pago ya no se puede revertir. Justo ese procedimiento es el que Solana cambia: TowerBFT, en servicio desde el arranque de 2020, deja paso a Alpenglow.

Hoy pasan unos 12,8 segundos hasta que un pago en Solana es definitivo. Alpenglow apunta a unos 150 milisegundos, apenas una centésima parte. CoinDesk sitúa la cifra con sobriedad: los 150 milisegundos son un objetivo y la velocidad real depende del estado de la red. Como efecto secundario, el nuevo procedimiento tolera, según la Solana Foundation, un 20 % de stake malicioso más un 20 % de stake caído.

Importante para cualquiera que use una aplicación en Solana: la ejecución de los pagos no cambia. El entorno de ejecución SVM, los formatos de transacción y la mecánica de comisiones se quedan como están. Alpenglow actúa una capa por debajo, en el acuerdo sobre los bloques.

La fuente primaria despeja de entrada un malentendido extendido: los 150 milisegundos son el tiempo hasta la finalidad, no el ritmo al que nacen los bloques. El tiempo de bloque se redujo de forma independiente, en cuatro fases de 400 a 200 milisegundos, concluidas en octubre de 2026.

Primero Votor, después Rotor: la actualización llega en dos fases

Alpenglow consta de dos piezas que llegan una después de otra. El 21 de octubre arranca Votor, la parte de la votación. Los validadores se enviarán en adelante sus votos directamente y los agruparán en certificados, de modo que un bloque es definitivo tras una o dos rondas de votación. Votor está en Agave 4.3.

Rotor, la segunda pieza, sustituirá más adelante la forma en que un bloque se distribuye por la red. Debe reemplazar la distribución actual, llamada Turbine, por una única capa de reenvío. Todavía no hay fecha para ello; Rotor llegará cuando Votor esté asentado en producción.

En la práctica, para la próxima semana eso significa que el 21 de octubre solo cambia la votación. Quien lea sobre «la actualización Alpenglow» como un único acontecimiento lee un atajo.

Los primeros 5.000 slots siguen funcionando con TowerBFT

Una particularidad afecta a todos los que quieran seguirlo en directo el 21 de octubre. El feature gate se abre al comienzo de la epoch 1064, pero la red procesa los primeros 5.000 slots de la epoch todavía con TowerBFT. Solo después toma el relevo Alpenglow, según la Solana Foundation en el slot 459.653.000, unos 18 minutos después del inicio de la epoch.

Esa cifra se puede recalcular, y cuadra. Del avance de bloques del miércoles por la mañana resulta el comienzo de la epoch 1064 en el slot 459.648.000. Hasta el cambio señalado en el slot 459.653.000 hay exactamente 5.000 slots. El dato de la fuente primaria y el estado de la blockchain coinciden, por tanto, slot a slot.

En esa ventana de un buen cuarto de hora, la red sigue indicando que funciona con el procedimiento antiguo. Si mirases el 21 de octubre a las 15:05 UTC y no encontrases una confirmación de Alpenglow, no estarías viendo un fallo, sino esta fase de transición.

Agave 4.3.0 es obligatorio y Firedancer se queda fuera de la migración

La primera de las dos condiciones afecta al software. Un validador debe ejecutar, antes del comienzo de la epoch 1064, un cliente basado en Agave, y en una versión construida sobre Agave 4.3.0. Están admitidos Agave mismo, Jito-Solana y Harmonic Salsa.

Un cliente validador es el programa con el que un operador participa en la red. Varios equipos desarrollan tales programas de forma independiente, lo que protege a la red frente a un fallo en una sola implementación. Justo esa diversidad se restringe brevemente en la migración: Firedancer y Frankendancer, los clientes de la casa Jump Crypto, no están soportados expresamente durante el cambio. CoinDesk formula la consecuencia de forma independiente: los operadores tienen que cambiar de software temporalmente.

Para un delegador, esa es la primera pregunta a su validador: ¿corre allí un cliente basado en Agave en una versión sobre Agave 4.3.0? Un validador que apueste por Firedancer y no cambie no estará en el cambio.

El Validator Admission Ticket cuesta 0,8 SOL por epoch

La segunda condición es una cuestión de dinero. Un validador debe mantener al menos 0,8 SOL en su cuenta de voto, y además del importe que ya tiene que estar allí como saldo mínimo. De ese saldo se paga el Validator Admission Ticket, VAT en corto, una especie de cuota de entrada para participar en la votación.

El calendario detrás va desfasado: la primera cuota se carga al comienzo de la epoch 1064 y paga la participación en la epoch 1065. Así sigue después, cada epoch paga la siguiente. La Solana Foundation escribe al respecto la frase que importa: si la cuota no se paga, el validador no vota en la epoch siguiente ni produce bloques.

Con ello incluso sale más barato. Hasta ahora los validadores pagaban sus votos como comisiones de transacción ordinarias, unos 1 SOL por epoch según CoinDesk. Esos costes desaparecen y se sustituyen por los 0,8 SOL fijos, una quinta parte menos.

Una epoch dura hoy unas 26 horas en lugar de dos días

Aquí merece la pena un cálculo propio, porque no aparece en ninguna nota. Una epoch abarca 432.000 slots. Mientras un slot duraba 400 milisegundos, eso eran dos días. Tras la rebaja a 200 milisegundos, la epoch se encoge en la misma medida.

De la distancia entre el nivel de bloques del miércoles por la mañana y la fecha de inicio anunciada de la epoch 1064 resulta un tiempo de slot de unos 218 milisegundos. Una epoch dura así unas buenas 26 horas, es decir, aproximadamente un día. Muchos textos explicativos antiguos siguen citando 38 o 48 horas; esas cifras vienen de antes de la rebaja.

Para la cuota, ahí está el punto de verdad. Los 0,8 SOL no se pagan cada dos días, sino una vez al día larga. Anualizado, eso son unos 267 SOL por validador, es decir, algo menos de 28.700 dólares a un precio de 107 dólares. El miércoles por la mañana la red registraba 678 validadores con cuenta de voto, de ellos 673 activos y cinco en falta. Extrapolado, toda la red paga así unos 542 SOL por epoch, en torno a 58.000 dólares.

Los operadores de un validador con poco stake delegado tienen que ganar esa cuota con las recompensas de bloque. Para los grandes operadores, 0,8 SOL al día es una línea de gastos generales; para los pequeños, un obstáculo.

Las cifras de transacciones de Solana se hunden el 21 de octubre sin que baje el uso

Una consecuencia de la actualización causará confusión en las próximas semanas, y lo hará en todo el que juzgue a Solana por sus métricas. Hasta ahora los votos de los validadores eran transacciones ordinarias en el bloque y se contaban como tales. Con Alpenglow abandonan el bloque por completo.

Dirigiéndose a los desarrolladores, la Solana Foundation escribe que conviene poner sobre una nueva línea base cualquier métrica que contara los votos. CoinDesk extrae la consecuencia para los de fuera: la cifra de transacciones declarada de Solana podría bajar con claridad sin que el uso por parte de usuarios reales retroceda.

Así que quien vea después del 21 de octubre un gráfico de las transacciones por segundo de Solana apuntando con fuerza hacia abajo debería comprobar primero la fecha. Una ruptura en la medición se parece en un gráfico a una ruptura en el mercado. En Solana la proporción de votos sobre el total de transacciones es tradicionalmente alta, de modo que el salto será notable.

Otros dos cambios afectan sobre todo a los desarrolladores, pero explican por qué se habla de un breaking change. Los dos niveles de confirmación confirmed y finalized se fusionan y significarán lo mismo. Y Proof of History, el cómputo propio del tiempo en Solana, deja de marcar el ritmo de la producción de bloques; las marcas temporales que dependían de él desaparecen del flujo de datos.

El validador detrás de tu delegación: versión del cliente y saldo de voto

Delegar SOL transfiere tus derechos de voto a un validador y te deja las monedas. El delegador comparte el riesgo de caída de ese validador: si el validador no vota en la epoch 1065, las recompensas de staking de la delegación asociada desaparecen durante ese periodo. Los SOL en sí no se ven afectados, quedan intactos.

Dos datos se pueden aclarar antes del 21 de octubre. Primero, el software cliente del validador con su versión. Segundo, el saldo de su cuenta de voto, que por encima del importe mínimo debe sostener los 0,8 SOL necesarios. Ambos constan en los directorios públicos de validadores, y hacer staking a través de un proveedor significa pedírselo a él.

La situación es más sencilla con validadores grandes y gestionados de forma profesional, que de todos modos han colaborado en el cambio. Merece atención un validador pequeño cuyo operador publique poco. Si la elección cuesta: una delegación se puede mover en cualquier momento a otro validador, aunque el cambio solo surte efecto en la epoch siguiente, así que tarda un día largo.

Staking por exchange, cartera o validador propio: quién carga con el riesgo

Para los inversores en Alemania confluyen tres vías, y se diferencian precisamente en esta pregunta.

Hacer staking a través de un exchange significa no tener nada que ver con clientes ni cuentas de voto. El exchange opera sus propios validadores o trabaja con socios y responde de su disponibilidad. A cambio se asume el riesgo de contraparte del exchange. Un panorama de los proveedores y sus condiciones está en la comparación de plataformas de staking.

Delegar desde la cartera propia significa elegir tú mismo el validador. Aquí los dos puntos de comprobación de arriba se aplican de forma directa y, en cambio, los SOL quedan en custodia propia.

Operar uno mismo un validador significa cumplir activamente las dos condiciones. Para ese grupo, el 21 de octubre es una fecha de trabajo, no de lectura.

En lo fiscal, la actualización no cambia nada. En Alemania las recompensas de staking cuentan entre los otros ingresos del artículo 22 número 3 de la ley del impuesto sobre la renta y tributan en el año en que se reciben, con un límite exento de 256 euros al año. Para los propios SOL en staking sigue valiendo el plazo de tenencia de un año del artículo 23 de la misma ley; el Ministerio Federal de Finanzas descartó ya en 2022 la anterior ampliación a diez años en caso de staking.

Nuestra valoración: el riesgo de caída se concentra en los validadores pequeños

Desde el punto de vista de la redacción, el riesgo para el participante alemán medio en staking es bajo, pero no nulo, y se reparte de forma desigual.

A favor hablan tres pruebas. El cambio funciona en la devnet desde el 25 de septiembre y antes en la testnet, así que los operadores han tenido semanas. Con 0,8 SOL por epoch la cuota queda por debajo de los costes de voto anteriores, de alrededor de 1 SOL, y no exige presupuesto adicional. Y con 438 millones de SOL en staking, un 74,4 % de la oferta en circulación según nuestra propia medición, el grueso del stake depende de unos pocos validadores grandes cuyos operadores acompañan el cambio.

En contra pesa la exclusión de Firedancer. Obliga justo a los operadores que habían elegido conscientemente una implementación alternativa a cambiar de software, y un cambio con la presión de una fecha es la fuente de error clásica. Cuánto stake depende de validadores con Firedancer no se puede leer en los datos públicos; esa laguna se mantiene. Cinco validadores en falta de 678 son el estado normal, y con esa referencia se podrá leer después del 21 de octubre si el cambio salió sin ruido.

De ahí no se sigue ninguna recomendación de compra o venta de SOL. Solana cotizaba el miércoles por la mañana en 107 dólares, casi un 10 % por debajo del nivel de la semana anterior. La pérdida total es posible en cualquier criptomoneda.

Qué dice tu propia cartera sobre Alpenglow y qué ha cambiado desde septiembre

Esta fecha tiene una historia previa que conviene para situarla. A finales de septiembre circulaba el 28 de septiembre como fecha de activación. Detrás había una confusión: en la hoja de ruta de la desarrolladora Anza, ese día solo marcaba que se retomaban las activaciones de funciones en general, sin nombrar Alpenglow. Entonces situamos la fecha incumplida.

La vía de comprobación para delegadores ya estaba en nuestro artículo del 1 de septiembre, aunque allí todavía con la fecha antigua. Lo que ha cambiado desde entonces son exactamente tres cosas: la fecha ya está fijada, la condición Agave 4.3.0 tiene nombre y la cuota tiene una cifra con 0,8 SOL. Cómo se reparte el stake entre los validadores y dónde está la minoría de bloqueo lo medimos a principios de octubre.

La cobertura en alemán va todavía por detrás de este estado de cosas. Los textos que señalan el 28 de septiembre como fecha o hablan de una actualización «sin fecha fija» están superados desde el miércoles por la mañana. Al leer cualquier dato sobre Alpenglow, mira la fecha de publicación.

Alpenglow el 21 de octubre: 0,8 SOL deciden una epoch de recompensas

La fecha está puesta, las condiciones tienen nombre y ambas se pueden aclarar en la semana que viene. Bastan tres pasos:

1. Aclara quién tiene delegados tus SOL. Con un proveedor, la responsabilidad del cliente y del saldo de voto está ahí; pregunta si sus validadores corren sobre Agave 4.3.0. Qué proveedores ofrecen qué condiciones lo muestra la comparación de exchanges cripto.
2. Con delegación propia, comprueba los dos datos. El software cliente con su versión y el saldo en la cuenta de voto. Si uno no encaja, la delegación se puede mover antes del 21 de octubre; el cambio surte efecto en la epoch siguiente. Para custodiar tus SOL tú mismo en ese paso, los dispositivos están en la comparación de carteras hardware.
3. Anota tus recompensas de staking para la declaración. Las recompensas cuentan en el año en que se reciben y el límite exento está en 256 euros. Las herramientas para ello están en la comparación de programas fiscales para cripto.

Los datos sobre la fecha, sobre Agave 4.3.0 y sobre el Validator Admission Ticket proceden de la página de actualización de la Solana Foundation; la lectura de los costes y de las cifras de transacciones la confirma de forma independiente CoinDesk.

(14 de octubre 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.)