Actualización Glamsterdam de Ethereum: qué deben comprobar ahora los stakers en su cliente

Ethereum recibe su próxima gran actualización y, por primera vez, tiene fecha: el 6 de octubre de 2026 debe activarse Glamsterdam en la red de pruebas Sepolia. Si haces staking por tu cuenta, esa es la fecha a partir de la cual tu nodo necesita una versión de software que hoy todavía no existe como publicación estable. El 11 de septiembre de 2026 contamos las versiones publicadas de los diez grandes clientes de Ethereum para mostrar hasta dónde llega realmente la preparación.

La respuesta breve por delante: ninguno de los diez clientes comprobados llevaba ese día una versión estable que mencionara la actualización en su nombre. El trabajo se desarrolla en versiones preliminares y compilaciones nocturnas de prueba. Para ti eso significa que hoy no hay nada que hacer. Más importante es saber cuándo llegará el momento.

Glamsterdam, Gloas y Sepolia: qué hay detrás de los nombres de la actualización de Ethereum

Tres términos aparecen en cada noticia sobre esta actualización, y designan cosas distintas.

Glamsterdam es el nombre colectivo del próximo cambio de reglas del protocolo Ethereum. Se compone de los nombres de las dos capas que Ethereum modifica a la vez: Gloas para la capa de consenso y Amsterdam para la capa de ejecución. Quien lee Gloas en las actas se refiere, por tanto, al mismo proceso, solo que a la otra mitad.

Sepolia es una red de pruebas. Funciona con el mismo software que la red principal, pero con tokens sin valor. Las nuevas reglas del protocolo se activan allí antes de tocar dinero real. Un fallo en Sepolia cuesta tiempo de desarrollo; un fallo en la red principal cuesta dinero a los inversores. De ahí este orden.

Un hard fork es un cambio de reglas que hace incompatibles el software antiguo y el nuevo: un nodo que no conoce las nuevas reglas sigue, desde el momento del cambio, una cadena distinta de la del resto de la red. Precisamente por eso actualizar el cliente antes de un fork no es una recomendación, sino el requisito para participar.

Por qué el 6 de octubre de 2026 figura en el calendario para Sepolia

La fecha procede de la 186.ª reunión de desarrolladores de la capa de consenso, celebrada el 3 de septiembre de 2026. Allí los equipos de los clientes acordaron la época 351232 como punto de cambio, lo que corresponde al 6 de octubre de 2026 a las 13:53 UTC. La página de hoja de ruta de la Ethereum Foundation recoge desde entonces esa fecha como próximo hito y el estado de la actualización como testing on devnets.

Para la red principal no hay fecha. En la misma página consta Q4 2026, con la indicación expresa de que la fecha aún no está confirmada. En círculos de desarrolladores se ha hablado de un plazo en diciembre, sin que ello obligue a nadie. Quien hoy te da una fecha para la red principal te da una expectativa.

También la fecha de Sepolia está sujeta a reserva. El orden del día de la reunión recoge que Lido y Optimism habían exigido al menos un día de funcionamiento estable en una red de pruebas antes de fijar un fork. Esa condición no se cumplía todavía el 11 de septiembre.

Devnet-11 el 14 de septiembre: la prueba de la que depende la fecha de Sepolia

Una devnet es una red de desarrollo efímera, montada expresamente para una prueba de actualización y descartada después. Es el escalón previo a la red de pruebas pública.

En un principio, Glamsterdam-Devnet-10 iba a ser la última de estas redes antes de Sepolia. Ese plan ha cambiado. Los desarrolladores han previsto una red más, Devnet-11, cuyo arranque está fijado para el lunes 14 de septiembre de 2026. En paralelo siguen las pruebas en Devnet-8, y en Devnet-9 se miden los clientes uno a uno.

Con eso, la situación previa al 6 de octubre se describe con claridad: entre el arranque previsto de Devnet-11 y la fecha de Sepolia median 22 días. En ese plazo los equipos deben operar una red de forma estable, corregir los fallos hallados y construir con ello versiones de publicación. Si Devnet-11 no aguanta, la fecha de Sepolia se desplaza. Justo para eso existen estas redes.

Preparación de los clientes: diez clientes de Ethereum y sus versiones a 11 de septiembre

Este estudio lo realizó cryptoticker.io el 11 de septiembre de 2026. Método: a través de la interfaz pública de GitHub recuperamos las listas de publicaciones de los diez clientes de Ethereum de código abierto y anotamos por cada cliente la versión estable más reciente con su fecha de publicación; las versiones preliminares se consignan aparte. Se comprobaron diez objetos, con hora de referencia a las 18:00 UTC.

Analizamos los nombres de versión, las fechas de publicación y la marca de versión preliminar, no el texto completo de cada descripción de publicación. Una versión puede contener reglas de Glamsterdam sin llevar la palabra en su nombre. Tampoco se recogen las compilaciones especiales para devnets concretas, que los equipos intercambian entre sí sin publicarlas como versiones.

Qué dicen las cifras sobre el calendario de Glamsterdam

De la tabla se leen tres hallazgos.

Primero: ninguna de las diez versiones estables lleva Glamsterdam, Gloas o Sepolia en su nombre de versión ni en su etiqueta. Eso coincide con el estado del desarrollo tal como lo describe la página de hoja de ruta.

Segundo: los ritmos de publicación divergen mucho. Cuatro clientes construyeron su versión estable más reciente en septiembre, Erigon hace dos días. Otros cuatro acumulan más de 30 días de retraso, encabezados por Geth con 46 días y Prysm con 44. De ahí no se deriva juicio alguno sobre su preparación, pero sí una expectativa: en esos equipos la publicación sigue pendiente.

Tercero: el movimiento visible ocurre en las versiones preliminares. Nethermind publicó el 2 de septiembre una versión preliminar 2.0.0-rc, Lodestar el 27 de agosto una preliminar de la 1.47.0, y Nimbus depositó la mañana del 11 de septiembre una compilación nocturna de prueba. Ahí es donde se está trabajando.

La conclusión para ti es poco espectacular y por eso aprovechable: ahora mismo no hay nada que instalar. La versión que necesitarás para el fork aún no existe como publicación estable. Actualizar con prisas no aporta nada.

Cliente de ejecución y cliente de consenso: por qué debes actualizar los dos

Desde el paso a la prueba de participación, un nodo de Ethereum se compone de dos programas que corren en paralelo y se comunican entre sí.

El cliente de ejecución ejecuta las transacciones y gestiona el estado de la cadena. Geth, Nethermind, Besu, Erigon y Reth pertenecen a este grupo. El cliente de consenso determina qué bloque vale a continuación y se ocupa del staking. Prysm, Lighthouse, Teku, Nimbus y Lodestar cumplen esa función.

Glamsterdam cambia reglas en ambas capas. Actualizar solo un lado no basta, por tanto. Quien actualiza el cliente de consenso y olvida el de ejecución se queda, tras el cambio, con un nodo cuyas mitades discrepan. En la práctica eso se traduce en atestaciones perdidas y, si eres validador, en ingresos que no llegan. Cuánto se acumula depende del tiempo que la situación pase inadvertida.

Si un servicio pone tu ETH en staking por ti, esa tarea le corresponde a él. Qué proveedores se encargan y en qué condiciones lo detalla nuestra comparativa de plataformas de staking.

Qué deben comprobar los stakers individuales en su nodo antes del fork

Cuatro puntos merecen la pena ya ahora, aun sin que exista una publicación.

Anota qué versiones corren en tu equipo, por separado para ambos clientes. Un número sorprendente de operadores no lo sabe de memoria cuando llega el momento y entonces lo busca con prisas.

Comprueba si tu instalación descarga las publicaciones automáticamente o si actualizas a mano. Ante un fork, la vía automática es la más segura, siempre que descargue publicaciones estables y no preliminares.

Mira cuánto espacio de disco queda libre. Una actualización que falla por un disco lleno es una caída evitable.

Suscríbete a los avisos de publicación de tus dos clientes. Ese es el canal por el que los equipos anunciarán la fecha del fork para la red principal, y es más rápido que cualquier sitio de noticias.

EIP-8061 y la cola de salida: qué cambia para los stakers

Entre las propuestas previstas para Glamsterdam, una afecta directamente al staking. La EIP-8061 eleva el llamado churn, es decir, el número de validadores que pueden salir de la red o consolidarse por unidad de tiempo.

Por qué cuenta: quien saca su ETH del staking se pone en una cola. Su longitud resulta de ese tope. Lo larga que puede llegar a ser en algunos momentos lo describimos en agosto con las cifras de entonces; los detalles están en nuestro análisis de la cola de staking. Si el churn sube, la espera se acorta con la misma demanda.

Otras dos propuestas marcan el contenido de la actualización. La EIP-7732 ancla en el protocolo la separación entre la propuesta y la construcción de bloques. La EIP-7928 introduce listas de acceso a nivel de bloque, que comunican al procesamiento por adelantado qué partes del estado toca un bloque. Ambas apuntan a la rapidez y a la igualdad de trato en la construcción de bloques, no a un cambio en tus saldos.

El alcance de la actualización se considera congelado, pero aún puede cambiar antes de la red principal, porque la propuesta marco figura formalmente en estado de borrador. La lista completa la recoge la página de hoja de ruta de la Ethereum Foundation.

Staking a través de un proveedor: qué puedes comprobar si no operas un nodo

La mayor parte del ETH puesto en staking está en exchanges, servicios de staking y protocolos de liquid staking, y solo una parte pequeña en equipos privados. Si estás en ese caso, la actualización del cliente no es tarea tuya. Aun así hay dos cosas que puedes hacer.

Mira si tu proveedor mantiene una página de estado o un canal de avisos, y si allí figura algo sobre Glamsterdam. Los proveedores que tratan en silencio las actualizaciones de red no te dan forma alguna de interpretar una caída.

Comprueba, en segundo lugar, cómo gestiona tu proveedor las ventanas de mantenimiento. En torno a un fork de la red principal muchos servicios suspenden ingresos y retiradas durante algunas horas. Es lo habitual y casi siempre inocuo, pero es un mal momento para una transacción planificada.

Qué significa la actualización para el ETH de tu cartera, y qué no

Aquí está la tranquilidad que corresponde a este asunto: si simplemente mantienes ETH, en una cartera propia o con un proveedor, Glamsterdam no te exige nada. No hay canje, ni migración, ni plazo que te cueste dinero. Tus direcciones siguen siendo las mismas y tus saldos también.

Una actualización de este tipo cambia las reglas con las que la red construye y comprueba bloques. No cambia lo que hay en tu cartera. Tampoco una cartera hardware necesita preparación especial para ello; qué dispositivos cubren qué funciones lo hemos contrastado en nuestra comparativa de carteras hardware.

La cautela procede en otro punto. Las actualizaciones de red son una ocasión acreditada para los intentos de estafa. En torno a un fork aparecen con regularidad mensajes que instan a una supuesta migración o que piden una frase semilla. Ningún cambio real de protocolo exige eso jamás. Quien te pide que introduzcas tus palabras de recuperación va a por tu dinero.

Valoración: en qué se ve si la fecha se sostiene

Tres señales dirán más en las próximas semanas que cualquier titular.

La primera es Devnet-11 a partir del 14 de septiembre. Si funciona varios días sin interrupción, el 6 de octubre resulta plausible. Si la finalización vuelve a romperse, la fecha se aplaza.

La segunda son las publicaciones de los equipos de los clientes. En cuanto varios clientes publiquen en pocos días versiones estables con soporte para Sepolia, el fork estará realmente preparado. Ese orden no se invierte nunca.

La tercera es la propia página de hoja de ruta. Allí figura el próximo hito con su fecha, y el dato se mantiene al día. La decisión original la describimos en agosto en nuestro artículo sobre la fecha de Glamsterdam para Sepolia; la reserva de septiembre todavía no consta allí. Las actas de las reuniones de desarrolladores las resume Christine Kim en sus notas sobre la 245.ª reunión de desarrolladores de la capa de ejecución.

Fecha de Glamsterdam y actualización del cliente: lo que te llevas

1. Anota hoy tus dos versiones de cliente y suscríbete a sus avisos de publicación. No hay nada que instalar: el 11 de septiembre ninguno de los diez clientes comprobados llevaba una versión estable con referencia a Glamsterdam. Si prefieres no operar un nodo, nuestra comparativa de plataformas de staking es la vía más rápida.
2. Observa Devnet-11 a partir del 14 de septiembre en lugar del calendario. La fecha de Sepolia del 6 de octubre depende de esa prueba y, para la red principal, solo existe de todos modos la indicación sin confirmar del cuarto trimestre de 2026. Si custodias tú mismo tus claves, nuestra comparativa de carteras hardware te ayuda a elegir dispositivo.
3. Trata cualquier invitación a migrar como un intento de estafa. Una actualización de protocolo nunca pide tu frase semilla. Mantén en su lugar tus registros ordenados, para que los ingresos por staking sigan siendo trazables; las herramientas adecuadas están en nuestra comparativa de software fiscal cripto.

(11 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.)