Fecha de Glamsterdam: Ethereum bifurca Sepolia el 28 de septiembre de 2026

Glamsterdam tiene fecha por primera vez. El 28 de septiembre de 2026 a las 14:44:48 UTC debe activarse en la red de pruebas Sepolia la próxima gran actualización de Ethereum. La cifra procede del acta de la reunión de desarrolladores del 20 de agosto de 2026, está fijada con precisión de época y de slot, y seis equipos de clientes la confirmaron en el chat de la sesión sin oposición.

Dos salvedades deben mencionarse en el mismo aliento, porque de lo contrario un calendario se convierte en una promesa. Primera: la fecha está sujeta a reserva, ya que el acta anota expresamente que la decisión se aplazó a la siguiente llamada. Segunda: afecta a una red de pruebas y en absoluto a una red principal. Para la mainnet sigue sin haber fecha, y las cifras que circulan al respecto ya no cuadran desde el 20 de agosto.

Este texto te muestra de dónde procede la fecha, cómo recalcularla tú mismo, qué puede aún tumbarla y qué cambia para ti como titular de ETH. Los antecedentes de contenido, es decir, qué cambios contiene realmente Glamsterdam y cómo funciona la selección para la actualización posterior, están en nuestro texto Actualización de Ethereum tras Glamsterdam: qué se ha decidido realmente en Hegotá. Aquí se trata del calendario.

¿Cuándo llega Glamsterdam? La primera fecha está en el acta de los desarrolladores

Los desarrolladores del núcleo de Ethereum coordinan sus actualizaciones en videoconferencias públicas, las All Core Devs Calls. Una llamada ACDC es la variante dedicada a la capa de consenso, es decir, la ronda en la que los equipos de los clientes de consenso acuerdan calendario, fallos y redes de pruebas. Estas llamadas se levantan en acta, y tanto el acta como la transcripción del chat se publican después en el repositorio de planificación del proyecto.

La frase de la que se trata figura en el acta de la llamada ACDC #185 del 20 de agosto de 2026. Bajo el epígrafe dedicado al estado de los forks se anota: Sepolia Glamsterdam fork proposed: epoch 351232, slot 11239424, Sep 28 2026 — no objections raised; decision deferred to next ACDC. La misma línea aparece una segunda vez en la lista de objetivos del mismo documento, allí con el añadido pending confirmation at next ACDC.

La transcripción del chat permite seguir el momento minuto a minuto. En el minuto 27:50, Parithosh Jayanthi, responsable de la coordinación de redes de pruebas en la Ethereum Foundation, escribe los valores completos en el chat: Sepolia: epoch 351232, slot 11239424, unix (1790606688), Mon 28 Sep 2026, 14:44:48. En los 60 segundos siguientes, seis participantes acusan recibo del mensaje con un emoji de barco, el signo habitual de conformidad en estas rondas: los representantes de Lodestar, ethrex, Lighthouse, Nethermind, Teku y Prysm. Poco después, Barnabas Busa deja constancia de cómo hay que leerlo: also no objection = agreement.

Esta cifra se distingue así de las fechas que por lo demás circulan en la cobertura informativa. No es la estimación de un observador ni la fecha deseada por un equipo concreto, sino una propuesta de la coordinación a la que los equipos de clientes no se opusieron en acta. Aun así, todavía no es vinculante.

Qué dicen la época, el slot y la marca de tiempo Unix sobre el fork de Sepolia

Un slot es la ventana fija de doce segundos en la que puede proponerse exactamente un bloque en Ethereum. Una época es un paquete de 32 slots de ese tipo, es decir, una ventana de seis minutos y 24 segundos. Las actualizaciones se anclan al inicio de una época, no a una hora del calendario. Esa es la razón por la que en las actas siempre aparecen tres cifras juntas.

El cálculo que hay detrás puedes reconstruirlo en dos pasos. El número de slot es el número de época multiplicado por 32: 351.232 por 32 da 11.239.424, y esa es exactamente la cifra que consta en el acta. La marca de tiempo resulta del momento de arranque de la cadena baliza de Sepolia más doce segundos por slot. El resultado es el valor Unix 1.790.606.688, que corresponde al lunes 28 de septiembre de 2026 a las 14:44:48 UTC. En horario de verano alemán serían las 16:44:48.

En la práctica esto significa una cosa que los titulares pierden con regularidad: la hora es un valor derivado y no una cita concertada. Solo se sostiene mientras la red produzca sus bloques a ritmo. Si faltan bloques, la activación real se desplaza hacia atrás sin que nadie haya cambiado la fecha.

Sepolia, Hoodi, mainnet: por qué un hard fork de Ethereum ocurre tres veces

Un hard fork es un cambio de las reglas del protocolo que no es retrocompatible: el software que no adopta la actualización deja de seguir la cadena a partir de ese momento. Como un error en este punto saldría caro, cada cambio se despliega por fases. Primero en redes de pruebas internas, después en redes de pruebas públicas y, por último, en la red principal.

Una red de pruebas es una cadena autónoma con el mismo software, pero con tokens sin valor. Sepolia es la red de pruebas en la que los desarrolladores de aplicaciones verifican sus contratos; Hoodi es la red más reciente, pensada sobre todo para infraestructura de validadores y de staking. Ambas tuvieron su línea en la llamada.

Para Hoodi, la misma fuente indicó la época 132352, el slot 4.235.264 y el valor Unix 1.793.036.568, es decir, el lunes 26 de octubre de 2026 a las 17:42:48 UTC. Esa línea, sin embargo, se sostiene con menos firmeza que la de Sepolia: el acta la acompaña del añadido contingent on stable DevNets, y en el chat el representante de Lighthouse, kingy_sigp, responde con la frase that date is fine with us provided we get a stable devnet ofc.

Para la mainnet, en cambio, el acta no contiene una sola línea. Ni en los acuerdos ni en la lista de objetivos aparece fecha alguna para la red principal. Quien hoy lee una cifra de mainnet está leyendo una proyección sin acuerdo detrás.

El fallo de DevNet 8: un error de caché en los depósitos de builder tumbó la finalidad

Una DevNet es una red de pruebas efímera que los desarrolladores levantan expresamente para una fase de actualización, a menudo solo durante unos días. Seis horas antes de la llamada del 20 de agosto se activó la fase Gloas en DevNet 8, y algo salió mal en el proceso.

El acta recoge el hecho y su causa en una frase: la activación desencadenó non-finality, la finalización acababa de recuperarse en el momento de la llamada, y como motivo se señala un error de caché en los depósitos de builder durante la transición del fork. Se vieron afectados tres clientes de consenso: Lighthouse, Prysm y Teku.

Un cliente es el software con el que un nodo participa en la red. Ethereum se implementa deliberadamente en paralelo por varios equipos independientes, de modo que un fallo en un software no arrastre a toda la red. Precisamente esa arquitectura funcionó aquí: el fallo alcanzó a tres implementaciones, la red volvió, y durante la llamada ya había contramedidas sobre la mesa.

El acta nombra dos de ellas de forma concreta. En Lodestar, una optimización del preprocesado de depósitos redujo la duración de la transición del fork de unos 20 segundos a unos 500 milisegundos; el cambio ya está en la rama principal. En Prysm se retiró de la rama la caché de depósitos de builder antes del fork, y una optimización adicional acorta la recuperación a un único slot incluso sin caché.

Qué significa la finalidad y por qué su pérdida frena el calendario de Glamsterdam

La finalidad designa el estado en el que un bloque se considera definitivo y solo podría revertirse con la pérdida de participaciones considerables. Si falla, la cadena sigue funcionando y produciendo bloques, pero nada de ello queda cerrado. Para un exchange, un puente o un protocolo de staking es el estado más incómodo que existe, porque no cabe afirmar con seguridad qué versión rige.

En el chat se discute exactamente esa valoración, y la discusión merece leerse porque separa con nitidez dos perspectivas. Barnabas Busa argumenta desde la óptica del protocolo: we might have unfinality on mainnet too. Why would this be an issue? We had no consensus issues. Dima Gusakov, del proveedor de staking Lido, responde desde la óptica del operador: precisamente por la pérdida de finalidad su equipo no pudo comprobar cómo atraviesan un hard fork sus oráculos y sus herramientas.

Lo en serio que se toma este estado por principio se ve en un comentario del mismo Barnabas Busa más adelante en la llamada: I think its also safe to say if we have 4-5 months non finality its game over. La afirmación se refería a una propuesta muy distinta sobre conservación de datos, pero marca el orden de magnitud en el que aquí se piensa.

Lido y Optimism piden una ventana de pruebas, la única objeción que consta en acta

La fecha se sostiene sin objeción formal, pero no sin reservas. Dos operadores plantearon condiciones de forma expresa en la llamada, y ambos constan por su nombre en el acta.

Lido, según Dima Gusakov, necesita al menos un día, preferiblemente dos, en una DevNet estable para comprobar oráculos y herramientas antes de la activación de Glamsterdam. Optimism, por boca de Chris Berry, solicitó una ventana comparable y lo precisó en el chat: We can do 1-2 days if we know. A ello se sumó la petición de anunciar el fork en la DevNet con una semana de antelación, para que los validadores estén en línea a tiempo.

Gusakov se muestra más claro sobre la fecha misma. Poco después de la línea de Hoodi escribe en el chat: I would rather have both dates a bit later. Like a week or so to have more room for the pending devnets testing. Otros dos participantes, Miguel Tenorio y Chris Berry, marcaron ese mensaje con un signo de conformidad. No es un veto y tampoco detuvo la propuesta, pero es la única voz documentada que considera demasiado pronto el 28 de septiembre.

Quien quiera situar la fecha tiene ya las dos caras. A favor están seis conformidades de los equipos de clientes y la constatación en el acta de que no se planteó objeción alguna. En contra está que el mayor operador de staking de la red desea más margen y que la línea de Hoodi queda expresamente supeditada a DevNets estables.

El 3 de septiembre es la fecha detrás de la fecha: decide la llamada ACDC #186

La formulación decisiva del acta es el inciso decision deferred to next ACDC. El 28 de septiembre es, por tanto, un objetivo que todavía debe someterse a votación. La pregunta real es entonces: ¿cuándo se convierte ese objetivo en un acuerdo?

Estas llamadas se celebran cada dos semanas. La llamada #184 tuvo lugar el 6 de agosto y la #185 el 20 de agosto. La siguiente es, por tanto, la del 3 de septiembre de 2026. Hasta entonces la fecha sigue siendo una propuesta con amplio respaldo; después estará confirmada, desplazada o dividida.

Para ti como lector esto tiene una utilidad práctica. Si entre el 3 y el 5 de septiembre lees en algún sitio que Glamsterdam ya tiene fecha, eso es la confirmación de esta propuesta y no una novedad. Si en cambio aparece allí una fecha distinta del 28 de septiembre, es que en la llamada se ha movido algo, y entonces merece la pena mirar el acta.

Por qué las fechas de mainnet que circulan, como el 4 de noviembre, ya no cuadran

Los agregadores de calendarios en lengua inglesa vienen recogiendo desde hace semanas tres cifras para Glamsterdam: Sepolia el 21 de septiembre, Hoodi el 5 de octubre y la mainnet el 4 de noviembre de 2026. En las páginas correspondientes, esos datos suelen aparecer señalados como proyección a partir de objetivos anteriores y no llevan acuerdo detrás.

Con los datos del 20 de agosto, las tres han quedado superadas. La cifra de Sepolia se ha desplazado una semana hacia atrás y la de Hoodi tres semanas. Y un fork de mainnet el 4 de noviembre quedaría solo nueve días después del fork de Hoodi del 26 de octubre. En Ethereum, entre la segunda red de pruebas pública y la red principal median habitualmente varias semanas, durante las cuales se observa y evalúa la activación. Nueve días serían inusualmente escasos para ese paso.

Las informaciones en alemán de mediados de agosto siguen, por su parte, ancladas en la situación previa a la llamada. Allí Glamsterdam es una actualización desplazada al cuarto trimestre de 2026 y con retraso. Eso fue correcto hasta el 19 de agosto y desde entonces es incompleto, porque faltan las líneas de las redes de pruebas. Si en esta situación orientas decisiones por una fecha que has encontrado en un titular, merece la pena la comprobación en la fuente. Quien de todos modos esté comparando proveedores encontrará las condiciones actuales en nuestra comparativa de los mejores exchanges de criptomonedas.

La EIP-7610 queda cancelada de Glamsterdam, no aplazada

Una EIP es una Ethereum Improvement Proposal, es decir, la propuesta formal de un cambio técnico concreto. Qué EIP entran en una actualización lo deciden los desarrolladores del núcleo precisamente en estas llamadas, y la lista permanece abierta hasta poco antes de la activación.

En la llamada del 20 de agosto, un participante preguntó por el estado de la EIP-7610, que había quedado fuera del alcance de Glamsterdam: si estaba aplazada o cancelada del todo. La respuesta del editor de EIP Jochem Brouwer en el chat es inequívoca: To answer explicitly, cancelled. I will also ask authors to formally withdraw this EIP. El acta recoge el mismo punto entre los acuerdos y da el motivo: la EIP-7610 queda sustituida por la EIP-8253, y esta apunta a Hegotá, la actualización posterior a Glamsterdam.

La diferencia entre aplazada y cancelada suena académica, pero tiene consecuencias para el calendario. Una EIP aplazada vuelve a aparecer en la misma lista en la ronda siguiente. Una cancelada está zanjada, y en su lugar entra otra propuesta con otro contenido.

Hegotá abre su primera ronda de selección: EIP-833 y EIP-8379

Mientras Glamsterdam avanza hacia las redes de pruebas, en la misma llamada ha comenzado la selección para la actualización posterior. Según el acta, dos propuestas se consideran previstas provisionalmente: la EIP-833, que corrige un error de desplazamiento de una unidad en el cálculo de las raíces de los puntos de control y mejora la precisión de los votos de destino, y la EIP-8379, que pretende convertir al cliente de consenso en la única fuente de sincronización y reducir así la propagación duplicada de bloques.

Una tercera propuesta, la EIP-12188 sobre el acortamiento de la ventana de conservación de bloques de consenso, no acabó ni en la lista ni en la papelera: volvió a la discusión de investigación. El acta señala al respecto que un participante cuestionó la motivación y que otro se mostró abierto con reservas.

Más interesante para el calendario es el acuerdo organizativo que la acompaña. Todos los equipos de clientes deben publicar hasta mediados de septiembre una primera valoración de las propuestas de Hegotá, en cuatro niveles de S a D. Barnabas Busa definió los niveles en el chat: S corresponde a una recomendación firme de inclusión, A a una recomendación en cuanto se resuelvan los puntos abiertos, B a un objetivo ambicioso y D a un rechazo. Para la DevCon debe salir de ahí un consenso aproximado sobre el alcance.

Qué cambia para ti como titular de ETH el 28 de septiembre

La respuesta corta: nada. El 28 de septiembre afecta a Sepolia, y Sepolia es una red de pruebas. El ETH que allí se utiliza carece de valor de mercado, se reparte gratis a través de grifos y no puede canjearse por ETH real. Un fork en Sepolia no toca ni tu saldo ni tus direcciones ni tu situación fiscal.

En esta actualización tampoco hay instantánea, ni canje, ni token nuevo. Glamsterdam es una actualización de protocolo de la cadena existente, no una escisión de cadena ni una migración. Quien te cuente otra cosa te está vendiendo algo.

A eso apunta precisamente el fraude más frecuente en torno a las fechas de fork. Tras cada anuncio de fecha aparecen mensajes que instan a actuar: una supuesta migración de cartera, un formulario de desbloqueo, un plazo. La regla en contra es sencilla y no admite excepción: una actualización de Ethereum nunca te exige introducir tu frase semilla, mover fondos o verificar una cuenta.

Staking, nodo propio y saldo en el exchange: quién tiene que actuar de verdad en un fork

Un hard fork genera necesidad de actuar en un solo punto, a saber, entre quienes operan software por su cuenta. El círculo es reducido.

Si operas tu propio nodo o validador

Entonces tienes que actualizar tu software cliente, antes de la activación, a una versión que conozca las nuevas reglas. Para las redes de pruebas rige desde la fecha correspondiente; para la mainnet, más adelante. Quien lo omite deja de seguir la cadena tras el fork. La experiencia de la DevNet del 20 de agosto muestra además que conviene tomar no la primerísima versión, sino aquella en la que los fallos de transición ya están corregidos.

Si haces staking a través de un proveedor

Entonces la actualización corre a cargo del proveedor, y precisamente por eso Lido pidió una ventana de pruebas en la llamada. A ti te queda la tarea de saber de antemano quién es tu proveedor y cómo comunica. Un proveedor que calla ante las actualizaciones tampoco será más locuaz en la próxima incidencia.

Si tus ETH están en un exchange o en una cartera

Entonces no te toca hacer nada. El exchange actualiza sus propios nodos y las carteras sin nodo propio siguen automáticamente. La experiencia muestra que algunos exchanges suspenden depósitos y retiradas durante unas horas en torno a los grandes forks de mainnet. Es rutina, se anuncia con antelación y en cualquier caso no afecta a los forks de redes de pruebas.

Cómo comprobar tú mismo la fecha de Glamsterdam en cinco minutos

No dependes de ningún titular. Los documentos de los desarrolladores del núcleo son públicos, y el camino hasta ellos es el mismo que ha recorrido este texto.

En el repositorio de planificación del proyecto, los materiales de cada sesión están ordenados por fecha. Para la llamada del 20 de agosto de 2026 son dos archivos: el resumen con acuerdos y objetivos y la transcripción completa del chat. En el primero encontrarás las líneas sobre estado de los forks, acuerdos y objetivos; en la segunda, las marcas de tiempo, las cifras tal cual y las reacciones de los equipos.

La conversión la haces tú mismo. Multiplica el número de época por 32 y tendrás el slot. Multiplica el slot por doce segundos y suma el momento de arranque de la cadena correspondiente, y tendrás la marca de tiempo Unix. Si tu resultado coincide con la hora indicada, la cifra es coherente consigo misma. Si se desvía, alguien copió sin hacer las cuentas.

Para tener una visión de conjunto de la valoración de cada propuesta, el proyecto opera además una herramienta pública de clasificación a la que se remitió expresamente en la llamada. Allí podrás leer, a partir de mediados de septiembre, cómo clasifican los equipos de clientes las propuestas de Hegotá.

Interpretar las fechas de actualización de Ethereum: qué debes retener

El 28 de septiembre de 2026 es la primera fecha sólida que existe para Glamsterdam. Rige para una red de pruebas, está sujeta a confirmación el 3 de septiembre y todavía no dice nada sobre la red principal. Quien lo tenga presente leerá las próximas semanas con bastante más calma que el mercado.

1. Apunta el 3 de septiembre en tu calendario, no el 28 de septiembre. Ese día decide la siguiente llamada si la fecha se mantiene. Hasta entonces, toda información que emplee la palabra «decidido» es imprecisa. Si de todos modos vas a revisar condiciones, nuestra comparativa de exchanges es la entrada más rápida.
2. Aclara de antemano quién hace la actualización en tu caso. Con nodo propio eres tú; con un proveedor de staking es el proveedor. Quien todavía esté eligiendo proveedor debería fijarse en cómo comunica en torno a las actualizaciones; las diferencias están en nuestra comparativa de staking.
3. Trata cualquier llamada a actuar como un intento de fraude. Una actualización de protocolo nunca exige migrar tus fondos. Custodiar uno mismo sus claves es la mejor protección frente a esta artimaña; los dispositivos para ello están en nuestra comparativa de carteras de hardware.

(21 de agosto 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.)