Actualización de Ethereum tras Glamsterdam: qué se ha decidido realmente en Hegotá

La próxima gran actualización de la red Ethereum se llama Glamsterdam; la siguiente lleva el nombre de Hegotá. Desde el 16 de agosto de 2026 circula una cifra por la prensa especializada: 66 propuestas estarían en debate para Hegotá. Quien lea ahí que la actualización traerá 66 novedades ha entendido mal el dato. En el documento oficial de planificación de los desarrolladores de Ethereum figura ese día exactamente una propuesta firmemente programada.

Este artículo te muestra de dónde viene la diferencia, cómo leer tú mismo el documento de planificación y en qué reconoces si una función anunciada llegará realmente a la red. Esa capacidad te servirá mucho más allá de hoy. Hasta que Hegotá se active en el año previsto, 2027, leerás decenas de informaciones sobre supuestas funciones de Ethereum, de las cuales una parte considerable nunca entrará en servicio. Todas las cifras de este texto proceden de un recuento propio de los documentos EIP oficiales realizado el 16 de agosto de 2026.

Qué es Hegotá y dónde se sitúa esta actualización de Ethereum en la hoja de ruta

Una actualización de Ethereum es técnicamente un hard fork: un cambio de las reglas del protocolo que todos los nodos de la red deben adoptar en el mismo momento. Quien no acompaña acaba en una cadena que los demás ya no siguen. Por eso cada cambio de este tipo se acuerda durante meses, se ensaya en redes de prueba y solo después recibe una fecha de activación firme. Si quieres repasar con calma la base técnica que hay detrás, nuestra explicación sobre el funcionamiento de Ethereum te ayudará.

Las actualizaciones llevan nombres sin significado propio, lo que dificulta seguirlas. Los desarrolladores principales trabajan actualmente en Glamsterdam, cuya mascota es, según el documento de planificación, un oso polar. En paralelo avanza la preparación de la actualización siguiente, Hegotá. Cada uno de los dos proyectos tiene su propio documento de control, en el que se anota en qué estado está cada cambio concreto. Para Glamsterdam es el EIP-7773, creado el 26 de septiembre de 2024. Para Hegotá es el EIP-8081, creado el 11 de noviembre de 2025. Ambos mantienen hasta hoy el estado de edición «Draft».

Qué contiene Glamsterdam y por qué esa actualización se considera especialmente relevante lo recogimos en un análisis propio sobre Glamsterdam y la cotización de Ethereum del 5 de abril de 2026. Hegotá es su sucesora y se encuentra hoy en el punto en el que Glamsterdam estaba hace unos dos años.

Por qué la fase de selección te afecta directamente como tenedor de ETH

Sería cómodo despachar el asunto como un tema de desarrolladores. Eso no llega muy lejos, porque un hard fork cambia a la vez y para todos las comisiones de cálculo, los tipos de transacción y las obligaciones de los validadores. Dos ejemplos de la lista ya firmemente programada para Glamsterdam lo hacen palpable: los EIP-8037 y EIP-8038 elevan el coste de gas de escribir y leer datos de estado, y el EIP-7981 encarece las listas de acceso. Quien trabaja mucho con contratos inteligentes pagará después comisiones distintas de las de hoy.

El staking de ETH también se ve afectado. El EIP-8061, de la lista de Glamsterdam, eleva el límite de cuántos validadores pueden salir o fusionarse por unidad de tiempo. Eso influye en cuánto esperas por tu saldo cuando deshaces una posición. Si cobras tus recompensas a través de un proveedor y quieres saber qué condiciones rigen allí ahora mismo, encontrarás la comparativa en nuestro repaso de las plataformas de staking; los plazos de pago de los proveedores y las reglas del protocolo son dos frenos distintos, que actúan de forma independiente.

Para ti, que simplemente compras ETH y lo dejas quieto, la cuenta es más sencilla: tu plataforma de negociación tiene que actualizar sus nodos a tiempo; de lo contrario, los ingresos y las retiradas se detienen en torno a la fecha de activación. Justamente por eso los exchanges anuncian ventanas de mantenimiento antes de cada hard fork. Si quieres saber con qué estabilidad trabaja tu propia plataforma en estos cambios y qué comisiones se aplican, el resumen está en la comparativa de exchanges de criptomonedas.

El metadocumento de hard fork EIP-8081 es la única lista vinculante

Para cada actualización, los desarrolladores principales crean lo que se conoce como un meta-EIP. No contiene técnica, sino solo un inventario: qué propuestas concretas están en debate, cuáles se examinan, cuáles están firmemente programadas y cuáles se han descartado. Como autores del EIP-8081 figuran Tim Beiko, Alex Stokes, Ansgar Dietrichs, Nixo y Parithosh Jayanthi, es decir, el mismo grupo responsable de los metadocumentos de las actualizaciones anteriores.

Este documento importa porque es el único lugar donde una clasificación queda registrada de forma vinculante. Una aportación en un foro de discusión, una ponencia en un congreso o un mensaje en una red social no dice nada sobre si un cambio llegará. Solo cuando alguien presenta una modificación del metadocumento y esta se acepta, la propuesta adquiere un estado oficial. Puedes consultar el documento completo en cualquier momento: EIP-8081, Hardfork Meta Hegotá.

El recuento del 16 de agosto de 2026: un EIP programado, 37 propuestas

Recuperamos el documento en bruto del repositorio de los desarrolladores de Ethereum y contamos las entradas de cada sección. La consulta devolvió el código 200 y el recuento arroja el siguiente cuadro.

La cifra más elocuente de este recuento es el cero. Mientras no se haya rechazado ni una sola propuesta, la selección no ha comenzado. Coincide con lo que describe la prensa especializada, según la cual los desarrolladores principales quieren empezar a recortar en las próximas reuniones. Para ti significa que la mayor parte de las 37 propuestas presentadas no entrará en esta actualización, y que hoy nadie sabe con fiabilidad cuáles serán.

Las cuatro etapas del EIP-7723 y qué garantizan realmente

Los términos del metadocumento no son giros del lenguaje, sino estados definidos. Están fijados en un documento propio, el EIP-7723, titulado «Network Upgrade Inclusion Stages», creado en junio de 2024 y que ha alcanzado el estado «Last Call». Quien sepa distinguir estos cuatro términos leerá cualquier noticia futura sobre actualizaciones con más fiabilidad de la que ofrecen la mayoría de los titulares. Puedes consultar las definiciones aquí: EIP-7723, Network Upgrade Inclusion Stages.

«Proposed for Inclusion» es solo una solicitud

Para elevar una propuesta a este nivel basta con presentar una modificación del metadocumento que añada la entrada. No hace falta la conformidad de los desarrolladores principales, ni una implementación terminada, ni pruebas. El documento se limita a dejar constancia de que alguien propone el cambio para esta actualización y queda disponible como interlocutor. Las 37 entradas que figuran ahora bajo este punto en Hegotá no han recorrido, por tanto, más que una presentación.

«Considered for Inclusion» es una declaración de intenciones, no un compromiso

Una propuesta alcanza este nivel después de que los equipos de desarrollo la hayan revisado y manifiesten la intención de probarla en una red de prueba. El EIP-7723 compara expresamente este estado con un «concept ACK» de otros proyectos de código abierto y escribe en el mismo párrafo que ese estado no basta para un despliegue en la red principal. Desde aquí, una propuesta puede volver al rechazo en cualquier momento, si los equipos se deciden en contra.

«Scheduled for Inclusion» exige una madurez medida

Solo este nivel significa que una propuesta va camino de la red principal. El EIP-7723 fija para ello cuatro criterios de control: la propuesta funcionó en una red de prueba que trabajó de forma estable durante al menos una semana y no mostró fallos críticos. La especificación ya no contiene marcadores provisionales ni preguntas de redacción abiertas. Las interacciones con otras propuestas son escasas o se han comprobado en esa misma red de prueba. Y la cobertura de pruebas es suficiente, sin que el software de los distintos proveedores difiera entre sí. Incluso después, la clasificación rige solo «a reserva de problemas imprevistos», y también desde aquí es posible una retirada.

Un efecto colateral práctico de las reglas merece recordarse: en cuanto el metadocumento pasa del estado «Draft» al estado «Review», las listas de propuestas y de rechazos se retiran de él. Al pasar al estado «Last Call» desaparece también la lista de candidatos examinados. Camino de su conclusión, el documento se acorta en lugar de alargarse. Si lo abres de nuevo dentro de unos meses y encuentras de repente solo una lista breve, es señal de avance y no un error.

FOCIL (EIP-7805) es el único componente firme de Hegotá

La única propuesta ya firmemente programada para Hegotá lleva el número EIP-7805 y las siglas FOCIL, que desarrolladas son «Fork-choice enforced Inclusion Lists». Se creó el 1 de noviembre de 2024 y como autores figuran Thomas Thiery, Francesco D'Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann y Jihoon Song.

El problema que aborda FOCIL lo describe con claridad la propia especificación: el derecho a construir bloques se subasta hoy entre proveedores especializados. Como consecuencia, unos pocos de estos constructores dominan la producción de bloques y la resistencia de la red frente a la censura se ha resentido. En la práctica significa que un constructor de bloques puede apartar una transacción, por ejemplo porque toca una dirección sancionada, sin que tú tengas derecho a que otro la recoja.

El mecanismo funciona en cuatro pasos. En cada intervalo de tiempo se designa como comité a un grupo de validadores; cada miembro elabora, desde su propia vista del depósito de transacciones, una lista de inclusión y la difunde por la red. El proponente del bloque siguiente y todos los atestiguadores recogen esas listas y las transmiten. El productor del bloque tiene que incorporar a su bloque las transacciones de todas las listas recogidas. Y los atestiguadores solo votan a favor del bloque si así lo ha hecho. Una petición se convierte así en una condición.

Para ti como usuario, esa es la diferencia entre «mi transacción probablemente se incluirá» y «mi transacción tiene que incluirse». Para los validadores crece la lista de tareas, porque el servicio de comité se suma a la operativa habitual. Quien tenga su ETH en staking a través de un proveedor debería comprobar de antemano cómo gestiona ese proveedor las nuevas obligaciones de protocolo; las condiciones actuales están en nuestra comparativa de staking.

Frame Transaction (EIP-8141) sostiene la vía de la privacidad

La segunda entrada con estado propio es el EIP-8141, denominado «Frame Transaction», creado el 29 de enero de 2026. La lista de autores es inusualmente larga e incluye, entre otros, a Vitalik Buterin, Felix Lange, Yoav Weiss, Alex Forshtat, Dror Tirosh, Shahaf Nacson, Derek Chiang, Stavros Vlachakis y Toni Wahrstätter. En Hegotá la propuesta se sitúa en el nivel «Considered for Inclusion» y es allí, por ahora, la única entrada.

En cuanto al contenido, introduce un nuevo tipo de transacción cuya comprobación de validez y cuyo pago de comisiones son de definición libre. Para ello la transacción se descompone en secciones, llamadas frames, que asumen sucesivamente la comprobación, la liberación de la comisión y la ejecución propiamente dicha. La especificación aduce varios motivos: salir del procedimiento de curvas elípticas que se usa hoy hacia procedimientos que resistan también a los ordenadores cuánticos; desacoplar una cuenta de su clave, con lo que un cambio de clave resulta posible dentro del propio protocolo; cuentas de contrato inteligente más sencillas y por ello más seguras, con procesamiento por lotes incorporado; así como modelos de comisiones alternativos, sin proveedores intermediarios.

El punto del cambio de clave merece atención si custodias tú mismo tus tenencias. Hoy una cuenta está unida de forma indisoluble a un par de claves; si la clave se pierde o cae en malas manos, la dirección queda quemada. Un cambio de clave anclado en el protocolo relajaría esa lógica. Hasta entonces, la custodia de la clave sigue siendo el eslabón decisivo, y para eso una solución de hardware continúa siendo la vía más sólida; en qué se diferencian los dispositivos, y en qué aspectos, está en nuestra comparativa de carteras hardware.

Qué significa realmente «privacidad nativa» en el documento

La información publicada el 16 de agosto de 2026 cita tres propuestas que en conjunto deberían permitir aplicaciones de privacidad sin intermediario: la Frame Transaction junto con el EIP-8250 («Keyed Nonces for Frame Transactions») y el EIP-8272 («Recent Roots for Frame Transactions»). El dato procede de una publicación del desarrollador Toni Wahrstätter.

En el metadocumento la situación se ve más sobria. De esas tres propuestas, una tiene el estado «Considered for Inclusion»; las otras dos figuran bajo «Proposed for Inclusion» y, por tanto, no han pasado ningún examen. Una cuarta entrada directamente relacionada con el tema, el EIP-8182 «Private ETH and ERC-20 Transfers», aparece igualmente solo entre las propuestas. El paquete que en los titulares se presenta como una ofensiva de privacidad se compone, en el documento oficial, de una entrada examinada y tres sin examinar.

Esta distinción no es una discusión de matices. De ella depende que puedas contar con una función dentro de dos años. Y se comprueba en treinta segundos, porque el documento es público.

66 propuestas en los medios, 39 entradas en el documento

Queda la pregunta de dónde sale la cifra de 66 cuando en el documento hay 39 entradas. Dos medios especializados informaron sobre ello el 16 de agosto de 2026, Cointelegraph y crypto.news, y ambos remiten a la misma publicación del desarrollador citado en una red social. No hemos podido consultar esa publicación por nuestra cuenta y por eso reproducimos la cifra expresamente como un dato de prensa. Solo los valores del metadocumento están verificados y contados por nosotros.

El motivo más probable de la diferencia está en qué se cuenta en cada caso. El metadocumento recoge únicamente lo que alguien ha presentado formalmente. En las reuniones de desarrolladores y en el foro de discusión circulan además propuestas que todavía no han dado ese paso. Ambas cifras pueden ser correctas y medir cosas distintas. Para ti como lector se deduce una regla de comprobación sencilla: una cifra sin el nivel que le corresponde no dice nada. Ante cada noticia de actualización, pregunta primero cuántas propuestas están firmemente programadas y sigue leyendo solo después.

Glamsterdam como referencia: 19 EIP programados y 41 rechazados

Cuánto adelgaza la selección al final se ve mirando la actualización anterior a Hegotá. El mismo recuento, aplicado al documento de Glamsterdam EIP-7773 el 16 de agosto de 2026, arroja 19 propuestas firmemente programadas, siete entradas más en categorías secundarias para protocolos de red y análisis, y 41 propuestas expresamente rechazadas. En Glamsterdam se descartó, por tanto, más de lo que se asumió.

Entre las propuestas de Glamsterdam firmemente programadas hay cambios de efecto apreciable, por ejemplo el EIP-7732 sobre el anclaje firme de la separación entre proponentes y constructores de bloques, el EIP-7928 sobre listas de acceso a nivel de bloque y el EIP-7954, que eleva el tamaño admisible de un contrato inteligente. Qué se activará realmente al final también aquí queda fijado solo con la activación.

Un detalle marginal resulta especialmente ilustrativo. Tres propuestas rechazadas para Glamsterdam reaparecen en el documento de Hegotá como propuestas: el EIP-7668 sobre la eliminación de los filtros de Bloom, el EIP-7819 sobre la instrucción SETDELEGATE y el EIP-7979 sobre nuevas instrucciones de llamada y retorno de la máquina virtual. Está expresamente previsto. El EIP-7723 recoge que un rechazo vale siempre solo para una actualización concreta y no impide un nuevo intento en la siguiente. Un rechazo no supone, por tanto, ningún juicio definitivo sobre una idea, solo una decisión sobre una fecha.

El calendario: Glamsterdam 2026, Hegotá 2027, ambos sin fecha firme

Con las fechas los documentos se muestran llamativamente prudentes, y esa es la información más honesta de todo el proceso. Ambos meta-EIP contienen una tabla con los momentos de activación para las redes de prueba y para la red principal. En los dos documentos todos los campos de esa tabla están vacíos. Debajo figura la indicación de que las filas se rellenarán en cuanto los equipos de desarrollo hayan fijado las fechas.

Lo que hay en cuanto a datos procede de la información publicada y de la hoja de ruta pública del proyecto: Glamsterdam debería llegar a la red principal en la segunda mitad de 2026, y los desarrolladores principales aspiran a Hegotá para el año siguiente. Como próxima cita para una reunión de desarrolladores, Cointelegraph menciona el lunes a las 14:00 UTC. Esa fecha no la hemos podido contrastar en la fuente primaria y por eso la damos como dato de prensa.

Para tu planificación significa que ahora mismo no hay ninguna fecha en la que puedas apoyarte, y que cualquier noticia que mencione una debería llevarte a comprobarla. Cómo ha evolucionado la discusión sobre la cotización de Ethereum al margen de todo esto es objeto de un análisis aparte de nuestra redacción; el texto de hoy no contiene deliberadamente ninguna afirmación sobre cotizaciones futuras.

Cómo seguir tú mismo la selección de una actualización de Ethereum, sin esperar a los titulares

La buena noticia de este asunto es que no tienes que fiarte de nadie. El documento es público, corto y se comprueba en pocos minutos. Una pasada se hace así:

1. Abre el EIP-8081 e ignora de entrada el texto corrido. Lo interesante son únicamente los títulos de sección y el número de entradas que hay debajo.
2. Cuenta las entradas bajo «Scheduled for Inclusion». Esa cifra es el núcleo sólido de cualquier noticia sobre la actualización.
3. Mira si hay algo bajo «Declined for Inclusion». Si esa lista crece, la selección ha empezado. Si sigue vacía, todo continúa abierto.
4. Echa un vistazo al EIP-7773 para ver qué precede a Hegotá en el tiempo y en qué estado se encuentra.
5. Comprueba el estado de edición del documento, arriba en la cabecera. Un paso de «Draft» a «Review» significa que la lista de propuestas se ha retirado y que el asunto se concreta.
6. Consulta la tabla de activación. Mientras ahí haya campos vacíos, no existe ninguna fecha acordada, al margen de lo que se escriba en otros sitios.

Quien haya hecho esta pasada dos veces apenas necesita cinco minutos la tercera. La ganancia es notable: puedes situar en poco tiempo cualquier noticia sobre una futura función de Ethereum, en lugar de tener que creértela.

Los límites de este recuento: a qué no responde el metadocumento

Para que sepas hasta dónde llegan las cifras de este texto, aquí están las limitaciones en claro. El recuento es una instantánea del 16 de agosto de 2026. Cada modificación aceptada del documento desplaza los valores, y en una fase de selección activa eso ocurre varias veces por semana.

El documento tampoco dice nada sobre cuánto ha avanzado la implementación en cada uno de los programas. Esa información está en los informes de las redes de prueba y en las actas de las reuniones de desarrolladores, no en el meta-EIP. Dice igual de poco sobre cuál de las 37 propuestas presentadas tiene alguna opción; quien lo afirme está interpretando en lugar de informar.

La cifra de 66, como se ha expuesto arriba, no la hemos comprobado en su fuente de origen. Y por último: una actualización de la red no es un acontecimiento de cotización. Ni el número de propuestas ni su estado dicen nada sobre el valor de ETH, y este artículo no deriva de ello expresamente ninguna expectativa.

Situar una actualización de Ethereum: qué te llevas de aquí

1. Cuenta las propuestas firmemente programadas, no las que se discuten. En Hegotá esa cifra está hoy en una, en Glamsterdam en 19. Todo lo demás es intención y no decide nada. Si tomas la evolución técnica como ocasión para construir o reordenar tu cartera, compara antes las comisiones y los pares de negociación de los proveedores en nuestra comparativa de exchanges.
2. Antes de cada hard fork, comprueba qué hace con él tu proveedor. Las ventanas de mantenimiento, las retiradas suspendidas y los plazos de salida modificados te afectan en la práctica antes que cualquier cambio del protocolo. Resulta especialmente relevante si cobras recompensas; las condiciones de los proveedores están en la comparativa de staking.
3. Mantén la custodia en tus propias manos. Mientras no exista un cambio de clave en el protocolo, todo depende de guardar tu clave con seguridad. En qué se diferencian los dispositivos, y cómo, está en la comparativa de carteras hardware.

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